1. 29 8月, 2005 1 次提交
    • J
      [libata] license change, other bits · af36d7f0
      Jeff Garzik 提交于
      - changes license of all code from OSL+GPL to plain ole GPL
        - except for NVIDIA, who hasn't yet responded about sata_nv
        - copyright holders were already contacted privately
      
      - adds info in each driver about where hardware/protocol docs may be
        obtained
      
      - where I have made major contributions, updated copyright dates
      af36d7f0
  2. 20 8月, 2005 1 次提交
    • L
      Fix nasty ncpfs symlink handling bug. · cc314eef
      Linus Torvalds 提交于
      This bug could cause oopses and page state corruption, because ncpfs
      used the generic page-cache symlink handlign functions.  But those
      functions only work if the page cache is guaranteed to be "stable", ie a
      page that was installed when the symlink walk was started has to still
      be installed in the page cache at the end of the walk.
      
      We could have fixed ncpfs to not use the generic helper routines, but it
      is in many ways much cleaner to instead improve on the symlink walking
      helper routines so that they don't require that absolute stability.
      
      We do this by allowing "follow_link()" to return a error-pointer as a
      cookie, which is fed back to the cleanup "put_link()" routine.  This
      also simplifies NFS symlink handling.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc314eef
  3. 19 8月, 2005 6 次提交
  4. 17 8月, 2005 2 次提交
  5. 16 8月, 2005 2 次提交
  6. 12 8月, 2005 3 次提交
  7. 10 8月, 2005 1 次提交
  8. 09 8月, 2005 4 次提交
  9. 08 8月, 2005 1 次提交
  10. 07 8月, 2005 1 次提交
  11. 06 8月, 2005 1 次提交
    • T
      [PATCH] blk: fix tag shrinking (revive real_max_size) · ba025082
      Tejun Heo 提交于
      My patch in commit fa72b903 incorrectly
      removed blk_queue_tag->real_max_depth.
      
      The original resize implementation was incorrect in the following
      points.
      
       * actual allocation size of tag_index was shorter than real_max_size,
         but assumed to be of the same size, possibly causing memory access
         beyond the allocated area.
       * bits in tag_map between max_deptn and real_max_depth were
         initialized to 1's, making the tags permanently reserved.
      
      In an attempt to fix above two bugs, I had removed allocation optimization
      in init_tag_map and real_max_size.  Tag map/index were allocated and freed
      immediately during resize.
      
      Unfortunately, I wasn't considering that tag map/index can be resized
      dynamically with tags beyond new_depth active.  This led to accessing
      freed area after shrinking tags and led to the following bug reporting
      thread on linux-scsi.
      
         http://marc.theaimsgroup.com/?l=linux-scsi&m=112319898111885&w=2
      
      To fix the problem, I've revived real_max_depth without allocation
      optimization in init_tag_map, and Andrew Vasquez confirmed that the
      problem was fixed.  As Jens is not going to be available for a week, he
      asked me to make sure that this patch reaches you.
      
         http://marc.theaimsgroup.com/?l=linux-scsi&m=112325778530886&w=2
      
      Also, a comment was added to make sure that real_max_size is needed for
      dynamic shrinking.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ba025082
  12. 05 8月, 2005 3 次提交
    • J
      [PATCH] Clean up inotify delete race fix · 0c3dba15
      John McCutchan 提交于
      This avoids the whole #ifdef mess by just getting a copy of
      dentry->d_inode before d_delete is called - that makes the codepaths the
      same for the INOTIFY/DNOTIFY cases as for the regular no-notify case.
      I've been running this under a Gnome session for the last 10 minutes.
      Inotify is being used extensively.
      Signed-off-by: NJohn McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c3dba15
    • J
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · fec59a71
      John W. Linville 提交于
      Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
      (including BARs) when transitioning from D3hot->D0.  This leaves such
      a device in an inaccessible state.  The patch below causes the BARs
      to be restored when enabling such a device, so that its driver will
      be able to access it.
      
      The patch also adds pci_restore_bars as a new global symbol, and adds a
      correpsonding EXPORT_SYMBOL_GPL for that.
      
      Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
      (re)boot.  Most drivers call pci_enable_device very early, so devices
      left in D3hot that lose configuration during the D3hot->D0 transition
      will be inaccessible to their drivers.
      
      Drivers could be modified to account for this, but it would
      be difficult to know which drivers need modification.  This is
      especially true since often many devices are covered by the same
      driver.  It likely would be necessary to replicate code across dozens
      of drivers.
      
      The patch below should trigger only when transitioning from D3hot->D0
      (or at boot), and only for devices that have the "no soft reset" bit
      cleared in the PM control register.  I believe it is safe to include
      this patch as part of the PCI infrastructure.
      
      The cleanest implementation of pci_restore_bars was to call
      pci_update_resource.  Unfortunately, that does not currently exist
      for the sparc64 architecture.  The patch below includes a null
      implemenation of pci_update_resource for sparc64.
      
      Some have expressed interest in making general use of the the
      pci_restore_bars function, so that has been exported to GPL licensed
      modules.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fec59a71
    • N
      [PATCH] md: make sure md bitmap updates are flushed when array is stopped. · 6b8b3e8a
      NeilBrown 提交于
      The recent change to never ignore the bitmap, revealed that the bitmap isn't
      begin flushed properly when an array is stopped.
      
      We call bitmap_daemon_work three times as there is a three-stage pipeline for
      flushing updates to the bitmap file.
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6b8b3e8a
  13. 04 8月, 2005 1 次提交
    • N
      [PATCH] fix get_user_pages bug · f33ea7f4
      Nick Piggin 提交于
      Checking pte_dirty instead of pte_write in __follow_page is problematic
      for s390, and for copy_one_pte which leaves dirty when clearing write.
      
      So revert __follow_page to check pte_write as before, and make
      do_wp_page pass back a special extra VM_FAULT_WRITE bit to say it has
      done its full job: once get_user_pages receives this value, it no longer
      requires pte_write in __follow_page.
      
      But most callers of handle_mm_fault, in the various architectures, have
      switch statements which do not expect this new case.  To avoid changing
      them all in a hurry, make an inline wrapper function (using the old
      name) that masks off the new bit, and use the extended interface with
      double underscores.
      
      Yes, we do have a call to do_wp_page from do_swap_page, but no need to
      change that: in rare case it's needed, another do_wp_page will follow.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      [ Cleanups by Nick Piggin ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f33ea7f4
  14. 02 8月, 2005 2 次提交
  15. 30 7月, 2005 2 次提交
  16. 29 7月, 2005 1 次提交
    • L
      Revert broken "statement with no effect" warning fix · 2ac6608c
      Linus Torvalds 提交于
      It may shut up gcc, but it also incorrectly changes the semantics of the
      smp_call_function() helpers.
      
      You can fix the warning other ways if you are interested (create another
      inline function that takes no arguments and returns zero), but
      preferably gcc just shouldn't complain about unused return values from
      statement expressions in the first place.
      2ac6608c
  17. 28 7月, 2005 8 次提交
    • R
      [PATCH] alpha: fix "statement with no effect" warnings · 79a88102
      Richard Henderson 提交于
      Apparently gcc 4.0 complains about "({ 0; });", which leads to -Werror
      breakage in one of the alpha oprofile modules.
      
      One might could argue that this is a gcc bug, in that statement-expressions
      should be considered to be function-like rather than statement-like for the
      purposes of this warning.  But it's just as easy to use an inline function
      in the first place, side-stepping the issue.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      79a88102
    • R
      [PATCH] serial_core whitespace fix · e5c2d749
      Ralf Baechle 提交于
      Use tabs for formatting like anywhere else in this file.
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e5c2d749
    • O
      [PATCH] turn many #if $undefined_string into #ifdef $undefined_string · 44456d37
      Olaf Hering 提交于
      turn many #if $undefined_string into #ifdef $undefined_string to fix some
      warnings after -Wno-def was added to global CFLAGS
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      44456d37
    • A
      [PATCH] mbcache: Remove unused mb_cache_shrink parameter · 8c52ab42
      Andreas Gruenbacher 提交于
      The cache parameter to mb_cache_shrink isn't used.  We may as well remove
      it.
      Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8c52ab42
    • P
      [PATCH] stale POSIX lock handling · c293621b
      Peter Staubach 提交于
      I believe that there is a problem with the handling of POSIX locks, which
      the attached patch should address.
      
      The problem appears to be a race between fcntl(2) and close(2).  A
      multithreaded application could close a file descriptor at the same time as
      it is trying to acquire a lock using the same file descriptor.  I would
      suggest that that multithreaded application is not providing the proper
      synchronization for itself, but the OS should still behave correctly.
      
      SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
      a file descriptor is closed, that all POSIX locks on the file, owned by the
      process which closed the file descriptor, should be released.
      
      The trick here is when those locks are released.  The current code releases
      all locks which exist when close is processing, but any locks in progress
      are handled when the last reference to the open file is released.
      
      There are three cases to consider.
      
      One is the simple case, a multithreaded (mt) process has a file open and
      races to close it and acquire a lock on it.  In this case, the close will
      release one reference to the open file and when the fcntl is done, it will
      release the other reference.  For this situation, no locks should exist on
      the file when both the close and fcntl operations are done.  The current
      system will handle this case because the last reference to the open file is
      being released.
      
      The second case is when the mt process has dup(2)'d the file descriptor.
      The close will release one reference to the file and the fcntl, when done,
      will release another, but there will still be at least one more reference
      to the open file.  One could argue that the existence of a lock on the file
      after the close has completed is okay, because it was acquired after the
      close operation and there is still a way for the application to release the
      lock on the file, using an existing file descriptor.
      
      The third case is when the mt process has forked, after opening the file
      and either before or after becoming an mt process.  In this case, each
      process would hold a reference to the open file.  For each process, this
      degenerates to first case above.  However, the lock continues to exist
      until both processes have released their references to the open file.  This
      lock could block other lock requests.
      
      The changes to release the lock when the last reference to the open file
      aren't quite right because they would allow the lock to exist as long as
      there was a reference to the open file.  This is too long.
      
      The new proposed solution is to add support in the fcntl code path to
      detect a race with close and then to release the lock which was just
      acquired when such as race is detected.  This causes locks to be released
      in a timely fashion and for the system to conform to the POSIX semantic
      specification.
      
      This was tested by instrumenting a kernel to detect the handling locks and
      then running a program which generates case #3 above.  A dangling lock
      could be reliably generated.  When the changes to detect the close/fcntl
      race were added, a dangling lock could no longer be generated.
      
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c293621b
    • M
      [PATCH] s390: spin lock retry · 951f22d5
      Martin Schwidefsky 提交于
      Split spin lock and r/w lock implementation into a single try which is done
      inline and an out of line function that repeatedly tries to get the lock
      before doing the cpu_relax().  Add a system control to set the number of
      retries before a cpu is yielded.
      
      The reason for the spin lock retry is that the diagnose 0x44 that is used to
      give up the virtual cpu is quite expensive.  For spin locks that are held only
      for a short period of time the costs of the diagnoses outweights the savings
      for spin locks that are held for a longer timer.  The default retry count is
      1000.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      951f22d5
    • A
      [PATCH] consolidate CONFIG_WATCHDOG_NOWAYOUT handling · 4bfdf378
      Andrey Panin 提交于
      Attached patch removes #ifdef CONFIG_WATCHDOG_NOWAYOUT mess duplicated in
      almost every watchdog driver and replaces it with common define in
      linux/watchdog.h.
      Signed-off-by: NAndrey Panin <pazke@donpac.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4bfdf378
    • O
      [PATCH] i4l: add Olitec ISDN PCI card in hisax gazel driver · 49f29915
      Olivier Blin 提交于
      This patch adds support for the Olitec ISDN PCI card in the hisax gazel
      driver.  The gazel driver supports this card, but wasn't aware of its PCI
      ids.  Users used to modify the PCI ids of a supported card in
      include/linux/pci_ids.h and recompile their kernel to get this card
      running, as said in most Howtos.  This patch makes the hisax gazel driver
      recognize the PCI ids of the Olitec ISDN PCI card.
      Signed-off-by: NOlivier Blin <oblin@mandriva.com>
      Signed-off-by: NKarsten Keil <kkeil@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      49f29915