summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"Arnd Bergmann2016-03-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: David Vrabel <david.vrabel@citrix.com> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: sis: remove unused variableSudip Mukherjee2016-03-031-8/+2
| | | | | | | | The variables modeflag and resinfo were only assigned some value but were never used. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drivers/video: make fbdev/sunxvr2500.c explicitly non-modularPaul Gortmaker2016-03-031-32/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of this code is: config FB_XVR2500 bool "Sun XVR-2500 3DLABS Wildcat support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. We don't replace module.h with init.h since the file already has that. We also delete the MODULE_LICENSE tag etc. since all that information was (or is now) contained at the top of the file in the comments. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drivers/video: make fbdev/sunxvr1000.c explicitly non-modularPaul Gortmaker2016-03-031-35/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of this code is: config FB_XVR1000 bool "Sun XVR-1000 support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. We don't replace module.h with init.h since the file already has that. Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. We also delete the MODULE_LICENSE tag etc. since all that information was (or is now) contained at the top of the file in the comments. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drivers/video: make fbdev/sunxvr500.c explicitly non-modularPaul Gortmaker2016-03-031-35/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of this code is: config FB_XVR500 bool "Sun XVR-500 3DLABS Wildcat support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We don't replace module.h with init.h since the file already has that. We also delete the MODULE_LICENSE tag etc. since all that information was (or is now) contained at the top of the file in the comments. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: exynos: fix modular buildArnd Bergmann2016-02-293-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE, which can be configured as a loadable module, so we have to make the driver a tristate symbol as well, to avoid this error: drivers/built-in.o: In function `s6e8ax0_probe': :(.text+0x23a48): undefined reference to `devm_backlight_device_register' This also means we get another error from a missing export, which this fixes as well: ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined! The drivers are all written to be loadable modules already, except the Kconfig options for that are missing, which makes the patch really easy. Finally, the EXYNOS_VIDEO option is turned into tristate as well for good measure, as all framebuffer drivers should be configurable as modules, though this change is not strictly necessary. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: da8xx-fb: fix videomodes of lcd panelsSushaanth Srirangapathi2016-02-291-4/+3
| | | | | | | | | | | | | | Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but forgot to update known_lcd_panels[] which had sync values according to old logic. This breaks LCD at least on DA850 EVM. This patch fixes this issue and I have tested this for panel "Sharp_LK043T1DG01" using DA850 EVM board. Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: kill fb_rotateRasmus Villemoes2016-02-266-90/+0
| | | | | | | | | | | | The fb_rotate method in struct fb_ops is never actually invoked, and it's been that way in the entire history of git (in fact, the last occurrence of the string '->fb_rotate' vanished over 10 years ago, with b4d8aea6d6, and that merely tested whether the callback existed). So remove some dead code and make struct fb_obs a little smaller. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: bt431: Correct cursor format control macroMaciej W. Rozycki2016-02-261-1/+1
| | | | | | | | | | | | | | | | The Bt431 cursor generator supports simultaneous generation of a 64 x 64 and a cross hair cursor in which the cursor format control bit (bit D4) of the command register "specifies whether the contents of the cursor RAM are to be logically exclusive-ORed (logical zero) or ORed (logical one) with the cross hair cursor". Rename the relevant macro accordingly. References: [1] "Bt431 Monolithic CMOS 64 x 64 Pixel Cursor Generator", Brooktree Corporation, Document Number: L431001, Rev. J Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-ba-fb: Optimize Bt455 colormap addressingMaciej W. Rozycki2016-02-262-12/+32
| | | | | | | | | | | | | | | | Use the address autoincrement feature when accessing successive palette entries and also skip loading a palette address in overlay register assesses which do not use that address. Provide a red/green/blue register sequencer reset helper for use in overlay register assesses where the state of the sequencer is not known. References: [1] "Bt454 Bt455 170 MHz Monolithic CMOS 16 Color Palette RAMDAC", Brooktree Corporation, Document Number: L454001, Rev. I Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-ba-fb: Fix and rework Bt455 colormap handlingMaciej W. Rozycki2016-02-262-21/+22
| | | | | | | | | | | | | | | | | | | | The Bt455 is a greyscale RAMDAC, using the green color palette entries only while still providing registers for the red and blue components, all the three of which have to be loaded on palette updates. Chip documentation [1] mandates that the unused red and blue registers are written with 0. Therefore update code to follow this requirement and given that it makes the red and blue components unusable remove them from internal API calls altogether. References: [1] "Bt454 Bt455 170 MHz Monolithic CMOS 16 Color Palette RAMDAC", Brooktree Corporation, Document Number: L454001, Rev. I Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: bt455: Remove unneeded colormap helpers for cursor supportMaciej W. Rozycki2016-02-261-25/+0
| | | | | Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-aa-fb: Report video timingsMaciej W. Rozycki2016-02-261-0/+7
| | | | | | | | | | | | | | | | | | The board uses hardwired timings compatible with 72Hz DEC VR319-DA and VRM17-AA monitors, according to the board owner's manual[1]. These timings are accordingly taken from the VR319 manual[2]. References: [1] "The Monochrome Frame Buffer TURBOchannel Module", Digital Equipment Corporation, Order Number: EK-MFBOM-TC-001, December 1991 [2] "Installing and Using the VR319 Monochrome Monitor", Digital Equipment Corporation, Order Number: EK-VR319-IN-001, First Edition, January 1990, Table 6-1 "Video Timing--1280 x 1024 Resolution" Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-aa-fb: Enable building as a moduleMaciej W. Rozycki2016-02-261-2/+2
| | | | | | | With the current TURBOchannel API support is automagical. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-aa-fb: Adapt to current APIsMaciej W. Rozycki2016-02-262-421/+215
| | | | | | | | | | | | | | | | | | | | | | | Rework the driver to use the current frambuffer and TURBOchannel APIs, including proper resource management and using the new framework for hardware cursor support. NB two Bt431 cursor generators are included onboard, both responding at the same TURBOchannel bus addresses and with their host data buses wired to byte lanes #0 and #1 respectively of the 32-bit bus. Therefore both can be accessed simultaneously with 16-bit data transfers. Cursor outputs of the chip wired to lane #0 drive the respective overlay select inputs of the Bt455 RAMDAC, whereas cursor outputs of the chip wired to lane #1 drive the respective P3 pixel select inputs of the RAMDAC. So 5 (out of 17) Bt455 color registers are usable with this board: palette entries #0 and #1 for frame buffer pixel data driven while neither cursor generator is active, palette entries #8 and #9 for frame buffer pixel data driven while cursor generator #1 is active only and the overlay entry while cursor generator #0 is active. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: pmag-ba-fb: Fix the lower margin sizeMaciej W. Rozycki2016-02-261-1/+1
| | | | | | | | | | | | | | | | | According to the board specification[1] the width of the vertical sync front porch is 12 pixels or the same as the width of the horizontal sync front porch. This in turn means the size of the lower margin is 0, because the vertical sync starts as soon as the start of the horizontal sync terminates the last line. References: [1] "PMAG-BA TURBOchannel Color Frame Buffer Functional Specification", Revision 1.2, Workstation Systems Engineering, Digital Equipment Corporation, August 27, 1990, Table 3-5: "Video Timing" Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: sh_mobile_lcdc: Use ARCH_RENESASSimon Horman2016-02-261-1/+1
| | | | | | | | | | | | Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: n411: check return valueSudip Mukherjee2016-02-261-3/+9
| | | | | | | | We were not checking the return value of platform_device_add_data() which can fail. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: exynos: fix IS_ERR_VALUE usageAndrzej Hajda2016-02-161-3/+3
| | | | | | | | | | | | | IS_ERR_VALUE macro should be used only with unsigned long type. For signed types comparison 'ret < 0' should be used. The patch follows conclusion from discussion on LKML [1][2]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2120927 [2]: http://permalink.gmane.org/gmane.linux.kernel/2150581 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: Use bool instead int pointer for get_opt_bool() argumentDaniel Wagner2016-02-161-1/+1
| | | | | | | | | | | | | | As the function name already indicates that get_opt_bool() parses for a bool. It is not a surprise that compiler is complaining about it when -Werror=incompatible-pointer-types is used: drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’: drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types] if (get_opt_bool(this_opt, "accel", &accel)) Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: metronomefb: two harmless off by one bugsDan Carpenter2016-02-161-2/+4
| | | | | | | | | | | | | | | | | par->metromem_cmd->args[] is an array of 31 elements of size u16. Here we have initialized the first "i" elements and want to set the rest to zero. The issue here is that ARRAY_SIZE(par->metromem_cmd->args) is 31 and not 32 as in the original code. It means that we set ->csum to zero, but that is harmless because we immediately set it to the correct value on the next line. Still, the buffer overflow upsets static checkers so let's correct the math. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Linux 4.5-rc4v4.5-rc4Linus Torvalds2016-02-141-1/+1
|
* Merge tag 'char-misc-4.5-rc4' of ↵Linus Torvalds2016-02-143-1/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are 3 fixes for some reported issues. Two nvmem driver fixes, and one mei fix. All have been in linux-next just fine" * tag 'char-misc-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: nvmem: qfprom: Specify LE device endianness nvmem: core: return error for non word aligned access mei: validate request value in client notify request ioctl
| * nvmem: qfprom: Specify LE device endiannessStephen Boyd2016-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The qfprom is a little endian device, but so far we've been relying on the regmap mmio bus handling this for us without explicitly stating that fact. After commit 4a98da2164cf (regmap-mmio: Use native endianness for read/write, 2015-10-29), the regmap mmio bus will read/write with the __raw_*() IO accessors, instead of using the readl/writel() APIs that do proper byte swapping for little endian devices. So if we're running on a big endian processor and haven't specified the endianness explicitly in the regmap config or in DT, we're going to switch from doing little endian byte swapping to big endian accesses without byte swapping, leading to some confusing results. Specify the endianness explicitly so that the regmap core properly byte swaps the accesses for us. Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: Kevin Hilman <khilman@linaro.org> Cc: Tyler Baker <tyler.baker@linaro.org> Cc: Simon Arlott <simon@fire.lp0.eu> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * nvmem: core: return error for non word aligned accessSrinivas Kandagatla2016-02-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | nvmem providers have restrictions on register strides, so return error when users attempt to read/write buffers with sizes which are less than word size. Without this patch the userspace would continue to try as it does not get any error from the nvmem core, resulting in a hang or endless loop in userspace. Reported-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * mei: validate request value in client notify request ioctlAlexander Usyskin2016-02-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch address a possible security issue: The request field in client notify request ioctl comes from user space as u32 and is downcasted to u8 with out validation. Check request field to have approved values MEI_HBM_NOTIFICATION_STAR/STOP Cc: <stable@vger.kernel.org> #4.3+ Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge tag 'driver-core-4.5-rc4' of ↵Linus Torvalds2016-02-141-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fix from Greg KH: "Here is one driver core, well klist, fix for 4.5-rc4. It fixes a problem found in the scsi device list traversal that probably also could be triggered by other subsystems. The fix has been in linux-next for a while with no reported problems" * tag 'driver-core-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: klist: fix starting point removed bug in klist iterators
| * | klist: fix starting point removed bug in klist iteratorsJames Bottomley2016-02-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The starting node for a klist iteration is often passed in from somewhere way above the klist infrastructure, meaning there's no guarantee the node is still on the list. We've seen this in SCSI where we use bus_find_device() to iterate through a list of devices. In the face of heavy hotplug activity, the last device returned by bus_find_device() can be removed before the next call. This leads to Dec 3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50() Dec 3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core Dec 3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2 Dec 3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013 Dec 3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000 Dec 3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000 Dec 3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60 Dec 3 13:22:02 localhost kernel: Call Trace: Dec 3 13:22:02 localhost kernel: [<ffffffff81321eef>] dump_stack+0x44/0x55 Dec 3 13:22:02 localhost kernel: [<ffffffff8107ca52>] warn_slowpath_common+0x82/0xc0 Dec 3 13:22:02 localhost kernel: [<ffffffff814542b0>] ? proc_scsi_show+0x20/0x20 Dec 3 13:22:02 localhost kernel: [<ffffffff8107cb4a>] warn_slowpath_null+0x1a/0x20 Dec 3 13:22:02 localhost kernel: [<ffffffff8167225d>] klist_iter_init_node+0x3d/0x50 Dec 3 13:22:02 localhost kernel: [<ffffffff81421d41>] bus_find_device+0x51/0xb0 Dec 3 13:22:02 localhost kernel: [<ffffffff814545ad>] scsi_seq_next+0x2d/0x40 [...] And an eventual crash. It can actually occur in any hotplug system which has a device finder and a starting device. We can fix this globally by making sure the starting node for klist_iter_init_node() is actually a member of the list before using it (and by starting from the beginning if it isn't). Reported-by: Ewan D. Milne <emilne@redhat.com> Tested-by: Ewan D. Milne <emilne@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | Merge tag 'tty-4.5-rc4' of ↵Linus Torvalds2016-02-147-7/+79
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are a number of small tty and serial driver fixes for 4.5-rc4 that resolve some reported issues. One of them got reverted as it wasn't correct based on testing, and all have been in linux-next for a while" * tag 'tty-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "8250: uniphier: allow modular build with 8250 console" pty: make sure super_block is still valid in final /dev/tty close pty: fix possible use after free of tty->driver_data tty: Add support for PCIe WCH382 2S multi-IO card serial/omap: mark wait_for_xmitr as __maybe_unused serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485) 8250: uniphier: allow modular build with 8250 console tty: Drop krefs for interrupted tty lock
| * | | Revert "8250: uniphier: allow modular build with 8250 console"Greg Kroah-Hartman2016-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit d56edd7ed0ed46a8043ee3040ededbd190818ccf, it shouldn't have been applied, it was fixed properly with commit 71f50c6d9a2276f3ec85384bffe2aee1962f4669 ("of: drop symbols declared by _OF_DECLARE() from modules") Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | pty: make sure super_block is still valid in final /dev/tty closeHerton R. Krzesinski2016-02-073-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Considering current pty code and multiple devpts instances, it's possible to umount a devpts file system while a program still has /dev/tty opened pointing to a previosuly closed pty pair in that instance. In the case all ptmx and pts/N files are closed, umount can be done. If the program closes /dev/tty after umount is done, devpts_kill_index will use now an invalid super_block, which was already destroyed in the umount operation after running ->kill_sb. This is another "use after free" type of issue, but now related to the allocated super_block instance. To avoid the problem (warning at ida_remove and potential crashes) for this specific case, I added two functions in devpts which grabs additional references to the super_block, which pty code now uses so it makes sure the super block structure is still valid until pty shutdown is done. I also moved the additional inode references to the same functions, which also covered similar case with inode being freed before /dev/tty final close/shutdown. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Cc: stable@vger.kernel.org # 2.6.29+ Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | pty: fix possible use after free of tty->driver_dataHerton R. Krzesinski2016-02-071-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a bug for a corner case where we have the the last release from a pty master/slave coming from a previously opened /dev/tty file. When this happens, the tty->driver_data can be stale, due to all ptmx or pts/N files having already been closed before (and thus the inode related to these files, which tty->driver_data points to, being already freed/destroyed). The fix here is to keep a reference on the opened master ptmx inode. We maintain the inode referenced until the final pty_unix98_shutdown, and only pass this inode to devpts_kill_index. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Cc: <stable@vger.kernel.org> # 2.6.29+ Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | tty: Add support for PCIe WCH382 2S multi-IO cardJeremy McNicoll2016-02-071-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WCH382 2S board is a PCIe card with 2 DB9 COM ports detected as Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850]) Signed-off-by: Jeremy McNicoll <jmcnicol@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | serial/omap: mark wait_for_xmitr as __maybe_unusedArnd Bergmann2016-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wait_for_xmitr() function is only used if CONFIG_CONSOLE_POLL or CONFIG_SERIAL_OMAP_CONSOLE are set, but when both are disabled, the compiler warns about it being unused: drivers/tty/serial/omap-serial.c:1168:13: warning: 'wait_for_xmitr' defined but not used [-Wunused-func We could add more #ifdefs to work around it, but adding __maybe_unused seems nicer. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 2172076d2399 ("serial/omap-serial: Deinline wait_for_xmitr, save 165 bytes") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485)Peter Hurley2016-02-071-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The omap-serial driver emulates RS485 delays using software timers, but neglects to clamp the input values from the unprivileged ioctl(TIOCSRS485). Because the software implementation busy-waits, malicious userspace could stall the cpu for ~49 days. Clamp the input values to < 100ms. Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support") Cc: <stable@vger.kernel.org> # 3.12+ Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | 8250: uniphier: allow modular build with 8250 consoleArnd Bergmann2016-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recently added uniphier 8250 port driver supports early console probing, and it supports being built as a module, but the combination of the two fails to link: ERROR: "early_serial8250_setup" [drivers/tty/serial/8250/8250_uniphier.ko] undefined! Given that earlycon support in a loadable module makes no sense, making that code conditional on 'MODULE' is a correct solution. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b8d20e06eaad ("serial: 8250_uniphier: add earlycon support") Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | tty: Drop krefs for interrupted tty lockPeter Hurley2016-02-072-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the tty lock is interrupted on attempted re-open, 2 tty krefs are still held. Drop extra kref before returning failure from tty_lock_interruptible(), and drop lookup kref before returning failure from tty_open(). Fixes: 0bfd464d3fdd ("tty: Wait interruptibly for tty lock on reopen") Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | | Merge tag 'usb-4.5-rc4' of ↵Linus Torvalds2016-02-143-12/+19
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull PHY fixes from Greg KH: "Here are a couple of PHY driver fixes for 4.5-rc4. A few small phy issues. All have been in linux-next with no reported issues" * tag 'usb-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload phy: twl4030-usb: Relase usb phy on unload phy: core: fix wrong err handle for phy_power_on phy: Restrict phy-hi6220-usb to HiSilicon arm64
| * \ \ \ Merge tag 'phy-for-4.5-rc' of ↵Greg Kroah-Hartman2016-02-123-12/+19
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus Kishon writes: phy: for 4.5-rc *) Fix error handling code in phy core [phy_power_on()] *) phy-twl4030-usb fixes for unloading the module *) Restrict phy-hi6220-usb to HiSilicon arm64 Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | * | | | phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reloadTony Lindgren2016-02-101-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we reload phy-twl4030-usb, we get a warning about unbalanced pm_runtime_enable. Let's fix the issue and also fix idling of the device on unload before we attempt to shut it down. If we don't properly idle the PHY before shutting it down on removal, the twl4030 ends up consuming about 62mW of extra power compared to running idle with the module loaded. Cc: stable@vger.kernel.org Cc: Bin Liu <b-liu@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: NeilBrown <neil@brown.name> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | * | | | phy: twl4030-usb: Relase usb phy on unloadTony Lindgren2016-02-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise rmmod omap2430; rmmod phy-twl4030-usb; modprobe omap2430 will try to use a non-existing phy and oops: Unable to handle kernel paging request at virtual address b6f7c1f0 ... [<c048a284>] (devm_usb_get_phy_by_node) from [<bf0758ac>] (omap2430_musb_init+0x44/0x2b4 [omap2430]) [<bf0758ac>] (omap2430_musb_init [omap2430]) from [<bf055ec0>] (musb_init_controller+0x194/0x878 [musb_hdrc]) Cc: stable@vger.kernel.org Cc: Bin Liu <b-liu@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: NeilBrown <neil@brown.name> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | * | | | phy: core: fix wrong err handle for phy_power_onShawn Lin2016-02-101-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If phy_pm_runtime_get_sync failed but we already enable regulator, current code return directly without doing regulator_disable. This patch fix this problem and cleanup err handle of phy_power_on to be more readable. Fixes: 3be88125d85d ("phy: core: Support regulator ...") Cc: <stable@vger.kernel.org> # v3.18+ Cc: Roger Quadros <rogerq@ti.com> Cc: Axel Lin <axel.lin@ingics.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | * | | | phy: Restrict phy-hi6220-usb to HiSilicon arm64Geert Uytterhoeven2016-02-031-0/+1
| | | |_|/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HiSilicon Hi6220 USB PHY is available in HiSilicon Hi6220 SoCs only. Restrict it to HiSilicon arm64, unless compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* | | | | Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2016-02-145-26/+63
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Thomas Gleixner: "Another round of fixes for the perf tooling side: - Prevent a NULL pointer dereference in tracepoint error handling - Fix a thread handling bug in the intel_pt error handling code - Search both .eh_frame and .debug_frame sections as toolchains seem to have random choices of storing the CFI information - Fix the perf state interval output values, which got broken when fixing the overall output" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf stat: Fix interval output values perf probe: Search both .eh_frame and .debug_frame sections for probe location perf tools: Fix thread lifetime related segfaut in intel_pt perf tools: tracepoint_error() can receive e=NULL, robustify it
| * \ \ \ \ Merge tag 'perf-urgent-for-mingo-2' of ↵Ingo Molnar2016-02-041-0/+10
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fix from Arnaldo Carvalho de Melo: - Fix 'perf stat' interval output values (Jiri Olsa) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
| | * | | | | perf stat: Fix interval output valuesJiri Olsa2016-02-031-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We broke interval data displays with commit: 3f416f22d1e2 ("perf stat: Do not clean event's private stats") This commit removed stats cleaning, which is important for '-r' option to carry counters data over the whole run. But it's necessary to clean it for interval mode, otherwise the displayed value is avg of all previous values. Before: $ perf stat -e cycles -a -I 1000 record # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 107,823,524 cycles $ perf stat report # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 91,519,906 cycles Now: $ perf stat report # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 107,823,524 cycles Notice the second value being bigger (91,.. < 107,..). This could be easily verified by using perf script which displays raw stat data: $ perf script CPU THREAD VAL ENA RUN TIME EVENT 0 -1 23855779 1000209530 1000209530 1000240796 cycles 1 -1 33340397 1000224964 1000224964 1000240796 cycles 2 -1 15835415 1000226695 1000226695 1000240796 cycles 3 -1 2184696 1000228245 1000228245 1000240796 cycles 0 -1 97014312 2000514533 2000514533 2000512791 cycles 1 -1 46121497 2000543795 2000543795 2000512791 cycles 2 -1 32269530 2000543566 2000543566 2000512791 cycles 3 -1 7634472 2000544108 2000544108 2000512791 cycles The sum of the first 4 values is the first interval aggregated value: 23855779 + 33340397 + 15835415 + 2184696 = 75,216,287 The sum of the second 4 values minus first value is the second interval aggregated value: 97014312 + 46121497 + 32269530 + 7634472 - 75216287 = 107,823,524 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1454485436-20639-1-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| * | | | | | Merge tag 'perf-urgent-for-mingo' of ↵Ingo Molnar2016-02-044-26/+53
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: - tracepoint_error() can receive e=NULL, robustify it, fixes a problem noticed with a very specific combination: Machine with Intel PT (e.g. Broadwell), kernel with no perf_event_attr.context_switch feature (e.g. 4.2) and unreadable tracefs (for instance !root users), making the fallback from perf_event_attr.context_switch to the sched:sched_switch tracepoint to fail reading its info from tracefs, fix it. (Adrian Hunter) - Fix segfault in intel PT, by making it follow the 'struct thread' lifetime cycle checking expectations, noticed for instance, when processing perf.data files with Intel PT data using 'perf script' and when exiting 'perf report' (Adrian Hunter) - Fix CFI usage from .eh_frame and .debug_frame, which sometimes requires that we fallback from .eh_frame to .debug_frame in architectures such as PowerPC (Hemant Kumar) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
| | * | | | | perf probe: Search both .eh_frame and .debug_frame sections for probe locationHemant Kumar2016-02-022-26/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'perf probe' through debuginfo__find_probes() in util/probe-finder.c checks for the functions' frame descriptions in either .eh_frame section of an ELF or the .debug_frame. The check is based on whether either one of these sections is present. Depending on distro, toolchain defaults, architetcutre, build flags, etc., CFI might be found in either .eh_frame and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if present, may not be complete and may miss some descriptions. Therefore, to be sure, to find the CFI covering an address we will always have to investigate both if available. For e.g., in powerpc, this may happen: $ gcc -g bin.c -o bin $ objdump --dwarf ./bin <1><145>: Abbrev Number: 7 (DW_TAG_subprogram) <146> DW_AT_external : 1 <146> DW_AT_name : (indirect string, offset: 0x9e): main <14a> DW_AT_decl_file : 1 <14b> DW_AT_decl_line : 39 <14c> DW_AT_prototyped : 1 <14c> DW_AT_type : <0x57> <150> DW_AT_low_pc : 0x100007b8 If the .eh_frame and .debug_frame are checked for the same binary, we will find that, .eh_frame (although present) doesn't contain a description for "main" function. But, .debug_frame has a description: 000000d8 00000024 00000000 FDE cie=00000000 pc=100007b8..10000838 DW_CFA_advance_loc: 16 to 100007c8 DW_CFA_def_cfa_offset: 144 DW_CFA_offset_extended_sf: r65 at cfa+16 ... Due to this (since, perf checks whether .eh_frame is present and goes on searching for that address inside that frame), perf is unable to process the probes: # perf probe -x ./bin main Failed to get call frame on 0x100007b8 Error: Failed to add events. To avoid this issue, we need to check both the sections (.eh_frame and .debug_frame), which is done in this patch. Note that, we can always force everything into both .eh_frame and .debug_frame by: $ gcc bin.c -fasynchronous-unwind-tables -fno-dwarf2-cfi-asm -g -o bin Signed-off-by: Hemant Kumar <hemant@linux.vnet.ibm.com> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: Mark Wielaard <mjw@redhat.com> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1454426806-13974-1-git-send-email-hemant@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | | | perf tools: Fix thread lifetime related segfaut in intel_ptAdrian Hunter2016-02-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intel_pt_process_auxtrace_info() creates a pt->unknown_thread thread that eventually needs to be freed by the last thread__put() on it, when its refcount hits zero, which may happen in intel_pt_process_auxtrace_info() error handling path and triggers the following segfault, which would happen as well at intel_pt_free, when tools using this intel_pt codebase frees up resources: # perf record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls 0 a anaconda-ks.cfg bin perf.data perf.data.old perf-f23-bringup.todo [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.217 MB perf.data ] # # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field. intel_pt_synth_events: failed to synthesize 'instructions' event type Segmentation fault (core dumped) # The problem is: there's a union in 'struct thread' combines a list_head and a rb_node. The standard life cycle of a thread is: init rb_node in the constructor, insert it into machine->threads rbtree using rb_node, move it to machine->dead_threads using list_head, clean in the last thread__put: list_del_init(&thread->node). In the above command, it clean a thread before adding it into list, causes the above segfault. Since pt->unknown_thread will never live in an rbtree, initialize its list node so that when list_del_init() is done on it we don't segfault. After this patch: # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field. intel_pt_synth_events: failed to synthesize 'instructions' event type 0x248 [0x88]: failed to process type: 70 # Reported-by: Tong Zhang <ztong@vt.edu> Reported-by: Wang Nan <wangnan0@huawei.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: http://lkml.kernel.org/r/1454296865-19749-1-git-send-email-wangnan0@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | | | perf tools: tracepoint_error() can receive e=NULL, robustify itAdrian Hunter2016-02-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes segmentation fault using, for instance: (gdb) run record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls Starting program: /home/acme/bin/perf record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls Missing separate debuginfos, use: dnf debuginfo-install glibc-2.22-7.fc23.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0 x00000000004b9ea5 in tracepoint_error (e=0x0, err=13, sys=0x19b1370 "sched", name=0x19a5d00 "sched_switch") at util/parse-events.c:410 (gdb) bt #0 0x00000000004b9ea5 in tracepoint_error (e=0x0, err=13, sys=0x19b1370 "sched", name=0x19a5d00 "sched_switch") at util/parse-events.c:410 #1 0x00000000004b9fc5 in add_tracepoint (list=0x19a5d20, idx=0x7fffffffb8c0, sys_name=0x19b1370 "sched", evt_name=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:433 #2 0x00000000004ba334 in add_tracepoint_event (list=0x19a5d20, idx=0x7fffffffb8c0, sys_name=0x19b1370 "sched", evt_name=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:498 #3 0x00000000004bb699 in parse_events_add_tracepoint (list=0x19a5d20, idx=0x7fffffffb8c0, sys=0x19b1370 "sched", event=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:936 #4 0x00000000004f6eda in parse_events_parse (_data=0x7fffffffb8b0, scanner=0x19a49d0) at util/parse-events.y:391 #5 0x00000000004bc8e5 in parse_events__scanner (str=0x663ff2 "sched:sched_switch", data=0x7fffffffb8b0, start_token=258) at util/parse-events.c:1361 #6 0x00000000004bca57 in parse_events (evlist=0x19a5220, str=0x663ff2 "sched:sched_switch", err=0x0) at util/parse-events.c:1401 #7 0x0000000000518d5f in perf_evlist__can_select_event (evlist=0x19a3b90, str=0x663ff2 "sched:sched_switch") at util/record.c:253 #8 0x0000000000553c42 in intel_pt_track_switches (evlist=0x19a3b90) at arch/x86/util/intel-pt.c:364 #9 0x00000000005549d1 in intel_pt_recording_options (itr=0x19a2c40, evlist=0x19a3b90, opts=0x8edf68 <record+232>) at arch/x86/util/intel-pt.c:664 #10 0x000000000051e076 in auxtrace_record__options (itr=0x19a2c40, evlist=0x19a3b90, opts=0x8edf68 <record+232>) at util/auxtrace.c:539 #11 0x0000000000433368 in cmd_record (argc=1, argv=0x7fffffffde60, prefix=0x0) at builtin-record.c:1264 #12 0x000000000049bec2 in run_builtin (p=0x8fa2a8 <commands+168>, argc=5, argv=0x7fffffffde60) at perf.c:390 #13 0x000000000049c12a in handle_internal_command (argc=5, argv=0x7fffffffde60) at perf.c:451 #14 0x000000000049c278 in run_argv (argcp=0x7fffffffdcbc, argv=0x7fffffffdcb0) at perf.c:495 #15 0x000000000049c60a in main (argc=5, argv=0x7fffffffde60) at perf.c:618 (gdb) Intel PT attempts to find the sched:sched_switch tracepoint but that seg faults if tracefs is not readable, because the error reporting structure is null, as errors are not reported when automatically adding tracepoints. Fix by checking before using. Committer note: This doesn't take place in a kernel that supports perf_event_attr.context_switch, that is the default way that will be used for tracking context switches, only in older kernels, like 4.2, in a machine with Intel PT (e.g. Broadwell) for non-priviledged users. Further info from a similar patch by Wang: The error is in tracepoint_error: it assumes the 'e' parameter is valid. However, there are many situation a parse_event() can be called without parse_events_error. See result of $ grep 'parse_events(.*NULL)' ./tools/perf/ -r' Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Tong Zhang <ztong@vt.edu> Cc: Wang Nan <wangnan0@huawei.com> Cc: stable@vger.kernel.org # v4.4+ Fixes: 196581717d85 ("perf tools: Enhance parsing events tracepoint error output") Link: http://lkml.kernel.org/r/1453809921-24596-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 06:15:23 +0100