On Sat, Jan 13, 2018 at 10:51 AM, Linus Torvalds
wrote:
> On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote:
> So your argument depends on "the uarch will actually run the code in
> order if there are no events that block the pipeline".
And might be bogus ... I'm a soft
On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
wrote:
> Should the array access in entry_SYSCALL_64_fastpath be made to use
> the masking approach?
That one has a bounds check for an inline constant.
cmpq$__NR_syscall_max, %rax
so should be safe.
The classic Spectre variant #1 code s
g the
> wrong way. Does this fix it?
Yes. That fixes it.
Wrap whichever of:
Reported-by: Tony Luck
and/or
Tested-by: Tony Luck
around that patch and ship it!
Thanks for the fast fix.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a
Oops ... forgot final step. That commit does revert cleanly (at least
git did not grumble when I asked it to revert). The resulting kernel
builds cleanly and boots without seeing this problem.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message
> This is alive and well in 2.6.13 (final) on ia64.
Or perhaps not. When I went into the machine room to take
a look at this machine, I found that the disk drive in
question was making some very bad noises. A few minutes
later it stopped responding at all.
Putting in a new drive, I see a consis
This is alive and well in 2.6.13 (final) on ia64. Excerpts from dmesg
when booting:
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
GSI 28 (level, low) -> CPU 1 (0xc218) vector 49
ACPI: PCI Interrupt :06:02.0[A] -> GSI 28 (level,
6 matches
Mail list logo
