lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 5 Sep 2014 16:22:42 -0700 From: Dmitry Torokhov <dmitry.torokhov@...il.com> To: Tejun Heo <tj@...nel.org> Cc: "Luis R. Rodriguez" <mcgrof@...not-panic.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Wu Zhangjin <falcon@...zu.com>, Takashi Iwai <tiwai@...e.de>, Arjan van de Ven <arjan@...ux.intel.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Oleg Nesterov <oleg@...hat.com>, hare@...e.com, Andrew Morton <akpm@...ux-foundation.org>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Joseph Salisbury <joseph.salisbury@...onical.com>, Benjamin Poirier <bpoirier@...e.de>, Santosh Rastapur <santosh@...lsio.com>, Kay Sievers <kay@...y.org>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Tim Gardner <tim.gardner@...onical.com>, Pierre Fersing <pierre-fersing@...rref.org>, Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>, Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>, Sreekanth Reddy <sreekanth.reddy@...gotech.com>, Abhijit Mahajan <abhijit.mahajan@...gotech.com>, Casey Leedom <leedom@...lsio.com>, Hariprasad S <hariprasad@...lsio.com>, MPT-FusionLinux.pdl@...gotech.com, Linux SCSI List <linux-scsi@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM Hi Tejun, On Sat, Sep 06, 2014 at 07:55:33AM +0900, Tejun Heo wrote: > Hello, Dmitry. > > On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote: > > On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote: > > > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote: > > > > It is for storage devices which always have guaranteed synchronous > > > > probing on module load and well-defined probing order. > > > > Agree about probing order (IIRC that is why we had to revert the > > wholesale asynchronous probing a few years back) but totally disagree > > about synchronous module loading. > > I don't get it. This is a behavior userland already depends on for > boots. What's there to agree or disagree? This is just a fact that > we can't do this w/o disturbing some userlands in a major way. I am just expressing my disbelief that somebody relies on module loading being synchronous with probing. Out of curiosity, do you have any pointers? > > > Anyway, I just posted a patch that I think preserves module loading > > behavior and solves my issue with built-in modules. It does not help > > Luis' issue though (but then I think the main problem is with systemd > > being stupid there). > > This sure can be worked around from userland side too by not imposing > any timeout on module loading but that said for the same reasons that > you've been arguing until now, I actually do think that it's kinda > silly to make device probing synchronous to module loading at this > time and age. What we disagree on is not that we want to separate > those waits. It is about how to achieve it. Well, there are separate things we want to solve. My main issue is not with modules, but rather compiled-in drivers that stall kernel boot, and these particular drivers are just fine if they are probed out of bound. > > > > To add a bit, if the argument here is that dependency on such behavior > > > shouldn't exist and module loading and device probing should always be > > > asynchronous, the right approach is implementing "synchronous_probing" > > > flag not the other way around. I actually wouldn't hate to see that > > > change happening but whoever submits and routes such a change should > > > be ready for a major shitstorm, I'm afraid. > > > > I think we already had this storm and that is why here we have opt-in > > behavior for the drivers. > > It's a different shitstorm where we actively break bootings on some > userlands. Trust me. That's gonna be a lot worse. That did break bootings and that's why we reverted the wholesale async probing. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists