1. 02 12月, 2016 18 次提交
  2. 27 11月, 2016 1 次提交
  3. 23 11月, 2016 1 次提交
    • A
      NFSv4.x: hide array-bounds warning · d55b352b
      Arnd Bergmann 提交于
      A correct bugfix introduced a harmless warning that shows up with gcc-7:
      
      fs/nfs/callback.c: In function 'nfs_callback_up':
      fs/nfs/callback.c:214:14: error: array subscript is outside array bounds [-Werror=array-bounds]
      
      What happens here is that the 'minorversion == 0' check tells the
      compiler that we assume minorversion can be something other than 0,
      but when CONFIG_NFS_V4_1 is disabled that would be invalid and
      result in an out-of-bounds access.
      
      The added check for IS_ENABLED(CONFIG_NFS_V4_1) tells gcc that this
      really can't happen, which makes the code slightly smaller and also
      avoids the warning.
      
      The bugfix that introduced the warning is marked for stable backports,
      we want this one backported to the same releases.
      
      Fixes: 98b0f80c ("NFSv4.x: Fix a refcount leak in nfs_callback_up_net")
      Cc: stable@vger.kernel.org # v3.7+
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      d55b352b
  4. 22 11月, 2016 1 次提交
  5. 20 11月, 2016 3 次提交
  6. 19 11月, 2016 4 次提交
  7. 17 11月, 2016 2 次提交
    • A
      xattr: Fix setting security xattrs on sockfs · 4a590153
      Andreas Gruenbacher 提交于
      The IOP_XATTR flag is set on sockfs because sockfs supports getting the
      "system.sockprotoname" xattr.  Since commit 6c6ef9f2, this flag is checked for
      setxattr support as well.  This is wrong on sockfs because security xattr
      support there is supposed to be provided by security_inode_setsecurity.  The
      smack security module relies on socket labels (xattrs).
      
      Fix this by adding a security xattr handler on sockfs that returns
      -EAGAIN, and by checking for -EAGAIN in setxattr.
      
      We cannot simply check for -EOPNOTSUPP in setxattr because there are
      filesystems that neither have direct security xattr support nor support
      via security_inode_setsecurity.  A more proper fix might be to move the
      call to security_inode_setsecurity into sockfs, but it's not clear to me
      if that is safe: we would end up calling security_inode_post_setxattr after
      that as well.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4a590153
    • M
      orangefs: add .owner to debugfs file_operations · 19ff7fcc
      Mike Marshall 提交于
      Without ".owner = THIS_MODULE" it is possible to crash the kernel
      by unloading the Orangefs module while someone is reading debugfs
      files.
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      19ff7fcc
  8. 15 11月, 2016 1 次提交
  9. 12 11月, 2016 3 次提交
    • A
      NFSv4.1: work around -Wmaybe-uninitialized warning · e84efa32
      Arnd Bergmann 提交于
      A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use if
      we enable -Wmaybe-uninitialized again:
      
        fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair results
      in a nonzero return value here.  Using PTR_ERR_OR_ZERO() instead makes
      this clear to the compiler.
      
      Fixes: e09c978a ("NFSv4.1: Fix Oopsable condition in server callback races")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e84efa32
    • A
      coredump: fix unfreezable coredumping task · 70d78fe7
      Andrey Ryabinin 提交于
      It could be not possible to freeze coredumping task when it waits for
      'core_state->startup' completion, because threads are frozen in
      get_signal() before they got a chance to complete 'core_state->startup'.
      
      Inability to freeze a task during suspend will cause suspend to fail.
      Also CRIU uses cgroup freezer during dump operation.  So with an
      unfreezable task the CRIU dump will fail because it waits for a
      transition from 'FREEZING' to 'FROZEN' state which will never happen.
      
      Use freezer_do_not_count() to tell freezer to ignore coredumping task
      while it waits for core_state->startup completion.
      
      Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70d78fe7
    • J
      ocfs2: fix not enough credit panic · d006c71f
      Junxiao Bi 提交于
      The following panic was caught when run ocfs2 disconfig single test
      (block size 512 and cluster size 8192).  ocfs2_journal_dirty() return
      -ENOSPC, that means credits were used up.
      
      The total credit should include 3 times of "num_dx_leaves" from
      ocfs2_dx_dir_rebalance(), because 2 times will be consumed in
      ocfs2_dx_dir_transfer_leaf() and 1 time will be consumed in
      ocfs2_dx_dir_new_cluster() -> __ocfs2_dx_dir_new_cluster() ->
      ocfs2_dx_dir_format_cluster().  But only two times is included in
      ocfs2_dx_dir_rebalance_credits(), fix it.
      
      This can cause read-only fs(v4.1+) or panic for mainline linux depending
      on mount option.
      
        ------------[ cut here ]------------
        kernel BUG at fs/ocfs2/journal.c:775!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi 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 ppdev xen_kbdfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea parport_pc parport acpi_cpufreq i2c_piix4 i2c_core pcspkr ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
        CPU: 2 PID: 10601 Comm: dd Not tainted 4.1.12-71.el6uek.bug24939243.x86_64 #2
        Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
        task: ffff8800b6de6200 ti: ffff8800a7d48000 task.ti: ffff8800a7d48000
        RIP: ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
        RSP: 0018:ffff8800a7d4b6d8  EFLAGS: 00010286
        RAX: 00000000ffffffe4 RBX: 00000000814d0a9c RCX: 00000000000004f9
        RDX: ffffffffa008e990 RSI: ffffffffa008f1ee RDI: ffff8800622b6460
        RBP: ffff8800a7d4b6f8 R08: ffffffffa008f288 R09: ffff8800622b6460
        R10: 0000000000000000 R11: 0000000000000282 R12: 0000000002c8421e
        R13: ffff88006d0cad00 R14: ffff880092beef60 R15: 0000000000000070
        FS:  00007f9b83e92700(0000) GS:ffff8800be880000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007fb2c0d1a000 CR3: 0000000008f80000 CR4: 00000000000406e0
        Call Trace:
          ocfs2_dx_dir_transfer_leaf+0x159/0x1a0 [ocfs2]
          ocfs2_dx_dir_rebalance+0xd9b/0xea0 [ocfs2]
          ocfs2_find_dir_space_dx+0xd3/0x300 [ocfs2]
          ocfs2_prepare_dx_dir_for_insert+0x219/0x450 [ocfs2]
          ocfs2_prepare_dir_for_insert+0x1d6/0x580 [ocfs2]
          ocfs2_mknod+0x5a2/0x1400 [ocfs2]
          ocfs2_create+0x73/0x180 [ocfs2]
          vfs_create+0xd8/0x100
          lookup_open+0x185/0x1c0
          do_last+0x36d/0x780
          path_openat+0x92/0x470
          do_filp_open+0x4a/0xa0
          do_sys_open+0x11a/0x230
          SyS_open+0x1e/0x20
          system_call_fastpath+0x12/0x71
        Code: 1d 3f 29 09 00 48 85 db 74 1f 48 8b 03 0f 1f 80 00 00 00 00 48 8b 7b 08 48 83 c3 10 4c 89 e6 ff d0 48 8b 03 48 85 c0 75 eb eb 90 <0f> 0b eb fe 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54
        RIP  ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
        ---[ end trace 91ac5312a6ee1288 ]---
        Kernel panic - not syncing: Fatal exception
        Kernel Offset: disabled
      
      Link: http://lkml.kernel.org/r/1478248135-31963-1-git-send-email-junxiao.bi@oracle.comSigned-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d006c71f
  10. 11 11月, 2016 2 次提交
  11. 08 11月, 2016 3 次提交
  12. 07 11月, 2016 1 次提交
    • M
      orangefs: clean up debugfs · dc033621
      Mike Marshall 提交于
      We recently refactored the Orangefs debugfs code.
      The refactor seemed to trigger dan.carpenter@oracle.com's
      static tester to find a possible double-free in the code.
      
      While designing the fix we saw a condition under which the
      buffer being freed could also be overflowed.
      
      We also realized how to rebuild the related debugfs file's
      "contents" (a string) without deleting and re-creating the file.
      
      This fix should eliminate the possible double-free, the
      potential overflow and improve code readability.
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      Signed-off-by: NMartin Brandenburg <martin@omnibond.com>
      dc033621