Date: Sat, 20 Sep 2003 01:47:44 +0100 From: Bruce M Simpson <bms@spc.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: ATAng still problematic Message-ID: <20030920004744.GA13242@saboteur.dek.spc.org> In-Reply-To: <20030920021721.F52973@newtrinity.zeist.de> References: <20030918134850.GA22643@student.agh.edu.pl> <200309181354.h8IDsa0F023908@spider.deepcore.dk> <20030918155125.GC22643@student.agh.edu.pl> <20030919182152.A98528@newtrinity.zeist.de> <20030919233632.GB32858@rot13.obsecurity.org> <20030920021721.F52973@newtrinity.zeist.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 20, 2003 at 02:17:21AM +0200, Marius Strobl wrote: > > Isn't it still a kernel bug if a user process can trigger a panic? > > Yes, it seems to be a bug in the mlockall(2) implementation. Backing > it out or hindering cdrecord to use it avoids the panic. I already > wrote an email to bms@ who commited the mlockall(2) and munlockall(2) > support regarding this issue. I don't think that's been conclusively established yet, so statements of the form above are a bit unhelpful. The problem may well lie elsewhere in the system, as a parameter in vm_map_copy_entry() is being unexpectedly set to NULL in the backtrace which you provided me with. If more people can exercise the same codepath as you appear to be exercising with different configurations, then I will have more to go on. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030920004744.GA13242>