1. 15 11月, 2011 1 次提交
    • M
      USB: gadgetfs: gadgetfs_disconnect: fix inconsistent lock state · 001428e4
      Marc Kleine-Budde 提交于
      Under certain circumstances lockdep finds an inconsistent lock state in
      gadgetfs. The problem can be reproduced with a hardware using the
      ci13xxx_udc driver and the gadgetfs test program (needs a patch to support
      the ci13xxx_udc, though):
      	http://www.linux-usb.org/gadget/usb.c
      Start the test program, wait to initialize, then press Ctrl+c.
      
      This patch fixes the following problem by using spin_lock_irqsave()
      instead of spin_lock().
      
      =================================
      [ INFO: inconsistent lock state ]
      3.1.0-rc6+ #158
      ---------------------------------
      inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
      {IN-HARDIRQ-W} state was registered at:
        [<c00596b8>] mark_irqflags+0x14c/0x1ac
        [<c0059bf8>] __lock_acquire+0x4e0/0x8f0
        [<c005a698>] lock_acquire+0x98/0x1a8
        [<c02f10e0>] _raw_spin_lock+0x54/0x8c
        [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
        [<c0229104>] _gadget_stop_activity+0xd4/0x154
        [<c022b130>] isr_reset_handler+0x34/0x1c0
        [<c022c320>] udc_irq+0x204/0x228
        [<c0069018>] handle_irq_event_percpu+0x64/0x3a0
        [<c0069390>] handle_irq_event+0x3c/0x5c
        [<c006ae5c>] handle_level_irq+0x8c/0x10c
        [<c0068a34>] generic_handle_irq+0x30/0x44
        [<c0009b2c>] handle_IRQ+0x30/0x84
        [<c0008ef8>] __irq_svc+0x38/0x60
        [<c0009c58>] default_idle+0x30/0x34
        [<c0009e30>] cpu_idle+0x9c/0xd8
        [<c04056f4>] start_kernel+0x278/0x2bc
      irq event stamp: 6412
      hardirqs last  enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c
      hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0
      softirqs last  enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8
      softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&dev->lock)->rlock);
        <Interrupt>
          lock(&(&dev->lock)->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by usb/113:
       #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
      
      stack backtrace:
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4)
      [<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274)
      [<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0)
      [<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac)
      [<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0)
      [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
      [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c)
      [<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs])
      [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154)
      [<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c)
      [<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
      [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
      [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs])
      [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0)
      [<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74)
      [<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150)
      [<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      001428e4
  2. 10 9月, 2011 1 次提交
    • K
      usb gadget: clean up FSF boilerplate text · 28c9fc68
      Klaus Schwarzkopf 提交于
      remove the following two paragraphs as they are not needed:
      
      This program is distributed in the hope that it will be useful, but
      WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
      FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
      License for more details.
      
      You should have received a copy of the GNU General Public License along with
      this program; if not, write to the Free Software Foundation, Inc.,59
      Temple Place - Suite 330, Boston, MA  02111-1307, USA.
      Signed-off-by: NKlaus Schwarzkopf <schwarzkopf@sensortherm.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      28c9fc68
  3. 02 7月, 2011 1 次提交
  4. 29 6月, 2011 1 次提交
  5. 07 6月, 2011 1 次提交
  6. 14 4月, 2011 1 次提交
  7. 29 10月, 2010 1 次提交
  8. 26 10月, 2010 1 次提交
    • C
      fs: do not assign default i_ino in new_inode · 85fe4025
      Christoph Hellwig 提交于
      Instead of always assigning an increasing inode number in new_inode
      move the call to assign it into those callers that actually need it.
      For now callers that need it is estimated conservatively, that is
      the call is added to all filesystems that do not assign an i_ino
      by themselves.  For a few more filesystems we can avoid assigning
      any inode number given that they aren't user visible, and for others
      it could be done lazily when an inode number is actually needed,
      but that's left for later patches.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      85fe4025
  9. 23 10月, 2010 1 次提交
  10. 05 10月, 2010 1 次提交
    • A
      BKL: Remove BKL from USB gadgetfs · cdbd2b01
      Arnd Bergmann 提交于
      The BKL is only used in fill_super, which is  protected by the superblocks
      s_umount rw_semaphore. Therefore it is safe to remove the BKL entirely.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: linux-usb@vger.kernel.org
      cdbd2b01
  11. 11 8月, 2010 2 次提交
  12. 03 3月, 2010 1 次提交
  13. 05 10月, 2009 1 次提交
  14. 22 9月, 2009 1 次提交
  15. 16 6月, 2009 1 次提交
  16. 25 3月, 2009 1 次提交
  17. 06 1月, 2009 1 次提交
  18. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  19. 26 7月, 2008 1 次提交
  20. 22 7月, 2008 1 次提交
  21. 10 7月, 2008 1 次提交
  22. 25 4月, 2008 1 次提交
  23. 25 3月, 2008 1 次提交
  24. 02 2月, 2008 1 次提交
  25. 13 10月, 2007 2 次提交
  26. 31 7月, 2007 1 次提交
  27. 13 7月, 2007 3 次提交
  28. 09 6月, 2007 1 次提交
    • D
      USB: usb gadgets avoid le{16,32}_to_cpup() · 01ee7d70
      David Brownell 提交于
      It turns out that le16_to_cpup() and le32_to_cpup() aren't always safe
      to call with pointers into packed structures, since those are inlined
      functions and GCC may lose the "packed" attribute.  So those references
      can become unaligned kernel accesses, which are evil on some hardware.
      
      This patch updates uses of those routines in the gadget stack.  The
      references into packed structures can just use leXX_to_cpu(*x), which
      in most cases is more natural.  Some other uses in RNDIS, mostly in
      debug code, were wrong in the first place; those use get_unaligned().
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      01ee7d70
  29. 24 2月, 2007 1 次提交
  30. 08 2月, 2007 7 次提交