1. 23 Feb, 2013 2 commits
  2. 16 Jan, 2013 6 commits
  3. 14 Jan, 2013 3 commits
    • Namjae Jeon's avatar
      UDF: Fix a null pointer dereference in udf_sb_free_partitions · 1b1baff6
      Namjae Jeon authored
      This patch fixes a regression caused by commit bff943af "udf: Fix memory
      leak when mounting" due to which it was triggering a kernel null point
      dereference in case of interrupted mount OR when allocating memory to
      sbi->s_partmaps failed in function udf_sb_alloc_partition_maps.
      Reported-and-tested-by: default avatarJames Hogan <james@albanarts.com>
      Signed-off-by: default avatarNamjae Jeon <namjae.jeon@samsung.com>
      Signed-off-by: default avatarAshish Sangwan <a.sangwan@samsung.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
    • Eric Sandeen's avatar
      jbd: don't wake kjournald unnecessarily · 7e2fb2d7
      Eric Sandeen authored
      Don't send an extra wakeup to kjournald in the case where we
      already have the proper target in j_commit_request, i.e. that
      commit has already been requested for commit.
      commit d9b01934 "jbd: fix fsync() tid wraparound bug" changed
      the logic leading to a wakeup, but it caused some extra wakeups
      which were found to lead to a measurable performance regression.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
    • Linus Torvalds's avatar
      vfs: add missing virtual cache flush after editing partial pages · 6d283dba
      Linus Torvalds authored
      Andrew Morton pointed this out a month ago, and then I completely forgot
      about it.
      If we read a partial last page of a block device, we will zero out the
      end of the page, but since that page can then be mapped into user space,
      we should also make sure to flush the cache on architectures that have
      virtual caches.  We have the flush_dcache_page() function for this, so
      use it.
      Now, in practice this really never matters, because nobody sane uses
      virtual caches to begin with, and they largely exist on old broken RISC
      And even if you did run on one of those obsolete CPU's, the whole "mmap
      and access the last partial page of a block device" behavior probably
      doesn't actually exist.  The normal IO functions (read/write) will never
      see the zeroed-out part of the page that migth not be coherent in the
      cache, because they honor the size of the device.
      So I'm marking this for stable (3.7 only), but I'm not sure anybody will
      ever care.
      Pointed-out-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: stable@vger.kernel.org  # 3.7
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 11 Jan, 2013 2 commits
  5. 10 Jan, 2013 1 commit
  6. 07 Jan, 2013 4 commits
  7. 05 Jan, 2013 1 commit
  8. 04 Jan, 2013 3 commits
  9. 03 Jan, 2013 3 commits
  10. 02 Jan, 2013 9 commits
  11. 30 Dec, 2012 2 commits
    • Jeff Layton's avatar
      cifs: adjust sequence number downward after signing NT_CANCEL request · 31efee60
      Jeff Layton authored
      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: default avatarTim Perry <tdparmor-sambabugs@yahoo.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
    • Jeff Layton's avatar
      cifs: move check for NULL socket into smb_send_rqst · ea702b80
      Jeff Layton authored
      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: default avatarCAI Qian <caiqian@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
  12. 28 Dec, 2012 4 commits