Messages in this thread | | | Date | Fri, 2 May 2008 18:22:00 -0400 | Subject | Re: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs | From | "J. Bruce Fields" <> |
| |
On Thu, May 01, 2008 at 07:24:32AM +0100, Al Viro wrote: > On Tue, Apr 29, 2008 at 05:42:31PM -0400, J. Bruce Fields wrote: > > The most likely consequences are that a local reader gets out-of-date > > data for a file that a Samba client has modified. > > > > I suppose that re-checking the d_count and i_count after step 3 might > > close the race. > > The hell it might.
Yeah, looking back at the code, I suppose by the time we've added the new lease to the inode's lock list, we've already broken conflicting leases. OK.
> Leases are broken, plain and simple. Not to mention > anything else, a couple of threads with shared descriptor table will > bypass these checks happily.
I lost you there.
> > FWIW, that's far from the worst problem in fs/locks.c, and not even the > worst one with leases. > > That, BTW, is a fine demonstration of the reasons why application-specific > kernel warts(tm) are bad. Lease support is samba-only turd; so's dnotify, > with its lovely problems. And interfaces like that *suck*; they are > developed with one application in mind and that leads to "we know how it > will be used" mentality. With obvious implications for quality of review > they get from their developers...
I honestly don't understand how exactly Samba uses leases; it'd be extremely useful to have a concise list of requirements from them. I know that they don't really meet the nfsv4 server's requirements (any bugs aside).
> Al, currently crawling through struct file_lock review and extremely annoyed > by the amount of turds being found...
Thanks, it's been long in need of more attention--details welcomed.
--b.
| |