<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs, branch v4.9.6</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ceph: fix endianness bug in frag_tree_split_cmp</title>
<updated>2017-01-26T07:24:43+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2017-01-12T19:42:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6e9fa67c58ccd59df9cc21a8e9a4c4f9aea15fa8'/>
<id>6e9fa67c58ccd59df9cc21a8e9a4c4f9aea15fa8</id>
<content type='text'>
commit fe2ed42517533068ac03eed5630fffafff27eacf upstream.

sparse says:

    fs/ceph/inode.c:308:36: warning: incorrect type in argument 1 (different base types)
    fs/ceph/inode.c:308:36:    expected unsigned int [unsigned] [usertype] a
    fs/ceph/inode.c:308:36:    got restricted __le32 [usertype] frag
    fs/ceph/inode.c:308:46: warning: incorrect type in argument 2 (different base types)
    fs/ceph/inode.c:308:46:    expected unsigned int [unsigned] [usertype] b
    fs/ceph/inode.c:308:46:    got restricted __le32 [usertype] frag

We need to convert these values to host-endian before calling the
comparator.

Fixes: a407846ef7c6 ("ceph: don't assume frag tree splits in mds reply are sorted")
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fe2ed42517533068ac03eed5630fffafff27eacf upstream.

sparse says:

    fs/ceph/inode.c:308:36: warning: incorrect type in argument 1 (different base types)
    fs/ceph/inode.c:308:36:    expected unsigned int [unsigned] [usertype] a
    fs/ceph/inode.c:308:36:    got restricted __le32 [usertype] frag
    fs/ceph/inode.c:308:46: warning: incorrect type in argument 2 (different base types)
    fs/ceph/inode.c:308:46:    expected unsigned int [unsigned] [usertype] b
    fs/ceph/inode.c:308:46:    got restricted __le32 [usertype] frag

We need to convert these values to host-endian before calling the
comparator.

Fixes: a407846ef7c6 ("ceph: don't assume frag tree splits in mds reply are sorted")
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ceph: fix endianness of getattr mask in ceph_d_revalidate</title>
<updated>2017-01-26T07:24:43+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2017-01-12T19:42:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2e4f2131b66ffe64ef90d1e85223ef347e355b65'/>
<id>2e4f2131b66ffe64ef90d1e85223ef347e355b65</id>
<content type='text'>
commit 1097680d759918ce4a8705381c0ab2ed7bd60cf1 upstream.

sparse says:

    fs/ceph/dir.c:1248:50: warning: incorrect type in assignment (different base types)
    fs/ceph/dir.c:1248:50:    expected restricted __le32 [usertype] mask
    fs/ceph/dir.c:1248:50:    got int [signed] [assigned] mask

Fixes: 200fd27c8fa2 ("ceph: use lookup request to revalidate dentry")
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1097680d759918ce4a8705381c0ab2ed7bd60cf1 upstream.

sparse says:

    fs/ceph/dir.c:1248:50: warning: incorrect type in assignment (different base types)
    fs/ceph/dir.c:1248:50:    expected restricted __le32 [usertype] mask
    fs/ceph/dir.c:1248:50:    got int [signed] [assigned] mask

Fixes: 200fd27c8fa2 ("ceph: use lookup request to revalidate dentry")
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ceph: fix ceph_get_caps() interruption</title>
<updated>2017-01-26T07:24:43+00:00</updated>
<author>
<name>Yan, Zheng</name>
<email>zyan@redhat.com</email>
</author>
<published>2016-12-22T08:05:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8934e069674a09c4ce4a0858e1aee5474784df92'/>
<id>8934e069674a09c4ce4a0858e1aee5474784df92</id>
<content type='text'>
commit 6e09d0fb64402cec579f029ca4c7f39f5c48fc60 upstream.

