- 23 Mar, 2007 11 commits
-
-
Ingo Molnar authored
Testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI state needs to be locked before we access it. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zilvinas Valinskas authored
Fixes a bogus lockdep warning which causes lockdep to disable itself. Acked-by:
-
Alan Stern authored
This patch (as870) adds a delay to ehci-hcd's bus_resume routine. Apparently there are controllers and/or BIOSes out there which need such a delay to get the ports back into their correct state. This fixes Bugzilla #8190. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Nick Piggin authored
madvise(MADV_REMOVE) can go into an infinite loop or cause an oops if the call covers a region from the start of a vma, and extending past that vma. Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: Badari Pulavarty <pbadari@us.ibm.com> Acked-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Jan Beulich authored
adjust legacy IDE resource setting (v2) The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
[IA64] fix NULL pointer in ia64/irq_chip-mask/unmask function This patch fixes boot failure because irq_desc->mask() is NULL. - Added mask/unmask functions to ia64's irq desc function table. - rename hw_interrupt_type to irq_chip. hw_interrupt_type is old name. - Tony: Added same change to arch/ia64/sn/kernel/irq.c as pointed out by Eric Biederman ... mask/unmask functions there can be no-op. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Michal Miroslaw authored
[NETFILTER]: nfnetlink_log: fix reference counting Fix reference counting (memory leak) problem in __nfulnl_send() and callers related to packet queueing. Signed-off-by:
Michal Miroslaw <mirq-linux@rere.qmqm.pl> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Paul Moore authored
The current CIPSO engine has a problem where it does not verify that the given sensitivity level has a valid CIPSO mapping when the "std" CIPSO DOI type is used. The end result is that bad packets are sent on the wire which should have never been sent in the first place. This patch corrects this problem by verifying the sensitivity level mapping similar to what is done with the category mapping. This patch also changes the returned error code in this case to -EPERM to better match what the category mapping verification code returns. Signed-off-by:
Paul Moore <paul.moore@hp.com> Acked-by:
James Morris <jmorris@namei.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Joerg Dorchain authored
Recent alterations to the gdth_fill_raw_cmd() path no longer set the sg_ranz field for zero transfer commands. However, this field is used lower down in the function to initialise ha->cmd_len to the size of the firmware packet. If this uninitialised field contains a bogus value, ha->cmd_len can become much larger than the actual firmware packet and end up oopsing in gdth_copy_cmd() as it tries to copy this huge packet to the device (usually because it runs into an unallocated page). The fix is to initialise the sg_ranz field to zero at the start of gdth_fill_raw_cmd(). Signed-off-by:
Joerg Dorchain <joerg@dorchain.net> Acked-by:
"Achim Leubner" <Achim_Leubner@adaptec.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Evgeniy Polyakov authored
[IPV4]: Fix rtm_to_ifaddr() error handling. Return negative error value (embedded in the pointer) instead of returning NULL. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Olaf Kirch authored
[IPV6]: Fix for ipv6_setsockopt NULL dereference I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
-
- 13 Mar, 2007 20 commits
-
-
Greg Kroah-Hartman authored
-
Herbert Xu authored
[UDP]: Reread uh pointer after pskb_trim The header may have moved when trimming. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Eric Dumazet authored
[INET]: twcal_jiffie should be unsigned long, not int Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
David Miller authored
[SPARC]: Fix bus handling in build_device_resources(). We mistakedly modify 'bus' in the innermost loop. What should happen is that at each register index iteration, we start with the same 'bus'. So preserve it's value at the top level, and use a loop local variable 'dbus' for iteration. This bug causes registers other than the first to be decoded improperly. Signed-off-by:
-
Philipp Reisner authored
[CONNECTOR]: Bugfix for cn_call_callback() When system under heavy stress and must allocate new work instead of reusing old one, new work must use correct completion callback. Patch is based on Philipp's and Lars' work. I only cleaned small stuff (and removed spaces instead of tabs). Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
Rainer Weikusat authored
At least the Keyspan USA-19HS USB-to-serial converter supports two different configurations, one where the input endpoints have interrupt transfer type and one where they are bulk endpoints. The default UHCI configuration uses the interrupt input endpoints. The keyspan driver, OTOH, assumes that the device has only bulk endpoints (all URBs are initialized by calling usb_fill_bulk_urb in keyspan.c/ keyspan_setup_urb). This causes the interval field of the input URBs to have a value of zero instead of one, which 'accidentally' worked with Linux at least up to 2.6.17.11 but stopped to with 2.6.18, which changed the UHCI support code handling URBs for interrupt endpoints. The patch below modifies to driver to initialize its input URBs either as interrupt or as bulk URBs, depending on the transfertype contained in the associated endpoint descriptor (only tested with the default configuration) enabling the driver to again receive data from the serial converter. Greg K-H reworked the patch. Signed-off-by:
Rainer Weikusat <rweikusat@sncag.com> Signed-off-by:
-
Johannes Berg authored
[NET]: Fix compat_sock_common_getsockopt typo. This patch fixes a typo in compat_sock_common_getsockopt. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
-
Larry Finger authored
Some versions of the bcm43xx chips only support 30-bit DMA, which means that the descriptors and buffers must be in the first 1 GB of RAM. On the i386 and x86_64 architectures with more than 1 GB RAM, an incorrect assignment may occur. This patch ensures that the various DMA addresses are within the capability of the chip. Testing has been limited to x86_64 as no one has an i386 system with more than 1 GB RAM. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Douglas Gilbert authored
- addresses the reported bug (with GFP_KERNEL -> GFP_ATOMIC) - improves error checking, and - is a subset of the changes to scsi_debug in lk 2.6.21-rc* Compiled and lightly tested (in lk 2.6.21-rc2 environment). Signed-off-by:
Douglas Gilbert <dougg@torque.net> Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: nfnetlink_log: fix crash on bridged packet physoutdev is only set on purely bridged packet, when nfnetlink_log is used in the OUTPUT/FORWARD/POSTROUTING hooks on packets forwarded from or to a bridge it crashes when trying to dereference skb->nf_bridge->physoutdev. Reported by Holger Eitzenberger <heitzenberger@astaro.com> Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: nfnetlink_log: zero-terminate prefix Userspace expects a zero-terminated string, so include the trailing zero in the netlink message. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: nf_conntrack: fix incorrect classification of IPv6 fragments as ESTABLISHED The individual fragments of a packet reassembled by conntrack have the conntrack reference from the reassembled packet attached, but nfctinfo is not copied. This leaves it initialized to 0, which unfortunately is the value of IP_CT_ESTABLISHED. The result is that all IPv6 fragments are tracked as ESTABLISHED, allowing them to bypass a usual ruleset which accepts ESTABLISHED packets early. Signed-off-by:
-
Yasuyuki Kozakai authored
[NETFILTER]: ip6_route_me_harder should take into account mark Signed-off-by:
Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by:
-
Michal Miroslaw authored
[NETFILTER]: nfnetlink_log: fix possible NULL pointer dereference Eliminate possible NULL pointer dereference in nfulnl_recv_config(). Signed-off-by:
-
Micha Mirosaw authored
[NETFILTER]: nfnetlink_log: fix NULL pointer dereference Fix the nasty NULL dereference on multiple packets per netlink message. BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004 printing eip: f8a4b3bf *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: nfnetlink_log ipt_ttl ipt_REDIRECT xt_tcpudp iptable_nat nf_nat nf_conntrack _ipv4 xt_state ipt_ipp2p xt_NFLOG xt_hashlimit ip6_tables iptable_filter xt_multiport xt_mark i pt_set iptable_raw xt_MARK iptable_mangle ip_tables cls_fw cls_u32 sch_esfq sch_htb ip_set_ipma p ip_set ipt_ULOG x_tables dm_snapshot dm_mirror loop e1000 parport_pc parport e100 floppy ide_ cd cdrom CPU: 0 EIP: 0060:[<f8a4b3bf>] Not tainted VLI EFLAGS: 00010206 (2.6.20 #5) EIP is at __nfulnl_send+0x24/0x51 [nfnetlink_log] eax: 00000000 ebx: f2b5cbc0 ecx: c03f5f54 edx: c03f4000 esi: f2b5cbc8 edi: c03f5f54 ebp: f8a4b3ec esp: c03f5f30 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, ti=c03f4000 task=c03bece0 task.ti=c03f4000) Stack: f2b5cbc0 f8a4b401 00000100 c0444080 c012af49 00000000 f6f19100 f6f19000 c1707800 c03f5f54 c03f5f54 00000123 00000021 c03e8d08 c0426380 00000009 c0126932 00000000 00000046 c03e9980 c03e6000 0047b007 c01269bd 00000000 Call Trace: [<f8a4b401>] nfulnl_timer+0x15/0x25 [nfnetlink_log] [<c012af49>] run_timer_softirq+0x10a/0x164 [<c0126932>] __do_softirq+0x60/0xba [<c01269bd>] do_softirq+0x31/0x35 [<c0104f6e>] do_IRQ+0x62/0x74 [<c01036cb>] common_interrupt+0x23/0x28 [<c0101018>] default_idle+0x0/0x3f [<c0101045>] default_idle+0x2d/0x3f [<c01010fa>] cpu_idle+0xa0/0xb9 [<c03fb7f5>] start_kernel+0x1a8/0x1ac [<c03fb293>] unknown_bootoption+0x0/0x181 ======================= Code: 5e 5f 5b 5e 5f 5d c3 53 89 c3 8d 40 1c 83 7b 1c 00 74 05 e8 2c ee 6d c7 83 7b 14 00 75 04 31 c0 eb 34 83 7b 10 01 76 09 8b 43 18 <66> c7 40 04 03 00 8b 53 34 8b 43 14 b9 40 00 00 00 e8 08 9a 84 EIP: [<f8a4b3bf>] __nfulnl_send+0x24/0x51 [nfnetlink_log] SS:ESP 0068:c03f5f30 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 5 seconds.. Panic no more! Signed-off-by: -
Patrick McHardy authored
[NETFILTER]: nfnetlink_log: fix use after free Paranoia: instance_put() might have freed the inst pointer when we spin_unlock_bh(). Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: nfnetlink_log: fix reference leak Stop reference leaking in nfulnl_log_packet(). If we start a timer we are already taking another reference. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: tcp conntrack: accept SYN|URG as valid Some stacks apparently send packets with SYN|URG set. Linux accepts these packets, so TCP conntrack should to. Pointed out by Martijn Posthuma <posthuma@sangine.com>. Signed-off-by: -
Patrick McHardy authored
[NETFILTER]: nf_conntrack/nf_nat: fix incorrect config ifdefs The nf_conntrack_netlink config option is named CONFIG_NF_CT_NETLINK, but multiple files use CONFIG_IP_NF_CONNTRACK_NETLINK or CONFIG_NF_CONNTRACK_NETLINK for ifdefs. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops Fix {nf,ip}_ct_iterate_cleanup unconfirmed list handling: - unconfirmed entries can not be killed manually, they are removed on confirmation or final destruction of the conntrack entry, which means we might iterate forever without making forward progress. This can happen in combination with the conntrack event cache, which holds a reference to the conntrack entry, which is only released when the packet makes it all the way through the stack or a different packet is handled. - taking references to an unconfirmed entry and using it outside the locked section doesn't work, the list entries are not refcounted and another CPU might already be waiting to destroy the entry What the code really wants to do is make sure the references of the hash table to the selected conntrack entries are released, so they will be destroyed once all references from skbs and the event cache are dropped. Since unconfirmed entries haven't even entered the hash yet, simply mark them as dying and skip confirmation based on that. Signed-off-by:
-
- 09 Mar, 2007 9 commits
-
-
Greg Kroah-Hartman authored
-
David S. Miller authored
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8134Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Eric W. Biederman authored
Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: "Luigi Genoni" <luigi.genoni@pirelli.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Marcel Holtmann authored
Based on a patch from Don Howard <dhoward@redhat.com> When calling write() with a buffer larger than 512 bytes, the driver's write buffer overflows, allowing to overwrite the EIP and execute arbitrary code with kernel privileges. In read(), there exists a similar problem, but coming from the device. A malicous or buggy device sending more than 512 bytes can overflow of the driver's read buffer, with the same effects as above. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
On 2/28/07, KOVACS Krisztian <hidden@balabit.hu> wrote: > > Hi, > > While reading TCP minisock code I've found this suspiciously looking > code fragment: > > - 8< - > struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb) > { > struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC); > > if (newsk != NULL) { > const struct inet_request_sock *ireq = inet_rsk(req); > struct tcp_request_sock *treq = tcp_rsk(req); > struct inet_connection_sock *newicsk = inet_csk(sk); > struct tcp_sock *newtp; > - 8< - > > The above code initializes newicsk to inet_csk(sk), isn't that supposed > to be inet_csk(newsk)? As far as I can tell this might leave > icsk_ack.last_seg_size zero even if we do have received data. Good catch! David, please apply the attached patch. Signed-off-by:Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Josef Whiter authored
Fix a locking mistake in the quota code, we do a mutex_lock instead of a mutex_unlock. Signed-off-by:
Josef Whiter <jwhiter@redhat.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Zhang, Yanmin authored
If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed irq number. On ia64 platform, such numbers are GSI and should be converted to irq vector. Signed-off-by:
Zhang Yanmin <yanmin.zhang@intel.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Gerhard Dirschl authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7810 - a silly copy-paste bug introduced by the latest change. Signed-off-by:
Gerhard Dirschl <gd@spherenet.de> Cc: Peter Osterlund <petero2@telia.com> Signed-off-by:
-
David Miller authored
CT based mach64 cards were reported to hang on sparc64 boxes when compiled with gcc-4.1.x and later. Looking at this piece of code, it's no surprise. A critical delay was implemented as an empty for() loop, and gcc 4.0.x and previous did not optimize it away, so we did get a delay. But gcc-4.1.x and later can optimize it away, and we get crashes. Use a real udelay() to fix this. Fix verified on SunBlade100. Signed-off-by:
-
