Messages in this thread | | | Date | Mon, 18 Jun 2001 12:55:21 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] devfs v181 available |
| |
On Mon, 18 Jun 2001, Richard Gooch wrote:
> > Irrelevant. BKL provides an exclusion only on non-blocking areas. > > Yeah, I know all that.
So what the hell are you talking about?
> > _Moved_ them there from the callers of these functions. And AFAICS > > you do need BKL for get_devfs_entry_...(); otherwise relocation of > > the table will be able to screw you inside of that function. Now, it > > will merrily screw you anyway in a lot of places, but that's another > > story. > > OK, so it was another global change.
Moving BKL into the ->readlink() and ->follow_link()? Sure, it was a global change. About a year ago.
> Question: assuming data fed to vfs_follow_link() is "safe", does it ^^^^^^^^ > need the BKL? I can see that vfs_readlink() obviously doesn't need > it. From reading Documentation/filesystems/Locking I suspect it > doesn't need the BKL, but the way I read it says "follow_link() method > does not *have* the BKL already". But that doesn't explicitely say > whether vfs_follow_link() needs it.
vfs_follow_link() doesn't need it. Moreover, if data fed to it is unsafe without BKL, you are screwed even if you take BKL. So assumption above is bogus - you _never_ need BKL on that call.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |