- 27 Jan, 2015 40 commits
-
-
Sebastian Andrzej Siewior authored
commit 68693b8e upstream. since the split of host+gadget mode in commit 74c2e936 ("usb: musb: factor out hcd initalization") we leak the usb_hcd struct. We call now musb_host_cleanup() which does basically usb_remove_hcd() and also sets the hcd variable to NULL. Doing so makes the finall call to musb_host_free() basically a nop and the usb_hcd remains around for ever without anowner. This patch drops that NULL assignment for that reason. Fixes: 74c2e936 ("usb: musb: factor out hcd initalization") Cc: Daniel Mack <zonque@gmail.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit 6d89252a upstream. Commit c3ee9b76 (EHCI: improved logic for isochronous scheduling) introduced the idea of using ehci->last_iso_frame as the origin (or base) for the circular calculations involved in modifying the isochronous schedule. However, the new code it added used ehci->last_iso_frame before the value was properly initialized. This patch rectifies the mistake by moving the initialization lines earlier in iso_stream_schedule(). This fixes Bugzilla #72891. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Fixes: c3ee9b76Reported-by:
Joe Bryant <tenminjoe@yahoo.com> Tested-by:
Martin Long <martin@longhome.co.uk> Signed-off-by:
-
Johan Hovold authored
commit 32a4bf2e upstream. Use tty kref to release the fake tty in usb_console_setup to avoid use after free if the underlying serial driver has acquired a reference. Note that using the tty destructor release_one_tty requires some more state to be initialised. Fixes: 4a90f09b ("tty: usb-serial krefs") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit d269d443 upstream. The USB console currently allocates a temporary fake tty which is used to pass terminal settings to the underlying serial driver. The tty struct is not fully initialised, something which can lead to a lockdep warning (or worse) if a serial driver tries to acquire a line-discipline reference: usbserial: USB Serial support registered for pl2303 pl2303 1-2.1:1.0: pl2303 converter detected usb 1-2.1: pl2303 converter now attached to ttyUSB0 INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 68 Comm: udevd Tainted: G W 3.18.0-rc5 #10 [<c0016f04>] (unwind_backtrace) from [<c0013978>] (show_stack+0x20/0x24) [<c0013978>] (show_stack) from [<c0449794>] (dump_stack+0x24/0x28) [<c0449794>] (dump_stack) from [<c006f730>] (__lock_acquire+0x1e50/0x2004) [<c006f730>] (__lock_acquire) from [<c0070128>] (lock_acquire+0xe4/0x18c) [<c0070128>] (lock_acquire) from [<c027c6f8>] (ldsem_down_read_trylock+0x78/0x90) [<c027c6f8>] (ldsem_down_read_trylock) from [<c027a1cc>] (tty_ldisc_ref+0x24/0x58) [<c027a1cc>] (tty_ldisc_ref) from [<c0340760>] (usb_serial_handle_dcd_change+0x48/0xe8) [<c0340760>] (usb_serial_handle_dcd_change) from [<bf000484>] (pl2303_read_int_callback+0x210/0x220 [pl2303]) [<bf000484>] (pl2303_read_int_callback [pl2303]) from [<c031624c>] (__usb_hcd_giveback_urb+0x80/0x140) [<c031624c>] (__usb_hcd_giveback_urb) from [<c0316fc0>] (usb_giveback_urb_bh+0x98/0xd4) [<c0316fc0>] (usb_giveback_urb_bh) from [<c0042e44>] (tasklet_hi_action+0x9c/0x108) [<c0042e44>] (tasklet_hi_action) from [<c0042380>] (__do_softirq+0x148/0x42c) [<c0042380>] (__do_softirq) from [<c00429cc>] (irq_exit+0xd8/0x114) [<c00429cc>] (irq_exit) from [<c007ae58>] (__handle_domain_irq+0x84/0xdc) [<c007ae58>] (__handle_domain_irq) from [<c000879c>] (omap_intc_handle_irq+0xd8/0xe0) [<c000879c>] (omap_intc_handle_irq) from [<c0014544>] (__irq_svc+0x44/0x7c) Exception stack(0xdf4e7f08 to 0xdf4e7f50) 7f00: debc0b80 df4e7f5c 00000000 00000000 debc0b80 be8da96c 7f20: 00000000 00000128 c000fc84 df4e6000 00000000 df4e7f94 00000004 df4e7f50 7f40: c038ebc0 c038d74c 600f0013 ffffffff [<c0014544>] (__irq_svc) from [<c038d74c>] (___sys_sendmsg.part.29+0x0/0x2e0) [<c038d74c>] (___sys_sendmsg.part.29) from [<c038ec08>] (SyS_sendmsg+0x18/0x1c) [<c038ec08>] (SyS_sendmsg) from [<c000fa00>] (ret_fast_syscall+0x0/0x48) console [ttyUSB0] enabled Fixes: 36697529 ("tty: Replace ldisc locking with ldisc_sem") Signed-off-by:
-
Songjun Wu authored
commit 5fb694f9 upstream. When unloading the module 'g_hid.ko', the urb request will be dequeued and the completion routine will be excuted. If there is no urb packet, the urb request will not be added to the endpoint queue and the completion routine pointer in urb request is NULL. Accessing to this NULL function pointer will cause the Oops issue reported below. Add the code to check if the urb request is in the endpoint queue or not. If the urb request is not in the endpoint queue, a negative error code will be returned. Here is the Oops log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = dedf0000 [00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000 Internal error: Oops: 80000007 [#1] ARM Modules linked in: g_hid(-) usb_f_hid libcomposite CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2 Hardware name: Atmel SAMA5 (Device Tree) task: df6b1100 ti: dedf6000 task.ti: dedf6000 PC is at 0x0 LR is at usb_gadget_giveback_request+0xc/0x10 pc : [<00000000>] lr : [<c02ace88>] psr: 60000093 sp : dedf7eb0 ip : df572634 fp : 00000000 r10: 00000000 r9 : df52e210 r8 : 60000013 r7 : df6a9858 r6 : df52e210 r5 : df6a9858 r4 : df572600 r3 : 00000000 r2 : ffffff98 r1 : df572600 r0 : df6a9868 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3edf0059 DAC: 00000015 Process rmmod (pid: 923, stack limit = 0xdedf6230) Stack: (0xdedf7eb0 to 0xdedf8000) 7ea0: 00000000 c02adbbc df572580 deced608 7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c 7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00 7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0 [..] [<c02ace88>] (usb_gadget_giveback_request) from [<c02adbbc>] (request_complete+0x64/0x88) [<c02adbbc>] (request_complete) from [<c02aed3c>] (usba_ep_dequeue+0x70/0x128) [<c02aed3c>] (usba_ep_dequeue) from [<bf010c00>] (hidg_unbind+0x50/0x7c [usb_f_hid]) [<bf010c00>] (hidg_unbind [usb_f_hid]) from [<bf00159c>] (remove_config.isra.6+0x98/0x9c [libcomposite]) [<bf00159c>] (remove_config.isra.6 [libcomposite]) from [<bf0031d0>] (__composite_unbind+0x34/0x98 [libcomposite]) [<bf0031d0>] (__composite_unbind [libcomposite]) from [<c02acee0>] (usb_gadget_remove_driver+0x50/0x78) [<c02acee0>] (usb_gadget_remove_driver) from [<c02ad570>] (usb_gadget_unregister_driver+0x64/0x94) [<c02ad570>] (usb_gadget_unregister_driver) from [<bf0160c0>] (hidg_cleanup+0x10/0x34 [g_hid]) [<bf0160c0>] (hidg_cleanup [g_hid]) from [<c0056748>] (SyS_delete_module+0x118/0x19c) [<c0056748>] (SyS_delete_module) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30) Code: bad PC value Signed-off-by:
Songjun Wu <songjun.wu@atmel.com> [nicolas.ferre@atmel.com: reworked the commit message] Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 914a3f3b ("USB: add atmel_usba_udc driver") Signed-off-by:
-
Bo Shen authored
commit 6785a103 upstream. When receive data, the RXRDY in status register set by hardware after a new packet has been stored in the endpoint FIFO. When it is copied from FIFO, this bit is cleared which make the FIFO can be accessed again. In the receive_data() function, this bit RXRDY has been cleared. So, after the receive_data() function return, this bit should not be cleared again, or else it may cause the accessing FIFO corrupt, which will make the data loss. Fixes: 914a3f3b (USB: add atmel_usba_udc driver) Acked-by:
Bo Shen <voice.shen@atmel.com> Signed-off-by:
-
Bo Shen authored
commit f40afddd upstream. According to the datasheet, when transfer using DMA, the control setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN, while for OUT packet, need more two bits END_TR_EN and END_TR_IE to be configured. Fixes: 914a3f3b (USB: add atmel_usba_udc driver) Acked-by:
-
Mario Schuknecht authored
commit b44be246 upstream. Commit 3b74c73f switched over to memdup_user() in ep_write() function and removed kfree (kbuf). memdup_user() function allocates memory which is never freed. Fixes: 3b74c73f (usb: gadget: inode: switch over to memdup_user()) Signed-off-by:
Mario Schuknecht <mario.schuknecht@dresearch-fe.de> Signed-off-by:
-
Johan Hovold authored
commit b5122236 upstream. Fix null-pointer dereference during probe if the interface-status completion handler is called before the individual ports have been set up. Fixes: f79b2d0f ("USB: keyspan: fix NULL-pointer dereferences and memory leaks") Reported-by:
Richard <richjunk@pacbell.net> Tested-by:
-
Reinhard Speyerer authored
commit d80c0d14 upstream. As has been discussed in the thread starting with https://lkml.kernel.org/g/549748e9.d+SiJzqu50f1r4lSAL043YSc@arcor.de Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the option_send_setup() code to be used on the USB interface for the AT port to make unsolicited response codes work correctly. Move these devices from the qcserial driver where they have been added by commit 70a3615f ("usb: qcserial: add Sierra Wireless MC73xx") to the option driver and add a MC73xx-specific blacklist to ensure that 1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces 2. the option driver does not attach to the QMI/network interfaces Signed-off-by:
Reinhard Speyerer <rspmn@arcor.de> Signed-off-by:
-
David Peterson authored
commit 1ae78a48 upstream. Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks devices. Signed-off-by:
David Peterson <david.peterson@cel.com> Signed-off-by:
-
Preston Fick authored
commit 90441b4d upstream. Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in production and is not needed. Instead it has been changed to the official production PID (0x8857). Signed-off-by:
Preston Fick <pffick@gmail.com> Signed-off-by:
-
Amit Virdi authored
commit 39e60635 upstream. DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This means, the max TRBs that can be submitted for an EP is fixed to 32. Since the request queue for an EP is a linked list, any number of requests can be queued to it by the gadget layer. However, the dwc3 driver must not submit TRBs more than the pool it has created for. This limit wasn't respected when SG was used resulting in submitting more than the max TRBs, eventually leading to non-transfer of the TRBs submitted over the max limit. Root cause: When SG is used, there are two loops iterating to prepare TRBs: - Outer loop over the request_list - Inner loop over the SG list The code was missing break to get out of the outer loop. Fixes: eeb720fb (usb: dwc3: gadget: add support for SG lists) Signed-off-by:
Amit Virdi <amit.virdi@st.com> Signed-off-by:
-
Amit Virdi authored
commit ec512fb8 upstream. When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3 request (dwc3_request). So while preparing TRBs, the 'last' flag should be set only when it is the last TRB being prepared from the last dwc3_request entry. The current implementation uses list_is_last to check if the dwc3_request is the last entry from the request_list. However, list_is_last returns false for the last entry too. This is because, while preparing the first TRB from a request, the function dwc3_prepare_one_trb modifies the request's next and prev pointers while moving the URB to req_queued. Hence, list_is_last always returns false no matter what. The correct way is not to access the modified pointers of dwc3_request but to use list_empty macro instead. Fixes: e5ba5ec8 (usb: dwc3: gadget: fix scatter gather implementation) Signed-off-by:
-
Arseny Solokha authored
commit 56abcab8 upstream. Commit 8dccddbc ("OHCI: final fix for NVIDIA problems (I hope)") introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development board. The code path that was previously specific to NVIDIA controllers had then become taken for all chips. However, the M5237 installed on the board wedges solid when accessing its base+OHCI_FMINTERVAL register, making it impossible to boot any kernel newer than 3.1.8 on this particular and apparently other similar machines. Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237. The patch is suitable for the -next tree as well as all maintained kernels up to 3.2 inclusive. Signed-off-by:
Arseny Solokha <asolokha@kb.kras.ru> Acked-by:
-
Johan Hovold authored
commit 0915e6fe upstream. The gpio device attributes were never destroyed when the gpio was unexported (or on export failures). Use device_create_with_groups() to create the default device attributes of the gpio class device. Note that this also fixes the attribute-creation race with userspace for these attributes. Remove contingent attributes in export error path and on unexport. Fixes: d8f388d8 ("gpio: sysfs interface") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Johan Hovold authored
commit 121b6a79 upstream. The gpio-chip device attributes were never destroyed when the device was removed. Fix by using device_create_with_groups() to create the device attributes of the chip class device. Note that this also fixes the attribute-creation race with userspace. Fixes: d8f388d8 ("gpio: sysfs interface") Signed-off-by:
-
Johan Hovold authored
commit 6798acaa upstream. Move direct and indirect calls to gpiochip_remove_pin_ranges outside of spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range. Note that the pin ranges are already added outside of the lock. Fixes: 9ef0d6f7 ("gpiolib: call pin removal in chip removal function") Fixes: f23f1516 ("gpiolib: provide provision to register pin ranges") Signed-off-by:
-
Johan Hovold authored
commit 00acc3dc upstream. Fix memory leak and sleep-while-atomic in gpiochip_remove. The memory leak was introduced by afa82fab ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") that moved the release of acpi interrupt resources to gpiochip_irqchip_remove, but by then the resources are no longer accessible as the acpi_gpio_chip has already been freed by acpi_gpiochip_remove. Note that this also fixes a few potential sleep-while-atomics, which has been around since 14250520 ("gpio: add IRQ chip helpers in gpiolib") when the call to gpiochip_irqchip_remove while holding a spinlock was added (a couple of irq-domain paths can end up grabbing mutexes). Fixes: afa82fab ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") Fixes: 14250520 ("gpio: add IRQ chip helpers in gpiolib") Signed-off-by:
-
Johan Hovold authored
commit 5539b3c9 upstream. Memory allocated and references taken by of_gpiochip_add and acpi_gpiochip_add were never released on errors in gpiochip_add (e.g. failure to find free gpio range). Fixes: 391c970c ("of/gpio: add default of_xlate function if device has a node pointer") Fixes: 664e3e5a ("gpio / ACPI: register to ACPI events automatically") Signed-off-by:
-
Aaron Lu authored
commit e733a2fb upstream. The CrystalCove GPIO chip has can_sleep set so its demultiplexed irqs will have IRQ_NESTED_THREAD flag set, thus we should use the nested version handle_nested_irq in CrystalCove's irq handler instead of handle_generic_irq, or the following warning will be hit and the functionality is lost: [ 4089.639554] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.313 08/13/2014 [ 4089.639564] 00000002 00000000 c24fbdf4 c16e0257 c24fbe38 c24fbe28 c105390c c18ec480 [ 4089.639596] c24fbe54 00000048 c18f8e3b 00000295 c10a60fc 00000295 c10a60fc f4464540 [ 4089.639626] f446459c c278ad40 c24fbe40 c1053974 00000009 c24fbe38 c18ec480 c24fbe54 [ 4089.639656] Call Trace: [ 4089.639685] [<c16e0257>] dump_stack+0x41/0x52 [ 4089.639707] [<c105390c>] warn_slowpath_common+0x8c/0xc0 [ 4089.639727] [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30 [ 4089.639744] [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30 [ 4089.639763] [<c1053974>] warn_slowpath_fmt+0x34/0x40 [ 4089.639781] [<c10a60fc>] irq_nested_primary_handler+0x2c/0x30 [ 4089.639800] [<c10a5c56>] handle_irq_event_percpu+0x76/0x190 [ 4089.639818] [<c1461570>] ? regmap_format_10_14_write+0x30/0x30 [ 4089.639836] [<c1464f4c>] ? _regmap_bus_raw_write+0x4c/0x70 [ 4089.639854] [<c10a5da1>] handle_irq_event+0x31/0x50 [ 4089.639872] [<c10a83eb>] handle_simple_irq+0x4b/0x70 [ 4089.639889] [<c10a5384>] generic_handle_irq+0x24/0x40 [ 4089.639908] [<c1366d87>] crystalcove_gpio_irq_handler+0xa7/0xc0 [ 4089.639927] [<c10a85a7>] handle_nested_irq+0x77/0x190 [ 4089.639947] [<c1469801>] regmap_irq_thread+0x1b1/0x360 [ 4089.639966] [<c10a6ae8>] irq_thread_fn+0x18/0x30 [ 4089.639983] [<c10a6906>] irq_thread+0xf6/0x110 [ 4089.640001] [<c10a6ad0>] ? irq_finalize_oneshot.part.30+0x1b0/0x1b0 [ 4089.640019] [<c10a6b50>] ? irq_forced_thread_fn+0x50/0x50 [ 4089.640037] [<c10a6810>] ? irq_thread_check_affinity+0xc0/0xc0 [ 4089.640054] [<c106f389>] kthread+0xa9/0xc0 [ 4089.640074] [<c16e6401>] ret_from_kernel_thread+0x21/0x30 [ 4089.640091] [<c106f2e0>] ? kthread_create_on_node+0x110/0x110 [ 4089.640105] ---[ end trace dca7946ad31eba7d ]--- Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=90521Reported-and-tested-by:
Brian Loften <bloften80@gmail.com> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
Hans Holmberg authored
commit 7b8792bb upstream. of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases where the gpio chip is available and the GPIO translation fails. This causes drivers to be re-probed erroneusly, and hides the real problem(i.e. the GPIO number being out of range). Signed-off-by:
Hans Holmberg <hans.holmberg@intel.com> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
Johan Hovold authored
commit 41f632fe upstream. Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error path) which is also called when adding the gpio chip. This prevents adding the same pinctrl range twice. Fixes: 3f8c50c9 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support") Signed-off-by:
-
Jisheng Zhang authored
commit 5138d5c5 upstream. The gpio4 and gpio5 are in 0xf7fc0000 apb which is located in the SM domain. This patch moves gpio4 and gpio5 to the correct location. This patch also renames them as the following to match the names we internally used in marvell: gpio4 -> sm_gpio1 gpio5 -> sm_gpio0 porte -> portf portf -> porte This also matches what we did for BG2 and BG2CD's SM GPIO. Fixes: cedf57fc ("ARM: dts: berlin: add the BG2Q GPIO nodes") Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Tyler Baker authored
commit 41544f9f upstream. Call spin_lock_init() before the spinlocks are used, both in early init and probe functions preventing a lockdep splat. I have been observing lockdep complaining [1] during boot on my a80 optimus [2] when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat, and has been tested on a few other sunxi platforms without issue. [1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html [2] http://kernelci.org/boot/?a80-optimusSigned-off-by:
Tyler Baker <tyler.baker@linaro.org> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Hans de Goede authored
commit 3ca8c717 upstream. Just like all previous UAS capable Seagate disk enclosures, these need the US_FL_NO_ATA_1X to not crash when udev probes them. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit c6fa3945 upstream. Like the JMicron JMS567 enclosures with the JMS566 choke on report-opcodes, so avoid it. Tested-and-reported-by:
Takeo Nakayama <javhera@gmx.com> Signed-off-by:
-
Hans de Goede authored
commit e5797a3d upstream. This is yet another Seagate device which needs the US_FL_NO_ATA_1X quirk Reported-by:
Marcin Zajączkowski <mszpak@wp.pl> Signed-off-by:
-
Alexander Usyskin authored
commit b13a65ef upstream. H_RST bit in H_CSR register may be found lit before reset is started, for example if preceding reset flow hasn't completed. In that case asserting H_RST will be ignored, therefore we need to clean H_RST bit to start a successful reset sequence. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Trond Myklebust authored
commit 1fc0703a upstream. Currently, our trunking code will check for session trunking, but will fail to detect client id trunking. This is a problem, because it means that the client will fail to recognise that the two connections represent shared state, even if they do not permit a shared session. By removing the check for the server minor id, and only checking the major id, we will end up doing the right thing in both cases: we close down the new nfs_client and fall back to using the existing one. Fixes: 05f4c350 ("NFS: Discover NFSv4 server trunking when mounting") Cc: Chuck Lever <chuck.lever@oracle.com> Tested-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 7485058e upstream. Using just the filter for checking for trampolines or regs is not enough when updating the code against the records that represent all functions. Both the filter hash and the notrace hash need to be checked. To trigger this bug (using trace-cmd and perf): # perf probe -a do_fork # trace-cmd start -B foo -e probe # trace-cmd record -p function_graph -n do_fork sleep 1 The trace-cmd record at the end clears the filter before it disables function_graph tracing and then that causes the accounting of the ftrace function records to become incorrect and causes ftrace to bug. Link: http://lkml.kernel.org/r/20150114154329.358378039@goodmis.org [ still need to switch old_hash_ops to old_ops_hash ] Reviewed-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 8f86f837 upstream. As the set_ftrace_filter affects both the function tracer as well as the function graph tracer, the ops that represent each have a shared ftrace_ops_hash structure. This allows both to be updated when the filter files are updated. But if function graph is enabled and the global_ops (function tracing) ops is not, then it is possible that the filter could be changed without the update happening for the function graph ops. This will cause the changes to not take place and may even cause a ftrace_bug to occur as it could mess with the trampoline accounting. The solution is to check if the ops uses the shared global_ops filter and if the ops itself is not enabled, to check if there's another ops that is enabled and also shares the global_ops filter. In that case, the modification still needs to be executed. Link: http://lkml.kernel.org/r/20150114154329.055980438@goodmis.orgReviewed-by:
-
Steven Rostedt (Red Hat) authored
commit 237d28db upstream. If the function graph tracer traces a jprobe callback, the system will crash. This can easily be demonstrated by compiling the jprobe sample module that is in the kernel tree, loading it and running the function graph tracer. # modprobe jprobe_example.ko # echo function_graph > /sys/kernel/debug/tracing/current_tracer # ls The first two commands end up in a nice crash after the first fork. (do_fork has a jprobe attached to it, so "ls" just triggers that fork) The problem is caused by the jprobe_return() that all jprobe callbacks must end with. The way jprobes works is that the function a jprobe is attached to has a breakpoint placed at the start of it (or it uses ftrace if fentry is supported). The breakpoint handler (or ftrace callback) will copy the stack frame and change the ip address to return to the jprobe handler instead of the function. The jprobe handler must end with jprobe_return() which swaps the stack and does an int3 (breakpoint). This breakpoint handler will then put back the saved stack frame, simulate the instruction at the beginning of the function it added a breakpoint to, and then continue on. For function tracing to work, it hijakes the return address from the stack frame, and replaces it with a hook function that will trace the end of the call. This hook function will restore the return address of the function call. If the function tracer traces the jprobe handler, the hook function for that handler will not be called, and its saved return address will be used for the next function. This will result in a kernel crash. To solve this, pause function tracing before the jprobe handler is called and unpause it before it returns back to the function it probed. Some other updates: Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the code look a bit cleaner and easier to understand (various tries to fix this bug required this change). Note, if fentry is being used, jprobes will change the ip address before the function graph tracer runs and it will not be able to trace the function that the jprobe is probing. Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.orgAcked-by:
-
Simon Guinot authored
commit 0c86ac2c upstream. This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to this bug, a kernel oops can be observed at probe time on the LaCie 2Big and 5Big v2 boards: Unable to handle kernel NULL pointer dereference at virtual address 00000008 [...] [<c03f244c>] (netxbig_led_probe) from [<c02c8c6c>] (platform_drv_probe+0x4c/0x9c) [<c02c8c6c>] (platform_drv_probe) from [<c02c72d0>] (driver_probe_device+0x98/0x25c) [<c02c72d0>] (driver_probe_device) from [<c02c7520>] (__driver_attach+0x8c/0x90) [<c02c7520>] (__driver_attach) from [<c02c5c24>] (bus_for_each_dev+0x68/0x94) [<c02c5c24>] (bus_for_each_dev) from [<c02c6408>] (bus_add_driver+0x124/0x1dc) [<c02c6408>] (bus_add_driver) from [<c02c7ac0>] (driver_register+0x78/0xf8) [<c02c7ac0>] (driver_register) from [<c000888c>] (do_one_initcall+0x80/0x1cc) [<c000888c>] (do_one_initcall) from [<c0733618>] (kernel_init_freeable+0xe4/0x1b4) [<c0733618>] (kernel_init_freeable) from [<c058db9c>] (kernel_init+0xc/0xec) [<c058db9c>] (kernel_init) from [<c0009850>] (ret_from_fork+0x14/0x24) [...] This bug was introduced by commit 588a6a99 ("leds: netxbig: fix attribute-creation race"). Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Acked-by:
Bryan Wu <cooloney@gmail.com> Signed-off-by:
-
Mugunthan V N authored
commit 25906052 upstream. Since ALE table is a common resource for both the interfaces in Dual EMAC mode and while bringing up the second interface in cpsw_ndo_set_rx_mode() all the multicast entries added by the first interface is flushed out and only second interface multicast addresses are added. Fixing this by flushing multicast addresses based on dual EMAC port vlans which will not affect the other emac port multicast addresses. Fixes: d9ba8f9e (driver: net: ethernet: cpsw: dual emac interface implementation) Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Vasu Dev authored
commit 776d4e9f upstream. Adds FCoE config option I40E_FCOE, so that FCoE can be enabled as needed but otherwise have it disabled by default. This also eliminate multiple FCoE config checks, instead now just one config check for CONFIG_I40E_FCOE. The I40E FCoE was added with 3.17 kernel and therefore this patch shall be applied to stable 3.17 kernel also. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Tested-by:
Jim Young <jamesx.m.young@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Eyal Shapira authored
commit c93edc63 upstream. commit 5c904224 "iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it" broke Rx with 2 chains for diversity. This had an impact on throughput where we're using only a single stream (11a/b/g APs, single stream APs, static SMPS). Fixes: 5c904224 ("iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it") Signed-off-by:
Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Catalin Marinas authored
commit 0145058c upstream. This patch partially reverts commit 421520ba (only the arm64 part). There is no guarantee that the boot-loader places other images like dtb in a different page than initrd start/end, especially when the kernel is built with 64KB pages. When this happens, such pages must not be freed. The free_reserved_area() already takes care of rounding up "start" and rounding down "end" to avoid freeing partially used pages. Reported-by:
Peter Maydell <Peter.Maydell@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Tim Kryger authored
commit 3cbc6123 upstream. Host controllers lacking the required internal vmmc regulator may still follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to to drive CMD, DAT, SDCLK. This fixes a regression observed on some Qualcomm and Nvidia boards caused by 52221610 mmc: sdhci: Improve external VDD regulator support. Fixes: 52221610 (mmc: sdhci: Improve external VDD regulator support) Signed-off-by:
Tim Kryger <tim.kryger@gmail.com> Tested-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Anton Blanchard authored
commit bfe5fda8 upstream. Patch c49f6353 ("powernv: Add OPAL tracepoints") has a spurious store to the stack: ld r12,opal_tracepoint_refcount@toc(r2); \ std r12,32(r1); \ The store was originally used to save the current tracepoint status so the entry and the exit tracepoints were always balanced. In the end I just created a separate path when tracepoints are enabled. The offset on the stack used for this store is not valid for ABIv2 and it causes strange issues. I noticed it because OPAL console input was broken. Fixes: c49f6353 ("powernv: Add OPAL tracepoints") Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
