- 09 Mar, 2007 40 commits
-
-
Adrian Bunk authored
Fix a double free of "dfid" introduced by commit da977b2c and spotted by the Coverity checker. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Eric Van Hensbergen <ericvh@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Evgeniy Dushistov authored
This is a fix of regression, which triggered by ~2.6.16. Patch with name ufs-directory-and-page-cache-from-blocks-to-pages.patch: in additional to conversation from block to page cache mechanism added new checks of directory integrity, one of them that directory entry do not across directory chunks. But some kinds of UFS: OpenStep UFS and Apple UFS (looks like these are the same filesystems) have different directory chunk size, then common UFSes(BSD and Solaris UFS). So this patch adds ability to works with variable size of directory chunks, and set it for ufstype=openstep to right size. Tested on darwin ufs. Signed-off-by:
Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
-
Zwane Mwaikambo authored
The MTRR compat code wasn't calling the lowlevel MTRR setup due to a switch block not handling the compat case. Before: (WW) I810(0): Failed to set up write-combining range (0xd0000000,0x10000000) After: reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x5f700000 (1527MB), size= 1MB: uncachable, count=1 reg03: base=0x5f800000 (1528MB), size= 8MB: uncachable, count=1 reg04: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 Signed-off-by:
Zwane Mwaikambo <zwane@infradead.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Magnus Damm authored
Kexec support for 2.6.20 on ia64 does not build properly using a config made up by CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n: CC arch/ia64/kernel/machine_kexec.o arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown': arch/ia64/kernel/machine_kexec.c:77: warning: implicit declaration of function `cpu_down' AS arch/ia64/kernel/relocate_kernel.o CC arch/ia64/kernel/crash.o arch/ia64/kernel/crash.c: In function `kdump_cpu_freeze': arch/ia64/kernel/crash.c:139: warning: implicit declaration of function `ia64_jump_to_sal' arch/ia64/kernel/crash.c:139: error: `sal_boot_rendez_state' undeclared (first use in this function) arch/ia64/kernel/crash.c:139: error: (Each undeclared identifier is reported only once arch/ia64/kernel/crash.c:139: error: for each function it appears in.) arch/ia64/kernel/crash.c: At top level: arch/ia64/kernel/crash.c:84: warning: 'kdump_wait_cpu_freeze' defined but not used make[1]: *** [arch/ia64/kernel/crash.o] Error 1 make: *** [arch/ia64/kernel] Error 2 Signed-off-by:
Magnus Damm <magnus@valinux.co.jp> Acked-by:
Simon Horman <horms@verge.net.au> Acked-by:
Jay Lan <jlan@sgi.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Trond Myklebust authored
rpc_call_async() will always call rpc_release_calldata(), so it is an error for __nlm_async_call() to do so as well. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=7923Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Jan "Yenya" Kasprzak <kas@fi.muni.cz> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Trond Myklebust authored
rpc_run_task is guaranteed to always call ->rpc_release. Signed-off-by:
-
Linus Torvalds authored
Revert "[PATCH] LOG2: Alter get_order() so that it can make use of ilog2() on a constant" This reverts commit 39d61db0. The commit was buggy in multiple ways: - the conversion to ilog2() was incorrect to begin with - it tested the wrong #defines, so on all architectures but FRV you'd never see the bug except for constant arguments. - the new "get_order()" macro used its arguments multiple times, and didn't even parenthesize them properly - despite the comments, it was not true that you could use it for constant initializers, since not all architectures even use the generic page.h header file. All of the problems are individually fixable, but it all boils down to: better just revert it, and re-do it from scratch. Cc: David Howells <dhowells@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Andrew Morton <akpm@osdl.org> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Renninger authored
This patch works back to 2.6.17 (earlier kernels seem to need up/down operations on mutex/semaphore). psmouse - properly reset mouse on shutdown/suspend Some people report that they need psmouse module unloaded for suspend to ram/disk to work properly. Let's make port cleanup behave the same way as driver unload. This fixes "bad state" problem on various HP laptops, such as nx7400. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
Thomas Renninger <trenn@suse.de> Signed-off-by:
-
David Brownell authored
The attached fixes an oops in the usbnet driver. The same patch is in 2.6.21-rc1, but that one has many whitespace changes. This is much smaller. Signed-off-by:
David Brownell <david-b@pacbell.net> Signed-off-by:
-
Ingo Molnar authored
The SMT scheduler incorrectly skips kernel threads even if they are runnable (but they are preempted by a higher-prio user-space task which got SMT-delayed by an even higher-priority task running on a sibling CPU). Fix this for now by only doing the SMT-nice optimization if the to-be-delayed task is the only runnable task. (This should cover most of the real-life cases anyway.) This bug has been in the SMT scheduler since 2.6.17 or so, but has only been noticed now by the active check in the dynticks code. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Aristeu Sergio Rozanski Filho authored
This patch fixes a possible race that leads to double freeing an idr index. When the master begin to close, release_dev() is called and then pty_close() is called: if (tty->driver->close) tty->driver->close(tty, filp); This is done without helding any locks other than BKL. Inside pty_close(), being a master close, the devpts entry will be removed: #ifdef CONFIG_UNIX98_PTYS if (tty->driver == ptm_driver) devpts_pty_kill(tty->index); #endif But devpts_pty_kill() will call get_node() that may sleep while waiting for &devpts_root->d_inode->i_sem. When this happens and the slave is being opened, tty_open() just found the driver and index: driver = get_tty_driver(device, &index); if (!driver) { mutex_unlock(&tty_mutex); return -ENODEV; } This part of the code is already protected under tty_mute. The problem is that the slave close already got an index. Then init_dev() is called and blocks waiting for the same &devpts_root->d_inode->i_sem. When the master close resumes, it removes the devpts entry, and the relation between idr index and the tty is gone. The master then sleeps waiting for the tty_mutex on release_dev(). Slave open resumes and found no tty for that index. As result, a NULL tty is returned and init_dev() doesn't flow to fast_track: /* check whether we're reopening an existing tty */ if (driver->flags & TTY_DRIVER_DEVPTS_MEM) { tty = devpts_get_tty(idx); if (tty && driver->subtype == PTY_TYPE_MASTER) tty = tty->link; } else { tty = driver->ttys[idx]; } if (tty) goto fast_track; The result of this, is that a new tty will be created and init_dev() returns sucessfull. After returning, tty_mutex is dropped and master close may resume. Master close finds it's the only use and both sides are closing, then releases the tty and the index. At this point, the idr index is free, but slave still has it. Slave open then calls pty_open() and finds that tty->link->count is 0, because there's no master and returns error. Then tty_open() calls release_dev() which executes without any warning, as it was a case of last slave close when the master is already closed (master->count == 0, slave->count == 1). The tty is then released with the already released idr index. This normally would only issue a warning on idr_remove() but in case of a customer's critical application, it's never too simple: thread1: opens master, gets index X thread1: begin closing master thread2: begin opening slave with index X thread1: finishes closing master, index X released thread3: opens master, gets index X, just released thread2: fails opening slave, releases index X <---- thread4: opens master, gets index X, init_dev() then find an already in use and healthy tty and fails If no more indexes are released, ptmx_open() will keep failing, as the first free index available is X, and it will make init_dev() fail because you're trying to "reopen a master" which isn't valid. The patch notices when this race happens and make init_dev() fail imediately. The init_dev() function is called with tty_mutex held, so it's safe to continue with tty till the end of function because release_dev() won't make any further changes without grabbing the tty_mutex. Without the patch, on some machines it's possible get easily idr warnings like this one: idr_remove called for id=15 which is not allocated. [<c02555b9>] idr_remove+0x139/0x170 [<c02a1b62>] release_mem+0x182/0x230 [<c02a28e7>] release_dev+0x4b7/0x700 [<c02a0ea7>] tty_ldisc_enable+0x27/0x30 [<c02a1e64>] init_dev+0x254/0x580 [<c02a0d64>] check_tty_count+0x14/0xb0 [<c02a4f05>] tty_open+0x1c5/0x340 [<c02a4d40>] tty_open+0x0/0x340 [<c017388f>] chrdev_open+0xaf/0x180 [<c017c2ac>] open_namei+0x8c/0x760 [<c01737e0>] chrdev_open+0x0/0x180 [<c0167bc9>] __dentry_open+0xc9/0x210 [<c0167e2c>] do_filp_open+0x5c/0x70 [<c0167a91>] get_unused_fd+0x61/0xd0 [<c0167e93>] do_sys_open+0x53/0x100 [<c0167f97>] sys_open+0x27/0x30 [<c010303b>] syscall_call+0x7/0xb using this test application available on: http://www.ruivo.org/~aris/pty_sodomizer.cSigned-off-by:Aristeu Sergio Rozanski Filho <aris@ruivo.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Ayaz Abdulla authored
forcedeth: disable msix There seems to be an issue when both MSI-X is enabled and NAPI is configured. This patch disables MSI-X until the issue is root caused. Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Neil Brown authored
On Monday February 12, marcm@liquid-nexus.net wrote: > > > > Thanks for the quick response Neil unfortunately the kernel doesn't build with > > this patch due to a missing symbol: > > > > WARNING: "blk_recount_segments" [drivers/md/raid456.ko] undefined! > > > > Is that in another file that needs patching or within raid5.c? Yes. I keep forgetting about that bit. Sorry. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Micha� Miros�aw authored
Fix reference counting (memory leak) problem in __nfulnl_send() and callers related to packet queueing. Signed-off-by:
MichaÅ MirosÅaw <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
David Stevens authored
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt From: David Stevens <dlstevens@us.ibm.com> Reading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of. From: David Stevens <dlstevens@us.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Michal Wrobel authored
[IPV6]: anycast refcnt fix This patch fixes a bug in Linux IPv6 stack which caused anycast address to be added to a device prior DAD has been completed. This led to incorrect reference count which resulted in infinite wait for unregister_netdevice completion on interface removal. Signed-off-by:
Michal Wrobel <xmxwx@asn.pl> Signed-off-by:
-
David Miller authored
[TCP]: Fix MD5 signature pool locking. The locking calls assumed that these code paths were only invoked in software interrupt context, but that isn't true. Therefore we need to use spin_{lock,unlock}_bh() throughout. Signed-off-by: -
David Miller authored
[SPARC64] bbc_i2c: Fix kenvctrld eating %100 cpu. Based almost entirely upon a patch by Joerg Friedrich Signed-off-by: -
Arnaldo Carvalho de Melo authored
[XFRM_TUNNEL]: Reload header pointer after pskb_may_pull/pskb_expand_head Please consider applying, this was found on your latest net-2.6 tree while playing around with that ip_hdr() + turn skb->nh/h/mac pointers as offsets on 64 bits idea :-) Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
David Miller authored
[XFRM] xfrm_user: Fix return values of xfrm_add_sa_expire. As noted by Kent Yoder, this function will always return an error. Make sure it returns zero on success. Signed-off-by:
-
David Miller authored
[SPARC64]: Fix PCI interrupts on E450 et al. When the PCI controller OBP node lacks an interrupt-map and interrupt-map-mask property, we need to form the INO by hand. The PCI swizzle logic was not doing that properly. This was a regression added by the of_device code. Signed-off-by:
-
Jiri Kosina authored
HID: fix possible double-free on error path in hid parser Freeing of device->collection is properly done in hid_free_device() (as this function is supposed to free all the device resources and could be called from transport specific code, e.g. usb_hid_configure()). Remove all kfree() calls preceeding the hid_free_device() call. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Livio Soares authored
To the issue: some point during 2.6.20 development, Paul Mackerras introduced the "lazy IRQ disabling" patch (very cool work, BTW). In that patch, the performance monitor unit exception was marked as "maskable", in the sense that if interrupts were soft-disabled, that exception could be ignored. This broke my PowerPC profiling code. The symptom that I see is that a varying number of interrupts (from 0 to $n$, typically closer to 0) get delivered, when, in reality, it should always be very close to $n$. The issue stems from the way masking is being done. Masking in this fashion seems to work well with the decrementer and external interrupts, because they are raised again until "really" handled. For the PMU, however, this does not apply (at least on my Xserver machine with a 970FX processor). If the PMU exception is not handled, it will _not_ be re-raised (at least on my machine). The documentation states that the PMXE bit in MMCR0 is set to 0 when the PMU exception is raised. However, software must re-set the bit to re-enable PMU exceptions. If the exception is ignored (as currently) not only is that interrupt lost, but because software does not re-set PMXE, the PMU registers are "frozen" forever. [This patch means that performance monitor exceptions are taken and handled even if irqs are off, as long as some other interrupt hasn't come along and caused interrupts to be hard-disabled. In this sense the PMU exception becomes like an NMI. The oprofile code for most powerpc processors does nothing that is unsafe in an NMI context, but the Cell oprofile code does a spin_lock_irqsave. However, that turns out to be OK because Cell doesn't actually use the performance monitor exception; performance monitor interrupts come in as a regular interrupt on Cell, so will be disabled when irqs are off. -- paulus.] From: Livio Soares <livio@eecg.toronto.edu> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Tejun Heo authored
Add missing #ifdef CONFIG_PM conditionals around all PM related parts in libata LLDs. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
Tejun Heo authored
Some LLDs were missing scsi device PM callbacks while having host/port suspend support. Add missing ones. Signed-off-by:
-
Pavel Roskin authored
In the bcm43xx interrupt handler, sanity checks are wrongly done before the verification that the interrupt is for the bcm43xx. Signed-off-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Darren Salt authored
mmc: Power quirk for ENE controllers Support for these devices was broken for 2.6.18-rc1 and later by commit 146ad66e, which added voltage level support. This restores the previous behaviour for these devices by ensuring that when the voltage is changed, only one write to set the voltage is performed. It may be that both writes are needed if the voltage is being changed between two non-zero values or that it's safe to ensure that only one write is done if the hardware only supports one voltage; I don't know whether either is the case nor can I test since I have only the one SD reader (1524:0550), and it supports just the one voltage. Signed-off-by:
Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Signed-off-by:
-
Jeff Dike authored
A previous cleanup misused need_poll, which had a fairly broken interface. It implemented a growable array, changing the used elements count itself, but leaving it up to the caller to fill in the actual elements, including the entire array if the array had to be reallocated. This worked because the previous users were switching between two such structures, and the elements were copied from the inactive array to the active array after making sure the active array had enough room. maybe_sigio_broken was made to use need_poll, but it was operating on a single array, so when the buffer was reallocated, the previous contents were lost. This patch makes need_poll implement more sane semantics. It merely assures that the array is of the proper size and that the contents are preserved. It is up to the caller to adjust the used elements count and to ensure that the proper elements are resent. This manifested itself as a hang in 2.6.20 as the uninitialized buffer convinced UML that one of its own file descriptors didn't support SIGIO and needed to be watched by poll in a separate thread. The result was an interrupt flood as control traffic over this descriptor sparked interrupts, which resulted in more control traffic, ad nauseum. Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Hugh Dickins authored
Fix insecure default behaviour reported by Tigran Aivazian: if an ext2 or ext3 or ext4 filesystem is tuned to mount with "acl", but mounted by a kernel built without ACL support, then umask was ignored when creating inodes - though root or user has umask 022, touch creates files as 0666, and mkdir creates directories as 0777. This appears to have worked right until 2.6.11, when a fix to the default mode on symlinks (always 0777) assumed VFS applies umask: which it does, unless the mount is marked for ACLs; but ext[234] set MS_POSIXACL in s_flags according to s_mount_opt set according to def_mount_opts. We could revert to the 2.6.10 ext[234]_init_acl (adding an S_ISLNK test); but other filesystems only set MS_POSIXACL when ACLs are configured. We could fix this at another level; but it seems most robust to avoid setting the s_mount_opt flag in the first place (at the expense of more ifdefs). Likewise don't set the XATTR_USER flag when built without XATTR support. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Acked-by:
Andreas Gruenbacher <agruen@suse.de> Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk> Signed-off-by:
-
Tejun Heo authored
sata_sil used to trigger HSM error if IRQ occurs during polling command. This didn't matter because polling wasn't used in sata_sil. However, as of 2.6.20, all IDENTIFYs are performed by polling and device detection sometimes fails due to spurious IRQ. This patch makes sata_sil ignore and clear spurious IRQ while executing commands by polling. This fixes bug#7996 and IMHO should also be included in -stable. Signed-off-by:
-
Stefan Seyfried authored
Fix the Oops occuring when SNAPSHOT_PMOPS or SNAPSHOT_S2RAM ioctl is called on a system without pm_ops defined (eg. a non-ACPI kernel on x86 PC). Signed-off-by:
Stefan Seyfried <seife@suse.de> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Thomas Gleixner authored
Problem description at: http://bugzilla.kernel.org/show_bug.cgi?id=8048 Commit b18ec803 [PATCH] sched: improve migration accuracy optimized the scheduler time calculations, but broke posix-cpu-timers. The problem is that the p->last_ran value is not updated after a context switch. So a subsequent call to current_sched_time() calculates with a stale p->last_ran value, i.e. accounts the full time, which the task was scheduled away. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
-
Michael Krufky authored
This updates the cx88-blackbird driver to be able to use the new cx23416 firmware image released by Hauppauge Computer Works, while retaining compatibility with the older firmware images. cx2341x firmware can be downloaded at: http://dl.ivtvdriver.org/ivtv/firmware/ (cherry picked from commit af70dbd3) Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Hans Verkuil authored
Due to changes in the i2c handling in 2.6.20 this cx25840 bug surfaced, causing the firmware load to fail for the ivtv driver. The correct sequence is to first attach the i2c client, then use the client's device to load the firmware. (cherry picked from commit d55c7aec) Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Acked-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Michael Krufky authored
dvb-pll normally opens the i2c gate before attempting to communicate with the pll, but the code for this device is not using dvb-pll. This should be cleaned up in the future, but for now, just open the i2c gate at the appropriate place in order to fix this driver bug. (cherry picked from commit 2fe22dcd) Signed-off-by:
-
Jin-Bong lee authored
Without this patch, the device will not be detected after firmware download on big endian systems. (cherry picked from commit 1d1370a4) Signed-off-by:
Jin-Bong lee <jinbong.lee@samsung.com> Signed-off-by:
-
Mike Isely authored
Rework the cx23416 firmware loader so that it longer requires the firmware size to be a multiple of 8KB. Until recently all cx2341x firmware images were exactly 256KB, but newer firmware is larger than that and also appears to have arbitrary size. We still must check against a multiple of 4 bytes (because the cx23416 itself uses a 32 bit word size). This fix is already in the upstream driver source and has proven itself there; this is a backport for the 2.6.20.y kernel series. (backported from commit 90060d32) Signed-off-by:
-
Mike Isely authored
This introduces some extra cx23416 commands when streaming is started. The addition of these commands fix random sporadic video corruption that can take place when the video stream is temporarily disrupted through loss of signal (e.g. changing the channel in the RF tuner). This fix is already in the upstream driver source and has proven itself there; this is a backport for the 2.6.20.y kernel series. (backported from commit 6fe7d2c4) Signed-off-by:
-
Marcel Siegert authored
Arjan van de Ven <arjan@infradead.org> reported an illegal re-usage of the fileoperations struct if more than one dvb device (e.g. frontend) is present. This patch fixes this issue. It allocates a new fileoperations struct each time a device is registered and copies the default template fileops. (backported from commit b6190102) Signed-off-by:
Marcel Siegert <mws@linuxtv.org> Signed-off-by:
-
NeilBrown authored
There are two errors that can lead to recovery problems with raid10 when used in 'far' more (not the default). Due to a '>' instead of '>=' the wrong block is located which would result in garbage being written to some random location, quite possible outside the range of the device, causing the newly reconstructed device to fail. The device size calculation had some rounding errors (it didn't round when it should) and so recovery would go a few blocks too far which would again cause a write to a random block address and probably a device error. The code for working with device sizes was fairly confused and spread out, so this has been tided up a bit. Signed-off-by:
-
