<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs, branch linux-2.6.32.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ocfs2/dlm: ignore cleaning the migration mle that is inuse</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>xuejiufei</name>
<email>xuejiufei@huawei.com</email>
</author>
<published>2016-01-14T23:17:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=276533d5acbfde1ed13cbc4ddf6ff22ce32d0a75'/>
<id>276533d5acbfde1ed13cbc4ddf6ff22ce32d0a75</id>
<content type='text'>
commit bef5502de074b6f6fa647b94b73155d675694420 upstream.

We have found that migration source will trigger a BUG that the refcount
of mle is already zero before put when the target is down during
migration.  The situation is as follows:

dlm_migrate_lockres
  dlm_add_migration_mle
  dlm_mark_lockres_migrating
  dlm_get_mle_inuse
  &lt;&lt;&lt;&lt;&lt;&lt; Now the refcount of the mle is 2.
  dlm_send_one_lockres and wait for the target to become the
  new master.
  &lt;&lt;&lt;&lt;&lt;&lt; o2hb detect the target down and clean the migration
  mle. Now the refcount is 1.

dlm_migrate_lockres woken, and put the mle twice when found the target
goes down which trigger the BUG with the following message:

  "ERROR: bad mle: ".

Signed-off-by: Jiufei Xue &lt;xuejiufei@huawei.com&gt;
Reviewed-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.de&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bef5502de074b6f6fa647b94b73155d675694420 upstream.

We have found that migration source will trigger a BUG that the refcount
of mle is already zero before put when the target is down during
migration.  The situation is as follows:

dlm_migrate_lockres
  dlm_add_migration_mle
  dlm_mark_lockres_migrating
  dlm_get_mle_inuse
  &lt;&lt;&lt;&lt;&lt;&lt; Now the refcount of the mle is 2.
  dlm_send_one_lockres and wait for the target to become the
  new master.
  &lt;&lt;&lt;&lt;&lt;&lt; o2hb detect the target down and clean the migration
  mle. Now the refcount is 1.

dlm_migrate_lockres woken, and put the mle twice when found the target
goes down which trigger the BUG with the following message:

  "ERROR: bad mle: ".

Signed-off-by: Jiufei Xue &lt;xuejiufei@huawei.com&gt;
Reviewed-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.de&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Check output buffer length when converting name to CS0</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2015-12-24T16:25:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1005e5f1cfedbec13c5a376416a43891601746b'/>
<id>f1005e5f1cfedbec13c5a376416a43891601746b</id>
<content type='text'>
commit bb00c898ad1ce40c4bb422a8207ae562e9aea7ae upstream.

If a name contains at least some characters with Unicode values
exceeding single byte, the CS0 output should have 2 bytes per character.
And if other input characters have single byte Unicode values, then
the single input byte is converted to 2 output bytes, and the length
of output becomes larger than the length of input. And if the input
name is long enough, the output length may exceed the allocated buffer
length.

All this means that conversion from UTF8 or NLS to CS0 requires
checking of output length in order to stop when it exceeds the given
output buffer size.

[JK: Make code return -ENAMETOOLONG instead of silently truncating the
name]

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bb00c898ad1ce40c4bb422a8207ae562e9aea7ae upstream.

If a name contains at least some characters with Unicode values
exceeding single byte, the CS0 output should have 2 bytes per character.
And if other input characters have single byte Unicode values, then
the single input byte is converted to 2 output bytes, and the length
of output becomes larger than the length of input. And if the input
name is long enough, the output length may exceed the allocated buffer
length.

All this means that conversion from UTF8 or NLS to CS0 requires
checking of output length in order to stop when it exceeds the given
output buffer size.

[JK: Make code return -ENAMETOOLONG instead of silently truncating the
name]

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Prevent buffer overrun with multi-byte characters</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2015-12-24T16:25:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7fe6afeeeb4a09006370274782338c1750d872f2'/>
<id>7fe6afeeeb4a09006370274782338c1750d872f2</id>
<content type='text'>
commit ad402b265ecf6fa22d04043b41444cdfcdf4f52d upstream.

udf_CS0toUTF8 function stops the conversion when the output buffer
length reaches UDF_NAME_LEN-2, which is correct maximum name length,
but, when checking, it leaves the space for a single byte only,
while multi-bytes output characters can take more space, causing
buffer overflow.

Similar error exists in udf_CS0toNLS function, that restricts
the output length to UDF_NAME_LEN, while actual maximum allowed
length is UDF_NAME_LEN-2.

In these cases the output can override not only the current buffer
length field, causing corruption of the name buffer itself, but also
following allocation structures, causing kernel crash.

