1. 08 7月, 2019 22 次提交
  2. 05 7月, 2019 2 次提交
  3. 04 7月, 2019 1 次提交
    • P
      nfsd: Fix overflow causing non-working mounts on 1 TB machines · 3b2d4dcf
      Paul Menzel 提交于
      Since commit 10a68cdf10 (nfsd: fix performance-limiting session
      calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with
      1 TB of memory cannot be mounted anymore. The mount just hangs on the
      client.
      
      The gist of commit 10a68cdf10 is the change below.
      
          -avail = clamp_t(int, avail, slotsize, avail/3);
          +avail = clamp_t(int, avail, slotsize, total_avail/3);
      
      Here are the macros.
      
          #define min_t(type, x, y)       __careful_cmp((type)(x), (type)(y), <)
          #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi)
      
      `total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts
      the values to `int`, which for 32-bit integers can only hold values
      −2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1).
      
      `avail` (in the function signature) is just 65536, so that no overflow
      was happening. Before the commit the assignment would result in 21845,
      and `num = 4`.
      
      When using `total_avail`, it is causing the assignment to be
      18446744072226137429 (printed as %lu), and `num` is then 4164608182.
      
      My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the
      server thinks there is no memory available any more for this client.
      
      Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long`
      fixes the issue.
      
      Now, `avail = 65536` (before commit 10a68cdf10 `avail = 21845`), but
      `num = 4` remains the same.
      
      Fixes: c54f24e3 (nfsd: fix performance-limiting session calculation)
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      3b2d4dcf
  4. 01 7月, 2019 1 次提交
    • E
      vfs: move_mount: reject moving kernel internal mounts · 570d7a98
      Eric Biggers 提交于
      sys_move_mount() crashes by dereferencing the pointer MNT_NS_INTERNAL,
      a.k.a. ERR_PTR(-EINVAL), if the old mount is specified by fd for a
      kernel object with an internal mount, such as a pipe or memfd.
      
      Fix it by checking for this case and returning -EINVAL.
      
      [AV: what we want is is_mounted(); use that instead of making the
      condition even more convoluted]
      
      Reproducer:
      
          #include <unistd.h>
      
          #define __NR_move_mount         429
          #define MOVE_MOUNT_F_EMPTY_PATH 0x00000004
      
          int main()
          {
          	int fds[2];
      
          	pipe(fds);
              syscall(__NR_move_mount, fds[0], "", -1, "/", MOVE_MOUNT_F_EMPTY_PATH);
          }
      
      Reported-by: syzbot+6004acbaa1893ad013f0@syzkaller.appspotmail.com
      Fixes: 2db154b3 ("vfs: syscall: Add move_mount(2) to move mounts around")
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      570d7a98
  5. 29 6月, 2019 3 次提交
  6. 28 6月, 2019 3 次提交
  7. 27 6月, 2019 1 次提交
  8. 22 6月, 2019 2 次提交
    • J
      io_uring: ensure req->file is cleared on allocation · 60c112b0
      Jens Axboe 提交于
      Stephen reports:
      
      I hit the following General Protection Fault when testing io_uring via
      the io_uring engine in fio. This was on a VM running 5.2-rc5 and the
      latest version of fio. The issue occurs for both null_blk and fake NVMe
      drives. I have not tested bare metal or real NVMe SSDs. The fio script
      used is given below.
      
      [io_uring]
      time_based=1
      runtime=60
      filename=/dev/nvme2n1 (note /dev/nullb0 also fails)
      ioengine=io_uring
      bs=4k
      rw=readwrite
      direct=1
      fixedbufs=1
      sqthread_poll=1
      sqthread_poll_cpu=0
      
      general protection fault: 0000 [#1] SMP PTI
      CPU: 0 PID: 872 Comm: io_uring-sq Not tainted 5.2.0-rc5-cpacket-io-uring #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      RIP: 0010:fput_many+0x7/0x90
      Code: 01 48 85 ff 74 17 55 48 89 e5 53 48 8b 1f e8 a0 f9 ff ff 48 85 db 48 89 df 75 f0 5b 5d f3 c3 0f 1f 40 00 0f 1f 44 00 00 89 f6 <f0> 48 29 77 38 74 01 c3 55 48 89 e5 53 48 89 fb 65 48 \
      
      RSP: 0018:ffffadeb817ebc50 EFLAGS: 00010246
      RAX: 0000000000000004 RBX: ffff8f46ad477480 RCX: 0000000000001805
      RDX: 0000000000000000 RSI: 0000000000000001 RDI: f18b51b9a39552b5
      RBP: ffffadeb817ebc58 R08: ffff8f46b7a318c0 R09: 000000000000015d
      R10: ffffadeb817ebce8 R11: 0000000000000020 R12: ffff8f46ad4cd000
      R13: 00000000fffffff7 R14: ffffadeb817ebe30 R15: 0000000000000004
      FS:  0000000000000000(0000) GS:ffff8f46b7a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055828f0bbbf0 CR3: 0000000232176004 CR4: 00000000003606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? fput+0x13/0x20
       io_free_req+0x20/0x40
       io_put_req+0x1b/0x20
       io_submit_sqe+0x40a/0x680
       ? __switch_to_asm+0x34/0x70
       ? __switch_to_asm+0x40/0x70
       io_submit_sqes+0xb9/0x160
       ? io_submit_sqes+0xb9/0x160
       ? __switch_to_asm+0x40/0x70
       ? __switch_to_asm+0x34/0x70
       ? __schedule+0x3f2/0x6a0
       ? __switch_to_asm+0x34/0x70
       io_sq_thread+0x1af/0x470
       ? __switch_to_asm+0x34/0x70
       ? wait_woken+0x80/0x80
       ? __switch_to+0x85/0x410
       ? __switch_to_asm+0x40/0x70
       ? __switch_to_asm+0x34/0x70
       ? __schedule+0x3f2/0x6a0
       kthread+0x105/0x140
       ? io_submit_sqes+0x160/0x160
       ? kthread+0x105/0x140
       ? io_submit_sqes+0x160/0x160
       ? kthread_destroy_worker+0x50/0x50
       ret_from_fork+0x35/0x40
      
      which occurs because using a kernel side submission thread isn't valid
      without using fixed files (registered through io_uring_register()). This
      causes io_uring to put the request after logging an error, but before
      the file field is set in the request. If it happens to be non-zero, we
      attempt to fput() garbage.
      
      Fix this by ensuring that req->file is initialized when the request is
      allocated.
      
      Cc: stable@vger.kernel.org # 5.1+
      Reported-by: NStephen Bates <sbates@raithlin.com>
      Tested-by: NStephen Bates <sbates@raithlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      60c112b0
    • B
      NFS4: Only set creation opendata if O_CREAT · 90910519
      Benjamin Coddington 提交于
      We can end up in nfs4_opendata_alloc during task exit, in which case
      current->fs has already been cleaned up.  This leads to a crash in
      current_umask().
      
      Fix this by only setting creation opendata if we are actually doing an open
      with O_CREAT.  We can drop the check for NULL nfs4_open_createattrs, since
      O_CREAT will never be set for the recovery path.
      Suggested-by: NTrond Myklebust <trondmy@hammerspace.com>
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      90910519
  9. 21 6月, 2019 1 次提交
    • D
      afs: Fix setting of i_blocks · 2cd42d19
      David Howells 提交于
      The setting of i_blocks, which is calculated from i_size, has got
      accidentally misordered relative to the setting of i_size when initially
      setting up an inode.  Further, i_blocks isn't updated by afs_apply_status()
      when the size is updated.
      
      To fix this, break the i_size/i_blocks setting out into a helper function
      and call it from both places.
      
      Fixes: a58823ac ("afs: Fix application of status and callback to be under same lock")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2cd42d19
  10. 20 6月, 2019 3 次提交
    • D
      afs: Fix uninitialised spinlock afs_volume::cb_break_lock · 90fa9b64
      David Howells 提交于
      Fix the cb_break_lock spinlock in afs_volume struct by initialising it when
      the volume record is allocated.
      
      Also rename the lock to cb_v_break_lock to distinguish it from the lock of
      the same name in the afs_server struct.
      
      Without this, the following trace may be observed when a volume-break
      callback is received:
      
        INFO: trying to register non-static key.
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
        CPU: 2 PID: 50 Comm: kworker/2:1 Not tainted 5.2.0-rc1-fscache+ #3045
        Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
        Workqueue: afs SRXAFSCB_CallBack
        Call Trace:
         dump_stack+0x67/0x8e
         register_lock_class+0x23b/0x421
         ? check_usage_forwards+0x13c/0x13c
         __lock_acquire+0x89/0xf73
         lock_acquire+0x13b/0x166
         ? afs_break_callbacks+0x1b2/0x3dd
         _raw_write_lock+0x2c/0x36
         ? afs_break_callbacks+0x1b2/0x3dd
         afs_break_callbacks+0x1b2/0x3dd
         ? trace_event_raw_event_afs_server+0x61/0xac
         SRXAFSCB_CallBack+0x11f/0x16c
         process_one_work+0x2c5/0x4ee
         ? worker_thread+0x234/0x2ac
         worker_thread+0x1d8/0x2ac
         ? cancel_delayed_work_sync+0xf/0xf
         kthread+0x11f/0x127
         ? kthread_park+0x76/0x76
         ret_from_fork+0x24/0x30
      
      Fixes: 68251f0a ("afs: Fix whole-volume callback handling")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      90fa9b64
    • D
      afs: Fix vlserver record corruption · a6853b9c
      David Howells 提交于
      Because I made the afs_call struct share pointers to an afs_server object
      and an afs_vlserver object to save space, afs_put_call() calls
      afs_put_server() on afs_vlserver object (which is only meant for the
      afs_server object) because it sees that call->server isn't NULL.
      
      This means that the afs_vlserver object gets unpredictably and randomly
      modified, depending on what config options are set (such as lockdep).
      
      Fix this by getting rid of the union and having two non-overlapping
      pointers in the afs_call struct.
      
      Fixes: ffba718e ("afs: Get rid of afs_call::reply[]")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a6853b9c
    • D
      afs: Fix over zealous "vnode modified" warnings · 3647e42b
      David Howells 提交于
      Occasionally, warnings like this:
      
      	vnode modified 2af7 on {10000b:1} [exp 2af2] YFS.FetchStatus(vnode)
      
      are emitted into the kernel log.  This indicates that when we were applying
      the updated vnode (file) status retrieved from the server to an inode we
      saw that the data version number wasn't what we were expecting (in this
      case it's 0x2af7 rather than 0x2af2).
      
      We've usually received a callback from the server prior to this point - or
      the callback promise has lapsed - so the warning is merely informative and
      the state is to be expected.
      
      Fix this by only emitting the warning if the we still think that we have a
      valid callback promise and haven't received a callback.
      
      Also change the format slightly so so that the new data version doesn't
      look like part of the text, the like is prefixed with "kAFS: " and the
      message is ranked as a warning.
      
      Fixes: 31143d5d ("AFS: implement basic file write support")
      Reported-by: NIan Wienand <iwienand@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      3647e42b
  11. 19 6月, 2019 1 次提交