[lkml]   [2007]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway)
    > > Actually there's also a non-malicious case in which waiting for
    > > requests to finish won't work: when one fuse filesystem is accessing
    > > another.
    > >
    > > Since we are blocking new fuse requests, that might block a fuse
    > > daemon, which in turn makes it impossible to finish the pending
    > > request.
    > Hmm, yes, this is ugly. But will it hurt? We'll just wait for number
    > of active fuse requests to go down to 0 before proceeding.

    I'm thinking of the following situation, immediately after we begin to
    wait for fuse requests to subside:

    - task A is performing file operation O1
    - O1 is being served by task B
    - task B needs to perform O2 before finishing O1

    Since we don't allow new requests, O2 will never start. So O1 will
    never finish. So the number of fuse requests will never go to 0.

    > It may still livelock on system with busy fused-s, but we'll detect
    > that with timeout, and I believe it is 'don't do that' situation.

    There are no busy fused's. If we allowed O2 to go through, everything
    would be nice and dandy. But we cannot know that O2 needs to be let
    through, and other fuse requests must not.

    > > And this is not at all theoretical, I know that encfs is used over
    > > various other fuse filesystems like sshfs or ntfs-3g.
    > >
    > > Yeah, stacking userspace filesystems could be done entirely in
    > > userspace, and I'm actually working on that (with fuse-2.7.0 already
    > > supporting some basic stacking).
    > Great.
    > > But the point is, that the "wait for fuse to quiescence" hack would
    > > not work in todays environment.
    > Ok, I'll just blame fuse here. 'You have to write to /sys
    > files for SIGKILL to work' is not funny.

    SIGKILL won't work on a stopped task. Neither on a traced task.
    Neither on a zombie (how many newbies are thoroughly confused about
    that ;)

    And it won't work on a task that is hanging on an NFS mount, when the
    network broke.

    Oh, and it won't work on a deadlocked fuse filesystem. How many of
    these have you met? How many of the others?

    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: 2007-07-13 00:01    [W:0.031 / U:17.244 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site