On Thu 13-06-19 08:27:55, Matthew Wilcox wrote: > On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote: > > e.g. Process A has an exclusive layout lease on file F. It does an > > IO to file F. The filesystem IO path checks that Process A owns the > > lease on the file and so skips straight through layout breaking > > because it owns the lease and is allowed to modify the layout. It > > then takes the inode metadata locks to allocate new space and write > > new data. > > > > Process B now tries to write to file F. The FS checks whether > > Process B owns a layout lease on file F. It doesn't, so then it > > tries to break the layout lease so the IO can proceed. The layout > > breaking code sees that process A has an exclusive layout lease > > granted, and so returns -ETXTBSY to process B - it is not allowed to > > break the lease and so the IO fails with -ETXTBSY. > > This description doesn't match the behaviour that RDMA wants either. > Even if Process A has a lease on the file, an IO from Process A which > results in blocks being freed from the file is going to result in the > RDMA device being able to write to blocks which are now freed (and > potentially reallocated to another file). I think you're partially wrong here. You are correct that the lease won't stop process A from doing truncate on the file. *But* there are still page pins in existence so truncate will block on waiting for these pins to go away (after all this is a protection that guards all short-term page pin users). So there is no problem with blocks being freed under the RDMA app. Yes, the app will effectively deadlock and sysadmin has to kill it. IMO an acceptable answer for doing something stupid and unsupportable... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
