[lkml]   [2012]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 4/4] {RFC} kmod.c: Add new call_usermodehelper_timeout()API
Boaz Harrosh wrote:
> That's fine. I will fail totally gracefully, and nothing will happen. I like this
> example if the system is under heavy load and there is no memory and the
> iscsi auto-login takes more then 15 second (Settable by module param) then I'd
> rather fail the login and revert to plain NFS-MDS IO, instead of the direct osd-target
> IO. Believe me.

So, race with timeout causes no inconsistency to the kernel.
Then, it will be no problem to have timeout-able version.

> >> I don't want any chance of D stating IO operations.
> >> (My code is in the IO path, either fsync or write-back. There is not
> >> always a killable target)
> >
> > Then, isn't UMH_NO_WAIT better than UMH_WAIT_PROC?
> >
> No I need to wait for the application to finish the iscsi login before
> I can continue IO to the target. Otherwise what's the point.

Your code which launches usermodehelper is in the I/O path, isn't it?
Then, don't you need to use GFP_NOFS rather than GFP_KERNEL?

I'm not familiar with GFP_* flags usage. Can somebody clarify when we need to
use GFP_NOFS rather than GFP_KERNEL by enumerating the name of function (e.g.
xxxfs_writepage()) and/or the name of locks (e.g. xxx_mutex)? I've asked this
in the past but
explanation with actual function/variable names is easier to understand.

 \ /
  Last update: 2012-03-23 06:27    [W:0.130 / U:2.200 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site