1. 29 6月, 2011 1 次提交
  2. 16 6月, 2011 1 次提交
  3. 11 5月, 2011 1 次提交
  4. 15 4月, 2011 1 次提交
    • G
      Revert "usb: usb_storage: do not align length of request for CBW to maxp size" · 98346f7d
      Greg Kroah-Hartman 提交于
      This reverts commit 806e8f8f.
      
      To quote Alan Stern:
      	The necessity for this patch has been under discussion.
      
      	It turns out the UDC that Mian has been working on and Felipe's
      	UDC have contradictory requirements.  Mian's UDC driver wants a
      	bulk-OUT transfer length to be shorter than the maxpacket size
      	if a short packet is expected, whereas Felipe's UDC hardware
      	always needs bulk-OUT transfer lengths to be evenly divisible by
      	the maxpacket size.
      
      	Mian has agreed to go back over the driver to resolve this
      	conflict.  This means we probably will not want this patch after
      	all.  (In fact, we may ultimately decide to change the gadget
      	framework to require that bulk-OUT transfer lengths _always_ be
      	divisible by the maxpacket size -- only the g_file_storage and
      	g_mass_storage gadgets would need to be changed.)
      
      Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      98346f7d
  5. 14 4月, 2011 2 次提交
  6. 11 11月, 2010 1 次提交
    • M
      USB: gadget: file_storage: put_device() in error recovery · d9385b63
      Michal Nazarewicz 提交于
      This commit fixes some issues with File-backed Storage Gadget
      error recovery when registering LUN's devices.
      
      First of all, when device_register() fails the device still
      needs to be put.  However, because lun_release() decreases
      fsg->ref reference counter the counter must be incremented
      beforehand.
      
      Second of all, after any of the device_create_file()s fails,
      device_unregister() is called which in turn (indirectly) calls
      lun_release() which decrements fsg->ref.  So, again, the
      reference counter must be incremented beforehand.
      
      Lastly, if the first or the second device_create_file()
      succeeds, the files are never removed.  To fix it,
      device_remove_file() needs to be called.  This is done by
      simply marking LUN as registered prior to creating files so
      that fsg_unbind() can handle removing files.
      Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
      Reported-by: NRahul Ruikar <rahul.ruikar@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d9385b63
  7. 23 10月, 2010 5 次提交
  8. 11 8月, 2010 4 次提交
  9. 04 3月, 2010 1 次提交
  10. 03 3月, 2010 1 次提交
  11. 12 12月, 2009 5 次提交
  12. 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
  13. 16 6月, 2009 1 次提交
  14. 24 4月, 2009 1 次提交
    • A
      USB: g_file_storage: fix use-after-free bug when closing files · 82a10a81
      Alan Stern 提交于
      This patch (as1231) fixes a use-after-free bug in g_file_storage.  A
      device's name may not be available after the device is unregistered,
      even if the device structure itself is still allocated.  Since
      close_backing_file() prints a LUN's name for debugging, it shouldn't
      be called after the LUN has been unregistered.
      
      That whole area needed to be cleaned up; the backing files were
      getting closed in a couple of different places.  The patch fixes
      things so that they get closed in just one place, as part of the
      unbind procedure, immediately before the LUN is unregistered.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      82a10a81
  15. 25 3月, 2009 1 次提交
  16. 16 3月, 2009 1 次提交
    • J
      Use f_lock to protect f_flags · db1dd4d3
      Jonathan Corbet 提交于
      Traditionally, changes to struct file->f_flags have been done under BKL
      protection, or with no protection at all.  This patch causes all f_flags
      changes after file open/creation time to be done under protection of
      f_lock.  This allows the removal of some BKL usage and fixes a number of
      longstanding (if microscopic) races.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      db1dd4d3
  17. 28 2月, 2009 1 次提交
  18. 08 1月, 2009 2 次提交
  19. 06 1月, 2009 1 次提交
    • C
      add a vfs_fsync helper · 4c728ef5
      Christoph Hellwig 提交于
      Fsync currently has a fdatawrite/fdatawait pair around the method call,
      and a mutex_lock/unlock of the inode mutex.  All callers of fsync have
      to duplicate this, but we have a few and most of them don't quite get
      it right.  This patch adds a new vfs_fsync that takes care of this.
      It's a little more complicated as usual as ->fsync might get a NULL file
      pointer and just a dentry from nfsd, but otherwise gets afile and we
      want to take the mapping and file operations from it when it is there.
      
      Notes on the fsync callers:
      
       - ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the
         	lower file
       - coda wasn't calling filemap_fdatawrite / filemap_fdatawait on the host
      	file, and returning 0 when ->fsync was missing
       - shm wasn't calling either filemap_fdatawrite / filemap_fdatawait nor
         taking i_mutex.  Now given that shared memory doesn't have disk
         backing not doing anything in fsync seems fine and I left it out of
         the vfs_fsync conversion for now, but in that case we might just
         not pass it through to the lower file at all but just call the no-op
         simple_sync_file directly.
      
      [and now actually export vfs_fsync]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4c728ef5
  20. 18 10月, 2008 2 次提交
  21. 17 10月, 2008 1 次提交
  22. 26 7月, 2008 1 次提交
  23. 22 7月, 2008 2 次提交
  24. 03 5月, 2008 1 次提交
  25. 25 4月, 2008 1 次提交