[lkml]   [2005]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CIFS improvements/wider testing needed
    Steve French wrote:
    > Eric,
    > Thanks for the feedback - any bugs which you report which I can
    > reproduce - I will treat
    > as a very high priority and your testing is helpful.

    I know you have tried to reproduce them and failed. The question was how
    to go further?

    >> Trying to push Linux in corporate environments in such condition is
    >> very difficult because, due to those bugs, you cannot:
    >> 1) save a new openoffice document twice, 2) create mail folders
    >> from inside thunderbird (local mailbox
    > shared
    >> with windows),
    > You can avoid these by mounting with "nobrl" (no remote byte range
    > lock) mount option (smbfs does not send byte range locks so would not
    > run into this problem, but would run into others). These appear to be
    > byte range locking problems. The problem is that cifs has to map
    > advisory to mandatory locks which only works if the application is
    > reasonably well behaved (not even Samba has support for advisory
    > locks although they will come with the new Unix extensions). It may
    > be made worse by a bug in openoffice (some Linux apps such as
    > Evolution lock on the "wrong" file handle which does not fail in
    > posix, although is sloppy coding) but I have not confirmed the byte
    > range lock sequence which openoffice is trying as we did with
    > Evolution - I did confirm that nobrl (disabling the byte range locks
    > on the client) works. Note that this mount option, although not
    > listed as a bug fix in git per-se - was added to address the
    > evolution etc. locking bugs. There are quite a few of the cifs
    > changes that fall into that category.

    Well I would be surprised the "cat >> titi" command does any of this
    byte range lock. If the "create and later rewrite the same file"
    sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
    titi), how can it works with complicated applications?

    >> 3) avoid to do FSCK after each reboot,
    > Not sure that cifs would cause this unless you mean that cifs was
    > hung and shutdown hung.

    Yes : the system hangs when shutting down as the result of the "umount
    -a" with the last message being as described in bug N° 3237. I have to
    press power button for 5 seconds.

    NB : manually doing the umount does exactly the same things.

    > To avoid cases where cifs requests could stay
    > blocked forever (especially locking requests), I added a umount_begin
    > routine a few weeks ago to try to free threads blocked in cifs - but
    > what I need from users/tests if they see a cifs umount fail is to
    > know where the requests are hung so I can add wakeup calls for that
    > condition in cifs's umount_begin (you can do "echo t >
    > /proc/sysrq-trigger" then "dmesg > debugdata" to get the debugdata
    > which has the callstacks of processes blocked in kernel).

    Will do that in the bug data.

    >> <>

    > Although I would like to find a workaround so it does not hang the
    > umount or fail umount I am not convinced that this is a typical
    > regression - if a server sends an illegal response which we were not
    > catching before ... it would be dangerous to call preventing that
    > potential security problem a regression.

    Hanging a system systematically leading to FSCK on each reboot is not
    particularly helpfull given the fact that it happens whebn you are doing
    a shutdown in most cases.

    -- eric

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-21 18:29    [W:0.025 / U:0.688 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site