Commit 5c341ee32881 ("ceph: fix scheduler warning due to nested
blocking") causes infinite loop when process is interrupted.  Fix it.

Signed-off-by: Yan, Zheng &lt;zyan@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6e09d0fb64402cec579f029ca4c7f39f5c48fc60 upstream.

Commit 5c341ee32881 ("ceph: fix scheduler warning due to nested
blocking") causes infinite loop when process is interrupted.  Fix it.

Signed-off-by: Yan, Zheng &lt;zyan@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ceph: fix scheduler warning due to nested blocking</title>
<updated>2017-01-26T07:24:43+00:00</updated>
<author>
<name>Nikolay Borisov</name>
<email>kernel@kyup.com</email>
</author>
<published>2016-10-11T09:04:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=48baa924108e124bc5221ca73b72562a8479c11c'/>
<id>48baa924108e124bc5221ca73b72562a8479c11c</id>
<content type='text'>
commit 5c341ee32881c554727ec14b71ec3e8832f01989 upstream.

try_get_cap_refs can be used as a condition in a wait_event* calls.
This is all fine until it has to call __ceph_do_pending_vmtruncate,
which in turn acquires the i_truncate_mutex. This leads to a situation
in which a task's state is !TASK_RUNNING and at the same time it's
trying to acquire a sleeping primitive. In essence a nested sleeping
primitives are being used. This causes the following warning:

WARNING: CPU: 22 PID: 11064 at kernel/sched/core.c:7631 __might_sleep+0x9f/0xb0()
do not call blocking ops when !TASK_RUNNING; state=1 set at [&lt;ffffffff8109447d&gt;] prepare_to_wait_event+0x5d/0x110
 ipmi_msghandler tcp_scalable ib_qib dca ib_mad ib_core ib_addr ipv6
CPU: 22 PID: 11064 Comm: fs_checker.pl Tainted: G           O    4.4.20-clouder2 #6
Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1a 10/16/2015
 0000000000000000 ffff8838b416fa88 ffffffff812f4409 ffff8838b416fad0
 ffffffff81a034f2 ffff8838b416fac0 ffffffff81052b46 ffffffff81a0432c
 0000000000000061 0000000000000000 0000000000000000 ffff88167bda54a0
Call Trace:
 [&lt;ffffffff812f4409&gt;] dump_stack+0x67/0x9e
 [&lt;ffffffff81052b46&gt;] warn_slowpath_common+0x86/0xc0
 [&lt;ffffffff81052bcc&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8109447d&gt;] ? prepare_to_wait_event+0x5d/0x110
 [&lt;ffffffff8109447d&gt;] ? prepare_to_wait_event+0x5d/0x110
 [&lt;ffffffff8107767f&gt;] __might_sleep+0x9f/0xb0
 [&lt;ffffffff81612d30&gt;] mutex_lock+0x20/0x40
 [&lt;ffffffffa04eea14&gt;] __ceph_do_pending_vmtruncate+0x44/0x1a0 [ceph]
 [&lt;ffffffffa04fa692&gt;] try_get_cap_refs+0xa2/0x320 [ceph]
 [&lt;ffffffffa04fd6f5&gt;] ceph_get_caps+0x255/0x2b0 [ceph]
 [&lt;ffffffff81094370&gt;] ? wait_woken+0xb0/0xb0
 [&lt;ffffffffa04f2c11&gt;] ceph_write_iter+0x2b1/0xde0 [ceph]
 [&lt;ffffffff81613f22&gt;] ? schedule_timeout+0x202/0x260
 [&lt;ffffffff8117f01a&gt;] ? kmem_cache_free+0x1ea/0x200
 [&lt;ffffffff811b46ce&gt;] ? iput+0x9e/0x230
 [&lt;ffffffff81077632&gt;] ? __might_sleep+0x52/0xb0
 [&lt;ffffffff81156147&gt;] ? __might_fault+0x37/0x40
 [&lt;ffffffff8119e123&gt;] ? cp_new_stat+0x153/0x170
 [&lt;ffffffff81198cfa&gt;] __vfs_write+0xaa/0xe0
 [&lt;ffffffff81199369&gt;] vfs_write+0xa9/0x190
 [&lt;ffffffff811b6d01&gt;] ? set_close_on_exec+0x31/0x70
 [&lt;ffffffff8119a056&gt;] SyS_write+0x46/0xa0

This happens since wait_event_interruptible can interfere with the
mutex locking code, since they both fiddle with the task state.

Fix the issue by using the newly-added nested blocking infrastructure
in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with
nested blocking")

Link: https://lwn.net/Articles/628628/
Signed-off-by: Nikolay Borisov &lt;kernel@kyup.com&gt;
Signed-off-by: Yan, Zheng &lt;zyan@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5c341ee32881c554727ec14b71ec3e8832f01989 upstream.

try_get_cap_refs can be used as a condition in a wait_event* calls.
This is all fine until it has to call __ceph_do_pending_vmtruncate,
which in turn acquires the i_truncate_mutex. This leads to a situation
in which a task's state is !TASK_RUNNING and at the same time it's
trying to acquire a sleeping primitive. In essence a nested sleeping
primitives are being used. This causes the following warning:

WARNING: CPU: 22 PID: 11064 at kernel/sched/core.c:7631 __might_sleep+0x9f/0xb0()
do not call blocking ops when !TASK_RUNNING; state=1 set at [&lt;ffffffff8109447d&gt;] prepare_to_wait_event+0x5d/0x110
 ipmi_msghandler tcp_scalable ib_qib dca ib_mad ib_core ib_addr ipv6
CPU: 22 PID: 11064 Comm: fs_checker.pl Tainted: G           O    4.4.20-clouder2 #6
Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1a 10/16/2015
 0000000000000000 ffff8838b416fa88 ffffffff812f4409 ffff8838b416fad0
 ffffffff81a034f2 ffff8838b416fac0 ffffffff81052b46 ffffffff81a0432c
 0000000000000061 0000000000000000 0000000000000000 ffff88167bda54a0
Call Trace:
 [&lt;ffffffff812f4409&gt;] dump_stack+0x67/0x9e
 [&lt;ffffffff81052b46&gt;] warn_slowpath_common+0x86/0xc0
 [&lt;ffffffff81052bcc&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8109447d&gt;] ? prepare_to_wait_event+0x5d/0x110
 [&lt;ffffffff8109447d&gt;] ? prepare_to_wait_event+0x5d/0x110
 [&lt;ffffffff8107767f&gt;] __might_sleep+0x9f/0xb0
 [&lt;ffffffff81612d30&gt;] mutex_lock+0x20/0x40
 [&lt;ffffffffa04eea14&gt;] __ceph_do_pending_vmtruncate+0x44/0x1a0 [ceph]
 [&lt;ffffffffa04fa692&gt;] try_get_cap_refs+0xa2/0x320 [ceph]
 [&lt;ffffffffa04fd6f5&gt;] ceph_get_caps+0x255/0x2b0 [ceph]
 [&lt;ffffffff81094370&gt;] ? wait_woken+0xb0/0xb0
 [&lt;ffffffffa04f2c11&gt;] ceph_write_iter+0x2b1/0xde0 [ceph]
 [&lt;ffffffff81613f22&gt;] ? schedule_timeout+0x202/0x260
 [&lt;ffffffff8117f01a&gt;] ? kmem_cache_free+0x1ea/0x200
 [&lt;ffffffff811b46ce&gt;] ? iput+0x9e/0x230
 [&lt;ffffffff81077632&gt;] ? __might_sleep+0x52/0xb0
 [&lt;ffffffff81156147&gt;] ? __might_fault+0x37/0x40
 [&lt;ffffffff8119e123&gt;] ? cp_new_stat+0x153/0x170
 [&lt;ffffffff81198cfa&gt;] __vfs_write+0xaa/0xe0
 [&lt;ffffffff81199369&gt;] vfs_write+0xa9/0x190
 [&lt;ffffffff811b6d01&gt;] ? set_close_on_exec+0x31/0x70
 [&lt;ffffffff8119a056&gt;] SyS_write+0x46/0xa0

This happens since wait_event_interruptible can interfere with the
mutex locking code, since they both fiddle with the task state.

Fix the issue by using the newly-added nested blocking infrastructure
in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with
nested blocking")

Link: https://lwn.net/Articles/628628/
Signed-off-by: Nikolay Borisov &lt;kernel@kyup.com&gt;
Signed-off-by: Yan, Zheng &lt;zyan@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ceph: fix bad endianness handling in parse_reply_info_extra</title>
<updated>2017-01-26T07:24:40+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2017-01-12T19:42:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1f75575aca7be589881cda14344b978b42cbceb5'/>
<id>1f75575aca7be589881cda14344b978b42cbceb5</id>
<content type='text'>
commit 6df8c9d80a27cb587f61b4f06b57e248d8bc3f86 upstream.

sparse says:

    fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer

The op value is __le32, so we need to convert it before comparing it.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6df8c9d80a27cb587f61b4f06b57e248d8bc3f86 upstream.

sparse says:

    fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
    fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer

The op value is __le32, so we need to convert it before comparing it.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Sage Weil &lt;sage@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ubifs: Fix journal replay wrt. xattr nodes</title>
<updated>2017-01-26T07:24:40+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2017-01-10T10:49:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ce5c52f039cf886ac1f2a2535bb4e02ebcefe043'/>
<id>ce5c52f039cf886ac1f2a2535bb4e02ebcefe043</id>
<content type='text'>
commit 1cb51a15b576ee325d527726afff40947218fd5e upstream.

When replaying the journal it can happen that a journal entry points to
a garbage collected node.
This is the case when a power-cut occurred between a garbage collect run
and a commit. In such a case nodes have to be read using the failable
read functions to detect whether the found node matches what we expect.

One corner case was forgotten, when the journal contains an entry to
remove an inode all xattrs have to be removed too. UBIFS models xattr
like directory entries, so the TNC code iterates over
all xattrs of the inode and removes them too. This code re-uses the
functions for walking directories and calls ubifs_tnc_next_ent().
ubifs_tnc_next_ent() expects to be used only after the journal and
aborts when a node does not match the expected result. This behavior can
render an UBIFS volume unmountable after a power-cut when xattrs are
used.

Fix this issue by using failable read functions in ubifs_tnc_next_ent()
too when replaying the journal.
Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Reported-by: Rock Lee &lt;rockdotlee@gmail.com&gt;
Reviewed-by: David Gstir &lt;david@sigma-star.at&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1cb51a15b576ee325d527726afff40947218fd5e upstream.

When replaying the journal it can happen that a journal entry points to
a garbage collected node.
This is the case when a power-cut occurred between a garbage collect run
and a commit. In such a case nodes have to be read using the failable
read functions to detect whether the found node matches what we expect.

One corner case was forgotten, when the journal contains an entry to
remove an inode all xattrs have to be removed too. UBIFS models xattr
like directory entries, so the TNC code iterates over
all xattrs of the inode and removes them too. This code re-uses the
functions for walking directories and calls ubifs_tnc_next_ent().
ubifs_tnc_next_ent() expects to be used only after the journal and
aborts when a node does not match the expected result. This behavior can
render an UBIFS volume unmountable after a power-cut when xattrs are
used.

Fix this issue by using failable read functions in ubifs_tnc_next_ent()
too when replaying the journal.
Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Reported-by: Rock Lee &lt;rockdotlee@gmail.com&gt;
Reviewed-by: David Gstir &lt;david@sigma-star.at&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fuse: fix time_to_jiffies nsec sanity check</title>
<updated>2017-01-26T07:24:38+00:00</updated>
<author>
<name>David Sheets</name>
<email>david.sheets@docker.com</email>
</author>
<published>2017-01-13T15:58:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=07f0267561c6cbe4a87c9a05134d2070f8b4a2ee'/>
<id>07f0267561c6cbe4a87c9a05134d2070f8b4a2ee</id>
<content type='text'>
commit 210675270caa33253e4c33f3c5e657e7d6060812 upstream.

Commit bcb6f6d2b9c2 ("fuse: use timespec64") introduced clamped nsec values
in time_to_jiffies but used the max of nsec and NSEC_PER_SEC - 1 instead of
the min. Because of this, dentries would stay in the cache longer than
requested and go stale in scenarios that relied on their timely eviction.

Fixes: bcb6f6d2b9c2 ("fuse: use timespec64")
Signed-off-by: David Sheets &lt;dsheets@docker.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 210675270caa33253e4c33f3c5e657e7d6060812 upstream.

Commit bcb6f6d2b9c2 ("fuse: use timespec64") introduced clamped nsec values
in time_to_jiffies but used the max of nsec and NSEC_PER_SEC - 1 instead of
the min. Because of this, dentries would stay in the cache longer than
requested and go stale in scenarios that relied on their timely eviction.

Fixes: bcb6f6d2b9c2 ("fuse: use timespec64")
Signed-off-by: David Sheets &lt;dsheets@docker.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fuse: clear FR_PENDING flag when moving requests out of pending queue</title>
<updated>2017-01-26T07:24:38+00:00</updated>
<author>
<name>Tahsin Erdogan</name>
<email>tahsin@google.com</email>
</author>
<published>2017-01-12T20:04:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0181b3603681d03e5753079cef8b17d2905faee5'/>
<id>0181b3603681d03e5753079cef8b17d2905faee5</id>
<content type='text'>
commit a8a86d78d673b1c99fe9b0064739fde9e9774184 upstream.

fuse_abort_conn() moves requests from pending list to a temporary list
before canceling them. This operation races with request_wait_answer()
which also tries to remove the request after it gets a fatal signal. It
checks FR_PENDING flag to determine whether the request is still in the
pending list.

Make fuse_abort_conn() clear FR_PENDING flag so that request_wait_answer()
does not remove the request from temporary list.

This bug causes an Oops when trying to delete an already deleted list entry
in end_requests().

Fixes: ee314a870e40 ("fuse: abort: no fc-&gt;lock needed for request ending")
Signed-off-by: Tahsin Erdogan &lt;tahsin@google.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a8a86d78d673b1c99fe9b0064739fde9e9774184 upstream.

fuse_abort_conn() moves requests from pending list to a temporary list
before canceling them. This operation races with request_wait_answer()
which also tries to remove the request after it gets a fatal signal. It
checks FR_PENDING flag to determine whether the request is still in the
pending list.

Make fuse_abort_conn() clear FR_PENDING flag so that request_wait_answer()
does not remove the request from temporary list.

This bug causes an Oops when trying to delete an already deleted list entry
in end_requests().

Fixes: ee314a870e40 ("fuse: abort: no fc-&gt;lock needed for request ending")
Signed-off-by: Tahsin Erdogan &lt;tahsin@google.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tmpfs: clear S_ISGID when setting posix ACLs</title>
<updated>2017-01-26T07:24:37+00:00</updated>
<author>
<name>Gu Zheng</name>
<email>guzheng1@huawei.com</email>
</author>
<published>2017-01-09T01:34:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=782b361c93062f083bbc9a78928498218f950399'/>
<id>782b361c93062f083bbc9a78928498218f950399</id>
<content type='text'>
commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.

This change was missed the tmpfs modification in In CVE-2016-7097
commit 073931017b49 ("posix_acl: Clear SGID bit when setting
file permissions")
It can test by xfstest generic/375, which failed to clear
setgid bit in the following test case on tmpfs:

  touch $testfile
  chown 100:100 $testfile
  chmod 2755 $testfile
  _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile

Signed-off-by: Gu Zheng &lt;guzheng1@huawei.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Brad Spengler &lt;spender@grsecurity.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.

This change was missed the tmpfs modification in In CVE-2016-7097
commit 073931017b49 ("posix_acl: Clear SGID bit when setting
file permissions")
It can test by xfstest generic/375, which failed to clear
setgid bit in the following test case on tmpfs:

  touch $testfile
  chown 100:100 $testfile
  chmod 2755 $testfile
  _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile

Signed-off-by: Gu Zheng &lt;guzheng1@huawei.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Brad Spengler &lt;spender@grsecurity.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success.</title>
<updated>2017-01-19T19:18:05+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.com</email>
</author>
<published>2016-12-19T00:19:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=396b25173370fc1afa3bc91a315d5597c2b10734'/>
<id>396b25173370fc1afa3bc91a315d5597c2b10734</id>
<content type='text'>
commit cfd278c280f997cf2fe4662e0acab0fe465f637b upstream.

Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds',
then ds-&gt;ds_clp will also be non-NULL.

This is not necessasrily true in the case when the process received a fatal signal
while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect().
In that case -&gt;ds_clp may not be set, and the devid may not recently have been marked
unavailable.

So add a test for ds_clp == NULL and return NULL in that case.

Fixes: c23266d532b4 ("NFS4.1 Fix data server connection race")
Signed-off-by: NeilBrown &lt;neilb@suse.com&gt;
Acked-by: Olga Kornievskaia &lt;aglo@umich.edu&gt;
Acked-by: Adamson, Andy &lt;William.Adamson@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cfd278c280f997cf2fe4662e0acab0fe465f637b upstream.

Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds',
then ds-&gt;ds_clp will also be non-NULL.

This is not necessasrily true in the case when the process received a fatal signal
while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect().
In that case -&gt;ds_clp may not be set, and the devid may not recently have been marked
unavailable.

So add a test for ds_clp == NULL and return NULL in that case.

Fixes: c23266d532b4 ("NFS4.1 Fix data server connection race")
Signed-off-by: NeilBrown &lt;neilb@suse.com&gt;
Acked-by: Olga Kornievskaia &lt;aglo@umich.edu&gt;
Acked-by: Adamson, Andy &lt;William.Adamson@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
