03 Dec, 2008
1 commit
-
Conflicts:
drivers/net/ixgbe/ixgbe_main.c
drivers/net/smc91x.c
27 Nov, 2008
1 commit
-
This is an implementation of David Miller's suggested fix in:
https://bugzilla.redhat.com/show_bug.cgi?id=470201It has been updated to use wait_event() instead of
wait_event_interruptible().Paraphrasing the description from the above report, it makes sendmsg()
block while UNIX garbage collection is in progress. This avoids a
situation where child processes continue to queue new FDs over a
AF_UNIX socket to a parent which is in the exit path and running
garbage collection on these FDs. This contention can result in soft
lockups and oom-killing of unrelated processes.Signed-off-by: dann frazier
Signed-off-by: David S. Miller
12 Nov, 2008
1 commit
-
Conflicts:
drivers/message/fusion/mptlan.c
drivers/net/sfc/ethtool.c
net/mac80211/debugfs_sta.c
10 Nov, 2008
1 commit
-
Previously I assumed that the receive queues of candidates don't
change during the GC. This is only half true, nothing can be received
from the queues (see comment in unix_gc()), but buffers could be added
through the other half of the socket pair, which may still have file
descriptors referring to it.This can result in inc_inflight_move_tail() erronously increasing the
"inflight" counter for a unix socket for which dec_inflight() wasn't
previously called. This in turn can trigger the "BUG_ON(total_refs <
inflight_refs)" in a later garbage collection run.Fix this by only manipulating the "inflight" counter for sockets which
are candidates themselves. Duplicating the file references in
unix_attach_fds() is also needed to prevent a socket becoming a
candidate for GC while the skb that contains it is not yet queued.Reported-by: Andrea Bittau
Signed-off-by: Miklos Szeredi
CC: stable@kernel.org
Signed-off-by: Linus Torvalds
02 Nov, 2008
1 commit
-
clean up net/unix/af_unix.c garbage.c sysctl_net_unix.c
Signed-off-by: Jianjun Kong
Signed-off-by: David S. Miller
27 Jul, 2008
1 commit
-
make it atomic_long_t; while we are at it, get rid of useless checks in affs,
hfs and hpfs - ->open() always has it equal to 1, ->release() - to 0.Signed-off-by: Al Viro
11 Nov, 2007
2 commits
-
The scan_inflight() routine scans through the unix sockets and calls
some passed callback. The fact is that all these callbacks work with
the unix_sock objects, not the sock ones, so make this conversion in
the scan_inflight() before calling the callbacks.This removes one unneeded variable from the inc_inflight_move_tail().
Signed-off-by: Pavel Emelyanov
Signed-off-by: David S. Miller -
This counter is _always_ modified under the unix_gc_lock spinlock,
so its atomicity can be provided w/o additional efforts.Signed-off-by: Pavel Emelyanov
Signed-off-by: David S. Miller
12 Jul, 2007
1 commit
-
Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one.The old one had a race with recvmsg, that resulted in false positives
and hence data loss. The old algorithm operated on all unix sockets
in the system, so any additional locking would have meant performance
problems for all users of these.The new algorithm instead only operates on "in flight" sockets, which
are very rare, and the additional locking for these doesn't negatively
impact the vast majority of users.In fact it's probable, that there weren't *any* heavy senders of
sockets over sockets, otherwise the above race would have been
discovered long ago.The patch works OK with the app that exposed the race with the old
code. The garbage collection has also been verified to work in a few
simple cases.Signed-off-by: Miklos Szeredi
Signed-off-by: David S. Miller
15 Feb, 2007
1 commit
-
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).Signed-off-by: Tim Schmielau
Acked-by: Russell King
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Feb, 2007
1 commit
-
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
09 Dec, 2006
1 commit
-
Signed-off-by: Josef Sipek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Mar, 2006
1 commit
-
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller
04 Jan, 2006
1 commit
-
This lock is actually taken mostly as a writer,
so using a rwlock actually just makes performance
worse especially on chips like the Intel P4.Signed-off-by: David S. Miller
30 Aug, 2005
2 commits
-
Lots of places just needs the states, not even linux/tcp.h, where this
enum was, needs it.This speeds up development of the refactorings as less sources are
rebuilt when things get moved from net/tcp.h.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
Remove the "list" member of struct sk_buff, as it is entirely
redundant. All SKB list removal callers know which list the
SKB is on, so storing this in sk_buff does nothing other than
taking up some space.Two tricky bits were SCTP, which I took care of, and two ATM
drivers which Francois Romieu fixed
up.Signed-off-by: David S. Miller
Signed-off-by: Francois Romieu
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
