Miklos Szeredi wrote:You skimmed over some stuff, like the pathname lookup component contained in the first set of dots... I can't guarantee that ->foo() won't always return ESTALE. That said, the loop is not unbreakable. At least for NFS, a signal to the process will interrupt the loop because the error returned will change from ESTALE to EINTR. These changes include the base assumption that the components of the underlying file system are basically reliable, that there is a way to deal with bugs and/or malicious entities in the short term, and that these things will be dealt with appropriately in the longer term. The short term resolution is a signal. The longer term fix is to hunt down the bug or the malicious entity and either make it go away or fence it off via some security measure or another to prevent it from causing another problem. If the underlying file system is the type that could potentially return ESTALE, then it needs to be aware of the system architecture and handle things appropriately. Thanx... ps --
| Ingo Molnar | [patch 02/13] syslets: add syslet.h include file, user API/ABI definitions |
| Heiko Carstens | Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Rafael J. Wysocki | [Bug #10629] 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160 |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Linus Torvalds | Re: [GIT]: Networking |
| Mark Lord | Re: [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