Adjust the output length checks in both functions to prevent buffer
overruns in case of multi-bytes UTF8 or NLS characters.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ad402b265ecf6fa22d04043b41444cdfcdf4f52d upstream.

udf_CS0toUTF8 function stops the conversion when the output buffer
length reaches UDF_NAME_LEN-2, which is correct maximum name length,
but, when checking, it leaves the space for a single byte only,
while multi-bytes output characters can take more space, causing
buffer overflow.

Similar error exists in udf_CS0toNLS function, that restricts
the output length to UDF_NAME_LEN, while actual maximum allowed
length is UDF_NAME_LEN-2.

In these cases the output can override not only the current buffer
length field, causing corruption of the name buffer itself, but also
following allocation structures, causing kernel crash.

Adjust the output length checks in both functions to prevent buffer
overruns in case of multi-bytes UTF8 or NLS characters.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: limit the maximum number of indirect extents in a row</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2015-12-11T14:54:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7fb40bde70d2130605c489b36fcc65b17200b542'/>
<id>7fb40bde70d2130605c489b36fcc65b17200b542</id>
<content type='text'>
commit b0918d9f476a8434b055e362b83fa4fd1d462c3f upstream.

udf_next_aext() just follows extent pointers while extents are marked as
indirect. This can loop forever for corrupted filesystem. Limit number
the of indirect extents we are willing to follow in a row.

[JK: Updated changelog, limit, style]

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Cc: Jan Kara &lt;jack@suse.com&gt;
Cc: Quentin Casasnovas &lt;quentin.casasnovas@oracle.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
[wt: udf_error() instead of udf_err() in 2.6.32]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b0918d9f476a8434b055e362b83fa4fd1d462c3f upstream.

udf_next_aext() just follows extent pointers while extents are marked as
indirect. This can loop forever for corrupted filesystem. Limit number
the of indirect extents we are willing to follow in a row.

[JK: Updated changelog, limit, style]

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Cc: Jan Kara &lt;jack@suse.com&gt;
Cc: Quentin Casasnovas &lt;quentin.casasnovas@oracle.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
[wt: udf_error() instead of udf_err() in 2.6.32]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Promote some debugging messages to udf_error</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2011-10-10T08:08:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=140d24629ba0a885ca050d81a3407a5d8c982538'/>
<id>140d24629ba0a885ca050d81a3407a5d8c982538</id>
<content type='text'>
commit 7e273e3b41e32716dc122b293b5f15635af495ff upstream.

If there is a problem with a scratched disc or loader, it's valuable to know
which error occurred.

Convert some debug messages to udf_error, neaten those messages too.
Add the calculated tag checksum and the read checksum to error message.
Make udf_error a public function and move the logging prototypes together.

Original-patch-by: NamJae Jeon &lt;linkinjeon@gmail.com&gt;
Reviewed-by: NamJae Jeon &lt;linkinjeon@gmail.com&gt;
Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
[wt: this one is only here to export udf_error() for next commit]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7e273e3b41e32716dc122b293b5f15635af495ff upstream.

If there is a problem with a scratched disc or loader, it's valuable to know
which error occurred.

Convert some debug messages to udf_error, neaten those messages too.
Add the calculated tag checksum and the read checksum to error message.
Make udf_error a public function and move the logging prototypes together.

Original-patch-by: NamJae Jeon &lt;linkinjeon@gmail.com&gt;
Reviewed-by: NamJae Jeon &lt;linkinjeon@gmail.com&gt;
Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
[wt: this one is only here to export udf_error() for next commit]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup</title>
<updated>2016-03-12T13:25:43+00:00</updated>
<author>
<name>xuejiufei</name>
<email>xuejiufei@huawei.com</email>
</author>
<published>2016-02-05T23:36:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=64da7b6527f3e80f65a0ce1b47fb0cd1d66a1853'/>
<id>64da7b6527f3e80f65a0ce1b47fb0cd1d66a1853</id>
<content type='text'>
commit c95a51807b730e4681e2ecbdfd669ca52601959e upstream.

When recovery master down, dlm_do_local_recovery_cleanup() only remove
the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
Which will make umount thread falling in dead loop migrating $RECOVERY
to the dead node.

Signed-off-by: xuejiufei &lt;xuejiufei@huawei.com&gt;
Reviewed-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.de&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
[wt: dlm_lockres_clear_refmap_bit() takes 2 args in 2.6.32]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c95a51807b730e4681e2ecbdfd669ca52601959e upstream.

When recovery master down, dlm_do_local_recovery_cleanup() only remove
the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
Which will make umount thread falling in dead loop migrating $RECOVERY
to the dead node.

