Linus Torvalds wrote:
>
> On Tue, 8 May 2001, Alan Cox wrote:
> >
> > I dont see where the alternative patch ensures the user didnt flip the
> > direction flag for one
>
> Yeah.
>
> We might as well just make it "eflags & IF", none of the other flags
> should matter (or we explicitly want them
On Tue, 8 May 2001, Alan Cox wrote:
>
> I dont see where the alternative patch ensures the user didnt flip the
> direction flag for one
Yeah.
We might as well just make it "eflags & IF", none of the other flags
should matter (or we explicitly want them cleared).
Linus
-
To u
> On Mon, 7 May 2001, Brian Gerst wrote:
> >
> > Keep in mind that regs->eflags could be from user space, and could have
> > some undesirable flags set. That's why I did a test/sti instead of
> > reloading eflags. Plus my patch leaves interrupts disabled for the
> > minimum time possible.
>
> T
> If anybody has such a beast, please try this kernel patch _and_ running
> the F0 0F bug-producing program (search for it on the 'net - it must be
One apparent problem with this implementation
> + *
> + * This verifies that the fault happens in kernel space
> + * (error_code & 4)
Linus Torvalds wrote:
>
> In particular, does anybody have a buggy Pentium to test with the F0 0F
> lock-up bug? It _should_ be caught with the error-code test (it's a
> protection fault, not a non-present fault and thus the F0 0F case never
> enters the vmalloc path), but it's been several year
Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Brian Gerst wrote:
> >
> > Keep in mind that regs->eflags could be from user space, and could have
> > some undesirable flags set. That's why I did a test/sti instead of
> > reloading eflags. Plus my patch leaves interrupts disabled for the
> > mini
At 18:12 07/05/2001, Linus Torvalds wrote:
>In particular, does anybody have a buggy Pentium to test with the F0 0F
>lock-up bug?
[snip]
>If anybody has such a beast, please try this kernel patch _and_ running
Still works ok (2.4.5-pre1 + patch). SIGILL is sent.
Best regards,
Anton
--
Anton
On Mon, 7 May 2001, Brian Gerst wrote:
> Nigel Gamble wrote:
> >
> > On Mon, 7 May 2001, Linus Torvalds wrote:
> > > On Mon, 7 May 2001, Brian Gerst wrote:
> > > > This patch will still cause the user process to seg fault: The error
> > > > code on the stack will not match the address in %cr2.
>
On Mon, 7 May 2001, Brian Gerst wrote:
>
> Keep in mind that regs->eflags could be from user space, and could have
> some undesirable flags set. That's why I did a test/sti instead of
> reloading eflags. Plus my patch leaves interrupts disabled for the
> minimum time possible.
The plain "popf
On Mon, 7 May 2001, Linus Torvalds wrote:
> On Mon, 7 May 2001, Brian Gerst wrote:
> > This patch will still cause the user process to seg fault: The error
> > code on the stack will not match the address in %cr2.
>
> You've convinced me. Good thinking. Let's do the irq thing.
I've actually seen
Nigel Gamble wrote:
>
> On Mon, 7 May 2001, Linus Torvalds wrote:
> > On Mon, 7 May 2001, Brian Gerst wrote:
> > > This patch will still cause the user process to seg fault: The error
> > > code on the stack will not match the address in %cr2.
> >
> > You've convinced me. Good thinking. Let's do
On Mon, 7 May 2001, Brian Gerst wrote:
>
> This patch will still cause the user process to seg fault: The error
> code on the stack will not match the address in %cr2.
You've convinced me. Good thinking. Let's do the irq thing.
Linus
-
To unsubscribe from this list: send the l
Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Alan Cox wrote:
> >
> > That is nice. I hadn't thought about doing it that way. It still has the problem
> > if %cr2 is corrupted by a vmalloc fault but it cleans up my other code paths
> > nicely.
>
> See about "corruption" in previous email. It doe
At 18:12 07/05/2001, Linus Torvalds wrote:
>Untested.
>
>In particular, does anybody have a buggy Pentium to test with the F0 0F
>lock-up bug?
Yes, I have one. 2.4.3-ac6 (plus a few patches) detects the bug on boot up
and enables the work around. Running the f00f test program from SGI results
i
At 18:32 07/05/2001, Dunlap, Randy wrote:
> > From: David Woodhouse [mailto:[EMAIL PROTECTED]]
> >
> > [EMAIL PROTECTED] said:
> > > If anybody has such a beast, please try this kernel patch _and_
> > > running the F0 0F bug-producing program (search for it on the 'net -
> > > it must be out ther
[EMAIL PROTECTED] said:
> > echo "unsigned long main=0xf00fc7c8;" > f00fbug.c ; make f00fbug
> Yes, that's what the (SGI) program uses:
> http://lwn.net/2001/0329/a/ltp-f00f.php3
Restated on l-k for the benefit of anyone naïve enough to expect me to have
got it right... my original version wo
> From: David Woodhouse [mailto:[EMAIL PROTECTED]]
>
> [EMAIL PROTECTED] said:
> > If anybody has such a beast, please try this kernel patch _and_
> > running the F0 0F bug-producing program (search for it on the 'net -
> > it must be out there somewhere) to verify that the code still
> > correc
[EMAIL PROTECTED] said:
> If anybody has such a beast, please try this kernel patch _and_
> running the F0 0F bug-producing program (search for it on the 'net -
> it must be out there somewhere) to verify that the code still
> correctly handles that case.
Something along the lines of:
echo "u
On Mon, 7 May 2001, Alan Cox wrote:
>
> That is nice. I hadn't thought about doing it that way. It still has the problem
> if %cr2 is corrupted by a vmalloc fault but it cleans up my other code paths
> nicely.
See about "corruption" in previous email. It doesn't exist.
For better debugging, we
On Mon, 7 May 2001, Alan Cox wrote:
>
> I dont see that we will get a valid value in both cases.
>
> get_user
> fault - set %cr2
> IRQ
> vmalloc
> fault
>
> Alan Cox wrote:
> > (The current -ac fix for the double vmalloc races is below. WP test makes it
> > more complex than is nice)
>
> WP test is easy to handle. Just filter out protection violations and
> only take the vmalloc path if the page was not found.
>
> - if (address >= TASK_SIZE
Alan Cox wrote:
> (The current -ac fix for the double vmalloc races is below. WP test makes it
> more complex than is nice)
WP test is easy to handle. Just filter out protection violations and
only take the vmalloc path if the page was not found.
- if (address >= TASK_SIZE && !(error_code
> Yes, we'll get a clobbered value, but we'll get a _valid_ clobbered value,
> and we'll just end up doing the fixups twice (and returning to the user
> process that didn't get the page it wanted, which will end up re-doing the
> page fault).
I dont see that we will get a valid value in both case
Linus Torvalds wrote:
>
> On Sat, 5 May 2001, Brian Gerst wrote:
> >
> > Currently the page fault handler on the x86 can get a clobbered value
> > for %cr2 if an interrupt occurs and causes another page fault (interrupt
> > handler touches a vmalloced area for example) before %cr2 is read.
>
> T
On Sat, 5 May 2001, Brian Gerst wrote:
>
> Currently the page fault handler on the x86 can get a clobbered value
> for %cr2 if an interrupt occurs and causes another page fault (interrupt
> handler touches a vmalloced area for example) before %cr2 is read.
That should be ok.
Yes, we'll get a c
Currently the page fault handler on the x86 can get a clobbered value
for %cr2 if an interrupt occurs and causes another page fault (interrupt
handler touches a vmalloced area for example) before %cr2 is read. This
patch changes the page fault and alignment check (currently unused)
handlers to in
26 matches
Mail list logo
