All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: file locking fix for 3.2
Date: Sat, 24 Dec 2011 18:50:35 -0500	[thread overview]
Message-ID: <20111224235035.GA23711@fieldses.org> (raw)
In-Reply-To: <20111224225525.GR23916@ZenIV.linux.org.uk>

On Sat, Dec 24, 2011 at 10:55:25PM +0000, Al Viro wrote:
> On Sat, Dec 24, 2011 at 04:50:12PM -0500, J. Bruce Fields wrote:
> 
> >     locks: fix null dereference on lease-break failure path
> >     
> >     Commit 778fc546f749c588aa2f6cd50215d2715c374252 "locks: fix tracking of
> >     inprogress lease breaks" introduced a null dereference on failure to
> >     allocate memory.
> >     
> >     This means an open (without O_NONBLOCK set) on a file with a lease
> >     applied (generally only done when Samba or nfsd (with v4) is running)
> >     could crash if a kmalloc() fails.
> 
> NULL?  AFAICS, lease_alloc() returns ERR_PTR() on failure...

Erp, you're right.

(The fix is still right, it's the changelog that's wrong; happy to
fix and resend if it's wanted....)

> I really
> don't like the look of that code, TBH - at the very least it needs to
> be commented a lot.  E.g. the rules for calling or not calling ->lm_break()
> are really not obvious - AFAICS, we do that if
> 	i_have_this_lease || (mode & O_NONBLOCK)
> is true *or* if allocation has succeeded.  The former condition is what'll
> end up with -EWOULDBLOCK; I can understand not wanting to return that in
> preference to -ENOMEM, but...  Do we want to skip ->lm_break() stuff only
> in case of allocation failures that won't be overridden by -EWOULDBLOCK?

We do want to break leases at least in the O_NONBLOCK case so that a
caller can make forward progress by retrying open(.,O_NONBLOCK).

In the other cases I don't think there's any logic to the current
behavior.  Something like:

-	if (IS_ERR(new_fl) && !i_have_this_lease
-			&& ((mode & O_NONBLOCK) == 0)) {
-		error = PTR_ERR(new_fl);
-		goto out;
-	}
-
...
 		error = -EWOULDBLOCK;
 		goto out;
 	}
-
+	if (IS_ERR(new_fl)) {
+		error = PTR_ERR(new_fl);
+		goto out;
+	}
 restart:
 	break_time = flock->fl_break_time;
 	if (break_time != 0) {

would be a little less convoluted.

Or we could just do it the really obvious way:

 	new_fl = lease_alloc(NULL, want_write ? F_WRLCK : F_RDLCK);
+	if (IS_ERR(new_fl))
+		return PTR_ERR(new_fl);
 
 	lock_flocks();
... 
-	if (IS_ERR(new_fl) && !i_have_this_lease
-			&& ((mode & O_NONBLOCK) == 0)) {
-		error = PTR_ERR(new_fl);
-		goto out;
-	}
-

Then you're returning -ENOMEM in a case when we really didn't need to do
an allocation, but is that really a problem?  It's a rare case, and
opens can already fail with -ENOMEM for other reasons, and I'd rather
not have the extra hair.

?

--b.

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Cc: Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: file locking fix for 3.2
Date: Sat, 24 Dec 2011 18:50:35 -0500	[thread overview]
Message-ID: <20111224235035.GA23711@fieldses.org> (raw)
In-Reply-To: <20111224225525.GR23916-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>

On Sat, Dec 24, 2011 at 10:55:25PM +0000, Al Viro wrote:
> On Sat, Dec 24, 2011 at 04:50:12PM -0500, J. Bruce Fields wrote:
> 
> >     locks: fix null dereference on lease-break failure path
> >     
> >     Commit 778fc546f749c588aa2f6cd50215d2715c374252 "locks: fix tracking of
> >     inprogress lease breaks" introduced a null dereference on failure to
> >     allocate memory.
> >     
> >     This means an open (without O_NONBLOCK set) on a file with a lease
> >     applied (generally only done when Samba or nfsd (with v4) is running)
> >     could crash if a kmalloc() fails.
> 
> NULL?  AFAICS, lease_alloc() returns ERR_PTR() on failure...

Erp, you're right.

(The fix is still right, it's the changelog that's wrong; happy to
fix and resend if it's wanted....)

> I really
> don't like the look of that code, TBH - at the very least it needs to
> be commented a lot.  E.g. the rules for calling or not calling ->lm_break()
> are really not obvious - AFAICS, we do that if
> 	i_have_this_lease || (mode & O_NONBLOCK)
> is true *or* if allocation has succeeded.  The former condition is what'll
> end up with -EWOULDBLOCK; I can understand not wanting to return that in
> preference to -ENOMEM, but...  Do we want to skip ->lm_break() stuff only
> in case of allocation failures that won't be overridden by -EWOULDBLOCK?

We do want to break leases at least in the O_NONBLOCK case so that a
caller can make forward progress by retrying open(.,O_NONBLOCK).

In the other cases I don't think there's any logic to the current
behavior.  Something like:

-	if (IS_ERR(new_fl) && !i_have_this_lease
-			&& ((mode & O_NONBLOCK) == 0)) {
-		error = PTR_ERR(new_fl);
-		goto out;
-	}
-
...
 		error = -EWOULDBLOCK;
 		goto out;
 	}
-
+	if (IS_ERR(new_fl)) {
+		error = PTR_ERR(new_fl);
+		goto out;
+	}
 restart:
 	break_time = flock->fl_break_time;
 	if (break_time != 0) {

would be a little less convoluted.

Or we could just do it the really obvious way:

 	new_fl = lease_alloc(NULL, want_write ? F_WRLCK : F_RDLCK);
+	if (IS_ERR(new_fl))
+		return PTR_ERR(new_fl);
 
 	lock_flocks();
... 
-	if (IS_ERR(new_fl) && !i_have_this_lease
-			&& ((mode & O_NONBLOCK) == 0)) {
-		error = PTR_ERR(new_fl);
-		goto out;
-	}
-

Then you're returning -ENOMEM in a case when we really didn't need to do
an allocation, but is that really a problem?  It's a rare case, and
opens can already fail with -ENOMEM for other reasons, and I'd rather
not have the extra hair.

?

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-12-24 23:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-24 21:50 file locking fix for 3.2 J. Bruce Fields
2011-12-24 22:55 ` Al Viro
2011-12-24 23:50   ` J. Bruce Fields [this message]
2011-12-24 23:50     ` J. Bruce Fields
2011-12-25  0:05     ` Al Viro
2011-12-25 18:19       ` J. Bruce Fields
2011-12-26 18:37         ` Linus Torvalds
2011-12-26 20:18           ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111224235035.GA23711@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.