Signed-off-by: xuejiufei &lt;xuejiufei@huawei.com&gt;
Reviewed-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.de&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
[wt: dlm_lockres_clear_refmap_bit() takes 2 args in 2.6.32]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pipe: Fix buffer offset after partially failed read</title>
<updated>2016-03-12T13:25:41+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2016-02-13T18:42:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=42646fbfdee0717b3d4c164e15d31b608d6ece97'/>
<id>42646fbfdee0717b3d4c164e15d31b608d6ece97</id>
<content type='text'>
Quoting the RHEL advisory:

&gt; It was found that the fix for CVE-2015-1805 incorrectly kept buffer
&gt; offset and buffer length in sync on a failed atomic read, potentially
&gt; resulting in a pipe buffer state corruption. A local, unprivileged user
&gt; could use this flaw to crash the system or leak kernel memory to user
&gt; space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Quoting the RHEL advisory:

&gt; It was found that the fix for CVE-2015-1805 incorrectly kept buffer
&gt; offset and buffer length in sync on a failed atomic read, potentially
&gt; resulting in a pipe buffer state corruption. A local, unprivileged user
&gt; could use this flaw to crash the system or leak kernel memory to user
&gt; space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>readv/writev: do the same MAX_RW_COUNT truncation that read/write does</title>
<updated>2016-03-12T13:25:41+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-10-29T17:36:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=adfdad98d876fc9e43746522d6329d482edca6b3'/>
<id>adfdad98d876fc9e43746522d6329d482edca6b3</id>
<content type='text'>
commit 435f49a518c78eec8e2edbbadd912737246cbe20 upstream.

We used to protect against overflow, but rather than return an error, do
what read/write does, namely to limit the total size to MAX_RW_COUNT.
This is not only more consistent, but it also means that any broken
low-level read/write routine that still keeps counts in 'int' can't
break.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 435f49a518c78eec8e2edbbadd912737246cbe20 upstream.

We used to protect against overflow, but rather than return an error, do
what read/write does, namely to limit the total size to MAX_RW_COUNT.
This is not only more consistent, but it also means that any broken
low-level read/write routine that still keeps counts in 'int' can't
break.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vfs: make AIO use the proper rw_verify_area() area helpers</title>
<updated>2016-03-12T13:25:41+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-05-21T23:06:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cde5406e80c478bf89b6c2874f02126ba37a7d91'/>
<id>cde5406e80c478bf89b6c2874f02126ba37a7d91</id>
<content type='text'>
commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.

We had for some reason overlooked the AIO interface, and it didn't use
the proper rw_verify_area() helper function that checks (for example)
mandatory locking on the file, and that the size of the access doesn't
cause us to overflow the provided offset limits etc.

Instead, AIO did just the security_file_permission() thing (that
rw_verify_area() also does) directly.

This fixes it to do all the proper helper functions, which not only
means that now mandatory file locking works with AIO too, we can
actually remove lines of code.

Reported-by: Manish Honap &lt;manish_honap_vit@yahoo.co.in&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.

We had for some reason overlooked the AIO interface, and it didn't use
the proper rw_verify_area() helper function that checks (for example)
mandatory locking on the file, and that the size of the access doesn't
cause us to overflow the provided offset limits etc.

Instead, AIO did just the security_file_permission() thing (that
rw_verify_area() also does) directly.

This fixes it to do all the proper helper functions, which not only
means that now mandatory file locking works with AIO too, we can
actually remove lines of code.

Reported-by: Manish Honap &lt;manish_honap_vit@yahoo.co.in&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>locks: fix unlock when fcntl_setlk races with a close</title>
<updated>2016-03-12T13:25:40+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jeff.layton@primarydata.com</email>
</author>
<published>2016-01-07T21:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5a7c752dd867bbea6d6301e9e4154a169f2ca4f6'/>
<id>5a7c752dd867bbea6d6301e9e4154a169f2ca4f6</id>
<content type='text'>
commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.

Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.

The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.

Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.

While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.

Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Jeff Layton &lt;jeff.layton@primarydata.com&gt;
Acked-by: "J. Bruce Fields" &lt;bfields@fieldses.org&gt;
[bwh: Backported to 3.2: s/i_flctx-&gt;flc_posix/inode-&gt;i_flock/ in comments]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.

Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.

The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.

Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.

While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.

Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Jeff Layton &lt;jeff.layton@primarydata.com&gt;
Acked-by: "J. Bruce Fields" &lt;bfields@fieldses.org&gt;
[bwh: Backported to 3.2: s/i_flctx-&gt;flc_posix/inode-&gt;i_flock/ in comments]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
</feed>
