1. 04 3月, 2010 1 次提交
  2. 09 2月, 2010 2 次提交
  3. 06 2月, 2010 2 次提交
  4. 17 1月, 2010 1 次提交
  5. 01 1月, 2010 1 次提交
  6. 10 12月, 2009 1 次提交
    • C
      vfs: Implement proper O_SYNC semantics · 6b2f3d1f
      Christoph Hellwig 提交于
      While Linux provided an O_SYNC flag basically since day 1, it took until
      Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
      since that day we had generic_osync_around with only minor changes and the
      great "For now, when the user asks for O_SYNC, we'll actually give
      O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
      semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
      patches which are required before this patch it's actually surprisingly
      simple, we just need to figure out when to set the datasync flag to
      vfs_fsync_range and when not.
      
      This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
      numerical value to keep binary compatibility, and adds a new real O_SYNC
      flag.  To guarantee backwards compatiblity it is defined as expanding to
      both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
      sure we are backwards-compatible when compiled against the new headers.
      
      This also means that all places that don't care about the differences can
      just check O_DSYNC and get the right behaviour for O_SYNC, too - only
      places that actuall care need to check __O_SYNC in addition.  Drivers and
      network filesystems have been updated in a fail safe way to always do the
      full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
      lower layers are kept that way for now to stay failsafe.
      
      We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
      to make sure we always get these sane options.
      
      Note that parisc really screwed up their headers as they already define a
      O_DSYNC that has always been a no-op.  We try to repair it by using it for
      the new O_DSYNC and redefinining O_SYNC to send both the traditional
      O_SYNC numerical value _and_ the O_DSYNC one.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andreas Dilger <adilger@sun.com>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      6b2f3d1f
  7. 07 12月, 2009 1 次提交
  8. 05 12月, 2009 1 次提交
  9. 04 12月, 2009 2 次提交
  10. 25 11月, 2009 3 次提交
    • S
      [CIFS] Fix sparse warning · 2f81e752
      Steve French 提交于
      Also update CHANGES file
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      2f81e752
    • S
      [CIFS] Duplicate data on appending to some Samba servers · cea62343
      Steve French 提交于
      SMB writes are sent with a starting offset and length. When the server
      supports the newer SMB trans2 posix open (rather than using the SMB
      NTCreateX) a file can be opened with SMB_O_APPEND flag, and for that
      case Samba server assumes that the offset sent in SMBWriteX is unneeded
      since the write should go to the end of the file - which can cause
      problems if the write was cached (since the beginning part of a
      page could be written twice by the client mm).  Jeff suggested that
      masking the flag on posix open on the client is easiest for the time
      being. Note that recent Samba server also had an unrelated problem with
      SMB NTCreateX and append (see samba bugzilla bug number 6898) which
      should not affect current Linux clients (unless cifs Unix Extensions
      are disabled).
      
      The cifs client did not send the O_APPEND flag on posix open
      before 2.6.29 so the fix is unneeded on early kernels.
      
      In the future, for the non-cached case (O_DIRECT, and forcedirectio mounts)
      it would be possible and useful to send O_APPEND on posix open (for Windows
      case: FILE_APPEND_DATA but not FILE_WRITE_DATA on SMB NTCreateX) but for
      cached writes although the vfs sets the offset to end of file it
      may fragment a write across pages - so we can't send O_APPEND on
      open (could result in sending part of a page twice).
      
      CC: Stable <stable@kernel.org>
      Reviewed-by: NShirish Pargaonkar <shirishp@us.ibm.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cea62343
    • S
      [CIFS] fix oops in cifs_lookup during net boot · 8e6c0332
      Steve French 提交于
      Fixes bugzilla.kernel.org bug number 14641
      
      Lookup called during network boot (network root filesystem
      for diskless workstation) has case where nd is null in
      lookup.  This patch fixes that in cifs_lookup.
      
      (Shirish noted that 2.6.30 and 2.6.31 stable need the same check)
      Signed-off-by: NShirish Pargaonkar <shirishp@us.ibm.com>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Tested-by: NVladimir Stavrinov <vs@inist.ru>
      CC: Stable <stable@kernel.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      8e6c0332
  11. 21 11月, 2009 1 次提交
    • D
      SLOW_WORK: Fix CIFS to pass THIS_MODULE to slow_work_register_user() · 0109d7e6
      David Howells 提交于
      As of the patch:
      
      	SLOW_WORK: Wait for outstanding work items belonging to a module to clear
      
      	Wait for outstanding slow work items belonging to a module to clear
      	when unregistering that module as a user of the facility.  This
      	prevents the put_ref code of a work item from being taken away before
      	it returns.
      
      slow_work_register_user() takes a module pointer as an argument.  CIFS must now
      pass THIS_MODULE as that argument, lest the following error be observed:
      
      	fs/cifs/cifsfs.c: In function 'init_cifs':
      	fs/cifs/cifsfs.c:1040: error: too few arguments to function 'slow_work_register_user'
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      0109d7e6
  12. 16 11月, 2009 1 次提交
  13. 07 11月, 2009 2 次提交
    • J
      cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible · f475f677
      Jeff Layton 提交于
      Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to
      verify the accessibility of the root inode and then falls back to doing a
      full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report
      of a server that returns NT_STATUS_INTERNAL_ERROR rather than something
      that translates to EOPNOTSUPP.
      
      Rather than trying to be clever with that call, just have
      is_path_accessible do a normal QPathInfo. That call is widely
      supported and it shouldn't increase the overhead significantly.
      
      Cc: Stable <stable@kernel.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f475f677
    • J
      cifs: clean up handling when server doesn't consistently support inode numbers · ec06aedd
      Jeff Layton 提交于
      It's possible that a server will return a valid FileID when we query the
      FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers
      when we do a FindFile with an infolevel of
      SMB_FIND_FILE_ID_FULL_DIR_INFO.
      
      In this situation turn off querying for server inode numbers, generate a
      warning for the user and just generate an inode number using iunique.
      Once we generate any inode number with iunique we can no longer use any
      server inode numbers or we risk collisions, so ensure that we don't do
      that in cifs_get_inode_info either.
      
      Cc: Stable <stable@kernel.org>
      Reported-by: NTimothy Normand Miller <theosib@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ec06aedd
  14. 28 10月, 2009 1 次提交
  15. 07 10月, 2009 1 次提交
    • S
      [CIFS] Fixing to avoid invalid kfree() in cifs_get_tcp_session() · 8347a5cd
      Steve French 提交于
      trivial bug in fs/cifs/connect.c .
      The bug is caused by fail of extract_hostname()
      when mounting cifs file system.
      
      This is the situation when I noticed this bug.
      
      % sudo mount -t cifs //192.168.10.208 mountpoint -o options...
      
      Then my kernel says,
      
      [ 1461.807776] ------------[ cut here ]------------
      [ 1461.807781] kernel BUG at mm/slab.c:521!
      [ 1461.807784] invalid opcode: 0000 [#2] PREEMPT SMP
      [ 1461.807790] last sysfs file:
      /sys/devices/pci0000:00/0000:00:1e.0/0000:09:02.0/resource
      [ 1461.807793] CPU 0
      [ 1461.807796] Modules linked in: nls_iso8859_1 usbhid sbp2 uhci_hcd
      ehci_hcd i2c_i801 ohci1394 ieee1394 psmouse serio_raw pcspkr sky2 usbcore
      evdev
      [ 1461.807816] Pid: 3446, comm: mount Tainted: G      D 2.6.32-rc2-vanilla
      [ 1461.807820] RIP: 0010:[<ffffffff810b888e>]  [<ffffffff810b888e>]
      kfree+0x63/0x156
      [ 1461.807829] RSP: 0018:ffff8800b4f7fbb8  EFLAGS: 00010046
      [ 1461.807832] RAX: ffffea00033fff98 RBX: ffff8800afbae7e2 RCX:
      0000000000000000
      [ 1461.807836] RDX: ffffea0000000000 RSI: 000000000000005c RDI:
      ffffffffffffffea
      [ 1461.807839] RBP: ffff8800b4f7fbf8 R08: 0000000000000001 R09:
      0000000000000000
      [ 1461.807842] R10: 0000000000000000 R11: ffff8800b4f7fbf8 R12:
      00000000ffffffea
      [ 1461.807845] R13: ffff8800afb23000 R14: ffff8800b4f87bc0 R15:
      ffffffffffffffea
      [ 1461.807849] FS:  00007f52b6f187c0(0000) GS:ffff880007600000(0000)
      knlGS:0000000000000000
      [ 1461.807852] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1461.807855] CR2: 0000000000613000 CR3: 00000000af8f9000 CR4:
      00000000000006f0
      [ 1461.807858] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [ 1461.807861] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [ 1461.807865] Process mount (pid: 3446, threadinfo ffff8800b4f7e000, task
      ffff8800950e4380)
      [ 1461.807867] Stack:
      [ 1461.807869]  0000000000000202 0000000000000282 ffff8800b4f7fbf8
      ffff8800afbae7e2
      [ 1461.807876] <0> 00000000ffffffea ffff8800afb23000 ffff8800b4f87bc0
      ffff8800b4f7fc28
      [ 1461.807884] <0> ffff8800b4f7fcd8 ffffffff81159f6d ffffffff81147bc2
      ffffffff816bfb48
      [ 1461.807892] Call Trace:
      [ 1461.807899]  [<ffffffff81159f6d>] cifs_get_tcp_session+0x440/0x44b
      [ 1461.807904]  [<ffffffff81147bc2>] ? find_nls+0x1c/0xe9
      [ 1461.807909]  [<ffffffff8115b889>] cifs_mount+0x16bc/0x2167
      [ 1461.807917]  [<ffffffff814455bd>] ? _spin_unlock+0x30/0x4b
      [ 1461.807923]  [<ffffffff81150da9>] cifs_get_sb+0xa5/0x1a8
      [ 1461.807928]  [<ffffffff810c1b94>] vfs_kern_mount+0x56/0xc9
      [ 1461.807933]  [<ffffffff810c1c64>] do_kern_mount+0x47/0xe7
      [ 1461.807938]  [<ffffffff810d8632>] do_mount+0x712/0x775
      [ 1461.807943]  [<ffffffff810d671f>] ? copy_mount_options+0xcf/0x132
      [ 1461.807948]  [<ffffffff810d8714>] sys_mount+0x7f/0xbf
      [ 1461.807953]  [<ffffffff8144509a>] ? lockdep_sys_exit_thunk+0x35/0x67
      [ 1461.807960]  [<ffffffff81011cc2>] system_call_fastpath+0x16/0x1b
      [ 1461.807963] Code: 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 68 48 01 d0
      66 83 38 00 79 04 48 8b 40 10 66 83 38 00 79 04 48 8b 40 10 80 38 00 78 04
      <0f> 0b eb fe 4c 8b 70 58 4c 89 ff 41 8b 76 4c e8 b8 49 fb ff e8
      [ 1461.808022] RIP  [<ffffffff810b888e>] kfree+0x63/0x156
      [ 1461.808027]  RSP <ffff8800b4f7fbb8>
      [ 1461.808031] ---[ end trace ffe26fcdc72c0ce4 ]---
      
      The reason of this bug is that the error handling code of
      cifs_get_tcp_session()
      calls kfree() when corresponding kmalloc() failed.
      (The kmalloc() is called by extract_hostname().)
      Signed-off-by: NHitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      CC: Stable <stable@kernel.org>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      8347a5cd
  16. 26 9月, 2009 1 次提交
  17. 25 9月, 2009 5 次提交
  18. 24 9月, 2009 2 次提交
  19. 22 9月, 2009 2 次提交
  20. 21 9月, 2009 1 次提交
  21. 16 9月, 2009 5 次提交
  22. 03 9月, 2009 1 次提交
  23. 02 9月, 2009 2 次提交