- Feb 24, 2007
-
-
Greg Kroah-Hartman authored
-
NeilBrown authored
If you lose this race, it can iput a socket inode twice and you get a BUG in fs/inode.c When I added the option for user-space to close a socket, I added some cruft to svc_delete_socket so that I could call that function when closing a socket per user-space request. This was the wrong thing to do. I should have just set SK_CLOSE and let normal mechanisms do the work. Not only wrong, but buggy. The locking is all wrong and it openned up a race where-by a socket could be closed twice. So this patch: Introduces svc_close_socket which sets SK_CLOSE then either leave the close up to a thread, or calls svc_delete_socket if it can get SK_BUSY. Adds a bias to sk_busy which is removed when SK_DEAD is set, This avoid races around shutting down the socket. Changes several 'spin_lock' to 'spin_lock_bh' where the _bh was missing. Bugzilla-url: http://bugzilla.kernel.org/show_bug.cgi?id=7916 Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Howells authored
Fix the key serial number collision avoidance code in key_alloc_serial(). This didn't use to be so much of a problem as the key serial numbers were allocated from a simple incremental counter, and it would have to go through two billion keys before it could possibly encounter a collision. However, now that random numbers are used instead, collisions are much more likely. This is fixed by finding a hole in the rbtree where the next unused serial number ought to be and using that by going almost back to the top of the insertion routine and redoing the insertion with the new serial number rather than trying to be clever and attempting to work out the insertion point pointer directly. This fixes kernel BZ #7727. Signed-off-by:
David Howells <dhowells@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ingo Molnar authored
fix deadlock in the 8139too driver: poll handlers should never forcibly enable local interrupts, because they might be used by netpoll/printk from IRQ context. ================================= [ INFO: inconsistent lock state ] 2.6.19 #11 --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes: (&npinfo->poll_lock){-+..}, at: [<c0350a41>] net_rx_action+0x64/0x1de {softirq-on-W} state was registered at: [<c0134c86>] mark_lock+0x5b/0x39c [<c0135012>] mark_held_locks+0x4b/0x68 [<c01351e9>] trace_hardirqs_on+0x115/0x139 [<c02879e6>] rtl8139_poll+0x3d7/0x3f4 [<c035c85d>] netpoll_poll+0x82/0x32f [<c035c775>] netpoll_send_skb+0xc9/0x12f [<c035cdcc>] netpoll_send_udp+0x253/0x25b [<c0288463>] write_msg+0x40/0x65 [<c011cead>] __call_console_drivers+0x45/0x51 [<c011cf16>] _call_console_drivers+0x5d/0x61 [<c011d4fb>] release_console_sem+0x11f/0x1d8 [<c011d7d7>] register_console+0x1ac/0x1b3 [<c02883f8>] init_netconsole+0x55/0x67 [<c010040c>] init+0x9a/0x24e [<c01049cf>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff irq event stamp: 819992 hardirqs last enabled at (819992): [<c0350a16>] net_rx_action+0x39/0x1de hardirqs last disabled at (819991): [<c0350b1e>] net_rx_action+0x141/0x1de softirqs last enabled at (817552): [<c01214e4>] __do_softirq+0xa3/0xa8 softirqs last disabled at (819987): [<c0106051>] do_softirq+0x5b/0xc9 other info that might help us debug this: no locks held by swapper/1. stack backtrace: [<c0104d88>] dump_trace+0x63/0x1e8 [<c0104f26>] show_trace_log_lvl+0x19/0x2e [<c010532d>] show_trace+0x12/0x14 [<c0105343>] dump_stack+0x14/0x16 [<c0134980>] print_usage_bug+0x23c/0x246 [<c0134d33>] mark_lock+0x108/0x39c [<c01356a7>] __lock_acquire+0x361/0x9ed [<c0136018>] lock_acquire+0x56/0x72 [<c03aff1f>] _spin_lock+0x35/0x42 [<c0350a41>] net_rx_action+0x64/0x1de [<c0121493>] __do_softirq+0x52/0xa8 [<c0106051>] do_softirq+0x5b/0xc9 [<c0121338>] irq_exit+0x3c/0x48 [<c0106163>] do_IRQ+0xa4/0xbd [<c01047c6>] common_interrupt+0x2e/0x34 [<c011db92>] vprintk+0x2c0/0x309 [<c011dbf6>] printk+0x1b/0x1d [<c01003f2>] init+0x80/0x24e [<c01049cf>] kernel_thread_helper+0x7/0x10 ======================= Signed-off-by:Ingo Molnar <mingo@elte.hu> Acked-by:
Jeff Garzik <jeff@garzik.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Dan Williams authored
Correct assignment of DOT1XENABLE in WE-19 codepaths. RX_UNENCRYPTED_EAPOL = 1 really means setting DOT1XENABLE _off_, and vice versa. The original WE-19 patch erroneously reversed that. This patch fixes association with unencrypted and WEP networks when using wpa_supplicant. It also adds two missing break statements that, left out, could result in incorrect card configuration. Applies to (I think) 2.6.19 and later. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Andi Kleen authored
Use different constraint for gcc < 4.1 in bitops.h +m is really correct for a RMW instruction, but some older gccs error out. I finally gave in and ifdefed it. This fixes compilation errors with some compiler version. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Takashi Iwai authored
The patch fixes the memory corruption by the support of unconventional sample rates. Also, it avoids the too restrictive constraints if any of usb descriptions contain continuous rates. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
This is a patch for ALSA Bug #2724. Some webcams provide bogus settings with no valid rates. With this patch those are skipped. Signed-off-by:
Gregor Jasny <gjasny@web.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
Takashi Iwai authored
The C-Media CM6501 chip's descriptors say that altsetting 5 supports 48 kHz, but it actually plays at 96 kHz. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Michael Buesch authored
If bcm43xx were to process an afterburner (ampdu) status response, Linux would oops. The ampdu and intermediate status bits are properly named. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop. Signed-off-by:
Larry <Finger<Larry.Finger@lwfinger.net> Signed-off-by:
-
Tejun Heo authored
80c test mask is at bits 18 and 19 of EIDE Controller Configuration not 22 and 23. Fix it. Signed-off-by:
Tejun Heo <htejun@gmail.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk>
-
Tejun Heo authored
eighty_ninty_three() had word 93 validitity check but not the 80c bit test itself (bit 12). This increases the chance of incorrect wire detection especially because host side cable detection is often unreliable and we sometimes soley depend on drive side cable detection. Fix it. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and forced by binary compatibility. UML/32bit breaks because of this - since it is wise enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host kernels. Until 2.6.17 (commit f0f2d653) we had: default: return sys_ptrace(request, pid, addr, data); Instead here we have: case PTRACE_GET_THREAD_AREA: case ...: return sys_ptrace(request, pid, addr, data); default: return -EINVAL; This change was a style change - when a case is added, it must be explicitly tested this way. In this case, not enough testing was done. Cc: Andi Kleen <ak@suse.de> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Ken Chen authored
An AIO bug was reported that sleeping function is being called in softirq context: BUG: warning at kernel/mutex.c:132/__mutex_lock_common() Call Trace: [<a000000100577b00>] __mutex_lock_slowpath+0x640/0x6c0 [<a000000100577ba0>] mutex_lock+0x20/0x40 [<a0000001000a25b0>] flush_workqueue+0xb0/0x1a0 [<a00000010018c0c0>] __put_ioctx+0xc0/0x240 [<a00000010018d470>] aio_complete+0x2f0/0x420 [<a00000010019cc80>] finished_one_bio+0x200/0x2a0 [<a00000010019d1c0>] dio_bio_complete+0x1c0/0x200 [<a00000010019d260>] dio_bio_end_aio+0x60/0x80 [<a00000010014acd0>] bio_endio+0x110/0x1c0 [<a0000001002770e0>] __end_that_request_first+0x180/0xba0 [<a000000100277b90>] end_that_request_chunk+0x30/0x60 [<a0000002073c0c70>] scsi_end_request+0x50/0x300 [scsi_mod] [<a0000002073c1240>] scsi_io_completion+0x200/0x8a0 [scsi_mod] [<a0000002074729b0>] sd_rw_intr+0x330/0x860 [sd_mod] [<a0000002073b3ac0>] scsi_finish_command+0x100/0x1c0 [scsi_mod] [<a0000002073c2910>] scsi_softirq_done+0x230/0x300 [scsi_mod] [<a000000100277d20>] blk_done_softirq+0x160/0x1c0 [<a000000100083e00>] __do_softirq+0x200/0x240 [<a000000100083eb0>] do_softirq+0x70/0xc0 See report: http://marc.theaimsgroup.com/?l=linux-kernel&m=116599593200888&w=2 flush_workqueue() is not allowed to be called in the softirq context. However, aio_complete() called from I/O interrupt can potentially call put_ioctx with last ref count on ioctx and triggers bug. It is simply incorrect to perform ioctx freeing from aio_complete. The bug is trigger-able from a race between io_destroy() and aio_complete(). A possible scenario: cpu0 cpu1 io_destroy aio_complete wait_for_all_aios { __aio_put_req ... ctx->reqs_active--; if (!ctx->reqs_active) return; } ... put_ioctx(ioctx) put_ioctx(ctx); __put_ioctx bam! Bug trigger! The real problem is that the condition check of ctx->reqs_active in wait_for_all_aios() is incorrect that access to reqs_active is not being properly protected by spin lock. This patch adds that protective spin lock, and at the same time removes all duplicate ref counting for each kiocb as reqs_active is already used as a ref count for each active ioctx. This also ensures that buggy call to flush_workqueue() in softirq context is eliminated. Signed-off-by:"Ken Chen" <kenchen@google.com> Cc: Zach Brown <zach.brown@oracle.com> Cc: Suparna Bhattacharya <suparna@in.ibm.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Badari Pulavarty <pbadari@us.ibm.com> Acked-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Atsushi Nemoto authored
The usage of the century bit was inverted on 2.6.19 following to PCF8563's description, but it was not match to usage suggested by RTC8564's datasheet. Anyway what MO_C=1 means can vary on each platform. This patch is to detect its polarity in get_datetime routine. The default value of c_polarity is 0 (MO_C=1 means 19xx) so that this patch does not change current behavior even if get_datetime was not called before set_datetime. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@teamlog.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Peter Korsgaard authored
smc911x_phy_configure's error handling unconditionally unlocks the spinlock even if it wasn't locked. Patch fixes it. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Oleg Nesterov authored
We are doing ->buf_prepare(buf) before adding buf to q->stream list. This means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer. (cherry picked from commit 419dd837) Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Krufky authored
Autodetect LG TAPC G701D as tuner type 37, fixing mis-detected tuners in some Hauppauge tv tuner cards. Thanks to Adonis Papas, for pointing this out. (cherry picked from commit 1323fbda) Signed-off-by:
-
Martin Samuelsson authored
Or status flags together in DECODER_GET_STATUS instead of and-zapping them. (cherry picked from commit 55d5440d) Signed-off-by:
Martin Samuelsson <sam@home.se> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Grant Likely authored
Host endianess does not affect the order that pixel rgb data comes in from the quickcam (the values are bytes, not words or longs). The driver is erroniously swapping the order of rgb values for big endian machines. This patch is needed get the Quickcam communicator working on big endian machines (tested on powerpc) (cherry picked from commit c6d704c8) Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
- Feb 20, 2007
-
-
Greg Kroah-Hartman authored
-
Greg Banks authored
Due to type confusion, when an nfsacl verison 2 'ACCESS' request finishes and tries to clean up, it calls fh_put on entiredly the wrong thing and this can cause an oops. Signed-off-by:
-
- Feb 05, 2007
-
-
Chris Wright authored
-
Ingo Molnar authored
Remove the __resched_legal() check: it is conceptually broken. The biggest problem it had is that it can mask buggy cond_resched() calls. A cond_resched() call is only legal if we are not in an atomic context, with two narrow exceptions: - if the system is booting - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set But __resched_legal() hid this and just silently returned whenever these primitives were called from invalid contexts. (Same goes for cond_resched_locked() and cond_resched_softirq()). Furthermore, the __legal_resched(0) call was buggy in that it caused unnecessarily long softirq latencies via cond_resched_softirq(). (which is only called from softirq-off sections, hence the code did nothing.) The fix is to resurrect the efficiency of the might_sleep checks and to only allow the narrow exceptions. Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Kirill Korotaev authored
move_task_off_dead_cpu() requires interrupts to be disabled, while migrate_dead() calls it with enabled interrupts. Added appropriate comments to functions and added BUG_ON(!irqs_disabled()) into double_rq_lock() and double_lock_balance() which are the origin sources of such bugs. Signed-off-by:
Kirill Korotaev <dev@openvz.org> Acked-by:
-
Trond Myklebust authored
This patch fixes a regression in 2.6.19 in which the use of multiple krb5 mounts against the same NFS server may result in an Oops on unmount. The Oops is due to the fact that multiple NFS krb5 clients may end up inadvertently sharing the same rpc_pipefs upcall pipe. The first client to 'umount' will unlink that shared pipe, causing an Oops. The solution is to give each client their own upcall pipe. This fix has been in mainline since 2.6.20-rc1. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> [chrisw: backport to 2.6.19.2] Signed-off-by:
-
Patrick McHardy authored
When the packet counter of a connection is zero a division by zero occurs in div64_64(). Fix that by using zero as average value, which is correct as long as the packet counter didn't overflow, at which point we have lost anyway. Additionally we're probably going to go back to 64 bit counters in 2.6.21. Based on patch from Jonas Berlin <xkr47@outerspace.dyndns.org>, with suggestions from KOVACS Krisztian <hidden@balabit.hu>. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Masayuki Nakagawa authored
I encountered a kernel panic with my test program, which is a very simple IPv6 client-server program. The server side sets IPV6_RECVPKTINFO on a listening socket, and the client side just sends a message to the server. Then the kernel panic occurs on the server. (If you need the test program, please let me know. I can provide it.) This problem happens because a skb is forcibly freed in tcp_rcv_state_process(). When a socket in listening state(TCP_LISTEN) receives a syn packet, then tcp_v6_conn_request() will be called from tcp_rcv_state_process(). If the tcp_v6_conn_request() successfully returns, the skb would be discarded by __kfree_skb(). However, in case of a listening socket which was already set IPV6_RECVPKTINFO, an address of the skb will be stored in treq->pktopts and a ref count of the skb will be incremented in tcp_v6_conn_request(). But, even if the skb is still in use, the skb will be freed. Then someone still using the freed skb will cause the kernel panic. I suggest to use kfree_skb() instead of __kfree_skb(). Signed-off-by:
Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Baruch Even authored
The sorting of SACK blocks actually munges them rather than sort, causing the TCP stack to ignore some SACK information and breaking the assumption of ordered SACK blocks after sorting. The sort takes the data from a second buffer which isn't moved causing subsequent data moves to occur from the wrong location. The fix is to use a temporary buffer as a normal sort does. Signed-off-By:
Baruch Even <baruch@ev-en.org> Signed-off-by:
-
Jarek Poplawski authored
The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE" changed to unconditional copying of ip_summed field from collapsed skb. This patch reverts this change. The majority of substantial work including heavy testing and diagnosing by: Michael Tokarev <mjt@tls.msk.ru> Possible reasons pointed by: Herbert Xu and Patrick McHardy. Signed-off-by:
Jarek Poplawski <jarkao2@o2.pl> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David S. Miller authored
If the device is down, invoking the device hard header callbacks is not legal, so check it early. Based upon a shaper OOPS report from Frederik Deweerdt. Signed-off-by:
-
David S. Miller authored
This fixes a bug introduced by: commit fda9ef5d Author: Dmitry Mishin <dim@openvz.org> Date: Thu Aug 31 15:28:39 2006 -0700 [NET]: Fix sk->sk_filter field access sk_run_filter() returns either 0 or an unsigned 32-bit length which says how much of the packet to retain. If that 32-bit unsigned integer is larger than the packet, this is fine we just leave the packet unchanged. The above commit caused all filter return values which were negative when interpreted as a signed integer to indicate a packet drop, which is wrong. Based upon a report and initial patch by Raivis Bucis. Signed-off-by:
-
Robert Olsson authored
When main table is just a single leaf this gets printed as belonging to the local table in /proc/net/fib_trie. A fix is below. Signed-off-by:
Robert Olsson <robert.olsson@its.uu.se> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
In a kernel with trie routing enabled I had a simple routing setup with only a single route to the outside world and no default route. "ip route table list main" showed my the route just fine but /proc/net/route was an empty file. What was going on? Thinking it was a bug in something I did and I looked deeper. Eventually I setup a second route and everything looked correct, huh? Finally I realized that the it was just the iterator pair in fib_trie_get_first, fib_trie_get_next just could not handle a routing table with a single entry. So to save myself and others further confusion, here is a simple fix for the fib proc iterator so it works even when there is only a single route in a routing table. Signed-off-by:
-
Bob Breuer authored
In some cases such as: iph->check = 0; iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); GCC may optimize out the previous store. Observed as a failure of NFS over udp (bad checksums on ip fragments) when compiled with GCC 3.4.2. Signed-off-by:
Bob Breuer <breuerr@mc.net> Signed-off-by:
-
Eric W. Biederman authored
While enhancing the neighbour code to handle multiple network namespaces I noticed that decnet is assuming neigh_parms_alloc will allways succeed, which is clearly wrong. So handle the failure. Signed-off-by:
Steven Whitehouse <steve@chygwyn.com> Signed-off-by:
-
ethanhsiao@jmicron.com authored
jmicron module detects all JMB36x as JMB361 and PATA0 has wrong pin status of XICBLID. Cc: Jeff Garzik <jeff@garzik.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Andy Gospodarek authored
While working with the latest bonding code I noticed a nasty problem that will prevent arp monitoring from always functioning correctly on x86_64 systems. Comparing ints to longs and expecting reliable results on x86_64 is a bad idea. With this patch, arp monitoring works correctly again. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Stephen Hemminger <shemminger@osdl.org> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeff Dike authored
Use the same signal frame alignment calculations as the underlying architecture. x86_64 appeared to do this, but the "- 8" was really subtracting 8 * sizeof(struct rt_sigframe) rather than 8 bytes. UML/i386 might have been OK, but I changed the calculation to match i386 just to be sure. Signed-off-by:
Jeff Dike <jdike@addtoit.com> Cc: <stable@kernel.org> Cc: Adrian Bunk <bunk@stusta.de> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by:
Antoine Martin <antoine@nagafix.co.uk> Signed-off-by:
-
