- 11 Jun, 2009 24 commits
-
-
Alan Cox authored
We fixed the globals, so now fix the comment Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
The tty throttling code can race due to the lock drops. It takes very high loads but this has been observed and verified by Rob Duncan. The basic problem is that on an SMP box we can go CPU #1 CPU #2 need to throttle ? suppose we should buffer space cleared are we throttled yes ? - unthrottle call throttle method This changeet take the termios lock to protect against this. The termios lock isn't the initial obvious candidate but many implementations of throttle methods already need to poke around their own termios structures (and nobody really locks them against a racing change of flow control). This does mean that anyone who is setting tty->low_latency = 1 and then calling tty_flip_buffer_push from their unthrottle method is going to end up collapsing in a pile of locks. However we've removed all the known bogus users of low_latency = 1 and such use isn't safe anyway for other reasons so catching it would be an improvement. Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Arnd Bergmann authored
The legacy TCSETA{,W,F} ioctls failed to set the termio->c_line field on x86. This adds a missing get_user. The same ioctls also fail to report faulting user pointers, which we keep ignoring. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Andre Przywara authored
This adds support for the following serial controller chip: Oxford Semiconductor OXCB950 for PCI Cardbus interface http://www.transdimension.com/products/serial/OXCB950.html on this card: ExSys EX-1370 1 port high-speed serial card for ExpressCard/34 slot Signed-off-by:
Andre Przywara <andre.przywara@amd.com> Signed-off-by:
-
Jiri Slaby authored
Switch from ASYNC_* to ASYNCB_*, because test_bit expects bit number, not mask. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Jiri Slaby authored
Switch from ASYNC_* to ASYNCB_*, because {test,set}_bit expect bit number, not mask. Signed-off-by: -
Jiri Slaby authored
Define ASYNCB_* flags which are bit numbers of the ASYNC_* flags. This is useful for {test,set,clear}_bit. Also convert each ASYNC_% to be (1 << ASYNCB_%) and define masks with the macros, not constants. Tested with: #include "PATH_TO_KERNEL/include/linux/serial.h" static struct { unsigned int new, old; } as[] = { { ASYNC_HUP_NOTIFY, 0x0001 }, { ASYNC_FOURPORT, 0x0002 }, ... { ASYNC_BOOT_ONLYMCA, 0x00400000 }, { ASYNC_INTERNAL_FLAGS, 0xFFC00000 } }; ... for (a = 0; a < ARRAY_SIZE(as); a++) if (as[a].old != as[a].new) printf("%.8x != %.8x\n", as[a].old, as[a].new); Signed-off-by: -
Alan Cox authored
Or at least most of it. There are further clean ups possible and there are are also thing checkpatch moans about that would be silly to "fix". Also note some FIXME points found as the cleanup was done. Signed-off-by:
-
Alan Cox authored
Now we have a port structure begin using the fields and kref counts Signed-off-by:
-
Jiri Slaby authored
Signed-off-by:
-
Jiri Slaby authored
Set up ports right after FW load so that we won't allocate maximal (64) ports when we use few. Also remove reading of nports in irq context, since we know it from initialisation now. This also fixes a tty ports unregistration on some fail paths and for Ze which registered 64 and unregistered real port count. Signed-off-by:
-
Jiri Slaby authored
They are unused anyway. Signed-off-by:
-
Jiri Slaby authored
Remove ugly macros and add inlines instead of them. This improves readability and type checking a much. Signed-off-by:
-
Jiri Slaby authored
Store HW version locally to not read it all the time in interrupts and alike. Signed-off-by:
-
Jiri Slaby authored
Remove ugly all-over-the-code casts of ctl_addr to 9060 space. Add an union to the cyclades_card structure, which contains a pointer to both 9050 and 9060 spaces. The 9050 space layout is unknown, so let it still as a void __iomem pointer. Signed-off-by:
-
Paul Fulghum authored
Add receive programmed IO mode to reduce receive latency when using low data rates. The receive FIFO trigger level of 128 bytes used in DMA mode creates excessive latency when operating at low data rates. PIO mode is selected when user application requests data in blocks of less than 128 bytes. Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Signed-off-by:
-
Alan Cox authored
The CDC ACM driver uses the tty layer correctly so needs conversion. Start by adding and initializing the port structures. Signed-off-by:
-
Alan Cox authored
This allows us to clean stuff up, but is probably also going to cause some app breakage with buggy apps as we now implement proper POSIX behaviour for USB ports matching all the other ports. This does also mean other apps that break on USB will now work properly. Signed-off-by:
-
Alan Cox authored
We need this for devices that cannot flush and wait, but which do not order data and modem events. Without it we will hang up before all the data clears the hardware. Needed for the USB changes. Signed-off-by:
-
Alan Cox authored
Some drivers implement this internally, others miss it out. Push the behaviour into the core code as that way everyone will do it consistently. Update the dtr rts method to raise or lower depending upon flags. Having a single method in this style fits most of the implementations more cleanly than two funtions. We need this in place before we tackle the USB side Signed-off-by:
-
Jiri Slaby authored
No need to check if dev_id is NULL, it never is. Signed-off-by:
-
Jiri Slaby authored
Don't reset the PLX chip after FW load, which effectively kills the FW, so that user had to boot manually. Signed-off-by:
-
Jiri Slaby authored
Ze needs firmware to be loaded as well as Zo. Move cyz_load_fw one level upper to achieve that. Signed-off-by:
-
- 10 Jun, 2009 2 commits
-
-
Linus Torvalds authored
-
Peter Botha authored
There's a bug in the mxser kernel module that still appears in the 2.6.29.4 kernel. mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the not of the ioaddr, you're effectively passing 0 which means it won't be able to talk to an ISA card. I have tested this, and removing the ! fixes the problem. Cc: "Peter Botha" <peterb@goldcircle.co.za> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
- 09 Jun, 2009 14 commits
-
-
Jan Kara authored
In commit code, we scan buffers attached to a transaction. During this scan, we sometimes have to drop j_list_lock and then we recheck whether the journal buffer head didn't get freed by journal_try_to_free_buffers(). But checking for buffer_jbd(bh) isn't enough because a new journal head could get attached to our buffer head. So add a check whether the journal head remained the same and whether it's still at the same transaction and list. This is a nasty bug and can cause problems like memory corruption (use after free) or trigger various assertions in JBD code (observed). Signed-off-by:
Jan Kara <jack@suse.cz> Cc: <stable@kernel.org> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Ian Kent authored
The recent ->lookup() deadlock correction required the directory inode mutex to be dropped while waiting for expire completion. We were concerned about side effects from this change and one has been identified. I saw several error messages. They cause autofs to become quite confused and don't really point to the actual problem. Things like: handle_packet_missing_direct:1376: can't find map entry for (43,1827932) which is usually totally fatal (although in this case it wouldn't be except that I treat is as such because it normally is). do_mount_direct: direct trigger not valid or already mounted /test/nested/g3c/s1/ss1 which is recoverable, however if this problem is at play it can cause autofs to become quite confused as to the dependencies in the mount tree because mount triggers end up mounted multiple times. It's hard to accurately check for this over mounting case and automount shouldn't need to if the kernel module is doing its job. There was one other message, similar in consequence of this last one but I can't locate a log example just now. When checking if a mount has already completed prior to adding a new mount request to the wait queue we check if the dentry is hashed and, if so, if it is a mount point. But, if a mount successfully completed while we slept on the wait queue mutex the dentry must exist for the mount to have completed so the test is not really needed. Mounts can also be done on top of a global root dentry, so for the above case, where a mount request completes and the wait queue entry has already been removed, the hashed test returning false can cause an incorrect callback to the daemon. Also, d_mountpoint() is not sufficient to check if a mount has completed for the multi-mount case when we don't have a real mount at the base of the tree. Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
Mike Frysinger authored
The massive nommu update (8feae131) resulted in these warnings: ipc/shm.c: In function `sys_shmdt': ipc/shm.c:974: warning: unused variable `size' ipc/shm.c:972: warning: unused variable `next' Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linusLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: kvm: fix kvm reboot crash when MAXSMP is used cpumask: alloc zeroed cpumask for static cpumask_var_ts cpumask: introduce zalloc_cpumask_var
-
git://git.kernel.dk/linux-2.6-blockLinus Torvalds authored
* 'for-linus' of git://git.kernel.dk/linux-2.6-block: bsg: setting rq->bio to NULL
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: cls_cgroup: Fix oops when user send improperly 'tc filter add' request r8169: fix crash when large packets are received
-
git://neil.brown.name/mdLinus Torvalds authored
* 'for-linus' of git://neil.brown.name/md: md/raid5: fix bug in reshape code when chunk_size decreases. md/raid5 - avoid deadlocks in get_active_stripe during reshape md/raid5: use conf->raid_disks in preference to mddev->raid_disk
-
FUJITA Tomonori authored
Due to commit 1cd96c24 ("block: WARN in __blk_put_request() for potential bio leak"), BSG SMP requests get the false warnings: WARNING: at block/blk-core.c:1068 __blk_put_request+0x52/0xc0() This sets rq->bio to NULL to avoid that false warnings. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
Avi Kivity authored
one system was found there is crash during reboot then kvm/MAXSMP Sending all processes the KILL signal... done Please stand by while rebooting the system... [ 1721.856538] md: stopping all md devices. [ 1722.852139] kvm: exiting hardware virtualization [ 1722.854601] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1722.872219] IP: [<ffffffff8102c6b6>] hardware_disable+0x4c/0xb4 [ 1722.877955] PGD 0 [ 1722.880042] Oops: 0000 [#1] SMP [ 1722.892548] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:2:0/0:2:0:0/vendor [ 1722.900977] CPU 9 [ 1722.912606] Modules linked in: [ 1722.914226] Pid: 0, comm: swapper Not tainted 2.6.30-rc7-tip-01843-g2305324-dirty #299 ... [ 1722.932589] RIP: 0010:[<ffffffff8102c6b6>] [<ffffffff8102c6b6>] hardware_disable+0x4c/0xb4 [ 1722.942709] RSP: 0018:ffffc900010b6ed8 EFLAGS: 00010046 [ 1722.956121] RAX: 0000000000000000 RBX: ffffc9000e253140 RCX: 0000000000000009 [ 1722.972202] RDX: 000000000000b020 RSI: ffffc900010c3220 RDI: ffffffffffffd790 [ 1722.977399] RBP: ffffc900010b6f08 R08: 0000000000000000 R09: 0000000000000000 [ 1722.995149] R10: 00000000000004b8 R11: 966912b6c78fddbd R12: 0000000000000009 [ 1723.011551] R13: 000000000000b020 R14: 0000000000000009 R15: 0000000000000000 [ 1723.019898] FS: 0000000000000000(0000) GS:ffffc900010b3000(0000) knlGS:0000000000000000 [ 1723.034389] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b [ 1723.041164] CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006e0 [ 1723.056192] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1723.072546] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1723.080562] Process swapper (pid: 0, threadinfo ffff88107e464000, task ffff88047e5a2550) [ 1723.096144] Stack: [ 1723.099071] 0000000000000046 ffffc9000e253168 966912b6c78fddbd ffffc9000e253140 [ 1723.115471] ffff880c7d4304d0 ffffc9000e253168 ffffc900010b6f28 ffffffff81011022 [ 1723.132428] ffffc900010b6f48 966912b6c78fddbd ffffc900010b6f48 ffffffff8100b83b [ 1723.141973] Call Trace: [ 1723.142981] <IRQ> <0> [<ffffffff81011022>] kvm_arch_hardware_disable+0x26/0x3c [ 1723.158153] [<ffffffff8100b83b>] hardware_disable+0x3f/0x55 [ 1723.172168] [<ffffffff810b95f6>] generic_smp_call_function_interrupt+0x76/0x13c [ 1723.178836] [<ffffffff8104cbea>] smp_call_function_interrupt+0x3a/0x5e [ 1723.194689] [<ffffffff81035bf3>] call_function_interrupt+0x13/0x20 [ 1723.199750] <EOI> <0> [<ffffffff814ad3b4>] ? acpi_idle_enter_c1+0xd3/0xf4 [ 1723.217508] [<ffffffff814ad3ae>] ? acpi_idle_enter_c1+0xcd/0xf4 [ 1723.232172] [<ffffffff814ad4bc>] ? acpi_idle_enter_bm+0xe7/0x2ce [ 1723.235141] [<ffffffff81a8d93f>] ? __atomic_notifier_call_chain+0x0/0xac [ 1723.253381] [<ffffffff818c3dff>] ? menu_select+0x58/0xd2 [ 1723.258179] [<ffffffff818c2c9d>] ? cpuidle_idle_call+0xa4/0xf3 [ 1723.272828] [<ffffffff81034085>] ? cpu_idle+0xb8/0x101 [ 1723.277085] [<ffffffff81a80163>] ? start_secondary+0x1bc/0x1d7 [ 1723.293708] Code: b0 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 e0 31 c0 48 8b 04 cd 30 ee 27 82 49 89 cc 49 89 d5 48 8b 04 10 48 8d b8 90 d7 ff ff <48> 8b 87 70 28 00 00 48 8d 98 90 d7 ff ff eb 16 e8 e9 fe ff ff [ 1723.335524] RIP [<ffffffff8102c6b6>] hardware_disable+0x4c/0xb4 [ 1723.342076] RSP <ffffc900010b6ed8> [ 1723.352021] CR2: 0000000000000000 [ 1723.354348] ---[ end trace e2aec53dae150aa1 ]--- it turns out that we need clear cpus_hardware_enabled in that case. Reported-and-tested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
Yinghai Lu authored
These are defined as static cpumask_var_t so if MAXSMP is not used, they are cleared already. Avoid surprises when MAXSMP is enabled. Signed-off-by:
Yinghai Lu <yinghai.lu@kernel.org> Signed-off-by:
-
Yinghai Lu authored
So can get cpumask_var with cpumask_clear Signed-off-by:
-
Minoru Usui authored
I found a bug in cls_cgroup_change() in cls_cgroup.c. cls_cgroup_change() expected tca[TCA_OPTIONS] was set from user space properly, but tc in iproute2-2.6.29-1 (which I used) didn't set it. In the current source code of tc in git, it set tca[TCA_OPTIONS]. git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git If we always use a newest iproute2 in git when we use cls_cgroup, we don't face this oops probably. But I think, kernel shouldn't panic regardless of use program's behaviour. Signed-off-by:
Minoru Usui <usui@mxm.nes.nec.co.jp> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Tested-by:
-
NeilBrown authored
Now that we support changing the chunksize, we calculate "reshape_sectors" to be the max of number of sectors in old and new chunk size. However there is one please where we still use 'chunksize' rather than 'reshape_sectors'. This causes a reshape that reduces the size of chunks to freeze. Signed-off-by:NeilBrown <neilb@suse.de>
-
