Thread (59 messages) 59 messages, 7 authors, 2012-04-20

Re: [ 10/41] CIFS: Do not kmalloc under the flocks spinlock

From: Ben Hutchings <hidden>
Date: 2012-03-17 02:37:51
Also in: lkml

On Fri, Mar 16, 2012 at 04:38:20PM -0700, Greg KH wrote:
quoted hunk ↗ jump to hunk
3.2-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Pavel Shilovsky <redacted>

commit d5751469f210d2149cc2159ffff66cbeef6da3f2 upstream.

Reorganize the code to make the memory already allocated before
spinlock'ed loop.

Reviewed-by: Jeff Layton <redacted>
Signed-off-by: Pavel Shilovsky <redacted>
Signed-off-by: Steve French <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/cifs/file.c |   69 ++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 56 insertions(+), 13 deletions(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
[....]
quoted hunk ↗ jump to hunk
@@ -940,29 +950,55 @@ cifs_push_posix_locks(struct cifsFileInf
 		return rc;
 	}
 
+	lock_flocks();
+	cifs_for_each_lock(cfile->dentry->d_inode, before) {
+		if ((*before)->fl_flags & FL_POSIX)
+			count++;
+	}
+	unlock_flocks();
+
 	INIT_LIST_HEAD(&locks_to_send);
 
+	/*
+	 * Allocating count locks is enough because no locks can be added to
+	 * the list while we are holding cinode->lock_mutex that protects
+	 * locking operations of this inode.
+	 */
+	for (; i < count; i++) {
+		lck = kmalloc(sizeof(struct lock_to_push), GFP_KERNEL);
+		if (!lck) {
+			rc = -ENOMEM;
+			goto err_out;
+		}
+		list_add_tail(&lck->llist, &locks_to_send);
+	}
+
+	i = 0;
+	el = locks_to_send.next;
 	lock_flocks();
 	cifs_for_each_lock(cfile->dentry->d_inode, before) {
+		if (el == &locks_to_send) {
+			/* something is really wrong */
+			cERROR(1, "Can't push all brlocks!");
+			break;
+		}
 		flock = *before;
+		if ((flock->fl_flags & FL_POSIX) == 0)
+			continue;
[...]

If I understand the logic correctly, el == &locks_to_send means we
already used all the lock_to_push structures.  (It should also be
equivalent to testing i == count.  Why is i incremented but not
otherwise used in the loop?)

But we test this before flock->fl_flags & FL_POSIX, which means we
don't know whether this lock actually needs to be assigned one of
those structures.  So it appears that we might report a spurious error
if the lock list ends with a mandatory lock.  If so, this is
relatively harmless but does need to be fixed.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help