* [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process @ 2014-03-04 19:10 Jeff Layton 2014-03-04 19:19 ` Andy Lutomirski 2014-03-04 19:35 ` J. Bruce Fields 0 siblings, 2 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 19:10 UTC (permalink / raw) To: linux-fsdevel; +Cc: bfields, luto My expectation is that programs shouldn't mix classic and file-private locks, but Glenn Skinner pointed out to me that that may occur at times even if the programmer isn't aware. Suppose we have a program that uses file-private locks. That program then links in a library that uses classic POSIX locks. If those locks end up conflicting and one is using blocking locks, then the program could end up deadlocked. Try to catch this situation in posix_locks_deadlock by looking for the case where the blocking lock was set by the same process but has a different type, and have the kernel return EDEADLK if that occurs. This check is not perfect. You could (in principle) have a threaded process that is using classic locks in one thread and file-private locks in another. That's not necessarily a deadlockable situation but this check would cause an EDEADLK return in that case. By the same token, you could also have a file-private lock that was inherited across a fork(). If the inheriting process ends up blocking on that while trying to set a classic POSIX lock then this check would miss it and the program would deadlock. Signed-off-by: Jeff Layton <jlayton@redhat.com> --- fs/locks.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 6fdf26a79cc8..19c0c5c24b93 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -790,7 +790,17 @@ static int posix_locks_deadlock(struct file_lock *caller_fl, int i = 0; /* - * This deadlock detector can't reasonably detect deadlocks with + * If one lock is file-private and the other one isn't, and these are + * owned by the same process, then we may be in a situation where + * a library is attempting to use a different locking flavor than the + * original program. + */ + if (caller_fl->fl_pid == block_fl->fl_pid && + IS_FILE_PVT(caller_fl) != IS_FILE_PVT(block_fl)) + return 1; + + /* + * This deadlock detector can't reasonably detect cyclic deadlocks with * FL_FILE_PVT locks, since they aren't owned by a process, per-se. */ if (IS_FILE_PVT(caller_fl)) -- 1.8.5.3 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 19:10 [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process Jeff Layton @ 2014-03-04 19:19 ` Andy Lutomirski 2014-03-04 19:35 ` J. Bruce Fields 1 sibling, 0 replies; 18+ messages in thread From: Andy Lutomirski @ 2014-03-04 19:19 UTC (permalink / raw) To: Jeff Layton; +Cc: Linux FS Devel, Bruce Fields On Tue, Mar 4, 2014 at 11:10 AM, Jeff Layton <jlayton@redhat.com> wrote: > My expectation is that programs shouldn't mix classic and file-private > locks, but Glenn Skinner pointed out to me that that may occur at times > even if the programmer isn't aware. > > Suppose we have a program that uses file-private locks. That program > then links in a library that uses classic POSIX locks. If those locks > end up conflicting and one is using blocking locks, then the program > could end up deadlocked. > > Try to catch this situation in posix_locks_deadlock by looking for the > case where the blocking lock was set by the same process but has a > different type, and have the kernel return EDEADLK if that occurs. > > This check is not perfect. You could (in principle) have a threaded > process that is using classic locks in one thread and file-private locks > in another. That's not necessarily a deadlockable situation but this > check would cause an EDEADLK return in that case. > > By the same token, you could also have a file-private lock that was > inherited across a fork(). If the inheriting process ends up blocking on > that while trying to set a classic POSIX lock then this check would miss > it and the program would deadlock. > This particular case IMO should *not* return -EDEADLK -- there's another process that has that fd open, and that process could release the lock. --Andy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 19:10 [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process Jeff Layton 2014-03-04 19:19 ` Andy Lutomirski @ 2014-03-04 19:35 ` J. Bruce Fields 2014-03-04 20:14 ` Jeff Layton 1 sibling, 1 reply; 18+ messages in thread From: J. Bruce Fields @ 2014-03-04 19:35 UTC (permalink / raw) To: Jeff Layton; +Cc: linux-fsdevel, luto On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > My expectation is that programs shouldn't mix classic and file-private > locks, but Glenn Skinner pointed out to me that that may occur at times > even if the programmer isn't aware. > > Suppose we have a program that uses file-private locks. That program > then links in a library that uses classic POSIX locks. If those locks > end up conflicting and one is using blocking locks, then the program > could end up deadlocked. > > Try to catch this situation in posix_locks_deadlock by looking for the > case where the blocking lock was set by the same process but has a > different type, and have the kernel return EDEADLK if that occurs. > > This check is not perfect. You could (in principle) have a threaded > process that is using classic locks in one thread and file-private locks > in another. That's not necessarily a deadlockable situation but this > check would cause an EDEADLK return in that case. > > By the same token, you could also have a file-private lock that was > inherited across a fork(). If the inheriting process ends up blocking on > that while trying to set a classic POSIX lock then this check would miss > it and the program would deadlock. If the caller's not prepared for the library to use classic posix locks, then it's not going to know how to recover from this EDEADLCK either, is it? I guess I don't understand how this helps anyone. Has it ever made sense for a library function and its caller to both use classic posix locking on the same file without any coordination? Besides the first-close problem there's the problem that locks merge, so for example you can't hold your own lock across a call to a function that grabs and drops a lock on the same file. --b. > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > --- > fs/locks.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/fs/locks.c b/fs/locks.c > index 6fdf26a79cc8..19c0c5c24b93 100644 > --- a/fs/locks.c > +++ b/fs/locks.c > @@ -790,7 +790,17 @@ static int posix_locks_deadlock(struct file_lock *caller_fl, > int i = 0; > > /* > - * This deadlock detector can't reasonably detect deadlocks with > + * If one lock is file-private and the other one isn't, and these are > + * owned by the same process, then we may be in a situation where > + * a library is attempting to use a different locking flavor than the > + * original program. > + */ > + if (caller_fl->fl_pid == block_fl->fl_pid && > + IS_FILE_PVT(caller_fl) != IS_FILE_PVT(block_fl)) > + return 1; > + > + /* > + * This deadlock detector can't reasonably detect cyclic deadlocks with > * FL_FILE_PVT locks, since they aren't owned by a process, per-se. > */ > if (IS_FILE_PVT(caller_fl)) > -- > 1.8.5.3 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 19:35 ` J. Bruce Fields @ 2014-03-04 20:14 ` Jeff Layton 2014-03-04 20:19 ` Andy Lutomirski 2014-03-04 20:35 ` J. Bruce Fields 0 siblings, 2 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 20:14 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-fsdevel, luto On Tue, 4 Mar 2014 14:35:51 -0500 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > > My expectation is that programs shouldn't mix classic and file-private > > locks, but Glenn Skinner pointed out to me that that may occur at times > > even if the programmer isn't aware. > > > > Suppose we have a program that uses file-private locks. That program > > then links in a library that uses classic POSIX locks. If those locks > > end up conflicting and one is using blocking locks, then the program > > could end up deadlocked. > > > > Try to catch this situation in posix_locks_deadlock by looking for the > > case where the blocking lock was set by the same process but has a > > different type, and have the kernel return EDEADLK if that occurs. > > > > This check is not perfect. You could (in principle) have a threaded > > process that is using classic locks in one thread and file-private locks > > in another. That's not necessarily a deadlockable situation but this > > check would cause an EDEADLK return in that case. > > > > By the same token, you could also have a file-private lock that was > > inherited across a fork(). If the inheriting process ends up blocking on > > that while trying to set a classic POSIX lock then this check would miss > > it and the program would deadlock. > > If the caller's not prepared for the library to use classic posix locks, > then it's not going to know how to recover from this EDEADLCK either, is > it? > Well, callers should be aware of that if we take this change. The semantics aren't yet set in stone... > I guess I don't understand how this helps anyone. > > Has it ever made sense for a library function and its caller to both use > classic posix locking on the same file without any coordination? > Not really, but that doesn't mean that it isn't done... ;) > Besides the first-close problem there's the problem that locks merge, so > for example you can't hold your own lock across a call to a function > that grabs and drops a lock on the same file. > It depends, but you're basically correct... It's likely that if the above situation occurred with a program using classic locks, then those locks were silently lost at times. It's also plausible that when it occurs that no one is aware of it due to the way POSIX locks work. If the program switched to using file-private locks and the library stays using classic locks (or vice versa), you then potentially trade that silent loss of locks for a deadlock (since classic and file-private locks always conflict). So, the idea would be to try to catch that situation explicitly and return a hard error instead of deadlocking. Unfortunately, it's a little tough to do that in all cases so all this does is try to catch a subset of them. Will it be helpful in the long run? I'm not sure. It seems unlikely to harm legit use cases though, and might catch some problematic situations. I can drop this if that's the consensus however. > > > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > > --- > > fs/locks.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/fs/locks.c b/fs/locks.c > > index 6fdf26a79cc8..19c0c5c24b93 100644 > > --- a/fs/locks.c > > +++ b/fs/locks.c > > @@ -790,7 +790,17 @@ static int posix_locks_deadlock(struct file_lock *caller_fl, > > int i = 0; > > > > /* > > - * This deadlock detector can't reasonably detect deadlocks with > > + * If one lock is file-private and the other one isn't, and these are > > + * owned by the same process, then we may be in a situation where > > + * a library is attempting to use a different locking flavor than the > > + * original program. > > + */ > > + if (caller_fl->fl_pid == block_fl->fl_pid && > > + IS_FILE_PVT(caller_fl) != IS_FILE_PVT(block_fl)) > > + return 1; > > + > > + /* > > + * This deadlock detector can't reasonably detect cyclic deadlocks with > > * FL_FILE_PVT locks, since they aren't owned by a process, per-se. > > */ > > if (IS_FILE_PVT(caller_fl)) > > -- > > 1.8.5.3 > > -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:14 ` Jeff Layton @ 2014-03-04 20:19 ` Andy Lutomirski 2014-03-04 20:37 ` Jeff Layton 2014-03-04 20:35 ` J. Bruce Fields 1 sibling, 1 reply; 18+ messages in thread From: Andy Lutomirski @ 2014-03-04 20:19 UTC (permalink / raw) To: Jeff Layton; +Cc: J. Bruce Fields, Linux FS Devel On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > On Tue, 4 Mar 2014 14:35:51 -0500 > "J. Bruce Fields" <bfields@fieldses.org> wrote: > >> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: >> > My expectation is that programs shouldn't mix classic and file-private >> > locks, but Glenn Skinner pointed out to me that that may occur at times >> > even if the programmer isn't aware. >> > >> > Suppose we have a program that uses file-private locks. That program >> > then links in a library that uses classic POSIX locks. If those locks >> > end up conflicting and one is using blocking locks, then the program >> > could end up deadlocked. >> > >> > Try to catch this situation in posix_locks_deadlock by looking for the >> > case where the blocking lock was set by the same process but has a >> > different type, and have the kernel return EDEADLK if that occurs. >> > >> > This check is not perfect. You could (in principle) have a threaded >> > process that is using classic locks in one thread and file-private locks >> > in another. That's not necessarily a deadlockable situation but this >> > check would cause an EDEADLK return in that case. >> > >> > By the same token, you could also have a file-private lock that was >> > inherited across a fork(). If the inheriting process ends up blocking on >> > that while trying to set a classic POSIX lock then this check would miss >> > it and the program would deadlock. >> >> If the caller's not prepared for the library to use classic posix locks, >> then it's not going to know how to recover from this EDEADLCK either, is >> it? >> > > Well, callers should be aware of that if we take this change. The > semantics aren't yet set in stone... > >> I guess I don't understand how this helps anyone. >> >> Has it ever made sense for a library function and its caller to both use >> classic posix locking on the same file without any coordination? >> > > Not really, but that doesn't mean that it isn't done... ;) > >> Besides the first-close problem there's the problem that locks merge, so >> for example you can't hold your own lock across a call to a function >> that grabs and drops a lock on the same file. >> > > It depends, but you're basically correct... > > It's likely that if the above situation occurred with a program using > classic locks, then those locks were silently lost at times. It's also > plausible that when it occurs that no one is aware of it due to the way > POSIX locks work. > > If the program switched to using file-private locks and the library > stays using classic locks (or vice versa), you then potentially trade > that silent loss of locks for a deadlock (since classic and > file-private locks always conflict). > > So, the idea would be to try to catch that situation explicitly and > return a hard error instead of deadlocking. Unfortunately, it's a > little tough to do that in all cases so all this does is try to catch a > subset of them. > > Will it be helpful in the long run? I'm not sure. It seems unlikely to > harm legit use cases though, and might catch some problematic > situations. I can drop this if that's the consensus however. I don't think I like it except in the case where there are no threads (number of tasks sharing the fd table is 1) and where the struct file only has one fd. Otherwise I think it can have false positives. Or am I missing something? --Andy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:19 ` Andy Lutomirski @ 2014-03-04 20:37 ` Jeff Layton 2014-03-04 20:40 ` J. Bruce Fields 2014-03-04 20:52 ` Trond Myklebust 0 siblings, 2 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 20:37 UTC (permalink / raw) To: Andy Lutomirski; +Cc: J. Bruce Fields, Linux FS Devel On Tue, 4 Mar 2014 12:19:44 -0800 Andy Lutomirski <luto@amacapital.net> wrote: > On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > > On Tue, 4 Mar 2014 14:35:51 -0500 > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > >> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > >> > My expectation is that programs shouldn't mix classic and file-private > >> > locks, but Glenn Skinner pointed out to me that that may occur at times > >> > even if the programmer isn't aware. > >> > > >> > Suppose we have a program that uses file-private locks. That program > >> > then links in a library that uses classic POSIX locks. If those locks > >> > end up conflicting and one is using blocking locks, then the program > >> > could end up deadlocked. > >> > > >> > Try to catch this situation in posix_locks_deadlock by looking for the > >> > case where the blocking lock was set by the same process but has a > >> > different type, and have the kernel return EDEADLK if that occurs. > >> > > >> > This check is not perfect. You could (in principle) have a threaded > >> > process that is using classic locks in one thread and file-private locks > >> > in another. That's not necessarily a deadlockable situation but this > >> > check would cause an EDEADLK return in that case. > >> > > >> > By the same token, you could also have a file-private lock that was > >> > inherited across a fork(). If the inheriting process ends up blocking on > >> > that while trying to set a classic POSIX lock then this check would miss > >> > it and the program would deadlock. > >> > >> If the caller's not prepared for the library to use classic posix locks, > >> then it's not going to know how to recover from this EDEADLCK either, is > >> it? > >> > > > > Well, callers should be aware of that if we take this change. The > > semantics aren't yet set in stone... > > > >> I guess I don't understand how this helps anyone. > >> > >> Has it ever made sense for a library function and its caller to both use > >> classic posix locking on the same file without any coordination? > >> > > > > Not really, but that doesn't mean that it isn't done... ;) > > > >> Besides the first-close problem there's the problem that locks merge, so > >> for example you can't hold your own lock across a call to a function > >> that grabs and drops a lock on the same file. > >> > > > > It depends, but you're basically correct... > > > > It's likely that if the above situation occurred with a program using > > classic locks, then those locks were silently lost at times. It's also > > plausible that when it occurs that no one is aware of it due to the way > > POSIX locks work. > > > > If the program switched to using file-private locks and the library > > stays using classic locks (or vice versa), you then potentially trade > > that silent loss of locks for a deadlock (since classic and > > file-private locks always conflict). > > > > So, the idea would be to try to catch that situation explicitly and > > return a hard error instead of deadlocking. Unfortunately, it's a > > little tough to do that in all cases so all this does is try to catch a > > subset of them. > > > > Will it be helpful in the long run? I'm not sure. It seems unlikely to > > harm legit use cases though, and might catch some problematic > > situations. I can drop this if that's the consensus however. > > I don't think I like it except in the case where there are no threads > (number of tasks sharing the fd table is 1) and where the struct file > only has one fd. Otherwise I think it can have false positives. Or > am I missing something? > The only case where I think this would hit a false positive is if you have a threaded program that's doing something weird like having one thread that's setting classic POSIX locks on a file, and one thread that isn't. Once you hit a conflict between the two, you'd get back EDEADLK on one of them, even though that situation might not actually be a deadlock. That doesn't really seem like a real-world use-case though, so I'm generally OK with that potential false-positive. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:37 ` Jeff Layton @ 2014-03-04 20:40 ` J. Bruce Fields 2014-03-04 20:44 ` Jeff Layton 2014-03-04 20:52 ` Trond Myklebust 1 sibling, 1 reply; 18+ messages in thread From: J. Bruce Fields @ 2014-03-04 20:40 UTC (permalink / raw) To: Jeff Layton; +Cc: Andy Lutomirski, Linux FS Devel On Tue, Mar 04, 2014 at 03:37:23PM -0500, Jeff Layton wrote: > On Tue, 4 Mar 2014 12:19:44 -0800 > Andy Lutomirski <luto@amacapital.net> wrote: > > > On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > > > On Tue, 4 Mar 2014 14:35:51 -0500 > > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > > > >> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > > >> > My expectation is that programs shouldn't mix classic and file-private > > >> > locks, but Glenn Skinner pointed out to me that that may occur at times > > >> > even if the programmer isn't aware. > > >> > > > >> > Suppose we have a program that uses file-private locks. That program > > >> > then links in a library that uses classic POSIX locks. If those locks > > >> > end up conflicting and one is using blocking locks, then the program > > >> > could end up deadlocked. > > >> > > > >> > Try to catch this situation in posix_locks_deadlock by looking for the > > >> > case where the blocking lock was set by the same process but has a > > >> > different type, and have the kernel return EDEADLK if that occurs. > > >> > > > >> > This check is not perfect. You could (in principle) have a threaded > > >> > process that is using classic locks in one thread and file-private locks > > >> > in another. That's not necessarily a deadlockable situation but this > > >> > check would cause an EDEADLK return in that case. > > >> > > > >> > By the same token, you could also have a file-private lock that was > > >> > inherited across a fork(). If the inheriting process ends up blocking on > > >> > that while trying to set a classic POSIX lock then this check would miss > > >> > it and the program would deadlock. > > >> > > >> If the caller's not prepared for the library to use classic posix locks, > > >> then it's not going to know how to recover from this EDEADLCK either, is > > >> it? > > >> > > > > > > Well, callers should be aware of that if we take this change. The > > > semantics aren't yet set in stone... > > > > > >> I guess I don't understand how this helps anyone. > > >> > > >> Has it ever made sense for a library function and its caller to both use > > >> classic posix locking on the same file without any coordination? > > >> > > > > > > Not really, but that doesn't mean that it isn't done... ;) > > > > > >> Besides the first-close problem there's the problem that locks merge, so > > >> for example you can't hold your own lock across a call to a function > > >> that grabs and drops a lock on the same file. > > >> > > > > > > It depends, but you're basically correct... > > > > > > It's likely that if the above situation occurred with a program using > > > classic locks, then those locks were silently lost at times. It's also > > > plausible that when it occurs that no one is aware of it due to the way > > > POSIX locks work. > > > > > > If the program switched to using file-private locks and the library > > > stays using classic locks (or vice versa), you then potentially trade > > > that silent loss of locks for a deadlock (since classic and > > > file-private locks always conflict). > > > > > > So, the idea would be to try to catch that situation explicitly and > > > return a hard error instead of deadlocking. Unfortunately, it's a > > > little tough to do that in all cases so all this does is try to catch a > > > subset of them. > > > > > > Will it be helpful in the long run? I'm not sure. It seems unlikely to > > > harm legit use cases though, and might catch some problematic > > > situations. I can drop this if that's the consensus however. > > > > I don't think I like it except in the case where there are no threads > > (number of tasks sharing the fd table is 1) and where the struct file > > only has one fd. Otherwise I think it can have false positives. Or > > am I missing something? > > > > The only case where I think this would hit a false positive is if you > have a threaded program that's doing something weird like having one > thread that's setting classic POSIX locks on a file, and one thread > that isn't. Once you hit a conflict between the two, you'd get back > EDEADLK on one of them, even though that situation might not actually > be a deadlock. > > That doesn't really seem like a real-world use-case though, so I'm > generally OK with that potential false-positive. Yes, you may be correct that those are almost certainly abuses of the interface, but I think Andy's point is that EDEADLK doesn't mean "you're doing something wrong", it has a stricter definition, and you're catching cases that are "false positives" in the sense that they don't necessarily identify actual deadlocks. --b. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:40 ` J. Bruce Fields @ 2014-03-04 20:44 ` Jeff Layton 0 siblings, 0 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 20:44 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Andy Lutomirski, Linux FS Devel On Tue, 4 Mar 2014 15:40:40 -0500 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 03:37:23PM -0500, Jeff Layton wrote: > > On Tue, 4 Mar 2014 12:19:44 -0800 > > Andy Lutomirski <luto@amacapital.net> wrote: > > > > > On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > > > > On Tue, 4 Mar 2014 14:35:51 -0500 > > > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > > > > > >> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > > > >> > My expectation is that programs shouldn't mix classic and file-private > > > >> > locks, but Glenn Skinner pointed out to me that that may occur at times > > > >> > even if the programmer isn't aware. > > > >> > > > > >> > Suppose we have a program that uses file-private locks. That program > > > >> > then links in a library that uses classic POSIX locks. If those locks > > > >> > end up conflicting and one is using blocking locks, then the program > > > >> > could end up deadlocked. > > > >> > > > > >> > Try to catch this situation in posix_locks_deadlock by looking for the > > > >> > case where the blocking lock was set by the same process but has a > > > >> > different type, and have the kernel return EDEADLK if that occurs. > > > >> > > > > >> > This check is not perfect. You could (in principle) have a threaded > > > >> > process that is using classic locks in one thread and file-private locks > > > >> > in another. That's not necessarily a deadlockable situation but this > > > >> > check would cause an EDEADLK return in that case. > > > >> > > > > >> > By the same token, you could also have a file-private lock that was > > > >> > inherited across a fork(). If the inheriting process ends up blocking on > > > >> > that while trying to set a classic POSIX lock then this check would miss > > > >> > it and the program would deadlock. > > > >> > > > >> If the caller's not prepared for the library to use classic posix locks, > > > >> then it's not going to know how to recover from this EDEADLCK either, is > > > >> it? > > > >> > > > > > > > > Well, callers should be aware of that if we take this change. The > > > > semantics aren't yet set in stone... > > > > > > > >> I guess I don't understand how this helps anyone. > > > >> > > > >> Has it ever made sense for a library function and its caller to both use > > > >> classic posix locking on the same file without any coordination? > > > >> > > > > > > > > Not really, but that doesn't mean that it isn't done... ;) > > > > > > > >> Besides the first-close problem there's the problem that locks merge, so > > > >> for example you can't hold your own lock across a call to a function > > > >> that grabs and drops a lock on the same file. > > > >> > > > > > > > > It depends, but you're basically correct... > > > > > > > > It's likely that if the above situation occurred with a program using > > > > classic locks, then those locks were silently lost at times. It's also > > > > plausible that when it occurs that no one is aware of it due to the way > > > > POSIX locks work. > > > > > > > > If the program switched to using file-private locks and the library > > > > stays using classic locks (or vice versa), you then potentially trade > > > > that silent loss of locks for a deadlock (since classic and > > > > file-private locks always conflict). > > > > > > > > So, the idea would be to try to catch that situation explicitly and > > > > return a hard error instead of deadlocking. Unfortunately, it's a > > > > little tough to do that in all cases so all this does is try to catch a > > > > subset of them. > > > > > > > > Will it be helpful in the long run? I'm not sure. It seems unlikely to > > > > harm legit use cases though, and might catch some problematic > > > > situations. I can drop this if that's the consensus however. > > > > > > I don't think I like it except in the case where there are no threads > > > (number of tasks sharing the fd table is 1) and where the struct file > > > only has one fd. Otherwise I think it can have false positives. Or > > > am I missing something? > > > > > > > The only case where I think this would hit a false positive is if you > > have a threaded program that's doing something weird like having one > > thread that's setting classic POSIX locks on a file, and one thread > > that isn't. Once you hit a conflict between the two, you'd get back > > EDEADLK on one of them, even though that situation might not actually > > be a deadlock. > > > > That doesn't really seem like a real-world use-case though, so I'm > > generally OK with that potential false-positive. > > Yes, you may be correct that those are almost certainly abuses of the > interface, but I think Andy's point is that EDEADLK doesn't mean "you're > doing something wrong", it has a stricter definition, and you're > catching cases that are "false positives" in the sense that they don't > necessarily identify actual deadlocks. > > --b. Fair enough -- you've convinced me. I'll plan to just drop this patch. Thanks! -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:37 ` Jeff Layton 2014-03-04 20:40 ` J. Bruce Fields @ 2014-03-04 20:52 ` Trond Myklebust 2014-03-04 21:14 ` Dr Fields James Bruce 2014-03-04 21:21 ` Jeff Layton 1 sibling, 2 replies; 18+ messages in thread From: Trond Myklebust @ 2014-03-04 20:52 UTC (permalink / raw) To: Layton Jeff; +Cc: Andy Lutomirski, Dr Fields James Bruce, Linux FS Devel On Mar 4, 2014, at 15:37, Jeff Layton <jlayton@redhat.com> wrote: > On Tue, 4 Mar 2014 12:19:44 -0800 > Andy Lutomirski <luto@amacapital.net> wrote: > >> On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: >>> On Tue, 4 Mar 2014 14:35:51 -0500 >>> "J. Bruce Fields" <bfields@fieldses.org> wrote: >>> >>>> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: >>>>> My expectation is that programs shouldn't mix classic and file-private >>>>> locks, but Glenn Skinner pointed out to me that that may occur at times >>>>> even if the programmer isn't aware. >>>>> >>>>> Suppose we have a program that uses file-private locks. That program >>>>> then links in a library that uses classic POSIX locks. If those locks >>>>> end up conflicting and one is using blocking locks, then the program >>>>> could end up deadlocked. >>>>> >>>>> Try to catch this situation in posix_locks_deadlock by looking for the >>>>> case where the blocking lock was set by the same process but has a >>>>> different type, and have the kernel return EDEADLK if that occurs. >>>>> >>>>> This check is not perfect. You could (in principle) have a threaded >>>>> process that is using classic locks in one thread and file-private locks >>>>> in another. That's not necessarily a deadlockable situation but this >>>>> check would cause an EDEADLK return in that case. >>>>> >>>>> By the same token, you could also have a file-private lock that was >>>>> inherited across a fork(). If the inheriting process ends up blocking on >>>>> that while trying to set a classic POSIX lock then this check would miss >>>>> it and the program would deadlock. >>>> >>>> If the caller's not prepared for the library to use classic posix locks, >>>> then it's not going to know how to recover from this EDEADLCK either, is >>>> it? >>>> >>> >>> Well, callers should be aware of that if we take this change. The >>> semantics aren't yet set in stone... >>> >>>> I guess I don't understand how this helps anyone. >>>> >>>> Has it ever made sense for a library function and its caller to both use >>>> classic posix locking on the same file without any coordination? >>>> >>> >>> Not really, but that doesn't mean that it isn't done... ;) >>> >>>> Besides the first-close problem there's the problem that locks merge, so >>>> for example you can't hold your own lock across a call to a function >>>> that grabs and drops a lock on the same file. >>>> >>> >>> It depends, but you're basically correct... >>> >>> It's likely that if the above situation occurred with a program using >>> classic locks, then those locks were silently lost at times. It's also >>> plausible that when it occurs that no one is aware of it due to the way >>> POSIX locks work. >>> >>> If the program switched to using file-private locks and the library >>> stays using classic locks (or vice versa), you then potentially trade >>> that silent loss of locks for a deadlock (since classic and >>> file-private locks always conflict). >>> >>> So, the idea would be to try to catch that situation explicitly and >>> return a hard error instead of deadlocking. Unfortunately, it's a >>> little tough to do that in all cases so all this does is try to catch a >>> subset of them. >>> >>> Will it be helpful in the long run? I'm not sure. It seems unlikely to >>> harm legit use cases though, and might catch some problematic >>> situations. I can drop this if that's the consensus however. >> >> I don't think I like it except in the case where there are no threads >> (number of tasks sharing the fd table is 1) and where the struct file >> only has one fd. Otherwise I think it can have false positives. Or >> am I missing something? >> > > The only case where I think this would hit a false positive is if you > have a threaded program that's doing something weird like having one > thread that's setting classic POSIX locks on a file, and one thread > that isn't. Once you hit a conflict between the two, you'd get back > EDEADLK on one of them, even though that situation might not actually > be a deadlock. > > That doesn't really seem like a real-world use-case though, so I'm > generally OK with that potential false-positive. > How do these locks interact with locks_mandatory_area(), and mandatory locking in general? Unless I missed something, it looks to me as if there is a nasty potential for a self-DOS if you set a file-private lock on a file with the mandatory lock bits set and the filesystem is mounted ‘-omand'. _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:52 ` Trond Myklebust @ 2014-03-04 21:14 ` Dr Fields James Bruce 2014-03-04 21:24 ` Jeff Layton 2014-03-04 22:42 ` Trond Myklebust 2014-03-04 21:21 ` Jeff Layton 1 sibling, 2 replies; 18+ messages in thread From: Dr Fields James Bruce @ 2014-03-04 21:14 UTC (permalink / raw) To: Trond Myklebust; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Tue, Mar 04, 2014 at 03:52:47PM -0500, Trond Myklebust wrote: > > On Mar 4, 2014, at 15:37, Jeff Layton <jlayton@redhat.com> wrote: > > > On Tue, 4 Mar 2014 12:19:44 -0800 > > Andy Lutomirski <luto@amacapital.net> wrote: > > > >> On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > >>> On Tue, 4 Mar 2014 14:35:51 -0500 > >>> "J. Bruce Fields" <bfields@fieldses.org> wrote: > >>> > >>>> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > >>>>> My expectation is that programs shouldn't mix classic and file-private > >>>>> locks, but Glenn Skinner pointed out to me that that may occur at times > >>>>> even if the programmer isn't aware. > >>>>> > >>>>> Suppose we have a program that uses file-private locks. That program > >>>>> then links in a library that uses classic POSIX locks. If those locks > >>>>> end up conflicting and one is using blocking locks, then the program > >>>>> could end up deadlocked. > >>>>> > >>>>> Try to catch this situation in posix_locks_deadlock by looking for the > >>>>> case where the blocking lock was set by the same process but has a > >>>>> different type, and have the kernel return EDEADLK if that occurs. > >>>>> > >>>>> This check is not perfect. You could (in principle) have a threaded > >>>>> process that is using classic locks in one thread and file-private locks > >>>>> in another. That's not necessarily a deadlockable situation but this > >>>>> check would cause an EDEADLK return in that case. > >>>>> > >>>>> By the same token, you could also have a file-private lock that was > >>>>> inherited across a fork(). If the inheriting process ends up blocking on > >>>>> that while trying to set a classic POSIX lock then this check would miss > >>>>> it and the program would deadlock. > >>>> > >>>> If the caller's not prepared for the library to use classic posix locks, > >>>> then it's not going to know how to recover from this EDEADLCK either, is > >>>> it? > >>>> > >>> > >>> Well, callers should be aware of that if we take this change. The > >>> semantics aren't yet set in stone... > >>> > >>>> I guess I don't understand how this helps anyone. > >>>> > >>>> Has it ever made sense for a library function and its caller to both use > >>>> classic posix locking on the same file without any coordination? > >>>> > >>> > >>> Not really, but that doesn't mean that it isn't done... ;) > >>> > >>>> Besides the first-close problem there's the problem that locks merge, so > >>>> for example you can't hold your own lock across a call to a function > >>>> that grabs and drops a lock on the same file. > >>>> > >>> > >>> It depends, but you're basically correct... > >>> > >>> It's likely that if the above situation occurred with a program using > >>> classic locks, then those locks were silently lost at times. It's also > >>> plausible that when it occurs that no one is aware of it due to the way > >>> POSIX locks work. > >>> > >>> If the program switched to using file-private locks and the library > >>> stays using classic locks (or vice versa), you then potentially trade > >>> that silent loss of locks for a deadlock (since classic and > >>> file-private locks always conflict). > >>> > >>> So, the idea would be to try to catch that situation explicitly and > >>> return a hard error instead of deadlocking. Unfortunately, it's a > >>> little tough to do that in all cases so all this does is try to catch a > >>> subset of them. > >>> > >>> Will it be helpful in the long run? I'm not sure. It seems unlikely to > >>> harm legit use cases though, and might catch some problematic > >>> situations. I can drop this if that's the consensus however. > >> > >> I don't think I like it except in the case where there are no threads > >> (number of tasks sharing the fd table is 1) and where the struct file > >> only has one fd. Otherwise I think it can have false positives. Or > >> am I missing something? > >> > > > > The only case where I think this would hit a false positive is if you > > have a threaded program that's doing something weird like having one > > thread that's setting classic POSIX locks on a file, and one thread > > that isn't. Once you hit a conflict between the two, you'd get back > > EDEADLK on one of them, even though that situation might not actually > > be a deadlock. > > > > That doesn't really seem like a real-world use-case though, so I'm > > generally OK with that potential false-positive. > > > > How do these locks interact with locks_mandatory_area(), and mandatory locking in general? Unless I missed something, it looks to me as if there is a nasty potential for a self-DOS if you set a file-private lock on a file with the mandatory lock bits set and the filesystem is mounted ‘-omand'. Good point: if I understand it right, in the mandatory locking case, before doing a read or write we first check if we'd be able to apply a classic posix lock. And that lock will always conflict with a file-private lock. I think we should just not worry about it and see if anyone complains. File-private locks are a new feature and I don't see that we're under any obligation to support the combination of file-private locks and mandatory locking. Mandatory locking is already buggy (because of the race between checking for locks and performing the IO). If we get no complaints about this file-private behavior then that's more evidence we could use to justify just ripping it out completely some day.... But if we really want to be helpful to (possibly nonexistant?) users of mandatory locking, maybe we could allow locks_mandatory_area to try *both* a file-private and a classic lock and to succeed if either one succeeds?? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 21:14 ` Dr Fields James Bruce @ 2014-03-04 21:24 ` Jeff Layton 2014-03-04 22:42 ` Trond Myklebust 1 sibling, 0 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 21:24 UTC (permalink / raw) To: Dr Fields James Bruce; +Cc: Trond Myklebust, Andy Lutomirski, Linux FS Devel On Tue, 4 Mar 2014 16:14:43 -0500 Dr Fields James Bruce <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 03:52:47PM -0500, Trond Myklebust wrote: > > > > On Mar 4, 2014, at 15:37, Jeff Layton <jlayton@redhat.com> wrote: > > > > > On Tue, 4 Mar 2014 12:19:44 -0800 > > > Andy Lutomirski <luto@amacapital.net> wrote: > > > > > >> On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > > >>> On Tue, 4 Mar 2014 14:35:51 -0500 > > >>> "J. Bruce Fields" <bfields@fieldses.org> wrote: > > >>> > > >>>> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > > >>>>> My expectation is that programs shouldn't mix classic and file-private > > >>>>> locks, but Glenn Skinner pointed out to me that that may occur at times > > >>>>> even if the programmer isn't aware. > > >>>>> > > >>>>> Suppose we have a program that uses file-private locks. That program > > >>>>> then links in a library that uses classic POSIX locks. If those locks > > >>>>> end up conflicting and one is using blocking locks, then the program > > >>>>> could end up deadlocked. > > >>>>> > > >>>>> Try to catch this situation in posix_locks_deadlock by looking for the > > >>>>> case where the blocking lock was set by the same process but has a > > >>>>> different type, and have the kernel return EDEADLK if that occurs. > > >>>>> > > >>>>> This check is not perfect. You could (in principle) have a threaded > > >>>>> process that is using classic locks in one thread and file-private locks > > >>>>> in another. That's not necessarily a deadlockable situation but this > > >>>>> check would cause an EDEADLK return in that case. > > >>>>> > > >>>>> By the same token, you could also have a file-private lock that was > > >>>>> inherited across a fork(). If the inheriting process ends up blocking on > > >>>>> that while trying to set a classic POSIX lock then this check would miss > > >>>>> it and the program would deadlock. > > >>>> > > >>>> If the caller's not prepared for the library to use classic posix locks, > > >>>> then it's not going to know how to recover from this EDEADLCK either, is > > >>>> it? > > >>>> > > >>> > > >>> Well, callers should be aware of that if we take this change. The > > >>> semantics aren't yet set in stone... > > >>> > > >>>> I guess I don't understand how this helps anyone. > > >>>> > > >>>> Has it ever made sense for a library function and its caller to both use > > >>>> classic posix locking on the same file without any coordination? > > >>>> > > >>> > > >>> Not really, but that doesn't mean that it isn't done... ;) > > >>> > > >>>> Besides the first-close problem there's the problem that locks merge, so > > >>>> for example you can't hold your own lock across a call to a function > > >>>> that grabs and drops a lock on the same file. > > >>>> > > >>> > > >>> It depends, but you're basically correct... > > >>> > > >>> It's likely that if the above situation occurred with a program using > > >>> classic locks, then those locks were silently lost at times. It's also > > >>> plausible that when it occurs that no one is aware of it due to the way > > >>> POSIX locks work. > > >>> > > >>> If the program switched to using file-private locks and the library > > >>> stays using classic locks (or vice versa), you then potentially trade > > >>> that silent loss of locks for a deadlock (since classic and > > >>> file-private locks always conflict). > > >>> > > >>> So, the idea would be to try to catch that situation explicitly and > > >>> return a hard error instead of deadlocking. Unfortunately, it's a > > >>> little tough to do that in all cases so all this does is try to catch a > > >>> subset of them. > > >>> > > >>> Will it be helpful in the long run? I'm not sure. It seems unlikely to > > >>> harm legit use cases though, and might catch some problematic > > >>> situations. I can drop this if that's the consensus however. > > >> > > >> I don't think I like it except in the case where there are no threads > > >> (number of tasks sharing the fd table is 1) and where the struct file > > >> only has one fd. Otherwise I think it can have false positives. Or > > >> am I missing something? > > >> > > > > > > The only case where I think this would hit a false positive is if you > > > have a threaded program that's doing something weird like having one > > > thread that's setting classic POSIX locks on a file, and one thread > > > that isn't. Once you hit a conflict between the two, you'd get back > > > EDEADLK on one of them, even though that situation might not actually > > > be a deadlock. > > > > > > That doesn't really seem like a real-world use-case though, so I'm > > > generally OK with that potential false-positive. > > > > > > > How do these locks interact with locks_mandatory_area(), and mandatory locking in general? Unless I missed something, it looks to me as if there is a nasty potential for a self-DOS if you set a file-private lock on a file with the mandatory lock bits set and the filesystem is mounted ‘-omand'. > > Good point: if I understand it right, in the mandatory locking case, > before doing a read or write we first check if we'd be able to apply a > classic posix lock. And that lock will always conflict with a > file-private lock. > > I think we should just not worry about it and see if anyone complains. > File-private locks are a new feature and I don't see that we're under > any obligation to support the combination of file-private locks and > mandatory locking. > > Mandatory locking is already buggy (because of the race between checking > for locks and performing the IO). If we get no complaints about this > file-private behavior then that's more evidence we could use to justify > just ripping it out completely some day.... > > But if we really want to be helpful to (possibly nonexistant?) users of > mandatory locking, maybe we could allow locks_mandatory_area to try > *both* a file-private and a classic lock and to succeed if either one > succeeds?? > Yeah, I think that's what we'll have to do. In principle it shouldn't be too hard to do, but I'll have look at the most efficient way to handle it. -- Jeff Layton <jlayton@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 21:14 ` Dr Fields James Bruce 2014-03-04 21:24 ` Jeff Layton @ 2014-03-04 22:42 ` Trond Myklebust 2014-03-04 22:56 ` Dr Fields James Bruce 1 sibling, 1 reply; 18+ messages in thread From: Trond Myklebust @ 2014-03-04 22:42 UTC (permalink / raw) To: Dr Fields James Bruce; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 03:52:47PM -0500, Trond Myklebust wrote: >> >> On Mar 4, 2014, at 15:37, Jeff Layton <jlayton@redhat.com> wrote: >> >>> On Tue, 4 Mar 2014 12:19:44 -0800 >>> Andy Lutomirski <luto@amacapital.net> wrote: >>> >>>> On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: >>>>> On Tue, 4 Mar 2014 14:35:51 -0500 >>>>> "J. Bruce Fields" <bfields@fieldses.org> wrote: >>>>> >>>>>> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: >>>>>>> My expectation is that programs shouldn't mix classic and file-private >>>>>>> locks, but Glenn Skinner pointed out to me that that may occur at times >>>>>>> even if the programmer isn't aware. >>>>>>> >>>>>>> Suppose we have a program that uses file-private locks. That program >>>>>>> then links in a library that uses classic POSIX locks. If those locks >>>>>>> end up conflicting and one is using blocking locks, then the program >>>>>>> could end up deadlocked. >>>>>>> >>>>>>> Try to catch this situation in posix_locks_deadlock by looking for the >>>>>>> case where the blocking lock was set by the same process but has a >>>>>>> different type, and have the kernel return EDEADLK if that occurs. >>>>>>> >>>>>>> This check is not perfect. You could (in principle) have a threaded >>>>>>> process that is using classic locks in one thread and file-private locks >>>>>>> in another. That's not necessarily a deadlockable situation but this >>>>>>> check would cause an EDEADLK return in that case. >>>>>>> >>>>>>> By the same token, you could also have a file-private lock that was >>>>>>> inherited across a fork(). If the inheriting process ends up blocking on >>>>>>> that while trying to set a classic POSIX lock then this check would miss >>>>>>> it and the program would deadlock. >>>>>> >>>>>> If the caller's not prepared for the library to use classic posix locks, >>>>>> then it's not going to know how to recover from this EDEADLCK either, is >>>>>> it? >>>>>> >>>>> >>>>> Well, callers should be aware of that if we take this change. The >>>>> semantics aren't yet set in stone... >>>>> >>>>>> I guess I don't understand how this helps anyone. >>>>>> >>>>>> Has it ever made sense for a library function and its caller to both use >>>>>> classic posix locking on the same file without any coordination? >>>>>> >>>>> >>>>> Not really, but that doesn't mean that it isn't done... ;) >>>>> >>>>>> Besides the first-close problem there's the problem that locks merge, so >>>>>> for example you can't hold your own lock across a call to a function >>>>>> that grabs and drops a lock on the same file. >>>>>> >>>>> >>>>> It depends, but you're basically correct... >>>>> >>>>> It's likely that if the above situation occurred with a program using >>>>> classic locks, then those locks were silently lost at times. It's also >>>>> plausible that when it occurs that no one is aware of it due to the way >>>>> POSIX locks work. >>>>> >>>>> If the program switched to using file-private locks and the library >>>>> stays using classic locks (or vice versa), you then potentially trade >>>>> that silent loss of locks for a deadlock (since classic and >>>>> file-private locks always conflict). >>>>> >>>>> So, the idea would be to try to catch that situation explicitly and >>>>> return a hard error instead of deadlocking. Unfortunately, it's a >>>>> little tough to do that in all cases so all this does is try to catch a >>>>> subset of them. >>>>> >>>>> Will it be helpful in the long run? I'm not sure. It seems unlikely to >>>>> harm legit use cases though, and might catch some problematic >>>>> situations. I can drop this if that's the consensus however. >>>> >>>> I don't think I like it except in the case where there are no threads >>>> (number of tasks sharing the fd table is 1) and where the struct file >>>> only has one fd. Otherwise I think it can have false positives. Or >>>> am I missing something? >>>> >>> >>> The only case where I think this would hit a false positive is if you >>> have a threaded program that's doing something weird like having one >>> thread that's setting classic POSIX locks on a file, and one thread >>> that isn't. Once you hit a conflict between the two, you'd get back >>> EDEADLK on one of them, even though that situation might not actually >>> be a deadlock. >>> >>> That doesn't really seem like a real-world use-case though, so I'm >>> generally OK with that potential false-positive. >>> >> >> How do these locks interact with locks_mandatory_area(), and mandatory locking in general? Unless I missed something, it looks to me as if there is a nasty potential for a self-DOS if you set a file-private lock on a file with the mandatory lock bits set and the filesystem is mounted ‘-omand'. > > Good point: if I understand it right, in the mandatory locking case, > before doing a read or write we first check if we'd be able to apply a > classic posix lock. And that lock will always conflict with a > file-private lock. > > I think we should just not worry about it and see if anyone complains. > File-private locks are a new feature and I don't see that we're under > any obligation to support the combination of file-private locks and > mandatory locking. > > Mandatory locking is already buggy (because of the race between checking > for locks and performing the IO). If we get no complaints about this > file-private behavior then that's more evidence we could use to justify > just ripping it out completely some day.... > > But if we really want to be helpful to (possibly nonexistant?) users of > mandatory locking, maybe we could allow locks_mandatory_area to try > *both* a file-private and a classic lock and to succeed if either one > succeeds?? The problem is that mandatory locking is something the administrator and user enable. It isn’t entirely under the control of the application… If you write a program that uses file-private locks, I can trivially DOS it by manipulating the mount parameters and manipulating the file's group execute and sgid bit. _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 22:42 ` Trond Myklebust @ 2014-03-04 22:56 ` Dr Fields James Bruce 2014-03-04 23:50 ` Trond Myklebust 0 siblings, 1 reply; 18+ messages in thread From: Dr Fields James Bruce @ 2014-03-04 22:56 UTC (permalink / raw) To: Trond Myklebust; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: > On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@fieldses.org> > wrote: > > Good point: if I understand it right, in the mandatory locking case, > > before doing a read or write we first check if we'd be able to apply > > a classic posix lock. And that lock will always conflict with a > > file-private lock. > > > > I think we should just not worry about it and see if anyone > > complains. File-private locks are a new feature and I don't see > > that we're under any obligation to support the combination of > > file-private locks and mandatory locking. > > > > Mandatory locking is already buggy (because of the race between > > checking for locks and performing the IO). If we get no complaints > > about this file-private behavior then that's more evidence we could > > use to justify just ripping it out completely some day.... ... > The problem is that mandatory locking is something the administrator > and user enable. It isn’t entirely under the control of the > application… If you write a program that uses file-private locks, I > can trivially DOS it by manipulating the mount parameters and > manipulating the file's group execute and sgid bit. Or you could take a lock on the file and DOS it in the same way. Why isn't the answer "don't do that"? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 22:56 ` Dr Fields James Bruce @ 2014-03-04 23:50 ` Trond Myklebust 2014-03-06 18:41 ` Dr Fields James Bruce 0 siblings, 1 reply; 18+ messages in thread From: Trond Myklebust @ 2014-03-04 23:50 UTC (permalink / raw) To: Dr Fields James Bruce; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: >> On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@fieldses.org> >> wrote: >>> Good point: if I understand it right, in the mandatory locking case, >>> before doing a read or write we first check if we'd be able to apply >>> a classic posix lock. And that lock will always conflict with a >>> file-private lock. >>> >>> I think we should just not worry about it and see if anyone >>> complains. File-private locks are a new feature and I don't see >>> that we're under any obligation to support the combination of >>> file-private locks and mandatory locking. >>> >>> Mandatory locking is already buggy (because of the race between >>> checking for locks and performing the IO). If we get no complaints >>> about this file-private behavior then that's more evidence we could >>> use to justify just ripping it out completely some day.... > ... >> The problem is that mandatory locking is something the administrator >> and user enable. It isn’t entirely under the control of the >> application… If you write a program that uses file-private locks, I >> can trivially DOS it by manipulating the mount parameters and >> manipulating the file's group execute and sgid bit. > > Or you could take a lock on the file and DOS it in the same way. > > Why isn't the answer "don't do that”? …because as a rule, it is bloody non-obvious and neither you nor Jeff had thought of it? _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 23:50 ` Trond Myklebust @ 2014-03-06 18:41 ` Dr Fields James Bruce 2014-03-06 18:58 ` Trond Myklebust 0 siblings, 1 reply; 18+ messages in thread From: Dr Fields James Bruce @ 2014-03-06 18:41 UTC (permalink / raw) To: Trond Myklebust; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Tue, Mar 04, 2014 at 06:50:10PM -0500, Trond Myklebust wrote: > > On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@fieldses.org> wrote: > > > On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: > >> On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@fieldses.org> > >> wrote: > >>> Good point: if I understand it right, in the mandatory locking case, > >>> before doing a read or write we first check if we'd be able to apply > >>> a classic posix lock. And that lock will always conflict with a > >>> file-private lock. > >>> > >>> I think we should just not worry about it and see if anyone > >>> complains. File-private locks are a new feature and I don't see > >>> that we're under any obligation to support the combination of > >>> file-private locks and mandatory locking. > >>> > >>> Mandatory locking is already buggy (because of the race between > >>> checking for locks and performing the IO). If we get no complaints > >>> about this file-private behavior then that's more evidence we could > >>> use to justify just ripping it out completely some day.... > > ... > >> The problem is that mandatory locking is something the administrator > >> and user enable. It isn’t entirely under the control of the > >> application… If you write a program that uses file-private locks, I > >> can trivially DOS it by manipulating the mount parameters and > >> manipulating the file's group execute and sgid bit. > > > > Or you could take a lock on the file and DOS it in the same way. > > > > Why isn't the answer "don't do that”? > > …because as a rule, it is bloody non-obvious and neither you nor Jeff had > thought of it? Agreed that it certainly violates the principal of least surprise. I just don't think that maintaining Linux's mandatory locking is worth any unnecessary effort. Nobody should be using it anyway as far as I can tell. But, fair enough, I don't feel terrifically strong about this, and it's probably not too hard to fix. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-06 18:41 ` Dr Fields James Bruce @ 2014-03-06 18:58 ` Trond Myklebust 0 siblings, 0 replies; 18+ messages in thread From: Trond Myklebust @ 2014-03-06 18:58 UTC (permalink / raw) To: Dr Fields James Bruce; +Cc: Layton Jeff, Andy Lutomirski, Linux FS Devel On Mar 6, 2014, at 13:41, Dr Fields James Bruce <bfields@fieldses.org> wrote: > On Tue, Mar 04, 2014 at 06:50:10PM -0500, Trond Myklebust wrote: >> >> On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@fieldses.org> wrote: >> >>> On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: >>>> On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@fieldses.org> >>>> wrote: >>>>> Good point: if I understand it right, in the mandatory locking case, >>>>> before doing a read or write we first check if we'd be able to apply >>>>> a classic posix lock. And that lock will always conflict with a >>>>> file-private lock. >>>>> >>>>> I think we should just not worry about it and see if anyone >>>>> complains. File-private locks are a new feature and I don't see >>>>> that we're under any obligation to support the combination of >>>>> file-private locks and mandatory locking. >>>>> >>>>> Mandatory locking is already buggy (because of the race between >>>>> checking for locks and performing the IO). If we get no complaints >>>>> about this file-private behavior then that's more evidence we could >>>>> use to justify just ripping it out completely some day.... >>> ... >>>> The problem is that mandatory locking is something the administrator >>>> and user enable. It isn’t entirely under the control of the >>>> application… If you write a program that uses file-private locks, I >>>> can trivially DOS it by manipulating the mount parameters and >>>> manipulating the file's group execute and sgid bit. >>> >>> Or you could take a lock on the file and DOS it in the same way. >>> >>> Why isn't the answer "don't do that”? >> >> …because as a rule, it is bloody non-obvious and neither you nor Jeff had >> thought of it? > > Agreed that it certainly violates the principal of least surprise. > > I just don't think that maintaining Linux's mandatory locking is worth > any unnecessary effort. Nobody should be using it anyway as far as I > can tell. If you can convince Linus to take a patch that disables the ‘-omand’ mount option, then that’s fine too, however leaving a known implementation bug is not... _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:52 ` Trond Myklebust 2014-03-04 21:14 ` Dr Fields James Bruce @ 2014-03-04 21:21 ` Jeff Layton 1 sibling, 0 replies; 18+ messages in thread From: Jeff Layton @ 2014-03-04 21:21 UTC (permalink / raw) To: Trond Myklebust; +Cc: Andy Lutomirski, Dr Fields James Bruce, Linux FS Devel On Tue, 4 Mar 2014 15:52:47 -0500 Trond Myklebust <trond.myklebust@primarydata.com> wrote: > > On Mar 4, 2014, at 15:37, Jeff Layton <jlayton@redhat.com> wrote: > > > On Tue, 4 Mar 2014 12:19:44 -0800 > > Andy Lutomirski <luto@amacapital.net> wrote: > > > >> On Tue, Mar 4, 2014 at 12:14 PM, Jeff Layton <jlayton@redhat.com> wrote: > >>> On Tue, 4 Mar 2014 14:35:51 -0500 > >>> "J. Bruce Fields" <bfields@fieldses.org> wrote: > >>> > >>>> On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > >>>>> My expectation is that programs shouldn't mix classic and file-private > >>>>> locks, but Glenn Skinner pointed out to me that that may occur at times > >>>>> even if the programmer isn't aware. > >>>>> > >>>>> Suppose we have a program that uses file-private locks. That program > >>>>> then links in a library that uses classic POSIX locks. If those locks > >>>>> end up conflicting and one is using blocking locks, then the program > >>>>> could end up deadlocked. > >>>>> > >>>>> Try to catch this situation in posix_locks_deadlock by looking for the > >>>>> case where the blocking lock was set by the same process but has a > >>>>> different type, and have the kernel return EDEADLK if that occurs. > >>>>> > >>>>> This check is not perfect. You could (in principle) have a threaded > >>>>> process that is using classic locks in one thread and file-private locks > >>>>> in another. That's not necessarily a deadlockable situation but this > >>>>> check would cause an EDEADLK return in that case. > >>>>> > >>>>> By the same token, you could also have a file-private lock that was > >>>>> inherited across a fork(). If the inheriting process ends up blocking on > >>>>> that while trying to set a classic POSIX lock then this check would miss > >>>>> it and the program would deadlock. > >>>> > >>>> If the caller's not prepared for the library to use classic posix locks, > >>>> then it's not going to know how to recover from this EDEADLCK either, is > >>>> it? > >>>> > >>> > >>> Well, callers should be aware of that if we take this change. The > >>> semantics aren't yet set in stone... > >>> > >>>> I guess I don't understand how this helps anyone. > >>>> > >>>> Has it ever made sense for a library function and its caller to both use > >>>> classic posix locking on the same file without any coordination? > >>>> > >>> > >>> Not really, but that doesn't mean that it isn't done... ;) > >>> > >>>> Besides the first-close problem there's the problem that locks merge, so > >>>> for example you can't hold your own lock across a call to a function > >>>> that grabs and drops a lock on the same file. > >>>> > >>> > >>> It depends, but you're basically correct... > >>> > >>> It's likely that if the above situation occurred with a program using > >>> classic locks, then those locks were silently lost at times. It's also > >>> plausible that when it occurs that no one is aware of it due to the way > >>> POSIX locks work. > >>> > >>> If the program switched to using file-private locks and the library > >>> stays using classic locks (or vice versa), you then potentially trade > >>> that silent loss of locks for a deadlock (since classic and > >>> file-private locks always conflict). > >>> > >>> So, the idea would be to try to catch that situation explicitly and > >>> return a hard error instead of deadlocking. Unfortunately, it's a > >>> little tough to do that in all cases so all this does is try to catch a > >>> subset of them. > >>> > >>> Will it be helpful in the long run? I'm not sure. It seems unlikely to > >>> harm legit use cases though, and might catch some problematic > >>> situations. I can drop this if that's the consensus however. > >> > >> I don't think I like it except in the case where there are no threads > >> (number of tasks sharing the fd table is 1) and where the struct file > >> only has one fd. Otherwise I think it can have false positives. Or > >> am I missing something? > >> > > > > The only case where I think this would hit a false positive is if you > > have a threaded program that's doing something weird like having one > > thread that's setting classic POSIX locks on a file, and one thread > > that isn't. Once you hit a conflict between the two, you'd get back > > EDEADLK on one of them, even though that situation might not actually > > be a deadlock. > > > > That doesn't really seem like a real-world use-case though, so I'm > > generally OK with that potential false-positive. > > > > How do these locks interact with locks_mandatory_area(), and mandatory locking in general? Unless I missed something, it looks to me as if there is a nasty potential for a self-DOS if you set a file-private lock on a file with the mandatory lock bits set and the filesystem is mounted ‘-omand'. > Good catch. I hadn't considered that case properly... Looks like I'll have to fix up locks_mandatory_area() to handle the file-private case. The fact that we'll now have to check for two different lock types makes that a bit more convoluted, but I'll see what can be done. Thanks, -- Jeff Layton <jlayton@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process 2014-03-04 20:14 ` Jeff Layton 2014-03-04 20:19 ` Andy Lutomirski @ 2014-03-04 20:35 ` J. Bruce Fields 1 sibling, 0 replies; 18+ messages in thread From: J. Bruce Fields @ 2014-03-04 20:35 UTC (permalink / raw) To: Jeff Layton; +Cc: linux-fsdevel, luto On Tue, Mar 04, 2014 at 03:14:51PM -0500, Jeff Layton wrote: > On Tue, 4 Mar 2014 14:35:51 -0500 > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > On Tue, Mar 04, 2014 at 02:10:49PM -0500, Jeff Layton wrote: > > > My expectation is that programs shouldn't mix classic and file-private > > > locks, but Glenn Skinner pointed out to me that that may occur at times > > > even if the programmer isn't aware. > > > > > > Suppose we have a program that uses file-private locks. That program > > > then links in a library that uses classic POSIX locks. If those locks > > > end up conflicting and one is using blocking locks, then the program > > > could end up deadlocked. > > > > > > Try to catch this situation in posix_locks_deadlock by looking for the > > > case where the blocking lock was set by the same process but has a > > > different type, and have the kernel return EDEADLK if that occurs. > > > > > > This check is not perfect. You could (in principle) have a threaded > > > process that is using classic locks in one thread and file-private locks > > > in another. That's not necessarily a deadlockable situation but this > > > check would cause an EDEADLK return in that case. > > > > > > By the same token, you could also have a file-private lock that was > > > inherited across a fork(). If the inheriting process ends up blocking on > > > that while trying to set a classic POSIX lock then this check would miss > > > it and the program would deadlock. > > > > If the caller's not prepared for the library to use classic posix locks, > > then it's not going to know how to recover from this EDEADLCK either, is > > it? > > > > Well, callers should be aware of that if we take this change. The > semantics aren't yet set in stone... > > > I guess I don't understand how this helps anyone. > > > > Has it ever made sense for a library function and its caller to both use > > classic posix locking on the same file without any coordination? > > > > Not really, but that doesn't mean that it isn't done... ;) > > > Besides the first-close problem there's the problem that locks merge, so > > for example you can't hold your own lock across a call to a function > > that grabs and drops a lock on the same file. > > > > It depends, but you're basically correct... > > It's likely that if the above situation occurred with a program using > classic locks, then those locks were silently lost at times. It's also > plausible that when it occurs that no one is aware of it due to the way > POSIX locks work. > > If the program switched to using file-private locks and the library > stays using classic locks (or vice versa), you then potentially trade > that silent loss of locks for a deadlock (since classic and > file-private locks always conflict). > > So, the idea would be to try to catch that situation explicitly and > return a hard error instead of deadlocking. Unfortunately, it's a > little tough to do that in all cases so all this does is try to catch a > subset of them. > > Will it be helpful in the long run? I'm not sure. It seems unlikely to > harm legit use cases though, and might catch some problematic > situations. I can drop this if that's the consensus however. As a way to tell you your program is using the interface in a fundamentally buggy way, maybe hanging isn't even any worse than returning an error. I'd rather stick with the simpler-to-document behavior ("file-private & classic locks always conflict") absent a stronger argument to the contrary. --b. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-03-06 18:58 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-04 19:10 [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process Jeff Layton 2014-03-04 19:19 ` Andy Lutomirski 2014-03-04 19:35 ` J. Bruce Fields 2014-03-04 20:14 ` Jeff Layton 2014-03-04 20:19 ` Andy Lutomirski 2014-03-04 20:37 ` Jeff Layton 2014-03-04 20:40 ` J. Bruce Fields 2014-03-04 20:44 ` Jeff Layton 2014-03-04 20:52 ` Trond Myklebust 2014-03-04 21:14 ` Dr Fields James Bruce 2014-03-04 21:24 ` Jeff Layton 2014-03-04 22:42 ` Trond Myklebust 2014-03-04 22:56 ` Dr Fields James Bruce 2014-03-04 23:50 ` Trond Myklebust 2014-03-06 18:41 ` Dr Fields James Bruce 2014-03-06 18:58 ` Trond Myklebust 2014-03-04 21:21 ` Jeff Layton 2014-03-04 20:35 ` J. Bruce Fields
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).