- 05 Feb, 2007 17 commits
-
-
Ard van Breemen authored
The pci_find_subsys gets called very early by obsolete ide setup parameters. This is a bogus call since pci is not initialized yet, so the list is empty. But in the mean time, interrupts get enabled by down_read. This can result in a kernel panic when the irq controller gets initialized. This patch checks if the device list is empty before taking the semaphore, and hence will not enable irq's. Furthermore it will inform that it is called while pci_devices is empty as a reminder that the ide code needs to be fixed. The pci_get_subsys can get called in the same manner, and as such is patched in the same manner. [akpm@osdl.org: cleanups] Signed-off-by:
Ard van Breemen <ard@telegraafnet.nl> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> [chrisw: fold in 6a4c24ec to avoid printk spamming] Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Ard van Breemen authored
The calls made by parse_parms to other initialization code might enable interrupts again way too early. Having interrupts on this early can make systems PANIC when they initialize the IRQ controllers (which happens later in the code). This patch detects that irq's are enabled again, barfs about it and disables them again as a safety net. [akpm@osdl.org: cleanups] Signed-off-by:
-
Linus Torvalds authored
Fix up CIFS for "test_clear_page_dirty()" removal This also adds he required page "writeback" flag handling, that cifs hasn't been doing and that the page dirty flag changes made obvious. Acked-by:
Steve French <smfltc@us.ibm.com> Acked-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by:
-
Nathan Lynch authored
Commit 5c1e1767 ("sched: force /sbin/init off isolated cpus") sets init's cpus_allowed to a subset of cpu_online_map at boot time, which means that tasks won't be scheduled on cpus that are added to the system later. Make init's cpus_allowed a subset of cpu_possible_map instead. This should still preserve the behavior that Nick's change intended. Thanks to Giuliano Pochini for reporting this and testing the fix: http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.htmlSigned-off-by:
Nathan Lynch <ntl@pobox.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: <stable@kernel.org> Signed-off-by:
-
Stefan Richter authored
Since commit 98e238cd in Linux 2.6.19, "ieee1394: sbp2: don't prefer MODE SENSE 10", some FireWire DVD-ROMs and DVD-RWs were mistaken as CD-ROM because sr_mod now sent MODE SENSE 6. The MMC command set includes only MODE SENSE 10. http://bugzilla.kernel.org/show_bug.cgi?id=7800 This fix lets sbp2 switch scsi_device.use_10_for_rw on for MMC LUs. This should rather be done in the command set driver sr_mod, not in the sbp2 transport driver, and an according patch will follow for a next Linux release. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Eric W. Biederman authored
This patch fixes the case when we reparent to a different thread in the same thread group. This modifies the code so that we do not send signals and do not change the signal to send to SIGCHLD unless we have change the thread group of our parents. It also suppresses sending pdeath_sig in this cas as well since the result of geppid doesn't change. Thanks to Oleg for spotting my bug of only fixing this for non-ptraced tasks. This fixes the issues identified by Albert Cahalan in thread http://lkml.org/lkml/2006/12/21/22. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Mike Galbraith <efault@gmx.de> Cc: Albert Cahalan <acahalan@gmail.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Coywolf Qi Hunt <qiyong@fc-cn.com> Acked-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Michael S. Tsirkin authored
mthca_table_find() will return the wrong address when the table entry being searched for is exactly at the beginning of a sglist entry (other than the first), because it uses >= when it should use >. Example: assume we have 2 entries in scatterlist, 4K each, offset is 4K. The current code will return first entry + 4K when we really want the second entry. In particular this means mapping an FMR on a memfree HCA may end up writing the page table into the wrong place, leading to memory corruption and also causing the HCA to use an incorrect address translation table. Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Karsten Wiese authored
The previous patch "Repair snd-usb-usx2y for usb 2.6.18" assumed urb->start_frame roll over beyond MAX_INT for both UHCI & OHCI. This isn't true until now (kernel 2.6.20). Fix this by only looking at the common between OHCI & UHCI Frame number range. This is for mainline and stable kernels >= 2.6.18. Signed-off-by:
Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by:
-
Patrick McHardy authored
The included patch translates arpt_counters to xt_counters, making userspace arptables compile against recent kernels. Signed-off-by:
Bart De Schuymer <bdschuym@pandora.be> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Patrick McHardy authored
IP_CT_TCP_FLAG_CLOSE_INIT is a flag and should have a value of 0x4 instead of 0x3, which is IP_CT_TCP_FLAG_WINDOW_SCALE | IP_CT_TCP_FLAG_SACK_PERM. Signed-off-by:
-
Patrick McHardy authored
When IPv6 connection tracking splits up a defragmented packet into its original fragments, the packets are taken from a list and are passed to the network stack with skb->next still set. This causes dev_hard_start_xmit to treat them as GSO fragments, resulting in a use after free when connection tracking handles the next fragment. Signed-off-by:
-
Patrick McHardy authored
Packets generated by the REJECT target in the output chain have a local destination address and a foreign source address. Make sure not to use the foreign source address for the output route lookup. Signed-off-by:
-
Lars Ellenberg authored
md raidX make_request functions strip off the BIO_RW_SYNC flag, thus introducing additional latency. Fixing this in raid1 and raid10 seems to be straightforward enough. For our particular usage case in DRBD, passing this flag improved some initialization time from ~5 minutes to ~5 seconds. Acked-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Lars Ellenberg <lars@linbit.com> Acked-by:
Jens Axboe <jens.axboe@oracle.com> Cc: <stable@kernel.org> Signed-off-by:
-
Michael Buesch authored
This changes all HWRNG driver initcalls to module_init(). We must probe the RNGs after the major kernel subsystems are already up and running (like PCI). This fixes Bug 7730. http://bugzilla.kernel.org/show_bug.cgi?id=7730Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Christoph Lameter authored
Both process_zones() and drain_node_pages() check for populated zones before touching pagesets. However, __drain_pages does not do so, This may result in a NULL pointer dereference for pagesets in unpopulated zones if a NUMA setup is combined with cpu hotplug. Initially the unpopulated zone has the pcp pointers pointing to the boot pagesets. Since the zone is not populated the boot pageset pointers will not be changed during page allocator and slab bootstrap. If a cpu is later brought down (first call to __drain_pages()) then the pcp pointers for cpus in unpopulated zones are set to NULL since __drain_pages does not first check for an unpopulated zone. If the cpu is then brought up again then we call process_zones() which will ignore the unpopulated zone. So the pageset pointers will still be NULL. If the cpu is then again brought down then __drain_pages will attempt to drain pages by following the NULL pageset pointer for unpopulated zones. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Philippe De Muyter authored
m41t00.c forgets to set the year field in set_rtc_time; fix that. Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Acked-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Maxime Bizon authored
I have a Marvell board which has the same i2c hw block than mv64xxx, so I'm trying to use i2c-mv64xxx driver. But I get the following random oops at boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Backtrace: [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c) [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0) r8 = C0501E08 r7 = 00000005 r6 = C0501E08 r5 = 00000005 r4 = C048BB78 [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134) r6 = C0449C78 r5 = F1020000 r4 = FFFFFFFF [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100) r8 = C1CAC400 r7 = 00000005 r6 = 00000002 r5 = F1020000 r4 = FFFFFFFF [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0) r7 = C041B2AC r6 = C0397E4C r5 = 00000000 r4 = 00000005 [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244) [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24) The oops is caused by a spurious interrupt that occurs when request_irq is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL. I noticed that hardware init is done after requesting irq. Thus any pending irq from previous hardware usage may cause this. The following patch fixes it: Signed-off-by:
Maxime Bizon <mbizon@freebox.fr> Acked-by:
-
- 10 Jan, 2007 23 commits
-
-
Chris Wright authored
-
Peter Zijlstra authored
- add flush_cache_page() for all those virtual indexed cache architectures. - handle s390. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Linus Torvalds authored
Doug Chapman noticed that mincore() will doa "copy_to_user()" of the result while holding the mmap semaphore for reading, which is a big no-no. While a recursive read-lock on a semaphore in the case of a page fault happens to work, we don't actually allow them due to deadlock schenarios with writers due to fairness issues. Doug and Marcel sent in a patch to fix it, but I decided to just rewrite the mess instead - not just fixing the locking problem, but making the code smaller and (imho) much easier to understand. Cc: Doug Chapman <dchapman@redhat.com> Cc: Marcel Holtmann <holtmann@redhat.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org> [chrisw: fold in subsequent fix: 4fb23e43] Acked-by:
Hugh Dickins <hugh@veritas.com> [chrisw: fold in subsequent fix: 825020c3] Signed-off-by:
-
Hugh Dickins authored
These days, if you swapoff when there isn't enough memory, OOM killer gives "BUG: scheduling while atomic" and the machine hangs: badness() needs to do its PF_SWAPOFF return after the task_unlock (tasklist_lock is also held here, so p isn't going to be freed: PF_SWAPOFF might get turned off at any moment, but that doesn't really matter). Signed-off-by:
-
Erik Jacobson authored
On ia64, the various functions that make up cn_proc.c cause kernel unaligned access errors. If you are using these, for example, to get notification about all tasks forking and exiting, you get multiple unaligned access errors per process. Use put_unaligned() in the appropriate palces to fix this. Signed-off-by:
Erik Jacobson <erikj@sgi.com> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Moore authored
Back when the original NetLabel patches were being changed to use Netlink attributes correctly some code was accidentially dropped which set all of the undefined CIPSOv4 level and category mappings to a sentinel value. The result is the mappings data in the kernel contains bogus mappings which always map to zero. Having level and category mappings that map to zero could result in the kernel assigning incorrect security attributes to packets. This patch restores the old/correct behavior by initializing the mapping data to the correct sentinel value. Signed-off-by:
Paul Moore <paul.moore@hp.com> Signed-off-by:
-
David Hollis authored
The attached patch fixes a PHY selection problem that prevents AX88772 based devices (Linksys USB200Mv2, etc) devices from working. The interface comes up and everything seems fine except the device doesn't send/receive any packets. The one-liner attached fixes this issue and makes the devices usable again. Signed-off-by:
David Hollis <dhollis@davehollis.com> Signed-off-by:
-
David L Stevens authored
It is important that we only assign dev->ip{,6}_ptr only after all portions of the inet{,6} are setup. Otherwise we can receive packets before the multicast spinlocks et al. are initialized. Signed-off-by:David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Miller authored
This matches what the ISA cs4231 driver uses. Tested by Georg Chini. Signed-off-by:
-
Georg Chini authored
SBUS: Change IRQ-handler return value from 0 to IRQ_HANDLED and fix some initialisation problems. Change period_bytes_min from 4096 to 256 to allow driver to work with low latency (VOIP) applications. Hope this does not break EBUS. Signed-off-by:
Georg Chini <georg.chini@triaton-webhosting.com> Signed-off-by:
-
Chuck Ebbert authored
We cannot compute the gap until we know we have a 'struct ebt_entry' and not 'struct ebt_entries'. Failure to check can cause crash. Tested-by:
Santiago Garcia Mantinan <manty@manty.net> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Jean Delvare authored
reference to .init.text: from .text between 'cx88_card_setup' (at offset 0x68c) and 'cx88_risc_field' Caused by leadtek_eeprom() being declared __devinit and called from a non-devinit context. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Ang Way Chuang authored
CRC-32 checking during ULE decapsulation always failed on x86_64 systems due to the size of a variable used to store CRC. This bug was discovered on Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such problem. This patch has been tested on 64-bit system as well as 32-bit system. Signed-off-by:
Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by:
-
Hans Verkuil authored
This bug broke the MPEG audio mode controls. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Linus Torvalds authored
The VM layer (on the face of it, fairly reasonably) expected that when it does a ->writepage() call to the filesystem, it would write out the full page at that point in time. Especially since it had earlier marked the whole page dirty with "set_page_dirty()". But that isn't actually the case: ->writepage() does not actually write a page, it writes the parts of the page that have been explicitly marked dirty before, *and* that had not got written out for other reasons since the last time we told it they were dirty. That last caveat is the important one. Which _most_ of the time ends up being the whole page (since we had called "set_page_dirty()" on the page earlier), but if the filesystem had done any dirty flushing of its own (for example, to honor some internal write ordering guarantees), it might end up doing only a partial page IO (or none at all) when ->writepage() is actually called. That is the correct thing in general (since we actually often _want_ only the known-dirty parts of the page to be written out), but the shared dirty page handling had implicitly forgotten about these details, and had a number of cases where it was doing just the "->writepage()" part, without telling the low-level filesystem that the whole page might have been re-dirtied as part of being mapped writably into user space. Since most of the time the FS did actually write out the full page, we didn't notice this for a loong time, and this needed some really odd patterns to trigger. But it caused occasional corruption with rtorrent and with the Debian "apt" database, because both use shared mmaps to update the end result. This fixes it. Finally. After way too much hair-pulling. Acked-by:
Nick Piggin <nickpiggin@yahoo.com.au> Acked-by:
Martin J. Bligh <mbligh@google.com> Acked-by:
Martin Michlmayr <tbm@cyrius.com> Acked-by:
Martin Johansson <martin@fatbob.nu> Acked-by:
Andrei Popa <andrei.popa@i-neo.ro> Cc: High Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org>, Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: David Miller <davem@davemloft.net> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Gordon Farquharson <gordonfarquharson@gmail.com> Cc: Guillaume Chazarain <guichaz@yahoo.fr> Cc: Theodore Tso <tytso@mit.edu> Cc: Kenneth Cheng <kenneth.w.chen@intel.com> Cc: Tobias Diedrich <ranma@tdiedrich.de> Signed-off-by:
-
Jan Andersson authored
Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32. Without the offset, transfers to buffers that do not begin on a page boundary will not work as expected. Signed-off-by:
Jan Andersson <jan.andersson@ieee.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by:
-
David Woodhouse authored
Don't add it there please; add it lower down inside the existing #ifdef __KERNEL__. You just made the _userspace_ net.h include random.h, which then fails to compile unless <asm/types.h> was already included. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Miller authored
And this points out that the return value from isa_dev_get_resource() and the 'pregs' arg to isa_dev_get_irq() are totally unused. Based upon a patch from Richard Mortimer <richm@oldelvet.org.uk> Signed-off-by:
-
David Miller authored
We were not being careful enough. When we trim the physical memory areas, we have to make sure we don't remove the kernel image or initial ramdisk image ranges. Signed-off-by:
-
Robert Olsson authored
Signed-off-by:
-
Eric Sandeen authored
This one was pointed out on the MOKB site: http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html If a directory's i_size is corrupted, ext2_find_entry() will keep processing pages until the i_size is reached, even if there are no more blocks associated with the directory inode. This patch puts in some minimal sanity-checking so that we don't keep checking pages (and issuing errors) if we know there can be no more data to read, based on the block count of the directory inode. This is somewhat similar in approach to the ext3 patch I sent earlier this year. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Phillip Lougher authored
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/ fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops is an unchecked corrupted block length field read by cramfs_readpage(). This patch adds a sanity check to cramfs_readpage() which checks that the block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is intentional, even though the uncompressed data is not going to be larger than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than the original source data. Mkcramfs checks that the compressed size is always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could use the original uncompressed data in this case, but it doesn't. Signed-off-by:
Phillip Lougher <phillip@lougher.org.uk> Signed-off-by:
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext3 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext3_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext3_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext3. Signed-off-by:
-
