- 02 Apr, 2012 32 commits
-
-
Thomas Tuttle authored
commit 2db4d870 upstream. Signed-off-by:
Thomas Tuttle <ttuttle@chromium.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Josh Boyer authored
commit 4898e071 upstream. __do_config_autodelink passes the data variable to the transport function. If the calling functions pass a stack variable, this will eventually trigger a DMA-API debug backtrace for mapping stack memory in the DMA buffer. Fix this by calling kmemdup for the passed data instead. Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
commit e90fc3cb upstream. When build i.mx platform with imx_v6_v7_defconfig, and after adding USB Gadget support, it has below build error: CC drivers/usb/host/fsl-mph-dr-of.o drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register': drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata' has no member named 'dma_mask' It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html For PowerPC, there is dma_mask at struct pdev_archdata, but there is no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is related to specific platform, it should NOT be accessed by cross platform drivers, like USB. The code for pdev_archdata should be useless, as for PowerPC, it has already gotten the value for pdev->dev.dma_mask at function arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c. Tested-by:
Ramneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Peter Chen authored
commit c5cc5ed8 upstream. When loading g_ether gadget, there is below message: Backtrace: [<80012248>] (dump_backtrace+0x0/0x10c) from [<803cb42c>] (dump_stack+0x18/0x1c) r7:00000000 r6:80512000 r5:8052bef8 r4:80513f30 [<803cb414>] (dump_stack+0x0/0x1c) from [<8000feb4>] (show_regs+0x44/0x50) [<8000fe70>] (show_regs+0x0/0x50) from [<8004c840>] (__schedule_bug+0x68/0x84) r5:8052bef8 r4:80513f30 [<8004c7d8>] (__schedule_bug+0x0/0x84) from [<803cd0e4>] (__schedule+0x4b0/0x528) r5:8052bef8 r4:809aad00 [<803ccc34>] (__schedule+0x0/0x528) from [<803cd214>] (_cond_resched+0x44/0x58) [<803cd1d0>] (_cond_resched+0x0/0x58) from [<800a9488>] (dma_pool_alloc+0x184/0x250) r5:9f9b4000 r4:9fb4fb80 [<800a9304>] (dma_pool_alloc+0x0/0x250) from [<802a8ad8>] (fsl_req_to_dtd+0xac/0x180) [<802a8a2c>] (fsl_req_to_dtd+0x0/0x180) from [<802a8ce4>] (fsl_ep_queue+0x138/0x274) [<802a8bac>] (fsl_ep_queue+0x0/0x274) from [<7f004328>] (composite_setup+0x2d4/0xfac [g_ether]) [<7f004054>] (composite_setup+0x0/0xfac [g_ether]) from [<802a9bb4>] (fsl_udc_irq+0x8dc/0xd38) [<802a92d8>] (fsl_udc_irq+0x0/0xd38) from [<800704f8>] (handle_irq_event_percpu+0x54/0x188) [<800704a4>] (handle_irq_event_percpu+0x0/0x188) from [<80070674>] (handle_irq_event+0x48/0x68) [<8007062c>] (handle_irq_event+0x0/0x68) from [<800738ec>] (handle_level_irq+0xb4/0x138) r5:80514f94 r4:80514f40 [<80073838>] (handle_level_irq+0x0/0x138) from [<8006ffa4>] (generic_handle_irq+0x38/0x44) r7:00000012 r6:80510b1c r5:80529860 r4:80512000 [<8006ff6c>] (generic_handle_irq+0x0/0x44) from [<8000f4c4>] (handle_IRQ+0x54/0xb4) [<8000f470>] (handle_IRQ+0x0/0xb4) from [<800085b8>] (tzic_handle_irq+0x64/0x94) r9:412fc085 r8:00000000 r7:80513f30 r6:00000001 r5:00000000 r4:00000000 [<80008554>] (tzic_handle_irq+0x0/0x94) from [<8000e680>] (__irq_svc+0x40/0x60) The reason of above dump message is calling dma_poll_alloc with can-schedule mem_flags at atomic context. To fix this problem, below changes are made: - fsl_req_to_dtd doesn't need to be protected by spin_lock_irqsave, as struct usb_request can be access at process context. Move lock to beginning of hardware visit (fsl_queue_td). - Change the memory flag which using to allocate dTD descriptor buffer, the memory flag can be from gadget layer. It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial. Signed-off-by:
Li Yang <leoli@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Ben Hutchings authored
commit b7a20554 upstream. The WDM_READ flag is cleared later iff desc->length is reduced to 0. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Tested-by:
Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Ben Hutchings authored
commit 711c68b3 upstream. We must not allow the input buffer length to change while we're shuffling the buffer contents. We also mustn't clear the WDM_READ flag after more data might have arrived. Therefore move both of these into the spinlocked region at the bottom of wdm_read(). When reading desc->length without holding the iuspin lock, use ACCESS_ONCE() to ensure the compiler doesn't re-read it with inconsistent results. Signed-off-by:
-
Johan Hovold authored
commit 548dd4b6 upstream. Do not report errors in write path if port is used as a console as this may trigger the same error (and error report) resulting in a loop. Reported-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Liz Clark authored
commit 4a4c61b7 upstream. Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map https://bugzilla.kernel.org/show_bug.cgi?id=40012 The unicode font map for the virtual console is a 32x32x64 table which allocates rows dynamically as entries are added. The unicode value increases sequentially and should count all entries even in empty rows. The defect is when copying the unicode font map in con_set_unimap(), the unicode value is not incremented properly. The wrong unicode value is entered in the new font map. Signed-off-by:
Liz Clark <liz.clark@hp.com> Signed-off-by:
-
Dan Carpenter authored
commit 58112dfb upstream. This is supposed to be doing a shift before the comparison instead of just doing a bitwise AND directly. The current code means the start() just returns without doing anything. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Masami Ichikawa authored
commit 93518dd2 upstream. This patch fixies follwing two memory leak patterns that reported by kmemleak. sysfs_sd_setsecdata() is called during sys_lsetxattr() operation. It checks sd->s_iattr is NULL or not. Then if it is NULL, it calls sysfs_init_inode_attrs() to allocate memory. That code is this. iattrs = sd->s_iattr; if (!iattrs) iattrs = sysfs_init_inode_attrs(sd); The iattrs recieves sysfs_init_inode_attrs()'s result, but sd->s_iattr doesn't know the address. so it needs to set correct address to sd->s_iattr to free memory in other function. unreferenced object 0xffff880250b73e60 (size 32): comm "systemd", pid 1, jiffies 4294683888 (age 94.553s) hex dump (first 32 bytes): 73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system_u:object_ 72 3a 73 79 73 66 73 5f 74 3a 73 30 00 00 00 00 r:sysfs_t:s0.... backtrace: [<ffffffff814cb1d0>] kmemleak_alloc+0x73/0x98 [<ffffffff811270ab>] __kmalloc+0x100/0x12c [<ffffffff8120775a>] context_struct_to_string+0x106/0x210 [<ffffffff81207cc1>] security_sid_to_context_core+0x10b/0x129 [<ffffffff812090ef>] security_sid_to_context+0x10/0x12 [<ffffffff811fb0da>] selinux_inode_getsecurity+0x7d/0xa8 [<ffffffff811fb127>] selinux_inode_getsecctx+0x22/0x2e [<ffffffff811f4d62>] security_inode_getsecctx+0x16/0x18 [<ffffffff81191dad>] sysfs_setxattr+0x96/0x117 [<ffffffff811542f0>] __vfs_setxattr_noperm+0x73/0xd9 [<ffffffff811543d9>] vfs_setxattr+0x83/0xa1 [<ffffffff811544c6>] setxattr+0xcf/0x101 [<ffffffff81154745>] sys_lsetxattr+0x6a/0x8f [<ffffffff814efda9>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff88024163c5a0 (size 96): comm "systemd", pid 1, jiffies 4294683888 (age 94.553s) hex dump (first 32 bytes): 00 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 .....A.......... 00 00 00 00 00 00 00 00 0c 64 42 4f 00 00 00 00 .........dBO.... backtrace: [<ffffffff814cb1d0>] kmemleak_alloc+0x73/0x98 [<ffffffff81127402>] kmem_cache_alloc_trace+0xc4/0xee [<ffffffff81191cbe>] sysfs_init_inode_attrs+0x2a/0x83 [<ffffffff81191dd6>] sysfs_setxattr+0xbf/0x117 [<ffffffff811542f0>] __vfs_setxattr_noperm+0x73/0xd9 [<ffffffff811543d9>] vfs_setxattr+0x83/0xa1 [<ffffffff811544c6>] setxattr+0xcf/0x101 [<ffffffff81154745>] sys_lsetxattr+0x6a/0x8f [<ffffffff814efda9>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff ` Signed-off-by:
Masami Ichikawa <masami256@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
commit 59263b51 upstream. Some of the newer futex PI opcodes do not check the cmpxchg enabled variable and call unconditionally into the handling functions. Cover all PI opcodes in a separate check. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Orjan Friberg authored
commit 33d2832a upstream. HID devices should specify this in their interface descriptors, not in the device descriptor. This fixes a "missing hardware id" bug under Windows 7 with a VIA VL800 (3.0) controller. Signed-off-by:
Orjan Friberg <of@flatfrog.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Thomas Faber authored
commit 85b4b3c8 upstream. A read from GadgetFS endpoint 0 during the data stage of a control request would always return 0 on success (as returned by wait_event_interruptible) despite having written data into the user buffer. This patch makes it correctly set the return value to the number of bytes read. Signed-off-by:
Thomas Faber <thfabba@gmx.de> Signed-off-by:
-
Kuninori Morimoto authored
commit 3b2a2e47 upstream. This patch fixup below warning on device_unregister() renesas_usbhs renesas_usbhs.1: host probed renesas_usbhs renesas_usbhs.1: gadget probed renesas_usbhs renesas_usbhs.1: irq request err ------------[ cut here ]------------ WARNING: at ${LINUX}/drivers/base/core.c:1) Device 'gadget' does not have a release() function, it is broken and must be fi. Modules linked in: [<c000e25c>] (unwind_backtrace+0x0/0xe4) from [<c0016960>] (warn_slowpath_commo) [<c0016960>] (warn_slowpath_common+0x4c/0x64) from [<c00169f8>] (warn_slowpath_) [<c00169f8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0185b80>] (device_release+0x) [<c0185b80>] (device_release+0x70/0x84) from [<c013e300>] (kobject_cleanup+0x58) [<c013e300>] (kobject_cleanup+0x58/0x6c) from [<c01cba14>] (usbhs_mod_gadget_re) [<c01cba14>] (usbhs_mod_gadget_remove+0x3c/0x6c) from [<c01c8384>] (usbhs_mod_p) [<c01c8384>] (usbhs_mod_probe+0x68/0x80) from [<c01c7f84>] (usbhs_probe+0x1cc/0) ... Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Supriya Karanth authored
commit 39287076 upstream. musb INDEX register is getting modified/corrupted during temporary un-locking in a SMP system. Set this register with proper value after re-acquiring the lock Scenario: --------- CPU1 is handling a data transfer completion interrupt received for the CLASS1 EP CPU2 is handling a CLASS2 thread which is queuing data to musb for transfer Below is the error sequence: CPU1 | CPU2 -------------------------------------------------------------------- Data transfer completion inter- | rupt recieved. | | musb INDEX reg set to CLASS1 EP | | musb LOCK is acquired. | | | CLASS2 thread queues data. | | CLASS2 thread tries to acquire musb | LOCK but lock is already taken by | CLASS1, so CLASS2 thread is | spinning. | From Interrupt Context musb | giveback function is called | | The giveback function releases | CLASS2 thread now acquires LOCK LOCK | | ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and lback is called | sets the MUSB INDEX to Class2 EP number | Interrupt handler for CLASS1 EP | tries to acquire LOCK and is | spinning | | Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and the MUSB LOCK | releases the musb LOCK | Interrupt for Class1 EP schedul-| es the next data transfer | but musb INDEX register is still| set to CLASS2 EP | Since the MUSB INDEX register is set to a different endpoint, we read and modify the wrong registers. Hence data transfer will not happen properly. This results in unpredictable behavior So, the MUSB INDEX register is set to proper value again when interrupt re-acquires the lock Signed-off-by:
Supriya Karanth <supriya.karanth@stericsson.com> Signed-off-by:
Praveena Nadahally <praveen.nadahally@stericsson.com> Reviewed-by:
srinidhi kasagar <srinidhi.kasagar@stericsson.com> Signed-off-by:
-
Anton Tikhomirov authored
commit 27a78d6a upstream. It's wrong to use the size of array as an argument for strncat. Memory corruption is possible. strlcat is exactly what we need here. Signed-off-by:
Anton Tikhomirov <av.tikhomirov@samsung.com> Signed-off-by:
-
Paul Zimmerman authored
commit 9bafa56c upstream. Zero is a valid value for a microframe number. So remove the bogus test for non-zero in dwc3_gadget_start_isoc(). Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Larry Finger authored
commit da3e6ec2 upstream. In commit c6dc001f "staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes", the returned qual.qual member of the iw_statistics struct was changed. For strong signals, this change made no difference; however for medium and weak signals it results in a low signal that shows considerable fluctuation, When using wicd for a medium-strength AP, the value reported in the status line is reduced from 100% to 60% by this bug. This problem is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42826. Reported-and-tested-by:
Robert Crawford <wrc1944@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
commit 9f4bc8cf upstream. In commit a5ee6529 "staging: r8712u: Interface-state not fully tracked", the private boolean "bup" was set false when the interface was brought down, as that seemed appropriate. This change has not caused any problems when using NetworkManager or manual control of the device; however, when wicd control is used, there is a locking problem in wpa_supplicant, as shown in https://bugzilla.kernel.org/show_bug.cgi?id=42818. This fix reverts the only code change in commit a5ee6529. My analysis is that "bup" is badly named. In its present form, it seems to indicate the up/down state of the device, but its usage is more consistent with an initialized/uninitialized state. That problem will be addressed in a later patch. Note: Commit 8c213fa, which introdued asynchronous firmware loading for this driver, exposed this bug to a greater extent. That bug is addressed in the next patch in this series. This bug is also responsible for the bug in https://bugzilla.kernel.org/show_bug.cgi?id=42815. and this bug is also part of the problems discussed at https://bugs.archlinux.org/task/27996#comment89950. Tested-by:
Alberto Lago Ballesteros <saniukeokusainaya@gmail.com> Tested-by:
Adrian <agib@gmx.de> Signed-off-by:
-
Larry Finger authored
commit 07386343 upstream. When this driver was upgraded to the vendor 20100831 version in commit 93c55dda et al,, one listhead initialization was missed. This broke complete operation of the driver whenever AP mode was enabled. This fixes https://bugs.archlinux.org/task/27996. The configuration parameter R8712_AP is misleading as the driver cannot function as an AP without a heavily hacked version of hostapd. Thus, it makes sense to remove the parameter; however the code and data configured for the option is left in. Signed-off-by:
-
Shengzhou Liu authored
commit 28c56ea1 upstream. If USB UTMI PHY is not enable, writing to portsc register will lead to kernel hang during boot up. Signed-off-by:
Shengzhou Liu <Shengzhou.Liu@freescale.com> Reported-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Michał Wróbel authored
commit 57e596f3 upstream. Signed-off-by:
Michał Wróbel <michal.wrobel@flytronic.pl> Signed-off-by:
-
Jim Paris authored
commit dc0827c1 upstream. Add PID 0x6015, corresponding to the new series of FT-X chips (FT220XD, FT201X, FT220X, FT221X, FT230X, FT231X, FT240X). They all appear as serial devices, and seem indistinguishable except for the default product string stored in their EEPROM. The baudrate generation matches FT232RL devices. Tested with a FT201X and FT230X at various baudrates (100 - 3000000). Sample dmesg: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver usb 2-1: new full-speed USB device number 6 using ohci_hcd usb 2-1: New USB device found, idVendor=0403, idProduct=6015 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: FT230X USB Half UART usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: DC001WI6 ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: ftdi_sio_port_probe drivers/usb/serial/ftdi_sio.c: ftdi_determine_type: bcdDevice = 0x1000, bNumInterfaces = 1 usb 2-1: Detected FT-X usb 2-1: Number of endpoints 2 usb 2-1: Endpoint 1 MaxPacketSize 64 usb 2-1: Endpoint 2 MaxPacketSize 64 usb 2-1: Setting MaxPacketSize 64 drivers/usb/serial/ftdi_sio.c: read_latency_timer drivers/usb/serial/ftdi_sio.c: write_latency_timer: setting latency timer = 1 drivers/usb/serial/ftdi_sio.c: create_sysfs_attrs drivers/usb/serial/ftdi_sio.c: sysfs attributes for FT-X usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0 Signed-off-by:
Jim Paris <jim@jtan.com> Signed-off-by:
-
Michał Wróbel authored
commit 47594d55 upstream. Signed-off-by:
-
Bruno Thomsen authored
commit c1cee1d8 upstream. Microchip VID (0x04d8) was mislabeled as Hornby VID according to USB-IDs. A Full Speed USB Demo Board PID (0x000a) was mislabeled as Hornby Elite (an Digital Command Controller Console for model railways). Most likely the Hornby based their design on PIC18F87J50 Full Speed USB Demo Board. Signed-off-by:
Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by:
-
Peter Korsgaard authored
commit 444aa7fa upstream. BeagleBone changed to the default FTDI 0403:6010 id in rev A5 to make life easier for Windows users, so we need a similar workaround as the Calao board to support it. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 656d2b39 upstream. On some misconfigured ftdi_sio devices, if the manufacturer string is NULL, the kernel will oops when the device is plugged in. This patch fixes the problem. Reported-by:
Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl> Tested-by:
-
Andrea Righi authored
commit cfbc6a92 upstream. Commit 9256a478 fixed a deadlock condition, being sure that the buddy list spinlock is always taken before the page spinlock. However in zbud_free_and_delist() locking order is the opposite (page lock -> list lock). Possible unsafe locking scenario (reported by lockdep): CPU0 CPU1 ---- ---- lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); Fix by grabbing the locks in opposite order in zbud_free_and_delist(). Signed-off-by:
Andrea Righi <andrea@betterlinux.com> Signed-off-by:
-
Bjørn Mork authored
commit 5889d3d4 upstream. This device presents a total of 5 interfaces with ff/ff/ff class/subclass/protocol. The last one of these is verified to be a QMI/wwan combined interface which should be handled by the qmi_wwan driver, so we blacklist it here. Signed-off-by:
-
Bjørn Mork authored
commit 963940cf upstream. commit 0d905fd5 "USB: option: convert Huawei K3765, K4505, K4605 reservered interface to blacklist" accidentally ANDed two blacklist tests by leaving out a return. This was not noticed because the two consecutive bracketless if statements made it syntactically correct. Signed-off-by:
-
Daniele Palmas authored
commit 7204cf58 upstream. Adding PID for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL modems Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Meng Zhang authored
commit 0d8520a1 upstream. Add MEDIATEK products to Option driver Signed-off-by:
Meng Zhang <meng.zhang@mediatek.com> Signed-off-by:
Matthias Urlichs <matthias@urlichs.de> Signed-off-by:
-
- 23 Mar, 2012 8 commits
-
-
Greg Kroah-Hartman authored
-
Benjamin Herrenschmidt authored
commit 78c5c68a upstream. The code for "powersurge" SMP would kick in and cause a crash at boot due to the lack of a NULL test. Signed-off-by:
Jeremy Kerr <jeremy.kerr@canonical.com> Reported-by:
Adam Conrad <adconrad@ubuntu.com> Tested-by:
-
Stanislaw Gruszka authored
commit 210787e8 upstream. On il3945_down procedure we free tx queue data and nullify il->txq pointer. After that we drop mutex and then cancel delayed works. There is possibility, that after drooping mutex and before the cancel, some delayed work will start and crash while trying to send commands to the device. For example, here is reported crash in il3945_bg_reg_txpower_periodic(): https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10 Patch fix problem by adding il->txq check on works that send commands, hence utilize tx queue. Reported-by:
Clemens Eisserer <linuxhippy@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
RongQing.Li authored
[ Upstream commit c5779237 ] ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't need to dev_hold(). With dev_hold(), not corresponding dev_put(), will lead to leak. [ bug introduced in 96b52e61 (ipv6: mcast: RCU conversions) ] Signed-off-by:
RongQing.Li <roy.qing.li@gmail.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit dfd25fff ] commit ea4fc0d6 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit()) added a serious regression on synflood handling. Simon Kirby discovered a successful connection was delayed by 20 seconds before being responsive. In my tests, I discovered that xmit frames were lost, and needed ~4 retransmits and a socket dst rebuild before being really sent. In case of syncookie initiated connection, we use a different path to initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared. As ip_queue_xmit() now depends on inet flow being setup, fix this by copying the temp flowi4 we use in cookie_v4_check(). Reported-by:
Simon Kirby <sim@netnation.com> Bisected-by:
-
Arnaldo Carvalho de Melo authored
commit e7f01d1e upstream. Several places were expecting that the value returned was the number of characters printed, not what would be printed if there was space. Fix it by using the scnprintf and vscnprintf variants we inherited from the kernel sources. Some corner cases where the number of printed characters were not accounted were fixed too. Reported-by:
Anton Blanchard <anton@samba.org> Cc: Anton Blanchard <anton@samba.org> Cc: Eric B Munson <emunson@mgebm.net> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com> Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Anton Blanchard authored
commit b832796c upstream. I have a workload where perf top scribbles over the stack and we SEGV. What makes it interesting is that an snprintf is causing this. The workload is a c++ gem that has method names over 3000 characters long, but snprintf is designed to avoid overrunning buffers. So what went wrong? The problem is we assume snprintf returns the number of characters written: ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level); ... ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name); Unfortunately this is not how snprintf works. snprintf returns the number of characters that would have been written if there was enough space. In the above case, if the first snprintf returns a value larger than size, we pass a negative size into the second snprintf and happily scribble over the stack. If you have 3000 character c++ methods thats a lot of stack to trample. This patch fixes repsep_snprintf by clamping the value at size - 1 which is the maximum snprintf can write before adding the NULL terminator. I get the sinking feeling that there are a lot of other uses of snprintf that have this same bug, we should audit them all. Cc: David Ahern <dsahern@gmail.com> Cc: Eric B Munson <emunson@mgebm.net> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com> Link: http://lkml.kernel.org/r/20120307114249.44275ca3@krytenSigned-off-by:
-
Anton Blanchard authored
commit c0173863 upstream. When writing files to afs I sometimes hit a BUG: kernel BUG at fs/afs/rxrpc.c:179! With a backtrace of: afs_free_call afs_make_call afs_fs_store_data afs_vnode_store_data afs_write_back_from_locked_page afs_writepages_region afs_writepages The cause is: ASSERT(skb_queue_empty(&call->rx_queue)); Looking at a tcpdump of the session the abort happens because we are exceeding our disk quota: rx abort fs reply store-data error diskquota exceeded (32) So the abort error is valid. We hit the BUG because we haven't freed all the resources for the call. By freeing any skbs in call->rx_queue before calling afs_free_call we avoid hitting leaking memory and avoid hitting the BUG. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
