- 23 Mar, 2017 1 commit
-
-
Elena Reshetova authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
David Windsor <dwindsor@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 Mar, 2017 1 commit
-
-
Cyril Bur authored
pgprot_dmachoerent() is not defined on every architecture. Having COMPILE_TEST set for the driver causes it to be compiled on architectures which do not have pgprot_dmachoerent(): drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap': drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of function 'pgprot_dmacoherent' [-Werror=implicit-function-declaration] prot = pgprot_dmacoherent(prot); There are two possible solutions: 1. Remove COMPILE_TEST to ensure the driver is only compiled on ARM 2. Use pgprot_noncached() instead of pgprot_dmachoerent() The first option results in less compile testing of the LPC control driver which is undesirable. The second option uses a function that is declared on all architectures and therefore should always build. Currently there is no practical difference between pgprot_noncached() and pgprot_dmachoerent() for the aspeed chips that this driver is compatible with. The reason for pgprot_dmachoerent() was that there may be chips made at some point in the future that could include hardware that pgprot_dmachoerent() could optimise for. As none of this hardware has even been announced there isn't really a need for pgprot_dmachoerent(). Using pgprot_noncached() is completely correct and optimal for all existing hardware on which the LPC control driver will run. This commit also addresses that phys_addr_t should be printed using %pap rather than %x: In file included from include/linux/miscdevice.h:6:0, from drivers/misc/aspeed-lpc-ctrl.c:11: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe': drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'phys_addr_t {aka long long unsigned int}' [-Wformat=] dev_info(dev, "Loaded at 0x%08x (0x%08x)\n", Signed-off-by:Cyril Bur <cyrilbur@gmail.com> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 21 Mar, 2017 15 commits
-
-
Logan Gunthorpe authored
This driver did not set kobj.parent so it likely suffered from a potential use after free race if the user unregistered the device while it was in use. This was not so straightforward a conversion but I think this patch cleans up its probe's error path significantly. This patch adds device_initialize, which is required for cdev_device_add. Then it switches to put_device instead of kfree as recommended by device_initialize's documentation. This removes a lot from the error path which was already in __remove. A couple things needed to be re-ordered to be entirely correct, though. ida_remove is also moved out of __remove and into unregister to simplify things and follow the pattern other devices are using. This also drop an extra unnecessary get_device/put_device in the code. Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
-
Logan Gunthorpe authored
Mostly straightforward, but we had to remove the rtc_dev_add/del_device functions as they split up the cdev_add and the device_add. Doing this also revealed that there was likely another subtle bug: seeing cdev_add was done after device_register, the cdev probably was not ready before device_add when the uevent occurs. This would race with userspace, if it tried to use the device directly after the uevent. This is fixed just by using the new helper function. Another weird thing is this driver would, in some error cases, call cdev_add() without calling cdev_init. This patchset corrects this by avoiding calling cdev_add if the devt is not set. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Logan Gunthorpe authored
This driver did not originally set kobj.parent so it likely had potential a use after free bug which this patch fixes. We convert from device_register to device_initialize/cdev_device_add. While we are at it we use put_device instead of kfree (as recommended by the device_initialize documentation). We also remove an unnecessary extra get_device from the code. Signed-off-by:
-
Logan Gunthorpe authored
This is not as straightforward a conversion as the others in this series. These drivers did not originally make use of kobj.parent so they likely suffered from a use after free bug if someone unregistered the devices while they are being used. In order to make the conversions, switch from device_register to device_initialize / cdev_device_add. In build.c, this patch unwinds a complicated mess of extra get_device/put_devices and reference tracking by moving device_initialize early in the attach process. Then it always uses put_device and instead of using device_unregister and extra get_devices everywhere we just use cdev_device_del and one put_device once everything is completely done. This simplifies things dramatically and makes it easier to reason about. In vmt.c, the patch pushes device initialization up to the beginning of the device creation and then that function only needs to use put_device in the error path which simplifies things a good deal. Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. In doing so we have to remove a guard statement from cdev_del, but this doesn't appear to be required in any way. Signed-off-by:
-
Logan Gunthorpe authored
This replaces the suspect looking cdev.kobj.parent lines with the equivalent cdev_set_parent function. This is a straightforward change that's largely cosmetic but it does push the kobj.parent ownership into char_dev.c where it belongs. Signed-off-by:
-
Jason Gunthorpe authored
The use after free is not triggerable here because the cdev holds the module lock and the only device_unregister is only triggered by module unload, however make the change for consistency. To make this work the cdev_del needs to move out of the struct device release function. This cleans up the error path significantly and thus also fixes a minor bug where the devnum would not be released if cdev_add failed. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. At the same time we cleanup the error path through device_probe function: we use put_device instead of kfree directly as recommended by the device_initialize documentation. Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper in evdev, joydev and mousedev. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Logan Gunthorpe authored
Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Dan Williams authored
If device_add() fails, cleanup the cdev. Otherwise, we leak a kobj_map() with a stale device number. As Jason points out, there is a small possibility that userspace has opened and mapped the device in the time between cdev_add() and the device_add() failure. We need a new kill_dax_dev() helper to invalidate any established mappings. Fixes: ba09c01d ("dax: convert to the cdev api") Cc: <stable@vger.kernel.org> Reported-by:
-
Logan Gunthorpe authored
Credit for this patch goes is shared with Dan Williams [1]. I've taken things one step further to make the helper function more useful and clean up calling code. There's a common pattern in the kernel whereby a struct cdev is placed in a structure along side a struct device which manages the life-cycle of both. In the naive approach, the reference counting is broken and the struct device can free everything before the chardev code is entirely released. Many developers have solved this problem by linking the internal kobjs in this fashion: cdev.kobj.parent = &parent_dev.kobj; The cdev code explicitly gets and puts a reference to it's kobj parent. So this seems like it was intended to be used this way. Dmitrty Torokhov first put this in place in 2012 with this commit: 2f0157f1 char_dev: pin parent kobject and the first instance of the fix was then done in the input subsystem in the following commit: 4a215aad Input: fix use-after-free introduced with dynamic minor changes Subsequently over the years, however, this issue seems to have tripped up multiple developers independently. For example, see these commits: 0d5b7dae iio: Prevent race between IIO chardev opening and IIO device (by Lars-Peter Clausen in 2013) ba0ef854 tpm: Fix initialization of the cdev (by Jason Gunthorpe in 2015) 5b28dde5 [media] media: fix use-after-free in cdev_put() when app exits after driver unbind (by Shauh Khan in 2016) This technique is similarly done in at least 15 places within the kernel and probably should have been done so in another, at least, 5 places. The kobj line also looks very suspect in that one would not expect drivers to have to mess with kobject internals in this way. Even highly experienced kernel developers can be surprised by this code, as seen in [2]. To help alleviate this situation, and hopefully prevent future wasted effort on this problem, this patch introduces a helper function to register a char device along with its parent struct device. This creates a more regular API for tying a char device to its parent without the developer having to set members in the underlying kobject. This patch introduce cdev_device_add and cdev_device_del which replaces a common pattern including setting the kobj parent, calling cdev_add and then calling device_add. It also introduces cdev_set_parent for the few cases that set the kobject parent without using device_add. [1] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370Signed-off-by:
-
- 17 Mar, 2017 23 commits
-
-
Geert Uytterhoeven authored
The Hitachi HD44780 Character LCD Controller is commonly used on character LCDs that can display one or more lines of text. This driver supports character LCDs connected to GPIOs, using either a 4-bit or 8-bit data bus, and provides access through the charlcd core and /dev/lcd. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
Add DT bindings for an Hitachi HD44780 Character LCD Controller where its M6800 bus interface is connected to GPIOs. Memory-mapped configurations are not yet supported. Signed-off-by:
-
Geert Uytterhoeven authored
On displays with more than two lines, the additional lines are stored in the buffers used for the first two lines, but beyond the visible parts. Adjust the DDRAM address calculation to cater for this. When clearing the display, avoid writing more spaces than the actual size of the physical buffer. Signed-off-by:
-
Geert Uytterhoeven authored
In 4-bit mode, 8-bit commands and data are written using two raw writes to the data interface: high nibble first, low nibble last. This must be handled by the low-level driver. However, as we don't know in which mode (4-bit or 8-bit) nor 4-bit phase the LCD was left, initialization must always be handled using raw writes, and needs to configure the LCD for 8-bit mode first. Signed-off-by:
-
Geert Uytterhoeven authored
Extract the character LCD core from the Parallel port LCD/Keypad Panel driver in the misc subsystem, and convert it into a subdriver in the auxdisplay subsystem. This allows the character LCD core to be used by other drivers later. Compilation is controlled by its own Kconfig symbol CHARLCD, which is to be selected by its users, but can be enabled manually for compile-testing. All functions changed their prefix from "lcd_" to "charlcd_", and gained a "struct charlcd *" parameter to operate on a specific instance. While the driver API thus is ready to support multiple instances, the current limitation of a single display (/dev/lcd has a single misc minor assigned) is retained. No functional changes intended. Signed-off-by:
-
Joe Perches authored
To enable eventual removal of pr_warning This makes pr_warn use consistent for drivers/char Prior to this patch, there were 1 use of pr_warning and 40 uses of pr_warn in drivers/char Signed-off-by:
Joe Perches <joe@perches.com> Reviewed-by:
Amit Shah <amit@kernel.org> Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
-
Mariusz Bialonczyk authored
Detailed information about support and provided sysfs files in my next commit which creates a documentation file: Documentation/w1/slaves/w1_ds2438 Signed-off-by:
-
Mariusz Bialonczyk authored
Signed-off-by:
-
Matt Ranostay authored
Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes so this patchset works around the issue and corrects the data returned in pps_fdata_compat. Acked-by:
Rodolfo Giometti <giometti@enneenne.com> Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Matt Ranostay authored
ioctl definitions use the pointer size of the architecture which is fine when userspace and kernel are the same bitsize. This patchset workarounds an issue with mixed bitsize kernel + userspace by rewriting the cmd to the kernelspace architecture pointer size. Acked-by:
-
Martyn Welch authored
Update VME documentation given that kerneldoc comments are now provided. Add "VME API" section to VME RST to pull in kerneldoc comments. Signed-off-by:
Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by:
-
Martyn Welch authored
Add kernel-doc comments to the VME driver API and structures. This documentation will be integrated into the RST documentation in a later patch. Signed-off-by:
-
Matthias Kaehlcke authored
The value passed by the two callers of the function is unsigned anyway. Making the parameter unsigned fixes the following warning when building with clang: drivers/char/hpet.c:588:7: error: overflow converting case value to switch condition type (2149083139 to 18446744071563667459) [-Werror,-Wswitch] case HPET_INFO: ^ include/uapi/linux/hpet.h:18:19: note: expanded from macro 'HPET_INFO' ^ include/uapi/asm-generic/ioctl.h:77:28: note: expanded from macro '_IOR' ^ include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC' (((dir) << _IOC_DIRSHIFT) | \ Signed-off-by:Matthias Kaehlcke <mka@chromium.org> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Cyril Bur authored
In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash. The Aspeed BMC family which is what is used on OpenPOWER machines and a number of x86 as well is typically connected to the host via an LPC (Low Pin Count) bus (among others). The LPC bus is an ISA bus on steroids. It's generally used by the BMC chip to provide the host with access to the system flash (via MEM/FW cycles) that contains the BIOS or other host firmware along with a number of SuperIO-style IOs (via IO space) such as UARTs, IPMI controllers. On the BMC chip side, this is all configured via a bunch of registers whose content is related to a given policy of what devices are exposed at a per system level, which is system/vendor specific, so we don't want to bolt that into the BMC kernel. This started with a need to provide something nicer than /dev/mem for user space to configure these things. One important aspect of the configuration is how the MEM/FW space is exposed to the host (ie, the x86 or POWER). Some registers in that bridge can define a window remapping all or portion of the LPC MEM/FW space to a portion of the BMC internal bus, with no specific limits imposed in HW. I think it makes sense to ensure that this window is configured by a kernel driver that can apply some serious sanity checks on what it is configured to map. In practice, user space wants to control this by flipping the mapping between essentially two types of portions of the BMC address space: - The flash space. This is a region of the BMC MMIO space that more/less directly maps the system flash (at least for reads, writes are somewhat more complicated). - One (or more) reserved area(s) of the BMC physical memory. The latter is needed for a number of things, such as avoiding letting the host manipulate the innards of the BMC flash controller via some evil backdoor, we want to do flash updates by routing the window to a portion of memory (under control of a mailbox protocol via some separate set of registers) which the host can use to write new data in bulk and then request the BMC to flash it. There are other uses, such as allowing the host to boot from an in-memory flash image rather than the one in flash (very handy for continuous integration and test, the BMC can just download new images). It is important to note that due to the way the Aspeed chip lets the kernel configure the mapping between host LPC addresses and BMC ram addresses the offset within the window must be a multiple of size. Not doing so will fragment the accessible space rather than simply moving 'zero' upwards. This is caused by the nature of HICR8 being a mask and the way host LPC addresses are translated. Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Dmitry Torokhov authored
Instead of creating attributes one by one, define attribute_group array and attach it to bus->dev_groups, so that all needed attributes are created automatically when a new device is registered on the bus. Also switch to using standard DEVICE_ATTR_RO() macros. Signed-off-by:
-
Ming Lei authored
This email of 'ming.lei@canonical.com' isn't valid any more, please remove the entry. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
Instead of creating switch-specific attributes by hand, implement is_visible() method of attribute group and hide them when dealing with non-switch devices. This will ensure that all attributes are created together, before userspace gets notified of new device. Also, remove rio-sysfs.c from list of files that are scanned when compiling RapiodIO documentations as it no longer has any structured comments, and leaving it in leads to warning when building docs. Signed-off-by:
-
Rob Herring authored
As AOSP master is now starting to require a hwbinder device, add it to the the default Kconfig. Having the hwbinder device when not needed shouldn't hurt anything either. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Martijn Coenen <maco@google.com> Cc: Arve Hjønnevåg <arve@android.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Serban Constantinescu <serban.constantinescu@arm.com> Cc: Dmitry Shmidt <dimitrysh@google.com> Cc: Rom Lemarchand <romlem@google.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
K. Y. Srinivasan authored
Don't enable auto-eoi if the hypervisor recommends otherwise. This will enable vAPIC functionality if available. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
Fix a typo in the macro. Signed-off-by:
-
Stephen Hemminger authored
Allow driver to get debug information about state of the ring. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
