1. 28 2月, 2013 4 次提交
    • 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
    • T
      ext4: fix extent status tree regression for file systems > 512GB · 8e919d13
      Theodore Ts'o 提交于
      This fixes a regression introduced by commit f7fec032.  The
      problem was that the extents status flags caused us to mask out block
      numbers smaller than 2**28 blocks.  Since we didn't test with file
      systems smaller than 512GB, we didn't notice this during the
      development cycle.
      
      A typical failure looks like this:
      
      EXT4-fs error (device sdb1): htree_dirblock_to_tree:919: inode #172235804: block
      152052301: comm ls: bad entry in directory: rec_len is smaller than minimal -
      offset=0(0), inode=0, rec_len=0, name_len=0
      
      ... where 'debugfs -R "stat <172235804>" /dev/sdb1' reports that the
      inode has block number 688923213.  When viewed in hex, block number
      152052301 (from the syslog) is 0x910224D, while block number 688923213
      is 0x2910224D.  Note the missing "0x20000000" in the block number.
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Verified-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Reported-by: NDave Jones <davej@redhat.com>
      Verified-by: NDave Jones <davej@redhat.com>
      Cc: Zheng Liu <gnehzuil.liu@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8e919d13
  2. 26 2月, 2013 23 次提交
  3. 24 2月, 2013 6 次提交
  4. 23 2月, 2013 7 次提交