1. 28 2月, 2013 3 次提交
    • M
      cifs: set MAY_SIGN when sec=krb5 · 0b7bc840
      Martijn de Gouw 提交于
      Setting this secFlg allows usage of dfs where some servers require
      signing and others don't.
      Signed-off-by: NMartijn de Gouw <martijn.de.gouw@prodrive.nl>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      0b7bc840
    • S
      POSIX extensions disabled on client due to illegal O_EXCL flag sent to Samba · 07b92d0d
      Steve French 提交于
      Samba rejected libreoffice's attempt to open a file with illegal
      O_EXCL (without O_CREAT).  Mask this flag off (as the local
      linux file system case does) for this case, so that we
      don't have disable Unix Extensions unnecessarily due to
      the Samba error (Samba server is also being fixed).
      
      See https://bugzilla.samba.org/show_bug.cgi?id=9519Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      07b92d0d
    • J
      cifs: ensure that cifs_get_root() only traverses directories · ce2ac521
      Jeff Layton 提交于
      Kjell Braden reported this oops:
      
      [  833.211970] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  833.212816] IP: [<          (null)>]           (null)
      [  833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
      [  833.213874] Oops: 0010 [#1] SMP
      [  833.214344] CPU 0
      [  833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000
      [  833.215629]
      [  833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9+ #18 innotek GmbH VirtualBox/VirtualBox
      [  833.215629] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
      [  833.215629] RSP: 0018:ffff8800119c9c50  EFLAGS: 00010282
      [  833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000
      [  833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8
      [  833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7
      [  833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8
      [  833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6
      [  833.215629] FS:  00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [  833.215629] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0
      [  833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)
      [  833.215629] Stack:
      [  833.215629]  ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286
      [  833.215629]  0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8
      [  833.215629]  ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0
      [  833.215629] Call Trace:
      [  833.215629]  [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90
      [  833.215629]  [<ffffffff81178075>] ? d_lookup+0x35/0x60
      [  833.215629]  [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0
      [  833.215629]  [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0
      [  833.215629]  [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20
      [  833.215629]  [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]
      [  833.215629]  [<ffffffff81163bd3>] mount_fs+0x43/0x1b0
      [  833.215629]  [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0
      [  833.215629]  [<ffffffff8117e584>] do_kern_mount+0x54/0x110
      [  833.215629]  [<ffffffff8117fdc2>] do_mount+0x262/0x840
      [  833.215629]  [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50
      [  833.215629]  [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180
      [  833.215629]  [<ffffffff8118075d>] sys_mount+0x8d/0xe0
      [  833.215629]  [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b
      [  833.215629] Code:  Bad RIP value.
      [  833.215629] RIP  [<          (null)>]           (null)
      [  833.215629]  RSP <ffff8800119c9c50>
      [  833.215629] CR2: 0000000000000000
      [  833.238525] ---[ end trace ec00758b8d44f529 ]---
      
      When walking down the path on the server, it's possible to hit a
      symlink. The path walking code assumes that the caller will handle that
      situation properly, but cifs_get_root() isn't set up for it. This patch
      prevents the oops by simply returning an error.
      
      A better solution would be to try and chase the symlinks here, but that's
      fairly complicated to handle.
      
      Fixes:
      
          https://bugzilla.kernel.org/show_bug.cgi?id=53221Reported-and-tested-by: NKjell Braden <afflux@pentabarf.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ce2ac521
  2. 26 2月, 2013 1 次提交
  3. 23 2月, 2013 1 次提交
  4. 13 2月, 2013 12 次提交
  5. 23 1月, 2013 1 次提交
  6. 22 1月, 2013 1 次提交
  7. 21 1月, 2013 1 次提交
  8. 09 1月, 2013 1 次提交
  9. 02 1月, 2013 3 次提交
  10. 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
  11. 21 12月, 2012 3 次提交
  12. 18 12月, 2012 1 次提交
  13. 12 12月, 2012 5 次提交
    • P
      CIFS: Fix write after setting a read lock for read oplock files · c299dd0e
      Pavel Shilovsky 提交于
      If we have a read oplock and set a read lock in it, we can't write to the
      locked area - so, filemap_fdatawrite may fail with a no information for a
      userspace application even if we request a write to non-locked area. Fix
      this by populating the page cache without marking affected pages dirty
      after a successful write directly to the server.
      
      Also remove CONFIG_CIFS_SMB2 ifdefs because it's suitable for both CIFS
      and SMB2 protocols.
      Signed-off-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      c299dd0e
    • J
      cifs: parse the device name into UNC and prepath · d387a5c5
      Jeff Layton 提交于
      This should fix a regression that was introduced when the new mount
      option parser went in. Also, when the unc= and prefixpath= options
      are provided, check their values against the ones we parsed from
      the device string. If they differ, then throw a warning that tells
      the user that we're using the values from the unc= option for now,
      but that that will change in 3.10.
      
      Pavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      d387a5c5
    • J
      cifs: fix up handling of prefixpath= option · 839db3d1
      Jeff Layton 提交于
      Currently the code takes care to ensure that the prefixpath has a
      leading '/' delimiter. What if someone passes us a prefixpath with a
      leading '\\' instead? The code doesn't properly handle that currently
      AFAICS.
      
      Let's just change the code to skip over any leading delimiter character
      when copying the prepath. Then, fix up the users of the prepath option
      to prefix it with the correct delimiter when they use it.
      
      Also, there's no need to limit the length of the prefixpath to 1k. If
      the server can handle it, why bother forbidding it?
      
      Pavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      839db3d1
    • J
      cifs: clean up handling of unc= option · 62a1a439
      Jeff Layton 提交于
      Make sure we free any existing memory allocated for vol->UNC, just in
      case someone passes in multiple unc= options.
      
      Get rid of the check for too long a UNC. The check for >300 bytes seems
      arbitrary. We later copy this into the tcon->treeName, for instance and
      it's a lot shorter than 300 bytes.
      
      Eliminate an extra kmalloc and copy as well. Just set the vol->UNC
      directly with the contents of match_strdup.
      
      Establish that the UNC should be stored with '\\' delimiters. Use
      convert_delimiter to change it in place in the vol->UNC.
      
      Finally, move the check for a malformed UNC into
      cifs_parse_mount_options so we can catch that situation earlier.
      
      Pavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      62a1a439
    • J
      cifs: fix SID binary to string conversion · 193cdd8a
      Jeff Layton 提交于
      The authority fields are supposed to be represented by a single 48-bit
      value. It's also supposed to represent the value as hex if it's equal to
      or greater than 2^32. This is documented in MS-DTYP, section 2.4.2.1.
      
      Also, fix up the max string length to account for this fix.
      Acked-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      193cdd8a
  14. 10 12月, 2012 2 次提交
  15. 09 12月, 2012 3 次提交