1. 13 1月, 2013 2 次提交
  2. 07 1月, 2013 4 次提交
  3. 06 1月, 2013 1 次提交
  4. 05 1月, 2013 1 次提交
  5. 04 1月, 2013 5 次提交
  6. 03 1月, 2013 2 次提交
    • H
      mempolicy: remove arg from mpol_parse_str, mpol_to_str · a7a88b23
      Hugh Dickins 提交于
      Remove the unused argument (formerly no_context) from mpol_parse_str()
      and from mpol_to_str().
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7a88b23
    • E
      epoll: prevent missed events on EPOLL_CTL_MOD · 128dd175
      Eric Wong 提交于
      EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
      ensure events are not missed.  Since the modifications to the interest
      mask are not protected by the same lock as ep_poll_callback, we need to
      ensure the change is visible to other CPUs calling ep_poll_callback.
      
      We also need to ensure f_op->poll() has an up-to-date view of past
      events which occured before we modified the interest mask.  So this
      barrier also pairs with the barrier in wq_has_sleeper().
      
      This should guarantee either ep_poll_callback or f_op->poll() (or both)
      will notice the readiness of a recently-ready/modified item.
      
      This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:
      http://thread.gmane.org/gmane.linux.kernel/1408782/Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Cc: Hans Verkuil <hans.verkuil@cisco.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
      Tested-by: N"Junchang(Jason) Wang" <junchang.wang@yale.edu>
      Cc: netdev@vger.kernel.org
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      128dd175
  7. 02 1月, 2013 7 次提交
  8. 31 12月, 2012 2 次提交
    • J
      cifs: adjust sequence number downward after signing NT_CANCEL request · 31efee60
      Jeff Layton 提交于
      When a call goes out, the signing code adjusts the sequence number
      upward by two to account for the request and the response. An NT_CANCEL
      however doesn't get a response of its own, it just hurries the server
      along to get it to respond to the original request more quickly.
      Therefore, we must adjust the sequence number back down by one after
      signing a NT_CANCEL request.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NTim Perry <tdparmor-sambabugs@yahoo.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      31efee60
    • J
      cifs: move check for NULL socket into smb_send_rqst · ea702b80
      Jeff Layton 提交于
      Cai reported this oops:
      
      [90701.616664] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      [90701.625438] IP: [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.632167] PGD fea319067 PUD 103fda4067 PMD 0
      [90701.637255] Oops: 0000 [#1] SMP
      [90701.640878] Modules linked in: des_generic md4 nls_utf8 cifs dns_resolver binfmt_misc tun sg igb iTCO_wdt iTCO_vendor_support lpc_ich pcspkr i2c_i801 i2c_core i7core_edac edac_core ioatdma dca mfd_core coretemp kvm_intel kvm crc32c_intel microcode sr_mod cdrom ata_generic sd_mod pata_acpi crc_t10dif ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
      [90701.677655] CPU 10
      [90701.679808] Pid: 9627, comm: ls Tainted: G        W    3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
      [90701.688950] RIP: 0010:[<ffffffff814a343e>]  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.698383] RSP: 0018:ffff88177b431bb8  EFLAGS: 00010206
      [90701.704309] RAX: ffff88177b431fd8 RBX: 00007ffffffff000 RCX: ffff88177b431bec
      [90701.712271] RDX: 0000000000000003 RSI: 0000000000000006 RDI: 0000000000000000
      [90701.720223] RBP: ffff88177b431bc8 R08: 0000000000000004 R09: 0000000000000000
      [90701.728185] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
      [90701.736147] R13: ffff88184ef92000 R14: 0000000000000023 R15: ffff88177b431c88
      [90701.744109] FS:  00007fd56a1a47c0(0000) GS:ffff88105fc40000(0000) knlGS:0000000000000000
      [90701.753137] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [90701.759550] CR2: 0000000000000028 CR3: 000000104f15f000 CR4: 00000000000007e0
      [90701.767512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [90701.775465] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [90701.783428] Process ls (pid: 9627, threadinfo ffff88177b430000, task ffff88185ca4cb60)
      [90701.792261] Stack:
      [90701.794505]  0000000000000023 ffff88177b431c50 ffff88177b431c38 ffffffffa014fcb1
      [90701.802809]  ffff88184ef921bc 0000000000000000 00000001ffffffff ffff88184ef921c0
      [90701.811123]  ffff88177b431c08 ffffffff815ca3d9 ffff88177b431c18 ffff880857758000
      [90701.819433] Call Trace:
      [90701.822183]  [<ffffffffa014fcb1>] smb_send_rqst+0x71/0x1f0 [cifs]
      [90701.828991]  [<ffffffff815ca3d9>] ? schedule+0x29/0x70
      [90701.834736]  [<ffffffffa014fe6d>] smb_sendv+0x3d/0x40 [cifs]
      [90701.841062]  [<ffffffffa014fe96>] smb_send+0x26/0x30 [cifs]
      [90701.847291]  [<ffffffffa015801f>] send_nt_cancel+0x6f/0xd0 [cifs]
      [90701.854102]  [<ffffffffa015075e>] SendReceive+0x18e/0x360 [cifs]
      [90701.860814]  [<ffffffffa0134a78>] CIFSFindFirst+0x1a8/0x3f0 [cifs]
      [90701.867724]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
      [90701.875601]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
      [90701.883477]  [<ffffffffa01578e6>] cifs_query_dir_first+0x26/0x30 [cifs]
      [90701.890869]  [<ffffffffa015480d>] initiate_cifs_search+0xed/0x250 [cifs]
      [90701.898354]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.904486]  [<ffffffffa01554cb>] cifs_readdir+0x45b/0x8f0 [cifs]
      [90701.911288]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.917410]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.923533]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.929657]  [<ffffffff81195848>] vfs_readdir+0xb8/0xe0
      [90701.935490]  [<ffffffff81195b9f>] sys_getdents+0x8f/0x110
      [90701.941521]  [<ffffffff815d3b99>] system_call_fastpath+0x16/0x1b
      [90701.948222] Code: 66 90 55 65 48 8b 04 25 f0 c6 00 00 48 89 e5 53 48 83 ec 08 83 fe 01 48 8b 98 48 e0 ff ff 48 c7 80 48 e0 ff ff ff ff ff ff 74 22 <48> 8b 47 28 ff 50 68 65 48 8b 14 25 f0 c6 00 00 48 89 9a 48 e0
      [90701.970313] RIP  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.977125]  RSP <ffff88177b431bb8>
      [90701.981018] CR2: 0000000000000028
      [90701.984809] ---[ end trace 24bd602971110a43 ]---
      
      This is likely due to a race vs. a reconnection event.
      
      The current code checks for a NULL socket in smb_send_kvec, but that's
      too late. By the time that check is done, the socket will already have
      been passed to kernel_setsockopt. Move the check into smb_send_rqst, so
      that it's checked earlier.
      
      In truth, this is a bit of a half-assed fix. The -ENOTSOCK error
      return here looks like it could bubble back up to userspace. The locking
      rules around the ssocket pointer are really unclear as well. There are
      cases where the ssocket pointer is changed without holding the srv_mutex,
      but I'm not clear whether there's a potential race here yet or not.
      
      This code seems like it could benefit from some fundamental re-think of
      how the socket handling should behave. Until then though, this patch
      should at least fix the above oops in most cases.
      
      Cc: <stable@vger.kernel.org> # 3.7+
      Reported-and-Tested-by: NCAI Qian <caiqian@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      ea702b80
  9. 28 12月, 2012 11 次提交
  10. 27 12月, 2012 2 次提交
    • T
      ext4: avoid hang when mounting non-journal filesystems with orphan list · 0e9a9a1a
      Theodore Ts'o 提交于
      When trying to mount a file system which does not contain a journal,
      but which does have a orphan list containing an inode which needs to
      be truncated, the mount call with hang forever in
      ext4_orphan_cleanup() because ext4_orphan_del() will return
      immediately without removing the inode from the orphan list, leading
      to an uninterruptible loop in kernel code which will busy out one of
      the CPU's on the system.
      
      This can be trivially reproduced by trying to mount the file system
      found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
      source tree.  If a malicious user were to put this on a USB stick, and
      mount it on a Linux desktop which has automatic mounts enabled, this
      could be considered a potential denial of service attack.  (Not a big
      deal in practice, but professional paranoids worry about such things,
      and have even been known to allocate CVE numbers for such problems.)
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NZheng Liu <wenqing.lz@taobao.com>
      Cc: stable@vger.kernel.org
      0e9a9a1a
    • T
      ext4: lock i_mutex when truncating orphan inodes · 721e3eba
      Theodore Ts'o 提交于
      Commit c278531d added a warning when ext4_flush_unwritten_io() is
      called without i_mutex being taken.  It had previously not been taken
      during orphan cleanup since races weren't possible at that point in
      the mount process, but as a result of this c278531d, we will now see
      a kernel WARN_ON in this case.  Take the i_mutex in
      ext4_orphan_cleanup() to suppress this warning.
      Reported-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NZheng Liu <wenqing.lz@taobao.com>
      Cc: stable@vger.kernel.org
      721e3eba
  11. 26 12月, 2012 3 次提交
    • E
      f2fs: Don't assign e_id in f2fs_acl_from_disk · 48c6d121
      Eric W. Biederman 提交于
      With user namespaces enabled building f2fs fails with:
      
       CC      fs/f2fs/acl.o
      fs/f2fs/acl.c: In function ‘f2fs_acl_from_disk’:
      fs/f2fs/acl.c:85:21: error: ‘struct posix_acl_entry’ has no member named ‘e_id’
      make[2]: *** [fs/f2fs/acl.o] Error 1
      make[2]: Target `__build' not remade because of errors.
      
      e_id is a backwards compatibility field only used for file systems
      that haven't been converted to use kuids and kgids.  When the posix
      acl tag field is neither ACL_USER nor ACL_GROUP assigning e_id is
      unnecessary.  Remove the assignment so f2fs will build with user
      namespaces enabled.
      
      Cc: Namjae Jeon <namjae.jeon@samsung.com>
      Cc: Amit Sahrawat <a.sahrawat@samsung.com>
      Acked-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      48c6d121
    • J
      f2fs: do f2fs_balance_fs in front of dir operations · 1efef832
      Jaegeuk Kim 提交于
      In order to conserve free sections to deal with the worst-case scenarios, f2fs
      should be able to freeze all the directory operations especially when there are
      not enough free sections. The f2fs_balance_fs() is for this use.
      
      When FS utilization becomes almost 100%, directory operations can be failed due
      to -ENOSPC frequently, which produces some dirty node pages occasionally.
      
      Previously, in such a case, f2fs_balance_fs() is not able to be triggered since
      it is triggered only if the directory operation ends up with success.
      
      So, this patch triggers f2fs_balance_fs() at first before handling directory
      operations.
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      1efef832
    • J
      f2fs: should recover orphan and fsync data · 30f0c758
      Jaegeuk Kim 提交于
      The recovery routine should do all the time regardless of normal umount action.
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      30f0c758