aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-09-04Staging: Android alarm: IOCTL command encoding fixDae S. Kim1-1/+3
Fixed a bug. Data was being written to user space using an IOCTL command encoded with _IOC_WRITE access mode. Signed-off-by: Dae S. Kim <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: vt6656: [BUG] - Failed connection, incorrect endian.Malcolm Priestley2-20/+20
Hi, This patch fixes a bug with driver failing to negotiate a connection. The bug was traced to commit 203e4615ee9d9fa8d3506b9d0ef30095e4d5bc90 staging: vt6656: removed custom definitions of Ethernet packet types In that patch, definitions in include/linux/if_ether.h replaced ones in tether.h which had both big and little endian definitions. include/linux/if_ether.h only refers to big endian values, cpu_to_be16 should be used for the correct endian architectures. Signed-off-by: Malcolm Priestley <[email protected]> Cc: stable <[email protected]> # 2.6.37+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04l2tp: fix a typo in l2tp_eth_dev_recv()Eric Dumazet1-1/+1
While investigating l2tp bug, I hit a bug in eth_type_trans(), because not enough bytes were pulled in skb head. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-04staging: ozwpan: fix memcmp() test in oz_set_active_pd()Tomas Winkler1-1/+2
"addr" is a pointer so it's either 4 or 8 bytes, but actually we want to compare 6 bytes (ETH_ALEN). As network stack already provides helper function is_zero_ether_addr() we use that instead of memcmp Signed-off-by: Tomas Winkler <[email protected]> Acked-by: Dan Carpenter <[email protected]> Acked-by: Rupesh Gujare <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: wlan-ng: Fix problem with wrong argumentsEmil Goode1-2/+2
The function pointer scan in struct cfg80211_ops is not supposed to be assigned a function with a struct net_device pointer as an argument. Instead access the net_device struct in the following way: struct net_device *dev = request->wdev->netdev; sparse gives these warnings: drivers/staging/wlan-ng/cfg80211.c:726:17: warning: incorrect type in initializer (incompatible argument 2 (different base types)) expected int ( *scan )( ... ) got int ( extern [toplevel] *<noident> )( ... ) drivers/staging/wlan-ng/cfg80211.c:726:2: warning: initialization from incompatible pointer type [enabled by default] drivers/staging/wlan-ng/cfg80211.c:726:2: warning: (near initialization for ‘prism2_usb_cfg_ops.scan’) [enabled by default] Signed-off-by: Emil Goode <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04Merge branch 'fixes' of ↵David S. Miller3-7/+9
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch
2012-09-04i825xx: fix paging fault on znet_probe()Wu Fengguang1-4/+9
In znet_probe(), strncmp() may access beyond 0x100000 and trigger the below oops in kvm. Fix it by limiting the loop under 0x100000-8. I suspect the limit could be further decreased to 0x100000-sizeof(struct netidblk), however no datasheet at hand.. [ 3.744312] BUG: unable to handle kernel paging request at 80100000 [ 3.746145] IP: [<8119d12a>] strncmp+0xc/0x20 [ 3.747446] *pde = 01d10067 *pte = 00100160 [ 3.747493] Oops: 0000 [#1] DEBUG_PAGEALLOC [ 3.747493] Pid: 1, comm: swapper Not tainted 3.6.0-rc1-00018-g57bfc0a #73 Bochs Bochs [ 3.747493] EIP: 0060:[<8119d12a>] EFLAGS: 00010206 CPU: 0 [ 3.747493] EIP is at strncmp+0xc/0x20 [ 3.747493] EAX: 800fff4e EBX: 00000006 ECX: 00000006 EDX: 814d2bb9 [ 3.747493] ESI: 80100000 EDI: 814d2bba EBP: 8e03dfa0 ESP: 8e03df98 [ 3.747493] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 3.747493] CR0: 8005003b CR2: 80100000 CR3: 016f7000 CR4: 00000690 [ 3.747493] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 3.747493] DR6: ffff0ff0 DR7: 00000400 [ 3.747493] Process swapper (pid: 1, ti=8e03c000 task=8e040000 task.ti=8e03c000) [ 3.747493] Stack: [ 3.747493] 800fffff 00000000 8e03dfb4 816a1376 00000006 816a134a 00000000 8e03dfd0 [ 3.747493] 816819b5 816ed1c0 8e03dfe4 00000006 00000123 816ed604 8e03dfe4 81681b29 [ 3.747493] 00000000 81681a5b 00000000 00000000 8134e542 00000000 00000000 00000000 [ 3.747493] Call Trace: [ 3.747493] [<816a1376>] znet_probe+0x2c/0x26b [ 3.747493] [<816a134a>] ? dnet_driver_init+0xf/0xf [ 3.747493] [<816819b5>] do_one_initcall+0x6a/0x110 [ 3.747493] [<81681b29>] kernel_init+0xce/0x14b Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-04Merge tag 'v3.6-rc1-iio-fixes-2' of ↵Greg Kroah-Hartman8-2/+16
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus IIO fixes for v3.6-rc1 set 2 A few simple fixes. 1)Fix up some possible divide by zero issues in various drivers. 2)Prevent a memory leak in an error path in lis3l02dq 3)Make sure the PTR_ERR call in at91_adc matches the check for IS_ERR just above it rather than using a different pointer. Merges fine against v3.6rc4
2012-09-04staging: comedi: das08: Correct AO output for das08jr-16-aoIan Abbott1-1/+1
Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as that knobbles the upper three-quarters of the output range for the 'das08jr-16-ao' board. Cc: stable <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: das08: Correct AI encoding for das08jr-16-aoIan Abbott1-1/+1
The element of `das08_boards[]` for the 'das08jr-16-ao' board has the `ai_encoding` member set to `das08_encode12`. It should be set to `das08_encode16` same as the 'das08jr/16' board. After all, this board has 16-bit AI resolution. The description of the A/D LSB register at offset 0 seems incorrect in the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI resolution is only 12 bits. The diagrams of the A/D LSB and MSB registers show 15 data bits and a sign bit, which matches what the software expects for the `das08_encode16` AI encoding method. Cc: stable <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04NFSv4: Fix range checking in __nfs4_get_acl_uncached and __nfs4_proc_set_aclTrond Myklebust1-9/+11
Ensure that the user supplied buffer size doesn't cause us to overflow the 'pages' array. Also fix up some confusion between the use of PAGE_SIZE and PAGE_CACHE_SIZE when calculating buffer sizes. We're not using the page cache for anything here. Signed-off-by: Trond Myklebust <[email protected]>
2012-09-04NFS: Fix a problem with the legacy binary mount codeTrond Myklebust1-0/+2
Apparently, am-utils is still using the legacy binary mountdata interface, and is having trouble parsing /proc/mounts due to the 'port=' field being incorrectly set. The following patch should fix up the regression. Reported-by: Marius Tolzmann <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected]
2012-09-04NFS: Fix the initialisation of the readdir 'cookieverf' arrayTrond Myklebust4-9/+4
When the NFS_COOKIEVERF helper macro was converted into a static inline function in commit 99fadcd764 (nfs: convert NFS_*(inode) helpers to static inline), we broke the initialisation of the readdir cookies, since that depended on doing a memset with an argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *). At this point, NFS_COOKIEVERF seems to be more of an obfuscation than a helper, so the best thing would be to just get rid of it. Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881 Reported-by: Andi Kleen <[email protected]> Reported-by: David Binderman <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected]
2012-09-04staging: comedi: das08: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`das08_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `das08_find_pci()`). It is decremented when the `detach` hook (`das08_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`das08_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `das08_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: amplc_pci230: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`pci230_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `pci230_find_pci_dev()`). It is decremented when the `detach` hook (`pci230_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`pci230_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `pci230_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: amplc_pc263: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`pc263_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `pc263_find_pci_dev()`). It is decremented when the `detach` hook (`pc263_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`pc263_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `pc263_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: amplc_pc236: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`pc236_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `pc236_find_pci_dev()`). It is decremented when the `detach` hook (`pc236_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`pc236_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `pc236_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: amplc_dio200: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`dio200_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `dio200_find_pci_dev()`). It is decremented when the `detach` hook (`dio200_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`dio200_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `dio200_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04staging: comedi: amplc_pci224: Fix PCI ref countIan Abbott1-0/+7
When attaching a PCI device manually via the comedi driver `attach` hook (`pci224_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the `for_each_pci_dev` loop (in `pci224_find_pci_dev()`). It is decremented when the `detach` hook (`pci224_detach()`) is called to detach the device. However, when the PCI device is attached automatically via the `attach_pci` hook (`pci224_attach_pci()`, called at probe time via `comedi_pci_auto_config()`) it's reference count is not incremented so there will be an unmatched decrement when detaching the device. Increment the PCI device reference count in `pci224_attach_pci()` to correct the mismatch. Once support for manual configuration has been removed from this driver, the calls to `pci_dev_get()` and `pci_dev_put()` can be removed. Cc: stable <[email protected]> # 3.5.x Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-09-04xfrm: Workaround incompatibility of ESN and async cryptoSteffen Klassert3-1/+19
ESN for esp is defined in RFC 4303. This RFC assumes that the sequence number counters are always up to date. However, this is not true if an async crypto algorithm is employed. If the sequence number counters are not up to date on sequence number check, we may incorrectly update the upper 32 bit of the sequence number. This leads to a DOS. We workaround this by comparing the upper sequence number, (used for authentication) with the upper sequence number computed after the async processing. We drop the packet if these numbers are different. To do this, we introduce a recheck function that does this check in the ESN case. Signed-off-by: Steffen Klassert <[email protected]> Acked-by: Herbert Xu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-04l2tp: fix a lockdep splatEric Dumazet1-0/+4
Fixes following lockdep splat : [ 1614.734896] ============================================= [ 1614.734898] [ INFO: possible recursive locking detected ] [ 1614.734901] 3.6.0-rc3+ #782 Not tainted [ 1614.734903] --------------------------------------------- [ 1614.734905] swapper/11/0 is trying to acquire lock: [ 1614.734907] (slock-AF_INET){+.-...}, at: [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.734920] [ 1614.734920] but task is already holding lock: [ 1614.734922] (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0 [ 1614.734932] [ 1614.734932] other info that might help us debug this: [ 1614.734935] Possible unsafe locking scenario: [ 1614.734935] [ 1614.734937] CPU0 [ 1614.734938] ---- [ 1614.734940] lock(slock-AF_INET); [ 1614.734943] lock(slock-AF_INET); [ 1614.734946] [ 1614.734946] *** DEADLOCK *** [ 1614.734946] [ 1614.734949] May be due to missing lock nesting notation [ 1614.734949] [ 1614.734952] 7 locks held by swapper/11/0: [ 1614.734954] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff81592801>] __netif_receive_skb+0x251/0xd00 [ 1614.734964] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff815d319c>] ip_local_deliver_finish+0x4c/0x4e0 [ 1614.734972] #2: (rcu_read_lock){.+.+..}, at: [<ffffffff8160d116>] icmp_socket_deliver+0x46/0x230 [ 1614.734982] #3: (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0 [ 1614.734989] #4: (rcu_read_lock){.+.+..}, at: [<ffffffff815da240>] ip_queue_xmit+0x0/0x680 [ 1614.734997] #5: (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9925>] ip_finish_output+0x135/0x890 [ 1614.735004] #6: (rcu_read_lock_bh){.+....}, at: [<ffffffff81595680>] dev_queue_xmit+0x0/0xe00 [ 1614.735012] [ 1614.735012] stack backtrace: [ 1614.735016] Pid: 0, comm: swapper/11 Not tainted 3.6.0-rc3+ #782 [ 1614.735018] Call Trace: [ 1614.735020] <IRQ> [<ffffffff810a50ac>] __lock_acquire+0x144c/0x1b10 [ 1614.735033] [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0 [ 1614.735037] [<ffffffff810a6762>] ? mark_held_locks+0x82/0x130 [ 1614.735042] [<ffffffff810a5df0>] lock_acquire+0x90/0x200 [ 1614.735047] [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735051] [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10 [ 1614.735060] [<ffffffff81749b31>] _raw_spin_lock+0x41/0x50 [ 1614.735065] [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735069] [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735075] [<ffffffffa014f7f2>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth] [ 1614.735079] [<ffffffff81595112>] dev_hard_start_xmit+0x502/0xa70 [ 1614.735083] [<ffffffff81594c6e>] ? dev_hard_start_xmit+0x5e/0xa70 [ 1614.735087] [<ffffffff815957c1>] ? dev_queue_xmit+0x141/0xe00 [ 1614.735093] [<ffffffff815b622e>] sch_direct_xmit+0xfe/0x290 [ 1614.735098] [<ffffffff81595865>] dev_queue_xmit+0x1e5/0xe00 [ 1614.735102] [<ffffffff81595680>] ? dev_hard_start_xmit+0xa70/0xa70 [ 1614.735106] [<ffffffff815b4daa>] ? eth_header+0x3a/0xf0 [ 1614.735111] [<ffffffff8161d33e>] ? fib_get_table+0x2e/0x280 [ 1614.735117] [<ffffffff8160a7e2>] arp_xmit+0x22/0x60 [ 1614.735121] [<ffffffff8160a863>] arp_send+0x43/0x50 [ 1614.735125] [<ffffffff8160b82f>] arp_solicit+0x18f/0x450 [ 1614.735132] [<ffffffff8159d9da>] neigh_probe+0x4a/0x70 [ 1614.735137] [<ffffffff815a191a>] __neigh_event_send+0xea/0x300 [ 1614.735141] [<ffffffff815a1c93>] neigh_resolve_output+0x163/0x260 [ 1614.735146] [<ffffffff815d9cf5>] ip_finish_output+0x505/0x890 [ 1614.735150] [<ffffffff815d9925>] ? ip_finish_output+0x135/0x890 [ 1614.735154] [<ffffffff815dae79>] ip_output+0x59/0xf0 [ 1614.735158] [<ffffffff815da1cd>] ip_local_out+0x2d/0xa0 [ 1614.735162] [<ffffffff815da403>] ip_queue_xmit+0x1c3/0x680 [ 1614.735165] [<ffffffff815da240>] ? ip_local_out+0xa0/0xa0 [ 1614.735172] [<ffffffff815f4402>] tcp_transmit_skb+0x402/0xa60 [ 1614.735177] [<ffffffff815f5a11>] tcp_retransmit_skb+0x1a1/0x620 [ 1614.735181] [<ffffffff815f7e93>] tcp_retransmit_timer+0x393/0x960 [ 1614.735185] [<ffffffff815fce23>] ? tcp_v4_err+0x163/0x6b0 [ 1614.735189] [<ffffffff815fd317>] tcp_v4_err+0x657/0x6b0 [ 1614.735194] [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230 [ 1614.735199] [<ffffffff8160d19e>] icmp_socket_deliver+0xce/0x230 [ 1614.735203] [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230 [ 1614.735208] [<ffffffff8160d464>] icmp_unreach+0xe4/0x2c0 [ 1614.735213] [<ffffffff8160e520>] icmp_rcv+0x350/0x4a0 [ 1614.735217] [<ffffffff815d3285>] ip_local_deliver_finish+0x135/0x4e0 [ 1614.735221] [<ffffffff815d319c>] ? ip_local_deliver_finish+0x4c/0x4e0 [ 1614.735225] [<ffffffff815d3ffa>] ip_local_deliver+0x4a/0x90 [ 1614.735229] [<ffffffff815d37b7>] ip_rcv_finish+0x187/0x730 [ 1614.735233] [<ffffffff815d425d>] ip_rcv+0x21d/0x300 [ 1614.735237] [<ffffffff81592a1b>] __netif_receive_skb+0x46b/0xd00 [ 1614.735241] [<ffffffff81592801>] ? __netif_receive_skb+0x251/0xd00 [ 1614.735245] [<ffffffff81593368>] process_backlog+0xb8/0x180 [ 1614.735249] [<ffffffff81593cf9>] net_rx_action+0x159/0x330 [ 1614.735257] [<ffffffff810491f0>] __do_softirq+0xd0/0x3e0 [ 1614.735264] [<ffffffff8109ed24>] ? tick_program_event+0x24/0x30 [ 1614.735270] [<ffffffff8175419c>] call_softirq+0x1c/0x30 [ 1614.735278] [<ffffffff8100425d>] do_softirq+0x8d/0xc0 [ 1614.735282] [<ffffffff8104983e>] irq_exit+0xae/0xe0 [ 1614.735287] [<ffffffff8175494e>] smp_apic_timer_interrupt+0x6e/0x99 [ 1614.735291] [<ffffffff81753a1c>] apic_timer_interrupt+0x6c/0x80 [ 1614.735293] <EOI> [<ffffffff810a14ad>] ? trace_hardirqs_off+0xd/0x10 [ 1614.735306] [<ffffffff81336f85>] ? intel_idle+0xf5/0x150 [ 1614.735310] [<ffffffff81336f7e>] ? intel_idle+0xee/0x150 [ 1614.735317] [<ffffffff814e6ea9>] cpuidle_enter+0x19/0x20 [ 1614.735321] [<ffffffff814e7538>] cpuidle_idle_call+0xa8/0x630 [ 1614.735327] [<ffffffff8100c1ba>] cpu_idle+0x8a/0xe0 [ 1614.735333] [<ffffffff8173762e>] start_secondary+0x220/0x222 Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-04mmc: omap: fix broken PIO modePaul Walmsley1-3/+11
After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 ("mmc: omap_hsmmc: remove private DMA API implementation"), the Nokia N800 here stopped booting: [ 2.086181] Waiting for root device /dev/mmcblk0p1... [ 2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000 [ 2.331451] Internal error: : 406 [#1] ARM [ 2.335784] Modules linked in: [ 2.339050] CPU: 0 Not tainted (3.6.0-rc3 #60) [ 2.344146] PC is at default_idle+0x28/0x30 [ 2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0 ... This turned out to be due to memory corruption caused by long-broken PIO code in drivers/mmc/host/omap.c. (Previously, this driver had been using DMA; but the above commit caused the MMC driver to fall back to PIO mode with an unmodified Kconfig.) The PIO code, added with the rest of the driver in commit 730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ("[MMC] Add OMAP MMC host driver"), confused bytes with 16-bit words. This bug caused memory located after the PIO transfer buffer to be corrupted with transfers larger than 32 bytes. The driver also did not increment the buffer pointer after the transfer occurred. This bug resulted in data corruption during any transfer larger than 64 bytes. Signed-off-by: Paul Walmsley <[email protected]> Reviewed-by: Felipe Balbi <[email protected]> Tested-by: Tony Lindgren <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.Ian Chen2-1/+26
For several MoviNAND eMMC parts, there are known issues with secure erase and secure trim. For these specific MoviNAND devices, we skip these operations. Specifically, there is a bug in the eMMC firmware that causes unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE enabled. References: http://forum.xda-developers.com/showthread.php?t=1644364 https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB Signed-off-by: Ian Chen <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Acked-by: Jaehoon Chung <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Cc: stable <[email protected]> [3.0+] Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: dw_mmc: Disable low power mode if SDIO interrupts are usedDoug Anderson1-3/+38
The documentation for the dw_mmc part says that the low power mode should normally only be set for MMC and SD memory and should be turned off for SDIO cards that need interrupts detected. The best place I could find to do this is when the SDIO interrupt was first enabled. I rely on the fact that dw_mci_setup_bus() will be called when it's time to reenable. Signed-off-by: Doug Anderson <[email protected]> Acked-by: Seungwon Jeon <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: dw_mmc: fix error handling in PIO modeSeungwon Jeon1-27/+2
Data transfer will be continued until all the bytes are transmitted, even if data crc error occurs during a multiple-block data transfer. This means RXDR/TXDR interrupts will occurs until data transfer is terminated. Early setting of host->sg to NULL prevents going into xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts occurs. And checking error interrupt status in the xxx_data_pio functions is no need because dw_mci_interrupt does do the same. This patch also removes it. Signed-off-by: Seungwon Jeon <[email protected]> Acked-by: Jaehoon Chung <[email protected]> Acked-by: Will Newton <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: dw_mmc: correct mishandling error interruptSeungwon Jeon1-3/+1
Datasheet of SYNOPSYS mentions that DTO(Data Transfer Over) interrupt will be raised even if some error interrupts, however it is actually found that DTO does not occur. SYNOPSYS has confirmed this issue. Current implementation defers the call of tasklet_schedule until DTO when the error interrupts is happened. This patch fixes error handling. Signed-off-by: Seungwon Jeon <[email protected]> Acked-by: Jaehoon Chung <[email protected]> Acked-by: Will Newton <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: dw_mmc: amend using error interrupt statusSeungwon Jeon1-6/+5
RINTSTS status includes masked interrupts as well as unmasked. data_status and cmd_status are set by value of RINTSTS in interrupt handler and tasklet finally uses it to decide whether error is happened or not. In addition, MINTSTS status is used for setting data_status in PIO. Masked error interrupt will not be handled and that status can be considered non-error case. Signed-off-by: Seungwon Jeon <[email protected]> Reviewed By: Girish K S <[email protected]> Acked-by: Jaehoon Chung <[email protected]> Acked-by: Will Newton <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: atmel-mci: not busy flag has also to be used for read operationsLudovic Desroches1-1/+5
Even if the datasheet says that the not busy flag has to be used only for write operations, it's false except for version lesser than v2xx. Not waiting on the not busy flag for read operations can cause the controller to hang-up during the initialization of some SD cards with DMA after the first CMD6 -- the next command is sent too early. Signed-off-by: Ludovic Desroches <[email protected]> Cc: stable <[email protected]> [3.5, 3.6] Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: sdhci-esdhc: break out early if clock is 0Shawn Guo1-3/+3
Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value zero to set_clock host op") was merged, esdhc_set_clock starts hitting "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated. This causes SDHCI card-detection function being broken. Fix the regression by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation. Signed-off-by: Shawn Guo <[email protected]> Cc: <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: mxs-mmc: fix deadlock caused by recursion loopLauri Hintsala1-5/+5
Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_enable_sdio_irq. Backtrace: [ 65.470000] ============================================= [ 65.470000] [ INFO: possible recursive locking detected ] [ 65.470000] 3.5.0-rc5 #2 Not tainted [ 65.470000] --------------------------------------------- [ 65.470000] ksdioirqd/mmc0/73 is trying to acquire lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] but task is already holding lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] other info that might help us debug this: [ 65.470000] Possible unsafe locking scenario: [ 65.470000] [ 65.470000] CPU0 [ 65.470000] ---- [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] [ 65.470000] *** DEADLOCK *** [ 65.470000] [ 65.470000] May be due to missing lock nesting notation [ 65.470000] [ 65.470000] 1 lock held by ksdioirqd/mmc0/73: [ 65.470000] #0: (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] stack backtrace: [ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) [ 65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108) [ 65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) [ 65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98) [ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8) [ 65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73 [ 65.470000] lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0 [ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) [ 65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) [ 65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98) [ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8) Reported-by: Attila Kinali <[email protected]> Signed-off-by: Lauri Hintsala <[email protected]> Acked-by: Shawn Guo <[email protected]> Cc: stable <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: mxs-mmc: fix deadlock in SDIO IRQ caseLauri Hintsala1-2/+2
Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler. Backtrace: [ 79.660000] ============================================= [ 79.660000] [ INFO: possible recursive locking detected ] [ 79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted [ 79.660000] --------------------------------------------- [ 79.660000] swapper/0 is trying to acquire lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4 [ 79.660000] [ 79.660000] but task is already holding lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] other info that might help us debug this: [ 79.660000] Possible unsafe locking scenario: [ 79.660000] [ 79.660000] CPU0 [ 79.660000] ---- [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] [ 79.660000] *** DEADLOCK *** [ 79.660000] [ 79.660000] May be due to missing lock nesting notation [ 79.660000] [ 79.660000] 1 lock held by swapper/0: [ 79.660000] #0: (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] stack backtrace: [ 79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) [ 79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8) [ 79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) [ 79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c) [ 79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110) [ 79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50) [ 79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84) [ 79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60) [ 79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40) [ 79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc) [ 79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8) [ 79.660000] BUG: spinlock lockup on CPU#0, swapper/0 [ 79.660000] lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) [ 79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) [ 79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c) [ 79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110) [ 79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50) [ 79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84) [ 79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60) [ 79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40) [ 79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc) [ 79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8) Signed-off-by: Lauri Hintsala <[email protected]> Acked-by: Shawn Guo <[email protected]> Cc: stable <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04mmc: bfin_sdh: fix dma_desc_array build errorSonic Zhang1-7/+0
Descriptor array structure has been moved into blackfin dma.h head file. This patch fix below error: drivers/mmc/host/bfin_sdh.c:52:8: error: redefinition of 'struct dma_desc_array' make[4]: *** [drivers/mmc/host/bfin_sdh.o] Error 1 Signed-off-by: Sonic Zhang <[email protected]> Signed-off-by: Bob Liu <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-09-04netrom: copy_datagram_iovec can failAlan Cox1-1/+6
Check for an error from this and if so bail properly. Signed-off-by: Alan Cox <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-04fuse: fix retrieve lengthMiklos Szeredi1-0/+1
In some cases fuse_retrieve() would return a short byte count if offset was non-zero. The data returned was correct, though. Signed-off-by: Miklos Szeredi <[email protected]> Cc: [email protected]
2012-09-04nl80211: fix possible memory leak nl80211_connect()Wei Yongjun1-1/+3
connkeys is malloced in nl80211_parse_connkeys() and should be freed in the error handling case, otherwise it will cause memory leak. spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2012-09-04perf/hwpb: Invoke __perf_event_disable() if interrupts are already disabledK.Prasad3-2/+13
While debugging a warning message on PowerPC while using hardware breakpoints, it was discovered that when perf_event_disable is invoked through hw_breakpoint_handler function with interrupts disabled, a subsequent IPI in the code path would trigger a WARN_ON_ONCE message in smp_call_function_single function. This patch calls __perf_event_disable() when interrupts are already disabled, instead of perf_event_disable(). Reported-by: Edjunior Barbosa Machado <[email protected]> Signed-off-by: K.Prasad <[email protected]> [[email protected]: v3: Check to make sure we target current task] Signed-off-by: Naveen N. Rao <[email protected]> Acked-by: Frederic Weisbecker <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ Fixed build error on MIPS. ] Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04perf/x86: Enable Intel Cedarview Atom suppportStephane Eranian2-1/+3
This patch enables perf_events support for Intel Cedarview Atom (model 54) processors. Support includes PEBS and LBR. Tested on my Atom N2600 netbook. Signed-off-by: Stephane Eranian <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/20120820092421.GA11284@quad Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04perf_event: Switch to internal refcount, fix race with close()Al Viro2-30/+34
Don't mess with file refcounts (or keep a reference to file, for that matter) in perf_event. Use explicit refcount of its own instead. Deal with the race between the final reference to event going away and new children getting created for it by use of atomic_long_inc_not_zero() in inherit_event(); just have the latter free what it had allocated and return NULL, that works out just fine (children of siblings of something doomed are created as singletons, same as if the child of leader had been created and immediately killed). Signed-off-by: Al Viro <[email protected]> Cc: [email protected] Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04mac80211: clear bssid on auth/assoc failureEliad Peller1-0/+4
ifmgd->bssid wasn't cleared properly in some auth/assoc failure cases, causing mac80211 and the low-level driver to go out of sync. Clear ifmgd->bssid on failure, and notify the driver. Cc: [email protected] # 3.4+ Signed-off-by: Eliad Peller <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2012-09-04KVM: PIC: fix use of uninitialised variable.Jamie Iles1-1/+1
Commit aea218f3cbbc (KVM: PIC: call ack notifiers for irqs that are dropped form irr) used an uninitialised variable to track whether an appropriate apic had been found. This could result in calling the ack notifier incorrectly. Cc: Gleb Natapov <[email protected]> Cc: Avi Kivity <[email protected]> Signed-off-by: Jamie Iles <[email protected]> Signed-off-by: Avi Kivity <[email protected]>
2012-09-04sched: Fix kernel-doc warnings in kernel/sched/fair.cRandy Dunlap1-2/+0
Fix two kernel-doc warnings in kernel/sched/fair.c: Warning(kernel/sched/fair.c:3660): Excess function parameter 'cpus' description in 'update_sg_lb_stats' Warning(kernel/sched/fair.c:3806): Excess function parameter 'cpus' description in 'update_sd_lb_stats' Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04sched: Unthrottle rt runqueues in __disable_runtime()Peter Boonstoppel4-6/+6
migrate_tasks() uses _pick_next_task_rt() to get tasks from the real-time runqueues to be migrated. When rt_rq is throttled _pick_next_task_rt() won't return anything, in which case migrate_tasks() can't move all threads over and gets stuck in an infinite loop. Instead unthrottle rt runqueues before migrating tasks. Additionally: move unthrottle_offline_cfs_rqs() to rq_offline_fair() Signed-off-by: Peter Boonstoppel <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: Paul Turner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04sched: Add missing call to calc_load_exit_idle()Charles Wang1-0/+1
Azat Khuzhin reported high loadavg in Linux v3.6 After checking the upstream scheduler code, I found Peter's commit: 5167e8d5417b sched/nohz: Rewrite and fix load-avg computation -- again not fully applied, missing the call to calc_load_exit_idle(). After that idle exit in sampling window will always be calculated to non-idle, and the load will be higher than normal. This patch adds the missing call to calc_load_exit_idle(). Signed-off-by: Charles Wang <[email protected]> Cc: [email protected] Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04sched: Fix load avg vs cpu-hotplugPeter Zijlstra1-21/+10
Rabik and Paul reported two different issues related to the same few lines of code. Rabik's issue is that the nr_uninterruptible migration code is wrong in that he sees artifacts due to this (Rabik please do expand in more detail). Paul's issue is that this code as it stands relies on us using stop_machine() for unplug, we all would like to remove this assumption so that eventually we can remove this stop_machine() usage altogether. The only reason we'd have to migrate nr_uninterruptible is so that we could use for_each_online_cpu() loops in favour of for_each_possible_cpu() loops, however since nr_uninterruptible() is the only such loop and its using possible lets not bother at all. The problem Rabik sees is (probably) caused by the fact that by migrating nr_uninterruptible we screw rq->calc_load_active for both rqs involved. So don't bother with fancy migration schemes (meaning we now have to keep using for_each_possible_cpu()) and instead fold any nr_active delta after we migrate all tasks away to make sure we don't have any skewed nr_active accounting. Reported-by: Rakib Mullick <[email protected]> Reported-by: Paul E. McKenney <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/1345454817.23018.27.camel@twins Signed-off-by: Ingo Molnar <[email protected]>
2012-09-04UBI: fix a horrible memory deallocation bugArtem Bityutskiy1-2/+2
UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened only when we were doing auto-format, so many systems were unaffected. However, there are still many users affected. It is strange, but the system did not crash and nothing bad happened when the SLUB memory allocator was used. However, in case of SLOB we observed an crash right away. This problem was introduced in 2.6.39 by commit "6c1e875 UBI: add slab cache for ubi_scan_leb objects" A note for stable trees: Because variable were renamed, this won't cleanly apply to older kernels. Changing names like this should help: 1. ai -> si 2. aeb_slab_cache -> seb_slab_cache 3. new_aeb -> new_seb Reported-by: Richard Genoud <[email protected]> Tested-by: Richard Genoud <[email protected]> Tested-by: Artem Bityutskiy <[email protected]> Cc: [email protected] [v2.6.39+] Signed-off-by: Artem Bityutskiy <[email protected]>
2012-09-03openvswitch: Fix FLOW_BUFSIZE definition.Jesse Gross1-3/+5
The vlan encapsulation fields in the maximum flow defintion were never updated when the representation changed before upstreaming. In theory this could cause a kernel panic when a maximum length flow is used. In practice this has never happened (to my knowledge) because skb allocations are padded out to a cache line so you would need the right combination of flow and packet being sent to userspace. Signed-off-by: Jesse Gross <[email protected]>
2012-09-04ext3: Fix fdatasync() for files with only i_size changesJan Kara1-3/+14
Code tracking when transaction needs to be committed on fdatasync(2) forgets to handle a situation when only inode's i_size is changed. Thus in such situations fdatasync(2) doesn't force transaction with new i_size to disk and that can result in wrong i_size after a crash. Fix the issue by updating inode's i_datasync_tid whenever its size is updated. CC: <[email protected]> # >= 2.6.32 Reported-by: Kristian Nielsen <[email protected]> Signed-off-by: Jan Kara <[email protected]>
2012-09-03mISDN: fix possible memory leak in hfcmulti_init()Wei Yongjun1-0/+2
hc has been allocated in this function and missing free it before leaving from some error handling cases. spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-03drm/i915: do not expose a dysfunctional backlight interface to userspaceJani Nikula1-9/+22
Previously intel_panel_setup_backlight() would create a sysfs backlight interface with max brightness of 1 if it was unable to figure out the max backlight brightness. This rendered the backlight interface useless. Do not create a dysfunctional backlight interface to begin with. Signed-off-by: Jani Nikula <[email protected]> Tested-by: David Woodhouse <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2012-09-03fq_codel: dont reinit flow stateEric Dumazet1-1/+1
When fq_codel builds a new flow, it should not reset codel state. Codel algo needs to get previous values (lastcount, drop_next) to get proper behavior. Signed-off-by: Dave Taht <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Dave Taht <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.