Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Sat, Jan 13, 2018 at 10:51 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck <tony.l...@gmail.com> wrote: > So your argument depends on "the uarch will actually run the code in > order if there are no even

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

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

Re: scsi scan: INQUIRY result too short (5), using 36

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

Re: scsi scan: INQUIRY result too short (5), using 36

rounding the wrong way. Does this fix it? Yes. That fixes it. Wrap whichever of: Reported-by: Tony Luck tony.l...@intel.com and/or Tested-by: Tony Luck tony.l...@intel.com around that patch and ship it! Thanks for the fast fix. -Tony -- To unsubscribe from this list: send the line

RE: As of 2.6.13-rc1 Fusion-MPT very slow

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,

RE: As of 2.6.13-rc1 Fusion-MPT very slow

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