Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2014-09-05 23:18:28
Also in:
linux-scsi, lkml
On Fri, Sep 05, 2014 at 04:05:30PM -0700, Arjan van de Ven wrote:
On 9/5/2014 3:52 PM, Dmitry Torokhov wrote:quoted
On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:quoted
On 9/5/2014 3:29 PM, Tejun Heo wrote:quoted
Hello, Dmitry. On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:quoted
I do not agree that it is actually user-visible change: generally speaking you do not really know if device is there or not. They come and go. Like I said, consider all permutations, with hot-pluggable buses, deferred probing, etc,It is for storage devices which always have guaranteed synchronous probing on module load and well-defined probing order. Sure, modern setups are a lot more dynamic but I'm quite certain that there are setups in the wild which depend on storage driver loading being synchronous. We can't simply declare one day that such behavior is broken and break, most likely, their boots.we even depend on this in the mount-by-label cases many setups assume that the internal storage prevails over the USB stick in the case of conflicts. it's a security issue; you don't want the built in secure bootloader that has a kernel root argument by label/uuid. the security there tends to assume that built-in wins over USBAhem... and they sure it works reliably with large storage arrays? With SCSI doing probing asynchronously already?you tend to trust your large storage array you tend to not trust the walk up USB stick.
If you allow physical access it does not matter really. -- Dmitry