On Friday 25 January 2008 05:33, Theodore Tso wrote:Hi Ted, There are a few holes: * The process may try to handle the signal and end up blocking on the filesystem again. * The process might pass the fd to another process by forking or fd passing. * The process holding the fd might be trying to take a lock held by another process that is blocked on the filesystem, and infinite variations on that theme. Remembering the task that did the ioctl might work out better than remembering the fd. Or just not try to be so fancy and rely on the application to take appropriate measures to ensure it will not access the filesystem, such as memlocking and not execing. The freezer also needs to run in PF_MEMALLOC mode or similar unless it can be sure it will not cause pageout to the frozen filesystem under low memory conditions. Regards, Daniel --
| David Miller | Re: Slow DOWN, please!!! |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Josip Rodin | bnx2_poll panicking kernel |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
