- 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:
Neil Brown <neilb@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- Dec 16, 2006
-
-
Chris Wright authored
-
Arjan van de Ven authored
On the Core2 cpus, the rdtsc instruction is not serializing (as defined in the architecture reference since rdtsc exists) and due to the deep speculation of these cores, it's possible that you can observe time go backwards between cores due to this speculation. Since the kernel already deals with this with the SYNC_RDTSC flag, the solution is simple, only assume that the instruction is serializing on family 15... The price one pays for this is a slightly slower gettimeofday (by a dozen or two cycles), but that increase is quite small to pay for a really-going-forward tsc counter. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Andi Kleen <ak@suse.de> [chrisw: backported to 2.6.18] Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Marcel Holtmann authored
With malformed packets it might be possible to overwrite internal CMTP and CAPI data structures. This patch adds additional length checks to prevent these kinds of remote attacks. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Daniel Barkalow authored
At least some nforce cards continue to send legacy interrupts when MSI is enabled, and these interrupts are treated as unhandled by the kernel. This patch disables legacy interrupts explicitly when enabling MSI mode. The correct fix is to change the MSI infrastructure to disable legacy interrupts when enabling MSI, but this is potentially risky if the device isn't PCI-2.3 or is quirky, so the correct fix is going into mainline, while patches like this one go into -stable. Legend has it that it is most correct to disable legacy interrupts before enabling MSI, but the mainline patch does it in the other order, and this patch is "obviously" the same as mainline. Signed-off-by:
Daniel Barkalow <barkalow@iabervon.org> Signed-off-by:
-
Hirokazu Takata authored
The m32r kernel 2.6.18-rc1 or after cause build errors of "unknown isa configuration" for userspace application programs, such as glibc, gdb, etc. This is because the recent kernel do not include linux/config.h not to expose kernel headers for userspace. To fix the above compile errors, this patch fixes two headers ptrace.h and sigcontext.h for m32r and makes them platform-independent. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Zachary Amsden authored
It is possible to have tasklets get scheduled before softirqd has had a chance to spawn on all CPUs. This is totally harmless; after success during action CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes softirqd on the appropriate CPU to process the already pending tasklets. So there is no danger of having a missed wakeup for any tasklets that were already pending. In particular, i386 is affected by this during startup, and is visible when using a very large initrd; during the time it takes for the initrd to be decompressed, a timer IRQ can come in and schedule RCU callbacks. It is also possible that resending of a hardware IRQ via a softirq triggers the same bug. Because of different timing conditions, this shows up in all emulators and virtual machines tested, including Xen, VMware, Virtual PC, and Qemu. It is also possible to trigger on native hardware with a large enough initrd, although I don't have a reliable case demonstrating that. Signed-off-by:
Zachary Amsden <zach@vmware.com> Cc: <caglar@pardus.org.tr> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> Signed-off-by:
-
Andrey Mirkin authored
OpenVZ Linux kernel team has found a problem with mounting in compat mode. Simple command "mount -t smbfs ..." on Fedora Core 5 distro in 32-bit mode leads to oops: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 PGD 34d48067 PUD 34d03067 PMD 0 Oops: 0000 [1] SMP CPU: 0 Modules linked in: iptable_nat simfs smbfs ip_nat ip_conntrack vzdquota parport_pc lp parport 8021q bridge llc vznetdev vzmon nfs lockd sunrpc vzdev iptable_filter af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle xt_limit ipt_tos ipt_REJECT ip_tables x_tables thermal processor fan button battery asus_acpi ac uhci_hcd ehci_hcd usbcore i2c_i801 i2c_core e100 mii floppy ide_cd cdrom Pid: 14656, comm: mount RIP: 0060:[<ffffffff802bc7c6>] [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP: 0000:ffff810034d31f38 EFLAGS: 00010292 RAX: 000000000000002c RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff810034c86bc0 RSI: 0000000000000096 RDI: ffffffff8061fc90 RBP: ffff810034d31f78 R08: 0000000000000000 R09: 000000000000000d R10: ffff810034d31e58 R11: 0000000000000001 R12: ffff810039dc3000 R13: 000000000805ea48 R14: 0000000000000000 R15: 00000000c0ed0000 FS: 0000000000000000(0000) GS:ffffffff80749000(0033) knlGS:00000000b7d556b0 CS: 0060 DS: 007b ES: 007b CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000034d43000 CR4: 00000000000006e0 Process mount (pid: 14656, veid=300, threadinfo ffff810034d30000, task ffff810034c86bc0) Stack: 0000000000000000 ffff810034dd0000 ffff810034e4a000 000000000805ea48 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000805ea48 ffffffff8021e64e 0000000000000000 0000000000000000 Call Trace: [<ffffffff8021e64e>] ia32_sysret+0x0/0xa Code: 83 3b 06 0f 85 41 01 00 00 0f b7 43 0c 89 43 14 0f b7 43 0a RIP [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP <ffff810034d31f38> CR2: 0000000000000000 The problem is that data_page pointer can be NULL, so we should skip data conversion in this case. Signed-off-by:
Andrey Mirkin <amirkin@openvz.org> Cc: <stable@kernel.org> Signed-off-by:
-
Russell King authored
Later glibc requires the *at syscalls. Add them. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Stefan Richter authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431 iBook G3 threw a machine check exception and put the display backlight to full brightness after ohci1394 was unloaded and reloaded. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> [dsd@gentoo.org: also added missing if condition, commit 63cca59e ] Signed-off-by:
Daniel Drake <dsd@gentoo.org> Acked-by:
-
Hans Verkuil authored
The TUNER_LG_NTSC_TAPE is identical in all respects to the TUNER_PHILIPS_FM1236_MK3. So use the params struct for the Philips tuner. Also add this LG_NTSC_TAPE tuner to the switches where radio specific parameters are set so it behaves like a TUNER_PHILIPS_FM1236_MK3. This change fixes the radio support for this tuner (the wrong bandswitch byte was used). Thanks to Andy Walls <cwalls@radix.net> for finding this bug. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Krufky authored
In some cases when using VSB, the AGC status register has been known to falsely report "no signal" when in fact there is a carrier lock. The datasheet labels these status flags as QAM only, yet the lgdt330x module is using these flags for both QAM and VSB. This patch allows for the carrier recovery lock status register to be tested, even if the agc signal status register falsely reports no signal. Thanks to jcrews from #linuxtv in irc, for initially reporting this bug. Signed-off-by:
-
Andy Gospodarek authored
This is a small fix-up to finish out the work done by Jay Vosburgh to add carrier-state support for bonding devices. The output in /proc/net/bonding/bondX was correct, but when collecting the same info via an iotcl it could still be incorrect. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Cc: Jeff Garzik <jeff@garzik.org> Cc: Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeet Chaudhuri authored
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in. This fixes an oops reported (and fixed) by Jeet Chaudhuri, when max_sdu_size is greater than 0. Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Miller authored
We grab a reference to the route's inetpeer entry but forget to release it in xfrm4_dst_destroy(). Bug discovered by Kazunori MIYAZAWA <kazunori@miyazawa.org> Signed-off-by:
-
Milan Broz authored
Fix oops when removing full snapshot kernel bugzilla bug 7040 If a snapshot became invalid (full) while there is outstanding pending_exception, pending_complete() forgets to remove the corresponding exception from its exception table before freeing it. Already fixed in 2.6.19. Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
-
David Miller authored
Currently the behaviour of disable_xfrm is inconsistent between locally generated and forwarded packets. For locally generated packets disable_xfrm disables the policy lookup if it is set on the output device, for forwarded traffic however it looks at the input device. This makes it impossible to disable xfrm on all devices but a dummy device and use normal routing to direct traffic to that device. Always use the output device when checking disable_xfrm. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Jurij Smakov authored
The following patch fixes the failure of sunhme drivers on x86 hosts due to missing pci_enable_device() and pci_set_master() calls, lost during code refactoring. It has been filed as bugzilla bug #7502 [0] and Debian bug #397460 [1]. [0] http://bugzilla.kernel.org/show_bug.cgi?id=7502 [1] http://bugs.debian.org/397460 Signed-off-by:
Jurij Smakov <jurij@wooyd.org> Signed-off-by:
-
David Miller authored
Not returning -EINVAL, because someone might want to use the value zero in some future gact_prob algorithm? Signed-off-by:
Kim Nordlund <kim.nordlund@nokia.com> Signed-off-by:
-
Patrick McHardy authored
Signed-off-by:
-
Christophe Saout authored
Fix corruption issue with dm-crypt on top of software raid5. Cancelled readahead bio's that report no error, just have BIO_UPTODATE cleared were reported as successful reads to the higher layers (and leaving random content in the buffer cache). Already fixed in 2.6.19. Signed-off-by:
Christophe Saout <christophe@saout.de> Signed-off-by:
-
Patrick McHardy authored
The tc actions increased the size of struct tc_police, which broke compatibility with old iproute binaries since both the act_police and the old NET_CLS_POLICE code check for an exact size match. Since the new members are not even used, the simple fix is to also accept the size of the old structure. Dumping is not affected since old userspace will receive a bigger structure, which is handled fine. Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
No need to revisit a chain we'd already finished with during the check for current hook. It's either instant loop (which we'd just detected) or a duplicate work. Signed-off-by:
-
Al Viro authored
We need that for iterator to work; existing check had been too weak. Signed-off-by:
-
Al Viro authored
We need to verify that a) we are not too close to the end of buffer to dereference b) next entry we'll be checking won't be _before_ our While we are at it, don't subtract unrelated pointers... Signed-off-by:
-
Michael Buesch authored
In the scan section of ieee80211softmac, network transmits are disabled. When SoftMAC re-enables transmits, it may override the wishes of a driver that may have very good reasons for disabling transmits. At least one failure in bcm43xx can be traced to this problem. In addition, several unexplained problems may arise from the unexpected enabling of transmits. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
- Dec 01, 2006
-
-
Chris Wright authored
-
Olaf Kirch authored
IPsec with NAT-T breaks on some notebooks using the latest e1000 chipset, when header split is enabled. When receiving sufficiently large packets, the driver puts everything up to and including the UDP header into the header portion of the skb, and the rest goes into the paged part. udp_encap_rcv forgets to use pskb_may_pull, and fails to decapsulate it. Instead, it passes it up it to the IKE daemon. Signed-off-by:
Olaf Kirch <okir@suse.de> Signed-off-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Miklos Szeredi authored
Fix bug in certain error paths of lookup routines. The request object was reused for sending FORGET, which is illegal. This bug could cause an Oops in 2.6.18. In earlier versions it might silently corrupt memory, but this is very unlikely. These error paths are never triggered by libfuse, so this wasn't noticed even with the 2.6.18 kernel, only with a filesystem using the raw kernel interface. Thanks to Russ Cox for the bug report and test filesystem. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Cc: <stable@kernel.org> Signed-off-by:
-
Linus Torvalds authored
Not all graphic page remappers support physical addresses over the 4GB mark for remapping, so while some do (the AMD64 GART always did, and I just fixed the i965 to do so properly), we're safest off just forcing GFP_DMA32 allocations to make sure graphics pages get allocated in the low 32-bit address space by default. AGP sub-drivers that really care, and can do better, could just choose to implement their own allocator (or we could add another "64-bit safe" default allocator for their use), but quite frankly, you're not likely to care in practice. So for now, this trivial change means that we won't be allocating pages that we can't map correctly by mistake on x86-64. [ On traditional 32-bit x86, this could never happen, because GFP_KERNEL would never allocate any highmem memory anyway ] Acked-by:
Dave Jones <davej@redhat.com> Cc: Eric Anholt <eric@anholt.net> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
David S. Miller authored
The "u16 *" derefs of skb->data need to be wrapped inside of a get_unaligned(). Thanks to Gustavo Zacarias for the bug report. Signed-off-by:
-
Robin Holt authored
When called to do a transfer that has a start offset within the cache line which is uneven between source and destination and a length which terminates the source of the copy exactly on a cache line, one extra line gets copied into a temporary buffer. This is normally not an issue since the buffer is a kernel buffer and only the requested information gets copied into the user buffer. The problem arises when the source ends at the very last physical page of memory. That last cache line does not exist and results in the SHUB chip raising an MCA. Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
Dean Nelson <dcn@sgi.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
YOSHIFUJI Hideaki authored
[PATCH] IPV6: Fix address/interface handling in UDP and DCCP, according to the scoping architecture. TCP and RAW do not have this issue. Closes Bug #7432. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Ira W. Snyder authored
Sparse noticed a locking imbalance in tg3_open(). This patch adds an unlock to one of the error paths, so that tg3_open() always exits without the lock held. Signed-off-by:
Ira W. Snyder <kernel@irasnyder.com> Signed-off-by:
-
Laurent Riffard authored
Fix a slab corruption in ieee80211softmac_auth(). The size of a buffer was miscomputed. see http://bugzilla.kernel.org/show_bug.cgi?id=7245 Acked-by:
Laurent Riffard <laurent.riffard@free.fr> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Fernando J. Pereda authored
There appears to be a typo in the EV56 config option. NORITAKE and PRIMO are be able to set a variation of either. Signed-off-by:
-
Shaohua Li authored
IA32 manual says if micorcode update's size is 0, then the size is default size (2048 bytes). But this doesn't suggest all microcode update's size should be above 2048 bytes to me. We actually had a microcode update whose size is 1024 bytes. The patch just removed the check. Backported to 2.6.18 by Daniel Drake. Signed-off-by:
-
Maciej W. Rozycki authored
V4L: Do not enable VIDEO_V4L2 unconditionally The VIDEO_V4L2 config setting is enabled unconditionally, even for configurations with no support for this subsystem whatsoever. The following patch adds the necessary dependency. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
