Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 接近 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 16 8月, 2005 2 次提交
  3. 12 8月, 2005 3 次提交
  5. 10 8月, 2005 1 次提交
  7. 09 8月, 2005 4 次提交
  9. 08 8月, 2005 1 次提交
  11. 07 8月, 2005 1 次提交
  13. 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
  15. 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
  17. 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
  19. 02 8月, 2005 2 次提交
  21. 30 7月, 2005 2 次提交
  23. 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
  25. 28 7月, 2005 9 次提交
    • 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
    • A
      [PATCH] Really __nocast-annotate kmalloc_node() · c10b8736
      由 Alexey Dobriyan 提交于 
      One chunk was lost somewhere between my and Andrew's machine.

Noticed by Victor Fusco.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c10b8736
  27. 27 7月, 2005 3 次提交
  29. 26 7月, 2005 1 次提交
  31. 25 7月, 2005 1 次提交
  33. 23 7月, 2005 2 次提交
  35. 22 7月, 2005 1 次提交
    • R
      [NETFILTER]: ip_conntrack_expect_related must not free expectation · 4acdbdbe
      由 Rusty Russell 提交于 
      If a connection tracking helper tells us to expect a connection, and
we're already expecting that connection, we simply free the one they
gave us and return success.

The problem is that NAT helpers (eg. FTP) have to allocate the
expectation first (to see what port is available) then rewrite the
packet.  If that rewrite fails, they try to remove the expectation,
but it was freed in ip_conntrack_expect_related.

This is one example of a larger problem: having registered the
expectation, the pointer is no longer ours to use.  Reference counting
is needed for ctnetlink anyway, so introduce it now.

To have a single "put" path, we need to grab the reference to the
connection on creation, rather than open-coding it in the caller.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4acdbdbe
  37. 19 7月, 2005 1 次提交