On Friday, 6-Jul-2007 at 7:17 +0200, Thomas Gleixner wrote:
> On Thu, 2007-07-05 at 19:12 -0400, Ernie Petrides wrote:
> > On Thursday, 5-Jul-2007 at 16:49 MDT, Chris Friesen wrote:
> >
> > > Ernie Petrides wrote:
> > >
> > > > Only kernels built w
On Friday, 6-Jul-2007 at 7:17 +0200, Thomas Gleixner wrote:
On Thu, 2007-07-05 at 19:12 -0400, Ernie Petrides wrote:
On Thursday, 5-Jul-2007 at 16:49 MDT, Chris Friesen wrote:
Ernie Petrides wrote:
Only kernels built with the CONFIG_HIGH_RES_TIMERS option enabled were
On Thursday, 5-Jul-2007 at 16:49 MDT, Chris Friesen wrote:
> Ernie Petrides wrote:
>
> > Only kernels built with the CONFIG_HIGH_RES_TIMERS option enabled were
> > vulnerable.
>
> As I mentioned in my post to Thomas, we have high res timers disabled
> and were st
On Thursday, 5-Jul-2007 at 11:48 MDT, "Chris Friesen" wrote:
> Clemens Koller wrote:
>
> > Okay, we all survived Y2K and this little glitch. Puh! ;-)
> > Can you please explain in which configuration this problem got triggered.
>
> As far as I can tell many kernel versions contained the source
On Thursday, 5-Jul-2007 at 16:49 MDT, Chris Friesen wrote:
Ernie Petrides wrote:
Only kernels built with the CONFIG_HIGH_RES_TIMERS option enabled were
vulnerable.
As I mentioned in my post to Thomas, we have high res timers disabled
and were still affected. Granted, our kernel has
On Thursday, 5-Jul-2007 at 11:48 MDT, Chris Friesen wrote:
Clemens Koller wrote:
Okay, we all survived Y2K and this little glitch. Puh! ;-)
Can you please explain in which configuration this problem got triggered.
As far as I can tell many kernel versions contained the source code bug.
On Thursday, 1-Mar-2007 at 7:22 PST, Andrew Morton wrote:
> On Thu, 01 Mar 2007 03:47:39 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
> > Rusty Russell wrote:
> > > On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
> > >
> > >> What would be really, really nice would be to
On Thursday, 1-Mar-2007 at 7:22 PST, Andrew Morton wrote:
On Thu, 01 Mar 2007 03:47:39 -0800 Zachary Amsden [EMAIL PROTECTED] wrote:
Rusty Russell wrote:
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
What would be really, really nice would be to statically check all
IO signals. With current code,
in a multi-threaded process, I think only the thread arming the SIGIO
gets the signal, whereas it seems that the whole thread group should
be signaled.
This has only been compile-tested.
Cheers. -ernie
Signed-off-by: Ernie Petrides <[EMAIL PROTECTED]>
--- lin
,
in a multi-threaded process, I think only the thread arming the SIGIO
gets the signal, whereas it seems that the whole thread group should
be signaled.
This has only been compile-tested.
Cheers. -ernie
Signed-off-by: Ernie Petrides [EMAIL PROTECTED]
--- linux-2.6.19/drivers/char/tty_io.c.orig
Hi, folks. While investigating the 2.4 memory corruption problem fixed
by the patch previously posted, it was noticed that the 2.6 version of
get_kcore_size() inappropriately uses sizeof(struct memelfnote) in its
calculation of the /proc/kcore ELF header size. What is actually stored
in the
Hi, Marcelo. A fairly nasty memory corruption potential exists when
/proc/kcore is accessed and there are at least 62 vmalloc'd areas.
The problem is that get_kcore_size() does not properly account for
the elf_prstatus, elf_prpsinfo, and task_struct structure sizes in
the fabricated ELF header,
Hi, Marcelo. A fairly nasty memory corruption potential exists when
/proc/kcore is accessed and there are at least 62 vmalloc'd areas.
The problem is that get_kcore_size() does not properly account for
the elf_prstatus, elf_prpsinfo, and task_struct structure sizes in
the fabricated ELF header,
Hi, folks. While investigating the 2.4 memory corruption problem fixed
by the patch previously posted, it was noticed that the 2.6 version of
get_kcore_size() inappropriately uses sizeof(struct memelfnote) in its
calculation of the /proc/kcore ELF header size. What is actually stored
in the
14 matches
Mail list logo
