1. 10 Nov, 2018 3 commits
    • Ashish Samant's avatar
      fuse: Dont call set_page_dirty_lock() for ITER_BVEC pages for async_dio · 1b6a863f
      Ashish Samant authored
      [ Upstream commit 61c12b49 ]
      
      Commit 8fba54ae ("fuse: direct-io: don't dirty ITER_BVEC pages") fixes
      the ITER_BVEC page deadlock for direct io in fuse by checking in
      fuse_direct_io(), whether the page is a bvec page or not, before locking
      it.  However, this check is missed when the "async_dio" mount option is
      enabled.  In this case, set_page_dirty_lock() is called from the req->end
      callback in request_end(), when the fuse thread is returning from userspace
      to respond to the read request.  This will cause the same deadlock because
      the bvec condition is not checked in this path.
      
      Here is the stack of the deadlocked thread, while returning from userspace:
      
      [13706.656686] INFO: task glusterfs:3006 blocked for more than 120 seconds.
      [13706.657808] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
      this message.
      [13706.658788] glusterfs       D ffffffff816c80f0     0  3006      1
      0x00000080
      [13706.658797]  ffff8800d6713a58 0000000000000086 ffff8800d9ad7000
      ffff8800d9ad5400
      [13706.658799]  ffff88011ffd5cc0 ffff8800d6710008 ffff88011fd176c0
      7fffffffffffffff
      [13706.658801]  0000000000000002 ffffffff816c80f0 ffff8800d6713a78
      ffffffff816c790e
      [13706.658803] Call Trace:
      [13706.658809]  [<ffffffff816c80f0>] ? bit_wait_io_timeout+0x80/0x80
      [13706.658811]  [<ffffffff816c790e>] schedule+0x3e/0x90
      [13706.658813]  [<ffffffff816ca7e5>] schedule_timeout+0x1b5/0x210
      [13706.658816]  [<ffffffff81073ffb>] ? gup_pud_range+0x1db/0x1f0
      [13706.658817]  [<ffffffff810668fe>] ? kvm_clock_read+0x1e/0x20
      [13706.658819]  [<ffffffff81066909>] ? kvm_clock_get_cycles+0x9/0x10
      [13706.658822]  [<ffffffff810f5792>] ? ktime_get+0x52/0xc0
      [13706.658824]  [<ffffffff816c6f04>] io_schedule_timeout+0xa4/0x110
      [13706.658826]  [<ffffffff816c8126>] bit_wait_io+0x36/0x50
      [13706.658828]  [<ffffffff816c7d06>] __wait_on_bit_lock+0x76/0xb0
      [13706.658831]  [<ffffffffa0545636>] ? lock_request+0x46/0x70 [fuse]
      [13706.658834]  [<ffffffff8118800a>] __lock_page+0xaa/0xb0
      [13706.658836]  [<ffffffff810c8500>] ? wake_atomic_t_function+0x40/0x40
      [13706.658838]  [<ffffffff81194d08>] set_page_dirty_lock+0x58/0x60
      [13706.658841]  [<ffffffffa054d968>] fuse_release_user_pages+0x58/0x70 [fuse]
      [13706.658844]  [<ffffffffa0551430>] ? fuse_aio_complete+0x190/0x190 [fuse]
      [13706.658847]  [<ffffffffa0551459>] fuse_aio_complete_req+0x29/0x90 [fuse]
      [13706.658849]  [<ffffffffa05471e9>] request_end+0xd9/0x190 [fuse]
      [13706.658852]  [<ffffffffa0549126>] fuse_dev_do_write+0x336/0x490 [fuse]
      [13706.658854]  [<ffffffffa054963e>] fuse_dev_write+0x6e/0xa0 [fuse]
      [13706.658857]  [<ffffffff812a9ef3>] ? security_file_permission+0x23/0x90
      [13706.658859]  [<ffffffff81205300>] do_iter_readv_writev+0x60/0x90
      [13706.658862]  [<ffffffffa05495d0>] ? fuse_dev_splice_write+0x350/0x350
      [fuse]
      [13706.658863]  [<ffffffff812062a1>] do_readv_writev+0x171/0x1f0
      [13706.658866]  [<ffffffff810b3d00>] ? try_to_wake_up+0x210/0x210
      [13706.658868]  [<ffffffff81206361>] vfs_writev+0x41/0x50
      [13706.658870]  [<ffffffff81206496>] SyS_writev+0x56/0xf0
      [13706.658872]  [<ffffffff810257a1>] ? syscall_trace_leave+0xf1/0x160
      [13706.658874]  [<ffffffff816cbb2e>] system_call_fastpath+0x12/0x71
      
      Fix this by making should_dirty a fuse_io_priv parameter that can be
      checked in fuse_aio_complete_req().
      Reported-by: default avatarTiger Yang <tiger.yang@oracle.com>
      Signed-off-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b6a863f
    • Mark Syms's avatar
      CIFS: handle guest access errors to Windows shares · 22979776
      Mark Syms authored
      [ Upstream commit 40920c2b ]
      
      Commit 1a967d6c ("correctly to
      anonymous authentication for the NTLM(v2) authentication") introduces
      a regression in handling errors related to attempting a guest
      connection to a Windows share which requires authentication. This
      should result in a permission denied error but actually causes the
      kernel module to enter a never-ending loop trying to follow a DFS
      referal which doesn't exist.
      
      The base cause of this is the failure now occurs later in the process
      during tree connect and not at the session setup setup and all errors
      in tree connect are interpreted as needing to follow the DFS paths
      which isn't in this case correct. So, check the returned error against
      EACCES and fail if this is returned error.
      
      Feedback from Aurelien:
      
        PS> net user guest /activate:no
          PS> mkdir C:\guestshare
            PS> icacls C:\guestshare /grant 'Everyone:(OI)(CI)F'
              PS> new-smbshare -name guestshare -path C:\guestshare -fullaccess Everyone
      
              I've tested v3.10, v4.4, master, master+your patch using default options
              (empty or no user "NU") and user=abc (U).
      
              NT_LOGON_FAILURE in session setup: LF
              This is what you seem to have in 3.10.
      
              NT_ACCESS_DENIED in tree connect to the share: AD
              This is what you get before your infinite loop.
      
                           |   NU       U
                           --------------------------------
                           3.10         |   LF       LF
                           4.4          |   LF       LF
                           master       |   AD       LF
                           master+patch |   AD       LF
      
                           No infinite DFS loop :(
                           All these issues result in mount failing very fast with permission denied.
      
                           I guess it could be from either the Windows version or the share/folder
                           ACL. A deeper analysis of the packets might reveal more.
      
                           In any case I did not notice any issues for on a basic DFS setup with
                           the patch so I don't think it introduced any regressions, which is
                           probably all that matters. It still bothers me a little I couldn't hit
                           the bug.
      
                           I've included kernel output w/ debugging output and network capture of
                           my tests if anyone want to have a look at it. (master+patch = ml-guestfix).
      Signed-off-by: default avatarMark Syms <mark.syms@citrix.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Tested-by: default avatarAurelien Aptel <aaptel@suse.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22979776
    • Jeff Mahoney's avatar
      btrfs: don't create or leak aliased root while cleaning up orphans · c1504091
      Jeff Mahoney authored
      [ Upstream commit 35bbb97f ]
      
      commit 909c3a22 (Btrfs: fix loading of orphan roots leading to BUG_ON)
      avoids the BUG_ON but can add an aliased root to the dead_roots list or
      leak the root.
      
      Since we've already been loading roots into the radix tree, we should
      use it before looking the root up on disk.
      
      Cc: <stable@vger.kernel.org> # 4.5
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c1504091
  2. 20 Oct, 2018 2 commits
  3. 13 Oct, 2018 2 commits
  4. 10 Oct, 2018 8 commits
    • Ashish Samant's avatar
      ocfs2: fix locking for res->tracking and dlm->tracking_list · 20ba8a53
      Ashish Samant authored
      commit cbe355f57c8074bc4f452e5b6e35509044c6fa23 upstream.
      
      In dlm_init_lockres() we access and modify res->tracking and
      dlm->tracking_list without holding dlm->track_lock.  This can cause list
      corruptions and can end up in kernel panic.
      
      Fix this by locking res->tracking and dlm->tracking_list with
      dlm->track_lock instead of dlm->spinlock.
      
      Link: http://lkml.kernel.org/r/1529951192-4686-1-git-send-email-ashish.samant@oracle.comSigned-off-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Reviewed-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Acked-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Acked-by: default avatarJun Piao <piaojun@huawei.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <ge.changwei@h3c.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20ba8a53
    • Jann Horn's avatar
      proc: restrict kernel stack dumps to root · 57475707
      Jann Horn authored
      commit f8a00cef17206ecd1b30d3d9f99e10d9fa707aa7 upstream.
      
      Currently, you can use /proc/self/task/*/stack to cause a stack walk on
      a task you control while it is running on another CPU.  That means that
      the stack can change under the stack walker.  The stack walker does
      have guards against going completely off the rails and into random
      kernel memory, but it can interpret random data from your kernel stack
      as instruction pointers and stack pointers.  This can cause exposure of
      kernel stack contents to userspace.
      
      Restrict the ability to inspect kernel stacks of arbitrary tasks to root
      in order to prevent a local attacker from exploiting racy stack unwinding
      to leak kernel task stack contents.  See the added comment for a longer
      rationale.
      
      There don't seem to be any users of this userspace API that can't
      gracefully bail out if reading from the file fails.  Therefore, I believe
      that this change is unlikely to break things.  In the case that this patch
      does end up needing a revert, the next-best solution might be to fake a
      single-entry stack based on wchan.
      
      Link: http://lkml.kernel.org/r/20180927153316.200286-1-jannh@google.com
      Fixes: 2ec220e2 ("proc: add /proc/*/stack")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Ken Chen <kenchen@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57475707
    • Aurelien Aptel's avatar
      smb2: fix missing files in root share directory listing · ec2a4f06
      Aurelien Aptel authored
      commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.
      
      When mounting a Windows share that is the root of a drive (eg. C$)
      the server does not return . and .. directory entries. This results in
      the smb2 code path erroneously skipping the 2 first entries.
      
      Pseudo-code of the readdir() code path:
      
      cifs_readdir(struct file, struct dir_context)
          initiate_cifs_search            <-- if no reponse cached yet
              server->ops->query_dir_first
      
          dir_emit_dots
              dir_emit                    <-- adds "." and ".." if we're at pos=0
      
          find_cifs_entry
              initiate_cifs_search        <-- if pos < start of current response
                                               (restart search)
              server->ops->query_dir_next <-- if pos > end of current response
                                               (fetch next search res)
      
          for(...)                        <-- loops over cur response entries
                                                starting at pos
              cifs_filldir                <-- skip . and .., emit entry
                  cifs_fill_dirent
                  dir_emit
      	pos++
      
      A) dir_emit_dots() always adds . & ..
         and sets the current dir pos to 2 (0 and 1 are done).
      
      Therefore we always want the index_to_find to be 2 regardless of if
      the response has . and ..
      
      B) smb1 code initializes index_of_last_entry with a +2 offset
      
        in cifssmb.c CIFSFindFirst():
      		psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
      			psrch_inf->entries_in_buffer;
      
      Later in find_cifs_entry() we want to find the next dir entry at pos=2
      as a result of (A)
      
      	first_entry_in_buffer = cfile->srch_inf.index_of_last_entry -
      					cfile->srch_inf.entries_in_buffer;
      
      This var is the dir pos that the first entry in the buffer will
      have therefore it must be 2 in the first call.
      
      If we don't offset index_of_last_entry by 2 (like in (B)),
      first_entry_in_buffer=0 but we were instructed to get pos=2 so this
      code in find_cifs_entry() skips the 2 first which is ok for non-root
      shares, as it skips . and .. from the response but is not ok for root
      shares where the 2 first are actual files
      
      		pos_in_buf = index_to_find - first_entry_in_buffer;
                      // pos_in_buf=2
      		// we skip 2 first response entries :(
      		for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) {
      			/* go entry by entry figuring out which is first */
      			cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
      						cfile->srch_inf.info_level);
      		}
      
      C) cifs_filldir() skips . and .. so we can safely ignore them for now.
      
      Sample program:
      
      int main(int argc, char **argv)
      {
      	const char *path = argc >= 2 ? argv[1] : ".";
      	DIR *dh;
      	struct dirent *de;
      
      	printf("listing path <%s>\n", path);
      	dh = opendir(path);
      	if (!dh) {
      		printf("opendir error %d\n", errno);
      		return 1;
      	}
      
      	while (1) {
      		de = readdir(dh);
      		if (!de) {
      			if (errno) {
      				printf("readdir error %d\n", errno);
      				return 1;
      			}
      			printf("end of listing\n");
      			break;
      		}
      		printf("off=%lu <%s>\n", de->d_off, de->d_name);
      	}
      
      	return 0;
      }
      
      Before the fix with SMB1 on root shares:
      
      <.>            off=1
      <..>           off=2
      <$Recycle.Bin> off=3
      <bootmgr>      off=4
      
      and on non-root shares:
      
      <.>    off=1
      <..>   off=4  <-- after adding .., the offsets jumps to +2 because
      <2536> off=5       we skipped . and .. from response buffer (C)
      <411>  off=6       but still incremented pos
      <file> off=7
      <fsx>  off=8
      
      Therefore the fix for smb2 is to mimic smb1 behaviour and offset the
      index_of_last_entry by 2.
      
      Test results comparing smb1 and smb2 before/after the fix on root
      share, non-root shares and on large directories (ie. multi-response
      dir listing):
      
      PRE FIX
      =======
      pre-1-root VS pre-2-root:
              ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
      pre-1-nonroot VS pre-2-nonroot:
              OK~ same files, same order, different offsets
      pre-1-nonroot-large VS pre-2-nonroot-large:
              OK~ same files, same order, different offsets
      
      POST FIX
      ========
      post-1-root VS post-2-root:
              OK same files, same order, same offsets
      post-1-nonroot VS post-2-nonroot:
              OK same files, same order, same offsets
      post-1-nonroot-large VS post-2-nonroot-large:
              OK same files, same order, same offsets
      
      REGRESSION?
      ===========
      pre-1-root VS post-1-root:
              OK same files, same order, same offsets
      pre-1-nonroot VS post-1-nonroot:
              OK same files, same order, same offsets
      
      BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarPaulo Alcantara <palcantara@suse.deR>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec2a4f06
    • Dan Carpenter's avatar
      cifs: read overflow in is_valid_oplock_break() · cd65a43f
      Dan Carpenter authored
      [ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]
      
      We need to verify that the "data_offset" is within bounds.
      Reported-by: default avatarDr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd65a43f
    • Stephen Rothwell's avatar
      fs/cifs: suppress a string overflow warning · 8c47defa
      Stephen Rothwell authored
      [ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]
      
      A powerpc build of cifs with gcc v8.2.0 produces this warning:
      
      fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
      fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
         strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Since we are already doing a strlen() on the source, change the strncpy
      to a memcpy().
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c47defa
    • Jon Kuhn's avatar
      fs/cifs: don't translate SFM_SLASH (U+F026) to backslash · 2b2ccb29
      Jon Kuhn authored
      [ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]
      
      When a Mac client saves an item containing a backslash to a file server
      the backslash is represented in the CIFS/SMB protocol as as U+F026.
      Before this change, listing a directory containing an item with a
      backslash in its name will return that item with the backslash
      represented with a true backslash character (U+005C) because
      convert_sfm_character mapped U+F026 to U+005C when interpretting the
      CIFS/SMB protocol response.  However, attempting to open or stat the
      path using a true backslash will result in an error because
      convert_to_sfm_char does not map U+005C back to U+F026 causing the
      CIFS/SMB request to be made with the backslash represented as U+005C.
      
      This change simply prevents the U+F026 to U+005C conversion from
      happenning.  This is analogous to how the code does not do any
      translation of UNI_SLASH (U+F000).
      Signed-off-by: default avatarJon Kuhn <jkuhn@barracuda.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b2ccb29
    • Theodore Ts'o's avatar
      ext4: never move the system.data xattr out of the inode body · cd3d6463
      Theodore Ts'o authored
      commit 8cdb5240ec5928b20490a2bb34cb87e9a5f40226 upstream.
      
      When expanding the extra isize space, we must never move the
      system.data xattr out of the inode body.  For performance reasons, it
      doesn't make any sense, and the inline data implementation assumes
      that system.data xattr is never in the external xattr block.
      
      This addresses CVE-2018-10880
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200005Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarZubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd3d6463
    • J. Bruce Fields's avatar
      nfsd: fix corrupted reply to badly ordered compound · 953b51b7
      J. Bruce Fields authored
      [ Upstream commit 5b7b15aee641904ae269be9846610a3950cbd64c ]
      
      We're encoding a single op in the reply but leaving the number of ops
      zero, so the reply makes no sense.
      
      Somewhat academic as this isn't a case any real client will hit, though
      in theory perhaps that could change in a future protocol extension.
      Reviewed-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      953b51b7
  5. 29 Sep, 2018 6 commits
    • Li Dongyang's avatar
      ext4: don't mark mmp buffer head dirty · e77dd99d
      Li Dongyang authored
      commit fe18d649891d813964d3aaeebad873f281627fbc upstream.
      
      Marking mmp bh dirty before writing it will make writeback
      pick up mmp block later and submit a write, we don't want the
      duplicate write as kmmpd thread should have full control of
      reading and writing the mmp block.
      Another reason is we will also have random I/O error on
      the writeback request when blk integrity is enabled, because
      kmmpd could modify the content of the mmp block(e.g. setting
      new seq and time) while the mmp block is under I/O requested
      by writeback.
      Signed-off-by: default avatarLi Dongyang <dongyangli@ddn.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e77dd99d
    • Theodore Ts'o's avatar
      ext4: fix online resizing for bigalloc file systems with a 1k block size · 47af9976
      Theodore Ts'o authored
      commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream.
      
      An online resize of a file system with the bigalloc feature enabled
      and a 1k block size would be refused since ext4_resize_begin() did not
      understand s_first_data_block is 0 for all bigalloc file systems, even
      when the block size is 1k.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47af9976
    • Theodore Ts'o's avatar
      ext4: fix online resize's handling of a too-small final block group · 70083af5
      Theodore Ts'o authored
      commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.
      
      Avoid growing the file system to an extent so that the last block
      group is too small to hold all of the metadata that must be stored in
      the block group.
      
      This problem can be triggered with the following reproducer:
      
      umount /mnt
      mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
      	-E resize=1073741824 /tmp/foo.img 128M
      mount /tmp/foo.img /mnt
      truncate --size 1708M /tmp/foo.img
      resize2fs /dev/loop0 295400
      umount /mnt
      e2fsck -fy /tmp/foo.img
      Reported-by: default avatarTorsten Hilbrich <torsten.hilbrich@secunet.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70083af5
    • Theodore Ts'o's avatar
      ext4: recalucate superblock checksum after updating free blocks/inodes · 66671ee8
      Theodore Ts'o authored
      commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.
      
      When mounting the superblock, ext4_fill_super() calculates the free
      blocks and free inodes and stores them in the superblock.  It's not
      strictly necessary, since we don't use them any more, but it's nice to
      keep them roughly aligned to reality.
      
      Since it's not critical for file system correctness, the code doesn't
      call ext4_commit_super().  The problem is that it's in
      ext4_commit_super() that we recalculate the superblock checksum.  So
      if we're not going to call ext4_commit_super(), we need to call
      ext4_superblock_csum_set() to make sure the superblock checksum is
      consistent.
      
      Most of the time, this doesn't matter, since we end up calling
      ext4_commit_super() very soon thereafter, and definitely by the time
      the file system is unmounted.  However, it doesn't work in this
      sequence:
      
      mke2fs -Fq -t ext4 /dev/vdc 128M
      mount /dev/vdc /vdc
      cp xfstests/git-versions /vdc
      godown /vdc
      umount /vdc
      mount /dev/vdc
      tune2fs -l /dev/vdc
      
      With this commit, the "tune2fs -l" no longer fails.
      Reported-by: default avatarChengguang Xu <cgxu519@gmx.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66671ee8
    • Theodore Ts'o's avatar
      ext4: avoid divide by zero fault when deleting corrupted inline directories · 7619c7f6
      Theodore Ts'o authored
      commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream.
      
      A specially crafted file system can trick empty_inline_dir() into
      reading past the last valid entry in a inline directory, and then run
      into the end of xattr marker. This will trigger a divide by zero
      fault.  Fix this by using the size of the inline directory instead of
      dir->i_size.
      
      Also clean up error reporting in __ext4_check_dir_entry so that the
      message is clearer and more understandable --- and avoids the division
      by zero trap if the size passed in is zero.  (I'm not sure why we
      coded it that way in the first place; printing offset % size is
      actually more confusing and less useful.)
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200933Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reported-by: default avatarWen Xu <wen.xu@gatech.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7619c7f6
    • Junxiao Bi's avatar
      ocfs2: fix ocfs2 read block panic · 98e14c52
      Junxiao Bi authored
      commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream.
      
      While reading block, it is possible that io error return due to underlying
      storage issue, in this case, BH_NeedsValidate was left in the buffer head.
      Then when reading the very block next time, if it was already linked into
      journal, that will trigger the following panic.
      
      [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!
      [203748.702533] invalid opcode: 0000 [#1] SMP
      [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod
      [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2
      [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015
      [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000
      [203748.703088] RIP: 0010:[<ffffffffa05e9f09>]  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
      [203748.703130] RSP: 0018:ffff88006ff4b818  EFLAGS: 00010206
      [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000
      [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe
      [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0
      [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000
      [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000
      [203748.705871] FS:  00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000
      [203748.706370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670
      [203748.707124] Stack:
      [203748.707371]  ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001
      [203748.707885]  0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00
      [203748.708399]  00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000
      [203748.708915] Call Trace:
      [203748.709175]  [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
      [203748.709680]  [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]
      [203748.710185]  [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]
      [203748.710691]  [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]
      [203748.711204]  [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]
      [203748.711716]  [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]
      [203748.712227]  [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]
      [203748.712737]  [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]
      [203748.713003]  [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]
      [203748.713263]  [<ffffffff8121714b>] vfs_create+0xdb/0x150
      [203748.713518]  [<ffffffff8121b225>] do_last+0x815/0x1210
      [203748.713772]  [<ffffffff812192e9>] ? path_init+0xb9/0x450
      [203748.714123]  [<ffffffff8121bca0>] path_openat+0x80/0x600
      [203748.714378]  [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620
      [203748.714634]  [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0
      [203748.714888]  [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130
      [203748.715143]  [<ffffffff81209ffc>] do_sys_open+0x12c/0x220
      [203748.715403]  [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180
      [203748.715668]  [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190
      [203748.715928]  [<ffffffff8120a10e>] SyS_open+0x1e/0x20
      [203748.716184]  [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7
      [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10
      [203748.717505] RIP  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
      [203748.717775]  RSP <ffff88006ff4b818>
      
      Joesph ever reported a similar panic.
      Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html
      
      Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.comSigned-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Changwei Ge <ge.changwei@h3c.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98e14c52
  6. 26 Sep, 2018 5 commits
    • Maciej W. Rozycki's avatar
      binfmt_elf: Respect error return from `regset->active' · 0b726a48
      Maciej W. Rozycki authored
      [ Upstream commit 2f819db565e82e5f73cd42b39925098986693378 ]
      
      The regset API documented in <linux/regset.h> defines -ENODEV as the
      result of the `->active' handler to be used where the feature requested
      is not available on the hardware found.  However code handling core file
      note generation in `fill_thread_core_info' interpretes any non-zero
      result from the `->active' handler as the regset requested being active.
      Consequently processing continues (and hopefully gracefully fails later
      on) rather than being abandoned right away for the regset requested.
      
      Fix the problem then by making the code proceed only if a positive
      result is returned from the `->active' handler.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 4206d3aa ("elf core dump: notes user_regset")
      Patchwork: https://patchwork.linux-mips.org/patch/19332/
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b726a48
    • Dan Carpenter's avatar
      CIFS: fix wrapping bugs in num_entries() · 74fb4686
      Dan Carpenter authored
      commit 56446f218af1133c802dad8e9e116f07f381846c upstream.
      
      The problem is that "entryptr + next_offset" and "entryptr + len + size"
      can wrap.  I ended up changing the type of "entryptr" because it makes
      the math easier when we don't have to do so much casting.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74fb4686
    • Dan Carpenter's avatar
      cifs: prevent integer overflow in nxt_dir_entry() · 2d363196
      Dan Carpenter authored
      commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream.
      
      The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap
      around so I have added a check for integer overflow.
      Reported-by: default avatarDr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d363196
    • Bin Yang's avatar
      pstore: Fix incorrect persistent ram buffer mapping · 1cd01dba
      Bin Yang authored
      commit 831b624df1b420c8f9281ed1307a8db23afb72df upstream.
      
      persistent_ram_vmap() returns the page start vaddr.
      persistent_ram_iomap() supports non-page-aligned mapping.
      
      persistent_ram_buffer_map() always adds offset-in-page to the vaddr
      returned from these two functions, which causes incorrect mapping of
      non-page-aligned persistent ram buffer.
      
      By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without
      this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which
      might not be page aligned. If the offset-in-page > 2048, the vaddr will be
      in next page. If the next page is not mapped, it will cause kernel panic:
      
      [    0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000
      ...
      [    0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f
      ...
      [    0.075000] Call Trace:
      [    0.075000]  ramoops_init_przs.part.10.constprop.15+0x105/0x260
      [    0.075000]  ramoops_probe+0x232/0x3a0
      [    0.075000]  platform_drv_probe+0x3e/0xa0
      [    0.075000]  driver_probe_device+0x2cd/0x400
      [    0.075000]  __driver_attach+0xe4/0x110
      [    0.075000]  ? driver_probe_device+0x400/0x400
      [    0.075000]  bus_for_each_dev+0x70/0xa0
      [    0.075000]  driver_attach+0x1e/0x20
      [    0.075000]  bus_add_driver+0x159/0x230
      [    0.075000]  ? do_early_param+0x95/0x95
      [    0.075000]  driver_register+0x70/0xc0
      [    0.075000]  ? init_pstore_fs+0x4d/0x4d
      [    0.075000]  __platform_driver_register+0x36/0x40
      [    0.075000]  ramoops_init+0x12f/0x131
      [    0.075000]  do_one_initcall+0x4d/0x12c
      [    0.075000]  ? do_early_param+0x95/0x95
      [    0.075000]  kernel_init_freeable+0x19b/0x222
      [    0.075000]  ? rest_init+0xbb/0xbb
      [    0.075000]  kernel_init+0xe/0xfc
      [    0.075000]  ret_from_fork+0x3a/0x50
      Signed-off-by: default avatarBin Yang <bin.yang@intel.com>
      [kees: add comments describing the mapping differences, updated commit log]
      Fixes: 24c3d2f3 ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cd01dba
    • Andreas Gruenbacher's avatar
      gfs2: Special-case rindex for gfs2_grow · 9e8d585c
      Andreas Gruenbacher authored
      [ Upstream commit 776125785a87ff05d49938bd5b9f336f2a05bff6 ]
      
      To speed up the common case of appending to a file,
      gfs2_write_alloc_required presumes that writing beyond the end of a file
      will always require additional blocks to be allocated.  This assumption
      is incorrect for preallocates files, but there are no negative
      consequences as long as *some* space is still left on the filesystem.
      
      One special file that always has some space preallocated beyond the end
      of the file is the rindex: when growing a filesystem, gfs2_grow adds one
      or more new resource groups and appends records describing those
      resource groups to the rindex; the preallocated space ensures that this
      is always possible.
      
      However, when a filesystem is completely full, gfs2_write_alloc_required
      will indicate that an additional allocation is required, and appending
      the next record to the rindex will fail even though space for that
      record has already been preallocated.  To fix that, skip the incorrect
      optimization in gfs2_write_alloc_required, but for the rindex only.
      Other writes to preallocated space beyond the end of the file are still
      allowed to fail on completely full filesystems.
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Reviewed-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e8d585c
  7. 19 Sep, 2018 4 commits
    • Ian Kent's avatar
      autofs: fix autofs_sbi() does not check super block type · 4bdac252
      Ian Kent authored
      commit 0633da48f0793aeba27f82d30605624416723a91 upstream.
      
      autofs_sbi() does not check the superblock magic number to verify it has
      been given an autofs super block.
      
      Backport Note: autofs4 has been renamed to autofs upstream. As a result
      the upstream patch does not apply cleanly onto 4.14.y.
      
      Link: http://lkml.kernel.org/r/153475422934.17131.7563724552005298277.stgit@pluto.themaw.net
      Reported-by: <syzbot+87c3c541582e56943277@syzkaller.appspotmail.com>
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarZubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bdac252
    • Chao Yu's avatar
      f2fs: fix to do sanity check with {sit,nat}_ver_bitmap_bytesize · e498af87
      Chao Yu authored
      [ Upstream commit c77ec61ca0a49544ca81881cc5d5529858f7e196 ]
      
      This patch adds to do sanity check with {sit,nat}_ver_bitmap_bytesize
      during mount, in order to avoid accessing across cache boundary with
      this abnormal bitmap size.
      
      - Overview
      buffer overrun in build_sit_info() when mounting a crafted f2fs image
      
      - Reproduce
      
      - Kernel message
      [  548.580867] F2FS-fs (loop0): Invalid log blocks per segment (8201)
      
      [  548.580877] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
      [  548.584979] ==================================================================
      [  548.586568] BUG: KASAN: use-after-free in kmemdup+0x36/0x50
      [  548.587715] Read of size 64 at addr ffff8801e9c265ff by task mount/1295
      
      [  548.589428] CPU: 1 PID: 1295 Comm: mount Not tainted 4.18.0-rc1+ #4
      [  548.589432] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  548.589438] Call Trace:
      [  548.589474]  dump_stack+0x7b/0xb5
      [  548.589487]  print_address_description+0x70/0x290
      [  548.589492]  kasan_report+0x291/0x390
      [  548.589496]  ? kmemdup+0x36/0x50
      [  548.589509]  check_memory_region+0x139/0x190
      [  548.589514]  memcpy+0x23/0x50
      [  548.589518]  kmemdup+0x36/0x50
      [  548.589545]  f2fs_build_segment_manager+0x8fa/0x3410
      [  548.589551]  ? __asan_loadN+0xf/0x20
      [  548.589560]  ? f2fs_sanity_check_ckpt+0x1be/0x240
      [  548.589566]  ? f2fs_flush_sit_entries+0x10c0/0x10c0
      [  548.589587]  ? __put_user_ns+0x40/0x40
      [  548.589604]  ? find_next_bit+0x57/0x90
      [  548.589610]  f2fs_fill_super+0x194b/0x2b40
      [  548.589617]  ? f2fs_commit_super+0x1b0/0x1b0
      [  548.589637]  ? set_blocksize+0x90/0x140
      [  548.589651]  mount_bdev+0x1c5/0x210
      [  548.589655]  ? f2fs_commit_super+0x1b0/0x1b0
      [  548.589667]  f2fs_mount+0x15/0x20
      [  548.589672]  mount_fs+0x60/0x1a0
      [  548.589683]  ? alloc_vfsmnt+0x309/0x360
      [  548.589688]  vfs_kern_mount+0x6b/0x1a0
      [  548.589699]  do_mount+0x34a/0x18c0
      [  548.589710]  ? lockref_put_or_lock+0xcf/0x160
      [  548.589716]  ? copy_mount_string+0x20/0x20
      [  548.589728]  ? memcg_kmem_put_cache+0x1b/0xa0
      [  548.589734]  ? kasan_check_write+0x14/0x20
      [  548.589740]  ? _copy_from_user+0x6a/0x90
      [  548.589744]  ? memdup_user+0x42/0x60
      [  548.589750]  ksys_mount+0x83/0xd0
      [  548.589755]  __x64_sys_mount+0x67/0x80
      [  548.589781]  do_syscall_64+0x78/0x170
      [  548.589797]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  548.589820] RIP: 0033:0x7f76fc331b9a
      [  548.589821] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
      [  548.589880] RSP: 002b:00007ffd4f0a0e48 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
      [  548.589890] RAX: ffffffffffffffda RBX: 000000000146c030 RCX: 00007f76fc331b9a
      [  548.589892] RDX: 000000000146c210 RSI: 000000000146df30 RDI: 0000000001474ec0
      [  548.589895] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
      [  548.589897] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000000001474ec0
      [  548.589900] R13: 000000000146c210 R14: 0000000000000000 R15: 0000000000000003
      
      [  548.590242] The buggy address belongs to the page:
      [  548.591243] page:ffffea0007a70980 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      [  548.592886] flags: 0x2ffff0000000000()
      [  548.593665] raw: 02ffff0000000000 dead000000000100 dead000000000200 0000000000000000
      [  548.595258] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [  548.603713] page dumped because: kasan: bad access detected
      
      [  548.605203] Memory state around the buggy address:
      [  548.606198]  ffff8801e9c26480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  548.607676]  ffff8801e9c26500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  548.609157] >ffff8801e9c26580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  548.610629]                                                                 ^
      [  548.612088]  ffff8801e9c26600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  548.613674]  ffff8801e9c26680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  548.615141] ==================================================================
      [  548.616613] Disabling lock debugging due to kernel taint
      [  548.622871] WARNING: CPU: 1 PID: 1295 at mm/page_alloc.c:4065 __alloc_pages_slowpath+0xe4a/0x1420
      [  548.622878] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
      [  548.623217] CPU: 1 PID: 1295 Comm: mount Tainted: G    B             4.18.0-rc1+ #4
      [  548.623219] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  548.623226] RIP: 0010:__alloc_pages_slowpath+0xe4a/0x1420
      [  548.623227] Code: ff ff 01 89 85 c8 fe ff ff e9 91 fc ff ff 41 89 c5 e9 5c fc ff ff 0f 0b 89 f8 25 ff ff f7 ff 89 85 8c fe ff ff e9 d5 f2 ff ff <0f> 0b e9 65 f2 ff ff 65 8b 05 38 81 d2 47 f6 c4 01 74 1c 65 48 8b
      [  548.623281] RSP: 0018:ffff8801f28c7678 EFLAGS: 00010246
      [  548.623284] RAX: 0000000000000000 RBX: 00000000006040c0 RCX: ffffffffb82f73b7
      [  548.623287] RDX: 1ffff1003e518eeb RSI: 000000000000000c RDI: 0000000000000000
      [  548.623290] RBP: ffff8801f28c7880 R08: 0000000000000000 R09: ffffed0047fff2c5
      [  548.623292] R10: 0000000000000001 R11: ffffed0047fff2c4 R12: ffff8801e88de040
      [  548.623295] R13: 00000000006040c0 R14: 000000000000000c R15: ffff8801f28c7938
      [  548.623299] FS:  00007f76fca51840(0000) GS:ffff8801f6f00000(0000) knlGS:0000000000000000
      [  548.623302] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  548.623304] CR2: 00007f19b9171760 CR3: 00000001ed952000 CR4: 00000000000006e0
      [  548.623317] Call Trace:
      [  548.623325]  ? kasan_check_read+0x11/0x20
      [  548.623330]  ? __zone_watermark_ok+0x92/0x240
      [  548.623336]  ? get_page_from_freelist+0x1c3/0x1d90
      [  548.623347]  ? _raw_spin_lock_irqsave+0x2a/0x60
      [  548.623353]  ? warn_alloc+0x250/0x250
      [  548.623358]  ? save_stack+0x46/0xd0
      [  548.623361]  ? kasan_kmalloc+0xad/0xe0
      [  548.623366]  ? __isolate_free_page+0x2a0/0x2a0
      [  548.623370]  ? mount_fs+0x60/0x1a0
      [  548.623374]  ? vfs_kern_mount+0x6b/0x1a0
      [  548.623378]  ? do_mount+0x34a/0x18c0
      [  548.623383]  ? ksys_mount+0x83/0xd0
      [  548.623387]  ? __x64_sys_mount+0x67/0x80
      [  548.623391]  ? do_syscall_64+0x78/0x170
      [  548.623396]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  548.623401]  __alloc_pages_nodemask+0x3c5/0x400
      [  548.623407]  ? __alloc_pages_slowpath+0x1420/0x1420
      [  548.623412]  ? __mutex_lock_slowpath+0x20/0x20
      [  548.623417]  ? kvmalloc_node+0x31/0x80
      [  548.623424]  alloc_pages_current+0x75/0x110
      [  548.623436]  kmalloc_order+0x24/0x60
      [  548.623442]  kmalloc_order_trace+0x24/0xb0
      [  548.623448]  __kmalloc_track_caller+0x207/0x220
      [  548.623455]  ? f2fs_build_node_manager+0x399/0xbb0
      [  548.623460]  kmemdup+0x20/0x50
      [  548.623465]  f2fs_build_node_manager+0x399/0xbb0
      [  548.623470]  f2fs_fill_super+0x195e/0x2b40
      [  548.623477]  ? f2fs_commit_super+0x1b0/0x1b0
      [  548.623481]  ? set_blocksize+0x90/0x140
      [  548.623486]  mount_bdev+0x1c5/0x210
      [  548.623489]  ? f2fs_commit_super+0x1b0/0x1b0
      [  548.623495]  f2fs_mount+0x15/0x20
      [  548.623498]  mount_fs+0x60/0x1a0
      [  548.623503]  ? alloc_vfsmnt+0x309/0x360
      [  548.623508]  vfs_kern_mount+0x6b/0x1a0
      [  548.623513]  do_mount+0x34a/0x18c0
      [  548.623518]  ? lockref_put_or_lock+0xcf/0x160
      [  548.623523]  ? copy_mount_string+0x20/0x20
      [  548.623528]  ? memcg_kmem_put_cache+0x1b/0xa0
      [  548.623533]  ? kasan_check_write+0x14/0x20
      [  548.623537]  ? _copy_from_user+0x6a/0x90
      [  548.623542]  ? memdup_user+0x42/0x60
      [  548.623547]  ksys_mount+0x83/0xd0
      [  548.623552]  __x64_sys_mount+0x67/0x80
      [  548.623557]  do_syscall_64+0x78/0x170
      [  548.623562]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  548.623566] RIP: 0033:0x7f76fc331b9a
      [  548.623567] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
      [  548.623632] RSP: 002b:00007ffd4f0a0e48 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
      [  548.623636] RAX: ffffffffffffffda RBX: 000000000146c030 RCX: 00007f76fc331b9a
      [  548.623639] RDX: 000000000146c210 RSI: 000000000146df30 RDI: 0000000001474ec0
      [  548.623641] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
      [  548.623643] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000000001474ec0
      [  548.623646] R13: 000000000146c210 R14: 0000000000000000 R15: 0000000000000003
      [  548.623650] ---[ end trace 4ce02f25ff7d3df5 ]---
      [  548.623656] F2FS-fs (loop0): Failed to initialize F2FS node manager
      [  548.627936] F2FS-fs (loop0): Invalid log blocks per segment (8201)
      
      [  548.627940] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
      [  548.635835] F2FS-fs (loop0): Failed to initialize F2FS node manager
      
      - Location
      https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/segment.c#L3578
      
      	sit_i->sit_bitmap = kmemdup(src_bitmap, bitmap_size, GFP_KERNEL);
      
      Buffer overrun happens when doing memcpy. I suspect there is missing (inconsistent) checks on bitmap_size.
      
      Reported by Wen Xu (wen.xu@gatech.edu) from SSLab, Gatech.
      Reported-by: default avatarWen Xu <wen.xu@gatech.edu>
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e498af87
    • Olga Kornievskaia's avatar
      NFSv4.0 fix client reference leak in callback · 2d926fe3
      Olga Kornievskaia authored
      [ Upstream commit 32cd3ee511f4e07ca25d71163b50e704808d22f4 ]
      
      If there is an error during processing of a callback message, it leads
      to refrence leak on the client structure and eventually an unclean
      superblock.
      Signed-off-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d926fe3
    • Yunlong Song's avatar
      f2fs: do not set free of current section · f5be08ed
      Yunlong Song authored
      [ Upstream commit 3611ce9911267cb93d364bd71ddea6821278d11f ]
      
      For the case when sbi->segs_per_sec > 1, take section:segment = 5 for
      example, if segment 1 is just used and allocate new segment 2, and the
      blocks of segment 1 is invalidated, at this time, the previous code will
      use __set_test_and_free to free the free_secmap and free_sections++,
      this is not correct since it is still a current section, so fix it.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5be08ed
  8. 15 Sep, 2018 10 commits
    • Ethan Lien's avatar
      btrfs: use correct compare function of dirty_metadata_bytes · a632d2d1
      Ethan Lien authored
      commit d814a49198eafa6163698bdd93961302f3a877a4 upstream.
      
      We use customized, nodesize batch value to update dirty_metadata_bytes.
      We should also use batch version of compare function or we will easily
      goto fast path and get false result from percpu_counter_compare().
      
      Fixes: e2d84521 ("Btrfs: use percpu counter for dirty metadata count")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarEthan Lien <ethanlien@synology.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      nb: Rebased on 4.4.y ]
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a632d2d1
    • Miklos Szeredi's avatar
      ovl: proper cleanup of workdir · 89f15c6e
      Miklos Szeredi authored
      commit eea2fb48 upstream.
      
      When mounting overlayfs it needs a clean "work" directory under the
      supplied workdir.
      
      Previously the mount code removed this directory if it already existed and
      created a new one.  If the removal failed (e.g. directory was not empty)
      then it fell back to a read-only mount not using the workdir.
      
      While this has never been reported, it is possible to get a non-empty
      "work" dir from a previous mount of overlayfs in case of crash in the
      middle of an operation using the work directory.
      
      In this case the left over state should be discarded and the overlay
      filesystem will be consistent, guaranteed by the atomicity of operations on
      moving to/from the workdir to the upper layer.
      
      This patch implements cleaning out any files left in workdir.  It is
      implemented using real recursion for simplicity, but the depth is limited
      to 2, because the worst case is that of a directory containing whiteouts
      under "work".
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89f15c6e
    • Antonio Murdaca's avatar
      ovl: override creds with the ones from the superblock mounter · 121b09d3
      Antonio Murdaca authored
      commit 3fe6e52f upstream.
      
      In user namespace the whiteout creation fails with -EPERM because the
      current process isn't capable(CAP_SYS_ADMIN) when setting xattr.
      
      A simple reproducer:
      
      $ mkdir upper lower work merged lower/dir
      $ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged
      $ unshare -m -p -f -U -r bash
      
      Now as root in the user namespace:
      
      \# touch merged/dir/{1,2,3} # this will force a copy up of lower/dir
      \# rm -fR merged/*
      
      This ends up failing with -EPERM after the files in dir has been
      correctly deleted:
      
      unlinkat(4, "2", 0)                     = 0
      unlinkat(4, "1", 0)                     = 0
      unlinkat(4, "3", 0)                     = 0
      close(4)                                = 0
      unlinkat(AT_FDCWD, "merged/dir", AT_REMOVEDIR) = -1 EPERM (Operation not
      permitted)
      
      Interestingly, if you don't place files in merged/dir you can remove it,
      meaning if upper/dir does not exist, creating the char device file works
      properly in that same location.
      
      This patch uses ovl_sb_creator_cred() to get the cred struct from the
      superblock mounter and override the old cred with these new ones so that
      the whiteout creation is possible because overlay is wrong in assuming that
      the creds it will get with prepare_creds will be in the initial user
      namespace.  The old cap_raise game is removed in favor of just overriding
      the old cred struct.
      
      This patch also drops from ovl_copy_up_one() the following two lines:
      
      override_cred->fsuid = stat->uid;
      override_cred->fsgid = stat->gid;
      
      This is because the correct uid and gid are taken directly with the stat
      struct and correctly set with ovl_set_attr().
      Signed-off-by: default avatarAntonio Murdaca <runcom@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      121b09d3
    • Miklos Szeredi's avatar
      ovl: rename is_merge to is_lowest · 6586f61a
      Miklos Szeredi authored
      commit 56656e96 upstream.
      
      The 'is_merge' is an historical naming from when only a single lower layer
      could exist.  With the introduction of multiple lower layers the meaning of
      this flag was changed to mean only the "lowest layer" (while all lower
      layers were being merged).
      
      So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6586f61a
    • Qu Wenruo's avatar
      btrfs: Don't remove block group that still has pinned down bytes · 02e48c4d
      Qu Wenruo authored
      [ Upstream commit 43794446548730ac8461be30bbe47d5d027d1d16 ]
      
      [BUG]
      Under certain KVM load and LTP tests, it is possible to hit the
      following calltrace if quota is enabled:
      
      BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
      BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
      
      WARNING: CPU: 0 PID: 49 at ../block/blk-core.c:172 blk_status_to_errno+0x1a/0x30
      CPU: 0 PID: 49 Comm: kworker/u2:1 Not tainted 4.12.14-15-default #1 SLE15 (unreleased)
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
      task: ffff9f827b340bc0 task.stack: ffffb4f8c0304000
      RIP: 0010:blk_status_to_errno+0x1a/0x30
      Call Trace:
       submit_extent_page+0x191/0x270 [btrfs]
       ? btrfs_create_repair_bio+0x130/0x130 [btrfs]
       __do_readpage+0x2d2/0x810 [btrfs]
       ? btrfs_create_repair_bio+0x130/0x130 [btrfs]
       ? run_one_async_done+0xc0/0xc0 [btrfs]
       __extent_read_full_page+0xe7/0x100 [btrfs]
       ? run_one_async_done+0xc0/0xc0 [btrfs]
       read_extent_buffer_pages+0x1ab/0x2d0 [btrfs]
       ? run_one_async_done+0xc0/0xc0 [btrfs]
       btree_read_extent_buffer_pages+0x94/0xf0 [btrfs]
       read_tree_block+0x31/0x60 [btrfs]
       read_block_for_search.isra.35+0xf0/0x2e0 [btrfs]
       btrfs_search_slot+0x46b/0xa00 [btrfs]
       ? kmem_cache_alloc+0x1a8/0x510
       ? btrfs_get_token_32+0x5b/0x120 [btrfs]
       find_parent_nodes+0x11d/0xeb0 [btrfs]
       ? leaf_space_used+0xb8/0xd0 [btrfs]
       ? btrfs_leaf_free_space+0x49/0x90 [btrfs]
       ? btrfs_find_all_roots_safe+0x93/0x100 [btrfs]
       btrfs_find_all_roots_safe+0x93/0x100 [btrfs]
       btrfs_find_all_roots+0x45/0x60 [btrfs]
       btrfs_qgroup_trace_extent_post+0x20/0x40 [btrfs]
       btrfs_add_delayed_data_ref+0x1a3/0x1d0 [btrfs]
       btrfs_alloc_reserved_file_extent+0x38/0x40 [btrfs]
       insert_reserved_file_extent.constprop.71+0x289/0x2e0 [btrfs]
       btrfs_finish_ordered_io+0x2f4/0x7f0 [btrfs]
       ? pick_next_task_fair+0x2cd/0x530
       ? __switch_to+0x92/0x4b0
       btrfs_worker_helper+0x81/0x300 [btrfs]
       process_one_work+0x1da/0x3f0
       worker_thread+0x2b/0x3f0
       ? process_one_work+0x3f0/0x3f0
       kthread+0x11a/0x130
       ? kthread_create_on_node+0x40/0x40
       ret_from_fork+0x35/0x40
      
      BTRFS critical (device vda2): unable to find logical 8820195328 length 16384
      BTRFS: error (device vda2) in btrfs_finish_ordered_io:3023: errno=-5 IO failure
      BTRFS info (device vda2): forced readonly
      BTRFS error (device vda2): pending csums is 2887680
      
      [CAUSE]
      It's caused by race with block group auto removal:
      
      - There is a meta block group X, which has only one tree block
        The tree block belongs to fs tree 257.
      - In current transaction, some operation modified fs tree 257
        The tree block gets COWed, so the block group X is empty, and marked
        as unused, queued to be deleted.
      - Some workload (like fsync) wakes up cleaner_kthread()
        Which will call btrfs_delete_unused_bgs() to remove unused block
        groups.
        So block group X along its chunk map get removed.
      - Some delalloc work finished for fs tree 257
        Quota needs to get the original reference of the extent, which will
        read tree blocks of commit root of 257.
        Then since the chunk map gets removed, the above warning gets
        triggered.
      
      [FIX]
      Just let btrfs_delete_unused_bgs() skip block group which still has
      pinned bytes.
      
      However there is a minor side effect: currently we only queue empty
      blocks at update_block_group(), and such empty block group with pinned
      bytes won't go through update_block_group() again, such block group
      won't be removed, until it gets new extent allocated and removed.
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02e48c4d
    • Qu Wenruo's avatar
      btrfs: relocation: Only remove reloc rb_trees if reloc control has been initialized · 510825b3
      Qu Wenruo authored
      [ Upstream commit 389305b2aa68723c754f88d9dbd268a400e10664 ]
      
      Invalid reloc tree can cause kernel NULL pointer dereference when btrfs
      does some cleanup of the reloc roots.
      
      It turns out that fs_info::reloc_ctl can be NULL in
      btrfs_recover_relocation() as we allocate relocation control after all
      reloc roots have been verified.
      So when we hit: note, we haven't called set_reloc_control() thus
      fs_info::reloc_ctl is still NULL.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=199833Reported-by: default avatarXu Wen <wen.xu@gatech.edu>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Tested-by: default avatarGu Jinxiang <gujx@cn.fujitsu.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      510825b3
    • Misono Tomohiro's avatar
      btrfs: replace: Reset on-disk dev stats value after replace · accb3e42
      Misono Tomohiro authored
      [ Upstream commit 1e7e1f9e3aba00c9b9c323bfeeddafe69ff21ff6 ]
      
      on-disk devs stats value is updated in btrfs_run_dev_stats(),
      which is called during commit transaction, if device->dev_stats_ccnt
      is not zero.
      
      Since current replace operation does not touch dev_stats_ccnt,
      on-disk dev stats value is not updated. Therefore "btrfs device stats"
      may return old device's value after umount/mount
      (Example: See "btrfs ins dump-t -t DEV $DEV" after btrfs/100 finish).
      
      Fix this by just incrementing dev_stats_ccnt in
      btrfs_dev_replace_finishing() when replace is succeeded and this will
      update the values.
      Signed-off-by: default avatarMisono Tomohiro <misono.tomohiro@jp.fujitsu.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      accb3e42
    • Steve French's avatar
      SMB3: Number of requests sent should be displayed for SMB3 not just CIFS · a9997f88
      Steve French authored
      [ Upstream commit 289131e1f1e6ad8c661ec05e176b8f0915672059 ]
      
      For SMB2/SMB3 the number of requests sent was not displayed
      in /proc/fs/cifs/Stats unless CONFIG_CIFS_STATS2 was
      enabled (only number of failed requests displayed). As
      with earlier dialects, we should be displaying these
      counters if CONFIG_CIFS_STATS is enabled. They
      are important for debugging.
      
      e.g. when you cat /proc/fs/cifs/Stats (before the patch)
      Resources in use
      CIFS Session: 1
      Share (unique mount targets): 2
      SMB Request/Response Buffer: 1 Pool size: 5
      SMB Small Req/Resp Buffer: 1 Pool size: 30
      Operations (MIDs): 0
      
      0 session 0 share reconnects
      Total vfs operations: 690 maximum at one time: 2
      
      1) \\localhost\test
      SMBs: 975
      Negotiates: 0 sent 0 failed
      SessionSetups: 0 sent 0 failed
      Logoffs: 0 sent 0 failed
      TreeConnects: 0 sent 0 failed
      TreeDisconnects: 0 sent 0 failed
      Creates: 0 sent 2 failed
      Closes: 0 sent 0 failed
      Flushes: 0 sent 0 failed
      Reads: 0 sent 0 failed
      Writes: 0 sent 0 failed
      Locks: 0 sent 0 failed
      IOCTLs: 0 sent 1 failed
      Cancels: 0 sent 0 failed
      Echos: 0 sent 0 failed
      QueryDirectories: 0 sent 63 failed
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9997f88
    • Steve French's avatar
      smb3: fix reset of bytes read and written stats · d6773f40
      Steve French authored
      [ Upstream commit c281bc0c7412308c7ec0888904f7c99353da4796 ]
      
      echo 0 > /proc/fs/cifs/Stats is supposed to reset the stats
      but there were four (see example below) that were not reset
      (bytes read and witten, total vfs ops and max ops
      at one time).
      
      ...
      0 session 0 share reconnects
      Total vfs operations: 100 maximum at one time: 2
      
      1) \\localhost\test
      SMBs: 0
      Bytes read: 502092  Bytes written: 31457286
      TreeConnects: 0 total 0 failed
      TreeDisconnects: 0 total 0 failed
      ...
      
      This patch fixes cifs_stats_proc_write to properly reset
      those four.
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6773f40
    • Tetsuo Handa's avatar
      fs/dcache.c: fix kmemcheck splat at take_dentry_name_snapshot() · 90d91af0
      Tetsuo Handa authored
      [ Upstream commit 6cd00a01f0c1ae6a852b09c59b8dd55cc6c35d1d ]
      
      Since only dentry->d_name.len + 1 bytes out of DNAME_INLINE_LEN bytes
      are initialized at __d_alloc(), we can't copy the whole size
      unconditionally.
      
       WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff8fa27465ac50)
       636f6e66696766732e746d70000000000010000000000000020000000188ffff
        i i i i i i i i i i i i i u u u u u u u u u u i i i i i u u u u
                                        ^
       RIP: 0010:take_dentry_name_snapshot+0x28/0x50
       RSP: 0018:ffffa83000f5bdf8 EFLAGS: 00010246
       RAX: 0000000000000020 RBX: ffff8fa274b20550 RCX: 0000000000000002
       RDX: ffffa83000f5be40 RSI: ffff8fa27465ac50 RDI: ffffa83000f5be60
       RBP: ffffa83000f5bdf8 R08: ffffa83000f5be48 R09: 0000000000000001
       R10: ffff8fa27465ac00 R11: ffff8fa27465acc0 R12: ffff8fa27465ac00
       R13: ffff8fa27465acc0 R14: 0000000000000000 R15: 0000000000000000
       FS:  00007f79737ac8c0(0000) GS:ffffffff8fc30000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffff8fa274c0b000 CR3: 0000000134aa7002 CR4: 00000000000606f0
        take_dentry_name_snapshot+0x28/0x50
        vfs_rename+0x128/0x870
        SyS_rename+0x3b2/0x3d0
        entry_SYSCALL_64_fastpath+0x1a/0xa4
        0xffffffffffffffff
      
      Link: http://lkml.kernel.org/r/201709131912.GBG39012.QMJLOVFSFFOOtH@I-love.SAKURA.ne.jpSigned-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90d91af0