linux-toradex.git/fs, branch v4.9.28

block: get rid of blk_integrity_revalidate()

2017-05-14T12:00:22+00:00

commit 19b7ccf8651df09d274671b53039c672a52ad84d upstream.

Commit 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk")
introduced blk_integrity_revalidate(), which seems to assume ownership
of the stable pages flag and unilaterally clears it if no blk_integrity
profile is registered:

    if (bi->profile)
            disk->queue->backing_dev_info->capabilities |=
                    BDI_CAP_STABLE_WRITES;
    else
            disk->queue->backing_dev_info->capabilities &=
                    ~BDI_CAP_STABLE_WRITES;

It's called from revalidate_disk() and rescan_partitions(), making it
impossible to enable stable pages for drivers that support partitions
and don't use blk_integrity: while the call in revalidate_disk() can be
trivially worked around (see zram, which doesn't support partitions and
hence gets away with zram_revalidate_disk()), rescan_partitions() can
be triggered from userspace at any time.  This breaks rbd, where the
ceph messenger is responsible for generating/verifying CRCs.

Since blk_integrity_{un,}register() "must" be used for (un)registering
the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES
setting there.  This way drivers that call blk_integrity_register() and
use integrity infrastructure won't interfere with drivers that don't
but still want stable pages.

Fixes: 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk")
Cc: "Martin K. Petersen" 
Cc: Christoph Hellwig 
Cc: Mike Snitzer 
Tested-by: Dan Williams 
Signed-off-by: Ilya Dryomov 
[idryomov@gmail.com: backport to < 4.11: bdi is embedded in queue]
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

f2fs: sanity check segment count

2017-05-14T12:00:22+00:00

commit b9dd46188edc2f0d1f37328637860bb65a771124 upstream.

F2FS uses 4 bytes to represent block address. As a result, supported
size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.

Signed-off-by: Jin Qian 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Greg Kroah-Hartman

9p: fix a potential acl leak

2017-05-14T12:00:13+00:00

commit b5c66bab72a6a65edb15beb60b90d3cb84c5763b upstream.

posix_acl_update_mode() could possibly clear 'acl', if so we leak the
memory pointed by 'acl'.  Save this pointer before calling
posix_acl_update_mode() and release the memory if 'acl' really gets
cleared.

Link: http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangcong@gmail.com
Signed-off-by: Cong Wang 
Reported-by: Mark Salyzyn 
Reviewed-by: Jan Kara 
Reviewed-by: Greg Kurz 
Cc: Eric Van Hensbergen 
Cc: Ron Minnich 
Cc: Latchesar Ionkov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ceph: try getting buffer capability for readahead/fadvise

2017-05-08T05:47:55+00:00

commit 2b1ac852eb67a6e95595e576371d23519105559f upstream.

For readahead/fadvise cases, caller of ceph_readpages does not
hold buffer capability. Pages can be added to page cache while
there is no buffer capability. This can cause data integrity
issue.

Signed-off-by: Yan, Zheng 
Signed-off-by: Greg Kroah-Hartman

Handle mismatched open calls

2017-05-08T05:47:55+00:00

commit 38bd49064a1ecb67baad33598e3d824448ab11ec upstream.

A signal can interrupt a SendReceive call which result in incoming
responses to the call being ignored. This is a problem for calls such as
open which results in the successful response being ignored. This
results in an open file resource on the server.

The patch looks into responses which were cancelled after being sent and
in case of successful open closes the open fids.

For this patch, the check is only done in SendReceive2()

RH-bz: 1403319

Signed-off-by: Sachin Prabhu 
Reviewed-by: Pavel Shilovsky 
Acked-by: Sachin Prabhu 
Signed-off-by: Pavel Shilovsky 
Signed-off-by: Greg Kroah-Hartman

timerfd: Protect the might cancel mechanism proper

2017-05-08T05:47:54+00:00

commit 1e38da300e1e395a15048b0af1e5305bd91402f6 upstream.

The handling of the might_cancel queueing is not properly protected, so
parallel operations on the file descriptor can race with each other and
lead to list corruptions or use after free.

Protect the context for these operations with a seperate lock.

The wait queue lock cannot be reused for this because that would create a
lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
atomic (atomic_t or atomic bit) does not help either because it still can
race vs. the actual list operation.

Reported-by: Dmitry Vyukov 
Signed-off-by: Thomas Gleixner 
Cc: "linux-fsdevel@vger.kernel.org"
Cc: syzkaller 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

ceph: fix recursion between ceph_set_acl() and __ceph_setattr()

2017-05-03T15:36:39+00:00

commit 8179a101eb5f4ef0ac9a915fcea9a9d3109efa90 upstream.

ceph_set_acl() calls __ceph_setattr() if the setacl operation needs
to modify inode's i_mode. __ceph_setattr() updates inode's i_mode,
then calls posix_acl_chmod().

The problem is that __ceph_setattr() calls posix_acl_chmod() before
sending the setattr request. The get_acl() call in posix_acl_chmod()
can trigger a getxattr request. The reply of the getxattr request
can restore inode's i_mode to its old value. The set_acl() call in
posix_acl_chmod() sees old value of inode's i_mode, so it calls
__ceph_setattr() again.

Link: http://tracker.ceph.com/issues/19688
Reported-by: Jerry Lee 
Signed-off-by: "Yan, Zheng" 
Reviewed-by: Jeff Layton 
Tested-by: Luis Henriques 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

nfsd: stricter decoding of write-like NFSv2/v3 ops

2017-05-03T15:36:38+00:00

commit 13bf9fbff0e5e099e2b6f003a0ab8ae145436309 upstream.

The NFSv2/v3 code does not systematically check whether we decode past
the end of the buffer.  This generally appears to be harmless, but there
are a few places where we do arithmetic on the pointers involved and
don't account for the possibility that a length could be negative.  Add
checks to catch these.

Reported-by: Tuomas Haanpää 
Reported-by: Ari Kauppi 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nfsd4: minor NFSv2/v3 write decoding cleanup

2017-05-03T15:36:38+00:00

commit db44bac41bbfc0c0d9dd943092d8bded3c9db19b upstream.

Use a couple shortcuts that will simplify a following bugfix.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nfsd: check for oversized NFSv2/v3 arguments

2017-05-03T15:36:38+00:00

commit e6838a29ecb484c97e4efef9429643b9851fba6e upstream.

A client can append random data to the end of an NFSv2 or NFSv3 RPC call
without our complaining; we'll just stop parsing at the end of the
expected data and ignore the rest.

Encoded arguments and replies are stored together in an array of pages,
and if a call is too large it could leave inadequate space for the
reply.  This is normally OK because NFS RPC's typically have either
short arguments and long replies (like READ) or long arguments and short
replies (like WRITE).  But a client that sends an incorrectly long reply
can violate those assumptions.  This was observed to cause crashes.

Also, several operations increment rq_next_page in the decode routine
before checking the argument size, which can leave rq_next_page pointing
well past the end of the page array, causing trouble later in
svc_free_pages.

So, following a suggestion from Neil Brown, add a central check to
enforce our expectation that no NFSv2/v3 call has both a large call and
a large reply.

As followup we may also want to rewrite the encoding routines to check
more carefully that they aren't running off the end of the page array.

We may also consider rejecting calls that have any extra garbage
appended.  That would be safer, and within our rights by spec, but given
the age of our server and the NFS protocol, and the fact that we've
never enforced this before, we may need to balance that against the
possibility of breaking some oddball client.

Reported-by: Tuomas Haanpää 
Reported-by: Ari Kauppi 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman