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

* Alan Cox wrote: > On Mon, 8 Jan 2018 11:08:36 +0100 > Peter Zijlstra wrote: > > > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote: > > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman > > > wrote: >

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

u appear to have hardware, it would be great if you could > test James' v3 (https://patchwork.kernel.org/patch/9519383/). Sorry for > the inconvenience. As per the interdiff below v2->v3 did not change the code in any way, only the name of the function and a comment, so you can add this to v

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

* James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Mon, 2017-01-16 at 10:22 +0100, Ingo Molnar wrote: > > * James Bottomley <james.bottom...@hansenpartnership.com> wrote: > > > > > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: &

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

* James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > > So there's a new mpt3sas SCSI driver boot regression, introduced in > > this merge window, which made one of my servers unbootable. > >

[PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

o it's reverting 18f6084a989b (while keeping ata_12_16_cmd() around to enable the 7ff723ad0f87 fix) that does the trick. Thanks, Ingo > >From 0734e6d2a7f757172d6b7750d8fcf602909300e6 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mi...@kernel.org> Date: Sun,

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

* Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Sat, Apr 16, 2016 at 11:03:32AM +0200, Ingo Molnar wrote: > > > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > > > > I don't think we know yet if there's a reliable way to turn the bug off

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

* Josh Poimboeuf wrote: > > I don't think we know yet if there's a reliable way to turn the bug off. > > > > Also, according to the gcc guys, this bug won't always result in a > > truncated function, and may sometimes just make some inline function > > call sites

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

* Denys Vlasenko wrote: > > In fact, the following patch seems to fix it: > > > > diff --git a/include/scsi/scsi_transport_fc.h > > b/include/scsi/scsi_transport_fc.h > > index bf66ea6..56b9e81 100644 > > --- a/include/scsi/scsi_transport_fc.h > > +++

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

* William Breathitt Gray <vilhelm.g...@gmail.com> wrote: > On Wed, Apr 13, 2016 at 09:26:02AM +0200, Ingo Molnar wrote: > >What's the practical motivation of this? What exact hardware is this for? > > > >Thanks, > > > > Ingo > > The PC/104 bus is

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

* William Breathitt Gray wrote: > This patchset is based on top of commit 3a3a5fece6f2 ("fs: kernfs: Replace > CURRENT_TIME by current_fs_time()") of the driver-core-testing branch of > the driver-core repository. > > The introduction of the ISA_BUS option in commit

Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h

to hide places where vmalloc() et al are added to files but the include of vmalloc.h is forgotten. Good idea. Acked-by: Ingo Molnar mi...@kernel.org Based in Linus' tree of today. There are probably more places that need vmalloc.h included, but this passes 64 bit and 32 bit allmodconfig

Re: spinlock_irqsave() flags (Was: pm80xx: Spinlock fix)

* Oleg Nesterov o...@redhat.com wrote: On 12/23, Ingo Molnar wrote: * Oleg Nesterov o...@redhat.com wrote: Initially I thought that this is obviously wrong, irqsave/irqrestore assume that flags is owned by the caller, not by the lock. And iirc this was certainly wrong in the past

Re: spinlock_irqsave() flags (Was: pm80xx: Spinlock fix)

* Oleg Nesterov o...@redhat.com wrote: On 12/23, Oleg Nesterov wrote: Perhaps we should ask the maintainers upstream? Even if this works, I am not sure this is _supposed_ to work. I mean, in theory spin_lock_irqave() can be changed as, say #define spin_lock_irqsave(lock, flags)

Re: RFC: Allow block drivers to poll for I/O instead of sleeping

* Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Jun 23, 2013 at 12:09 AM, Ingo Molnar mi...@kernel.org wrote: The spinning approach you add has the disadvantage of actively wasting CPU time, which could be used to run other tasks. In general it's much better to make sure

Re: RFC: Allow block drivers to poll for I/O instead of sleeping

* Jens Axboe ax...@kernel.dk wrote: - With the former note, the app either needs to opt in (and hence willingly sacrifice CPU cycles of its scheduling slice) or it needs to be nicer in when it gives up and goes back to irq driven IO. The scheduler could look at sleep latency averages of

Re: RFC: Allow block drivers to poll for I/O instead of sleeping

* David Ahern dsah...@gmail.com wrote: On 6/23/13 3:09 AM, Ingo Molnar wrote: If an IO driver is implemented properly then it will batch up requests for the controller, and gets IRQ-notified on a (sub-)batch of buffers completed. If there's any spinning done then it should be NAPI-alike

Re: RFC: Allow block drivers to poll for I/O instead of sleeping

* Matthew Wilcox wi...@linux.intel.com wrote: A paper at FAST2012 (http://static.usenix.org/events/fast12/tech/full_papers/Yang.pdf) pointed out the performance overhead of taking interrupts for low-latency block I/Os. The solution the author investigated was to spin waiting for each I/O

Re: [git patches] libata updates

* Linus Torvalds torva...@linux-foundation.org wrote: I couldn't find an example of that in a quick look, it's fairly uncommon to have non-conflicting merges that had semantic - but not contextual - conflicts. [...] This: git log --grep='Semantic merge\|Semantic conflict' gives over a

Re: [patch] pci: pci_enable_device_bars() fix

* Jeff Garzik [EMAIL PROTECTED] wrote: Ingo Molnar wrote: so please tell me Jeff. If Greg, who is the super-maintainer of your code area, and who deals with your code every day and changes it every minute and hour, simply did not Cc: the SCSI list - how am i, a largely outside party

Re: [patch] pci: pci_enable_device_bars() fix

* Jeff Garzik [EMAIL PROTECTED] wrote: Ingo Molnar wrote: === --- linux.orig/drivers/scsi/lpfc/lpfc_init.c +++ linux/drivers/scsi/lpfc/lpfc_init.c @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev, uint16_t

Re: [patch] pci: pci_enable_device_bars() fix

* Jeff Garzik [EMAIL PROTECTED] wrote: Ingo Molnar wrote: it would have been totally appropriate for me to just send a mail to lkml with the proper subject line about the breakage. (I might even have decided to stay completely silent about the issue and fix it for my own build, letting

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

* Bob Tracy [EMAIL PROTECTED] wrote: Current state of the source tree is the 6f37ac... version, so I'll start backing out the above diffs in related groups and continue until I've got a working kernel. For lack of an obvious target, I'll start with the seemingly innocuous change to

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

* Bob Tracy [EMAIL PROTECTED] wrote: I'm struggling to see how any of those could have broken block device mounting on alpha. Are you sure you bisected right? Based on what's in that commit, it *does* appear something went wrong with bisection. If the implicated commit is the next

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

* Bob Tracy [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * Bob Tracy [EMAIL PROTECTED] wrote: Current state of the source tree is the 6f37ac... version, so I'll start backing out the above diffs in related groups and continue until I've got a working kernel. For lack

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

* Andrew Morton [EMAIL PROTECTED] wrote: then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

* Bob Tracy [EMAIL PROTECTED] wrote: Finally got back in town. Starting the git-bisect process. I've got a relatively slow network connection, and the PWS 433au isn't exactly what I would call fast by modern standards, so bear with me while I get things set up and crank through this.

Re: [BUG] 2.6.24-rc3-git2 softlockup detected

* Kamalesh Babulal [EMAIL PROTECTED] wrote: So 2.6.24-rc3 was OK and 2.6.24-rc3-git2 is not? Yes, the 2.6.24-rc3 was Ok and this is seen from 2.6.24-rc3-git2/3/4. just to make sure: this is a real lockup and failed bootup (or device init), not just a message, right? Ingo - To

Re: [BUG] 2.6.24-rc3-git2 softlockup detected

* Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Ingo, This softlockup is seen in the 2.6.24-rc4 either and looks like a message because this is seen while running tbench and machine continues running other test's after the softlockup messages and some times seen with the bootup, but the

Re: [2/2] 2.6.23-rc2: known regressions with patches

* Michal Piotrowski [EMAIL PROTECTED] wrote: Memory management Subject : [bug] SLUB freeing locks References : http://lkml.org/lkml/2007/7/26/90 Last known good : ? Submitter : Ingo Molnar [EMAIL PROTECTED] Caused-By : ? Handled-By : Peter Zijlstra [EMAIL

Re: [PATCH] remove name length check in a workqueue

yeah ... cannot remember why i have done it originally :-| Acked-by: Ingo Molnar [EMAIL PROTECTED] Ingo On Wed, 10 Aug 2005, James Bottomley wrote: Ingo, This has been in the workqueue code in day one, for no real reason that I can see. We just tripped over it in SCSI because