- 03 Mar, 2007 16 commits
-
-
Greg Kroah-Hartman authored
-
Stephen Hemminger authored
Different chipsets have different amount of ram buffer (some have none), so need to make sure that driver does proper setup for all cases from 0 on to 48K, in units of 1K. This is a backport of the code from 2.6.19 or later Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stephen Hemminger authored
Don't mark pause frames as errors. This caused a bug that would lockup transmitter, as well as all the other ports on a switch. Signed-off-by:
-
Stephen Hemminger authored
The code in transmit timeout incorrectly assumed that netif_tx_lock was not set. Signed-off-by:
-
Stephen Hemminger authored
When using netconsole, it is possible for the driver to try and free skb's with IRQ's disabled. This could cause problems if the skb had a destructor function that didn't expect this. The documented semantics is that skb->destructor callback happens in softirq. Signed-off-by:
-
Stephen Hemminger authored
This driver uses port 0 to handle receives on both ports. So the netif_poll_disable call in dev_close would end up stopping the second port on dual port cards. Signed-off-by:
-
Stephen Hemminger authored
PHY power control won't work because writes to PCI config space are not re-enabled. Signed-off-by:
-
David Moore authored
Adds missing call to phys_to_virt() in the lib/swiotlb.c:swiotlb_sync_sg() function. Without this change, a kernel panic will always occur whenever a SWIOTLB bounce buffer from a scatter-gather list gets synced. Signed-off-by:
David Moore <dcm@acm.org> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Takashi Iwai authored
[ALSA] hda-codec - Don't return error at initialization of modem codec Some modem codec seem to fail in the initialization, and this stopped loading of the whole module although the audio is OK. Since it's usually a non-fatal issue, the driver tries to proceed to initialize now. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> 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:
-
Steve French authored
[CIFS] Fix oops when Windows server sent bad domain name null terminator Fixes RedHat bug 211672 Windows sends one byte (instead of two) of null to terminate final Unicode string (domain name) in session setup response in some cases - this caused cifs to misalign some informational strings (making it hard to convert from UCS16 to UTF8). Thanks to Shaggy for his help and Akemi Yagi for debugging/testing Signed-off-by:
Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Takashi Iwai authored
[ALSA] hda-intel - Don't try to probe invalid codecs Fix the max number of codecs detected by HD-intel (and compatible) controllers to 3. Some hardware reports extra bits as if connected, and the driver gets confused to probe unexisting codecs. Signed-off-by:
-
Francois Romieu authored
netpoll: drivers must not enable IRQ unconditionally in their NAPI handler net/core/netpoll.c::netpoll_send_skb() calls the poll handler when it is available. As netconsole can be used from almost any context, IRQ must not be enabled blindly in the NAPI handler of a driver which supports netpoll. b57bd066 fixed the issue for the 8139too.c driver. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Eric Sandeen authored
CVE-2006-5753 is for a case where an inode can be marked bad, switching the ops to bad_inode_ops, which are all connected as: static int return_EIO(void) { return -EIO; } #define EIO_ERROR ((void *) (return_EIO)) static struct inode_operations bad_inode_ops = { .create = bad_inode_create ...etc... The problem here is that the void cast causes return types to not be promoted, and for ops such as listxattr which expect more than 32 bits of return value, the 32-bit -EIO is interpreted as a large positive 64-bit number, i.e. 0x00000000fffffffa instead of 0xfffffffa. This goes particularly badly when the return value is taken as a number of bytes to copy into, say, a user's buffer for example... I originally had coded up the fix by creating a return_EIO_<TYPE> macro for each return type, like this: static int return_EIO_int(void) { return -EIO; } #define EIO_ERROR_INT ((void *) (return_EIO_int)) static struct inode_operations bad_inode_ops = { .create = EIO_ERROR_INT, ...etc... but Al felt that it was probably better to create an EIO-returner for each actual op signature. Since so few ops share a signature, I just went ahead & created an EIO function for each individual file & inode op that returns a value. Signed-off-by:Eric Sandeen <sandeen@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.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:
-
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:
-
- 24 Feb, 2007 21 commits
-
-
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=7916Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
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:
-
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 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:
-
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:
-
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:
-
- 20 Feb, 2007 2 commits
-
-
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:
-
- 05 Feb, 2007 1 commit
-
-
Chris Wright authored
-
