[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.021 / U:45.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site