linux

mirror of https://github.com/raspberrypi/linux.git synced 2025-12-06 18:09:56 +00:00

Author	SHA1	Message	Date
Sasha Levin	51af817611	Linux 3.18.14 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-20 11:04:50 -04:00
K. Y. Srinivasan	199637437a	Drivers: hv: vmbus: Don't wait after requesting offers [ Upstream commit `73cffdb65e` ] Don't wait after sending request for offers to the host. This wait is unnecessary and simply adds 5 seconds to the boot time. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:43 -04:00
Thomas Hebb	0aea21ec8f	hfsplus: don't store special "osx" xattr prefix on-disk [ Upstream commit `db579e76f0` ] On Mac OS X, HFS+ extended attributes are not namespaced. Since we want to be compatible with OS X filesystems and yet still support the Linux namespacing system, the hfsplus driver implements a special "osx" namespace that is reported for any attribute that is not namespaced on-disk. However, the current code for getting and setting these unprefixed attributes is broken. hfsplus_osx_setattr() and hfsplus_osx_getattr() are passed names that have already had their "osx." prefixes stripped by the generic functions. The functions first, quite correctly, check those names to make sure that they aren't prefixed with a known namespace, which would allow namespace access restrictions to be bypassed. However, the functions then prepend "osx." to the name they're given before passing it on to hfsplus_getattr() and hfsplus_setattr(). Not only does this cause the "osx." prefix to be stored on-disk, defeating its purpose, it also breaks the check for the special "com.apple.FinderInfo" attribute, which is reported for all files, and as a consequence makes some userspace applications (e.g. GNU patch) fail even when extended attributes are not otherwise in use. There are five commits which have touched this particular code: `127e5f5ae5` ("hfsplus: rework functionality of getting, setting and deleting of extended attributes") `b168fff721` ("hfsplus: use xattr handlers for removexattr") `bf29e886b2` ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes") fcacbd95e121 ("fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()") ec1bbd346f18 ("fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()") The first commit creates the functions to begin with. The namespace is prepended by the original code, which I believe was correct at the time, since hfsplus_?etattr() stripped the prefix if found. The second commit removes this behavior from hfsplus_?etattr() and appears to have been intended to also remove the prefixing from hfsplus_osx_?etattr(). However, what it actually does is remove a necessary strncpy() call completely, breaking the osx namespace entirely. The third commit re-adds the strncpy() call as it was originally, but doesn't mention it in its commit message. The final two commits refactor the code and don't affect its functionality. This commit does what b168fff attempted to do (prevent the prefix from being added), but does it properly, instead of passing in an empty buffer (which is what b168fff actually did). Fixes: `b168fff721` ("hfsplus: use xattr handlers for removexattr") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Sergei Antonov <saproj@gmail.com> Cc: Anton Altaparmakov <anton@tuxera.com> Cc: Fabian Frederick <fabf@skynet.be> Cc: Christian Kujau <lists@nerdbynature.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Viacheslav Dubeyko <slava@dubeyko.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:43 -04:00
Christian König	be5288ba78	drm/radeon: check new address before removing old one [ Upstream commit `c29c0876ec` ] Otherwise the change isn't atomic. Signed-off-by: Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:42 -04:00
Alex Deucher	2fb8260159	drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5 [ Upstream commit `cd17e02ff4` ] Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:42 -04:00
Alex Deucher	572a8eae2a	drm/radeon: adjust pll when audio is not enabled [ Upstream commit `7fe04d6fa8` ] Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:42 -04:00
Christoph Hellwig	742b16a269	3w-sas: fix command completion race [ Upstream commit `579d69bc1f` ] The 3w-sas driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Torsten Luettgert <ml-lkml@enda.eu> Tested-by: Bernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de> Cc: stable@vger.kernel.org Acked-by: Adam Radford <aradford@gmail.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:42 -04:00
Christoph Hellwig	d722b89103	3w-9xxx: fix command completion race [ Upstream commit `118c855b56` ] The 3w-9xxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Acked-by: Adam Radford <aradford@gmail.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:41 -04:00
Christoph Hellwig	c0abe5a7b6	3w-xxxx: fix command completion race [ Upstream commit `9cd9554615` ] The 3w-xxxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Acked-by: Adam Radford <aradford@gmail.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:41 -04:00
Davide Italiano	e5975e422e	ext4: move check under lock scope to close a race. [ Upstream commit `280227a75b` ] fallocate() checks that the file is extent-based and returns EOPNOTSUPP in case is not. Other tasks can convert from and to indirect and extent so it's safe to check only after grabbing the inode mutex. Signed-off-by: Davide Italiano <dccitaliano@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:41 -04:00
Lukas Czerner	826e9b94ce	ext4: fix data corruption caused by unwritten and delayed extents [ Upstream commit `d2dc317d56` ] Currently it is possible to lose whole file system block worth of data when we hit the specific interaction with unwritten and delayed extents in status extent tree. The problem is that when we insert delayed extent into extent status tree the only way to get rid of it is when we write out delayed buffer. However there is a limitation in the extent status tree implementation so that when inserting unwritten extent should there be even a single delayed block the whole unwritten extent would be marked as delayed. At this point, there is no way to get rid of the delayed extents, because there are no delayed buffers to write out. So when a we write into said unwritten extent we will convert it to written, but it still remains delayed. When we try to write into that block later ext4_da_map_blocks() will set the buffer new and delayed and map it to invalid block which causes the rest of the block to be zeroed loosing already written data. For now we can fix this by simply not allowing to set delayed status on written extent in the extent status tree. Also add WARN_ON() to make sure that we notice if this happens in the future. This problem can be easily reproduced by running the following xfs_io. xfs_io -f -c "pwrite -S 0xaa 4096 2048" \ -c "falloc 0 131072" \ -c "pwrite -S 0xbb 65536 2048" \ -c "fsync" /mnt/test/fff echo 3 > /proc/sys/vm/drop_caches xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff This can be theoretically also reproduced by at random by running fsx, but it's not very reliable, though on machines with bigger page size (like ppc) this can be seen more often (especially xfstest generic/127) Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:41 -04:00
Hans de Goede	d3dc2e86f7	uas: Set max_sectors_240 quirk for ASM1053 devices [ Upstream commit `8e779c6c4a` ] Testing has shown that ASM1053 devices do not work properly with transfers larger than 240 sectors, so set max_sectors to 240 on these. Cc: stable@vger.kernel.org # 3.16 Reported-by: Steve Bangert <sbangert@frontier.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Steve Bangert <sbangert@frontier.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:40 -04:00
Hans de Goede	f6283d7d0c	uas: Add US_FL_MAX_SECTORS_240 flag [ Upstream commit `ee136af4a0` ] The usb-storage driver sets max_sectors = 240 in its scsi-host template, for uas we do not want to do that for all devices, but testing has shown that some devices need it. This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and implements support for it in uas.c, while at it it also adds support for US_FL_MAX_SECTORS_64 to uas.c. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:40 -04:00
Hans de Goede	e5e3b31493	uas: Allow uas_use_uas_driver to return usb-storage flags [ Upstream commit `a5011d44f0` ] uas_use_uas_driver may set some US_FL_foo flags during detection, currently these are stored in a local variable and then throw away, but these may be of interest to the caller, so add an extra parameter to (optionally) return the detected flags, and use this in the uas driver. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:40 -04:00
Ilya Dryomov	1a5be433a3	rbd: end I/O the entire obj_request on error [ Upstream commit `082a75dad8` ] When we end I/O struct request with error, we need to pass obj_request->length as @nr_bytes so that the entire obj_request worth of bytes is completed. Otherwise block layer ends up confused and we trip on rbd_assert(more ^ (which == img_request->obj_request_count)); in rbd_img_obj_callback() due to more being true no matter what. We already do it in most cases but we are missing some, in particular those where we don't even get a chance to submit any obj_requests, due to an early -ENOMEM for example. A number of obj_request->xferred assignments seem to be redundant but I haven't touched any of obj_request->xferred stuff to keep this small and isolated. Cc: Alex Elder <elder@linaro.org> Cc: stable@vger.kernel.org # 3.10+ Reported-by: Shawn Edwards <lesser.evil@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:40 -04:00
Ludovic Desroches	5286f7e311	tty/serial: at91: maxburst was missing for dma transfers [ Upstream commit `a8d4e01637` ] Maxburst was not set when doing the dma slave configuration. This value is checked by the recently introduced xdmac. It causes an error when doing the slave configuration and so prevents from using dma. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: <stable@vger.kernel.org> # 3.12 and later Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:40 -04:00
Chris Bainbridge	ed92377049	ACPI / SBS: Enable battery manager when present [ Upstream commit `61f8ff6939` ] Commit `9faf6136ff` (ACPI / SBS: Disable smart battery manager on Apple) introduced a regression disabling the SBS battery manager. The battery manager should be marked as present when acpi_manager_get_info() returns 0. Fixes: `9faf6136ff` (ACPI / SBS: Disable smart battery manager on Apple) Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Cc: 3.18+ <stable@vger.kernel.org> # 3.18+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:39 -04:00
Omar Sandoval	9f57ba579e	btrfs: unlock i_mutex after attempting to delete subvolume during send [ Upstream commit `909e26dce3` ] Whenever the check for a send in progress introduced in commit `521e0546c9` (btrfs: protect snapshots from deleting during send) is hit, we return without unlocking inode->i_mutex. This is easy to see with lockdep enabled: [ +0.000059] ================================================ [ +0.000028] [ BUG: lock held when returning to user space! ] [ +0.000029] 4.0.0-rc5-00096-g3c435c1 #93 Not tainted [ +0.000026] ------------------------------------------------ [ +0.000029] btrfs/211 is leaving the kernel with locks still held! [ +0.000029] 1 lock held by btrfs/211: [ +0.000023] #0: (&type->i_mutex_dir_key){+.+.+.}, at: [<ffffffff8135b8df>] btrfs_ioctl_snap_destroy+0x2df/0x7a0 Make sure we unlock it in the error path. Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:39 -04:00
Bard Liao	36bcc94a44	ASoC: rt5677: fixed wrong DMIC ref clock [ Upstream commit `60a8d62b84` ] DMIC clock source is not from codec system clock directly. it is generated from the division of system clock. And it should be 256 * sample rate of AIF1. Signed-off-by: Bard Liao <bardliao@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:39 -04:00
Charles Keepax	5d767349a1	ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE [ Upstream commit `a2d97723cb` ] Correct small copy and paste error where autodisable was not being enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:39 -04:00
Wei Yongjun	9714fe21c6	ASoC: samsung: s3c24xx-i2s: Fix return value check in s3c24xx_iis_dev_probe() [ Upstream commit `c479163a1b` ] In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:38 -04:00
Li Jun	69e961c219	usb: chipidea: otg: remove mutex unlock and lock while stop and start role [ Upstream commit `a5a356cee8` ] Wrongly release mutex lock during otg_statemachine may result in re-enter otg_statemachine, which is not allowed, we should do next state transtition after previous one completed. Fixes: `826cfe751f` ("usb: chipidea: add OTG fsm operation functions implementation") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Li Jun <jun.li@freescale.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:38 -04:00
Marek Szyprowski	a142e9641d	arm64: dma-mapping: always clear allocated buffers [ Upstream commit `6829e274a6` ] Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha, ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures. It turned out that some drivers rely on this 'feature'. Allocated buffer might be also exposed to userspace with dma_mmap() call, so clearing it is desired from security point of view to avoid exposing random memory to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64 architecture with other implementations by unconditionally zeroing allocated buffer. Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:38 -04:00
Michal Simek	57c6da407a	serial: xilinx: Use platform_get_irq to get irq description structure [ Upstream commit `5c90c07b98` ] For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type = "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because driver probe fails). Then a driver is called but irq mapping is not created that's why driver is failing again in again on request_irq(). Based on this use platform_get_irq() instead of platform_get_resource() which is doing irq_desc allocation and driver itself can request IRQ. Fix both xilinx serial drivers in the tree. Signed-off-by: Michal Simek <michal.simek@xilinx.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:38 -04:00
Michal Simek	4957c4d378	serial: of-serial: Remove device_type = "serial" registration [ Upstream commit `6befa9d883` ] Do not probe all serial drivers by of_serial.c which are using device_type = "serial"; property. Only drivers which have valid compatible strings listed in the driver should be probed. When PORT_UNKNOWN is setup probe will fail anyway. Arnd quotation about driver historical background: "when I wrote that driver initially, the idea was that it would get used as a stub to hook up all other serial drivers but after that, the common code learned to create platform devices from DT" This patch fix the problem with on the system with xilinx_uartps and 16550a where of_serial failed to register for xilinx_uartps and because of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking for irq with request_irq() EINVAL is returned. Signed-off-by: Michal Simek <michal.simek@xilinx.com> CC: <stable@vger.kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:37 -04:00
Quentin Casasnovas	da797a4ce5	cdc-acm: prevent infinite loop when parsing CDC headers. [ Upstream commit `0d3bba0287` ] Phil and I found out a problem with commit: `7e860a6e7a` ("cdc-acm: add sanity checks") It added some sanity checks to ignore potential garbage in CDC headers but also introduced a potential infinite loop. This can happen at the first loop iteration (elength = 0 in that case) if the description isn't a DT_CS_INTERFACE or later if 'buffer[0]' is zero. It should also be noted that the wrong length was being added to 'buffer' in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was assigned after that check in the loop. A specially crafted USB device could be used to trigger this infinite loop. Fixes: `7e860a6e7a` ("cdc-acm: add sanity checks") Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> CC: Oliver Neukum <oneukum@suse.de> CC: Adam Lee <adam8157@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:37 -04:00
Oliver Neukum	57f086bcbc	cdc-acm: add sanity checks [ Upstream commit `7e860a6e7a` ] Check the special CDC headers for a plausible minimum length. Another big operating systems ignores such garbage. Signed-off-by: Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Reviewed-by: Adam Lee <adam8157@gmail.com> Tested-by: Adam Lee <adam8157@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:37 -04:00
Takashi Iwai	a1f3efd406	ALSA: hda - Add mute-LED mode control to Thinkpad [ Upstream commit `7290006d8c` ] This patch adds the missing flag to enable "Mute-LED Mode" mixer enum ctl for Thinkpads that have also the software mute-LED control. Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:36 -04:00
Peter Zubaj	ea4b18887e	ALSA: emu10k1: Emu10k2 32 bit DMA mode [ Upstream commit `7241ea558c` ] Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two modes for DMA. Second mode is useful for 64 bit os with more then 2 GB of ram (fixes problems with big soundfont loading) 1) 32MB from 2 GB address space using 8192 pages (used now as default) 2) 16MB from 4 GB address space using 4096 pages Mode is set using HCFG_EXPANDED_MEM flag in HCFG register. Also format of emu10k2 page table is then different. Signed-off-by: Peter Zubaj <pzubaj@marticonet.sk> Tested-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:36 -04:00
Takashi Iwai	79f0cbcc9a	ALSA: emu10k1: Fix card shortname string buffer overflow [ Upstream commit `d02260824e` ] Some models provide too long string for the shortname that has 32bytes including the terminator, and it results in a non-terminated string exposed to the user-space. This isn't too critical, though, as the string is stopped at the succeeding longname string. This patch fixes such entries by dropping "SB" prefix (it's enough to fit within 32 bytes, so far). Meanwhile, it also changes strcpy() with strlcpy() to make sure that this kind of problem won't happen in future, too. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:36 -04:00
Takashi Iwai	33b9b8ceb1	ALSA: emux: Fix mutex deadlock in OSS emulation [ Upstream commit `1c94e65c66` ] The OSS emulation in synth-emux helper has a potential AB/BA deadlock at the simultaneous closing and opening: close -> snd_seq_release() -> sne_seq_free_client() -> snd_seq_delete_all_ports(): takes client->ports_mutex -> port_delete() -> snd_emux_unuse(): takes emux->register_mutex open -> snd_seq_oss_open() -> snd_emux_open_seq_oss(): takes emux->register_mutex -> snd_seq_event_port_attach() -> snd_seq_create_port(): takes client->ports_mutex This patch addresses the deadlock by reducing the rance taking emux->register_mutex in snd_emux_open_seq_oss(). The lock is needed for the refcount handling, so move it locally. The calls in emux_seq.c are already with the mutex, thus they are replaced with the version without mutex lock/unlock. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:36 -04:00
Takashi Iwai	1e568ab9b2	ALSA: emux: Fix mutex deadlock at unloading [ Upstream commit `07b0e5d49d` ] The emux-synth driver has a possible AB/BA mutex deadlock at unloading the emu10k1 driver: snd_emux_free() -> snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) -> snd_seq_delete_kernel_client() -> snd_seq_free_client(): mutex_lock(&register_mutex) snd_seq_release() -> snd_seq_free_client(): mutex_lock(&register_mutex) -> snd_seq_delete_all_ports() -> snd_emux_unuse(): mutex_lock(&emu->register_mutex) Basically snd_emux_detach_seq() doesn't need a protection of emu->register_mutex as it's already being unregistered. So, we can get rid of this for avoiding the deadlock. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:36 -04:00
Rafał Miłecki	3c021baa28	MIPS: BCM47XX: Fix detecting Microsoft MN-700 & Asus WL500G [ Upstream commit `96f7c21363` ] Since the day of adding this code it was broken. We were iterating over a wrong array and checking for wrong NVRAM entry. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: linux-mips@linux-mips.org Cc: Hauke Mehrtens <hauke@hauke-m.de> Patchwork: https://patchwork.linux-mips.org/patch/9654/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:35 -04:00
Markos Chandras	e17bb066ab	MIPS: Kconfig: Disable SMP/CPS for 64-bit [ Upstream commit `6ca716f2e5` ] A 64-bit build for Malta produces far too many build problems when SMP/CPS is selected. Moreover, there is currently no 64-bit product with SMP/CPS so we disable SMP/CPS when building for 64-bit until it is properly supported. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8573/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:35 -04:00
Niklas Cassel	8a77ae3ed6	MIPS: smp-cps: cpu_set FPU mask if FPU present [ Upstream commit `90db024f14` ] If we have an FPU, enroll ourselves in the FPU-full mask. Matching the MT_SMP and CMP implementations of smp_setup. Signed-off-by: Niklas Cassel <niklass@axis.com> Cc: paul.burton@imgtec.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8948/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:35 -04:00
John Crispin	718bce368d	MIPS: ralink: add missing symbol for RALINK_ILL_ACC [ Upstream commit `a7b7aad383` ] A driver was added in commit `5433acd81e` ("MIPS: ralink: add illegal access driver") without the Kconfig section being added. Fix this by adding the symbol to the Kconfig file. Signed-off-by: John Crispin <blogic@openwrt.org> Reported-by: Paul Bolle <pebolle@tiscali.nl> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9299/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:34 -04:00
Adrien Schildknecht	e10f7b8031	SSB: fix Kconfig dependencies [ Upstream commit `179fa46fb6` ] The commit `21400f252a` ("MIPS: BCM47XX: Make ssb init NVRAM instead of bcm47xx polling it") introduces a dependency to SSB_SFLASH but did not add it to the Kconfig. drivers/ssb/driver_mipscore.c:216:36: error: 'struct ssb_mipscore' has no member named 'sflash' struct ssb_sflash *sflash = &mcore->sflash; ^ drivers/ssb/driver_mipscore.c:249:12: error: dereferencing pointer to incomplete type if (sflash->present) { ^ Signed-off-by: Adrien Schildknecht <adrien+dev@schischi.me> Cc: m@bues.ch Cc: zajec5@gmail.com Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9598/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:34 -04:00
Ralf Baechle	3552e35020	MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard. [ Upstream commit `f05ff43355` ] This is no longer needed with the fixed, new and improved definition of cpu_has_mips_r2_exec_hazard in <asm/cpu-features.h>. For a discussion, see http://patchwork.linux-mips.org/patch/9539/. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:34 -04:00
Markos Chandras	3749ec1e51	MIPS: kernel: entry.S: Set correct ISA level for mips_ihb [ Upstream commit `aebac99384` ] Commit 6ebb496ffc7e("MIPS: kernel: entry.S: Add MIPS R6 related definitions") added the MIPSR6 definition but it did not update the ISA level of the actual assembly code so a pre-MIPSR6 jr.hb instruction was generated instead. Fix this by using the MISP_ISA_LEVEL_RAW macro. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Fixes: 6ebb496ffc7e("MIPS: kernel: entry.S: Add MIPS R6 related definitions") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9386/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:34 -04:00
Ganesan Ramalingam	a23817cb37	MIPS: Netlogic: Fix for SATA PHY init [ Upstream commit `872cd4c2c6` ] Update to the SATA PHY initialization. This is needed for SATA detection to succeed in all configurations. Signed-off-by: Ganesan Ramalingam <ganesanr@broadcom.com> Signed-off-by: Jayachandran C <jchandra@broadcom.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8886/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:33 -04:00
Aaro Koskinen	b50f1cb13d	MIPS: OCTEON: fix PCI interrupt mapping for D-Link DSR-1000N [ Upstream commit `b083518c52` ] Fix PCI interrupt mapping for DSR1000N. This will get the PCI slot interrupts working. The mapping is based on D-Link GPL tarball. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9593/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:33 -04:00
Alexander Sverdlin	9ba256194c	MIPS: Octeon: Remove udelay() causing huge IRQ latency [ Upstream commit `73bf3c2a50` ] udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon platforms because these operations are called from PCI_OP_READ() and PCI_OP_WRITE() under raw_spin_lock_irqsave(). Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: linux-mips@linux-mips.org Cc: David Daney <ddaney@cavium.com> Cc: Rob Herring <robh@kernel.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Masanari Iida <standby24x7@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Mathias <mathias.rulf@nokia.com> Patchwork: https://patchwork.linux-mips.org/patch/9576/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:33 -04:00
Boris Brezillon	76723e7ed5	clk: at91: usb: fix determine_rate prototype Commit c67881fc890916206e723329e774391c6ed354ce is a backport of `0b67c43ce3` upstream commit, fixing a bug on clk rate change propagation. But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:33 -04:00
Aaro Koskinen	51f3eddd03	MIPS: OCTEON: dma-octeon: fix OHCI USB config check [ Upstream commit `a8667d706d` ] CONFIG_USB_OCTEON_OHCI is deprecated and no longer needed to use OHCI on OCTEON II. Instead, CONFIG_USB_OHCI_HCD_PLATFORM should be used. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Aleksey Makarov <aleksey.makarov@auriga.com> Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9421/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:33 -04:00
Nicolas Schichan	7b5991c863	MIPS: BCM63xx: Move bcm63xx_gpio_init() to bcm63xx_register_devices(). [ Upstream commit `2ec459f2a7` ] When called from prom init code, bcm63xx_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move bcm63xx_gpio_init() to bcm63xx_register_devices() (an arch_initcall) where kmalloc works. Fixes: `14e85c0e69` ("gpio: remove gpio_descs global array") Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Alexandre Courbot <acourbot@nvidia.com> Patchwork: https://patchwork.linux-mips.org/patch/9530/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:32 -04:00
Alexei Starovoitov	2611e2418c	bpf: fix 64-bit divide [ Upstream commit `876a7ae65b` ] ALU64_DIV instruction should be dividing 64-bit by 64-bit, whereas do_div() does 64-bit by 32-bit divide. x64 and arm64 JITs correctly implement 64 by 64 unsigned divide. llvm BPF backend emits code assuming that ALU64_DIV does 64 by 64. Fixes: `89aa075832` ("net: sock: allow eBPF programs to be attached to sockets") Reported-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:32 -04:00
Jann Horn	7f1a6ae73b	fs: take i_mutex during prepare_binprm for set[ug]id executables [ Upstream commit `8b01fc86b9` ] This prevents a race between chown() and execve(), where chowning a setuid-user binary to root would momentarily make the binary setuid root. This patch was mostly written by Linus Torvalds. Signed-off-by: Jann Horn <jann@thejh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:32 -04:00
Troy Tan	c42f3e154e	rtlwifi: rtl8192ee: Fix handling of new style descriptors [ Upstream commit `d0311314d0` ] The hardware and firmware for the RTL8192EE utilize a FIFO list of descriptors. There were some problems with the initial implementation. The worst of these failed to detect that the FIFO was becoming full, which led to the device needing to be power cycled. As this condition is not relevant to most of the devices supported by rtlwifi, a callback routine was added to detect this situation. This patch implements the necessary changes in the pci handler, and the linkage into the appropriate rtl8192ee routine. Signed-off-by: Troy Tan <troy_tan@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [V3.18] Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:31 -04:00
Naoya Horiguchi	35d44e970e	mm/hugetlb: take page table lock in follow_huge_pmd() [ Upstream commit `e66f17ff71` ] We have a race condition between move_pages() and freeing hugepages, where move_pages() calls follow_page(FOLL_GET) for hugepages internally and tries to get its refcount without preventing concurrent freeing. This race crashes the kernel, so this patch fixes it by moving FOLL_GET code for hugepages into follow_huge_pmd() with taking the page table lock. This patch intentionally removes page==NULL check after pte_page. This is justified because pte_page() never returns NULL for any architectures or configurations. This patch changes the behavior of follow_huge_pmd() for tail pages and then tail pages can be pinned/returned. So the caller must be changed to properly handle the returned tail pages. We could have a choice to add the similar locking to follow_huge_(addr\|pud) for consistency, but it's not necessary because currently these functions don't support FOLL_GET flag, so let's leave it for future development. Here is the reproducer: $ cat movepages.c #include <stdio.h> #include <stdlib.h> #include <numaif.h> #define ADDR_INPUT 0x700000000000UL #define HPS 0x200000 #define PS 0x1000 int main(int argc, char argv[]) { int i; int nr_hp = strtol(argv[1], NULL, 0); int nr_p = nr_hp HPS / PS; int ret; void *addrs; int status; int nodes; pid_t pid; pid = strtol(argv[2], NULL, 0); addrs = malloc(sizeof(char ) * nr_p + 1); status = malloc(sizeof(char ) nr_p + 1); nodes = malloc(sizeof(char ) nr_p + 1); while (1) { for (i = 0; i < nr_p; i++) { addrs[i] = (void )ADDR_INPUT + i PS; nodes[i] = 1; status[i] = 0; } ret = numa_move_pages(pid, nr_p, addrs, nodes, status, MPOL_MF_MOVE_ALL); if (ret == -1) err("move_pages"); for (i = 0; i < nr_p; i++) { addrs[i] = (void )ADDR_INPUT + i PS; nodes[i] = 0; status[i] = 0; } ret = numa_move_pages(pid, nr_p, addrs, nodes, status, MPOL_MF_MOVE_ALL); if (ret == -1) err("move_pages"); } return 0; } $ cat hugepage.c #include <stdio.h> #include <sys/mman.h> #include <string.h> #define ADDR_INPUT 0x700000000000UL #define HPS 0x200000 int main(int argc, char argv[]) { int nr_hp = strtol(argv[1], NULL, 0); char p; while (1) { p = mmap((void )ADDR_INPUT, nr_hp HPS, PROT_READ \| PROT_WRITE, MAP_PRIVATE \| MAP_ANONYMOUS \| MAP_HUGETLB, -1, 0); if (p != (void )ADDR_INPUT) { perror("mmap"); break; } memset(p, 0, nr_hp HPS); munmap(p, nr_hp * HPS); } } $ sysctl vm.nr_hugepages=40 $ ./hugepage 10 & $ ./movepages 10 $(pgrep -f hugepage) Fixes: `e632a938d9` ("mm: migrate: add hugepage migration code to move_pages()") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Reported-by: Hugh Dickins <hughd@google.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Rientjes <rientjes@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Steve Capper <steve.capper@linaro.org> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:31 -04:00
Naoya Horiguchi	dd8f776dbe	mm/hugetlb: use pmd_page() in follow_huge_pmd() [ Upstream commit `9753412701` ] Commit `61f77eda9b` ("mm/hugetlb: reduce arch dependent code around follow_huge_") broke follow_huge_pmd() on s390, where pmd and pte layout differ and using pte_page() on a huge pmd will return wrong results. Using pmd_page() instead fixes this. All architectures that were touched by that commit have pmd_page() defined, so this should not break anything on other architectures. Fixes: `61f77eda` "mm/hugetlb: reduce arch dependent code around follow_huge_" Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: Michal Hocko <mhocko@suse.cz>, Andrea Arcangeli <aarcange@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by: David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:31 -04:00
Ian Abbott	ced9df8d7f	staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel [ Upstream commit `abe46b8932` ] Reading of analog input channels by the `INSN_READ` comedi instruction is broken for all except channel 0. `pci171x_ai_insn_read()` calls `pci171x_ai_read_sample()` with the wrong value for the third parameter. It is supposed to be the current index in a channel list (which is always of length 1 in this case, so the index should be 0), but instead it is passing the actual channel number. `pci171x_ai_read_sample()` checks the channel number encoded in the raw sample value read from the hardware matches the channel number stored in the specified index of the previously set up channel list and returns `-ENODATA` if it doesn't match. Since the index should always be 0 in this case, the match will fail unless the channel number is also 0. Fix it by passing 0 as the channel index. Note that when the bug first appeared, it was `pci171x_ai_dropout()` that was called with the wrong parameter value. `pci171x_ai_dropout()` got replaced with `pci171x_ai_read_sample()` in commit `7fd2dae250` ("staging: comedi: adv_pci1710: introduce pci171x_ai_read_sample()"). Fixes: `16c7eb6047` ("staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code") Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Cc: stable <stable@vger.kernel.org> # 3.16+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:30 -04:00
Radim Krčmář	24f2e905a3	KVM: nVMX: mask unrestricted_guest if disabled on L0 [ Upstream commit `0790ec172d` ] If EPT was enabled, unrestricted_guest was allowed in L1 regardless of L0. L1 triple faulted when running L2 guest that required emulation. Another side effect was 'WARN_ON_ONCE(vmx->nested.nested_run_pending)' in L0's dmesg: WARNING: CPU: 0 PID: 0 at arch/x86/kvm/vmx.c:9190 nested_vmx_vmexit+0x96e/0xb00 [kvm_intel] () Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when the host doesn't have it enabled. Fixes: `78051e3b7e` ("KVM: nVMX: Disable unrestricted mode if ept=0") Cc: stable@vger.kernel.org Tested-By: Kashyap Chamarthy <kchamart@redhat.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:30 -04:00
Florian Westphal	d07c59df9f	netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING [ Upstream commit `0b67c43ce3` ] We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well. Fixes: `93fdd47e5` ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING') Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:30 -04:00
Junjie Mao	d08282c148	driver core: bus: Goto appropriate labels on failure in bus_add_device [ Upstream commit `1c34203a14` ] It is not necessary to call device_remove_groups() when device_add_groups() fails. The group added by device_add_groups() should be removed if sysfs_create_link() fails. Fixes: `fa6fdb33b4` ("driver core: bus_type: add dev_groups") Signed-off-by: Junjie Mao <junjie_mao@yeah.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:29 -04:00
Linus Walleij	ce7c6bb45f	drivers: platform: parse IRQ flags from resources [ Upstream commit `7085a7401b` ] This fixes a regression from the net subsystem: After commit `d52fdbb735` "smc91x: retrieve IRQ and trigger flags in a modern way" a regression would appear on some legacy platforms such as the ARM PXA Zylonite that specify IRQ resources like this: static struct resource r = { .start = X, .end = X, .flags = IORESOURCE_IRQ \| IORESOURCE_IRQ_HIGHEDGE, }; The previous code would retrieve the resource and parse the high edge setting in the SMC91x driver, a use pattern that means every driver specifying an IRQ flag from a static resource need to parse resource flags and apply them at runtime. As we switched the code to use IRQ descriptors to retrieve the the trigger type like this: irqd_get_trigger_type(irq_get_irq_data(...)); the code would work for new platforms using e.g. device tree as the backing irq descriptor would have its flags properly set, whereas this kind of oldstyle static resources at no point assign the trigger flags to the corresponding IRQ descriptor. To make the behaviour identical on modern device tree and legacy static platform data platforms, modify platform_get_irq() to assign the trigger flags to the irq descriptor when a client looks up an IRQ from static resources. Fixes: `d52fdbb735` ("smc91x: retrieve IRQ and trigger flags in a modern way") Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:29 -04:00
Dan Carpenter	e2276c7e6b	memstick: mspro_block: add missing curly braces [ Upstream commit `13f6b191aa` ] Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: `f1d8269802` ('memstick: use fully asynchronous request processing') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:28 -04:00
Nishanth Menon	e0407f4aea	C6x: time: Ensure consistency in __init [ Upstream commit `f4831605f2` ] time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well. This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references the function __init timer64_init(). This is often because time_init lacks a __init annotation or the annotation of timer64_init is wrong. Fixes: `546a39546c` ("C6X: time management") Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:28 -04:00
Vutla, Lokesh	da41fc72d2	crypto: omap-aes - Fix support for unequal lengths [ Upstream commit `6d7e7e02a0` ] For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: `6242332ff2` ("crypto: omap-aes - Add support for cases of unaligned lengths") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:28 -04:00
Nicolas Iooss	9e9150bece	wl18xx: show rx_frames_per_rates as an array as it really is [ Upstream commit `a3fa71c40f` ] In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead. This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'". Fixes: `c5d94169e8` ("wl18xx: use new fw stats structures") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:28 -04:00
mancha security	e4e28fbc30	lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR [ Upstream commit `0b053c9518` ] OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. For the random driver and crypto drivers, calls are emitted ... $ gdb vmlinux (gdb) disassemble memzero_explicit Dump of assembler code for function memzero_explicit: 0xffffffff813a18b0 <+0>: push %rbp 0xffffffff813a18b1 <+1>: mov %rsi,%rdx 0xffffffff813a18b4 <+4>: xor %esi,%esi 0xffffffff813a18b6 <+6>: mov %rsp,%rbp 0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 <memset> 0xffffffff813a18be <+14>: pop %rbp 0xffffffff813a18bf <+15>: retq End of assembler dump. (gdb) disassemble extract_entropy [...] 0xffffffff814a5009 <+313>: mov %r12,%rdi 0xffffffff814a500c <+316>: mov $0xa,%esi 0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 <memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax [...] ... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead. Minimal test example when we assume memzero_explicit() would not be a call, but would have been inlined instead: static inline void memzero_explicit(void *s, size_t count) { memset(s, 0, count); <foo> } int main(void) { char buff[20]; snprintf(buff, sizeof(buff) - 1, "test"); printf("%s", buff); memzero_explicit(buff, sizeof(buff)); return 0; } With <foo> := OPTIMIZER_HIDE_VAR(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp 0x000000000040046f <+47>: retq End of assembler dump. With <foo> := barrier(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp 0x0000000000400488 <+72>: retq End of assembler dump. As can be seen, movq, movq, movl are being emitted inlined via memset(). Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/ Fixes: `d4c5efdb97` ("random: add and use memzero_explicit() for clearing data") Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: mancha security <mancha1@zoho.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:27 -04:00
Daniel Borkmann	b6c65e3672	ebpf: verifier: check that call reg with ARG_ANYTHING is initialized [ Upstream commit `80f1d68ccb` ] I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register). This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API. The underlying issue is that ARG_ANYTHING should actually be split into two different semantics: 1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and 2) ARG_ANYTHING that is an argument actually being used by a helper function and guaranteed to be an initialized register. The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking. Fixes: `17a5267067` ("bpf: verifier (add verifier core)") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:27 -04:00
Sabrina Dubroca	fcea4d66b0	e1000: add dummy allocator to fix race condition between mtu change and netpoll [ Upstream commit `08e8331654` ] There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330 [...] Call Trace: [<ffffffff81195445>] put_page+0x55/0x60 [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200 [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60 [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0 [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840 [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170 [<ffffffff81647050>] dev_set_mtu+0xa0/0x140 [<ffffffff81664218>] do_setlink+0x218/0xac0 [<ffffffff814459e9>] ? nla_parse+0xb9/0x120 [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890 [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40 [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: `edbbb3ca10` ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:27 -04:00
Anna Schumaker	49b6acb62a	NFS: Add a stub for GETDEVICELIST [ Upstream commit `7c61f0d389` ] `d4b18c3e` (pnfs: remove GETDEVICELIST implementation) removed the GETDEVICELIST operation from the NFS client, but left a "hole" in the nfs4_procedures array. This caused /proc/self/mountstats to report an operation named "51" where GETDEVICELIST used to be. This patch adds a stub to fix mountstats. Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Fixes: `d4b18c3e` (pnfs: remove GETDEVICELIST implementation) Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:26 -04:00
J. Bruce Fields	61c8c52ced	nfsd4: disallow SEEK with special stateids [ Upstream commit `980608fb50` ] If the client uses a special stateid then we'll pass a NULL file to vfs_llseek. Fixes: `24bab49122` " NFSD: Implement SEEK" Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: stable@vger.kernel.org Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:26 -04:00
J. Bruce Fields	5a9fb83ea5	nfsd4: fix READ permission checking [ Upstream commit `6e4891dc28` ] In the case we already have a struct file (derived from a stateid), we still need to do permission-checking; otherwise an unauthorized user could gain access to a file by sniffing or guessing somebody else's stateid. Cc: stable@vger.kernel.org Fixes: `dc97618ddd` "nfsd4: separate splice and readv cases" Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:25 -04:00
Al Viro	c5f77349d6	RCU pathwalk breakage when running into a symlink overmounting something [ Upstream commit `3cab989afd` ] Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput(). Cc: stable@vger.kernel.org # since 2.6.39 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:25 -04:00
Dmitry Torokhov	3d46720fc1	drm/i915: cope with large i2c transfers [ Upstream commit `9535c4757b` ] The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit `9d8dc3e529` "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:25 -04:00
Imre Deak	712d9cd6d0	drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg [ Upstream commit `b5f1c97f94` ] Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit `ddeea5b0c3` Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:24 -04:00
Daniel Vetter	631590d952	drm/i915: Dont enable CS_PARSER_ERROR interrupts at all [ Upstream commit `37ef01ab5d` ] We stopped handling them in commit `aaecdf611a` Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (cough coreboot cough) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171 Tested-by: Mono <mono-for-kernel-org@donderklumpen.de> Tested-by: info@gluglug.org.uk Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:24 -04:00
Alex Deucher	9be03c9a98	drm/radeon: fix doublescan modes (v2) [ Upstream commit `fd99a0943f` ] Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:24 -04:00
Mark Brown	808601dcd3	i2c: core: Export bus recovery functions [ Upstream commit `c1c21f4e60` ] Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported: ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined! Add exports to fix this. Fixes: `5f9296ba21` (i2c: Add bus recovery infrastructure) Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:23 -04:00
Dmitry Torokhov	74cd034768	i2c: rk3x: report number of messages transmitted [ Upstream commit `c6cbfb91b8` ] master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:23 -04:00
Rabin Vincent	c130887c14	tracing: Handle ftrace_dump() atomic context in graph_trace_open() [ Upstream commit `ef99b88b16` ] graph_trace_open() can be called in atomic context from ftrace_dump(). Use GFP_ATOMIC for the memory allocations when that's the case, in order to avoid the following splat. BUG: sleeping function called from invalid context at mm/slab.c:2849 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 Backtrace: .. [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238) r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0) r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8 r4:810d16f0 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c) r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec) r4:810d2580 r3:00000000 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20) r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a r4:808d5394 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18) [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18) r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60 r4:8454fe00 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c) r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60 r4:84f01e00 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac) r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c) r6:00000026 r5:00000000 r4:00000026 r3:8007a938 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc) r4:808c1e38 r3:0000002e [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c) r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015 r4:8880210c r3:808c7ef0 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c) Link: http://lkml.kernel.org/r/1428953721-31349-1-git-send-email-rabin@rab.in Link: http://lkml.kernel.org/r/1428957012-2319-1-git-send-email-rabin@rab.in Cc: stable@vger.kernel.org # 3.13+ Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:23 -04:00
Sagi Grimberg	72f9b0fa0d	IB/iser: Fix wrong calculation of protection buffer length [ Upstream commit `a065fe6aa2` ] This length miss-calculation may cause a silent data corruption in the DIX case and cause the device to reference unmapped area. Fixes: `d77e65350f` ('libiscsi, iser: Adjust data_length to include protection information') Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:22 -04:00
Erez Shitrit	4eb6d476fc	IB/mlx4: Fix WQE LSO segment calculation [ Upstream commit `ca9b590caa` ] The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers. It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers. The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages. An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2hlen (256) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state. Fixes: `b832be1e40` ('IB/mlx4: Add IPoIB LSO support') Reported-by: Matthew Finlay <matt@mellanox.com> Signed-off-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:22 -04:00
Yann Droneaud	ee4709cebb	IB/core: don't disallow registering region starting at 0x0 [ Upstream commit `66578b0b2f` ] In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit `8494057ab5` ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0). This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages(). There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: <stable@vger.kernel.org> # `8494057ab5` ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") Cc: Shachar Raindel <raindel@mellanox.com> Cc: Jack Morgenstein <jackm@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:22 -04:00
Yann Droneaud	33f0de4016	IB/core: disallow registering 0-sized memory region [ Upstream commit `8abaae62f3` ] If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller. This should not be allowed: it's not expected for a memory region to have a size equal to 0. This patch adds a check to explicitly refuse to register a 0-sized region. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: <stable@vger.kernel.org> Cc: Shachar Raindel <raindel@mellanox.com> Cc: Jack Morgenstein <jackm@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:21 -04:00
Ezequiel Garcia	071dac7383	[media] stk1160: Make sure current buffer is released [ Upstream commit `aeff092767` ] The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it. Cc: stable@vger.kernel.org Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:21 -04:00
Sifan Naeem	c2c7af9c23	[media] rc: img-ir: fix error in parameters passed to irq_free() [ Upstream commit `80ccf4ad06` ] img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure. This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module. WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278 __free_irq+0xb4/0x214() Trying to free already-free IRQ 58 Modules linked in: img_ir(-) CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ... Call Trace: ... [<8048d420>] __free_irq+0xb4/0x214 [<8048d6b4>] free_irq+0xac/0xf4 [<c009b130>] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>] platform_drv_remove+0x30/0x54 ... Fixes: `160a8f8aec` ("[media] rc: img-ir: add base driver") Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com> Cc: <stable@vger.kernel.org> # 3.15+ Acked-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:21 -04:00
James Bottomley	3b2b5bee96	mvsas: fix panic on expander attached SATA devices [ Upstream commit `56cbd0ccc1` ] mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer. mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic. Reported-by: Adam Talbot <ajtalbot1@gmail.com> Tested-by: Adam Talbot <ajtalbot1@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:20 -04:00
K. Y. Srinivasan	49afcd312b	Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open() [ Upstream commit `40384e4bbe` ] Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:20 -04:00
Martin K. Petersen	a31989f031	sd: Fix missing ATO tag check [ Upstream commit `e557990e35` ] `3aec2f41a8` introduced a merge error where we would end up check for sdkp instead of sdkp->ATO. Fix this so we register app tag capability correctly. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:20 -04:00
Martin K. Petersen	ee7633f06e	sd: Unregister integrity profile [ Upstream commit `e727c42bd5` ] The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Reported-by: Sagi Grimberg <sagig@dev.mellanox.co.il> Tested-by: Sagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:20 -04:00
Ben Collins	34c26c01be	Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY" [ Upstream commit `c0403ec0bb` ] This reverts Linux 4.1-rc1 commit `0618764cb2`. The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver not dm-crypt. dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done. Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example). dm-crypt (before the patch that needs reverting) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt. The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver. Commit `0618764cb2` incorrectly made dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly. Revert it. Correct backlog handling should be implemented in the CAAM driver instead. Cc'ing stable purely because commit `0618764cb2` did. If for some reason a stable@ kernel did pick up commit `0618764cb2` it should get reverted. Signed-off-by: Rabin Vincent <rabin.vincent@axis.com> Reviewed-by: Horia Geanta <horia.geanta@freescale.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:19 -04:00
Archit Taneja	5ec6388f8e	clk: qcom: fix RCG M/N counter configuration [ Upstream commit `0b21503dbb` ] Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by: Archit Taneja <architt@codeaurora.org> Fixes: `bcd61c0f53` (clk: qcom: Add support for root clock generators (RCGs)) Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:19 -04:00
Stephen Boyd	d415fc1d43	clk: qcom: Fix i2c frequency table [ Upstream commit `0bf0ff82c3` ] PXO is 25MHz, not 27MHz. Fix the table. Fixes: `24d8fba44a` "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Tested-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:19 -04:00
Thierry Reding	06714fcfc0	clk: tegra: Register the proper number of resets [ Upstream commit `5e43e25917` ] The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32). This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array. Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Fixes: `6d5b988e7d` ("clk: tegra: implement a reset driver") Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:18 -04:00
Bartlomiej Zolnierkiewicz	7b5b428d0b	clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC [ Upstream commit `3a9e9cb65b` ] Commit `42773b28e7` ("clk: samsung: exynos4: Enable ARMCLK down feature") enabled ARMCLK down feature on all Exynos4 SoCs. Unfortunately on Exynos4210 SoC ARMCLK down feature causes a lockup when ondemand cpufreq governor is used. Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs. This patch was tested on: - Exynos4210 SoC based Trats board - Exynos4210 SoC based Origen board - Exynos4412 SoC based Trats2 board - Exynos4412 SoC based Odroid-U3 board Cc: Daniel Drake <drake@endlessm.com> Cc: Tomasz Figa <t.figa@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Fixes: `42773b28e7` ("clk: samsung: exynos4: Enable ARMCLK down feature") Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:18 -04:00
Gregory CLEMENT	30d458c451	gpio: mvebu: Fix mask/unmask managment per irq chip type [ Upstream commit `61819549f5` ] Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario: First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm. The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue. It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario. This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov: `9ece8839b1` "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there: http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012 Reported-by: Evgeniy A. Dushistov <dushistov@mail.ru> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.7 + Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:18 -04:00
Max Filippov	2f55b8d36f	xtensa: ISS: fix locking in TAP network adapter [ Upstream commit `24e94454c8` ] - don't lock lp->lock in the iss_net_timer for the call of iss_net_poll, it will lock it itself; - invert order of lp->lock and opened_lock acquisition in the iss_net_open to make it consistent with iss_net_poll; - replace spin_lock with spin_lock_bh when acquiring locks used in iss_net_timer from non-atomic context; - replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit as the driver doesn't use lp->lock in the hard IRQ context; - replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise lockdep is unhappy about using non-static key. Cc: <stable@vger.kernel.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:17 -04:00
Max Filippov	0333a44643	xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range [ Upstream commit `01e84c70fe` ] xtensa actually uses sync_file_range2 implementation, so it should define __NR_sync_file_range2 as other architectures that use that function. That fixes userspace interface (that apparently never worked) and avoids special-casing xtensa in libc implementations. See the thread ending at http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html for more details. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:17 -04:00
Max Filippov	6a87cc5ee7	xtensa: xtfpga: fix hardware lockup caused by LCD driver [ Upstream commit `4949009eb8` ] LCD driver is always built for the XTFPGA platform, but its base address is not configurable, and is wrong for ML605/KC705. Its initialization locks up KC705 board hardware. Make the whole driver optional, and its base address and bus width configurable. Implement 4-bit bus access method. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:17 -04:00
Rafael J. Wysocki	fc69ac41da	ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline() [ Upstream commit `4c533c801d` ] acpi_scan_is_offline() may be called under the physical_node_lock lock of the given device object's parent, so prevent lockdep from complaining about that by annotating that instance with SINGLE_DEPTH_NESTING. Fixes: `caa73ea158` (ACPI / hotplug / driver core: Handle containers in a special way) Reported-and-tested-by: Xie XiuQi <xiexiuqi@huawei.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:16 -04:00
Octavian Purdila	6fd1b9912f	ACPICA: Tables: Don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table(). [ Upstream commit `77ddc2fe08` ] ACPICA commit c70434d4da13e65b6163c79a5aa16b40193631c7 ACPI_MTX_TABLES is acquired and released by the callers of acpi_tb_install_standard_table() so releasing it in the function itself is causing the following error in Linux kernel if the table is reloaded: ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321) Call Trace: [<ffffffff81b0bd48>] dump_stack+0x4f/0x7b [<ffffffff81546bf5>] acpi_ut_release_mutex+0x47/0x67 [<ffffffff81544357>] acpi_load_table+0x73/0xcb Link: https://github.com/acpica/acpica/commit/c70434d4 Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:16 -04:00
Lv Zheng	9d7f2ea242	ACPICA: Utilities: split IO address types from data type models. [ Upstream commit `2b8760100e` ] ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Reported-and-tested-by: Sial Nije <sialnije@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:16 -04:00
Howard Mitchell	28cafa9851	ASoC: pcm512x: Add 'Analogue' prefix to analogue volume controls [ Upstream commit `4d9b13c7cc` ] This is to ensure that 'alsactl restore' does not apply default initialisation as the chip reset defaults are preferred. Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:15 -04:00
Manish Badarkhe	e31c834e34	ASoC: davinci-evm: drop un-necessary remove function [ Upstream commit `a57069e33f` ] As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function. Hence drop the 'remove' function. Fixes: `ee2f615d6e` (ASoC: davinci-evm: Add device tree binding) Signed-off-by: Manish Badarkhe <manishvb@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:15 -04:00
Sergej Sawazki	26ea595bd5	ASoC: wm8741: Fix rates constraints values [ Upstream commit `8787041d9b` ] The WM8741 DAC supports the following typical audio sampling rates: 44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz) 32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz) For the rates lists, we should use 82000 instead of 88235, 176400 instead of 1764000 and 192000 instead of 19200 (seems to be a typo). Signed-off-by: Sergej Sawazki <ce3a@gmx.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:15 -04:00
Pascal Huerst	8003c8f027	ASoC: cs4271: Increase delay time after reset [ Upstream commit `74ff960222` ] The delay time after a reset in the codec probe callback was too short, and did not work on certain hw because the codec needs more time to power on. This increases the delay time from 1us to 1ms. Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com> Acked-by: Brian Austin <brian.austin@cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:14 -04:00
Michael Ellerman	11a0c1eff6	powerpc/cell: Fix cell iommu after it_page_shift changes [ Upstream commit `7261b956b2` ] The patch to add it_page_shift incorrectly changed the increment of uaddr to use it_page_shift, rather then (1 << it_page_shift). This broke booting on at least some Cell blades, as the iommu was basically non-functional. Fixes: `3a553170d3` ("powerpc/iommu: Add it_page_shift field to determine iommu page size") Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:14 -04:00
Michael Ellerman	74fb2a59b1	powerpc/cell: Fix crash in iic_setup_cpu() after per_cpu changes [ Upstream commit `b0dd00addc` ] The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu() is wrong. It causes an oops at boot. We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio. Sparse noticed this, because we pass a non-iomem pointer to out_be64(), but we obviously don't check the sparse results often enough. Fixes: `69111bac42` ("powerpc: Replace __get_cpu_var uses") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:14 -04:00
Dave Olson	55b47182b6	powerpc: Fix missing L2 cache size in /sys/devices/system/cpu [ Upstream commit `f7e9e35836` ] This problem appears to have been introduced in 2.6.29 by commit `93197a36a9` "Rewrite sysfs processor cache info code". This caused lscpu to error out on at least e500v2 devices, eg: error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this. Fixes: `93197a36a9` ("powerpc: Rewrite sysfs processor cache info code") Signed-off-by: Dave Olson <olson@cumulusnetworks.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:14 -04:00
Gavin Shan	945818207f	powerpc/powernv: Don't map M64 segments using M32DT [ Upstream commit `027fa02f84` ] If M64 has been supported, the prefetchable 64-bits memory resources shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately, we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was introduced by commit `262af55` ("powerpc/powernv: Enable M64 aperatus for PHB3"). The patch fixes the issue by simply skipping M64 resources when updating to M32DT. Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:13 -04:00
Alexander Ploumistos	132a0d3a3c	Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card [ Upstream commit `2eeff0b431` ] Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so that the device can load the ath3k firmware and re-enumerate itself as an AR3011 device. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=aff1 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Alexander Ploumistos <alexpl@fedoraproject.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:13 -04:00
Sagi Grimberg	eb2844f82f	iser-target: Fix session hang in case of an rdma read DIF error [ Upstream commit `364189f0ad` ] This hang was a result of a missing command put when a DIF error occurred during a rdma read (and we sent an CHECK_CONDITION error without passing it to the backend). Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:13 -04:00
Akinobu Mita	5e64371411	target/file: Fix SG table for prot_buf initialization [ Upstream commit `c836777830` ] In fd_do_prot_rw(), it allocates prot_buf which is used to copy from se_cmd->t_prot_sg by sbc_dif_copy_prot(). The SG table for prot_buf is also initialized by allocating 'se_cmd->t_prot_nents' entries of scatterlist and setting the data length of each entry to PAGE_SIZE at most. However if se_cmd->t_prot_sg contains a clustered entry (i.e. sg->length > PAGE_SIZE), the SG table for prot_buf can't be initialized correctly and sbc_dif_copy_prot() can't copy to prot_buf. (This actually happened with TCM loopback fabric module) As prot_buf is allocated by kzalloc() and it's physically contiguous, we only need a single scatterlist entry. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:12 -04:00
Akinobu Mita	606105af94	target/file: Fix UNMAP with DIF protection support [ Upstream commit `64d240b721` ] When UNMAP command is issued with DIF protection support enabled, the protection info for the unmapped region is remain unchanged. So READ command for the region causes data integrity failure. This fixes it by invalidating protection info for the unmapped region by filling with 0xff pattern. This change also adds helper function fd_do_prot_fill() in order to reduce code duplication with existing fd_format_prot(). Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:12 -04:00
Akinobu Mita	cc75f2514d	target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled [ Upstream commit `38da0f49e8` ] When CONFIG_DEBUG_SG=y and DIF protection support enabled, kernel BUG()s are triggered due to the following two issues: 1) prot_sg is not initialized by sg_init_table(). When CONFIG_DEBUG_SG=y, scatterlist helpers check sg entry has a correct magic value. 2) vmalloc'ed buffer is passed to sg_set_buf(). sg_set_buf() uses virt_to_page() to convert virtual address to struct page, but it doesn't work with vmalloc address. vmalloc_to_page() should be used instead. As prot_buf isn't usually too large, so fix it by allocating prot_buf by kmalloc instead of vmalloc. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:11 -04:00
Nicholas Bellinger	d71c65f44e	target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling [ Upstream commit `c8e639852a` ] This patch fixes a bug for COMPARE_AND_WRITE handling with fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC. It adds the missing allocation for cmd->t_bidi_data_sg within transport_generic_new_cmd() that is used by COMPARE_AND_WRITE for the initial READ payload, even if the fabric is already providing a pre-allocated buffer for cmd->t_data_sg. Also, fix zero-length COMPARE_AND_WRITE handling within the compare_and_write_callback() and target_complete_ok_work() to queue the response, skipping the initial READ. This fixes COMPARE_AND_WRITE emulation with loopback, vhost, and xen-backend fabric drivers using SG_TO_MEM_NOALLOC. Reported-by: Christoph Hellwig <hch@lst.de> Cc: Christoph Hellwig <hch@lst.de> Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:11 -04:00
K. Y. Srinivasan	867af24da0	scsi: storvsc: Fix a bug in copy_from_bounce_buffer() [ Upstream commit `8de580742f` ] We may exit this function without properly freeing up the maapings we may have acquired. Fix the bug. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Long Li <longli@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:11 -04:00
Brian Norris	054cf47d81	UBI: fix check for "too many bytes" [ Upstream commit `299d0c5b27` ] The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Cc: stable <stable@vger.kernel.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com> [rw: Fixed comparison] Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:11 -04:00
Brian Norris	256f346654	UBI: initialize LEB number variable [ Upstream commit `f16db8071c` ] In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it. This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway. Coverity CID #113449 Cc: stable <stable@vger.kernel.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:10 -04:00
Brian Norris	c2ffa098d6	UBI: fix out of bounds write [ Upstream commit `d74adbdb9a` ] If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Cc: stable <stable@vger.kernel.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:10 -04:00
Brian Norris	cdf5f4433c	UBI: account for bitflips in both the VID header and data [ Upstream commit `8eef7d70f7` ] We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead. Coverity CID #1226856 Cc: stable <stable@vger.kernel.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:10 -04:00
Thomas D	1a18b9807e	tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile [ Upstream commit `f82263c698` ] Since commit `ee0778a301` ("tools/power: turbostat: make Makefile a bit more capable") turbostat's Makefile is using [...] BUILD_OUTPUT := $(PWD) [...] which obviously causes trouble when building "turbostat" with make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat because GNU make does not update nor guarantee that $PWD is set. This patch changes the Makefile to use $CURDIR instead, which GNU make guarantees to set and update (i.e. when using "make -C ...") and also adds support for the O= option (see "make help" in your root of your kernel source tree for more details). Link: https://bugs.gentoo.org/show_bug.cgi?id=533918 Fixes: `ee0778a301` ("tools/power: turbostat: make Makefile a bit more capable") Signed-off-by: Thomas D. <whissi@whissi.de> Cc: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:09 -04:00
Steven Rostedt (Red Hat)	06676db706	tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING [ Upstream commit `c5e691928b` ] When a event PADDING is hit (a deleted event that is still in the ring buffer), translate_data() sets the length of the padding and also updates the data pointer which is passed back to the caller. This is unneeded because the caller also updates the data pointer with the passed back length. translate_data() should not update the pointer, only set the length. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: stable@vger.kernel.org # 3.12+ Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:09 -04:00
Anton Blanchard	ff342613d0	powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH [ Upstream commit `9a5cbce421` ] We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces. Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:09 -04:00
Vinson Lee	877f68ecbd	perf tools: Work around lack of sched_getcpu in glibc < 2.6. [ Upstream commit `e1e455f4f4` ] This patch fixes this build error with glibc < 2.6. CC util/cloexec.o cc1: warnings being treated as errors util/cloexec.c: In function ‘perf_flag_probe’: util/cloexec.c:24: error: implicit declaration of function ‘sched_getcpu’ util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’ make: *** [util/cloexec.o] Error 1 Signed-off-by: Vinson Lee <vlee@twitter.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Yann Droneaud <ydroneaud@opteya.com> Cc: stable@vger.kernel.org # 3.18+ Link: http://lkml.kernel.org/r/1427137761-16119-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:09 -04:00
Vinson Lee	7b6f0b0a71	perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older. [ Upstream commit `4e31050f48` ] The token STT_GNU_IFUNC is not available with glibc 2.9 and older. Define this token if it is not already defined. This patch fixes this build errors with older versions of glibc. CC util/symbol-elf.o util/symbol-elf.c: In function ‘elf_sym__is_function’: util/symbol-elf.c:75: error: ‘STT_GNU_IFUNC’ undeclared (first use in this function) util/symbol-elf.c:75: error: (Each undeclared identifier is reported only once util/symbol-elf.c:75: error: for each function it appears in.) make: *** [util/symbol-elf.o] Error 1 Signed-off-by: Vinson Lee <vlee@twitter.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Anton Blanchard <anton@samba.org> Cc: Avi Kivity <avi@cloudius-systems.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Cc: Waiman Long <Waiman.Long@hp.com> Cc: stable@vger.kernel.org # 3.17+ Link: http://lkml.kernel.org/r/1423528286-13630-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:08 -04:00
Eric W. Biederman	1c1cf82e19	mnt: Don't propagate umounts in __detach_mounts [ Upstream commit `8318e667f1` ] Invoking mount propagation from __detach_mounts is inefficient and wrong. It is inefficient because __detach_mounts already walks the list of mounts that where something needs to be done, and mount propagation walks some subset of those mounts again. It is actively wrong because if the dentry that is passed to __detach_mounts is not part of the path to a mount that mount should not be affected. change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation tree of a master mount so it's slaves are connected to another master if possible. Which means even removing a mount from the middle of a mount tree with __detach_mounts will not deprive any mount propagated mount events. Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:08 -04:00
Eric W. Biederman	6b1353cb26	mnt: Improve the umount_tree flags [ Upstream commit `e819f15210` ] - Remove the unneeded declaration from pnode.h - Mark umount_tree static as it has no callers outside of namespace.c - Define an enumeration of umount_tree's flags. - Pass umount_tree's flags in by name This removes the magic numbers 0, 1 and 2 making the code a little clearer and makes it possible for there to be lazy unmounts that don't propagate. Which is what __detach_mounts actually wants for example. Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:08 -04:00
Lukas Czerner	01acccfad3	ext4: make fsync to sync parent dir in no-journal for real this time [ Upstream commit `e12fb97222` ] Previously commit `14ece1028b` added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode. However this does not work in majority of cases, namely: - if the directory has inline data - if the directory is already indexed - if the directory already has at least one block and: - the new entry fits into it - or we've successfully converted it to indexed So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously. I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before. Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well. Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Frank Mayhar <fmayhar@google.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:07 -04:00
Marek Vasut	25a1a0e4bf	rtlwifi: rtl8192cu: Add new device ID [ Upstream commit `9374e7d2fd` ] Add new ID for ASUS N10 WiFi dongle. Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Marek Vasut <marex@denx.de> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:07 -04:00
Larry Finger	036452652b	rtlwifi: rtl8192cu: Add new USB ID [ Upstream commit `2f92b314f4` ] USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:07 -04:00
Christophe Ricard	e2914f4a8c	NFC: st21nfcb: Retry i2c_master_send if it returns a negative value [ Upstream commit `d4a41d10b2` ] i2c_master_send may return many negative values different than -EREMOTEIO. In case an i2c transaction is NACK'ed, on raspberry pi B+ kernel 3.18, -EIO is generated instead. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:06 -04:00
Oleg Nesterov	016177a2f3	ptrace: fix race between ptrace_resume() and wait_task_stopped() [ Upstream commit `b72c186999` ] ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <sys/ptrace.h> #include <pthread.h> #include <assert.h> int pid; void waiter(void arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without `9899d11f65` "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Pavel Labath <labath@google.com> Tested-by: Pavel Labath <labath@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:06 -04:00
Michael Davidson	954f17f76c	fs/binfmt_elf.c: fix bug in loading of PIE binaries [ Upstream commit `a87938b2e2` ] With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by: Michael Davidson <md@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:06 -04:00
Ulrik De Bie	d37d990e81	Input: elantech - fix absolute mode setting on some ASUS laptops [ Upstream commit `bd884149ac` ] On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Cc: stable@vger.kernel.org Reported-and-tested-by: George Moutsopoulos <gmoutso@yahoo.co.uk> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:05 -04:00
Kailang Yang	f42c7734c0	ALSA: hda/realtek - Fix Headphone Mic doesn't recording for ALC256 [ Upstream commit `d32b66668c` ] Switch default pcbeep path to Line in path. Signed-off-by: Kailang Yang <kailang@realtek.com> Tested-by: Hui Wang <hui.wang@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:05 -04:00
David Henningsson	bf78e00928	ALSA: hda - fix "num_steps = 0" error on ALC256 [ Upstream commit `7d1b6e2932` ] The ALC256 does not have a mixer nid at 0x0b, and there's no loopback path (the output pins are directly connected to the DACs). This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)" error (and as a result, problems with amixer/alsamixer). If there's pcbeep functionality, it certainly isn't controlled by setting an amp on 0x0b, so disable beep functionality (at least for now). Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517 Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:05 -04:00
Jo-Philipp Wich	5f54521eb9	ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T450 [ Upstream commit `f2aa111041` ] The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in conjunction with a ThinkPad Ultradock. Signed-off-by: Jo-Philipp Wich <jow@openwrt.org> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:04 -04:00
Michael Gernoth	f44e7673bd	ALSA: emu10k1: don't deadlock in proc-functions [ Upstream commit `91bf0c2dcb` ] The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by: Michael Gernoth <michael@gernoth.net> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:04 -04:00
Yves-Alexis Perez	ef1eaaef22	ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226) [ Upstream commit `c0278669fb` ] This model uses the same dock port as the previous generation. Signed-off-by: Yves-Alexis Perez <corsac@debian.org> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:04 -04:00
Boris Brezillon	ae74ea64cc	clk: at91: usb: propagate rate modification to the parent clk [ Upstream commit `4591243102` ] The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents. This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz). Implement the determinate_rate method and propagate the change rate request to the parent clk. Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Bo Shen <voice.shen@atmel.com> Tested-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:03 -04:00
Felipe Balbi	e04bccabf7	usb: core: hub: use new USB_RESUME_TIMEOUT [ Upstream commit `bbc78c07a5` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:03 -04:00
Felipe Balbi	47e82783bf	usb: host: sl811: use new USB_RESUME_TIMEOUT [ Upstream commit `08debfb13b` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:02 -04:00
Felipe Balbi	4062a4ead1	usb: host: ehci: use new USB_RESUME_TIMEOUT [ Upstream commit `ea16328f80` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:02 -04:00
Felipe Balbi	9f3220454e	usb: host: xhci: use new USB_RESUME_TIMEOUT [ Upstream commit `b9e451885d` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:01 -04:00
Felipe Balbi	f1106b21fb	usb: host: isp116x: use new USB_RESUME_TIMEOUT [ Upstream commit `8c0ae6574c` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:01 -04:00
Felipe Balbi	9e26387b15	usb: host: r8a66597: use new USB_RESUME_TIMEOUT [ Upstream commit `7a606ac297` ] While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong. It also gives a more "stable" expectation to Linux users. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:01 -04:00
Felipe Balbi	90c918c993	usb: host: fotg210: use new USB_RESUME_TIMEOUT [ Upstream commit `7e136bb71a` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:00 -04:00
Felipe Balbi	07431f5334	usb: host: uhci: use new USB_RESUME_TIMEOUT [ Upstream commit `b8fb6f79f7` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:00 -04:00
Felipe Balbi	878b8fafad	usb: host: fusbh200: use new USB_RESUME_TIMEOUT [ Upstream commit `595227db1f` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:12:00 -04:00
Felipe Balbi	250e891f84	usb: host: oxu210hp: use new USB_RESUME_TIMEOUT [ Upstream commit `84c0d178eb` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:59 -04:00
Felipe Balbi	be6bc8bf1c	usb: musb: use new USB_RESUME_TIMEOUT [ Upstream commit `309be23936` ] Make sure we're using the new macro, so our resume signaling will always pass certification. Based on original work by Bin Liu <Bin Liu <b-liu@ti.com>> Cc: Bin Liu <b-liu@ti.com> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:59 -04:00
Felipe Balbi	a7d51bcea4	usb: define a generic USB_RESUME_TIMEOUT macro [ Upstream commit `62f0342de1` ] Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Cc: <stable@vger.kernel.org> # v3.10+ Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:59 -04:00
Axel Lin	8627988cfc	usb: phy: Find the right match in devm_usb_phy_match [ Upstream commit `869aee0f31` ] The res parameter passed to devm_usb_phy_match() is the location where the pointer to the usb_phy is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Fixes: `410219dcd2` ("usb: otg: utils: devres: Add API's to associate a device with the phy") Signed-off-by: Axel Lin <axel.lin@ingics.com> Cc: <stable@vger.kernel.org> # v3.6+ Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:58 -04:00
Felipe Balbi	a7d37b3c14	usb: musb: core: fix TX/RX endpoint order [ Upstream commit `e3c93e1a3f` ] As per Mentor Graphics' documentation, we should always handle TX endpoints before RX endpoints. This patch fixes that error while also updating some hard-to-read comments which were scattered around musb_interrupt(). This patch should be backported as far back as possible since this error has been in the driver since it's conception. Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:58 -04:00
Sebastian Hesselbarth	e9db32eeb4	ARM: dts: dove: Fix uart[23] reg property [ Upstream commit `a74cd13b80` ] Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error. Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:58 -04:00
Charles Keepax	ed4210b61a	ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore [ Upstream commit `4e330ae4ab` ] There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kukjin Kim <kgene@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:58 -04:00
Gregory CLEMENT	5ec2065d79	ARM: mvebu: Disable CPU Idle on Armada 38x [ Upstream commit `548ae94c1c` ] On Armada 38x SoCs, under heavy I/O load, the system hangs when CPU Idle is enabled. Waiting for a solution to this issue, this patch disables the CPU Idle support for this SoC. As CPU Hot plug support also uses some of the CPU Idle functions it is also affected by the same issue. This patch disables it also for the Armada 38x SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.17 + Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:57 -04:00
Andrey Ryabinin	870ee20489	ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE [ Upstream commit `8defb3367f` ] Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is: (2 TASK_SIZE / 3) = 0x2a000000 When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory. Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible. Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y): (TASK_SIZE / 3 * 2) = 0x7f555554 [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Reported-by: Maria Guseva <m.guseva@samsung.com> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:57 -04:00
Russell King	3e98276b95	ARM: fix broken hibernation [ Upstream commit `767bf7e7a1` ] Normally, when a CPU wants to clear a cache line to zero in the external L2 cache, it would generate bus cycles to write each word as it would do with any other data access. However, a Cortex A9 connected to a L2C-310 has a specific feature where the CPU can detect this operation, and signal that it wants to zero an entire cache line. This feature, known as Full Line of Zeros (FLZ), involves a non-standard AXI signalling mechanism which only the L2C-310 can properly interpret. There are separate enable bits in both the L2C-310 and the Cortex A9 - the L2C-310 needs to be enabled and have the FLZ enable bit set in the auxiliary control register before the Cortex A9 has this feature enabled. Unfortunately, the suspend code was not respecting this - it's not obvious from the code: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register / arch_save_image() soft_restart() / turns off FLZ in Cortex A9, and disables L2C / cpu_resume() / restores the Cortex A9 registers, inc auxcr / At this point, we end up with the L2C disabled, but the Cortex A9 with FLZ enabled - which means any memset() or zeroing of a full cache line will fail to take effect. A similar issue exists in the resume path, but it's slightly more complex: swsusp_arch_suspend() cpu_suspend() / saves the Cortex A9 auxiliary control register / arch_save_image() / image with A9 auxcr saved / ... swsusp_arch_resume() call_with_stack() arch_restore_image() / restores image with A9 auxcr saved above / soft_restart() / turns off FLZ in Cortex A9, and disables L2C / cpu_resume() / restores the Cortex A9 registers, inc auxcr */ Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled. There's no need to turn off the L2C in either of these two paths; there are benefits from not doing so - for example, the page copies will be faster with the L2C enabled. Hence, fix this by providing a variant of soft_restart() which can be used without turning the L2 cache controller off, and use it in both of these paths to keep the L2C enabled across the respective resume transitions. Fixes: `8ef418c717` ("ARM: l2c: trial at enabling some Cortex-A9 optimisations") Reported-by: Sean Cross <xobs@kosagi.com> Tested-by: Sean Cross <xobs@kosagi.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:57 -04:00
Andrew Elble	36af79ba9d	NFS: fix BUG() crash in notify_change() with patch to chown_common() [ Upstream commit `c1b8940b42` ] We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS. 1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) `6de0ec00ba` ("VFS: make notify_change pass ATTR_KILL_SID to setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_SID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination. 3.) `27ac0ffeac` ("locks: break delegations on any attribute modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2. 4.) The path that that triggers this is via fs/open.c:chmod_common(). The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr. Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset. There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this. Fixes: `27ac0ffeac` ("locks: break delegations on any attribute modification") Reported-by: Eric Meddaugh <etmsys@rit.edu> Tested-by: Eric Meddaugh <etmsys@rit.edu> Signed-off-by: Andrew Elble <aweits@rit.edu> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:56 -04:00
Krzysztof Kozlowski	3235480139	power_supply: ipaq_micro_battery: Check return values in probe [ Upstream commit `a2c1d53185` ] The return values of create_singlethread_workqueue() and power_supply_register() calls were not checked and even on error probe() function returned 0. 1. If allocation of workqueue failed (returning NULL) then further accesses could lead to NULL pointer dereference. The queue_delayed_work() expects workqueue to be non-NULL. 2. If registration of power supply failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `00a588f9d2` ("power: add driver for battery reading on iPaq h3xxx") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:56 -04:00
Krzysztof Kozlowski	d81418c1cb	power_supply: ipaq_micro_battery: Fix leaking workqueue [ Upstream commit `f852ec461e` ] Driver allocates singlethread workqueue in probe but it is not destroyed during removal. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `00a588f9d2` ("power: add driver for battery reading on iPaq h3xxx") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:56 -04:00
Krzysztof Kozlowski	58aad4043b	power_supply: lp8788-charger: Fix leaked power supply on probe fail [ Upstream commit `a7117f81e8` ] Driver forgot to unregister charger power supply if registering of battery supply failed in probe(). In such case the memory associated with power supply leaked. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `98a2766493` ("power_supply: Add new lp8788 charger driver") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:55 -04:00
Krzysztof Kozlowski	6bc373ff48	power_supply: twl4030_madc: Check return value of power_supply_register [ Upstream commit `68c3ed6fa7` ] The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `da0a00ebc2` ("power: Add twl4030_madc battery driver.") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:55 -04:00
Steven Rostedt	6ec5fc3a83	ring-buffer: Replace this_cpu_() with __this_cpu_() [ Upstream commit `80a9b64e2c` ] It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM. 101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this. The generic version of this_cpu_read() and write() are: #define this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \ }) #define this_cpu_generic_to_op(pcp, val, op) \ do { \ unsigned long flags; \ raw_local_irq_save(flags); \ __this_cpu_ptr(&(pcp)) op val; \ raw_local_irq_restore(flags); \ } while (0) Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations. Paul McKenney stated that __this_cpu_() versions produce much better code on other architectures than this_cpu_() does, if we know that the call is done in a preempt disabled location. I also changed the recursive_unlock() to use two local variables instead of accessing the per_cpu variable twice. Link: http://lkml.kernel.org/r/20150317114411.GE3589@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/20150317104038.312e73d1@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Christoph Lameter <cl@linux.com> Reported-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de> Tested-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:55 -04:00
Krzysztof Kozlowski	ebc00a2053	compal-laptop: Check return value of power_supply_register [ Upstream commit `1915a718b1` ] The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `9be0fcb5ed` ("compal-laptop: add JHL90, battery & hwmon interface") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:55 -04:00
Krzysztof Kozlowski	29037bcf2d	compal-laptop: Fix leaking hwmon device [ Upstream commit `ad774702f1` ] The commit `c2be45f09b` ("compal-laptop: Use devm_hwmon_device_register_with_groups") wanted to change the registering of hwmon device to resource-managed version. It mostly did it except the main thing - it forgot to use devm-like function so the hwmon device leaked after device removal or probe failure. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `c2be45f09b` ("compal-laptop: Use devm_hwmon_device_register_with_groups") Cc: <stable@vger.kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:54 -04:00
Ian Abbott	502e024655	spi: spidev: fix possible arithmetic overflow for multi-transfer message [ Upstream commit `f20fbaad76` ] `spidev_message()` sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value. Thanks to Dan Carpenter for reporting the potential integer overflow. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:54 -04:00
Lucas Stach	2ed82e9e17	spi: imx: read back the RX/TX watermark levels earlier [ Upstream commit `f511ab09df` ] They are used to decide if the controller can do DMA on a buffer of a specific length and thus are needed before any transfer is attempted. This fixes a memory leak where the SPI core uses the drivers can_dma() callback to determine if a buffer needs to be mapped. As the watermark levels aren't correct at that point the driver falsely claims to be able to DMA the buffer when it fact it isn't. After the transfer has been done the core uses the same callback to determine if it needs to unmap the buffers. As the driver now correctly claims to not being able to DMA the buffer the core doesn't attempt to unmap the buffer which leaves the SGT leaking. Fixes: `f62caccd12` (spi: spi-imx: add DMA support) Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:54 -04:00
Chen-Yu Tsai	7c06756c1d	mmc: sunxi: Use devm_reset_control_get_optional() for reset control [ Upstream commit `9e71c589e4` ] The reset control for the sunxi mmc controller is optional. Some newer platforms (sun6i, sun8i, sun9i) have it, while older ones (sun4i, sun5i, sun7i) don't. Use the properly stubbed _optional version so the driver does not fail to compile when RESET_CONTROLLER=n. This patch also adds a check for deferred probing on the reset control. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Cc: <stable@vger.kernel.org> # 3.16+ Acked-by: David Lanzendörfer <david.lanzendoerfer@o2s.ch> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:53 -04:00
Oliver Neukum	cdc0cf5f1f	cdc-wdm: fix endianness bug in debug statements [ Upstream commit `323ece54e0` ] Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by: Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:53 -04:00
NeilBrown	d2c861b700	md/raid0: fix bug with chunksize not a power of 2. [ Upstream commit `47d68979cc` ] Since commit `20d0189b10` in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2. This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch. So restore that first arg before re-using the variable. Reported-by: Joe Landman <joe.landman@gmail.com> Reported-by: Dave Chinner <david@fromorbit.com> Fixes: `20d0189b10` Cc: stable@vger.kernel.org (3.14 and later). Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:53 -04:00
Alistair Strachan	f364a04fb4	staging: android: sync: Fix memory corruption in sync_timeline_signal(). [ Upstream commit `8e43c9c75f` ] The android_fence_release() function checks for active sync points by calling list_empty() on the list head embedded on the sync point. However, it is only valid to use list_empty() on nodes that have been initialized with INIT_LIST_HEAD() or list_del_init(). Because the list entry has likely been removed from the active list by sync_timeline_signal(), there is a good chance that this WARN_ON_ONCE() will be hit due to dangling pointers pointing at freed memory (even though the sync drivers did nothing wrong) and memory corruption will ensue as the list entry is removed for a second time, corrupting the active list. This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y and fences with more than one sync point. Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Colin Cross <ccross@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:52 -04:00
Sudip Mukherjee	fd431a7ce4	staging: panel: fix lcd type [ Upstream commit `2c20d92dad` ] the lcd type as defined in the Kconfig is not matching in the code. as a result the rs, rw and en pins were getting interchanged. Kconfig defines the value of PANEL_LCD to be 1 if we select custom configuration but in the code LCD_TYPE_CUSTOM is defined as 5. my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it as pins of LCD_TYPE_OLD, and it was not working. Now values are corrected with referenece to the values defined in Kconfig and it is working. checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration. Cc: <stable@vger.kernel.org> # 2.6.32+ Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:52 -04:00
Huacai Chen	886b9d665e	MIPS: Hibernate: flush TLB entries earlier [ Upstream commit `a843d00d03` ] We found that TLB mismatch not only happens after kernel resume, but also happens during snapshot restore. So move it to the beginning of swsusp_arch_suspend(). Signed-off-by: Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9621/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:52 -04:00
Huacai Chen	38d99bff82	MIPS: Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction [ Upstream commit `0add9c2f1c` ] HPET irq is routed to i8259 and then to MIPS CPU irq (cascade). After commit `a3e6c1eff5` (MIPS: IRQ: Fix disable_irq on CPU IRQs), if without IRQF_NO_SUSPEND in cascade_irqaction, HPET interrupts will lost during suspend. The result is machine cannot be waken up. Signed-off-by: Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/9528/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:51 -04:00
Markos Chandras	301080ae27	MIPS: asm: asm-eva: Introduce kernel load/store variants [ Upstream commit `60cd7e08e4` ] Introduce new macros for kernel load/store variants which will be used to perform regular kernel space load/store operations in EVA mode. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: <stable@vger.kernel.org> # v3.15+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9500/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:51 -04:00
Markos Chandras	312bc67c17	MIPS: Malta: Detect and fix bad memsize values [ Upstream commit `f7f8aea4b9` ] memsize denotes the amount of RAM we can access from kseg{0,1} and that should be up to 256M. In case the bootloader reports a value higher than that (perhaps reporting all the available RAM) it's best if we fix it ourselves and just warn the user about that. This is usually a problem with the bootloader and/or its environment. [ralf@linux-mips.org: Remove useless parens as suggested bei Sergei. Reformat long pr_warn statement to fit into 80 column limit.] Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: <stable@vger.kernel.org> # v3.15+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9362/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:51 -04:00
James Hogan	00f1187a9c	MIPS: lose_fpu(): Disable FPU when MSA enabled [ Upstream commit `f8483988ca` ] The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the FPU is in use and MSA isn't enabled. This isn't necessarily a problem because KSTK_STATUS(current), the version of CP0_Status stored on the kernel stack on entry from user mode, does always get updated and gets restored when returning to user mode, but I don't think it was intended, and it is inconsistent with the case of only the FPU being in use. Sometimes leaving the FPU enabled may also mask kernel bugs where FPU operations are executed when the FPU might not be enabled. So lets disable the FPU in the MSA case too. Fixes: `33c771ba5c` ("MIPS: save/disable MSA in lose_fpu") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9323/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:51 -04:00
James Hogan	707ff2258e	MIPS: KVM: Handle MSA Disabled exceptions from guest [ Upstream commit `98119ad533` ] Guest user mode can generate a guest MSA Disabled exception on an MSA capable core by simply trying to execute an MSA instruction. Since this exception is unknown to KVM it will be passed on to the guest kernel. However guest Linux kernels prior to v3.15 do not set up an exception handler for the MSA Disabled exception as they don't support any MSA capable cores. This results in a guest OS panic. Since an older processor ID may be being emulated, and MSA support is not advertised to the guest, the correct behaviour is to generate a Reserved Instruction exception in the guest kernel so it can send the guest process an illegal instruction signal (SIGILL), as would happen with a non-MSA-capable core. Fix this as minimally as reasonably possible by preventing kvm_mips_check_privilege() from relaying MSA Disabled exceptions from guest user mode to the guest kernel, and handling the MSA Disabled exception by emulating a Reserved Instruction exception in the guest, via a new handle_msa_disabled() KVM callback. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Gleb Natapov <gleb@kernel.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Cc: <stable@vger.kernel.org> # v3.15+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:50 -04:00
Andre Przywara	e580744e77	KVM: arm/arm64: check IRQ number on userland injection [ Upstream commit `fd1d0ddf2a` ] When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] pgd=00000000f658b003, pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18 [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:50 -04:00
Radim Krčmář	35e1329264	KVM: use slowpath for cross page cached accesses [ Upstream commit `ca3f087472` ] kvm_write_guest_cached() does not mark all written pages as dirty and code comments in kvm_gfn_to_hva_cache_init() talk about NULL memslot with cross page accesses. Fix all the easy way. The check is '<= 1' to have the same result for 'len = 0' cache anywhere in the page. (nr_pages_needed is 0 on page boundary.) Fixes: `8f964525a1` ("KVM: Allow cross page reads and writes from cached translations.") Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Message-Id: <20150408121648.GA3519@potion.brq.redhat.com> Reviewed-by: Wanpeng Li <wanpeng.li@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:49 -04:00
Heiko Carstens	23786453d8	s390/hibernate: fix save and restore of kernel text section [ Upstream commit `d744194956` ] Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system. This means that after a suspend/resume cycle we lost all modifications done to the kernel text section. The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only. We still need to make sure to not save and restore pages contained within NSS and DCSS segment. To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment. Fixes the following crash (and the above bugs as well): Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0 Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc Reported-and-tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:49 -04:00
Jens Freimann	00d83726cc	KVM: s390: fix get_all_floating_irqs [ Upstream commit `94aa033efc` ] This fixes a bug introduced with commit `c05c4186bb` ("KVM: s390: add floating irq controller"). get_all_floating_irqs() does copy_to_user() while holding a spin lock. Let's fix this by filling a temporary buffer first and copy it to userspace after giving up the lock. Cc: <stable@vger.kernel.org> # 3.18+: `69a8d45626` KVM: s390: no need to hold... Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:49 -04:00
Christian Borntraeger	7e15bc0e1c	KVM: s390: no need to hold the kvm->mutex for floating interrupts [ Upstream commit `69a8d45626` ] The kvm mutex was (probably) used to protect against cpu hotplug. The current code no longer needs to protect against that, as we only rely on CPU data structures that are guaranteed to be available if we can access the CPU. (e.g. vcpu_create will put the cpu in the array AFTER the cpu is ready). Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Jens Freimann <jfrei@linux.vnet.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:49 -04:00
Ekaterina Tumanova	abd80ecb36	KVM: s390: Zero out current VMDB of STSI before including level3 data. [ Upstream commit `b75f4c9afa` ] s390 documentation requires words 0 and 10-15 to be reserved and stored as zeros. As we fill out all other fields, we can memset the full structure. Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:48 -04:00
David Hildenbrand	b7c23d30ee	KVM: s390: reinjection of irqs can fail in the tpi handler [ Upstream commit `15462e37ca` ] The reinjection of an I/O interrupt can fail if the list is at the limit and between the dequeue and the reinjection, another I/O interrupt is injected (e.g. if user space floods kvm with I/O interrupts). This patch avoids this memory leak and returns -EFAULT in this special case. This error is not recoverable, so let's fail hard. This can later be avoided by not dequeuing the interrupt but working directly on the locked list. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:48 -04:00
David Hildenbrand	19881aff15	KVM: s390: fix handling of write errors in the tpi handler [ Upstream commit `261520dcfc` ] If the I/O interrupt could not be written to the guest provided area (e.g. access exception), a program exception was injected into the guest but "inti" wasn't freed, therefore resulting in a memory leak. In addition, the I/O interrupt wasn't reinjected. Therefore the dequeued interrupt is lost. This patch fixes the problem while cleaning up the function and making the cc and rc logic easier to handle. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:48 -04:00
Andrzej Pietrasiewicz	67c5b95cdb	usb: gadget: printer: enqueue printer's response for setup request [ Upstream commit `eb132ccbde` ] Function-specific setup requests should be handled in such a way, that apart from filling in the data buffer, the requests are also actually enqueued: if function-specific setup is called from composte_setup(), the "usb_ep_queue()" block of code in composite_setup() is skipped. The printer function lacks this part and it results in e.g. get device id requests failing: the host expects some response, the device prepares it but does not equeue it for sending to the host, so the host finally asserts timeout. This patch adds enqueueing the prepared responses. Cc: <stable@vger.kernel.org> # v3.4+ Fixes: `2e87edf492`: "usb: gadget: make g_printer use composite" Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:47 -04:00
Filipe Manana	43e8149d04	Btrfs: fix inode eviction infinite loop after extent_same ioctl [ Upstream commit HEAD ] commit `113e828386` upstream. If we pass a length of 0 to the extent_same ioctl, we end up locking an extent range with a start offset greater then its end offset (if the destination file's offset is greater than zero). This results in a warning from extent_io.c:insert_state through the following call chain: btrfs_extent_same() btrfs_double_lock() lock_extent_range() lock_extent(inode->io_tree, offset, offset + len - 1) lock_extent_bits() __set_extent_bit() insert_state() --> WARN_ON(end < start) This leads to an infinite loop when evicting the inode. This is the same problem that my previous patch titled "Btrfs: fix inode eviction infinite loop after cloning into it" addressed but for the extent_same ioctl instead of the clone ioctl. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 9dc106617d5669a6f8d86e08f620dc2fb0413e21) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:47 -04:00
Filipe Manana	d5454242a1	Btrfs: fix inode eviction infinite loop after cloning into it [ Upstream commit HEAD ] commit `ccccf3d672` upstream. If we attempt to clone a 0 length region into a file we can end up inserting a range in the inode's extent_io tree with a start offset that is greater then the end offset, which triggers immediately the following warning: [ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3914.620886] BTRFS: end < start 4095 4096 (...) [ 3914.638093] Call Trace: [ 3914.638636] [<ffffffff81425fd9>] dump_stack+0x4c/0x65 [ 3914.639620] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb [ 3914.640789] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs] [ 3914.642041] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48 [ 3914.643236] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs] [ 3914.644441] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3914.645711] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs] [ 3914.646914] [<ffffffff8142b2fb>] ? _raw_spin_unlock+0x28/0x33 [ 3914.648058] [<ffffffffa03cbac4>] ? test_range_bit+0xcc/0xde [btrfs] [ 3914.650105] [<ffffffffa03cb3c3>] lock_extent+0x13/0x15 [btrfs] [ 3914.651361] [<ffffffffa03db39e>] lock_extent_range+0x3d/0xcd [btrfs] [ 3914.652761] [<ffffffffa03de1fe>] btrfs_ioctl_clone+0x278/0x388 [btrfs] [ 3914.654128] [<ffffffff811226dd>] ? might_fault+0x58/0xb5 [ 3914.655320] [<ffffffffa03e0909>] btrfs_ioctl+0xb51/0x2195 [btrfs] (...) [ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]--- This later makes the inode eviction handler enter an infinite loop that keeps dumping the following warning over and over: [ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3915.119913] BTRFS: end < start 4095 4096 (...) [ 3915.137394] Call Trace: [ 3915.137913] [<ffffffff81425fd9>] dump_stack+0x4c/0x65 [ 3915.139154] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb [ 3915.140316] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs] [ 3915.141505] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48 [ 3915.142709] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs] [ 3915.143849] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3915.145120] [<ffffffffa038c1e3>] ? btrfs_kill_super+0x17/0x23 [btrfs] [ 3915.146352] [<ffffffff811548f6>] ? deactivate_locked_super+0x3b/0x50 [ 3915.147565] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs] [ 3915.148785] [<ffffffff8142b7e2>] ? _raw_write_unlock+0x28/0x33 [ 3915.149931] [<ffffffffa03bc325>] btrfs_evict_inode+0x196/0x482 [btrfs] [ 3915.151154] [<ffffffff81168904>] evict+0xa0/0x148 [ 3915.152094] [<ffffffff811689e5>] dispose_list+0x39/0x43 [ 3915.153081] [<ffffffff81169564>] evict_inodes+0xdc/0xeb [ 3915.154062] [<ffffffff81154418>] generic_shutdown_super+0x49/0xef [ 3915.155193] [<ffffffff811546d1>] kill_anon_super+0x13/0x1e [ 3915.156274] [<ffffffffa038c1e3>] btrfs_kill_super+0x17/0x23 [btrfs] (...) [ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]--- So just bail out of the clone ioctl if the length of the region to clone is zero, without locking any extent range, in order to prevent this issue (same behaviour as a pwrite with a 0 length for example). This is trivial to reproduce. For example, the steps for the test I just made for fstests: mkfs.btrfs -f SCRATCH_DEV mount SCRATCH_DEV $SCRATCH_MNT touch $SCRATCH_MNT/foo touch $SCRATCH_MNT/bar $CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar umount $SCRATCH_MNT A test case for fstests follows soon. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 449b46275ce58e1d3fc20d1efacd0d0369c6070f) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:46 -04:00
David Sterba	5728a92403	btrfs: don't accept bare namespace as a valid xattr [ Upstream commit HEAD ] commit `3c3b04d10f` upstream. Due to insufficient check in btrfs_is_valid_xattr, this unexpectedly works: $ touch file $ setfattr -n user. -v 1 file $ getfattr -d file user.="1" ie. the missing attribute name after the namespace. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94291 Reported-by: William Douglas <william.douglas@intel.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 1bb2835ed4f8ee186d8110817cf5a96ef9e35ab3) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:46 -04:00
Filipe Manana	372b2ac593	Btrfs: fix log tree corruption when fs mounted with -o discard [ Upstream commit HEAD ] commit `dcc82f4783` upstream. While committing a transaction we free the log roots before we write the new super block. Freeing the log roots implies marking the disk location of every node/leaf (metadata extent) as pinned before the new super block is written. This is to prevent the disk location of log metadata extents from being reused before the new super block is written, otherwise we would have a corrupted log tree if before the new super block is written a crash/reboot happens and the location of any log tree metadata extent ended up being reused and rewritten. Even though we pinned the log tree's metadata extents, we were issuing a discard against them if the fs was mounted with the -o discard option, resulting in corruption of the log tree if a crash/reboot happened before writing the new super block - the next time the fs was mounted, during the log replay process we would find nodes/leafs of the log btree with a content full of zeroes, causing the process to fail and require the use of the tool btrfs-zero-log to wipeout the log tree (and all data previously fsynced becoming lost forever). Fix this by not doing a discard when pinning an extent. The discard will be done later when it's safe (after the new super block is committed) at extent-tree.c:btrfs_finish_extent_commit(). Fixes: `e688b7252f` (Btrfs: fix extent pinning bugs in the tree log) Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3909e5a93ed64a186a396c1b7fd1db07e065728f) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:46 -04:00
Nadav Amit	753fd54a07	KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save [ Upstream commit HEAD ] commit `9e9c3fe40b` upstream. kvm_init_msr_list is currently called before hardware_setup. As a result, vmx_mpx_supported always returns false when kvm_init_msr_list checks whether to save MSR_IA32_BNDCFGS. Move kvm_init_msr_list after vmx_hardware_setup is called to fix this issue. Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Message-Id: <1428864435-4732-1-git-send-email-namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 702a71cf592282298395b3359f49a9a985182934) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:46 -04:00
Mike Galbraith	6cbb41b186	sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs [ Upstream commit `f8e617f458` ] To fully take advantage of MWAIT, apparently the CLFLUSH instruction needs another quirk on certain CPUs: proper barriers around it on certain machines. On a Q6600 SMP system, pipe-test scheduling performance, cross core, improves significantly: 3.8.13 487.2 KHz 1.000 3.13.0-master 415.5 KHz .852 3.13.0-master+ 415.2 KHz .852 + restore mwait_idle 3.13.0-master++ 488.5 KHz 1.002 + restore mwait_idle + IPI fix Since X86_BUG_CLFLUSH_MONITOR is already a quirk, don't create a separate quirk for the extra smp_mb()s. Signed-off-by: Mike Galbraith <bitbucket@online.de> Cc: <stable@vger.kernel.org> # 3.10+ Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ian Malone <ibmalone@gmail.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Len Brown <len.brown@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1390061684.5566.4.camel@marge.simpson.net [ Ported to recent kernel, added comments about the quirk. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:45 -04:00
Len Brown	560e6448bc	sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance [ Upstream commit `b253149b84` ] In Linux-3.9 we removed the mwait_idle() loop: `69fb3676df` ("x86 idle: remove mwait_idle() and "idle=mwait" cmdline param") The reasoning was that modern machines should be sufficiently happy during the boot process using the default_idle() HALT loop, until cpuidle loads and either acpi_idle or intel_idle invoke the newer MWAIT-with-hints idle loop. But two machines reported problems: 1. Certain Core2-era machines support MWAIT-C1 and HALT only. MWAIT-C1 is preferred for optimal power and performance. But if they support just C1, cpuidle never loads and so they use the boot-time default idle loop forever. 2. Some laptops will boot-hang if HALT is used, but will boot successfully if MWAIT is used. This appears to be a hidden assumption in BIOS SMI, that is presumably valid on the proprietary OS where the BIOS was validated. https://bugzilla.kernel.org/show_bug.cgi?id=60770 So here we effectively revert the patch above, restoring the mwait_idle() loop. However, we don't bother restoring the idle=mwait cmdline parameter, since it appears to add no value. Maintainer notes: For 3.9, simply revert `69fb3676df` for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context For 3.11, 3.12, 3.13, this patch applies cleanly Tested-by: Mike Galbraith <bitbucket@online.de> Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Mike Galbraith <bitbucket@online.de> Cc: <stable@vger.kernel.org> # 3.9+ Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ian Malone <ibmalone@gmail.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/345254a551eb5a6a866e048d7ab570fd2193aca4.1389763084.git.len.brown@intel.com [ Ported to recent kernels. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-17 19:11:45 -04:00
Eric Dumazet	0ff99ba9eb	net: fix crash in build_skb() [ Upstream commit `2ea2f62c8b` ] When I added pfmemalloc support in build_skb(), I forgot netlink was using build_skb() with a vmalloc() area. In this patch I introduce __build_skb() for netlink use, and build_skb() is a wrapper handling both skb->head_frag and skb->pfmemalloc This means netlink no longer has to hack skb->head_frag [ 1567.700067] kernel BUG at arch/x86/mm/physaddr.c:26! [ 1567.700067] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1567.700067] Dumping ftrace buffer: [ 1567.700067] (ftrace buffer empty) [ 1567.700067] Modules linked in: [ 1567.700067] CPU: 9 PID: 16186 Comm: trinity-c182 Not tainted 4.0.0-next-20150424-sasha-00037-g4796e21 #2167 [ 1567.700067] task: ffff880127efb000 ti: ffff880246770000 task.ti: ffff880246770000 [ 1567.700067] RIP: __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3)) [ 1567.700067] RSP: 0018:ffff8802467779d8 EFLAGS: 00010202 [ 1567.700067] RAX: 000041000ed8e000 RBX: ffffc9008ed8e000 RCX: 000000000000002c [ 1567.700067] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffffb3fd6049 [ 1567.700067] RBP: ffff8802467779f8 R08: 0000000000000019 R09: ffff8801d0168000 [ 1567.700067] R10: ffff8801d01680c7 R11: ffffed003a02d019 R12: ffffc9000ed8e000 [ 1567.700067] R13: 0000000000000f40 R14: 0000000000001180 R15: ffffc9000ed8e000 [ 1567.700067] FS: 00007f2a7da3f700(0000) GS:ffff8801d1000000(0000) knlGS:0000000000000000 [ 1567.700067] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1567.700067] CR2: 0000000000738308 CR3: 000000022e329000 CR4: 00000000000007e0 [ 1567.700067] Stack: [ 1567.700067] ffffc9000ed8e000 ffff8801d0168000 ffffc9000ed8e000 ffff8801d0168000 [ 1567.700067] ffff880246777a28 ffffffffad7c0a21 0000000000001080 ffff880246777c08 [ 1567.700067] ffff88060d302e68 ffff880246777b58 ffff880246777b88 ffffffffad9a6821 [ 1567.700067] Call Trace: [ 1567.700067] build_skb (include/linux/mm.h:508 net/core/skbuff.c:316) [ 1567.700067] netlink_sendmsg (net/netlink/af_netlink.c:1633 net/netlink/af_netlink.c:2329) [ 1567.774369] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] sock_sendmsg (net/socket.c:614 net/socket.c:623) [ 1567.774369] sock_write_iter (net/socket.c:823) [ 1567.774369] ? sock_sendmsg (net/socket.c:806) [ 1567.774369] __vfs_write (fs/read_write.c:479 fs/read_write.c:491) [ 1567.774369] ? get_lock_stats (kernel/locking/lockdep.c:249) [ 1567.774369] ? default_llseek (fs/read_write.c:487) [ 1567.774369] ? vtime_account_user (kernel/sched/cputime.c:701) [ 1567.774369] ? rw_verify_area (fs/read_write.c:406 (discriminator 4)) [ 1567.774369] vfs_write (fs/read_write.c:539) [ 1567.774369] SyS_write (fs/read_write.c:586 fs/read_write.c:577) [ 1567.774369] ? SyS_read (fs/read_write.c:577) [ 1567.774369] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1567.774369] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636) [ 1567.774369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42) [ 1567.774369] system_call_fastpath (arch/x86/kernel/entry_64.S:261) Fixes: `79930f5892` ("net: do not deplete pfmemalloc reserve") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:58 -04:00
Eric Dumazet	cfe7befc7d	net: do not deplete pfmemalloc reserve [ Upstream commit `79930f5892` ] build_skb() should look at the page pfmemalloc status. If set, this means page allocator allocated this page in the expectation it would help to free other pages. Networking stack can do that only if skb->pfmemalloc is also set. Also, we must refrain using high order pages from the pfmemalloc reserve, so __page_frag_refill() must also use __GFP_NOMEMALLOC for them. Under memory pressure, using order-0 pages is probably the best strategy. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:58 -04:00
Eric Dumazet	b5635e4539	tcp: avoid looping in tcp_send_fin() [ Upstream commit `845704a535` ] Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets. Lets try a different strategy : In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation. By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory. In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:57 -04:00
Eric Dumazet	2732443ade	tcp: fix possible deadlock in tcp_send_fin() [ Upstream commit `d83769a580` ] Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in case a huge process is killed by OOM, and tcp_mem[2] is hit. To be able to free memory we need to make progress, so this patch allows FIN packets to not care about tcp_mem[2], if skb allocation succeeded. In a follow-up patch, we might abort tcp_send_fin() infinite loop in case TIF_MEMDIE is set on this thread, as memory allocator did its best getting extra memory already. This patch reverts `d22e153718` ("tcp: fix tcp fin memory accounting") Fixes: `d22e153718` ("tcp: fix tcp fin memory accounting") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:56 -04:00
Tom Herbert	93cc442175	ppp: call skb_checksum_complete_unset in ppp_receive_frame [ Upstream commit `3dfb05340e` ] Call checksum_complete_unset in PPP receive to discard checksum-complete value. PPP does not pull checksum for headers and also modifies packet as in VJ compression. Signed-off-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:56 -04:00
Tom Herbert	dc7071483e	net: add skb_checksum_complete_unset [ Upstream commit `4e18b9adf2` ] This function changes ip_summed to CHECKSUM_NONE if CHECKSUM_COMPLETE is set. This is called to discard checksum-complete when packet is being modified and checksum is not pulled for headers in a layer. Signed-off-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:55 -04:00
Sebastian Pöhn	7aca247209	ip_forward: Drop frames with attached skb->sk [ Upstream commit `2ab957492d` ] Initial discussion was: [FYI] xfrm: Don't lookup sk_policy for timewait sockets Forwarded frames should not have a socket attached. Especially tw sockets will lead to panics later-on in the stack. This was observed with TPROXY assigning a tw socket and broken policy routing (misconfigured). As a result frame enters forwarding path instead of input. We cannot solve this in TPROXY as it cannot know that policy routing is broken. v2: Remove useless comment Signed-off-by: Sebastian Poehn <sebastian.poehn@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:55 -04:00
David S. Miller	e13f6f2b39	ipv4: Missing sk_nulls_node_init() in ping_unhash(). [ Upstream commit `a134f083e7` ] If we don't do that, then the poison value is left in the ->pprev backlink. This can cause crashes if we do a disconnect, followed by a connect(). Tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Wen Xu <hotdog3645@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:54 -04:00
Ido Shamay	b64bab57fb	net/mlx4_en: Schedule napi when RX buffers allocation fails [ Upstream commit `07841f9d94` ] When system is out of memory, refilling of RX buffers fails while the driver continue to pass the received packets to the kernel stack. At some point, when all RX buffers deplete, driver may fall into a sleep, and not recover when memory for new RX buffers is once again availible. This is because hardware does not have valid descriptors, so no interrupt will be generated for the driver to return to work in napi context. Fix it by schedule the napi poll function from stats_task delayed workqueue, as long as the allocations fail. Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:53 -04:00
Benjamin Poirier	09f2ece83a	mlx4: Fix tx ring affinity_mask creation [ Upstream commit `42eab005a5` ] By default, the number of tx queues is limited by the number of online cpus in mlx4_en_get_profile(). However, this limit no longer holds after the ethtool .set_channels method has been called. In that situation, the driver may access invalid bits of certain cpumask variables when queue_index >= nr_cpu_ids. Signed-off-by: Benjamin Poirier <bpoirier@suse.de> Acked-by: Ido Shamay <idos@mellanox.com> Fixes: `d03a68f` ("net/mlx4_en: Configure the XPS queue mapping on driver load") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:53 -04:00
Christoffer Dall	5c0ac4b58b	arm/arm64: KVM: Keep elrsr/aisr in sync with software model commit `ae705930fc` upstream. There is an interesting bug in the vgic code, which manifests itself when the KVM run loop has a signal pending or needs a vmid generation rollover after having disabled interrupts but before actually switching to the guest. In this case, we flush the vgic as usual, but we sync back the vgic state and exit to userspace before entering the guest. The consequence is that we will be syncing the list registers back to the software model using the GICH_ELRSR and GICH_EISR from the last execution of the guest, potentially overwriting a list register containing an interrupt. This showed up during migration testing where we would capture a state where the VM has masked the arch timer but there were no interrupts, resulting in a hung test. Cc: Marc Zyngier <marc.zyngier@arm.com> Reported-by: Alex Bennee <alex.bennee@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:37 -04:00
Marc Zyngier	74e0fedea4	arm64: KVM: Do not use pgd_index to index stage-2 pgd commit `04b8dc85bf` upstream. The kernel's pgd_index macro is designed to index a normal, page sized array. KVM is a bit diffferent, as we can use concatenated pages to have a bigger address space (for example 40bit IPA with 4kB pages gives us an 8kB PGD. In the above case, the use of pgd_index will always return an index inside the first 4kB, which makes a guest that has memory above 0x8000000000 rather unhappy, as it spins forever in a page fault, whist the host happilly corrupts the lower pgd. The obvious fix is to get our own kvm_pgd_index that does the right thing(tm). Tested on X-Gene with a hacked kvmtool that put memory at a stupidly high address. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:37 -04:00
Marc Zyngier	354883e3e5	arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting commit `a987370f8e` upstream. We're using __get_free_pages with to allocate the guest's stage-2 PGD. The standard behaviour of this function is to return a set of pages where only the head page has a valid refcount. This behaviour gets us into trouble when we're trying to increment the refcount on a non-head page: page:ffff7c00cfb693c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() page dumped because: VM_BUG_ON_PAGE((({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) )&((&page->_count)->counter); })) <= 0) BUG: failure at include/linux/mm.h:548/get_page()! Kernel panic - not syncing: BUG! CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825 Hardware name: APM X-Gene Mustang board (DT) Call trace: [<ffff80000008a09c>] dump_backtrace+0x0/0x13c [<ffff80000008a1e8>] show_stack+0x10/0x1c [<ffff800000691da8>] dump_stack+0x74/0x94 [<ffff800000690d78>] panic+0x100/0x240 [<ffff8000000a0bc4>] stage2_get_pmd+0x17c/0x2bc [<ffff8000000a1dc4>] kvm_handle_guest_abort+0x4b4/0x6b0 [<ffff8000000a420c>] handle_exit+0x58/0x180 [<ffff80000009e7a4>] kvm_arch_vcpu_ioctl_run+0x114/0x45c [<ffff800000099df4>] kvm_vcpu_ioctl+0x2e0/0x754 [<ffff8000001c0a18>] do_vfs_ioctl+0x424/0x5c8 [<ffff8000001c0bfc>] SyS_ioctl+0x40/0x78 CPU0: stopping A possible approach for this is to split the compound page using split_page() at allocation time, and change the teardown path to free one page at a time. It turns out that alloc_pages_exact() and free_pages_exact() does exactly that. While we're at it, the PGD allocation code is reworked to reduce duplication. This has been tested on an X-Gene platform with a 4kB/48bit-VA host kernel, and kvmtool hacked to place memory in the second page of the hardware PGD (PUD for the host kernel). Also regression-tested on a Cubietruck (Cortex-A7). [ Reworked to use alloc_pages_exact() and free_pages_exact() and to return pointers directly instead of by reference as arguments - Christoffer ] Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:36 -04:00
Jan Kiszka	f10b9c8a2e	ARM: KVM: Fix size check in __coherent_cache_guest_page commit `a050dfb21c` upstream. The check is supposed to catch page-unaligned sizes, not the inverse. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:36 -04:00
Marc Zyngier	a49ecf872e	arm/arm64: KVM: Use kernel mapping to perform invalidation on page fault commit `0d3e4d4fad` upstream. When handling a fault in stage-2, we need to resync I$ and D$, just to be sure we don't leave any old cache line behind. That's very good, except that we do so using the user address. Under heavy load (swapping like crazy), we may end up in a situation where the page gets mapped in stage-2 while being unmapped from userspace by another CPU. At that point, the DC/IC instructions can generate a fault, which we handle with kvm->mmu_lock held. The box quickly deadlocks, user is unhappy. Instead, perform this invalidation through the kernel mapping, which is guaranteed to be present. The box is much happier, and so am I. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:36 -04:00
Marc Zyngier	a412dc06d6	arm/arm64: KVM: Invalidate data cache on unmap commit `363ef89f8e` upstream. Let's assume a guest has created an uncached mapping, and written to that page. Let's also assume that the host uses a cache-coherent IO subsystem. Let's finally assume that the host is under memory pressure and starts to swap things out. Before this "uncached" page is evicted, we need to make sure we invalidate potential speculated, clean cache lines that are sitting there, or the IO subsystem is going to swap out the cached view, loosing the data that has been written directly into memory. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:35 -04:00
Marc Zyngier	cc0c5f43df	arm64: KVM: Fix HCR setting for 32bit guests commit `801f6772ce` upstream. Commit `b856a59141` (arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu) moved the init of the HCR register to happen later in the init of a vcpu, but left out the fixup done in kvm_reset_vcpu when preparing for a 32bit guest. As a result, the 32bit guest is run as a 64bit guest, but the rest of the kernel still manages it as a 32bit. Fun follows. Moving the fixup to vcpu_reset_hcr solves the problem for good. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:35 -04:00
Marc Zyngier	9a73540524	arm64: KVM: Fix TLB invalidation by IPA/VMID commit `55e858b758` upstream. It took about two years for someone to notice that the IPA passed to TLBI IPAS2E1IS must be shifted by 12 bits. Clearly our reviewing is not as good as it should be... Paper bag time for me. Reported-by: Mario Smarduch <m.smarduch@samsung.com> Tested-by: Mario Smarduch <m.smarduch@samsung.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:34 -04:00
Eric Auger	3fca593bd1	KVM: arm/arm64: vgic: vgic_init returns -ENODEV when no online vcpu commit `66b030e48a` upstream. To be more explicit on vgic initialization failure, -ENODEV is returned by vgic_init when no online vcpus can be found at init. Signed-off-by: Eric Auger <eric.auger@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:34 -04:00
Christoffer Dall	765420c335	arm/arm64: KVM: Require in-kernel vgic for the arch timers commit `05971120fc` upstream. It is curently possible to run a VM with architected timers support without creating an in-kernel VGIC, which will result in interrupts from the virtual timer going nowhere. To address this issue, move the architected timers initialization to the time when we run a VCPU for the first time, and then only initialize (and enable) the architected timers if we have a properly created and initialized in-kernel VGIC. When injecting interrupts from the virtual timer to the vgic, the current setup should ensure that this never calls an on-demand init of the VGIC, which is the only call path that could return an error from kvm_vgic_inject_irq(), so capture the return value and raise a warning if there's an error there. We also change the kvm_timer_init() function from returning an int to be a void function, since the function always succeeds. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:34 -04:00
Christoffer Dall	11d483cec8	arm/arm64: KVM: Initialize the vgic on-demand when injecting IRQs commit `ca7d9c829d` upstream. Userspace assumes that it can wire up IRQ injections after having created all VCPUs and after having created the VGIC, but potentially before starting the first VCPU. This can currently lead to lost IRQs because the state of that IRQ injection is not stored anywhere and we don't return an error to userspace. We haven't seen this problem manifest itself yet, presumably because guests reset the devices on boot, but this could cause issues with migration and other non-standard startup configurations. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:34 -04:00
Shannon Zhao	d4d53f72fa	arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through all commit `016ed39c54` upstream. When call kvm_vgic_inject_irq to inject interrupt, we can known which vcpu the interrupt for by the irq_num and the cpuid. So we should just kick this vcpu to avoid iterating through all. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:33 -04:00
Christoffer Dall	c0a5bdaba1	arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized commit `716139df25` upstream. When the vgic initializes its internal state it does so based on the number of VCPUs available at the time. If we allow KVM to create more VCPUs after the VGIC has been initialized, we are likely to error out in unfortunate ways later, perform buffer overflows etc. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Eric Auger <eric.auger@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:33 -04:00
Peter Maydell	2da33f7dca	arm/arm64: KVM: vgic: move reset initialization into vgic_init_maps() commit `6d3cfbe21b` upstream. VGIC initialization currently happens in three phases: (1) kvm_vgic_create() (triggered by userspace GIC creation) (2) vgic_init_maps() (triggered by userspace GIC register read/write requests, or from kvm_vgic_init() if not already run) (3) kvm_vgic_init() (triggered by first VM run) We were doing initialization of some state to correspond with the state of a freshly-reset GIC in kvm_vgic_init(); this is too late, since it will overwrite changes made by userspace using the register access APIs before the VM is run. Move this initialization earlier, into the vgic_init_maps() phase. This fixes a bug where QEMU could successfully restore a saved VM state snapshot into a VM that had already been run, but could not restore it "from cold" using the -loadvm command line option (the symptoms being that the restored VM would run but interrupts were ignored). Finally rename vgic_init_maps to vgic_init and renamed kvm_vgic_init to kvm_vgic_map_resources. [ This patch is originally written by Peter Maydell, but I have modified it somewhat heavily, renaming various bits and moving code around. If something is broken, I am to be blamed. - Christoffer ] Acked-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Eric Auger <eric.auger@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:33 -04:00
Christoffer Dall	63d4dc9ea3	arm/arm64: KVM: Introduce stage2_unmap_vm commit `957db105c9` upstream. Introduce a new function to unmap user RAM regions in the stage2 page tables. This is needed on reboot (or when the guest turns off the MMU) to ensure we fault in pages again and make the dcache, RAM, and icache coherent. Using unmap_stage2_range for the whole guest physical range does not work, because that unmaps IO regions (such as the GIC) which will not be recreated or in the best case faulted in on a page-by-page basis. Call this function on secondary and subsequent calls to the KVM_ARM_VCPU_INIT ioctl so that a reset VCPU will detect the guest Stage-1 MMU is off when faulting in pages and make the caches coherent. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:32 -04:00
Christoffer Dall	964cce8df8	arm/arm64: KVM: Turn off vcpus on PSCI shutdown/reboot commit `cf5d318865` upstream. When a vcpu calls SYSTEM_OFF or SYSTEM_RESET with PSCI v0.2, the vcpus should really be turned off for the VM adhering to the suggestions in the PSCI spec, and it's the sane thing to do. Also, clarify the behavior and expectations for exits to user space with the KVM_EXIT_SYSTEM_EVENT case. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:32 -04:00
Christoffer Dall	e8234528bd	arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu commit `b856a59141` upstream. When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also reset the HCR, because we now modify the HCR dynamically to enable/disable trapping of guest accesses to the VM registers. This is crucial for reboot of VMs working since otherwise we will not be doing the necessary cache maintenance operations when faulting in pages with the guest MMU off. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:32 -04:00
Christoffer Dall	2421dbc19a	arm/arm64: KVM: Correct KVM_ARM_VCPU_INIT power off option commit `3ad8b3de52` upstream. The implementation of KVM_ARM_VCPU_INIT is currently not doing what userspace expects, namely making sure that a vcpu which may have been turned off using PSCI is returned to its initial state, which would be powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag. Implement the expected functionality and clarify the ABI. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:31 -04:00
Christoffer Dall	04329bd399	arm/arm64: KVM: Don't clear the VCPU_POWER_OFF flag commit `03f1d4c17e` upstream. If a VCPU was originally started with power off (typically to be brought up by PSCI in SMP configurations), there is no need to clear the POWER_OFF flag in the kernel, as this flag is only tested during the init ioctl itself. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:31 -04:00
Ard Biesheuvel	cd7b8af485	arm, arm64: KVM: handle potential incoherency of readonly memslots commit `849260c72c` upstream. Readonly memslots are often used to implement emulation of ROMs and NOR flashes, in which case the guest may legally map these regions as uncached. To deal with the incoherency associated with uncached guest mappings, treat all readonly memslots as incoherent, and ensure that pages that belong to regions tagged as such are flushed to DRAM before being passed to the guest. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:30 -04:00
Laszlo Ersek	4529fdd323	arm, arm64: KVM: allow forced dcache flush on page faults commit `840f4bfbe0` upstream. To allow handling of incoherent memslots in a subsequent patch, this patch adds a paramater 'ipa_uncached' to cache_coherent_guest_page() so that we can instruct it to flush the page's contents to DRAM even if the guest has caching globally enabled. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:30 -04:00
Ard Biesheuvel	02f88a7f2a	kvm: add a memslot flag for incoherent memory regions commit `1050dcda30` upstream. Memory regions may be incoherent with the caches, typically when the guest has mapped a host system RAM backed memory region as uncached. Add a flag KVM_MEMSLOT_INCOHERENT so that we can tag these memslots and handle them appropriately when mapping them. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-11 07:07:30 -04:00
Sasha Levin	72d391fefc	Linux 3.18.13 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-05-05 12:39:05 -04:00
Naoya Horiguchi	ad93155538	mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page() [ Upstream commit `9ab3b598d2` ] A race condition starts to be visible in recent mmotm, where a PG_hwpoison flag is set on a migration source page before it's back in buddy page poo= l. This is problematic because no page flag is supposed to be set when freeing (see __free_one_page().) So the user-visible effect of this race is that it could trigger the BUG_ON() when soft-offlining is called. The root cause is that we call lru_add_drain_all() to make sure that the page is in buddy, but that doesn't work because this function just schedule= s a work item and doesn't wait its completion. drain_all_pages() does drainin= g directly, so simply dropping lru_add_drain_all() solves this problem. Fixes: `f15bdfa802` ("mm/memory-failure.c: fix memory leak in successful soft offlining") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Chen Gong <gong.chen@linux.intel.com> Cc: <stable@vger.kernel.org> [3.11+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-28 10:48:53 -04:00
Janne Heikkinen	3e16c7f2f0	Bluetooth: Add USB device 04ca:3010 as Atheros AR3012 [ Upstream commit `134d3b3550` ] Asus X553MA has USB device 04ca:3010 that is Atheros AR3012 or compatible. Device from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3010 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Janne Heikkinen <janne.m.heikkinen@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-28 10:48:45 -04:00
Anantha Krishnan	6a64bf941b	Bluetooth: Add support for Acer [0489:e078] [ Upstream commit `4b552bc9ed` ] Add support for the QCA6174 chip. T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e078 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Anantha Krishnan <ananthk@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-28 10:47:26 -04:00
Marcel Holtmann	d94e38ae7d	Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard [ Upstream commit `c2aef6e8cb` ] The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth controller on the USB bus. However vendor and product ID are listed as ASUSTek Computer. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17cf Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=54271E910064 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Reported-by: Jerome Leclanche <jerome@leclan.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-28 10:47:00 -04:00
Jeremiah Mahler	33c9cfd8cb	usb: serial: silence all non-critical read errors [ Upstream commit `aa8e22128b` ] If a USB serial device is unplugged while there is an active program using the device it may spam the logs with -EPROTO (71) messages as it attempts to retry. Most serial usb drivers (metro-usb, pl2303, mos7840, ...) only output these messages for debugging. The generic driver treats these as errors. Change the default output for the generic serial driver from error to debug to silence these non-critical errors. Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:47 -04:00
Bo Yan	2ca6349bd0	arm64: fix midr range for Cortex-A57 erratum 832075 Register MIDR_EL1 is masked to get variant and revision fields, then compared against midr_range_min and midr_range_max when checking whether CPU is affected by any particular erratum. However, variant and revision fields in MIDR_EL1 are separated by 16 bits, so the min and max of midr range should be constructed accordingly, otherwise the patch will not be applied when variant field is non-0. Acked-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Bo Yan <byan@nvidia.com> [will: use MIDR_VARIANT_SHIFT to construct upper bound] Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `6d1966dfd6`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:47 -04:00
Will Deacon	5430a02112	arm64: errata: add workaround for cortex-a53 erratum #845719 When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data. This patch works around the issue by writing to the contextidr_el1 register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `905e8c5dca`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:46 -04:00
Andre Przywara	62ef31e125	arm64: protect alternatives workarounds with Kconfig options Not all of the errata we have workarounds for apply necessarily to all SoCs, so people compiling a kernel for one very specific SoC may not need to patch the kernel. Introduce a new submenu in the "Platform selection" menu to allow people to turn off certain bugs if they are not affected. By default all of them are enabled. Normal users or distribution kernels shouldn't bother to deselect any bugs here, since the alternatives framework will take care of patching them in only if needed. Signed-off-by: Andre Przywara <andre.przywara@arm.com> [will: moved kconfig menu under `Kernel Features'] Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `c0a01b84b1`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:46 -04:00
Andre Przywara	e51ce83faf	arm64: add Cortex-A57 erratum 832075 workaround The ARM erratum 832075 applies to certain revisions of Cortex-A57, one of the workarounds is to change device loads into using load-aquire semantics. This is achieved using the alternatives framework. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `5afaa1fc1b`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:45 -04:00
Andre Przywara	4d817d3de6	arm64: add Cortex-A53 cache errata workaround The ARM errata 819472, 826319, 827319 and 824069 define the same workaround for these hardware issues in certain Cortex-A53 parts. Use the new alternatives framework and the CPU MIDR detection to patch "cache clean" into "cache clean and invalidate" instructions if an affected CPU is detected at runtime. Signed-off-by: Andre Przywara <andre.przywara@arm.com> [will: add __maybe_unused to squash gcc warning] Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `301bcfac42`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:45 -04:00
Andre Przywara	da767e54e3	arm64: detect silicon revisions and set cap bits accordingly After each CPU has been started, we iterate through a list of CPU features or bugs to detect CPUs which need (or could benefit from) kernel code patches. For each feature/bug there is a function which checks if that particular CPU is affected. We will later provide some more generic functions for common things like testing for certain MIDR ranges. We do this for every CPU to cover big.LITTLE systems properly as well. If a certain feature/bug has been detected, the capability bit will be set, so that later the call to apply_alternatives() will trigger the actual code patching. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `e116a37542`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:44 -04:00
Andre Przywara	6a5a8112e8	arm64: add alternative runtime patching With a blatant copy of some x86 bits we introduce the alternative runtime patching "framework" to arm64. This is quite basic for now and we only provide the functions we need at this time. This is connected to the newly introduced feature bits. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `e039ee4ee3`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:43 -04:00
Andre Przywara	9a21c96c46	arm64: add cpu_capabilities bitmap For taking note if at least one CPU in the system needs a bug workaround or would benefit from a code optimization, we create a new bitmap to hold (artificial) feature bits. Since elf_hwcap is part of the userland ABI, we keep it alone and introduce a new data structure for that (along with some accessors). Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> # v3.18.y (cherry picked from commit `930da09f5e`) Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:43 -04:00
$Jun'ichi Nomura \\\$NEC\\\$$ Jun'ichi Nomura \\\$NEC\\\$	dd69034328	tg3: Hold tp->lock before calling tg3_halt() from tg3_init_one() [ Upstream commit `d0af71a357` ] tg3_init_one() calls tg3_halt() without tp->lock despite its assumption and causes deadlock. If lockdep is enabled, a warning like this shows up before the stall: [ BUG: bad unlock balance detected! ] 3.19.0test #3 Tainted: G E ------------------------------------- insmod/369 is trying to release lock (&(&tp->lock)->rlock) at: [<ffffffffa02d5a1d>] tg3_chip_reset+0x14d/0x780 [tg3] but there are no more locks to release! tg3_init_one() doesn't call tg3_halt() under normal situation but during kexec kdump I hit this problem. Fixes: `932f19de` ("tg3: Release tp->lock before invoking synchronize_irq()") Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:42 -04:00
Ben Hutchings	e083cde25c	usbnet: Fix tx_bytes statistic running backward in cdc_ncm [ Upstream commit `7a1e890e21` ] cdc_ncm disagrees with usbnet about how much framing overhead should be counted in the tx_bytes statistics, and tries 'fix' this by decrementing tx_bytes on the transmit path. But statistics must never be decremented except due to roll-over; this will thoroughly confuse user-space. Also, tx_bytes is only incremented by usbnet in the completion path. Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a tx_bytes delta along with the tx_packets count. Fixes: `beeecd42c3` ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics") Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:42 -04:00
Ben Hutchings	d0f6e5cf80	usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers [ Upstream commit `1e9e39f4a2` ] Currently the usbnet core does not update the tx_packets statistic for drivers with FLAG_MULTI_PACKET and there is no hook in the TX completion path where they could do this. cdc_ncm and dependent drivers are bumping tx_packets stat on the transmit path while asix and sr9800 aren't updating it at all. Add a packet count in struct skb_data so these drivers can fill it in, initialise it to 1 for other drivers, and add the packet count to the tx_packets statistic on completion. Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:41 -04:00
Jesse Gross	218aa70e49	udptunnels: Call handle_offloads after inserting vlan tag. [ Upstream commit `b736a623bd` ] handle_offloads() calls skb_reset_inner_headers() to store the layer pointers to the encapsulated packet. However, we currently push the vlag tag (if there is one) onto the packet afterwards. This changes the MAC header for the encapsulated packet but it is not reflected in skb->inner_mac_header, which breaks GSO and drivers which attempt to use this for encapsulation offloads. Fixes: `1eaa8178` ("vxlan: Add tx-vlan offload support.") Signed-off-by: Jesse Gross <jesse@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 17:13:41 -04:00
Pravin B Shelar	754a19948e	vxlan: Fix double free of skb. [ Upstream commit `74f47278cb` ] In case of error vxlan_xmit_one() can free already freed skb. Also fixes memory leak of dst-entry. Fixes: `acbf74a763` ("vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions"). Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:35 -04:00
Jiri Pirko	a67e2e8834	vlan: introduce *vlan_hwaccel_push_inside helpers [ Upstream commit `5968250c86` ] Use them to push skb->vlan_tci into the payload and avoid code duplication. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:34 -04:00
Jiri Pirko	d329729a26	vlan: rename __vlan_put_tag to vlan_insert_tag_set_proto [ Upstream commit `62749e2cb3` ] Name fits better. Plus there's going to be introduced __vlan_insert_tag later on. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:33 -04:00
Jiri Pirko	c01a1cb684	vlan: kill vlan_put_tag helper [ Upstream commit `b4bef1b575` ] Since both tx and rx paths work with skb->vlan_tci, there's no need for this function anymore. Switch users directly to __vlan_hwaccel_put_tag. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:33 -04:00
Herbert Xu	ca7c7b9059	skbuff: Do not scrub skb mark within the same name space [ Upstream commit `213dd74aee` ] On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote: > Le 15/04/2015 15:57, Herbert Xu a écrit : > >On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote: > [snip] > >Subject: skbuff: Do not scrub skb mark within the same name space > > > >The commit `ea23192e8e` ("tunnels: > Maybe add a Fixes tag? > Fixes: `ea23192e8e` ("tunnels: harmonize cleanup done on skb on rx path") > > >harmonize cleanup done on skb on rx path") broke anyone trying to > >use netfilter marking across IPv4 tunnels. While most of the > >fields that are cleared by skb_scrub_packet don't matter, the > >netfilter mark must be preserved. > > > >This patch rearranges skb_scurb_packet to preserve the mark field. > nit: s/scurb/scrub > > Else it's fine for me. Sure. PS I used the wrong email for James the first time around. So let me repeat the question here. Should secmark be preserved or cleared across tunnels within the same name space? In fact, do our security models even support name spaces? ---8<--- The commit `ea23192e8e` ("tunnels: harmonize cleanup done on skb on rx path") broke anyone trying to use netfilter marking across IPv4 tunnels. While most of the fields that are cleared by skb_scrub_packet don't matter, the netfilter mark must be preserved. This patch rearranges skb_scrub_packet to preserve the mark field. Fixes: `ea23192e8e` ("tunnels: harmonize cleanup done on skb on rx path") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:32 -04:00
Herbert Xu	efca6fa3f9	Revert "net: Reset secmark when scrubbing packet" [ Upstream commit `4c0ee414e8` ] This patch reverts commit `b8fb4e0648` because the secmark must be preserved even when a packet crosses namespace boundaries. The reason is that security labels apply to the system as a whole and is not per-namespace. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:31 -04:00
Alexei Starovoitov	6ee16f4a03	bpf: fix verifier memory corruption [ Upstream commit `c3de6317d7` ] Due to missing bounds check the DAG pass of the BPF verifier can corrupt the memory which can cause random crashes during program loading: [8.449451] BUG: unable to handle kernel paging request at ffffffffffffffff [8.451293] IP: [<ffffffff811de33d>] kmem_cache_alloc_trace+0x8d/0x2f0 [8.452329] Oops: 0000 [#1] SMP [8.452329] Call Trace: [8.452329] [<ffffffff8116cc82>] bpf_check+0x852/0x2000 [8.452329] [<ffffffff8116b7e4>] bpf_prog_load+0x1e4/0x310 [8.452329] [<ffffffff811b190f>] ? might_fault+0x5f/0xb0 [8.452329] [<ffffffff8116c206>] SyS_bpf+0x806/0xa30 Fixes: `f1bca824da` ("bpf: add search pruning optimization to verifier") Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:31 -04:00
Eric Dumazet	0a50f4197f	bnx2x: Fix busy_poll vs netpoll [ Upstream commit `074975d037` ] Commit `9a2620c877` ("bnx2x: prevent WARN during driver unload") switched the napi/busy_lock locking mechanism from spin_lock() into spin_lock_bh(), breaking inter-operability with netconsole, as netpoll disables interrupts prior to calling our napi mechanism. This switches the driver into using atomic assignments instead of the spinlock mechanisms previously employed. Based on initial patch from Yuval Mintz & Ariel Elior I basically added softirq starvation avoidance, and mixture of atomic operations, plain writes and barriers. Note this slightly reduces the overhead for this driver when no busy_poll sockets are in use. Fixes: `9a2620c877` ("bnx2x: prevent WARN during driver unload") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:30 -04:00
Eric Dumazet	73b4de2b9d	tcp: tcp_make_synack() should clear skb->tstamp [ Upstream commit `b50edd7812` ] I noticed tcpdump was giving funky timestamps for locally generated SYNACK messages on loopback interface. 11:42:46.938990 IP 127.0.0.1.48245 > 127.0.0.2.23850: S 945476042:945476042(0) win 43690 <mss 65495,nop,nop,sackOK,nop,wscale 7> 20:28:58.502209 IP 127.0.0.2.23850 > 127.0.0.1.48245: S 3160535375:3160535375(0) ack 945476043 win 43690 <mss 65495,nop,nop,sackOK,nop,wscale 7> This is because we need to clear skb->tstamp before entering lower stack, otherwise net_timestamp_check() does not set skb->tstamp. Fixes: `7faee5c0d5` ("tcp: remove TCP_SKB_CB(skb)->when") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:29 -04:00
Jack Morgenstein	eea274fd0d	net/mlx4_core: Fix error message deprecation for ConnectX-2 cards [ Upstream commit `fde913e254` ] Commit `1daa4303b4` ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") did the deprecation only for port 1 of the card. Need to deprecate for port 2 as well. Fixes: `1daa4303b4` ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:29 -04:00
hannes@stressinduktion.org	c8c30b2b17	ipv6: protect skb->sk accesses from recursive dereference inside the stack [ Upstream commit `f60e5990d9` ] We should not consult skb->sk for output decisions in xmit recursion levels > 0 in the stack. Otherwise local socket settings could influence the result of e.g. tunnel encapsulation process. ipv6 does not conform with this in three places: 1) ip6_fragment: we do consult ipv6_npinfo for frag_size 2) sk_mc_loop in ipv6 uses skb->sk and checks if we should loop the packet back to the local socket 3) ip6_skb_dst_mtu could query the settings from the user socket and force a wrong MTU Furthermore: In sk_mc_loop we could potentially land in WARN_ON(1) if we use a PF_PACKET socket ontop of an IPv6-backed vxlan device. Reuse xmit_recursion as we are currently only interested in protecting tunnel devices. Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:28 -04:00
Neal Cardwell	6ef8d55c80	tcp: fix FRTO undo on cumulative ACK of SACKed range [ Upstream commit `666b805150` ] On processing cumulative ACKs, the FRTO code was not checking the SACKed bit, meaning that there could be a spurious FRTO undo on a cumulative ACK of a previously SACKed skb. The FRTO code should only consider a cumulative ACK to indicate that an original/unretransmitted skb is newly ACKed if the skb was not yet SACKed. The effect of the spurious FRTO undo would typically be to make the connection think that all previously-sent packets were in flight when they really weren't, leading to a stall and an RTO. Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Fixes: `e33099f96d` ("tcp: implement RFC5682 F-RTO") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:27 -04:00
Jonathan Davies	01c30913ab	xen-netfront: transmit fully GSO-sized packets [ Upstream commit `0c36820e2a` ] xen-netfront limits transmitted skbs to be at most 44 segments in size. However, GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448 bytes each. This slight reduction in the size of packets means a slight loss in efficiency. Since c/s `9ecd1a75d`, xen-netfront sets gso_max_size to XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER, where XEN_NETIF_MAX_TX_SIZE is 65535 bytes. The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s `6c09fa09d`) in determining when to split an skb into two is sk->sk_gso_max_size - 1 - MAX_TCP_HEADER. So the maximum permitted size of an skb is calculated to be (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER. Intuitively, this looks like the wrong formula -- we don't need two TCP headers. Instead, there is no need to deviate from the default gso_max_size of 65536 as this already accommodates the size of the header. Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments of 1448 bytes each), as observed via tcpdump. This patch makes netfront send skbs of up to 65160 bytes (45 segments of 1448 bytes each). Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as it relates to the size of the whole packet, including the header. Fixes: `9ecd1a75d9` ("xen-netfront: reduce gso_max_size to account for max TCP header") Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:27 -04:00
Anton Nayshtut	98ec7a5e47	bonding: Bonding Overriding Configuration logic restored. [ Upstream commit `f5e2dc5d7f` ] Before commit `3900f29021` ("bonding: slight optimizztion for bond_slave_override()") the override logic was to send packets with non-zero queue_id through the slave with corresponding queue_id, under two conditions only - if the slave can transmit and it's up. The above mentioned commit changed this logic by introducing an additional condition - whether the bond is active (indirectly, using the slave_can_tx and later - bond_is_active_slave), that prevents the user from implementing more complex policies according to the Documentation/networking/bonding.txt. Signed-off-by: Anton Nayshtut <anton@swortex.com> Signed-off-by: Alexey Bogoslavsky <alexey@swortex.com> Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:26 -04:00
Alexey Kodanev	65b7ff47a7	net: tcp6: fix double call of tcp_v6_fill_cb() [ Upstream commit `4ad19de877` ] tcp_v6_fill_cb() will be called twice if socket's state changes from TCP_TIME_WAIT to TCP_LISTEN. That can result in control buffer data corruption because in the second tcp_v6_fill_cb() call it's not copying IP6CB(skb) anymore, but 'seq', 'end_seq', etc., so we can get weird and unpredictable results. Performance loss of up to 1200% has been observed in LTP/vxlan03 test. This can be fixed by copying inet6_skb_parm to the beginning of 'cb' only if xfrm6_policy_check() and tcp_v6_fill_cb() are going to be called again. Fixes: `2dc49d1680` ("tcp6: don't move IP6CB before xfrm6_policy_check()") Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:25 -04:00
D.S. Ljungmark	c85b2d7e9f	ipv6: Don't reduce hop limit for an interface [ Upstream commit `6fd99094de` ] A local route may have a lower hop_limit set than global routes do. RFC 3756, Section 4.2.7, "Parameter Spoofing" > 1. The attacker includes a Current Hop Limit of one or another small > number which the attacker knows will cause legitimate packets to > be dropped before they reach their destination. > As an example, one possible approach to mitigate this threat is to > ignore very small hop limits. The nodes could implement a > configurable minimum hop limit, and ignore attempts to set it below > said limit. Signed-off-by: D.S. Ljungmark <ljungmark@modio.se> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:25 -04:00
Ido Shamay	e1a2b75979	net/mlx4_en: Call register_netdevice in the proper location [ Upstream commit `e5eda89d97` ] Netdevice registration should be performed a the end of the driver initialization flow. If we don't do that, after calling register_netdevice, device callbacks may be issued by higher layers of the stack before final configuration of the device is done. For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued after the register_netdev command. System network scripts may configure the interface (UP) right after the registration, which also attach unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called, causing the firmware to fail the rule attachment. Fixes: `837052d0cc` ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling") Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:24 -04:00
Michal Kubeček	b9a91574ad	tcp: prevent fetching dst twice in early demux code [ Upstream commit `d0c294c53a` ] On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux() struct dst_entry *dst = sk->sk_rx_dst; if (dst) dst = dst_check(dst, inet6_sk(sk)->rx_dst_cookie); to code reading sk->sk_rx_dst twice, once for the test and once for the argument of ip6_dst_check() (dst_check() is inline). This allows ip6_dst_check() to be called with null first argument, causing a crash. Protect sk->sk_rx_dst access by READ_ONCE() both in IPv4 and IPv6 TCP early demux code. Fixes: `41063e9dd1` ("ipv4: Early TCP socket demux.") Fixes: `c7109986db` ("ipv6: Early TCP socket demux") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:23 -04:00
Christian Borntraeger	1ba15e1085	kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val) [ Upstream commit `43239cbe79` ] Feedback has shown that WRITE_ONCE(x, val) is easier to use than ASSIGN_ONCE(val,x). There are no in-tree users yet, so lets change it for 3.19. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-27 16:48:19 -04:00
Christian Borntraeger	63787890ec	kernel: Provide READ_ONCE and ASSIGN_ONCE [ Upstream commit `230fa253df` ] ACCESS_ONCE does not work reliably on non-scalar types. For example gcc 4.6 and 4.7 might remove the volatile tag for such accesses during the SRA (scalar replacement of aggregates) step https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145) Let's provide READ_ONCE/ASSIGN_ONCE that will do all accesses via scalar types as suggested by Linus Torvalds. Accesses larger than the machines word size cannot be guaranteed to be atomic. These macros will use memcpy and emit a build warning. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-26 23:02:56 -04:00
Igor Mammedov	b94e91cc22	kvm: avoid page allocation failure in kvm_set_memory_region() [ Upstream commit `744961341d` ] KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order:4, mode:0x40d0 Call Trace: dump_stack+0x47/0x67 warn_alloc_failed+0xee/0x150 __alloc_pages_direct_compact+0x14a/0x150 __alloc_pages_nodemask+0x776/0xb80 alloc_kmem_pages+0x3a/0x110 kmalloc_order+0x13/0x50 kmemdup+0x1b/0x40 __kvm_set_memory_region+0x24a/0x9f0 [kvm] kvm_set_ioapic+0x130/0x130 [kvm] kvm_set_memory_region+0x21/0x40 [kvm] kvm_vm_ioctl+0x43f/0x750 [kvm] Failure happens when attempting to allocate pages for 'struct kvm_memslots', however it doesn't have to be present in physically contiguous (kmalloc-ed) address space, change allocation to kvm_kvzalloc() so that it will be vmalloc-ed when its size is more then a page. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:14 -04:00
Dave Chinner	48ca7d78ff	xfs: ensure truncate forces zeroed blocks to disk [ Upstream commit `5885ebda87` ] A new fsync vs power fail test in xfstests indicated that XFS can have unreliable data consistency when doing extending truncates that require block zeroing. The blocks beyond EOF get zeroed in memory, but we never force those changes to disk before we run the transaction that extends the file size and exposes those blocks to userspace. This can result in the blocks not being correctly zeroed after a crash. Because in-memory behaviour is correct, tools like fsx don't pick up any coherency problems - it's not until the filesystem is shutdown or the system crashes after writing the truncate transaction to the journal but before the zeroed data in the page cache is flushed that the issue is exposed. Fix this by also flushing the dirty data in memory region between the old size and new size when we've found blocks that need zeroing in the truncate process. Reported-by: Liu Bo <bo.li.liu@oracle.com> cc: <stable@vger.kernel.org> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:13 -04:00
Omar Sandoval	a699573622	ext4: fix indirect punch hole corruption [ Upstream commit `6f30b7e37a` ] Commit `4f579ae7de` (ext4: fix punch hole on files with indirect mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect mapping. However, there are bugs in several corner cases. This fixes 5 distinct bugs: 1. When there is at least one entire level of indirection between the start and end of the punch range and the end of the punch range is the first block of its level, we can't return early; we have to free the intervening levels. 2. When the end is at a higher level of indirection than the start and ext4_find_shared returns a top branch for the end, we still need to free the rest of the shared branch it returns; we can't decrement partial2. 3. When a punch happens within one level of indirection, we need to converge on an indirect block that contains the start and end. However, because the branches returned from ext4_find_shared do not necessarily start at the same level (e.g., the partial2 chain will be shallower if the last block occurs at the beginning of an indirect group), the walk of the two chains can end up "missing" each other and freeing a bunch of extra blocks in the process. This mismatch can be handled by first making sure that the chains are at the same level, then walking them together until they converge. 4. When the punch happens within one level of indirection and ext4_find_shared returns a top branch for the start, we must free it, but only if the end does not occur within that branch. 5. When the punch happens within one level of indirection and ext4_find_shared returns a top branch for the end, then we shouldn't free the block referenced by the end of the returned chain (this mirrors the different levels case). Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:13 -04:00
Preeti U Murthy	b27b4b79d5	timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop [ Upstream commit `a127d2bcf1` ] The hrtimer mode of broadcast queues hrtimers in the idle entry path so as to wakeup cpus in deep idle states. The associated call graph is : cpuidle_idle_call() \|____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....)) \|_____tick_broadcast_set_event() \|____clockevents_program_event() \|____bc_set_next() The hrtimer_{start/cancel} functions call into tracing which uses RCU. But it is not legal to call into RCU in cpuidle because it is one of the quiescent states. Hence protect this region with RCU_NONIDLE which informs RCU that the cpu is momentarily non-idle. As an aside it is helpful to point out that the clock event device that is programmed here is not a per-cpu clock device; it is a pseudo clock device, used by the broadcast framework alone. The per-cpu clock device programming never goes through bc_set_next(). Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: linuxppc-dev@ozlabs.org Cc: mpe@ellerman.id.au Cc: tglx@linutronix.de Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:12 -04:00
Majd Dibbiny	02d51afc23	IB/mlx4: Saturate RoCE port PMA counters in case of overflow [ Upstream commit `61a3855bb7` ] For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of overflow, according to the IB spec, we have to saturate a counter to its max value, do that. Fixes: `c37791349c` ('IB/mlx4: Support PMA counters for IBoE') Signed-off-by: Majd Dibbiny <majd@mellanox.com> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:11 -04:00
Uwe Kleine-König	aaa2bf750a	clk: divider: fix calculation of maximal parent rate for a given divider [ Upstream commit `da321133b5` ] The rate provided at the output of a clk-divider is calculated as: DIV_ROUND_UP(parent_rate, div) since commit `b11d282dbe` (clk: divider: fix rate calculation for fractional rates). So to yield a rate not bigger than r parent_rate must be <= r * div. The effect of choosing a parent rate that is too big as was done before this patch results in wrongly ruling out good dividers. Note that this is not a complete fix as __clk_round_rate might return a value >= its 2nd parameter. Also for dividers with CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this fixes the test case by Sascha Hauer that uses a chain of three dividers under a fixed clock. Fixes: `b11d282dbe` (clk: divider: fix rate calculation for fractional rates) Suggested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:11 -04:00
Uwe Kleine-König	5cd223ea7e	clk: divider: fix selection of divider when rounding to closest [ Upstream commit `26bac95aa8` ] It's an invalid approach to assume that among two divider values the one nearer the exact divider is the better one. Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16 are the candidates to choose from yielding rates 125 Hz and 62.5 Hz respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still the better divider as 62.5 is nearer to 89 than 125 is. Fixes: `774b514390` (clk: divider: Add round to closest divider) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:10 -04:00
Hans Verkuil	c6aa7146f1	[media] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop() [ Upstream commit `0e66100637` ] Stopping the vb2 thread (as used by several DVB devices) can result in an 'UNBALANCED' warning such as this: vb2: counters for queue ffff880407ee9828: UNBALANCED! vb2: setup: 1 start_streaming: 1 stop_streaming: 1 vb2: wait_prepare: 249333 wait_finish: 249334 This is due to a race condition between stopping the thread and calling vb2_internal_streamoff(). While I have not been able to deduce the exact mechanism how this race condition can produce this warning, I can see that the way the stream is stopped is likely to lead to a race somewhere. This patch simplifies how this is done by first ensuring that the thread is completely stopped before cleaning up the vb2 queue. It does that by setting threadio->stop to true, followed by a call to vb2_queue_error() which will wake up the thread. The thread sees that 'stop' is true and it will exit. The call to kthread_stop() waits until the thread has exited, and only then is the queue cleaned up by calling __vb2_cleanup_fileio(). This is a much cleaner sequence and the warning has now disappeared. Reported-by: Jurgen Kramer <gtmkramer@xs4all.nl> Tested-by: Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v3.18 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:09 -04:00
Geert Uytterhoeven	71871e8982	[media] soc-camera: Fix devm_kfree() in soc_of_bind() [ Upstream commit `8e48a2d54c` ] Unlike scan_async_group(), soc_of_bind() doesn't allocate its soc_camera_async_client structure using devm_kzalloc(), but has it embedded inside the soc_of_info structure. Hence on failure, it must free the whole soc_of_info structure, and not just the embedded soc_camera_async_client structure, as the latter causes a warning, and may cause slab corruption: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:887 devm_kfree+0x30/0x40() CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-shmobile-08386-g37feb0d093cb2d8e #128 Hardware name: Generic R8A7791 (Flattened Device Tree) Backtrace: [<c0011e7c>] (dump_backtrace) from [<c0012024>] (show_stack+0x18/0x1c) r6:c05a923b r5:00000009 r4:00000000 r3:00204140 [<c001200c>] (show_stack) from [<c048ed30>] (dump_stack+0x78/0x94) [<c048ecb8>] (dump_stack) from [<c002687c>] (warn_slowpath_common+0x8c/0xb8) r4:00000000 r3:00000000 [<c00267f0>] (warn_slowpath_common) from [<c0026980>] (warn_slowpath_null+0x24/0x2c) r8:ee7d8214 r7:ed83b810 r6:ed83bc20 r5:fffffffa r4:ed83e510 [<c002695c>] (warn_slowpath_null) from [<c025e0cc>] (devm_kfree+0x30/0x40) [<c025e09c>] (devm_kfree) from [<c032bbf4>] (soc_of_bind.isra.14+0x194/0x1d4) [<c032ba60>] (soc_of_bind.isra.14) from [<c032c6b8>] (soc_camera_host_register+0x208/0x31c) r9:00000070 r8:ee7e05d0 r7:ee153210 r6:00000000 r5:ee7e0218 r4:ed83bc20 [<c032c4b0>] (soc_camera_host_register) from [<c032e80c>] (rcar_vin_probe+0x1f4/0x238) r8:ee153200 r7:00000008 r6:ee153210 r5:ed83bc10 r4:c066319c r3:000000c0 [<c032e618>] (rcar_vin_probe) from [<c025c334>] (platform_drv_probe+0x50/0xa0) r10:00000000 r9:c0662fa8 r8:00000000 r7:c06a3700 r6:c0662fa8 r5:ee153210 r4:00000000 [<c025c2e4>] (platform_drv_probe) from [<c025af08>] (driver_probe_device+0xc4/0x208) r6:c06a36f4 r5:00000000 r4:ee153210 r3:c025c2e4 [<c025ae44>] (driver_probe_device) from [<c025b108>] (__driver_attach+0x70/0x94) r9:c066f9c0 r8:c0624a98 r7:c065b790 r6:c0662fa8 r5:ee153244 r4:ee153210 [<c025b098>] (__driver_attach) from [<c025984c>] (bus_for_each_dev+0x74/0x98) r6:c025b098 r5:c0662fa8 r4:00000000 r3:00000001 [<c02597d8>] (bus_for_each_dev) from [<c025b1dc>] (driver_attach+0x20/0x28) r6:ed83c200 r5:00000000 r4:c0662fa8 [<c025b1bc>] (driver_attach) from [<c025a00c>] (bus_add_driver+0xdc/0x1c4) [<c0259f30>] (bus_add_driver) from [<c025b8f4>] (driver_register+0xa4/0xe8) r7:c0624a98 r6:00000000 r5:c060b010 r4:c0662fa8 [<c025b850>] (driver_register) from [<c025ccd0>] (__platform_driver_register+0x50/0x64) r5:c060b010 r4:ed8394c0 [<c025cc80>] (__platform_driver_register) from [<c060b028>] (rcar_vin_driver_init+0x18/0x20) [<c060b010>] (rcar_vin_driver_init) from [<c05edde8>] (do_one_initcall+0x108/0x1b8) [<c05edce0>] (do_one_initcall) from [<c05edfb4>] (kernel_init_freeable+0x11c/0x1e4) r9:c066f9c0 r8:c066f9c0 r7:c062eab0 r6:c06252c4 r5:000000ad r4:00000006 [<c05ede98>] (kernel_init_freeable) from [<c048c3d0>] (kernel_init+0x10/0xec) r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c048c3c0 r4:00000000 [<c048c3c0>] (kernel_init) from [<c000eba0>] (ret_from_fork+0x14/0x34) r4:00000000 r3:ee04e000 ---[ end trace e3a984cc0335c8a0 ]--- rcar_vin e6ef1000.video: group probe failed: -6 Fixes: `1ddc6a6caa` ("[media] soc_camera: add support for dt binding soc_camera drivers") Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:09 -04:00
Marek Szyprowski	9785703f29	[media] media: s5p-mfc: fix mmap support for 64bit arch [ Upstream commit `05b676ab42` ] TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it should not be used for defining offset boundary for mmaping buffers for CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on the CAPTURE queue on 64bit architectures (like ARM64). Cc: stable@vger.kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:08 -04:00
Hans Verkuil	632f8dff84	[media] sh_veu: v4l2_dev wasn't set [ Upstream commit `ab3120300b` ] The v4l2_dev field of struct video_device must be set correctly. This was never done for this driver, so no video nodes were created anymore. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v3.11 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:07 -04:00
Mike Christie	a7c0141438	iscsi target: fix oops when adding reject pdu [ Upstream commit `b815fc12d4` ] This fixes a oops due to a double list add when adding a reject PDU for iscsit_allocate_iovecs allocation failures. The cmd has already been added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call iscsit_reject_cmd. Note that for ERL0 the reject PDU is not actually sent, so this patch is not completely tested. Just verified we do not oops. The problem is the add reject functions return -1 which is returned all the way up to iscsi_target_rx_thread which for ERL0 will drop the connection. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:07 -04:00
Al Viro	fe4a6fceff	ioctx_alloc(): fix vma (and file) leak on failure [ Upstream commit `deeb8525f9` ] If we fail past the aio_setup_ring(), we need to destroy the mapping. We don't need to care about anybody having found ctx, or added requests to it, since the last failure exit is exactly the failure to make ctx visible to lookups. Reproducer (based on one by Joe Mario <jmario@redhat.com>): void count(char p) { char s[80]; printf("%s: ", p); fflush(stdout); sprintf(s, "/bin/cat /proc/%d/maps\|/bin/fgrep -c '/[aio] (deleted)'", getpid()); system(s); } int main() { io_context_t ctx; int created, limit, i, destroyed; FILE *f; count("before"); if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL) perror("opening aio-max-nr"); else if (fscanf(f, "%d", &limit) != 1) fprintf(stderr, "can't parse aio-max-nr\n"); else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL) perror("allocating aio_context_t array"); else { for (i = 0, created = 0; i < limit; i++) { if (io_setup(1000, ctx + created) == 0) created++; } for (i = 0, destroyed = 0; i < created; i++) if (io_destroy(ctx[i]) == 0) destroyed++; printf("created %d, failed %d, destroyed %d\n", created, limit - created, destroyed); count("after"); } } Found-by: Joe Mario <jmario@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:06 -04:00
Al Viro	67041680ff	ocfs2: _really_ sync the right range [ Upstream commit `64b4e2526d` ] "ocfs2 syncs the wrong range" had been broken; prior to it the code was doing the wrong thing in case of O_APPEND, all right, but _after_ it we were syncing the wrong range in 100% cases. *ppos, aka iocb->ki_pos is incremented prior to that point, so we are always doing sync on the area _after_ the one we'd written to. Spotted by Joseph Qi <joseph.qi@huawei.com> back in January; unfortunately, I'd missed his mail back then ;-/ Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:05 -04:00
John Soni Jose	a260abd133	be2iscsi: Fix kernel panic when device initialization fails [ Upstream commit `2e7cee027b` ] Kernel panic was happening as iscsi_host_remove() was called on a host which was not yet added. Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:04 -04:00
Rafael J. Wysocki	862158f2bb	Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions" [ Upstream commit `f82daee49c` ] Commit `84c91b7ae0` (PM / hibernate: avoid unsafe pages in e820 reserved regions) is reported to make resume from hibernation on Lenovo x230 unreliable, so revert it. We will revisit the issue the commit in question was supposed to fix in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96111 Reported-by: rhn <kebuac.rhn@porcupinefactory.org> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:04 -04:00
Benjamin Herrenschmidt	0bc444b173	drivers/of: Add empty ranges quirk for PA-Semi [ Upstream commit `41d9489319` ] The "sdc" node is missing the ranges property, it needs to be treated as having an empty one otherwise translation fails for its children. Fixes `746c9e9f92`, "of/base: Fix PowerPC address parsing hack" Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Grant Likely <grant.likely@linaro.org> Cc: Stable <stable@vger.kernel.org> # v3.18+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:03 -04:00
Larry Finger	19d240f78b	rtlwifi: Fix IOMMU mapping leak in AP mode [ Upstream commit `be0b5e6358` ] Transmission of an AP beacon does not call the TX interrupt service routine, which usually does the cleanup. Instead, cleanup is handled in a tasklet completion routine. Unfortunately, this routine has a serious bug in that it does not release the DMA mapping before it frees the skb, thus one IOMMU mapping is leaked for each beacon. The test system failed with no free IOMMU mapping slots approximately one hour after hostapd was used to start an AP. This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30. Reported-and-tested-by: Kevin Mullican <kevin@mullican.com> Cc: Kevin Mullican <kevin@mullican.com> Signed-off-by: Shao Fu <shaofu@realtek.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.18+] Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:02 -04:00
Alex Williamson	d29425669a	iommu/vt-d: Detach domain only from attached iommus [ Upstream commit `7168440690` ] Device domains never span IOMMU hardware units, which allows the domain ID space for each IOMMU to be an independent address space. Therefore we can have multiple, independent domains, each with the same domain->id, but attached to different hardware units. This is also why we need to do a heavy-weight search for VM domains since they can span multiple IOMMUs hardware units and we don't require a single global ID to use for all hardware units. Therefore, if we call iommu_detach_domain() across all active IOMMU hardware units for a non-VM domain, the result is that we clear domain IDs that are not associated with our domain, allowing them to be re-allocated and causing apparent coherency issues when the device cannot access IOVAs for the intended domain. This bug was introduced in commit `fb170fb4c5` ("iommu/vt-d: Introduce helper functions to make code symmetric for readability"), but is significantly exacerbated by the more recent commit `62c22167dd` ("iommu/vt-d: Fix dmar_domain leak in iommu_attach_device") which calls domain_exit() more frequently to resolve a domain leak. Fixes: `fb170fb4c5` ("iommu/vt-d: Introduce helper functions to make code symmetric for readability") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:02 -04:00
David Disseldorp	e9c75e69d6	cifs: fix use-after-free bug in find_writable_file [ Upstream commit `e1e9bda22d` ] Under intermittent network outages, find_writable_file() is susceptible to the following race condition, which results in a user-after-free in the cifs_writepages code-path: Thread 1 Thread 2 ======== ======== inv_file = NULL refind = 0 spin_lock(&cifs_file_list_lock) // invalidHandle found on openFileList inv_file = open_file // inv_file->count currently 1 cifsFileInfo_get(inv_file) // inv_file->count = 2 spin_unlock(&cifs_file_list_lock); cifs_reopen_file() cifs_close() // fails (rc != 0) ->cifsFileInfo_put() spin_lock(&cifs_file_list_lock) // inv_file->count = 1 spin_unlock(&cifs_file_list_lock) spin_lock(&cifs_file_list_lock); list_move_tail(&inv_file->flist, &cifs_inode->openFileList); spin_unlock(&cifs_file_list_lock); cifsFileInfo_put(inv_file); ->spin_lock(&cifs_file_list_lock) // inv_file->count = 0 list_del(&cifs_file->flist); // cleanup!! kfree(cifs_file); spin_unlock(&cifs_file_list_lock); spin_lock(&cifs_file_list_lock); ++refind; // refind = 1 goto refind_writable; At this point we loop back through with an invalid inv_file pointer and a refind value of 1. On second pass, inv_file is not overwritten on openFileList traversal, and is subsequently dereferenced. Signed-off-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Jeff Layton <jlayton@samba.org> CC: <stable@vger.kernel.org> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:01 -04:00
Sachin Prabhu	6bb88677e8	cifs: smb2_clone_range() - exit on unhandled error [ Upstream commit `2477bc58d4` ] While attempting to clone a file on a samba server, we receive a STATUS_INVALID_DEVICE_REQUEST. This is mapped to -EOPNOTSUPP which isn't handled in smb2_clone_range(). We end up looping in the while loop making same call to the samba server over and over again. The proposed fix is to exit and return the error value when encountered with an unhandled error. Cc: <stable@vger.kernel.org> Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Steve French <steve.french@primarydata.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:00 -04:00
Stefan Agner	465dd8c051	tty: serial: fsl_lpuart: clear receive flag on FIFO flush [ Upstream commit `8e4934c6d6` ] When the receiver was enabled during startup, a character could have been in the FIFO when the UART get initially used. The driver configures the (receive) watermark level, and flushes the FIFO. However, the receive flag (RDRF) could still be set at that stage (as mentioned in the register description of UARTx_RWFIFO). This leads to an interrupt which won't be handled properly in interrupt mode: The receive interrupt function lpuart_rxint checks the FIFO count, which is 0 at that point (due to the flush during initialization). The problem does not manifest when using DMA to receive characters. Fix this situation by explicitly read the status register, which leads to clearing of the RDRF flag. Due to the flush just after the status flag read, a explicit data read is not to required. Signed-off-by: Stefan Agner <stefan@agner.ch> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:14:00 -04:00
Stefan Agner	eed8dd7be5	tty: serial: fsl_lpuart: specify transmit FIFO size [ Upstream commit `4e8f245937` ] Specify transmit FIFO size which might be different depending on LPUART instance. This makes sure uart_wait_until_sent in serial core getting called, which in turn waits and checks if the FIFO is really empty on shutdown by using the tx_empty callback. Without the call of this callback, the last several characters might not yet be transmitted when closing the serial port. This can be reproduced by simply using echo and redirect the output to a ttyLP device. Signed-off-by: Stefan Agner <stefan@agner.ch> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:59 -04:00
Lu Baolu	3372538a5a	usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers [ Upstream commit `227a4fd801` ] When a device with an isochronous endpoint is plugged into the Intel xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under Intel xHCI host controllers, if the event ring is full of events from transfers with BEI set, an "Event Ring is Full" event will be posted to the last entry of the event ring, but no interrupt is generated. Host will cease all transfer and command executions and wait until software completes handling the pending events in the event ring. That means xHC stops, but event of "event ring is full" is not notified. As the result, the xHC looks like dead to user. This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And it should be backported to kernels as old as 3.0, that contains the commit `69e848c209` ("Intel xhci: Support EHCI/xHCI port switching."). Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Alistair Grant <akgrant0710@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:58 -04:00
Lu Baolu	83961c5495	usb: xhci: handle Config Error Change (CEC) in xhci driver [ Upstream commit `9425183d17` ] Linux xHCI driver doesn't report and handle port cofig error change. If Port Configure Error for root hub port occurs, CEC bit in PORTSC would be set by xHC and remains 1. This happends when the root port fails to configure its link partner, e.g. the port fails to exchange port capabilities information using Port Capability LMPs. Then the Port Status Change Events will be blocked until all status change bits(CEC is one of the change bits) are cleared('0') (refer to xHCI spec 4.19.2). Otherwise, the port status change event for this root port will not be generated anymore, then root port would look like dead for user and can't be recovered until a Host Controller Reset(HCRST). This patch is to check CEC bit in PORTSC in xhci_get_port_status() and set a Config Error in the return status if CEC is set. This will cause a ClearPortFeature request, where CEC bit is cleared in xhci_clear_port_change_bit(). [The commit log is based on initial Marvell patch posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2] Reported-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:58 -04:00
Thomas Schlichter	ae0f5de3bb	cpuidle: ACPI: do not overwrite name and description of C0 [ Upstream commit `c7e8bdf587` ] Fix a bug that leads to showing the name and description of C-state C0 as "<null>" in sysfs after the ACPI C-states changed (e.g. after AC->DC or DC->AC transition). The function poll_idle_init() in drivers/cpuidle/driver.c initializes the state 0 during cpuidle_register_driver(), so we better do not overwrite it again with '\0' during acpi_processor_cst_has_changed(). Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:57 -04:00
Bartlomiej Zolnierkiewicz	8711912370	cpuidle: remove state_count field from struct cpuidle_device [ Upstream commit `d75e4af14e` ] Thomas Schlichter reports the following issue on his Samsung NC20: "The C-states C1 and C2 to the OS when connected to AC, and additionally provides the C3 C-state when disconnected from AC. However, the number of C-states shown in sysfs is fixed to the number of C-states present at boot. If I boot with AC connected, I always only see the C-states up to C2 even if I disconnect AC. The reason is commit `130a5f6924` (ACPI / cpuidle: remove dev->state_count setting). It removes the update of dev->state_count, but sysfs uses exactly this variable to show the C-states. The fix is to use drv->state_count in sysfs. As this is currently the last user of dev->state_count, this variable can be completely removed." Remove dev->state_count as per the above. Reported-by: Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:56 -04:00
Andreas Werner	a32d3f4034	can: flexcan: Deferred on Regulator return EPROBE_DEFER [ Upstream commit `555828ef45` ] Return EPROBE_DEFER if Regulator returns EPROBE_DEFER If the Flexcan driver is built into kernel and a regulator is used to enable the CAN transceiver, the Flexcan driver may not use the regulator. When initializing the Flexcan device with a regulator defined in the device tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence the Flexcan init fails. The solution for this is to return EPROBE_DEFER if regulator is not initialized and wait until the regulator is initialized. Signed-off-by: Andreas Werner <kernel@andy89.org> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:56 -04:00
Stefan Lippers-Hollmann	44d8cbece7	x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk [ Upstream commit `80313b3078` ] The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in both BIOS and UEFI mode while rebooting unless reboot=pci is used. Add a quirk to reboot via the pci method. The problem is very intermittent and hard to debug, it might succeed rebooting just fine 40 times in a row - but fails half a dozen times the next day. It seems to be slightly less common in BIOS CSM mode than native UEFI (with the CSM disabled), but it does happen in either mode. Since I've started testing this patch in late january, rebooting has been 100% reliable. Most of the time it already hangs during POST, but occasionally it might even make it through the bootloader and the kernel might even start booting, but then hangs before the mode switch. The same symptoms occur with grub-efi, gummiboot and grub-pc, just as well as (at least) kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16). Upgrading to the most current mainboard firmware of the ASRock Q1900DC-ITX, version 1.20, does not improve the situation. ( Searching the web seems to suggest that other Bay Trail-D mainboards might be affected as well. ) -- Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: <stable@vger.kernel.org> Cc: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:55 -04:00
Felix Fietkau	7f67673653	ath9k: fix tracking of enabled AP beacons [ Upstream commit `1cf48f22c9` ] sc->nbcnvifs tracks assigned beacon slots, not enabled beacons. Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool) should be updated, or if beacons have been enabled already. With the current code (depending on the order of calls), beacons often do not get enabled in an AP+STA setup. To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a bitmask of enabled beacon slots. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:54 -04:00
Peter Ujfalusi	9786bf2b3a	dmaengine: omap-dma: Fix memory leak when terminating running transfer [ Upstream commit `02d88b735f` ] In omap_dma_start_desc the vdesc->node is removed from the virt-dma framework managed lists (to be precise from the desc_issued list). If a terminate_all comes before the transfer finishes the omap_desc will not be freed up because it is not in any of the lists and we stopped the DMA channel so the transfer will not going to complete. There is no special sequence for leaking memory when using cyclic (audio) transfer: with every start and stop of a cyclic transfer the driver leaks struct omap_desc worth of memory. Free up the allocated memory directly in omap_dma_terminate_all() since the framework will not going to do that for us. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: <stable@vger.kernel.org> CC: <linux-omap@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:54 -04:00
Petr Kulhavy	ba1d2d92c3	dmaengine: edma: fix memory leak when terminating running transfers [ Upstream commit `5ca9e7ce6e` ] If edma_terminate_all() was called while a transfer was running (i.e. after edma_execute() but before edma_callback()) the echan->edesc was not freed. This was due to the fact that a running transfer is on none of the vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute() removes it from the desc_issued list), so the vchan_dma_desc_free_list() called at the end of edma_terminate_all() didn't find it and didn't free it. This bug was found on an AM1808 based hardware (very similar to da850evm, however using the second MMC/SD controller), where intense operations on the SD card wasted the device 128MB RAM within a couple of days. Peter Ujfalusi: The issue is even more severe since it affects cyclic (audio) transfers as well. In this case starting/stopping audio will results memory leak. Signed-off-by: Petr Kulhavy <petr@barix.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: <stable@vger.kernel.org> CC: <linux-omap@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:53 -04:00
Darshana Padmadas	cfb769a843	iio: imu: Use iio_trigger_get for indio_dev->trig assignment [ Upstream commit `4ce7ca89d6` ] This patch uses iio_trigger_get to increment the reference count of trigger device, to avoid incorrect assignment. Can result in a null pointer dereference during removal if the trigger has been changed before removal. This patch refers to a similar situation encountered through the following discussion: http://www.spinics.net/lists/linux-iio/msg13669.html Signed-off-by: Darshana Padmadas <darshanapadmadas@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:53 -04:00
Stefan Agner	dcf72cd613	iio: adc: vf610: use ADC clock within specification [ Upstream commit `f54e9f2be3` ] Depending on conversion mode used, the ADC clock (ADCK) needs to be below a maximum frequency. According to Vybrid's data sheet this is 20MHz for the low power conversion mode. The ADC clock is depending on input clock, which is the bus clock by default. Vybrid SoC are typically clocked at at 400MHz or 500MHz, which leads to 66MHz or 83MHz bus clock respectively. Hence, a divider of 8 is required to stay below the specified maximum clock of 20MHz. Due to the different bus clock speeds, the resulting sampling frequency is not static. Hence use the ADC clock and calculate the actual available sampling frequency dynamically. This fixes bogous values observed on some 500MHz clocked Vybrid SoC. The resulting value usually showed Bit 9 being stuck at 1, or 0, which lead to a value of +/-512. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Fugang Duan <B38611@freescale.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:52 -04:00
Sathyanarayanan Kuppuswamy	1930ba06ce	iio: bmc150: change sampling frequency [ Upstream commit `0ba8da961b` ] Currently driver reports device bandwidth list as available sampling frequency. But sampling frequency is actually twice the device bandwidth. This patch fixes this issue. Signed-off-by: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@intel.com> Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:51 -04:00
Martin Fuzzey	42ec319b44	iio: core: Fix double free. [ Upstream commit `c1b03ab5e8` ] When an error occurred during event registration memory was freed twice resulting in kernel memory corruption and a crash in unrelated code. The problem was caused by iio_device_unregister_eventset() iio_device_unregister_sysfs() being called twice, once on the error path and then again via iio_dev_release(). Fix this by making these two functions idempotent so they may be called multiple times. The problem was observed before applying `78b33216` iio:core: Handle error when mask type is not separate Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:50 -04:00
Viorel Suman	382fd035e6	iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo [ Upstream commit `4dac0a8eef` ] A hardware fifo reset always imply an invalidation of the existing timestamps, so we'll clear timestamps fifo on successfull hardware fifo reset. Signed-off-by: Viorel Suman <viorel.suman@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:50 -04:00
Bart Van Assche	f37f8f40ba	Defer processing of REQ_PREEMPT requests for blocked devices [ Upstream commit `bba0bdd7ad` ] SCSI transport drivers and SCSI LLDs block a SCSI device if the transport layer is not operational. This means that in this state no requests should be processed, even if the REQ_PREEMPT flag has been set. This patch avoids that a rescan shortly after a cable pull sporadically triggers the following kernel oops: BUG: unable to handle kernel paging request at ffffc9001a6bc084 IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib] Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100) Call Trace: [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp] [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp] [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod] [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod] [<ffffffff81223b37>] __blk_run_queue+0x27/0x30 [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110 [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0 [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod] [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod] [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod] [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod] [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod] [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod] [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod] [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod] [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160 [<ffffffff811589de>] vfs_write+0xce/0x140 [<ffffffff81158b53>] sys_write+0x53/0xa0 [<ffffffff81464592>] system_call_fastpath+0x16/0x1b [<00007f611c9d9300>] 0x7f611c9d92ff Reported-by: Max Gurtuvoy <maxg@mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:49 -04:00
Doug Goldstein	4893f8b26f	USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 [ Upstream commit `b229a0f840` ] This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Signed-off-by: Doug Goldstein <cardoe@cardoe.com> CC: stable <stable@vger.kernel.org> [johan: clean up probe logic ] Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:48 -04:00
Doug Goldstein	5134850530	USB: ftdi_sio: Added custom PID for Synapse Wireless product [ Upstream commit `4899c054a9` ] Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their SNAP Stick 200 product. Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:48 -04:00
Nathaniel W Filardo	b8cfabf90c	USB: keyspan_pda: add new device id [ Upstream commit `5e71fc8629` ] Add USB VID/PID for Xircom PGMFHUB USB/serial component. (The hub and SCSI bridge on that hardware are recognized out of the box by existing drivers.) Tested VID/PID using new_id and loopback connection and was met with success, but that's all the testing done. Signed-off-by: Nathaniel Wesley Filardo <nwf@cs.jhu.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:47 -04:00
David Miller	fde250a51c	radeon: Do not directly dereference pointers to BIOS area. [ Upstream commit `f2c9e560b4` ] Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:46 -04:00
Tejun Heo	51e17d281a	writeback: fix possible underflow in write bandwidth calculation [ Upstream commit `c72efb658f` ] From 1ebf33901ecc75d9496862dceb1ef0377980587c Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj@kernel.org> Date: Mon, 23 Mar 2015 00:08:19 -0400 `2f800fbd77` ("writeback: fix dirtied pages accounting on redirty") introduced account_page_redirty() which reverts stat updates for a redirtied page, making BDI_DIRTIED no longer monotonically increasing. bdi_update_write_bandwidth() uses the delta in BDI_DIRTIED as the basis for bandwidth calculation. While unlikely, since the above patch, the newer value may be lower than the recorded past value and underflow the bandwidth calculation leading to a wild result. Fix it by subtracing min of the old and new values when calculating delta. AFAIK, there hasn't been any report of it happening but the resulting erratic behavior would be non-critical and temporary, so it's possible that the issue is happening without being reported. The risk of the fix is very low, so tagged for -stable. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jan Kara <jack@suse.cz> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Greg Thelen <gthelen@google.com> Fixes: `2f800fbd77` ("writeback: fix dirtied pages accounting on redirty") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:46 -04:00
Tejun Heo	5988107861	writeback: add missing INITIAL_JIFFIES init in global_update_bandwidth() [ Upstream commit `7d70e15480` ] global_update_bandwidth() uses static variable update_time as the timestamp for the last update but forgets to initialize it to INITIALIZE_JIFFIES. This means that global_dirty_limit will be 5 mins into the future on 32bit and some large amount jiffies into the past on 64bit. This isn't critical as the only effect is that global_dirty_limit won't be updated for the first 5 mins after booting on 32bit machines, especially given the auxiliary nature of global_dirty_limit's role - protecting against global dirty threshold's sudden dips; however, it does lead to unintended suboptimal behavior. Fix it. Fixes: `c42843f2f0` ("writeback: introduce smoothed global dirty limit") Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Jan Kara <jack@suse.cz> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:45 -04:00
Viresh Kumar	5f44e3971f	cpufreq: Schedule work for the first-online CPU on resume [ Upstream commit `c75de0ac07` ] All CPUs leaving the first-online CPU are hotplugged out on suspend and and cpufreq core stops managing them. On resume, we need to call cpufreq_update_policy() for this CPU's policy to make sure its frequency is in sync with cpufreq's cached value, as it might have got updated by hardware during suspend/resume. The policies are always added to the top of the policy-list. So, in normal circumstances, CPU 0's policy will be the last one in the list. And so the code checks for the last policy. But there are cases where it will fail. Consider quad-core system, with policy-per core. If CPU0 is hotplugged out and added back again, the last policy will be on CPU1 :( To fix this in a proper way, always look for the policy of the first online CPU. That way we will be sure that we are calling cpufreq_update_policy() for the only CPU that wasn't hotplugged out. Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Fixes: `2f0aea9363` ("cpufreq: suspend governors on system suspend/hibernate") Reported-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:44 -04:00
Brian Silverman	42d921d36b	sched: Fix RLIMIT_RTTIME when PI-boosting to RT [ Upstream commit `746db9443e` ] When non-realtime tasks get priority-inheritance boosted to a realtime scheduling class, RLIMIT_RTTIME starts to apply to them. However, the counter used for checking this (the same one used for SCHED_RR timeslices) was not getting reset. This meant that tasks running with a non-realtime scheduling class which are repeatedly boosted to a realtime one, but never block while they are running realtime, eventually hit the timeout without ever running for a time over the limit. This patch resets the realtime timeslice counter when un-PI-boosting from an RT to a non-RT scheduling class. I have some test code with two threads and a shared PTHREAD_PRIO_INHERIT mutex which induces priority boosting and spins while boosted that gets killed by a SIGXCPU on non-fixed kernels but doesn't with this patch applied. It happens much faster with a CONFIG_PREEMPT_RT kernel, and does happen eventually with PREEMPT_VOLUNTARY kernels. Signed-off-by: Brian Silverman <brian@peloton-tech.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: austin@peloton-tech.com Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/1424305436-6716-1-git-send-email-brian@peloton-tech.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:43 -04:00
Laura Abbott	a38edfb213	mm/page_alloc.c: call kernel_map_pages in unset_migrateype_isolate [ Upstream commit `cfa8694382` ] Commit `3c605096d3` ("mm/page_alloc: restrict max order of merging on isolated pageblock") changed the logic of unset_migratetype_isolate to check the buddy allocator and explicitly call __free_pages to merge. The page that is being freed in this path never had prep_new_page called so set_page_refcounted is called explicitly but there is no call to kernel_map_pages. With the default kernel_map_pages this is mostly harmless but if kernel_map_pages does any manipulation of the page tables (unmapping or setting pages to read only) this may trigger a fault: alloc_contig_range test_pages_isolated(ceb00, ced00) failed Unable to handle kernel paging request at virtual address ffffffc0cec00000 pgd = ffffffc045fc4000 [ffffffc0cec00000] *pgd=0000000000000000 Internal error: Oops: 9600004f [#1] PREEMPT SMP Modules linked in: exfatfs CPU: 1 PID: 23237 Comm: TimedEventQueue Not tainted 3.10.49-gc72ad36-dirty #1 task: ffffffc03de52100 ti: ffffffc015388000 task.ti: ffffffc015388000 PC is at memset+0xc8/0x1c0 LR is at kernel_map_pages+0x1ec/0x244 Fix this by calling kernel_map_pages to ensure the page is set in the page table properly Fixes: `3c605096d3` ("mm/page_alloc: restrict max order of merging on isolated pageblock") Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mel Gorman <mgorman@suse.de> Acked-by: Rik van Riel <riel@redhat.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Cc: Xishi Qiu <qiuxishi@huawei.com> Cc: Vladimir Davydov <vdavydov@parallels.com> Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Gioh Kim <gioh.kim@lge.com> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:43 -04:00
Gu Zheng	ec4db2665a	mm/memory hotplug: postpone the reset of obsolete pgdat [ Upstream commit `b0dc3a342a` ] Qiu Xishi reported the following BUG when testing hot-add/hot-remove node under stress condition: BUG: unable to handle kernel paging request at 0000000000025f60 IP: next_online_pgdat+0x1/0x50 PGD 0 Oops: 0000 [#1] SMP ACPI: Device does not support D3cold Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod coretemp mperf crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 pcspkr microcode igb dca i2c_algo_bit ipv6 megaraid_sas iTCO_wdt i2c_i801 i2c_core iTCO_vendor_support tg3 sg hwmon ptp lpc_ich pps_core mfd_core acpi_pad rtc_cmos button ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh ahci libahci libata scsi_mod [last unloaded: rasf] CPU: 23 PID: 238 Comm: kworker/23:1 Tainted: G O 3.10.15-5885-euler0302 #1 Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Huawei N1/Huawei N1, BIOS V100R001 03/02/2015 Workqueue: events vmstat_update task: ffffa800d32c0000 ti: ffffa800d32ae000 task.ti: ffffa800d32ae000 RIP: 0010: next_online_pgdat+0x1/0x50 RSP: 0018:ffffa800d32afce8 EFLAGS: 00010286 RAX: 0000000000001440 RBX: ffffffff81da53b8 RCX: 0000000000000082 RDX: 0000000000000000 RSI: 0000000000000082 RDI: 0000000000000000 RBP: ffffa800d32afd28 R08: ffffffff81c93bfc R09: ffffffff81cbdc96 R10: 00000000000040ec R11: 00000000000000a0 R12: ffffa800fffb3440 R13: ffffa800d32afd38 R14: 0000000000000017 R15: ffffa800e6616800 FS: 0000000000000000(0000) GS:ffffa800e6600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000025f60 CR3: 0000000001a0b000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: refresh_cpu_vm_stats+0xd0/0x140 vmstat_update+0x11/0x50 process_one_work+0x194/0x3d0 worker_thread+0x12b/0x410 kthread+0xc6/0xd0 ret_from_fork+0x7c/0xb0 The cause is the "memset(pgdat, 0, sizeof(pgdat))" at the end of try_offline_node, which will reset all the content of pgdat to 0, as the pgdat is accessed lock-free, so that the users still using the pgdat will panic, such as the vmstat_update routine. process A: offline node XX: vmstat_updat() refresh_cpu_vm_stats() for_each_populated_zone() find online node XX cond_resched() offline cpu and memory, then try_offline_node() node_set_offline(nid), and memset(pgdat, 0, sizeof(pgdat)) zone = next_zone(zone) pg_data_t *pgdat = zone->zone_pgdat; // here pgdat is NULL now next_online_pgdat(pgdat) next_online_node(pgdat->node_id); // NULL pointer access So the solution here is postponing the reset of obsolete pgdat from try_offline_node() to hotadd_new_pgdat(), and just resetting pgdat->nr_zones and pgdat->classzone_idx to be 0 rather than the memset 0 to avoid breaking pointer information in pgdat. Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Reported-by: Xishi Qiu <qiuxishi@huawei.com> Suggested-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: David Rientjes <rientjes@google.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: Taku Izumi <izumi.taku@jp.fujitsu.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: Xie XiuQi <xiexiuqi@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:42 -04:00
Leon Yu	5bc650f06f	mm: fix anon_vma->degree underflow in anon_vma endless growing prevention [ Upstream commit `3fe89b3e2a` ] I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after upgrading to 3.19 and had no luck with 4.0-rc1 neither. So, after looking into new logic introduced by commit `7a3ef208e6` ("mm: prevent endless growth of anon_vma hierarchy"), I found chances are that unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL in error path, its degree will be incorrectly decremented in unlink_anon_vmas() and eventually underflow when exiting as a result of another call to unlink_anon_vmas(). That's how "kernel BUG at mm/rmap.c:399!" is triggered for me. This patch fixes the underflow by dropping dst->anon_vma when allocation fails. It's safe to do so regardless of original value of dst->anon_vma because dst->anon_vma doesn't have valid meaning if anon_vma_clone() fails. Besides, callers don't care dst->anon_vma in such case neither. Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as anon_vma_clone() now does the work. [akpm@linux-foundation.org: tweak comment] Fixes: `7a3ef208e6` ("mm: prevent endless growth of anon_vma hierarchy") Signed-off-by: Leon Yu <chianglungyu@gmail.com> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:38 -04:00
Konstantin Khlebnikov	f94faaaa99	mm: fix corner case in anon_vma endless growing prevention [ Upstream commit `b800c91a05` ] Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas() ("kernel BUG at mm/rmap.c:399!") caused by commit `7a3ef208e6` ("mm: prevent endless growth of anon_vma hierarchy") Anon_vma_clone() is usually called for a copy of source vma in destination argument. If source vma has anon_vma it should be already in dst->anon_vma. NULL in dst->anon_vma is used as a sign that it's called from anon_vma_fork(). In this case anon_vma_clone() finds anon_vma for reusing. Vma_adjust() calls it differently and this breaks anon_vma reusing logic: anon_vma_clone() links vma to old anon_vma and updates degree counters but vma_adjust() overrides vma->anon_vma right after that. As a result final unlink_anon_vmas() decrements degree for wrong anon_vma. This patch assigns ->anon_vma before calling anon_vma_clone(). Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com> Reported-and-tested-by: Chris Clayton <chris2553@googlemail.com> Reported-and-tested-by: Oded Gabbay <oded.gabbay@amd.com> Reported-and-tested-by: Chih-Wei Huang <cwhuang@android-x86.org> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Daniel Forrest <dan.forrest@ssec.wisc.edu> Cc: Michal Hocko <mhocko@suse.cz> Cc: stable@vger.kernel.org # to match back-porting of `7a3ef208e6` Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:22 -04:00
Konstantin Khlebnikov	3f1618006b	mm: prevent endless growth of anon_vma hierarchy [ Upstream commit `7a3ef208e6` ] Constantly forking task causes unlimited grow of anon_vma chain. Each next child allocates new level of anon_vmas and links vma to all previous levels because pages might be inherited from any level. This patch adds heuristic which decides to reuse existing anon_vma instead of forking new one. It adds counter anon_vma->degree which counts linked vmas and directly descending anon_vmas and reuses anon_vma if counter is lower than two. As a result each anon_vma has either vma or at least two descending anon_vmas. In such trees half of nodes are leafs with alive vmas, thus count of anon_vmas is no more than two times bigger than count of vmas. This heuristic reuses anon_vmas as few as possible because each reuse adds false aliasing among vmas and rmap walker ought to scan more ptes when it searches where page is might be mapped. Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu Fixes: `5beb493052` ("mm: change anon_vma linking to fix multi-process server scalability issue") [akpm@linux-foundation.org: fix typo, per Rik] Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com> Reported-by: Daniel Forrest <dan.forrest@ssec.wisc.edu> Tested-by: Michal Hocko <mhocko@suse.cz> Tested-by: Jerome Marchand <jmarchan@redhat.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: <stable@vger.kernel.org> [2.6.34+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-24 17:13:13 -04:00
Johannes Berg	f68391eb9b	mac80211: fix RX A-MPDU session reorder timer deletion [ Upstream commit `788211d81b` ] There's an issue with the way the RX A-MPDU reorder timer is deleted that can cause a kernel crash like this: * tid_rx is removed - call_rcu(ieee80211_free_tid_rx) * station is destroyed * reorder timer fires before ieee80211_free_tid_rx() runs, accessing the station, thus potentially crashing due to the use-after-free The station deletion is protected by synchronize_net(), but that isn't enough -- ieee80211_free_tid_rx() need not have run when that returns (it deletes the timer.) We could use rcu_barrier() instead of synchronize_net(), but that's much more expensive. Instead, to fix this, add a field tracking that the session is being deleted. In this case, the only re-arming of the timer happens with the reorder spinlock held, so make that code not rearm it if the session is being deleted and also delete the timer after setting that field. This ensures the timer cannot fire after ___ieee80211_stop_rx_ba_session() returns, which fixes the problem. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:29 -04:00
Sudip Mukherjee	4f33d5001b	nbd: fix possible memory leak [ Upstream commit `ff6b8090e2` ] we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Paul Clements <Paul.Clements@SteelEye.com> Cc: <stable@vger.kernel.org> Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:28 -04:00
Paul Clarke	43d9ca6b59	powerpc: Re-enable dynticks [ Upstream commit `fea559f303` ] Implement arch_irq_work_has_interrupt() for powerpc Commit `9b01f5bf3` introduced a dependency on "IRQ work self-IPIs" for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt() routine. Several arches have implemented this routine, including x86 (`3010279f`) and arm (`09f6edd4`), but powerpc was omitted. This patch implements this routine for powerpc. The symptom, at boot (on powerpc systems) with "nohz_full=<CPU list>" is displayed: NO_HZ: Can't run full dynticks because arch doesn't support irq work self-IPIs after this patch: NO_HZ: Full dynticks CPUs: <CPU list>. Tested against 3.19. powerpc implements "IRQ work self-IPIs" by setting the decrementer to 1 in arch_irq_work_raise(), which causes a decrementer exception on the next timebase tick. We then handle the work in __timer_interrupt(). CC: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Paul A. Clarke <pc@us.ibm.com> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> [mpe: Flesh out change log, fix ws & include guards, remove include of processor.h] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:28 -04:00
Jan Stancek	70213cdd6b	powerpc: fix memory corruption by pnv_alloc_idle_core_states [ Upstream commit `d52356e7f4` ] Space allocated for paca is based off nr_cpu_ids, but pnv_alloc_idle_core_states() iterates paca with cpu_nr_cores()*threads_per_core, which is using NR_CPUS. This causes pnv_alloc_idle_core_states() to write over memory, which is outside of paca array and may later lead to various panics. Fixes: `7cba160ad7` (powernv/cpuidle: Redesign idle states management) Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:27 -04:00
J. Bruce Fields	604696d8b5	nfsd: return correct lockowner when there is a race on hash insert [ Upstream commit `340f0ba1c6` ] alloc_init_lock_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. Noticed by inspection after Jeff Layton fixed the same bug for open owners. Depending on client behavior, this one may be trickier to trigger in practice. Fixes: `c58c6610ec` "nfsd: Protect adding/removing lock owners using client_lock" Cc: <stable@vger.kernel.org> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Acked-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:27 -04:00
Jeff Layton	5a472b11c0	nfsd: return correct openowner when there is a race to put one in the hash [ Upstream commit `c5952338bf` ] alloc_init_open_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. In commit `7ffb588086`, we changed it so that we allocate and initialize an openowner, and then check to see if a matching one got stuffed into the hashtable in the meantime. If it did, then we free the one we just allocated and take a reference on the one already there. There is a bug here though. The code will then return the pointer to the one that was allocated (and has now been freed). This wasn't evident before as this race almost never occurred. The Linux kernel client used to serialize requests for a single openowner. That has changed now with v4.0 kernels, and this race can now easily occur. Fixes: `7ffb588086` Cc: <stable@vger.kernel.org> # v3.17+ Cc: Trond Myklebust <trond.myklebust@primarydata.com> Reported-by: Christoph Hellwig <hch@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:26 -04:00
Juergen Gross	76569d5333	xen/balloon: before adding hotplugged memory, set frames to invalid [ Upstream commit `3c56b3a12c` ] Commit `25b884a83d` ("x86/xen: set regions above the end of RAM as 1:1") introduced a regression. To be able to add memory pages which were added via memory hotplug to a pv domain, the pages must be "invalid" instead of "identity" in the p2m list before they can be added. Suggested-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com> Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:26 -04:00
Emmanuel Grumbach	3b73092996	iwlwifi: dvm: run INIT firmware again upon .start() [ Upstream commit `9c8928f517` ] The assumption before this patch was that we don't need to run again the INIT firmware after the system booted. The INIT firmware runs calibrations which impact the physical layer's behavior. Users reported that it may be helpful to run these calibrations again every time the interface is brought up. The penatly is minimal, since the calibrations run fast. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=94341 CC: <stable@vger.kernel.org> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:25 -04:00
Shachar Raindel	9b233a2fb7	IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic [ Upstream commit `8494057ab5` ] Properly verify that the resulting page aligned end address is larger than both the start address and the length of the memory area requested. Both the start and length arguments for ib_umem_get are controlled by the user. A misbehaving user can provide values which will cause an integer overflow when calculating the page aligned end address. This overflow can cause also miscalculation of the number of pages mapped, and additional logic issues. Addresses: CVE-2014-8159 Cc: <stable@vger.kernel.org> Signed-off-by: Shachar Raindel <raindel@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:25 -04:00
David Sterba	b3d55b2f85	btrfs: simplify insert_orphan_item [ Upstream commit `9c4f61f01d` ] We can search and add the orphan item in one go, btrfs_insert_orphan_item will find out if the item already exists. Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:24 -04:00
Daniel Vetter	171c32b52f	drm/i915: Align initial plane backing objects correctly [ Upstream commit `f37b5c2be8` ] Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: stable@vger.kernel.org Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Johannes W <jargon@molb.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:23 -04:00
Jesse Barnes	fea8f8a4c5	drm/i915/vlv: remove wait for previous GFX clk disable request [ Upstream commit `5df0582bf0` ] Looks like it was introduced in: commit `650ad970a3` Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see `85250ddff7` "drm/i915/chv: Remove Wait for a previous gfx force-off" and `8d4eee9cd7` "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # `c9c52e2419`: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:23 -04:00
Jesse Barnes	498ddc6f73	drm/i915/vlv: save/restore the power context base reg [ Upstream commit `9c25210fd3` ] Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:22 -04:00
Deepak S	a8c89064e3	drm/i915/vlv: remove wait for previous GFX clk disable request [ Upstream commit `5df0582bf0` ] Looks like it was introduced in: commit `650ad970a3` Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see `85250ddff7` "drm/i915/chv: Remove Wait for a previous gfx force-off" and `8d4eee9cd7` "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # `c9c52e2419`: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:22 -04:00
Christian König	642069bc2e	drm/radeon: fix wait in radeon_mn_invalidate_range_start [ Upstream commit `22e2e86560` ] We need to wait for all fences, not just the exclusive one. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:21 -04:00
Christian König	529797cb41	drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr [ Upstream commit `863653fed0` ] We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:21 -04:00
Alex Deucher	2cd4d4120f	drm/radeon/dpm: fix 120hz handling harder [ Upstream commit `3899ca844b` ] Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:20 -04:00
Ville Syrjälä	19f2e4b1c2	drm/i915: Reject the colorkey ioctls for primary and cursor planes [ Upstream commit `840a1cf0cd` ] The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Cc: stable@vger.kernel.org Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:20 -04:00
Jani Nikula	ed40507c15	drm/edid: set ELD for firmware and debugfs override EDIDs [ Upstream commit `ad692b46db` ] If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Reported-by: Emil <emilsvennesson@gmail.com> Reported-by: Rob Engle <grenoble@gmail.com> Tested-by: Jolan Luff <jolan@gormsby.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:19 -04:00
Daniel Vetter	aa8c340074	drm: Fixup racy refcounting in plane_force_disable [ Upstream commit `8218c3f4df` ] Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit `83f45fc360` Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-23 14:58:19 -04:00
Wenbo Wang	ff06e6e533	Fix bug in blk_rq_merge_ok [ Upstream commit `7ee8e4f398` ] Use the right array index to reference the last element of rq->biotail->bi_io_vec[] Signed-off-by: Wenbo Wang <wenbo.wang@memblaze.com> Reviewed-by: Chong Yuan <chong.yuan@memblaze.com> Fixes: `66cb45aa41` ("block: add support for limiting gaps in SG lists") Cc: stable@kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:32:31 -04:00
Mike Snitzer	06767df271	blk-mq: fix use of incorrect goto label in blk_mq_init_queue error path [ Upstream commit `9a30b096b5` ] If percpu_ref_init() fails the allocated q and hctxs must get cleaned up; using 'err_map' doesn't allow that to happen. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Reviewed-by: Ming Lei <ming.lei@canonical.com> Cc: stable@kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:32:10 -04:00
Joe Perches	9da02d84fe	selinux: fix sel_write_enforce broken return value [ Upstream commit `6436a123a1` ] Return a negative error value like the rest of the entries in this function. Cc: <stable@vger.kernel.org> Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: tweaked subject line] Signed-off-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:32:02 -04:00
Chen-Yu Tsai	5ceacd4db8	ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage [ Upstream commit `fdc0074c5f` ] As the sunxi usb clocks all contain a reset controller, it is not possible to build the sunxi clock driver without RESET_CONTROLLER enabled. Doing so results in an undefined symbol error: drivers/built-in.o: In function `sunxi_gates_clk_setup': linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to `reset_controller_register' This is possible if building a minimal kernel without PHY_SUN4I_USB. The dependency issue is made visible at compile time instead of link time by the new A80 mmc clocks, which also use a reset control itself. This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER. Fixes: `559482d1f9` ARM: sunxi: Split the various SoCs support in Kconfig Cc: <stable@vger.kernel.org> # 3.16+ Reported-by: Lourens Rozema <ik@lourensrozema.nl> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:31:52 -04:00
Vineet Gupta	654acb340d	ARC: signal handling robustify [ Upstream commit `e4140819da` ] A malicious signal handler / restorer can DOS the system by fudging the user regs saved on stack, causing weird things such as sigreturn returning to user mode PC but cpu state still being kernel mode.... Ensure that in sigreturn path status32 always has U bit; any other bogosity (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms. Reproducer signal handler: void handle_sig(int signo, siginfo_t info, void context) { ucontext_t uc = context; struct user_regs_struct regs = &(uc->uc_mcontext.regs); regs->scratch.status32 = 0; } Before the fix, kernel would go off to weeds like below: --------->8----------- [ARCLinux]$ ./signal-test Path: /signal-test CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65 task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000 [ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698 [EFA ]: 0x00000010 [BLINK ]: 0x2007c1ee [ERET ]: 0x10698 [STAT32]: 0x00000000 : <-------- BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000 LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000 ... --------->8----------- Reported-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: <stable@vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:31:18 -04:00
Vineet Gupta	b0864666b2	ARC: SA_SIGINFO ucontext regs off-by-one [ Upstream commit `6914e1e3f6` ] The regfile provided to SA_SIGINFO signal handler as ucontext was off by one due to pt_regs gutter cleanups in 2013. Before handling signal, user pt_regs are copied onto user_regs_struct and copied back later. Both structs are binary compatible. This was all fine until commit `2fa919045b` (ARC: pt_regs update #2) which removed the empty stack slot at top of pt_regs (corresponding to first pad) and made the corresponding fixup in struct user_regs_struct (the pad in there was moved out of @scratch - not removed altogether as it is part of ptrace ABI) struct user_regs_struct { + long pad; struct { - long pad; long bta, lp_start, lp_end,.... } scratch; ... } This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and signal code needs to user_regs_struct.scratch to reflect it as pt_regs, which is what this commit does. This problem was hidden for 2 years, because both save/restore, despite using wrong location, were using the same location. Only an interim inspection (reproducer below) exposed the issue. void handle_segv(int signo, siginfo_t info, void context) { ucontext_t uc = context; struct user_regs_struct regs = &(uc->uc_mcontext.regs); printf("regs %x %x\n", <=== prints 7 8 (vs. 8 9) regs->scratch.r8, regs->scratch.r9); } int main() { struct sigaction sa; sa.sa_sigaction = handle_segv; sa.sa_flags = SA_SIGINFO; sigemptyset(&sa.sa_mask); sigaction(SIGSEGV, &sa, NULL); asm volatile( "mov r7, 7 \n" "mov r8, 8 \n" "mov r9, 9 \n" "mov r10, 10 \n" :::"r7","r8","r9","r10"); ((unsigned int)0x10) = 0; } Fixes: `2fa919045b` "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs" CC: <stable@vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:31:10 -04:00
Matwey V. Kornilov	a78cff341c	PCI: spear: Drop __initdata from spear13xx_pcie_driver [ Upstream commit `a43f32d647` ] Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it to platform_driver_register(), which can use the pointer at arbitrary times in the future, even after the initdata is freed. That leads to crashes. Move spear13xx_pcie_driver and things referenced by it (spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata. [bhelgaas: changelog] Fixes: `6675ef212d` ("PCI: spear: Fix Section mismatch compilation warning for probe()") Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> CC: stable@vger.kernel.org # v3.17+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:31:01 -04:00
Bjorn Helgaas	f31d6097a8	PCI: Don't look for ACPI hotplug parameters if ACPI is disabled [ Upstream commit `8647ca9ad5` ] Booting a v3.18 or newer Xen domU kernel with PCI devices passed through results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0 hypervisor and 32-bit domU): BUG: unable to handle kernel paging request at 0030303e IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a Call Trace: [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0 [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30 [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4 [<c0699d34>] ? pci_device_add+0x24/0x450 Don't look for ACPI configuration information if ACPI has been disabled. I don't think this is the best fix, because we can boot plain Linux (no Xen) with "acpi=off", and we don't need this check in pci_get_hp_params(). There should be a better fix that would make Xen domU work the same way. The domU kernel has ACPI support but it has no AML. There should be a way to initialize the ACPI data structures so things fail gracefully rather than oopsing. This is an interim fix to address the regression. Fixes: `6cd33649fa` ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301 Reported-by: Michael D Labriola <mlabriol@gdeb.com> Tested-by: Michael D Labriola <mlabriol@gdeb.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.18+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:30:27 -04:00
Dan Carpenter	5a3edbcd62	PCI: cpcihp: Add missing curly braces in cpci_configure_slot() [ Upstream commit `bc3b5b47c8` ] I don't have this hardware but it looks like we weren't adding bridge devices as intended. Maybe the bridge is always the last device? Fixes: `05b1250048` ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yijing Wang <wangyijing@huawei.com> CC: stable@vger.kernel.org # v3.9+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:28:34 -04:00
Rasmus Villemoes	02e0fab6a0	PCI/AER: Avoid info leak in __print_tlp_header() [ Upstream commit `a1b7f2f636` ] Commit `fab4c256a5` ("PCI/AER: Add a TLP header print helper") introduced the helper function __print_tlp_header(), but contrary to the intention, the behaviour did change: Since we're taking the address of the parameter t, the first 4 or 8 bytes printed will be the value of the pointer t itself, and the remaining 12 or 8 bytes will be who-knows-what (something from the stack). We want to show the values of the four members of the struct aer_header_log_regs; that can be done without ugly and error-prone casts. On little-endian this should produce the same output as originally intended, and since no-one has complained about getting garbage output so far, I think big-endian should be ok too. Fixes: `fab4c256a5` ("PCI/AER: Add a TLP header print helper") Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Borislav Petkov <bp@suse.de> CC: stable@vger.kernel.org # v3.14+ Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:28:22 -04:00
Takashi Iwai	e045a4c598	ALSA: hda - Fix headphone pin config for Lifebook T731 [ Upstream commit `cc7016ab1a` ] Some BIOS version of Fujitsu Lifebook T731 seems to set up the headphone pin (0x21) without the assoc number 0x0f while it's set only to the output on the docking port (0x1a). With the recent commit [`03ad6a8c93`: ALSA: hda - Fix "PCM" name being used on one DAC when there are two DACs], this resulted in the weird mixer element mapping where the headphone on the laptop is assigned as a shared volume with the speaker and the docking port is assigned as an individual headphone. This patch improves the situation by correcting the headphone pin config to the more appropriate value. Reported-and-tested-by: Taylor Smock <smocktaylor@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:28:14 -04:00
Kailang Yang	432b1f9b27	ALSA: hda/realtek - Make more stable to get pin sense for ALC283 [ Upstream commit `a59d7199f6` ] Pin sense will active when power pin is wake up. Power pin will not wake up immediately during resume state. Add some delay to wait for power pin activated. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:28:06 -04:00
Takashi Sakamoto	8c54c7cb6f	ALSA: bebob: fix to processing in big-endian machine for sending cue [ Upstream commit `a053fc318b` ] Some M-Audio devices require to receive bootup command just after powering on, while codes in BeBoB driver doesn't work properly in big-endian machine because the command should be aligned by little-endian. This commit fixes this bug. This fix should go to stable kernel. Cc: Takayuki Shiroma <t.shiroma.oki@gmail.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:27:58 -04:00
Dmitry M. Fedin	1f1c12d2d4	ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support [ Upstream commit `3dc8523fa7` ] Adds an entry for Creative USB X-Fi to the rc_config array in mixer_quirks.c to allow use of volume knob on the device. Adds support for newer X-Fi Pro card, known as "Model No. SB1095" with USB ID "041e:3237" Signed-off-by: Dmitry M. Fedin <dmitry.fedin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:27:50 -04:00
Hui Wang	e85435779e	ALSA: hda - Add one more node in the EAPD supporting candidate list [ Upstream commit `af95b41426` ] We have a HP machine which use the codec node 0x17 connecting the internal speaker, and from the node capability, we saw the EAPD, if we don't set the EAPD on for this node, the internal speaker can't output any sound. Cc: <stable@vger.kernel.org> BugLink: https://bugs.launchpad.net/bugs/1436745 Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:27:42 -04:00
Sebastian Wicki	fc9a2d469c	ALSA: hda - Add dock support for Thinkpad T450s (17aa:5036) [ Upstream commit `80b311d311` ] This model uses the same dock port as the previous generation. Signed-off-by: Sebastian Wicki <gandro@gmx.net> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-22 23:27:34 -04:00
Peter Hurley	49118e2296	n_tty: Fix read buffer overwrite when no newline [ Upstream commit `fb5ef9e7da` ] BugLink: http://bugs.launchpad.net/bugs/1381005 In canon mode, the read buffer head will advance over the buffer tail if the input > 4095 bytes without receiving a line termination char. Discard additional input until a line termination is received. Before evaluating for overflow, the 'room' value is normalized for I_PARMRK and 1 byte is reserved for line termination (even in !icanon mode, in case the mode is switched). The following table shows the transform: actual buffer \| 'room' value before overflow calc space avail \| !I_PARMRK \| I_PARMRK -------------------------------------------------- 0 \| -1 \| -1 1 \| 0 \| 0 2 \| 1 \| 0 3 \| 2 \| 0 4+ \| 3 \| 1 When !icanon or when icanon and the read buffer contains newlines, normalized 'room' values of -1 and 0 are clamped to 0, and 'overflow' is 0, so read_head is not adjusted and the input i/o loop exits (setting no_room if called from flush_to_ldisc()). No input is discarded since the reader does have input available to read which ensures forward progress. When icanon and the read buffer does not contain newlines and the normalized 'room' value is 0, then overflow and room are reset to 1, so that the i/o loop will process the next input char normally (except for parity errors which are ignored). Thus, erasures, signalling chars, 7-bit mode, etc. will continue to be handled properly. If the input char processed was not a line termination char, then the canon_head index will not have advanced, so the normalized 'room' value will now be -1 and 'overflow' will be set, which indicates the read_head can safely be reset, effectively erasing the last char processed. If the input char processed was a line termination, then the canon_head index will have advanced, so 'overflow' is cleared to 0, the read_head is not reset, and 'room' is cleared to 0, which exits the i/o loop (because the reader now have input available to read which ensures forward progress). Note that it is possible for a line termination to be received, and for the reader to copy the line to the user buffer before the input i/o loop is ready to process the next input char. This is why the i/o loop recomputes the room/overflow state with every input char while handling overflow. Finally, if the input data was processed without receiving a line termination (so that overflow is still set), the pty driver must receive a write wakeup. A pty writer may be waiting to write more data in n_tty_write() but without unthrottling here that wakeup will not arrive, and forward progress will halt. (Normally, the pty writer is woken when the reader reads data out of the buffer and more space become available). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit `fb5ef9e7da`) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>	2015-04-22 23:26:53 -04:00
Sasha Levin	43f497a203	Linux 3.18.12 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-20 15:48:02 -04:00
Ameya Palande	bc94325817	mfd: kempld-core: Fix callback return value check [ Upstream commit `c8648508eb` ] On success, callback function returns 0. So invert the if condition check so that we can break out of loop. Cc: stable@vger.kernel.org Signed-off-by: Ameya Palande <2ameya@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:19 -04:00
Markos Chandras	5f40212836	net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5} [ Upstream commit `87f966d97b` ] On a MIPS Malta board, tons of fifo underflow errors have been observed when using u-boot as bootloader instead of YAMON. The reason for that is that YAMON used to set the pcnet device to SRAM mode but u-boot does not. As a result, the default Tx threshold (64 bytes) is now too small to keep the fifo relatively used and it can result to Tx fifo underflow errors. As a result of which, it's best to setup the SRAM on supported controllers so we can always use the NOUFLO bit. Cc: <netdev@vger.kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Cc: Don Fry <pcnet32@frontier.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:18 -04:00
Scott Wood	7b1b437605	powerpc/mpc85xx: Add ranges to etsec2 nodes [ Upstream commit `bb344ca5b9` ] Commit `746c9e9f92` "of/base: Fix PowerPC address parsing hack" limited the applicability of the workaround whereby a missing ranges is treated as an empty ranges. This workaround was hiding a bug in the etsec2 device tree nodes, which have children with reg, but did not have ranges. Signed-off-by: Scott Wood <scottwood@freescale.com> Reported-by: Alexander Graf <agraf@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:18 -04:00
Tyrel Datwyler	950b82542c	powerpc/pseries: Little endian fixes for post mobility device tree update [ Upstream commit `f6ff041496` ] We currently use the device tree update code in the kernel after resuming from a suspend operation to re-sync the kernels view of the device tree with that of the hypervisor. The code as it stands is not endian safe as it relies on parsing buffers returned by RTAS calls that thusly contains data in big endian format. This patch annotates variables and structure members with __be types as well as performing necessary byte swaps to cpu endian for data that needs to be parsed. Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com> Cc: Cyril Bur <cyrilbur@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:17 -04:00
Catalin Marinas	20ecb85c6e	arm64: Use the reserved TTBR0 if context switching to the init_mm [ Upstream commit `e53f21bce4` ] The idle_task_exit() function may call switch_mm() with next == &init_mm. On arm64, init_mm.pgd cannot be used for user mappings, so this patch simply sets the reserved TTBR0. Cc: <stable@vger.kernel.org> Reported-by: Jon Medhurst (Tixy) <tixy@linaro.org> Tested-by: Jon Medhurst (Tixy) <tixy@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:17 -04:00
Keerthy	3d8fc13835	regulator: palmas: Correct TPS659038 register definition for REGEN2 [ Upstream commit `e03826d504` ] The register offset for REGEN2_CTRL in different for TPS659038 chip as when compared with other Palmas family PMICs. In the case of TPS659038 the wrong offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:16 -04:00
Mahesh Salgaonkar	bac01bf2da	powerpc/book3s: Fix the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER [ Upstream commit `44d5f6f590` ] commit id `2ba9f0d` has changed CONFIG_KVM_BOOK3S_64_HV to tristate to allow HV/PR bits to be built as modules. But the MCE code still depends on CONFIG_KVM_BOOK3S_64_HV which is wrong. When user selects CONFIG_KVM_BOOK3S_64_HV=m to build HV/PR bits as a separate module the relevant MCE code gets excluded. This patch fixes the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER. This makes sure that the relevant MCE code is included when HV/PR bits are built as a separate modules. Fixes: `2ba9f0d887` ("kvm: powerpc: book3s: Support building HV and PR KVM as module") Cc: stable@vger.kernel.org # v3.14+ Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Acked-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:16 -04:00
Tony Luck	32ac769b9d	sb_edac: Fix typo computing number of banks [ Upstream commit `fec53af531` ] Code will always think there are 16 banks because of a typo Reported-by: Misha Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Aristeu Rozanski <aris@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:15 -04:00
Tony Luck	e3d11d50ec	sb_edac: Fix discovery of top-of-low-memory for Haswell [ Upstream commit `f7cf2a22a2` ] Haswell moved the TOLM/TOHM registers to a different device and offset. The sb_edac driver accounted for the change of device, but not for the new offset. There was also a typo in the constant to fill in the low 26 bits (was 0x1ffffff, should be 0x3ffffff). This resulted in a bogus value for the top of low memory: EDAC DEBUG: get_memory_layout: TOLM: 0.032 GB (0x0000000001ffffff) which would result in EDAC refusing to translate addresses for errors above the bogus value and below 4GB: sbridge MC3: HANDLING MCE MEMORY ERROR sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 sbridge MC3: TSC 0 sbridge MC3: ADDR 2000000 sbridge MC3: MISC 523eac86 sbridge MC3: PROCESSOR 0:306f3 TIME 1414600951 SOCKET 0 APIC 0 MC3: 1 CE Error at TOLM area, on addr 0x02000000 on any memory ( page:0x0 offset:0x0 grain:32 syndrome:0x0) With the fix we see the correct TOLM value: DEBUG: get_memory_layout: TOLM: 2.048 GB (0x000000007fffffff) and we decode address 2000000 correctly: sbridge MC3: HANDLING MCE MEMORY ERROR sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 sbridge MC3: TSC 0 sbridge MC3: ADDR 2000000 sbridge MC3: MISC 523e1086 sbridge MC3: PROCESSOR 0:306f3 TIME 1414601319 SOCKET 0 APIC 0 DEBUG: get_memory_error_data: SAD interleave package: 0 = CPU socket 0, HA 0, shiftup: 0 DEBUG: get_memory_error_data: TAD#0: address 0x0000000002000000 < 0x000000007fffffff, socket interleave 1, channel interleave 4 (offset 0x00000000), index 0, base ch: 0, ch mask: 0x01 DEBUG: get_memory_error_data: RIR#0, limit: 4.095 GB (0x00000000ffffffff), way: 1 DEBUG: get_memory_error_data: RIR#0: channel address 0x00200000 < 0xffffffff, RIR interleave 0, index 0 DEBUG: sbridge_mce_output_error: area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0 MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x2000 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Aristeu Rozanski <aris@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:15 -04:00
Ilya Dryomov	310ba06e51	Revert "libceph: use memalloc flags for net IO" [ Upstream commit `6d7fdb0ab3` ] This reverts commit `89baaa570a`. Dirty page throttling should be sufficient for us in the general case so there is no need to use __GFP_MEMALLOC - it would be needed only in the swap-over-rbd case, which we currently don't support. (It would probably take approximately the commit that is being reverted to add that support, but we would also need the "swap" option to distinguish from the general case and make sure swap ceph_client-s aren't shared with anything else.) See ceph-devel threads [1] and [2] for the details of why enabling pfmemalloc reserves for all cases is a bad thing. On top of potential system lockups related to drained emergency reserves, this turned out to cause ceph lockups in case peers are on the same host and communicating via loopback due to sk_filter() dropping pfmemalloc skbs on the receiving side because the receiving loopback socket is not tagged with SOCK_MEMALLOC. [1] "SOCK_MEMALLOC vs loopback" http://www.spinics.net/lists/ceph-devel/msg22998.html [2] "[PATCH] libceph: don't set memalloc flags in loopback case" http://www.spinics.net/lists/ceph-devel/msg23392.html Conflicts: net/ceph/messenger.c [ context: tcp_nodelay option ] Cc: Mike Christie <michaelc@cs.wisc.edu> Cc: Mel Gorman <mgorman@suse.de> Cc: Sage Weil <sage@redhat.com> Cc: stable@vger.kernel.org # 3.18+, needs backporting Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Acked-by: Mike Christie <michaelc@cs.wisc.edu> Acked-by: Mel Gorman <mgorman@suse.de> [idryomov@gmail.com: backport to 3.18, 3.19: context] Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:14 -04:00
Sergei Antonov	44f6282e37	hfsplus: fix B-tree corruption after insertion at position 0 [ Upstream commit `98cf21c61a` ] Fix B-tree corruption when a new record is inserted at position 0 in the node in hfs_brec_insert(). In this case a hfs_brec_update_parent() is called to update the parent index node (if exists) and it is passed hfs_find_data with a search_key containing a newly inserted key instead of the key to be updated. This results in an inconsistent index node. The bug reproduces on my machine after an extents overflow record for the catalog file (CNID=4) is inserted into the extents overflow B-tree. Because of a low (reserved) value of CNID=4, it has to become the first record in the first leaf node. The resulting first leaf node is correct: ---------------------------------------------------- \| key0.CNID=4 \| key1.CNID=123 \| key2.CNID=456, ... \| ---------------------------------------------------- But the parent index key0 still contains the previous key CNID=123: ----------------------- \| key0.CNID=123 \| ... \| ----------------------- A change in hfs_brec_insert() makes hfs_brec_update_parent() work correctly by preventing it from getting fd->record=-1 value from __hfs_brec_find(). Along the way, I removed duplicate code with unification of the if condition. The resulting code is equivalent to the original code because node is never 0. Also hfs_brec_update_parent() will now return an error after getting a negative fd->record value. However, the return value of hfs_brec_update_parent() is not checked anywhere in the file and I'm leaving it unchanged by this patch. brec.c lacks error checking after some other calls too, but this issue is of less importance than the one being fixed by this patch. Signed-off-by: Sergei Antonov <saproj@gmail.com> Cc: Joe Perches <joe@perches.com> Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Anton Altaparmakov <aia21@cam.ac.uk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:14 -04:00
Uwe Kleine-König	ea4e289c28	spi: trigger trace event for message-done before mesg->complete [ Upstream commit `391949b6f0` ] With spidev the mesg->complete callback points to spidev_complete. Calling this unblocks spidev_sync and so spidev_sync_write finishes. As the struct spi_message just read is a local variable in spidev_sync_write and recording the trace event accesses this message the recording is better done first. The same can happen for spidev_sync_read. This fixes an oops observed on a 3.14-rt system with spidev activity after echo 1 > /sys/kernel/debug/tracing/events/spi/enable . Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:13 -04:00
Ivan T. Ivanov	7cc582d4ae	spi: qup: Fix cs-num DT property parsing [ Upstream commit `12cb89e37a` ] num-cs is 32 bit property, don't read just upper 16 bits. Fixes: `4a8573abe9` (spi: qup: Remove chip select function) Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:12 -04:00
Mikulas Patocka	c280422c27	dm snapshot: suspend merging snapshot when doing exception handover [ Upstream commit `09ee96b214` ] The "dm snapshot: suspend origin when doing exception handover" commit fixed a exception store handover bug associated with pending exceptions to the "snapshot-origin" target. However, a similar problem exists in snapshot merging. When snapshot merging is in progress, we use the target "snapshot-merge" instead of "snapshot-origin". Consequently, during exception store handover, we must find the snapshot-merge target and suspend its associated mapped_device. To avoid lockdep warnings, the target must be suspended and resumed without holding _origins_lock. Introduce a dm_hold() function that grabs a reference on a mapped_device, but unlike dm_get(), it doesn't crash if the device has the DMF_FREEING flag set, it returns an error in this case. In snapshot_resume() we grab the reference to the origin device using dm_hold() while holding _origins_lock (_origins_lock guarantees that the device won't disappear). Then we release _origins_lock, suspend the device and grab _origins_lock again. NOTE to stable@ people: When backporting to kernels 3.18 and older, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:13:10 -04:00
Mikulas Patocka	306d712286	dm snapshot: suspend origin when doing exception handover [ Upstream commit `b735fede8d` ] In the function snapshot_resume we perform exception store handover. If there is another active snapshot target, the exception store is moved from this target to the target that is being resumed. The problem is that if there is some pending exception, it will point to an incorrect exception store after that handover, causing a crash due to dm-snap-persistent.c:get_exception()'s BUG_ON. This bug can be triggered by repeatedly changing snapshot permissions with "lvchange -p r" and "lvchange -p rw" while there are writes on the associated origin device. To fix this bug, we must suspend the origin device when doing the exception store handover to make sure that there are no pending exceptions: - introduce _origin_hash that keeps track of dm_origin structures. - introduce functions __lookup_dm_origin, __insert_dm_origin and __remove_dm_origin that manipulate the origin hash. - modify snapshot_resume so that it calls dm_internal_suspend_fast() and dm_internal_resume_fast() on the origin device. NOTE to stable@ people: When backporting to kernels 3.12-3.18, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. When backporting to kernels older than 3.12, you need to pick functions dm_internal_suspend and dm_internal_resume from the commit `fd2ed4d252`. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:12:50 -04:00
Sasha Levin	58533aecce	dm thin: fix to consistently zero-fill reads to unprovisioned blocks [ Upstream commit `5f027a3bf1` ] It was always intended that a read to an unprovisioned block will return zeroes regardless of whether the pool is in read-only or read-write mode. thin_bio_map() was inconsistent with its handling of such reads when the pool is in read-only mode, it now properly zero-fills the bios it returns in response to unprovisioned block reads. Eliminate thin_bio_map()'s special read-only mode handling of -ENODATA and just allow the IO to be deferred to the worker which will result in pool->process_bio() handling the IO (which already properly zero-fills reads to unprovisioned blocks). Reported-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:47 -04:00
Darrick J. Wong	0f4687c37c	dm io: deal with wandering queue limits when handling REQ_DISCARD and REQ_WRITE_SAME [ Upstream commit `e5db29806b` ] Since it's possible for the discard and write same queue limits to change while the upper level command is being sliced and diced, fix up both of them (a) to reject IO if the special command is unsupported at the start of the function and (b) read the limits once and let the commands error out on their own if the status happens to change. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:46 -04:00
Mikulas Patocka	28bd7dd371	dm: hold suspend_lock while suspending device during device deletion [ Upstream commit `ab7c7bb6f4` ] __dm_destroy() must take the suspend_lock so that its presuspend and postsuspend calls do not race with an internal suspend. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:45 -04:00
Andy Shevchenko	b648dce3a9	dmaengine: dw: append MODULE_ALIAS for platform driver [ Upstream commit `a104a45ba7` ] The commit `9cade1a46c` (dma: dw: split driver to library part and platform code) introduced a separate platform driver but missed to add a MODULE_ALIAS("platform:dw_dmac"); to that module. The patch adds this to get driver loaded automatically if platform device is registered. Reported-by: "Blin, Jerome" <jerome.blin@intel.com> Fixes: `9cade1a46c` (dma: dw: split driver to library part and platform code) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:45 -04:00
Malcolm Priestley	e0bf428e21	vt6655: RFbSetPower fix missing rate RATE_12M [ Upstream commit `40c8790bcb` ] When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:44 -04:00
Malcolm Priestley	c1fd7cc2f1	staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M [ Upstream commit `163fe301b9` ] When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:44 -04:00
Peter Zijlstra	f7d84d2b7c	perf: Fix irq_work 'tail' recursion [ Upstream commit `d525211f9d` ] Vince reported a watchdog lockup like: [<ffffffff8115e114>] perf_tp_event+0xc4/0x210 [<ffffffff810b4f8a>] perf_trace_lock+0x12a/0x160 [<ffffffff810b7f10>] lock_release+0x130/0x260 [<ffffffff816c7474>] _raw_spin_unlock_irqrestore+0x24/0x40 [<ffffffff8107bb4d>] do_send_sig_info+0x5d/0x80 [<ffffffff811f69df>] send_sigio_to_task+0x12f/0x1a0 [<ffffffff811f71ce>] send_sigio+0xae/0x100 [<ffffffff811f72b7>] kill_fasync+0x97/0xf0 [<ffffffff8115d0b4>] perf_event_wakeup+0xd4/0xf0 [<ffffffff8115d103>] perf_pending_event+0x33/0x60 [<ffffffff8114e3fc>] irq_work_run_list+0x4c/0x80 [<ffffffff8114e448>] irq_work_run+0x18/0x40 [<ffffffff810196af>] smp_trace_irq_work_interrupt+0x3f/0xc0 [<ffffffff816c99bd>] trace_irq_work_interrupt+0x6d/0x80 Which is caused by an irq_work generating new irq_work and therefore not allowing forward progress. This happens because processing the perf irq_work triggers another perf event (tracepoint stuff) which in turn generates an irq_work ad infinitum. Avoid this by raising the recursion counter in the irq_work -- which effectively disables all software events (including tracepoints) from actually triggering again. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Tested-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20150219170311.GH21418@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:43 -04:00
Laurent Pinchart	225d923571	of/irq: Fix of_irq_parse_one() returned error codes [ Upstream commit `d7c146053d` ] The error code paths that require cleanup use a goto to jump to the cleanup code and return an error code. However, the error code variable res, which is initialized to -EINVAL when declared, is then overwritten with the return value of of_parse_phandle_with_args(), and reused as the return code from of_irq_parse_one(). This leads to an undetermined error being returned instead of the expected -EINVAL value. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: stable@vger.kernel.org # 3.13+ Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:42 -04:00
Gregory CLEMENT	542a92093e	cpuidle: mvebu: Fix the CPU PM notifier usage [ Upstream commit `43b68879de` ] As stated in kernel/cpu_pm.c, "Platform is responsible for ensuring that cpu_pm_enter is not called twice on the same CPU before cpu_pm_exit is called.". In the current code in case of failure when calling mvebu_v7_cpu_suspend, the function cpu_pm_exit() is never called whereas cpu_pm_enter() was called just before. This patch moves the cpu_pm_exit() in order to balance the cpu_pm_enter() calls. Cc: stable@vger.kernel.org Reported-by: Fulvio Benini <fbf@libero.it> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:42 -04:00
Larry Finger	240e177bb4	rtlwifi: Improve handling of IPv6 packets [ Upstream commit `c8f0345586` ] Routine rtl_is_special_data() is supposed to identify packets that need to use a low bit rate so that the probability of successful transmission is high. The current version has a bug that causes all IPv6 packets to be labelled as special, with a corresponding low rate of transmission. A complete fix will be quite intrusive, but until that is available, all IPv6 packets are identified as regular. This patch also removes a magic number. Reported-and-tested-by: Alan Fisher <acf@unixcube.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.18+] Cc: Alan Fisher <acf@unixcube.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:41 -04:00
Thierry Reding	59bbaa453d	phy: Find the right match in devm_phy_destroy() [ Upstream commit `2f1bce487c` ] devm_phy_create() stores the pointer to the new PHY at the address returned by devres_alloc(). The res parameter passed to devm_phy_match() is therefore the location where the pointer to the PHY is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Cc: <stable@vger.kernel.org> # v3.13+ Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:41 -04:00
Peter Chen	bf8935d8ac	usb: common: otg-fsm: only signal connect after switching to peripheral [ Upstream commit `a886bd9226` ] We should signal connect (pull up dp) after we have already at peripheral mode, otherwise, the dp may be toggled due to we reset controller or do disconnect during the initialization for peripheral, then, the host may be confused during the enumeration, eg, it finds the reset can't succeed, but the device is still there, see below error message. hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: unable to enumerate USB device on port 1 Fixes: the issue existed when the otg fsm code was added. Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:40 -04:00
Li Jun	efbf141e9c	usb: chipidea: otg: add a_alt_hnp_support response for B device [ Upstream commit `d20f780799` ] This patch adds response to a_alt_hnp_support set feature request from legacy A device, that is, B-device can provide a message to the user indicating that the user needs to connect the B-device to an alternate port on the A-device. A device sets this feature indicates to the B-device that it is connected to an A-device port that is not capable of HNP, but that the A-device does have an alternate port that is capable of HNP. [Peter] Without this patch, the OTG B device can't be enumerated on non-HNP port at A device, see below log: [ 2.287464] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.293105] usb 1-1: can't set HNP mode: -32 [ 2.417422] usb 1-1: new high-speed USB device number 4 using ci_hdrc [ 2.460635] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.466424] usb 1-1: can't set HNP mode: -32 [ 2.587464] usb 1-1: new high-speed USB device number 5 using ci_hdrc [ 2.630649] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.636436] usb 1-1: can't set HNP mode: -32 [ 2.641003] usb usb1-port1: unable to enumerate USB device Cc: stable <stable@vger.kernel.org> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Li Jun <b47624@freescale.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:40 -04:00
David Dueck	de4b9c41c2	usb: phy: am335x-control: check return value of bus_find_device [ Upstream commit `d0f347d628` ] This fixes a potential null pointer dereference. Cc: <stable@vger.kernel.org> # v3.16+ Fixes: `d433201391` ("driver core: dev_get_drvdata: Don't check for NULL dev") Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David Dueck <davidcdueck@googlemail.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:39 -04:00
Hans de Goede	07088f9c1e	uas: Add US_FL_NO_ATA_1X for Initio Corporation controllers / devices [ Upstream commit `bda13e35d5` ] A new uas compatible controller has shown up in some people's devices from the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X quirk to work properly with uas, so add it to the uas quirks table. Reported-and-tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:38 -04:00
Andrei Otcheretianski	e6171aa257	mac80211: count interfaces correctly for combination checks [ Upstream commit `0f611d28fc` ] Since moving the interface combination checks to mac80211, it's broken because it now only considers interfaces with an assigned channel context, so for example any interface that isn't active can still be up, which is clearly an issue; also, in particular P2P-Device wdevs are an issue since they never have a chanctx. Fix this by counting running interfaces instead the ones with a channel context assigned. Cc: stable@vger.kernel.org [3.16+] Fixes: `73de86a389` ("cfg80211/mac80211: move interface counting for combination check to mac80211") Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [rewrite commit message, dig out the commit it fixes] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:38 -04:00
Bob Copeland	d78408c028	mac80211: drop unencrypted frames in mesh fwding [ Upstream commit `d0c22119f5` ] The mesh forwarding path was not checking that data frames were protected when running an encrypted network; add the necessary check. Cc: stable@vger.kernel.org Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:37 -04:00
Michal Kazior	205124bc2c	mac80211: disable u-APSD queues by default [ Upstream commit `aa75ebc275` ] Some APs experience problems when working with U-APSD. Decreasing the probability of that happening by using legacy mode for all ACs but VO isn't enough. Cisco 4410N originally forced us to enable VO by default only because it treated non-VO ACs as legacy. However some APs (notably Netgear R7000) silently reclassify packets to different ACs. Since u-APSD ACs require trigger frames for frame retrieval clients would never see some frames (e.g. ARP responses) or would fetch them accidentally after a long time. It makes little sense to enable u-APSD queues by default because it needs userspace applications to be aware of it to actually take advantage of the possible additional powersavings. Implicitly depending on driver autotrigger frame support doesn't make much sense. Cc: stable@vger.kernel.org Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:37 -04:00
Johannes Berg	3c87039770	nl80211: ignore HT/VHT capabilities without QoS/WMM [ Upstream commit `496fcc294d` ] As HT/VHT depend heavily on QoS/WMM, it's not a good idea to let userspace add clients that have HT/VHT but not QoS/WMM. Since it does so in certain cases we've observed (client is using HT IEs but not QoS/WMM) just ignore the HT/VHT info at this point and don't pass it down to the drivers which might unconditionally use it. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:36 -04:00
Benjamin Tissoires	2786d08b06	Input: synaptics - do not retrieve the board id on old firmwares [ Upstream commit `b57a7128be` ] The board id capability has been added in firmware 7.5. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:35 -04:00
Benjamin Tissoires	4258604ea1	Input: synaptics - handle spurious release of trackstick buttons [ Upstream commit `ebc80840b8` ] The Fimware 8.1 has a bug in which the extra buttons are only sent when the ExtBit is 1. This should be fixed in a future FW update which should have a bump of the minor version. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:35 -04:00
Dmitry Torokhov	376cfea5a6	Input: synaptics - fix middle button on Lenovo 2015 products [ Upstream commit `dc5465dc8a` ] On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle button of the trackstick (attached to the touchpad serio device, of course) seems to get lost. Actually, the touchpads reports 3 extra buttons, which falls in the switch below to the '2' case. Let's handle the case of odd numbers also, so that the middle button finds its way back. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:34 -04:00
Benjamin Tissoires	ad565a9e13	Input: synaptics - skip quirks when post-2013 dimensions [ Upstream commit `02e07492cd` ] Post-2013 Lenovo laptops provide correct min/max dimensions, which are different with the ones currently quirked. According to https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids are assigned in the post-2013 touchpads: t440p/t440s: LEN0036 -> 2964/2962 t540p: LEN0034 -> 2964 Using 2961 as the common minimum makes these 3 laptops OK. We may need to update those values later if other pnp_ids has a lower board_id. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:34 -04:00
Daniel Martin	c22c859798	Input: synaptics - support min/max board id in min_max_pnpid_table [ Upstream commit `5b3089ddb5` ] Add a min/max range for board ids to the min/max coordinates quirk. This makes it possible to restrict quirks to specific models based upon their board id. The define ANY_BOARD_ID (0) serves as a wild card. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by: Daniel Martin <daniel.martin@secunet.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:33 -04:00
Daniel Martin	2f76815667	Input: synaptics - remove obsolete min/max quirk for X240 [ Upstream commit `b05f4d1c33` ] The firmware of the X240 (LEN0035, 2013/12) exposes the same values x [1232..5710], y [1156..4696] as the quirk applies. Cc: stable@vger.kernel.org Signed-off-by: Daniel Martin <consume.noise@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:32 -04:00
Daniel Martin	87602c580a	Input: synaptics - query min dimensions for fw v8.1 [ Upstream commit `ac097930f0` ] Query the min dimensions even if the check SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the firmware version 8.1 is safe. With that we don't need quirks for post-2013 models anymore as they expose correct min and max dimensions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by: Daniel Martin <consume.noise@gmail.com> re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1 Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:32 -04:00
Daniel Martin	20428fd841	Input: synaptics - log queried and quirked dimension values [ Upstream commit `9aff65982d` ] Logging the dimension values we queried and the values we use from a quirk to overwrite can be helpful for debugging. This partly relates to bug: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by: Daniel Martin <consume.noise@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:31 -04:00
Daniel Martin	8784d2e07c	Input: synaptics - split synaptics_resolution(), query first [ Upstream commit `8b04baba10` ] Split the function synaptics_resolution() into synaptics_resolution() and synaptics_quirks(). synaptics_resolution() will be called before synaptics_quirks() to query dimensions and resolutions before overwriting them with quirks. Cc: stable@vger.kernel.org Signed-off-by: Daniel Martin <consume.noise@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:31 -04:00
Bart Van Assche	c4d66c922d	tcm_qla2xxx: Fix incorrect use of __transport_register_session [ Upstream commit `75c3d0bf9c` ] This patch fixes the incorrect use of __transport_register_session() in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list to add new se_sess nodes. Given that tcm_qla2xxx_check_initiator_node_acl() is not called with qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the code should be using transport_register_session() instead. Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:30 -04:00
Dan Carpenter	2223d18c6c	tcm_fc: missing curly braces in ft_invl_hw_context() [ Upstream commit `d556546e7e` ] This patch adds a missing set of conditional check braces in ft_invl_hw_context() originally introduced by commit `dcd998ccd` when handling DDP failures in ft_recv_write_data() code. commit `dcd998ccdb` Author: Kiran Patil <kiran.patil@intel.com> Date: Wed Aug 3 09:20:01 2011 +0000 tcm_fc: Handle DDP/SW fc_frame_payload_get failures in ft_recv_write_data Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Kiran Patil <kiran.patil@intel.com> Cc: <stable@vger.kernel.org> # 3.1+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:30 -04:00
Yongbae Park	3c6527a543	clocksource: efm32: Fix a NULL pointer dereference [ Upstream commit `7b8f10da3b` ] The initialisation of the efm32 clocksource first sets up the irq and only after that initialises the data needed for irq handling. In case this initialisation is delayed the irq handler would dereference a NULL pointer. I'm not aware of anything that could delay the process in such a way, but it's better to be safe than sorry, so setup the irq only when the clock event device is ready. Cc: stable@vger.kernel.org Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yongbae Park <yongbae2@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:29 -04:00
Philipp Zabel	5a0ed0a901	regmap: introduce regmap_name to fix syscon regmap trace events [ Upstream commit `c6b570d97c` ] This patch fixes a NULL pointer dereference when enabling regmap event tracing in the presence of a syscon regmap, introduced by commit `bdb0066df9` ("mfd: syscon: Decouple syscon interface from platform devices"). That patch introduced syscon regmaps that have their dev field set to NULL. The regmap trace events expect it to point to a valid struct device and feed it to dev_name(): $ echo 1 > /sys/kernel/debug/tracing/events/regmap/enable Unable to handle kernel NULL pointer dereference at virtual address 0000002c pgd = 80004000 [0000002c] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: coda videobuf2_vmalloc CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events_freezable thermal_zone_device_check task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000 PC is at ftrace_raw_event_regmap_block+0x3c/0xe4 LR is at _regmap_raw_read+0x1bc/0x1cc pc : [<803636e8>] lr : [<80365f2c>] psr: 600f0093 sp : 9f1efd78 ip : 9f1efdb8 fp : 9f1efdb4 r10: 00000004 r9 : 00000001 r8 : 00000001 r7 : 00000180 r6 : 00000000 r5 : 9f00e3c0 r4 : 00000003 r3 : 00000001 r2 : 00000180 r1 : 00000000 r0 : 9f00e3c0 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 2d91004a DAC: 00000015 Process kworker/0:2 (pid: 304, stack limit = 0x9f1ee210) Stack: (0x9f1efd78 to 0x9f1f0000) fd60: 9f1efda4 9f1efd88 fd80: 800708c0 805f9510 80927140 800f0013 9f1fc800 9eb2f490 00000000 00000180 fda0: 808e3840 00000001 9f1efdfc 9f1efdb8 80365f2c 803636b8 805f8958 800708e0 fdc0: a00f0013 803636ac 9f16de00 00000180 80927140 9f1fc800 9f1fc800 9f1efe6c fde0: 9f1efe6c 9f732400 00000000 00000000 9f1efe1c 9f1efe00 80365f70 80365d7c fe00: 80365f3c 9f1fc800 9f1fc800 00000180 9f1efe44 9f1efe20 803656a4 80365f48 fe20: 9f1fc800 00000180 9f1efe6c 9f1efe6c 9f732400 00000000 9f1efe64 9f1efe48 fe40: 803657bc 80365634 00000001 9e95f910 9f1fc800 9f1efeb4 9f1efe8c 9f1efe68 fe60: 80452ac0 80365778 9f1efe8c 9f1efe78 9e93d400 9e93d5e8 9f1efeb4 9f72ef40 fe80: 9f1efeac 9f1efe90 8044e11c 80452998 8045298c 9e93d608 9e93d400 808e1978 fea0: 9f1efecc 9f1efeb0 8044fd14 8044e0d0 ffffffff 9f25a200 9e93d608 9e481380 fec0: 9f1efedc 9f1efed0 8044fde8 8044fcec 9f1eff1c 9f1efee0 80038d50 8044fdd8 fee0: 9f1ee020 9f72ef40 9e481398 00000000 00000008 9f72ef54 9f1ee020 9f72ef40 ff00: 9e481398 9e481380 00000008 9f72ef40 9f1eff5c 9f1eff20 80039754 80038bfc ff20: 00000000 9e481380 80894100 808e1662 00000000 9e4f2ec0 00000000 9e481380 ff40: 800396f8 00000000 00000000 00000000 9f1effac 9f1eff60 8003e020 80039704 ff60: ffffffff 00000000 ffffffff 9e481380 00000000 00000000 9f1eff78 9f1eff78 ff80: 00000000 00000000 9f1eff88 9f1eff88 9e4f2ec0 8003df30 00000000 00000000 ffa0: 00000000 9f1effb0 8000eb60 8003df3c 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff Backtrace: [<803636ac>] (ftrace_raw_event_regmap_block) from [<80365f2c>] (_regmap_raw_read+0x1bc/0x1cc) r9:00000001 r8:808e3840 r7:00000180 r6:00000000 r5:9eb2f490 r4:9f1fc800 [<80365d70>] (_regmap_raw_read) from [<80365f70>] (_regmap_bus_read+0x34/0x6c) r10:00000000 r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:9f1fc800 r4:9f1fc800 [<80365f3c>] (_regmap_bus_read) from [<803656a4>] (_regmap_read+0x7c/0x144) r6:00000180 r5:9f1fc800 r4:9f1fc800 r3:80365f3c [<80365628>] (_regmap_read) from [<803657bc>] (regmap_read+0x50/0x70) r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:00000180 r4:9f1fc800 [<8036576c>] (regmap_read) from [<80452ac0>] (imx_get_temp+0x134/0x1a4) r6:9f1efeb4 r5:9f1fc800 r4:9e95f910 r3:00000001 [<8045298c>] (imx_get_temp) from [<8044e11c>] (thermal_zone_get_temp+0x58/0x74) r7:9f72ef40 r6:9f1efeb4 r5:9e93d5e8 r4:9e93d400 [<8044e0c4>] (thermal_zone_get_temp) from [<8044fd14>] (thermal_zone_device_update+0x34/0xec) r6:808e1978 r5:9e93d400 r4:9e93d608 r3:8045298c [<8044fce0>] (thermal_zone_device_update) from [<8044fde8>] (thermal_zone_device_check+0x1c/0x20) r5:9e481380 r4:9e93d608 [<8044fdcc>] (thermal_zone_device_check) from [<80038d50>] (process_one_work+0x160/0x3d4) [<80038bf0>] (process_one_work) from [<80039754>] (worker_thread+0x5c/0x4f4) r10:9f72ef40 r9:00000008 r8:9e481380 r7:9e481398 r6:9f72ef40 r5:9f1ee020 r4:9f72ef54 [<800396f8>] (worker_thread) from [<8003e020>] (kthread+0xf0/0x108) r10:00000000 r9:00000000 r8:00000000 r7:800396f8 r6:9e481380 r5:00000000 r4:9e4f2ec0 [<8003df30>] (kthread) from [<8000eb60>] (ret_from_fork+0x14/0x34) r7:00000000 r6:00000000 r5:8003df30 r4:9e4f2ec0 Code: e3140040 1a00001a e3140020 `1a000016` (e596002c) ---[ end trace 193c15c2494ec960 ]--- Fixes: `bdb0066df9` (mfd: syscon: Decouple syscon interface from platform devices) Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:29 -04:00
Lars-Peter Clausen	7ac888f30d	regmap: regcache-rbtree: Fix present bitmap resize [ Upstream commit `328f494d95` ] When inserting a new register into a block at the lower end the present bitmap is currently shifted into the wrong direction. The effect of this is that the bitmap becomes corrupted and registers which are present might be reported as not present and vice versa. Fix this by shifting left rather than right. Fixes: 472fdec7380c("regmap: rbtree: Reduce number of nodes, take 2") Reported-by: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:28 -04:00
Yongbae Park	5820c59b7d	clockevents: sun5i: Fix setup_irq init sequence [ Upstream commit `1096be084a` ] The interrupt is enabled before the handler is set. Even this bug did not appear, it is potentially dangerous as it can lead to a NULL pointer dereference. Fix the error by enabling the interrupt after clockevents_config_and_register() is called. Cc: stable@vger.kernel.org Signed-off-by: Yongbae Park <yongbae2@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:27 -04:00
Michael S. Tsirkin	c436954309	virtio-balloon: do not call blocking ops when !TASK_RUNNING [ Upstream commit `3d2a3774c1` ] virtio balloon has this code: wait_event_interruptible(vb->config_change, (diff = towards_target(vb)) != 0 \|\| vb->need_stats_update \|\| kthread_should_stop() \|\| freezing(current)); Which is a problem because towards_target() call might block after wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing the task_struct::state collision typical of nesting of sleeping primitives See also http://lwn.net/Articles/628628/ or Thomas's bug report http://article.gmane.org/gmane.linux.kernel.virtualization/24846 for a fuller explanation. To fix, rewrite using wait_woken. Cc: stable@vger.kernel.org Reported-by: Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Thomas Huth <thuth@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:27 -04:00
Peter Zijlstra	32384effc1	sched/wait: Provide infrastructure to deal with nested blocking [ Upstream commit `61ada528de` ] There are a few places that call blocking primitives from wait loops, provide infrastructure to support this without the typical task_struct::state collision. We record the wakeup in wait_queue_t::flags which leaves task_struct::state free to be used by others. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: tglx@linutronix.de Cc: ilya.dryomov@inktank.com Cc: umgwanakikbuti@gmail.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20140924082242.051202318@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-16 20:11:19 -04:00
Michael S. Tsirkin	2e7822fa33	virtio_balloon: set DRIVER_OK before using device [ Upstream commit `88660f7fb9` ] virtio spec requires that all drivers set DRIVER_OK before using devices. While balloon isn't yet included in the virtio 1 spec, previous spec versions also required this. virtio balloon might violate this rule: probe calls kthread_run before setting DRIVER_OK, which might run immediately and cause balloon to inflate/deflate. To fix, call virtio_device_ready before running the kthread. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:58:20 -04:00
Takashi Iwai	2eb57b35ee	ASoC: wm8955: Fix wrong value references for boolean kctl [ Upstream commit `07892b1035` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:42:33 -04:00
Takashi Iwai	83ebc44473	ASoC: adav80x: Fix wrong value references for boolean kctl [ Upstream commit `2bf4c1d483` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:42:24 -04:00
Takashi Iwai	12708c851a	ASoC: ak4641: Fix wrong value references for boolean kctl [ Upstream commit `08641d9b7b` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:42:16 -04:00
Takashi Iwai	26e34b2204	ASoC: wm8904: Fix wrong value references for boolean kctl [ Upstream commit `eaddf6fd95` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:42:08 -04:00
Takashi Iwai	a4622f5303	ASoC: wm8903: Fix wrong value references for boolean kctl [ Upstream commit `24cc883c1f` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:42:00 -04:00
Takashi Iwai	39a6e41672	ASoC: wm2000: Fix wrong value references for boolean kctl [ Upstream commit `00a14c2968` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:51 -04:00
Takashi Iwai	6755eab9d6	ASoC: wm8731: Fix wrong value references for boolean kctl [ Upstream commit `bd14016fbf` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:43 -04:00
Takashi Iwai	5841b1d709	ASoC: tas5086: Fix wrong value references for boolean kctl [ Upstream commit `4c523ef611` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:35 -04:00
Takashi Iwai	238cb9052d	ASoC: wm8960: Fix wrong value references for boolean kctl [ Upstream commit `b4a18c8b1a` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:28 -04:00
Takashi Iwai	deb426a463	ASoC: es8238: Fix wrong value references for boolean kctl [ Upstream commit `d223b0e7fc` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:20 -04:00
Takashi Iwai	1ad7b2862e	ASoC: cs4271: Fix wrong value references for boolean kctl [ Upstream commit `e8371aa0fe` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:12 -04:00
Takashi Iwai	586e6dd08f	ASoC: pcm1681: Fix wrong value references for boolean kctl [ Upstream commit `d7f58db49d` ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:41:04 -04:00
Eric Nelson	dd7445688e	ASoC: sgtl5000: remove useless register write clearing CHRGPUMP_POWERUP [ Upstream commit `c7d910b87d` ] The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached value instead of writing it directly. Patch inspired by Russell King's more colorful remarks in this patch: https://github.com/SolidRun/linux-imx6-3.14/commit/dd4bf6a Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:40:56 -04:00
Lars-Peter Clausen	db17146a0d	ASoC: sn95031: Fix control-less DAPM routes [ Upstream commit `cdd3d2a93f` ] Routes without a control must use NULL for the control name. The sn95031 driver uses "NULL" instead in a few places. Previous to commit `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the sn95031 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:40:48 -04:00
Lars-Peter Clausen	4ac22da9d8	ASoC: ak4671: Fix control-less DAPM routes [ Upstream commit `ce9594c6b3` ] Routes without a control must use NULL for the control name. The ak4671 driver uses "NULL" instead in a few places. Previous to commit `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the ak4671 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:40:40 -04:00
Lars-Peter Clausen	cab451cce5	ASoC: da732x: Fix control-less DAPM routes [ Upstream commit `8e6a75c102` ] Routes without a control must use NULL for the control name. The da732x driver uses "NULL" instead in a few places. Previous to commit `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the da732x driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-09 18:40:32 -04:00
Sasha Levin	f154a14e3e	Linux 3.18.11 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-04-03 22:46:37 -04:00
Nicholas Bellinger	4c23efb4e6	target/pscsi: Fix NULL pointer dereference in get_device_type [ Upstream commit `215a8fe419` ] This patch fixes a NULL pointer dereference OOPs with pSCSI backends within target_core_stat.c code. The bug is caused by a configfs attr read if no pscsi_dev_virt->pdv_sd has been configured. Reported-by: Olaf Hering <olaf@aepfle.de> Cc: <stable@vger.kernel.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:23:20 -04:00
Nicholas Bellinger	af8524b010	iscsi-target: Avoid early conn_logout_comp for iser connections [ Upstream commit `f068fbc82e` ] This patch fixes a iser specific logout bug where early complete() of conn->conn_logout_comp in iscsit_close_connection() was causing isert_wait4logout() to complete too soon, triggering a use after free NULL pointer dereference of iscsi_conn memory. The complete() was originally added for traditional iscsi-target when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given iser-target does not wait in logout failure, this special case needs to be avoided. Reported-by: Sagi Grimberg <sagig@mellanox.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Slava Shwartsman <valyushash@gmail.com> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:23:13 -04:00
Nicholas Bellinger	b54521a3bf	target: Fix virtual LUN=0 target_configure_device failure OOPs [ Upstream commit `5f7da044f8` ] This patch fixes a NULL pointer dereference triggered by a late target_configure_device() -> alloc_workqueue() failure that results in target_free_device() being called with DF_CONFIGURED already set, which subsequently OOPses in destroy_workqueue() code. Currently this only happens at modprobe target_core_mod time when core_dev_setup_virtual_lun0() -> target_configure_device() fails, and the explicit target_free_device() gets called. To address this bug originally introduced by commit `0fd97ccf45`, go ahead and move DF_CONFIGURED to end of target_configure_device() code to handle this special failure case. Reported-by: Claudio Fleiner <cmf@daterainc.com> Cc: Claudio Fleiner <cmf@daterainc.com> Cc: Christoph Hellwig <hch@lst.de> Cc: <stable@vger.kernel.org> # v3.7+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:23:05 -04:00
Bart Van Assche	6526d32f6b	target: Fix reference leak in target_get_sess_cmd() error path [ Upstream commit `7544e59734` ] This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down is true within target_get_sess_cmd() submission path code. This se_cmd reference leak can occur during active session shutdown when ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers. Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: <stable@vger.kernel.org> # 3.6+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:58 -04:00
Vignesh R	5ef7008ba1	ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx [ Upstream commit `7d53d25578` ] ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck. The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the functional clock of pwmss (l4ls_gclk). Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk. Fixes: `4da1c67719` ("add tbclk data for ehrpwm") Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:50 -04:00
Vignesh R	25d96d6b6b	ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx [ Upstream commit `6e22616eba` ] ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck. The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the functional clock of pwmss (l4ls_gclk). Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk. Fixes: `9e100ebafb`: ("Fix ehrpwm tbclk data") Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:42 -04:00
Ravikumar Kattekola	0755481749	ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others [ Upstream commit `d2192ea098` ] Fixes: `ee6c750761` (ARM: dts: dra7 clock data) On DRA7x, For DPLL_IVA, the ref clock(CLKINP) is connected to sys_clk1 and the bypass input(CLKINPULOW) is connected to iva_dpll_hs_clk_div clock. But the bypass input is not directly routed to bypass clkout instead both CLKINP and CLKINPULOW are connected to bypass clkout via a mux. This mux is controlled by the bit - CM_CLKSEL_DPLL_IVA[23]:DPLL_BYP_CLKSEL and it's POR value is zero which selects the CLKINP as bypass clkout. which means iva_dpll_hs_clk_div is not the bypass clock for dpll_iva_ck Fix this by adding another mux clock as parent in bypass mode. This design is common to most of the PLLs and the rest have only one bypass clock. Below is a list of the DPLLs that need this fix: DPLL_IVA, DPLL_DDR, DPLL_DSP, DPLL_EVE, DPLL_GMAC, DPLL_PER, DPLL_USB and DPLL_CORE Signed-off-by: Ravikumar Kattekola <rk@ti.com> Acked-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:35 -04:00
Alexandre Belloni	d409e2e694	ARM: at91: pm: fix at91rm9200 standby [ Upstream commit `84e871660b` ] at91rm9200 standby and suspend to ram has been broken since `00482a4078`. It is wrongly using AT91_BASE_SYS which is a physical address and actually doesn't correspond to any register on at91rm9200. Use the correct at91_ramc_base[0] instead. Fixes: `00482a4078` (ARM: at91: implement the standby function for pm/cpuidle) Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:28 -04:00
Peter Chen	1e29f16a9b	ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg [ Upstream commit `40f737791d` ] USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's parent reg, it fixed a bug that the voltage of vbus is incorrect due to swbst_reg is disabled after boots up. Cc: stable@vger.kernel.org Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:22:20 -04:00
Daniel J Blueman	f8ac6343a3	x86: numachip: Fix 16-bit APIC ID truncation [ Upstream commit `00e7977dd1` ] Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes booting large systems, where the wrong core would receive the startup and init IPIs, causing hanging. Signed-off-by: Daniel J Blueman <daniel@numascale.com> Cc: Steffen Persvold <sp@numascale.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: http://lkml.kernel.org/r/1415089784-28779-1-git-send-email-daniel@numascale.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:08:32 -04:00
Jiri Slaby	ad92776986	x86/vdso: Fix the build on GCC5 [ Upstream commit `e893286918` ] On gcc5 the kernel does not link: ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670. Because prior GCC versions always emitted NOPs on ALIGN directives, but gcc5 started omitting them. .LSTARTFDEDLSI1 says: /* HACK: The dwarf2 unwind routines will subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we didn't get here via a call, we need to include the nop before the real start to make up for it. / .long .LSTART_sigreturn-1-. / PC-relative start address */ But commit `69d0627a7f` ("x86 vDSO: reorder vdso32 code") from 2.6.25 replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before __kernel_sigreturn. Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN". So fix this by adding to that point at least a single NOP and make the function ALIGN possibly with more NOPs then. Kudos for reporting and diagnosing should go to Richard. Reported-by: Richard Biener <rguenther@suse.de> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Andy Lutomirski <luto@amacapital.net> Cc: <stable@vger.kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:04:14 -04:00
Paolo Bonzini	9ab9ee7a87	kvm: move advertising of KVM_CAP_IRQFD to common code [ Upstream commit `dc9be0fac7` ] POWER supports irqfds but forgot to advertise them. Some userspace does not check for the capability, but others check it---thus they work on x86 and s390 but not POWER. To avoid that other architectures in the future make the same mistake, let common code handle KVM_CAP_IRQFD the same way as KVM_CAP_IRQFD_RESAMPLE. Reported-and-tested-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Fixes: `297e21053a` Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:04:06 -04:00
Oleg Nesterov	1b6bd91982	x86/fpu: Drop_fpu() should not assume that tsk equals current [ Upstream commit `f4c3686386` ] drop_fpu() does clear_used_math() and usually this is correct because tsk == current. However switch_fpu_finish()->restore_fpu_checking() is called before __switch_to() updates the "current_task" variable. If it fails, we will wrongly clear the PF_USED_MATH flag of the previous task. So use clear_stopped_child_used_math() instead. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: <stable@vger.kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pekka Riikonen <priikone@iki.fi> Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:58 -04:00
Oleg Nesterov	1a29c27a0f	x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig() [ Upstream commit `a7c80ebcac` ] math_state_restore() assumes it is called with irqs disabled, but this is not true if the caller is __restore_xstate_sig(). This means that if ia32_fxstate == T and __copy_from_user() fails, __restore_xstate_sig() returns with irqs disabled too. This triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41 dump_stack ___might_sleep ? _raw_spin_unlock_irqrestore __might_sleep down_read ? _raw_spin_unlock_irqrestore print_vma_addr signal_fault sys32_rt_sigreturn Change __restore_xstate_sig() to call set_used_math() unconditionally. This avoids enabling and disabling interrupts in math_state_restore(). If copy_from_user() fails, we can simply do fpu_finit() by hand. [ Note: this is only the first step. math_state_restore() should not check used_math(), it should set this flag. While init_fpu() should simply die. ] Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pekka Riikonen <priikone@iki.fi> Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: Rik van Riel <riel@redhat.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:51 -04:00
Stephan Mueller	3b38995615	crypto: aesni - fix memory usage in GCM decryption [ Upstream commit `ccfe8c3f7e` ] The kernel crypto API logic requires the caller to provide the length of (ciphertext \|\| authentication tag) as cryptlen for the AEAD decryption operation. Thus, the cipher implementation must calculate the size of the plaintext output itself and cannot simply use cryptlen. The RFC4106 GCM decryption operation tries to overwrite cryptlen memory in req->dst. As the destination buffer for decryption only needs to hold the plaintext memory but cryptlen references the input buffer holding (ciphertext \|\| authentication tag), the assumption of the destination buffer length in RFC4106 GCM operation leads to a too large size. This patch simply uses the already calculated plaintext size. In addition, this patch fixes the offset calculation of the AAD buffer pointer: as mentioned before, cryptlen already includes the size of the tag. Thus, the tag does not need to be added. With the addition, the AAD will be written beyond the already allocated buffer. Note, this fixes a kernel crash that can be triggered from user space via AF_ALG(aead) -- simply use the libkcapi test application from [1] and update it to use rfc4106-gcm-aes. Using [1], the changes were tested using CAVS vectors to demonstrate that the crypto operation still delivers the right results. [1] http://www.chronox.de/libkcapi.html CC: Tadeusz Struk <tadeusz.struk@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:43 -04:00
Ard Biesheuvel	73a115c540	crypto: arm/aes update NEON AES module to latest OpenSSL version [ Upstream commit `001eabfd54` ] This updates the bit sliced AES module to the latest version in the upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a bug in the XTS decryption path, where data chunked in a certain way could trigger the ciphertext stealing code, which is not supposed to be active in the kernel build (The kernel implementation of XTS only supports round multiples of the AES block size of 16 bytes, whereas the conformant OpenSSL implementation of XTS supports inputs of arbitrary size by applying ciphertext stealing). This is fixed in the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK around the offending instructions. The upstream code also contains the change applied by Russell to build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7, but implemented slightly differently. Cc: stable@vger.kernel.org Fixes: `e4e7f10bfc` ("ARM: add support for bit sliced AES using NEON instructions") Reported-by: Adrian Kotelba <adrian.kotelba@gmail.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Milan Broz <gmazyland@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:36 -04:00
Kirill A. Shutemov	1cd3d374b2	pagemap: do not leak physical addresses to non-privileged userspace [ Upstream commit `ab676b7d6f` ] As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks. This disallows anybody without CAP_SYS_ADMIN to read the pagemap. [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [ Eventually we might want to do anything more finegrained, but for now this is the simple model. - Linus ] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Acked-by: Andy Lutomirski <luto@amacapital.net> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Seaborn <mseaborn@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:28 -04:00
Maxime Ripard	016958bf05	irqchip: armada-370-xp: Fix chained per-cpu interrupts [ Upstream commit `5724be8464` ] On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt controller. Yet, it still has to handle some per-cpu interrupt. To do so, it is chained with the GIC using a per-cpu interrupt. However, the current code only call irq_set_chained_handler, which is called and enable that interrupt only on the boot CPU, which means that the parent per-CPU interrupt is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to actually work as expected. This was not seen until now since the only MPIC PPI users were the Marvell timers that were not working, but not used either since the system use the ARM TWD by default, and the ethernet controllers, that are faking there interrupts as SPI, and don't really expect to have interrupts on the secondary cores anyway. Add a CPU notifier that will enable the PPI on the secondary cores when they are brought up. Cc: <stable@vger.kernel.org> # 3.15+ Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:03:20 -04:00
Sasha Levin	a10f28903b	PCI: Don't read past the end of sysfs "driver_override" buffer [ Upstream commit `4efe874aac` ] When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count+1 bytes for printing. Fixes: `782a985d7a` ("PCI: Introduce new device binding path using pci_dev.driver_override") Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> CC: stable@vger.kernel.org # v3.16+ CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Alexander Graf <agraf@suse.de> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:01:54 -04:00
James Bottomley	89410138b4	libsas: Fix Kernel Crash in smp_execute_task [ Upstream commit `6302ce4d80` ] This crash was reported: [ 366.947370] sd 3:0:1:0: [sdb] Spinning up disk.... [ 368.804046] BUG: unable to handle kernel NULL pointer dereference at (null) [ 368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.804098] PGD 0 [ 368.804114] Oops: 0002 [#1] SMP [ 368.804143] CPU 1 [ 368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common [ 368.804749] [ 368.804764] Pid: 392, comm: kworker/u:3 Tainted: P W O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920 [ 368.804802] RIP: 0010:[<ffffffff81358457>] [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.804827] RSP: 0018:ffff880117001cc0 EFLAGS: 00010246 [ 368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420 [ 368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4 [ 368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe [ 368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4 [ 368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8 [ 368.804916] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000 [ 368.804931] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0 [ 368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0) [ 368.805009] Stack: [ 368.805017] ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c [ 368.805062] 000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000 [ 368.805100] ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac [ 368.805135] Call Trace: [ 368.805153] [<ffffffff81056f7c>] ? up+0xb/0x33 [ 368.805168] [<ffffffff813583ac>] ? mutex_lock+0x16/0x25 [ 368.805194] [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas] [ 368.805217] [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas] [ 368.805240] [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas] [ 368.805264] [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas] [ 368.805280] [<ffffffff81355a2a>] ? printk+0x43/0x48 [ 368.805296] [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd [ 368.805318] [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas] [ 368.805336] [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c [ 368.805351] [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152 [ 368.805366] [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163 [ 368.805382] [<ffffffff81052c4e>] ? kthread+0x79/0x81 [ 368.805399] [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10 [ 368.805416] [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9 [ 368.805431] [<ffffffff8135fea0>] ? gs_change+0x13/0x13 [ 368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41 [ 368.805851] RIP [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.805877] RSP <ffff880117001cc0> [ 368.805886] CR2: 0000000000000000 [ 368.805899] ---[ end trace b720682065d8f4cc ]--- It's directly caused by `89d3cf6` [SCSI] libsas: add mutex for SMP task execution, but shows a deeper cause: expander functions expect to be able to cast to and treat domain devices as expanders. The correct fix is to only do expander discover when we know we've got an expander device to avoid wrongly casting a non-expander device. Reported-by: Praveen Murali <pmurali@logicube.com> Tested-by: Praveen Murali <pmurali@logicube.com> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:01:47 -04:00
Al Viro	c81fc59be4	gadgetfs: use-after-free in ->aio_read() [ Upstream commit `f01d35a15f` ] AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if we are going to access it asynchronously, we'd better get ourselves a copy - the one on kernel stack of aio_run_iocb() won't be there anymore. function/f_fs.c take care of doing that, legacy/inode.c doesn't... Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:01:39 -04:00
Jan Beulich	c7fd1867c7	xen-pciback: limit guest control of command register [ Upstream commit `af6fc858a3` ] Otherwise the guest can abuse that control to cause e.g. PCIe Unsupported Request responses by disabling memory and/or I/O decoding and subsequently causing (CPU side) accesses to the respective address ranges, which (depending on system configuration) may be fatal to the host. Note that to alter any of the bits collected together as PCI_COMMAND_GUEST permissive mode is now required to be enabled globally or on the specific device. This is CVE-2015-2150 / XSA-120. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 10:00:58 -04:00
Juergen Gross	72c7a8558c	xen/events: avoid NULL pointer dereference in dom0 on large machines [ Upstream commit `85e40b0539` ] Using the pvops kernel a NULL pointer dereference was detected on a large machine (144 processors) when booting as dom0 in evtchn_fifo_unmask() during assignment of a pirq. The event channel in question was the first to need a new entry in event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup() is called with evtchn being 0 for a new pirq and the real event channel number is assigned to the pirq only during __startup_pirq(). It is mandatory to call xen_evtchn_port_setup() after assigning the event channel number to the pirq to make sure all memory needed for the event channel is allocated. Signed-off-by: Juergen Gross <jgross@suse.com> Cc: <stable@vger.kernel.org> # 3.14+ Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:59:51 -04:00
Javier Martinez Canillas	75391143ec	drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data [ Upstream commit `8792f7772f` ] Commit `df9e26d093` ("rtc: s3c: add support for RTC of Exynos3250 SoC") added an "rtc_src" DT property to specify the clock used as a source to the S3C real-time clock. Not all SoCs needs this so commit `eaf3a65908` ("drivers/rtc/rtc-s3c.c: fix initialization failure without rtc source clock") changed to check the struct s3c_rtc_data .needs_src_clk to conditionally grab the clock. But that commit didn't update the data for each IP version so the RTC broke on the boards that needs a source clock. This is the case of at least Exynos5250 and Exynos5440 which uses the s3c6410 RTC IP block. This commit fixes the S3C rtc on the Exynos5250 Snow and Exynos5420 Peach Pit and Pi Chromebooks. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Olof Johansson <olof@lixom.net> Cc: Kevin Hilman <khilman@linaro.org> Cc: Tyler Baker <tyler.baker@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:59:44 -04:00
Chris Wilson	af6887e210	drm: Don't assign fbs for universal cursor support to files [ Upstream commit `9a6f513014` ] The internal framebuffers we create to remap legacy cursor ioctls to plane operations for the universal plane support shouldn't be linke to the file like normal userspace framebuffers. This bug goes back to the original universal cursor plane support introduced in commit `161d0dc1dc` Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Jun 10 08:28:10 2014 -0700 drm: Support legacy cursor ioctls via universal planes when possible (v4) The isn't too disastrous since fbs are small, we only create one when the cursor bo gets changed and ultimately they'll be reaped when the window server restarts. Conceptually we'd want to just pass NULL for file_priv when creating it, but the driver needs the file to lookup the underlying buffer object for cursor id. Instead let's move the file_priv linking out of add_framebuffer_internal() into the addfb ioctl implementation, which is the only place it is needed. And also rename the function for a more accurate since it only creates the fb, but doesn't add it anywhere. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:53:25 -04:00
Thomas Hellstrom	2c7f037016	drm/vmwgfx: Fix a couple of lock dependency violations [ Upstream commit `5151adb37a` ] Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: <stable@vger.kernel.org> Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:53:17 -04:00
Thomas Hellstrom	c95800d035	drm/vmwgfx: Reorder device takedown somewhat [ Upstream commit `3458390b9f` ] To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:53:10 -04:00
Jakub Kicinski	9297c32626	Revert "i2c: core: Dispose OF IRQ mapping at client removal time" [ Upstream commit `a494457270` ] This reverts commit `e4df3a0b62` ("i2c: core: Dispose OF IRQ mapping at client removal time") Calling irq_dispose_mapping() will destroy the mapping and disassociate the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because existent mappings are reused properly. Also, this commit breaks drivers using devm* for IRQ management on OF-based systems because devm* cleanup happens in device code, after bus's remove() method returns. Signed-off-by: Jakub Kicinski <kubakici@wp.pl> Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [wsa: updated the commit message with findings fromt the other bug report] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Fixes: `e4df3a0b62` Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:53:02 -04:00
Ryusuke Konishi	5e0c3d9ec8	nilfs2: fix deadlock of segment constructor during recovery [ Upstream commit `283ee1482f` ] According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck during recovery at mount time. The code path that caused the deadlock was as follows: nilfs_fill_super() load_nilfs() nilfs_salvage_orphan_logs() * Do roll-forwarding, attach segment constructor for recovery, and kick it. nilfs_segctor_thread() nilfs_segctor_thread_construct() * A lock is held with nilfs_transaction_lock() nilfs_segctor_do_construct() nilfs_segctor_drop_written_files() iput() iput_final() write_inode_now() writeback_single_inode() __writeback_single_inode() do_writepages() nilfs_writepage() nilfs_construct_dsync_segment() nilfs_transaction_lock() --> deadlock This can happen if commit `7ef3ff2fea` ("nilfs2: fix deadlock of segment constructor over I_SYNC flag") is applied and roll-forward recovery was performed at mount time. The roll-forward recovery can happen if datasync write is done and the file system crashes immediately after that. For instance, we can reproduce the issue with the following steps: < nilfs2 is mounted on /nilfs (device: /dev/sdb1) > # dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync # dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k count=1 && reboot -nfh < the system will immediately reboot > # mount -t nilfs2 /dev/sdb1 /nilfs The deadlock occurs because iput() can run segment constructor through writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags. The above commit changed segment constructor so that it calls iput() asynchronously for inodes with i_nlink == 0, but that change was imperfect. This fixes the another deadlock by deferring iput() in segment constructor even for the case that mount is not finished, that is, for the case that MS_ACTIVE flag is not set. Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Reported-by: Yuxuan Shui <yshuiv7@gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:51:45 -04:00
Doug Anderson	bf90526a2d	regulator: core: Fix enable GPIO reference counting [ Upstream commit `29d62ec5f8` ] Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: `967cfb18c0` ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:51:37 -04:00
Javier Martinez Canillas	4aeea72574	regulator: Only enable disabled regulators on resume [ Upstream commit `0548bf4f5a` ] The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:51:30 -04:00
Doug Anderson	084968adf5	regulator: rk808: Set the enable time for LDOs [ Upstream commit `28249b0c2f` ] The LDOs are documented in the rk808 datasheet to have a soft start time of 400us. Add that to the driver. If this time takes longer on a certain board the device tree should be able to override with "regulator-enable-ramp-delay". This fixes some dw_mmc probing problems (together with other patches posted to the mmc maiing lists) on rk3288. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:51:22 -04:00
Brian King	45eacb50e5	bnx2x: Force fundamental reset for EEH recovery [ Upstream commit `da29370056` ] EEH recovery for bnx2x based adapters is not reliable on all Power systems using the default hot reset, which can result in an unrecoverable EEH error. Forcing the use of fundamental reset during EEH recovery fixes this. Cc: stable<stable@vger.kernel.org> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:49 -04:00
Maxime Ripard	8c07b3abce	mtd: nand: pxa3xx: Fix PIO FIFO draining [ Upstream commit `8dad0386b9` ] The NDDB register holds the data that are needed by the read and write commands. However, during a read PIO access, the datasheet specifies that after each 32 bytes read in that register, when BCH is enabled, we have to make sure that the RDDREQ bit is set in the NDSR register. This fixes an issue that was seen on the Armada 385, and presumably other mvebu SoCs, when a read on a newly erased page would end up in the driver reporting a timeout from the NAND. Cc: <stable@vger.kernel.org> # v3.14 Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:41 -04:00
Takashi Iwai	79eb59a64b	ALSA: hda - Treat stereo-to-mono mix properly [ Upstream commit `cc261738ad` ] The commit [`ef403edb75`: ALSA: hda - Don't access stereo amps for mono channel widgets] fixed the handling of mono widgets in general, but it still misses an exceptional case: namely, a mono mixer widget taking a single stereo input. In this case, it has stereo volumes although it's a mono widget, and thus we have to take care of both left and right input channels, as stated in HD-audio spec ("7.1.3 Widget Interconnection Rules"). This patch covers this missing piece by adding proper checks of stereo amps in both the generic parser and the proc output codes. Reported-by: Raymond Yau <superquad.vortex2@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:33 -04:00
Takashi Iwai	6fdbb0ba74	ALSA: hda - Fix regression of HD-audio controller fallback modes [ Upstream commit `a1f3f1ca66` ] The commit [`63e51fd708`: ALSA: hda - Don't take unresponsive D3 transition too serious] introduced a conditional fallback behavior to the HD-audio controller depending on the flag set. However, it introduced a silly bug, too, that the flag was evaluated in a reverse way. This resulted in a regression of HD-audio controller driver where it can't go to the fallback mode at communication errors. Unfortunately (or fortunately?) this didn't come up until recently because the affected code path is an error handling that happens only on an unstable hardware chip. Most of recent chips work stably, thus they didn't hit this problem. Now, we've got a regression report with a VIA chip, and this seems indeed requiring the fallback to the polling mode, and finally the bug was revealed. The fix is a oneliner to remove the wrong logical NOT in the check. (Lesson learned - be careful about double negation.) The bug should be backported to stable, but the patch won't be applicable to 3.13 or earlier because of the code splits. The stable fix patches for earlier kernels will be posted later manually. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021 Fixes: `63e51fd708` ('ALSA: hda - Don't take unresponsive D3 transition too serious') Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:26 -04:00
Takashi Iwai	73de0edf4b	ALSA: hda - Add workaround for MacBook Air 5,2 built-in mic [ Upstream commit `2ddee91abe` ] MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the built-in mic records only the right channel. Apply the same workaround as MBP8,1 to spread the mono channel via a Cirrus codec vendor-specific COEF setup. Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:18 -04:00
Takashi Iwai	b0501ca4a6	ALSA: hda - Set single_adc_amp flag for CS420x codecs [ Upstream commit `bad994f5b4` ] CS420x codecs seem to deal only the single amps of ADC nodes even though the nodes receive multiple inputs. This leads to the inconsistent amp value after S3/S4 resume, for example. The fix is just to set codec->single_adc_amp flag. Then the driver handles these ADC amps as if single connections. Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:10 -04:00
Takashi Iwai	e2b501a93a	ALSA: hda - Don't access stereo amps for mono channel widgets [ Upstream commit `ef403edb75` ] The current HDA generic parser initializes / modifies the amp values always in stereo, but this seems causing the problem on ALC3229 codec that has a few mono channel widgets: namely, these mono widgets react to actions for both channels equally. In the driver code, we do care the mono channel and create a control only for the left channel (as defined in HD-audio spec) for such a node. When the control is updated, only the left channel value is changed. However, in the resume, the right channel value is also restored from the initial value we took as stereo, and this overwrites the left channel value. This ends up being the silent output as the right channel has been never touched and remains muted. This patch covers the places where unconditional stereo amp accesses are done and converts to the conditional accesses. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:50:03 -04:00
Takashi Iwai	05e83bd5ad	ALSA: hda - Fix built-in mic on Compaq Presario CQ60 [ Upstream commit `ddb6ca75b5` ] Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the built-in mic NID 0x17 instead of NID 0x1d, and it results in the non-working mic. This patch just remaps the pin correctly via fixup. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:49:55 -04:00
Takashi Iwai	c0527b93dc	ALSA: control: Add sanity checks for user ctl id name string [ Upstream commit `be3bb8236d` ] There was no check about the id string of user control elements, so we accepted even a control element with an empty string, which is obviously bogus. This patch adds more sanity checks of id strings. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:49:48 -04:00
Daniel Mack	095ea4b422	ALSA: snd-usb: add quirks for Roland UA-22 [ Upstream commit `fcdcd1dec6` ] The device complies to the UAC1 standard but hides that fact with proprietary descriptors. The autodetect quirk for Roland devices catches the audio interface but misses the MIDI part, so a specific quirk is needed. Signed-off-by: Daniel Mack <daniel@zonque.org> Reported-by: Rafa Lafuente <rafalafuente@gmail.com> Tested-by: Raphaël Doursenaud <raphael@doursenaud.fr> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:49:40 -04:00
Alexander Sverdlin	766afbabcb	spi: pl022: Fix race in giveback() leading to driver lock-up [ Upstream commit `cd6fa8d2ca` ] Commit `fd316941c` ("spi/pl022: disable port when unused") introduced a race, which leads to possible driver lock up (easily reproducible on SMP). The problem happens in giveback() function where the completion of the transfer is signalled to SPI subsystem and then the HW SPI controller is disabled. Another transfer might be setup in between, which brings driver in locked-up state. Exact event sequence on SMP: core0 core1 => pump_transfers() /* message->state == STATE_DONE / => giveback() => spi_finalize_current_message() => pl022_unprepare_transfer_hardware() => pl022_transfer_one_message => flush() => do_interrupt_dma_transfer() => set_up_next_transfer() / Enable SSP, turn on interrupts / writew((readw(SSP_CR1(pl022->virtbase)) \| SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase)); ... => pl022_interrupt_handler() => readwriter() / disable the SPI/SSP operation */ => writew((readw(SSP_CR1(pl022->virtbase)) & (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase)); Lockup! SPI controller is disabled and the data will never be received. Whole SPI subsystem is waiting for transfer ACK and blocked. So, only signal transfer completion after disabling the controller. Fixes: `fd316941c` (spi/pl022: disable port when unused) Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:49:32 -04:00
Andy Shevchenko	f3aa910546	spi: dw-mid: avoid potential NULL dereference [ Upstream commit `c9dafb27c8` ] When DMA descriptor allocation fails we should not try to assign any fields in the bad descriptor. The patch adds the necessary checks for that. Fixes: `7063c0d942` (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:49:22 -04:00
Torsten Fleischer	fbafcf8fb1	spi: atmel: Fix interrupt setup for PDC transfers [ Upstream commit `76e1d14b31` ] Additionally to the current DMA transfer the PDC allows to set up a next DMA transfer. This is useful for larger SPI transfers. The driver currently waits for ENDRX as end of the transfer. But ENDRX is set when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the next DMA transfer. Thus a subsequent SPI transfer could be started although there is currently a transfer in progress. This can cause invalid accesses to the SPI slave devices and to SPI transfer errors. This issue has been observed on a hardware with a M25P128 SPI NOR flash. So instead of ENDRX we should wait for RXBUFF. This flag is set if there is no more DMA transfer in progress (RCR = RNCR = 0). Signed-off-by: Torsten Fleischer <torfl6749@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:44:58 -04:00
Christophe Ricard	a036688474	tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO [ Upstream commit `c4eadfafb9` ] Add a return value check when reading data from the FIFO register. Cc: <stable@vger.kernel.org> Reviewed-by: Jason Gunthorpe <jason.gunthorpe@obsidianresearch.com> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Reviewed-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:43:13 -04:00
jmlatten@linux.vnet.ibm.com	33c5b3ad4b	tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send [ Upstream commit `62dfd912ab` ] Problem: When IMA and VTPM are both enabled in kernel config, kernel hangs during bootup on LE OS. Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send and tpm_ibmtpm_recv getting called. A trace showed that tpm_ibmtpm_recv was hanging. Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send was sending CRQ message that probably did not make much sense to phype because of Endianness. The fix below sends correctly converted CRQ for LE. This was not caught before because it seems IMA is not enabled by default in kernel config and IMA exercises this particular code path in vtpm. Tested with IMA and VTPM enabled in kernel config and VTPM enabled on both a BE OS and a LE OS ppc64 lpar. This exercised CRQ and TPM command code paths in vtpm. Patch is against Peter's tpmdd tree on github which included Vicky's previous vtpm le patches. Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> # `eb71f8a5e3`: "Added Little Endian support to vtpm module" Cc: <stable@vger.kernel.org> Reviewed-by: Ashley Lai <ashley@ahsleylai.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:43:06 -04:00
Jason Low	ea7358ff38	cpuset: Fix cpuset sched_relax_domain_level [ Upstream commit `283cb41f42` ] The cpuset.sched_relax_domain_level can control how far we do immediate load balancing on a system. However, it was found on recent kernels that echo'ing a value into cpuset.sched_relax_domain_level did not reduce any immediate load balancing. The reason this occurred was because the update_domain_attr_tree() traversal did not update for the "top_cpuset". This resulted in nothing being changed when modifying the sched_relax_domain_level parameter. This patch is able to address that problem by having update_domain_attr_tree() allow updates for the root in the cpuset traversal. Fixes: `fc560a26ac` ("cpuset: replace cpuset->stack_list with cpuset_for_each_descendant_pre()") Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: Jason Low <jason.low2@hp.com> Signed-off-by: Zefan Li <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Tested-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:42:58 -04:00
Zefan Li	79692efa3a	cpuset: fix a warning when clearing configured masks in old hierarchy [ Upstream commit `79063bffc8` ] When we clear cpuset.cpus, cpuset.effective_cpus won't be cleared: # mount -t cgroup -o cpuset xxx /mnt # mkdir /mnt/tmp # echo 0 > /mnt/tmp/cpuset.cpus # echo > /mnt/tmp/cpuset.cpus # cat cpuset.cpus # cat cpuset.effective_cpus 0-15 And a kernel warning in update_cpumasks_hier() is triggered: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4028 at kernel/cpuset.c:894 update_cpumasks_hier+0x471/0x650() Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Zefan Li <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Tested-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:42:51 -04:00
Zefan Li	dacb6ccdcc	cpuset: initialize effective masks when clone_children is enabled [ Upstream commit `790317e1b2` ] If clone_children is enabled, effective masks won't be initialized due to the bug: # mount -t cgroup -o cpuset xxx /mnt # echo 1 > cgroup.clone_children # mkdir /mnt/tmp # cat /mnt/tmp/ # cat cpuset.effective_cpus # cat cpuset.cpus 0-15 And then this cpuset won't constrain the tasks in it. Either the bug or the fix has no effect on unified hierarchy, as there's no clone_chidren flag there any more. Reported-by: Christian Brauner <christianvanbrauner@gmail.com> Reported-by: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Zefan Li <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Tested-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:42:38 -04:00
Tejun Heo	d4bc18f7bb	workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE [ Upstream commit `8603e1b300` ] cancel[_delayed]_work_sync() are implemented using __cancel_work_timer() which grabs the PENDING bit using try_to_grab_pending() and then flushes the work item with PENDING set to prevent the on-going execution of the work item from requeueing itself. try_to_grab_pending() can always grab PENDING bit without blocking except when someone else is doing the above flushing during cancelation. In that case, try_to_grab_pending() returns -ENOENT. In this case, __cancel_work_timer() currently invokes flush_work(). The assumption is that the completion of the work item is what the other canceling task would be waiting for too and thus waiting for the same condition and retrying should allow forward progress without excessive busy looping Unfortunately, this doesn't work if preemption is disabled or the latter task has real time priority. Let's say task A just got woken up from flush_work() by the completion of the target work item. If, before task A starts executing, task B gets scheduled and invokes __cancel_work_timer() on the same work item, its try_to_grab_pending() will return -ENOENT as the work item is still being canceled by task A and flush_work() will also immediately return false as the work item is no longer executing. This puts task B in a busy loop possibly preventing task A from executing and clearing the canceling state on the work item leading to a hang. task A task B worker executing work __cancel_work_timer() try_to_grab_pending() set work CANCELING flush_work() block for work completion completion, wakes up A __cancel_work_timer() while (forever) { try_to_grab_pending() -ENOENT as work is being canceled flush_work() false as work is no longer executing } This patch removes the possible hang by updating __cancel_work_timer() to explicitly wait for clearing of CANCELING rather than invoking flush_work() after try_to_grab_pending() fails with -ENOENT. Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com v3: bit_waitqueue() can't be used for work items defined in vmalloc area. Switched to custom wake function which matches the target work item and exclusive wait and wakeup. v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if the target bit waitqueue has wait_bit_queue's on it. Use DEFINE_WAIT_BIT() and __wake_up_bit() instead. Reported by Tomeu Vizoso. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Rabin Vincent <rabin.vincent@axis.com> Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com> Cc: stable@vger.kernel.org Tested-by: Jesper Nilsson <jesper.nilsson@axis.com> Tested-by: Rabin Vincent <rabin.vincent@axis.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:48 -04:00
Ahmed S. Darwish	9c8090e1e5	can: kvaser_usb: Read all messages in a bulk-in URB buffer [ Upstream commit `2fec5104f9` ] The Kvaser firmware can only read and write messages that are not crossing the USB endpoint's wMaxPacketSize boundary. While receiving commands from the CAN device, if the next command in the same URB buffer crossed that max packet size boundary, the firmware puts a zero-length placeholder command in its place then moves the real command to the next boundary mark. The driver did not recognize such behavior, leading to missing a good number of rx events during a heavy rx load session. Moreover, a tx URB context only gets freed upon receiving its respective tx ACK event. Over time, the free tx URB contexts pool gets depleted due to the missing ACK events. Consequently, the netif transmission queue gets __permanently__ stopped; no frames could be sent again except after restarting the CAN newtwork interface. Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:40 -04:00
Oliver Hartkopp	9baee04246	can: add missing initialisations in CAN related skbuffs [ Upstream commit `969439016d` ] When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient this can lead to a skb_under_panic due to missing skb initialisations. Add the missing initialisations at the CAN skbuff creation times on driver level (rx path) and in the network layer (tx path). Reported-by: Austin Schuh <austin@peloton-tech.com> Reported-by: Daniel Steer <daniel.steer@mclaren.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:33 -04:00
Steven Rostedt (Red Hat)	24cc23d3af	ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled [ Upstream commit `524a386825` ] Some archs (specifically PowerPC), are sensitive with the ordering of the enabling of the calls to function tracing and setting of the function to use to be traced. That is, update_ftrace_function() sets what function the ftrace_caller trampoline should call. Some archs require this to be set before calling ftrace_run_update_code(). Another bug was discovered, that ftrace_startup_sysctl() called ftrace_run_update_code() directly. If the function the ftrace_caller trampoline changes, then it will not be updated. Instead a call to ftrace_startup_enable() should be called because it tests to see if the callback changed since the code was disabled, and will tell the arch to update appropriately. Most archs do not need this notification, but PowerPC does. The problem could be seen by the following commands: # echo 0 > /proc/sys/kernel/ftrace_enabled # echo function > /sys/kernel/debug/tracing/current_tracer # echo 1 > /proc/sys/kernel/ftrace_enabled # cat /sys/kernel/debug/tracing/trace The trace will show that function tracing was not active. Cc: stable@vger.kernel.org # 2.6.27+ Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:25 -04:00
Pratyush Anand	4184e5ecb9	ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl [ Upstream commit `1619dc3f8f` ] When ftrace is enabled globally through the proc interface, we must check if ftrace_graph_active is set. If it is set, then we should also pass the FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when ftrace is disabled globally through the proc interface, we must check if ftrace_graph_active is set. If it is set, then we should also pass the FTRACE_STOP_FUNC_RET command to ftrace_run_update_code(). Consider the following situation. # echo 0 > /proc/sys/kernel/ftrace_enabled After this ftrace_enabled = 0. # echo function_graph > /sys/kernel/debug/tracing/current_tracer Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never called. # echo 1 > /proc/sys/kernel/ftrace_enabled Now ftrace_enabled will be set to true, but still ftrace_enable_ftrace_graph_caller() will not be called, which is not desired. Further if we execute the following after this: # echo nop > /sys/kernel/debug/tracing/current_tracer Now since ftrace_enabled is set it will call ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on the ARM platform. On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called, it checks whether the old instruction is a nop or not. If it's not a nop, then it returns an error. If it is a nop then it replaces instruction at that address with a branch to ftrace_graph_caller. ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore, if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller() or ftrace_disable_ftrace_graph_caller() consecutively two times in a row, then it will return an error, which will cause the generic ftrace code to raise a warning. Note, x86 does not have an issue with this because the architecture specific code for ftrace_enable_ftrace_graph_caller() and ftrace_disable_ftrace_graph_caller() does not check the previous state, and calling either of these functions twice in a row has no ill effect. Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com Cc: stable@vger.kernel.org # 2.6.31+ Signed-off-by: Pratyush Anand <panand@redhat.com> [ removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0 if CONFIG_FUNCTION_GRAPH_TRACER is not set. ] Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:18 -04:00
Steven Rostedt (Red Hat)	b4521c3dbf	ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl [ Upstream commit `b24d443b8f` ] When /proc/sys/kernel/ftrace_enabled is set to zero, all function tracing is disabled. But the records that represent the functions still hold information about the ftrace_ops that are hooked to them. ftrace_ops may request "REGS" (have a full set of pt_regs passed to the callback), or "TRAMP" (the ops has its own trampoline to use). When the record is updated to represent the state of the ops hooked to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback points to the correct trampoline (REGS has its own trampoline). When ftrace_enabled is set to zero, all ftrace locations are a nop, so they do not point to any trampoline. But the _EN flags are still set. This can cause the accounting to go wrong when ftrace_enabled is cleared and an ops that has a trampoline is registered or unregistered. For example, the following will cause ftrace to crash: # echo function_graph > /sys/kernel/debug/tracing/current_tracer # echo 0 > /proc/sys/kernel/ftrace_enabled # echo nop > /sys/kernel/debug/tracing/current_tracer # echo 1 > /proc/sys/kernel/ftrace_enabled # echo function_graph > /sys/kernel/debug/tracing/current_tracer As function_graph uses a trampoline, when ftrace_enabled is set to zero the updates to the record are not done. When enabling function_graph again, the record will still have the TRAMP_EN flag set, and it will look for an op that has a trampoline other than the function_graph ops, and fail to find one. Cc: stable@vger.kernel.org # 3.17+ Reported-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:10 -04:00
Russell King	51ff22caa1	Change email address for 8250_pci [ Upstream commit `f2e0ea8611` ] I'm still receiving reports to my email address, so let's point this at the linux-serial mailing list instead. Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:37:02 -04:00
Michael S. Tsirkin	ee7fb5b371	virtio_console: avoid config access from irq [ Upstream commit `eeb8a7e8bb` ] when multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:36:55 -04:00
Michael S. Tsirkin	0b39fb1962	virtio_console: init work unconditionally [ Upstream commit `4f6e24ed9d` ] when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:36:47 -04:00
Peter Hurley	5850222dac	console: Fix console name size mismatch commit `30a22c215a` upstream. commit `6ae9200f2c` ("enlarge console.name") increased the storage for the console name to 16 bytes, but not the corresponding struct console_cmdline::name storage. Console names longer than 8 bytes cause read beyond end-of-string and failure to match console; I'm not sure if there are other unexpected consequences. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit `2cf6258c28`)	2015-03-28 09:36:33 -04:00
Peter Hurley	de62b34827	serial: 8250_dw: Fix deadlock in LCR workaround [ Upstream commit `7fd6f640f2` ] Trying to write console output from within the serial console driver while the port->lock is held causes recursive deadlock: CPU 0 spin_lock_irqsave(&port->lock) printk() console_unlock() call_console_drivers() serial8250_console_write() spin_lock_irqsave(&port->lock) DEADLOCK The 8250_dw i/o accessors try to write a console error message if the LCR workaround was unsuccessful. When the port->lock is already held (eg., when called from serial8250_set_termios()), this deadlocks. Make the error message a FIXME until a general solution is devised. Cc: Tim Kryger <tim.kryger@gmail.com> Reported-by: Zhang Zhen <zhenzhang.zhang@huawei.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:36:25 -04:00
Miklos Szeredi	78df56cca6	fuse: notify: don't move pages [ Upstream commit `0d2783626a` ] fuse_try_move_page() is not prepared for replacing pages that have already been read. Reported-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:33:41 -04:00
Miklos Szeredi	9525473566	fuse: set stolen page uptodate [ Upstream commit `aa991b3b26` ] Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set PG_uptodate. Don't warn on this condition, just set the uptodate flag. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:33:33 -04:00
JeHyeon Yeon	9bda2fc64c	LZ4 : fix the data abort issue [ Upstream commit `d5e7cafd69` ] If the part of the compression data are corrupted, or the compression data is totally fake, the memory access over the limit is possible. This is the log from my system usning lz4 decompression. [6502]data abort, halting [6503]r0 0x00000000 r1 0x00000000 r2 0xdcea0ffc r3 0xdcea0ffc [6509]r4 0xb9ab0bfd r5 0xdcea0ffc r6 0xdcea0ff8 r7 0xdce80000 [6515]r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0xb9a98000 [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc 0x820149bc [6528]spsr 0x400001f3 and the memory addresses of some variables at the moment are ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000 As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory over @oend. Signed-off-by: JeHyeon Yeon <tom.yeon@windriver.com> Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:33:25 -04:00
Alex Deucher	7809f283e0	drm/radeon: drop ttm two ended allocation [ Upstream commit `a239118a24` ] radeon_bo_create() calls radeon_ttm_placement_from_domain() before ttm_bo_init() is called. radeon_ttm_placement_from_domain() uses the ttm bo size to determine when to select top down allocation but since the ttm bo is not initialized yet the check is always false. It only took effect when buffers were validated later. It also seemed to regress suspend and resume on some systems possibly due to it not taking effect in radeon_bo_create(). radeon_bo_create() and radeon_ttm_placement_from_domain() need to be reworked substantially for this to be optimally effective. Re-enable it at that point. Noticed-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:33:13 -04:00
Maarten Lankhorst	764725a6ee	drm/radeon: fix wait to actually occur after the signaling callback [ Upstream commit `b661010171` ] A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:24:06 -04:00
Christian König	6eef27b662	drm/radeon: drop setting UPLL to sleep mode [ Upstream commit `a17d4996e0` ] Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:59 -04:00
Alex Deucher	570f8c7739	drm/radeon: fix interlaced modes on DCE8 [ Upstream commit `77ae5f4b48` ] Need to double the viewport height. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:51 -04:00
Alex Deucher	2b4cdd25e9	drm/radeon: do a posting read in rs600_set_irq [ Upstream commit `54acf107e4` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:43 -04:00
Alex Deucher	030b28dca1	drm/radeon: do a posting read in si_set_irq [ Upstream commit `0586915ec1` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:36 -04:00
Alex Deucher	09e605b314	drm/radeon: do a posting read in cik_set_irq [ Upstream commit `cffefd9bb3` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:28 -04:00
Alex Deucher	a5f1220ce4	drm/radeon: do a posting read in r600_set_irq [ Upstream commit `9d1393f23d` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:21 -04:00
Alex Deucher	226c62843f	drm/radeon: do a posting read in r100_set_irq [ Upstream commit `f957063fee` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:13 -04:00
Alex Deucher	26f16cbdfd	drm/radeon: do a posting read in evergreen_set_irq [ Upstream commit `c320bb5f6d` ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:23:05 -04:00
Tommi Rantala	7d5b23fa02	drm/radeon: fix DRM_IOCTL_RADEON_CS oops [ Upstream commit `a28b2a47ed` ] Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include <stdint.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/radeon_drm.h> static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640 [ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570 [ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0 [ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP <ffff880058e67998> [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:22:58 -04:00
Catalin Marinas	e9ab6db096	arm64: Invalidate the TLB corresponding to intermediate page table levels [ Upstream commit `285994a62c` ] The ARM architecture allows the caching of intermediate page table levels and page table freeing requires a sequence like: pmd_clear() TLB invalidation pte page freeing With commit `5e5f6dc105` (arm64: mm: enable HAVE_RCU_TABLE_FREE logic), the page table freeing batching was moved from tlb_remove_page() to tlb_remove_table(). The former takes care of TLB invalidation as this is also shared with pte clearing and page cache page freeing. The latter, however, does not invalidate the TLBs for intermediate page table levels as it probably relies on the architecture code to do it if required. When the mm->mm_users < 2, tlb_remove_table() does not do any batching and page table pages are freed before tlb_finish_mmu() which performs the actual TLB invalidation. This patch introduces __tlb_flush_pgtable() for arm64 and calls it from the {pte,pmd,pud}_free_tlb() directly without relying on deferred page table freeing. Fixes: `5e5f6dc105` arm64: mm: enable HAVE_RCU_TABLE_FREE logic Reported-by: Jon Masters <jcm@redhat.com> Tested-by: Jon Masters <jcm@redhat.com> Tested-by: Steve Capper <steve.capper@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:22:42 -04:00
Will Deacon	bf91097cd5	mmu_gather: move minimal range calculations into generic code [ Upstream commit `fb7332a9fe` ] On architectures with hardware broadcasting of TLB invalidation messages , it makes sense to reduce the range of the mmu_gather structure when unmapping page ranges based on the dirty address information passed to tlb_remove_tlb_entry. arm64 already does this by directly manipulating the start/end fields of the gather structure, but this confuses the generic code which does not expect these fields to change and can end up calculating invalid, negative ranges when forcing a flush in zap_pte_range. This patch moves the minimal range calculation out of the arm64 code and into the generic implementation, simplifying zap_pte_range in the process (which no longer needs to care about start/end, since they will point to the appropriate ranges already). With the range being tracked by core code, the need_flush flag is dropped in favour of checking that the end of the range has actually been set. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Michal Simek <monstr@monstr.eu> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:22:01 -04:00
Suzuki K. Poulose	0ef78141be	arm64: Honor __GFP_ZERO in dma allocations [ Upstream commit `7132813c38` ] Current implementation doesn't zero out the pages allocated. Honor the __GFP_ZERO flag and zero out if set. Cc: <stable@vger.kernel.org> # v3.14+ Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-28 09:20:39 -04:00
Eric Dumazet	e8f117f002	tcp: make connect() mem charging friendly [ Upstream commit `355a901e6c` ] While working on sk_forward_alloc problems reported by Denys Fedoryshchenko, we found that tcp connect() (and fastopen) do not call sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so sk_forward_alloc is negative while connect is in progress. We can fix this by calling regular sk_stream_alloc_skb() both for the SYN packet (in tcp_connect()) and the syn_data packet in tcp_send_syn_data() Then, tcp_send_syn_data() can avoid copying syn_data as we simply can manipulate syn_data->cb[] to remove SYN flag (and increment seq) Instead of open coding memcpy_fromiovecend(), simply use this helper. This leaves in socket write queue clean fast clone skbs. This was tested against our fastopen packetdrill tests. Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:22 -04:00
Catalin Marinas	34ca18c8fb	net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour [ Upstream commit `91edd096e2` ] Commit `db31c55a6f` (net: clamp ->msg_namelen instead of returning an error) introduced the clamping of msg_namelen when the unsigned value was larger than sizeof(struct sockaddr_storage). This caused a msg_namelen of -1 to be valid. The native code was subsequently fixed by commit `dbb490b965` (net: socket: error on a negative msg_namelen). In addition, the native code sets msg_namelen to 0 when msg_name is NULL. This was done in commit (`6a2a2b3ae0` net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland) and subsequently updated by `08adb7dabd` (fold verify_iovec() into copy_msghdr_from_user()). This patch brings the get_compat_msghdr() in line with copy_msghdr_from_user(). Fixes: `db31c55a6f` (net: clamp ->msg_namelen instead of returning an error) Cc: David S. Miller <davem@davemloft.net> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:21 -04:00
Josh Hunt	b182ecc84b	tcp: fix tcp fin memory accounting [ Upstream commit `d22e153718` ] tcp_send_fin() does not account for the memory it allocates properly, so sk_forward_alloc can be negative in cases where we've sent a FIN: ss example output (ss -amn \| grep -B1 f4294): tcp FIN-WAIT-1 0 1 192.168.0.1:45520 192.0.2.1:8080 skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0) Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:21 -04:00
Steven Barth	7f249ac587	ipv6: fix backtracking for throw routes [ Upstream commit `73ba57bfae` ] for throw routes to trigger evaluation of other policy rules EAGAIN needs to be propagated up to fib_rules_lookup similar to how its done for IPv4 A simple testcase for verification is: ip -6 rule add lookup 33333 priority 33333 ip -6 route add throw 2001:db8::1 ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 33333 ip route get 2001:db8::1 Signed-off-by: Steven Barth <cyrus@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:21 -04:00
Ondrej Zary	5039b8cfb5	Revert "net: cx82310_eth: use common match macro" [ Upstream commit `8d006e0105` ] This reverts commit `11ad714b98` because it breaks cx82310_eth. The custom USB_DEVICE_CLASS macro matches bDeviceClass, bDeviceSubClass and bDeviceProtocol but the common USB_DEVICE_AND_INTERFACE_INFO matches bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are not specified. Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:20 -04:00
Al Viro	3d1acc9e72	rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg() [ Upstream commit `7d985ed1dc` ] [I would really like an ACK on that one from dhowells; it appears to be quite straightforward, but...] MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit in there. It gets passed via flags; in fact, another such check in the same function is done correctly - as flags & MSG_PEEK. It had been that way (effectively disabled) for 8 years, though, so the patch needs beating up - that case had never been tested. If it is correct, it's -stable fodder. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:20 -04:00
Al Viro	02bfe56e55	caif: fix MSG_OOB test in caif_seqpkt_recvmsg() [ Upstream commit `3eeff778e0` ] It should be checking flags, not msg->msg_flags. It's ->sendmsg() instances that need to look for that in ->msg_flags, ->recvmsg() ones (including the other ->recvmsg() instance in that file, as well as unix_dgram_recvmsg() this one claims to be imitating) check in flags. Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC in receive") back in 2010, so it goes quite a while back. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:20 -04:00
Eric Dumazet	e1f2092a94	inet_diag: fix possible overflow in inet_diag_dump_one_icsk() [ Upstream commit `c8e2c80d7e` ] inet_diag_dump_one_icsk() allocates too small skb. Add inet_sk_attr_size() helper right before inet_sk_diag_fill() so that it can be updated if/when new attributes are added. iproute2/ss currently does not use this dump_one() interface, this might explain nobody noticed this problem yet. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:19 -04:00
Jason Wang	b9befa4303	virtio-net: correctly delete napi hash [ Upstream commit `ab3971b1e7` ] We don't delete napi from hash list during module exit. This will cause the following panic when doing module load and unload: BUG: unable to handle kernel paging request at 0000004e00000075 IP: [<ffffffff816bd01b>] napi_hash_add+0x6b/0xf0 PGD 3c5d5067 PUD 0 Oops: 0000 [#1] SMP ... Call Trace: [<ffffffffa0a5bfb7>] init_vqs+0x107/0x490 [virtio_net] [<ffffffffa0a5c9f2>] virtnet_probe+0x562/0x791815639d880be [virtio_net] [<ffffffff8139e667>] virtio_dev_probe+0x137/0x200 [<ffffffff814c7f2a>] driver_probe_device+0x7a/0x250 [<ffffffff814c81d3>] __driver_attach+0x93/0xa0 [<ffffffff814c8140>] ? __device_attach+0x40/0x40 [<ffffffff814c6053>] bus_for_each_dev+0x63/0xa0 [<ffffffff814c7a79>] driver_attach+0x19/0x20 [<ffffffff814c76f0>] bus_add_driver+0x170/0x220 [<ffffffffa0a60000>] ? 0xffffffffa0a60000 [<ffffffff814c894f>] driver_register+0x5f/0xf0 [<ffffffff8139e41b>] register_virtio_driver+0x1b/0x30 [<ffffffffa0a60010>] virtio_net_driver_init+0x10/0x12 [virtio_net] This patch fixes this by doing this in virtnet_free_queues(). And also don't delete napi in virtnet_freeze() since it will call virtnet_free_queues() which has already did this. Fixes `91815639d8` ("virtio-net: rx busy polling support") Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:19 -04:00
Arnd Bergmann	6ba8661b56	rds: avoid potential stack overflow [ Upstream commit `f862e07cf9` ] The rds_iw_update_cm_id function stores a large 'struct rds_sock' object on the stack in order to pass a pair of addresses. This happens to just fit withint the 1024 byte stack size warning limit on x86, but just exceed that limit on ARM, which gives us this warning: net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=] As the use of this large variable is basically bogus, we can rearrange the code to not do that. Instead of passing an rds socket into rds_iw_get_device, we now just pass the two addresses that we have available in rds_iw_update_cm_id, and we change rds_iw_get_mr accordingly, to create two address structures on the stack there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:18 -04:00
Alexey Kodanev	c48cf4f27d	net: sysctl_net_core: check SNDBUF and RCVBUF for min length [ Upstream commit `b1cb59cf2e` ] sysctl has sysctl.net.core.rmem_/wmem_ parameters which can be set to incorrect values. Given that 'struct sk_buff' allocates from rcvbuf, incorrectly set buffer length could result to memory allocation failures. For example, set them as follows: # sysctl net.core.rmem_default=64 net.core.wmem_default = 64 # sysctl net.core.wmem_default=64 net.core.wmem_default = 64 # ping localhost -s 1024 -i 0 > /dev/null This could result to the following failure: skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32 head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev:<NULL> kernel BUG at net/core/skbuff.c:102! invalid opcode: 0000 [#1] SMP ... task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000 RIP: 0010:[<ffffffff8155fbd1>] [<ffffffff8155fbd1>] skb_put+0xa1/0xb0 RSP: 0018:ffff88003ae8bc68 EFLAGS: 00010296 RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000 RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8 RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900 FS: 00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0 Stack: ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550 ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00 Call Trace: [<ffffffff81628db4>] unix_stream_sendmsg+0x2c4/0x470 [<ffffffff81556f56>] sock_write_iter+0x146/0x160 [<ffffffff811d9612>] new_sync_write+0x92/0xd0 [<ffffffff811d9cd6>] vfs_write+0xd6/0x180 [<ffffffff811da499>] SyS_write+0x59/0xd0 [<ffffffff81651532>] system_call_fastpath+0x12/0x17 Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 <0f> 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 RIP [<ffffffff8155fbd1>] skb_put+0xa1/0xb0 RSP <ffff88003ae8bc68> Kernel panic - not syncing: Fatal exception Moreover, the possible minimum is 1, so we can get another kernel panic: ... BUG: unable to handle kernel paging request at ffff88013caee5c0 IP: [<ffffffff815604cf>] __alloc_skb+0x12f/0x1f0 ... Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:18 -04:00
Nimrod Andy	563d9192f9	net: fec: fix receive VLAN CTAG HW acceleration issue [ Upstream commit `af5cbc9822` ] The current driver support receive VLAN CTAG HW acceleration feature (NETIF_F_HW_VLAN_CTAG_RX) through software simulation. There calls the api .skb_copy_to_linear_data_offset() to skip the VLAN tag, but there have overlap between the two memory data point range. The patch just fix the issue. V2: Michael Grzeschik suggest to use memmove() instead of skb_copy_to_linear_data_offset(). Reported-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Fixes: `1b7bde6d65` ("net: fec: implement rx_copybreak to improve rx performance") Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:17 -04:00
WANG Cong	06e0dd7368	net_sched: fix struct tc_u_hnode layout in u32 [ Upstream commit `5778d39d07` ] We dynamically allocate divisor+1 entries for ->ht[] in tc_u_hnode: ht = kzalloc(sizeof(ht) + divisorsizeof(void *), GFP_KERNEL); So ->ht is supposed to be the last field of this struct, however this is broken, since an rcu head is appended after it. Fixes: `1ce87720d4` ("net: sched: make cls_u32 lockless") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:17 -04:00
David S. Miller	62268585e5	sparc64: Fix several bugs in memmove(). [ Upstream commit `2077cef4d5` ] Firstly, handle zero length calls properly. Believe it or not there are a few of these happening during early boot. Next, we can't just drop to a memcpy() call in the forward copy case where dst <= src. The reason is that the cache initializing stores used in the Niagara memcpy() implementations can end up clearing out cache lines before we've sourced their original contents completely. For example, considering NG4memcpy, the main unrolled loop begins like this: load src + 0x00 load src + 0x08 load src + 0x10 load src + 0x18 load src + 0x20 store dst + 0x00 Assume dst is 64 byte aligned and let's say that dst is src - 8 for this memcpy() call. That store at the end there is the one to the first line in the cache line, thus clearing the whole line, which thus clobbers "src + 0x28" before it even gets loaded. To avoid this, just fall through to a simple copy only mildly optimized for the case where src and dst are 8 byte aligned and the length is a multiple of 8 as well. We could get fancy and call GENmemcpy() but this is good enough for how this thing is actually used. Reported-by: David Ahern <david.ahern@oracle.com> Reported-by: Bob Picco <bpicco@meloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:10 -04:00
David Ahern	54762bf148	sparc: Touch NMI watchdog when walking cpus and calling printk [ Upstream commit `31aaa98c24` ] With the increase in number of CPUs calls to functions that dump output to console (e.g., arch_trigger_all_cpu_backtrace) can take a long time to complete. If IRQs are disabled eventually the NMI watchdog kicks in and creates more havoc. Avoid by telling the NMI watchdog everything is ok. Signed-off-by: David Ahern <david.ahern@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:10 -04:00
David Ahern	4cd5bcca29	sparc: perf: Make counting mode actually work [ Upstream commit `d51291cb8f` ] Currently perf-stat (aka, counting mode) does not work: $ perf stat ls ... Performance counter stats for 'ls': 1.585665 task-clock (msec) # 0.580 CPUs utilized 24 context-switches # 0.015 M/sec 0 cpu-migrations # 0.000 K/sec 86 page-faults # 0.054 M/sec <not supported> cycles <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend <not supported> instructions <not supported> branches <not supported> branch-misses 0.002735100 seconds time elapsed The reason is that state is never reset (stays with PERF_HES_UPTODATE set). Add a call to sparc_pmu_enable_event during the added_event handling. Clean up the encoding since pmu_start calls sparc_pmu_enable_event which does the same. Passing PERF_EF_RELOAD to sparc_pmu_start means the call to sparc_perf_event_set_period can be removed as well. With this patch: $ perf stat ls ... Performance counter stats for 'ls': 1.552890 task-clock (msec) # 0.552 CPUs utilized 24 context-switches # 0.015 M/sec 0 cpu-migrations # 0.000 K/sec 86 page-faults # 0.055 M/sec 5,748,997 cycles # 3.702 GHz <not supported> stalled-cycles-frontend:HG <not supported> stalled-cycles-backend:HG 1,684,362 instructions:HG # 0.29 insns per cycle 295,133 branches:HG # 190.054 M/sec 28,007 branch-misses:HG # 9.49% of all branches 0.002815665 seconds time elapsed Signed-off-by: David Ahern <david.ahern@oracle.com> Acked-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:10 -04:00
David Ahern	84763ada06	sparc: perf: Remove redundant perf_pmu_{en\|dis}able calls [ Upstream commit `5b0d4b5514` ] perf_pmu_disable is called by core perf code before pmu->del and the enable function is called by core perf code afterwards. No need to call again within sparc_pmu_del. Ditto for pmu->add and sparc_pmu_add. Signed-off-by: David Ahern <david.ahern@oracle.com> Acked-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:09 -04:00
Rob Gardner	4fb82ed6c0	sparc: semtimedop() unreachable due to comparison error [ Upstream commit `53eb251697` ] A bug was reported that the semtimedop() system call was always failing eith ENOSYS. Since SEMCTL is defined as 3, and SEMTIMEDOP is defined as 4, the comparison "call <= SEMCTL" will always prevent SEMTIMEDOP from getting through to the semaphore ops switch statement. This is corrected by changing the comparison to "call <= SEMTIMEDOP". Orabug: 20633375 Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:09 -04:00
Andreas Larsson	b8b07bdf44	sparc32: destroy_context() and switch_mm() needs to disable interrupts. [ Upstream commit `66d0f7ec9f` ] Load balancing can be triggered in the critical sections protected by srmmu_context_spinlock in destroy_context() and switch_mm() and can hang the cpu waiting for the rq lock of another cpu that in turn has called switch_mm hangning on srmmu_context_spinlock leading to deadlock. So, disable interrupt while taking srmmu_context_spinlock in destroy_context() and switch_mm() so we don't deadlock. See also commit `77b838fa1e` ("[SPARC64]: destroy_context() needs to disable interrupts.") Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-24 08:22:08 -04:00
Sasha Levin	96e199f175	Linux 3.18.10 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:05:12 -04:00
Ian Munsie	da7a053319	cxl: Add missing return statement after handling AFU errror commit `a6130ed253` upstream. We were missing a return statement in the PSL interrupt handler in the case of an AFU error, which would trigger an "Unhandled CXL PSL IRQ" warning. We do actually handle these type of errors (by notifying userspace), so add the missing return IRQ_HANDLED so we don't throw unecessary warnings. Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:54 -04:00
Ryan Grimm	3bc64c1b58	cxl: Fix device_node reference counting commit `6f963ec2d6` upstream. When unbinding and rebinding the driver on a system with a card in PHB0, this error condition is reached after a few attempts: ERROR: Bad of_node_put() on /pciex@3fffe40000000 CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152 Call Trace: [c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable) [c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0 [c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0 [c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30 [c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50 [c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0 [c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170 [c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0 [c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160 [c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60 [c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0 [c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0 [c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260 [c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100 [c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98 We are missing a call to of_node_get(). pnv_pci_to_phb_node() should call of_node_get() otherwise np's reference count isn't incremented and it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node() so it's clear it calls of_node_get(). Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com> Acked-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:54 -04:00
Ryan Grimm	0153a8f025	cxl: Use image state defaults for reloading FPGA commit `4beb5421ba` upstream. Select defaults such that a PERST causes flash image reload. Select which image based on what the card is set up to load. CXL_VSEC_PERST_LOADS_IMAGE selects whether PERST assertion causes flash image load. CXL_VSEC_PERST_SELECT_USER selects which image is loaded on the next PERST. cxl_update_image_control writes these bits into the VSEC. Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com> Acked-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:54 -04:00
Sergei Shtylyov	22374fc8ef	clk-gate: fix bit # check in clk_register_gate() commit `2e9dcdae40` upstream. In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit # should be no higher than 15, however the corresponding check is obviously off- by-one. Fixes: `045779942c` ("clk: gate: add CLK_GATE_HIWORD_MASK") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:54 -04:00
Peter Zijlstra	9acb057e97	sched/autogroup: Fix failure to set cpu.rt_runtime_us commit `1fe89e1b6d` upstream. Because task_group() uses a cache of autogroup_task_group(), whose output depends on sched_class, switching classes can generate problems. In particular, when started as fair, the cache points to the autogroup, so when switching to RT the tg_rt_schedulable() test fails for every cpu.rt_{runtime,period}_us change because now the autogroup has tasks and no runtime. Furthermore, going back to the previous semantics of varying task_group() with sched_class has the down-side that the sched_debug output varies as well, even though the task really is in the autogroup. Therefore add an autogroup exception to tg_has_rt_tasks() -- such that both (all) task_group() usages in sched/core now have one. And remove all the remnants of the variable task_group() output. Reported-by: Zefan Li <lizefan@huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <umgwanakikbuti@gmail.com> Cc: Stefan Bader <stefan.bader@canonical.com> Fixes: `8323f26ce3` ("sched: Fix race in task_group()") Link: http://lkml.kernel.org/r/20150209112237.GR5029@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:53 -04:00
Michal Hocko	c462adc8c2	vmstat: do not use deferrable delayed work for vmstat_update commit `ba4877b9ca` upstream. Vinayak Menon has reported that an excessive number of tasks was throttled in the direct reclaim inside too_many_isolated() because NR_ISOLATED_FILE was relatively high compared to NR_INACTIVE_FILE. However it turned out that the real number of NR_ISOLATED_FILE was 0 and the per-cpu vm_stat_diff wasn't transferred into the global counter. vmstat_work which is responsible for the sync is defined as deferrable delayed work which means that the defined timeout doesn't wake up an idle CPU. A CPU might stay in an idle state for a long time and general effort is to keep such a CPU in this state as long as possible which might lead to all sorts of troubles for vmstat consumers as can be seen with the excessive direct reclaim throttling. This patch basically reverts `39bf6270f5` ("VM statistics: Make timer deferrable") but it shouldn't cause any problems for idle CPUs because only CPUs with an active per-cpu drift are woken up since `7cc36bbddd` ("vmstat: on-demand vmstat workers v8") and CPUs which are idle for a longer time shouldn't have per-cpu drift. Fixes: `39bf6270f5` (VM statistics: Make timer deferrable) Signed-off-by: Michal Hocko <mhocko@suse.cz> Reported-by: Vinayak Menon <vinmenon@codeaurora.org> Acked-by: Christoph Lameter <cl@linux.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Vladimir Davydov <vdavydov@parallels.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Minchan Kim <minchan@kernel.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:53 -04:00
Uwe Kleine-König	71a2b6dff6	pinctrl: imx25: fix numbering for pins commit `34027ca2bb` upstream. The pin id for a given tuple listed in a fsl,pins property is calculated by dividing the first entry (which is also a register offset) by 4. As the first available register is at offset 0x8 and configures the pad MX25_PAD_A10 the right id for this pin is 2. All other pins are off by one, too. This patch drops the definition MX25_PAD_RESERVE1 (together with its only use) and decrements all following values by 1. Fixes: `b4a87c9b96` ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") Signed-off-by: Uwe Kleine-KÃ¶nig <u.kleine-koenig@pengutronix.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:53 -04:00
Uwe Kleine-König	248f2c55b4	pinctrl: pinctrl-imx: don't use invalid value of conf_reg commit `4ff0f034e9` upstream. The right check for conf_reg to be invalid it testing against -1 not 0 as is done in the rest of the driver. This fixes an oops that can be triggered by: cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/* Fixes: `ae75ff8145` ("pinctrl: pinctrl-imx: add imx pinctrl core driver") Signed-off-by: Uwe Kleine-KÃ¶nig <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:53 -04:00
Sergey Ryazanov	a5754abd4f	ath5k: fix spontaneus AR5312 freezes commit `8bfae4f993` upstream. Sometimes while CPU have some load and ath5k doing the wireless interface reset the whole WiSoC completely freezes. Set of tests shows that using atomic delay function while we wait interface reset helps to avoid such freezes. The easiest way to reproduce this issue: create a station interface, start continous scan with wpa_supplicant and load CPU by something. Or just create multiple station interfaces and put them all in continous scan. This patch partially reverts the commit `1846ac3dbe` ("ath5k: Use usleep_range where possible"), which replaces initial udelay() by usleep_range(). I do not know actual source of this issue, but all looks like that HW freeze is caused by transaction on internal SoC bus, while wireless block is in reset state. Also I should note that I do not know how many chips are affected, but I did not see this issue with chips, other than AR5312. CC: Jiri Slaby <jirislaby@gmail.com> CC: Nick Kossifidis <mickflemm@gmail.com> CC: Luis R. Rodriguez <mcgrof@do-not-panic.com> Fixes: `1846ac3dbe` ("ath5k: Use usleep_range where possible") Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com> Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com> Tested-by: Eric Bree <ebree@nltinc.com> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:53 -04:00
Andrew Elble	46b6f104d8	GFS2: Fix crash during ACL deletion in acl max entry check in gfs2_set_acl() commit `278702074f` upstream. Fixes: `e01580bf9e` ("gfs2: use generic posix ACL infrastructure") Reported-by: Eric Meddaugh <etmsys@rit.edu> Tested-by: Eric Meddaugh <etmsys@rit.edu> Signed-off-by: Andrew Elble <aweits@rit.edu> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:52 -04:00
Lorenzo Pieralisi	c0064e10c9	of/pci: Free resources on failure in of_pci_get_host_bridge_resources() commit `d2be00c0fb` upstream. In the function of_pci_get_host_bridge_resources() if the parsing of ranges fails, previously allocated resources inclusive of bus_range are not freed and are not expected to be freed by the function caller on error return. This patch fixes the issues by adding code that properly frees resources and bus_range before exiting the function with an error return value. Fixes: `cbe4097f8a` ("of/pci: Add support for parsing PCI host bridge resources from DT") Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Rob Herring <robh+dt@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:52 -04:00
Wanpeng Li	f42e86dcb1	sched: Fix hrtick_start() on UP commit `868933359a` upstream. The commit `177ef2a631` ("sched/deadline: Fix a precision problem in the microseconds range") forgot to change the UP version of hrtick_start(), do so now. Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com> Fixes: `177ef2a631` ("sched/deadline: Fix a precision problem in the microseconds range") [ Fixed the changelog. ] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@arm.com> Cc: Kirill Tkhai <ktkhai@parallels.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1416962647-76792-7-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:52 -04:00
Brian Norris	ac99673572	stable_kernel_rules: reorganize and update submission options commit `5de61e7aa1` upstream. The current organization of Documentation/stable_kernel_rules.txt doesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to stable@vger.kernel.org, but the instructions do not make this clear. Also, there are some established processes that are not listed -- specifically, what I call Option 2 below. This patch updates and reorganizes a bit, to make things clearer. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:52 -04:00
Bard Liao	a607783c8c	ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile commit `850529249d` upstream. RT5670_IRQ_CTRL1(0xbd) is a non volatile register. And we need to restore its value after suspend/resume. Signed-off-by: Bard Liao <bardliao@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:52 -04:00
Peter Ujfalusi	651b0e43f9	ASoC: omap-pcm: Correct dma mask commit `d51199a83a` upstream. DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be set to 32. The 64 was introduced by commit (in 2009): `a152ff24b9` ASoC: OMAP: Make DMA 64 aligned But the dma_mask and coherent_dma_mask can not be used to specify alignment. Fixes: `a152ff24b9` (ASoC: OMAP: Make DMA 64 aligned) Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Trond Myklebust	1b9428b3de	NFSv4: Don't call put_rpccred() under the rcu_read_lock() commit `7c0af9ffb7` upstream. put_rpccred() can sleep. Fixes: `8f649c3762` ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()") Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Trond Myklebust	6394d0e510	NFS: Don't invalidate a submounted dentry in nfs_prime_dcache() commit `6c441c254e` upstream. If we're traversing a directory which contains a submounted filesystem, or one that has a referral, the NFS server that is processing the READDIR request will often return information for the underlying (mounted-on) directory. It may, or may not, also return filehandle information. If this happens, and the lookup in nfs_prime_dcache() returns the dentry for the submounted directory, the filehandle comparison will fail, and we call d_invalidate(). Post-commit `8ed936b567` ("vfs: Lazily remove mounts on unlinked files and directories."), this means the entire subtree is unmounted. The following minimal patch addresses this problem by punting on the invalidation if there is a submount. Kudos to Neil Brown <neilb@suse.de> for having tracked down this issue (see link). Reported-by: Nix <nix@esperi.org.uk> Link: http://lkml.kernel.org/r/87iofju9ht.fsf@spindle.srvr.nix Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Heikki Krogerus	76e118b5f0	ACPI / LPSS: provide con_id for the clkdev commit `fcf0789a96` upstream. Commit `7d78cbefaa` (serial: 8250_dw: add ability to handle the peripheral clock) introduces handling for a second clk to 8250_dw.c which is the driver also for LPSS UART. The second clk forces us to provide identifier (con_id) for the clkdev we create. This fixes an issue where 8250_dw.c is getting the same handler for both clocks. Fixes: `7d78cbefaa` (serial: 8250_dw: add ability to handle the peripheral clock) Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Chris Wilson	78f8ef0786	ACPI / video: Load the module even if ACPI is disabled commit `6e17cb1288` upstream. i915.ko depends upon the acpi/video.ko module and so refuses to load if ACPI is disabled at runtime if for example the BIOS is broken beyond repair. acpi/video provides an optional service for i915.ko and so we should just allow the modules to load, but do no nothing in order to let the machines boot correctly. Reported-by: Bill Augur <bill-auger@programmer.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Acked-by: Aaron Lu <aaron.lu@intel.com> [ rjw: Fixed up the new comment in acpi_video_init() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Tyler Hicks	4a1167f2dd	eCryptfs: don't pass fs-specific ioctl commands through commit `6d65261a09` upstream. eCryptfs can't be aware of what to expect when after passing an arbitrary ioctl command through to the lower filesystem. The ioctl command may trigger an action in the lower filesystem that is incompatible with eCryptfs. One specific example is when one attempts to use the Btrfs clone ioctl command when the source file is in the Btrfs filesystem that eCryptfs is mounted on top of and the destination fd is from a new file created in the eCryptfs mount. The ioctl syscall incorrectly returns success because the command is passed down to Btrfs which thinks that it was able to do the clone operation. However, the result is an empty eCryptfs file. This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl commands through and then copies up the inode metadata from the lower inode to the eCryptfs inode to catch any changes made to the lower inode's metadata. Those five ioctl commands are mostly common across all filesystems but the whitelist may need to be further pruned in the future. https://bugzilla.kernel.org/show_bug.cgi?id=93691 https://launchpad.net/bugs/1305335 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Cc: Rocko <rockorequin@hotmail.com> Cc: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:51 -04:00
Yinghai Lu	e16752a8d3	efi/libstub: Fix boundary checking in efi_high_alloc() commit `7ed620bb34` upstream. While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. It turns out efi_high_alloc() boundary checking is not right. end - size will be the new start, and should not compare new start with max, we need to make sure end is smaller than max. [ Basically, with the current efi_high_alloc() code it's possible to allocate memory above 'max', because efi_high_alloc() doesn't check that the tail of the allocation is below 'max'. If you have an EFI memory map with a single entry that looks like so, [0xc0000000-0xc0004000] And want to allocate 0x3000 bytes below 0xc0003000 the current code will allocate [0xc0001000-0xc0004000], not [0xc0000000-0xc0003000] like you would expect. - Matt ] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:50 -04:00
Dan Carpenter	f3b9a854c4	efi: Small leak on error in runtime map code commit `86d68a58d0` upstream. The "> 0" here should ">= 0" so we free map_entries[0]. Fixes: `926172d460` ('efi: Export EFI runtime memory mapping to sysfs') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:50 -04:00
Andrew Elble	95379cd7da	nfsd: fix clp->cl_revoked list deletion causing softlock in nfsd commit `c876486be1` upstream. commit `2d4a532d38` ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock") removed the use of the reaplist to clean out clp->cl_revoked. It failed to change list_entry() to walk clp->cl_revoked.next instead of reaplist.next Fixes: `2d4a532d38` ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock") Reported-by: Eric Meddaugh <etmsys@rit.edu> Tested-by: Eric Meddaugh <etmsys@rit.edu> Signed-off-by: Andrew Elble <aweits@rit.edu> Reviewed-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:50 -04:00
Michel Dänzer	6a6eed5961	reservation: Remove shadowing local variable 'ret' commit `4eb2440ed6` upstream. It was causing the return value of fence_is_signaled to be ignored, making reservation objects signal too early. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:50 -04:00
Imre Deak	eb67532e61	drm/i915: avoid processing spurious/shared interrupts in low-power states commit `2dd2a883aa` upstream. Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit `e11aa36230` Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by: Klaus Ethgen <Klaus@Ethgen.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:49 -04:00
Jani Nikula	fc6f347ca3	drm/i915: Dell Chromebook 11 has PWM backlight commit `cf6f0af9fb` upstream. Add quirk for Dell Chromebook 11 backlight. Reported-and-tested-by: Owen Garland <garland.owen@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451 Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:49 -04:00
Chris Wilson	a0e57b28b7	drm/i915: Check obj->vma_list under the struct_mutex commit `6c31a614c4` upstream. When we walk the list of vma, or even for protecting against concurrent framebuffer creation, we must hold the struct_mutex or else a second thread can corrupt the list as we walk it. Fixes regression from commit `d7f46fc4e7` Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA References: https://bugs.freedesktop.org/show_bug.cgi?id=89085 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:49 -04:00
Rodrigo Vivi	914b78e88f	drm/i915/bdw: PCI IDs ending in 0xb are ULT. commit `0dc6f20b98` upstream. When reviewing patch that fixes VGA on BDW Halo Jani noticed that we also had other ULT IDs that weren't listed there. So this follow-up patch add these pci-ids as halo and fix comments on i915_pciids.h Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:49 -04:00
Alex Deucher	f69d6655cd	drm/radeon: fix 1 RB harvest config setup for TN/RL commit `dbfb00c3e7` upstream. The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:49 -04:00
Alex Deucher	7b1fcdad16	drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh commit `3d2d98ee1a` upstream. Just in case it hasn't been calculated for the mode. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
Nathan-J. Hirschauer	814475133b	drm/radeon: enable native backlight control on old macs commit `7a26f9ad1b` upstream. Commit `b7bc596ebb` ("drm/radeon: disable native backlight control on pre-r6xx asics (v2)") accidently broke backlight control on old mac laptops that use the on-GPU backlight controller. Signed-off-by: Nathan-J. Hirschauer <nathanhi@deepserve.info> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
Jason Gerecke	60efb89c4e	HID: wacom: Report ABS_MISC event for Cintiq Companion Hybrid commit `33e5df0e0e` upstream. It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to userspace when any of its ExpressKeys are pressed. This is not strictly necessary now that the pad exists on its own device, but should be fixed for consistency's sake. Traditionally both the stylus and pad shared the same device node, and xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes the Hybrid to behave incorrectly with xf86-input-wacom beginning with its 8f44f3 commit. Signed-off-by: Jason Gerecke <killertofu@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
Jiri Kosina	c6cbffb4e9	HID: fixup the conflicting keyboard mappings quirk commit `8e7b341037` upstream. The ignore check that got added in `6ce901eb61` ("HID: input: fix confusion on conflicting mappings") needs to properly check for VARIABLE reports as well (ARRAY reports should be ignored), otherwise legitimate keyboards might break. Fixes: `6ce901eb61` ("HID: input: fix confusion on conflicting mappings") Reported-by: Fredrik Hallenberg <megahallon@gmail.com> Reported-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
David Herrmann	1e1d4d7158	HID: input: fix confusion on conflicting mappings commit `6ce901eb61` upstream. On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its neighbours look like this: +---+ +---+ +-------+ \| 1 \| \| 2 \| \| 5 \| +---+ +---+ +-------+ +---+ +-----------+ \| 3 \| \| 4 \| +---+ +-----------+ On a PC-102/105 keyboard (European layout) it looks like this: +---+ +---+ +-------+ \| 1 \| \| 2 \| \| \| +---+ +---+ +-+ 4 \| +---+ +---+ \| \| \| 3 \| \| 5 \| \| \| +---+ +---+ +-----+ (Note that the number of keys is the same, but key '5' is moved down and the shape of key '4' is changed. Keys '1' to '3' are exactly the same.) The keys 1-4 report the same scan-code in HID in both layouts, even though the keysym they produce is usually different depending on the XKB-keymap used by user-space. However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout and 0x32 for the lower layout, as defined by the HID spec. This is highly confusing as the linux-input API uses a single keycode for both. So far, this was never a problem as there never has been a keyboard with both of those keys present at the same time. It would have to look something like this: +---+ +---+ +-------+ \| 1 \| \| 2 \| \| x31 \| +---+ +---+ +-------+ +---+ +---+ +-----+ \| 3 \| \|x32\| \| 4 \| +---+ +---+ +-----+ HID can represent such a keyboard, but the linux-input API cannot. Furthermore, any user-space mapping would be confused by this and, luckily, no-one ever produced such hardware. Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys is present on a hardware, this works just fine. Lets introduce hardware-vendors into this: ------------------------------------------ Unfortunately, it seems way to expensive to produce a different device for American and European layouts. Therefore, hardware-vendors put both keys, (0x31 and 0x32) on the same keyboard, but only one of them is hooked up to the physical button, the other one is 'dead'. This means, they can use the same hardware, with a different button-layout and automatically produce the correct HID events for American and European layouts. This is unproblematic for normal keyboards, as the 'dead' key will never report any KEY-DOWN events. But RollOver keyboards send the whole matrix on each key-event, allowing n-key roll-over mode. This means, we get a 0x31 and 0x32 event on each key-press. One of them will always be 0, the other reports the real state. As we map both to the same keycode, we will get spurious key-events, even though the real key-state never changed. The easiest way would be to blacklist 'dead' keys and never handle those. We could simply read the 'country' tag of USB devices and blacklist either key according to the layout. But... hardware vendors... want the same device for all countries and thus many of them set 'country' to 0 for all devices. Meh.. So we have to deal with this properly. As we cannot know which of the keys is 'dead', we either need a heuristic and track those keys, or we simply make use of our value-tracking for HID fields. We simply ignore HID events for absolute data if the data didn't change. As HID tracks events on the HID level, we haven't done the keycode translation, yet. Therefore, the 'dead' key is tracked independently of the real key, therefore, any events on it will be ignored. This patch simply discards any HID events for absolute data if it didn't change compared to the last report. We need to ignore relative and buffered-byte reports for obvious reasons. But those cannot be affected by this bug, so we're fine. Preferably, we'd do this filtering on the HID-core level. But this might break a lot of custom drivers, if they do not follow the HID specs. Therefore, we do this late in hid-input just before we inject it into the input layer (which does the exact same filtering, but on the keycode level). If this turns out to break some devices, we might have to limit filtering to EV_KEY events. But lets try to do the Right Thing first, and properly filter any absolute data that didn't change. This patch is tagged for 'stable' as it fixes a lot of n-key RollOver hardware. We might wanna wait with backporting for a while, before we know it doesn't break anything else, though. Reported-by: Adam Goode <adam@spicenitz.org> Reported-by: Fredrik Hallenberg <megahallon@gmail.com> Tested-by: Fredrik Hallenberg <megahallon@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
Ian Abbott	a437367531	staging: comedi: cb_pcidas64: fix incorrect AI range code handling commit `be8e89087e` upstream. The hardware range code values and list of valid ranges for the AI subdevice is incorrect for several supported boards. The hardware range code values for all boards except PCI-DAS4020/12 is determined by calling `ai_range_bits_6xxx()` based on the maximum voltage of the range and whether it is bipolar or unipolar, however it only returns the correct hardware range code for the PCI-DAS60xx boards. For PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar ranges. For PCI-DAS64/Mx/16 it returns the wrong code for all the ranges and the comedi range table is incorrect. Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new member `ai_range_codes` of `struct pcidas64_board` to map the comedi range table indices to the hardware range codes. Use a new comedi range table for the PCI-DAS64/Mx/16 boards (and the commented out variants). Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:48 -04:00
Mikulas Patocka	29bc14605e	dm snapshot: fix a possible invalid memory access on unload commit `22aa66a3ee` upstream. When the snapshot target is unloaded, snapshot_dtr() waits until pending_exceptions_count drops to zero. Then, it destroys the snapshot. Therefore, the function that decrements pending_exceptions_count should not touch the snapshot structure after the decrement. pending_complete() calls free_pending_exception(), which decrements pending_exceptions_count, and then it performs up_write(&s->lock) and it calls retry_origin_bios() which dereferences s->origin. These two memory accesses to the fields of the snapshot may touch the dm_snapshot struture after it is freed. This patch moves the call to free_pending_exception() to the end of pending_complete(), so that the snapshot will not be destroyed while pending_complete() is in progress. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Mikulas Patocka	ed68077f44	dm: fix a race condition in dm_get_md commit `2bec1f4a88` upstream. The function dm_get_md finds a device mapper device with a given dev_t, increases the reference count and returns the pointer. dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the device, tests that the device doesn't have DMF_DELETING or DMF_FREEING flag, drops _minor_lock and returns pointer to the device. dm_get_md then calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag, otherwise it increments the reference count. There is a possible race condition - after dm_find_md exits and before dm_get is called, there are no locks held, so the device may disappear or DMF_FREEING flag may be set, which results in BUG. To fix this bug, we need to call dm_get while we hold _minor_lock. This patch renames dm_find_md to dm_get_md and changes it so that it calls dm_get while holding the lock. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Darrick J. Wong	48703eaf51	dm io: reject unsupported DISCARD requests with EOPNOTSUPP commit `37527b8692` upstream. I created a dm-raid1 device backed by a device that supports DISCARD and another device that does NOT support DISCARD with the following dm configuration: # echo '0 2048 mirror core 1 512 2 /dev/sda 0 /dev/sdb 0' \| dmsetup create moo # lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 4K 1G 0 `-moo (dm-0) 0 4K 1G 0 sdb 0 0B 0B 0 `-moo (dm-0) 0 4K 1G 0 Notice that the mirror device /dev/mapper/moo advertises DISCARD support even though one of the mirror halves doesn't. If I issue a DISCARD request (via fstrim, mount -o discard, or ioctl BLKDISCARD) through the mirror, kmirrord gets stuck in an infinite loop in do_region() when it tries to issue a DISCARD request to sdb. The problem is that when we call do_region() against sdb, num_sectors is set to zero because q->limits.max_discard_sectors is zero. Therefore, "remaining" never decreases and the loop never terminates. To fix this: before entering the loop, check for the combination of REQ_DISCARD and no discard and return -EOPNOTSUPP to avoid hanging up the mirror device. This bug was found by the unfortunate coincidence of pvmove and a discard operation in the RHEL 6.5 kernel; upstream is also affected. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: "Martin K. Petersen" <martin.petersen@oracle.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Mikulas Patocka	0a877dfa4f	dm mirror: do not degrade the mirror on discard error commit `f2ed51ac64` upstream. It may be possible that a device claims discard support but it rejects discards with -EOPNOTSUPP. It happens when using loopback on ext2/ext3 filesystem driven by the ext4 driver. It may also happen if the underlying devices are moved from one disk on another. If discard error happens, we reject the bio with -EOPNOTSUPP, but we do not degrade the array. This patch fixes failed test shell/lvconvert-repair-transient.sh in the lvm2 testsuite if the testsuite is extracted on an ext2 or ext3 filesystem and it is being driven by the ext4 driver. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Ian Abbott	0e60c3831e	staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back commit `42b8ce6f55` upstream. `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl. This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd` back to user-space. (This occurs when the low-level Comedi driver's `do_cmdtest()` handler returns non-zero to indicate a problem with the contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has the `CMDF_BOGUS` flag set.) `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible version of the `COMEDI_CMD` ioctl. Currently, it never copies a 32-bit compatible version of `struct comedi_cmd` back to user-space, which is at odds with the way the regular `COMEDI_CMD` ioctl is handled. To fix it, change `compat_cmd()` to copy a 32-bit compatible version of the `struct comedi_cmd` back to user-space when the main ioctl handler returns `-EAGAIN`. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Hans de Goede	d3fd045f4f	sunxi: clk: Set sun6i-pll1 n_start = 1 commit `76820fcf7a` upstream. For all pll-s on sun6i n == 0 means use a multiplier of 1, rather then 0 as it means on sun4i / sun5i / sun7i. n_start = 1 is already correctly set for sun6i pll6, but was missing for pll1, this commit fixes this. Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:47 -04:00
Srinivas Kandagatla	af33873cc7	clk: Fix debugfs clk removal before inited commit `52bba9809a` upstream. Some of the clks can be registered & unregistered before the clk related debugfs entries are initialized at late_initcall. In the unregister path checking for only dentry before clk_debug_init() would lead dangling pointers in the debug clk list, because the list is already populated in register path and the clk pointer freed in unregister path. The side effect of not removing it from the list is either a null pointer dereference or if lucky to boot the system, the number of clk entries in debugfs disappear. We could add more checks like if (inited && !clk->dentry) but just removing the check for dentry made more sense as debugfs_remove_recursive() seems to be safe with null pointers. This will ensure that the unregistering clk would be removed from the debug list in all the code paths. Without this patch kernel would crash with log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 3.19.0-rc3-00007-g412f9ba-dirty #840 Hardware name: Qualcomm (Flattened Device Tree) task: ed948000 ti: ed944000 task.ti: ed944000 PC is at strlen+0xc/0x40 LR is at __create_file+0x64/0x1dc pc : [<c04ee604>] lr : [<c049f1c4>] psr: 60000013 sp : ed945e40 ip : ed945e50 fp : ed945e4c r10: 00000000 r9 : c1006094 r8 : 00000000 r7 : 000041ed r6 : 00000000 r5 : ed4af998 r4 : c11b5e28 r3 : 00000000 r2 : ed945e38 r1 : a0000013 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 8020406a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xed944248) Stack: (0xed945e40 to 0xed946000) 5e40: ed945e7c ed945e50 c049f1c4 c04ee604 c0fc2fa4 00000000 ecb748c0 c11c2b80 5e60: c0beec04 0000011c c0fc2fa4 00000000 ed945e94 ed945e80 c049f3e0 c049f16c 5e80: 00000000 00000000 ed945eac ed945e98 c08cbc50 c049f3c0 ecb748c0 c11c2b80 5ea0: ed945ed4 ed945eb0 c0fc3080 c08cbc30 c0beec04 c107e1d8 ecdf0600 c107e1d8 5ec0: c107e1d8 ecdf0600 ed945f54 ed945ed8 c0208ed4 c0fc2fb0 c026a784 c04ee628 5ee0: ed945f0c ed945ef0 c0f5d600 c04ee604 c0f5d5ec ef7fcc7d c0b40ecc 0000011c 5f00: ed945f54 ed945f10 c026a994 c0f5d5f8 c04ecc00 00000007 ef7fcc95 00000007 5f20: c0e90744 c0dd0884 ed945f54 c106cde0 00000007 c117f8c0 0000011c c0f5d5ec 5f40: c1006094 c100609c ed945f94 ed945f58 c0f5de34 c0208e50 00000007 00000007 5f60: c0f5d5ec be9b5ae0 00000000 c117f8c0 c0af1680 00000000 00000000 00000000 5f80: 00000000 00000000 ed945fac ed945f98 c0af169c c0f5dd2c ed944000 00000000 5fa0: 00000000 ed945fb0 c020f298 c0af168c 00000000 00000000 00000000 00000000 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ebcc6d33 bfffca73 [<c04ee604>] (strlen) from [<c049f1c4>] (__create_file+0x64/0x1dc) [<c049f1c4>] (__create_file) from [<c049f3e0>] (debugfs_create_dir+0x2c/0x34) [<c049f3e0>] (debugfs_create_dir) from [<c08cbc50>] (clk_debug_create_one+0x2c/0x16c) [<c08cbc50>] (clk_debug_create_one) from [<c0fc3080>] (clk_debug_init+0xdc/0x144) [<c0fc3080>] (clk_debug_init) from [<c0208ed4>] (do_one_initcall+0x90/0x1e0) [<c0208ed4>] (do_one_initcall) from [<c0f5de34>] (kernel_init_freeable+0x114/0x1e0) [<c0f5de34>] (kernel_init_freeable) from [<c0af169c>] (kernel_init+0x1c/0xfc) [<c0af169c>] (kernel_init) from [<c020f298>] (ret_from_fork+0x14/0x3c) Code: c0b40ecc e1a0c00d e92dd800 e24cb004 (e5d02000) ---[ end trace b940e45b5e25c1e7 ]--- Fixes: `6314b6796e` "clk: Don't hold prepare_lock across debugfs creation" Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:46 -04:00
Soren Brinkmann	5be4a62632	clk: zynq: Force CPU_2X clock to be ungated commit `3dccfecdb8` upstream. The CPU_2X clock does not have a classical in-kernel user, but is, amongst other things, required for OCM and debug access. Make sure this clock is not mistakenly disabled during boot up by enabling it in the platform's clock driver. Fixes: `0ee52b157b` 'clk: zynq: Add clock controller driver' Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:46 -04:00
Minh Duc Tran	83ace369e3	fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather segment boundary limit. commit `f76a610a8b` upstream. In reference to bug https://bugzilla.redhat.com/show_bug.cgi?id=1097141 Assert is seen with AMD cpu whenever calling pci_alloc_consistent. [ 29.406183] ------------[ cut here ]------------ [ 29.410505] kernel BUG at lib/iommu-helper.c:13! Signed-off-by: Minh Tran <minh.tran@emulex.com> Fixes: `6733b39a13` Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-23 21:02:46 -04:00
Ryusuke Konishi	814643bcbf	nilfs2: fix potential memory overrun on inode commit `957ed60b53` upstream. Each inode of nilfs2 stores a root node of a b-tree, and it turned out to have a memory overrun issue: Each b-tree node of nilfs2 stores a set of key-value pairs and the number of them (in "bn_nchildren" member of nilfs_btree_node struct), as well as a few other "bn_*" members. Since the value of "bn_nchildren" is used for operations on the key-values within the b-tree node, it can cause memory access overrun if a large number is incorrectly set to "bn_nchildren". For instance, nilfs_btree_node_lookup() function determines the range of binary search with it, and too large "bn_nchildren" leads nilfs_btree_node_get_key() in that function to overrun. As for intermediate b-tree nodes, this is prevented by a sanity check performed when each node is read from a drive, however, no sanity check has been done for root nodes stored in inodes. This patch fixes the issue by adding missing sanity check against b-tree root nodes so that it's called when on-memory inodes are read from ifile, inode metadata file. Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:46 -04:00
Ilya Nelkenbaum	6ff59abff6	IB/core: When marshaling ucma path from user-space, clear unused fields commit `c2be9dc0e0` upstream. When marshaling a user path to the kernel struct ib_sa_path, we need to zero smac and dmac and set the vlan id to the "no vlan" value. This is to ensure that Ethernet attributes are not used with InfiniBand QPs. Fixes: `dd5f03beb4` ("IB/core: Ethernet L2 attributes in verbs/cm structures") Signed-off-by: Ilya Nelkenbaum <ilyan@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:46 -04:00
Moshe Lazer	f90ead8d0f	IB/core: Fix deadlock on uverbs modify_qp error flow commit `0fb8bcf022` upstream. The deadlock occurs in __uverbs_modify_qp: we take a lock (idr_read_qp) and in case of failure in ib_resolve_eth_l2_attrs we don't release it (put_qp_read). Fix that. Fixes: `ed4c54e5b4` ("IB/core: Resolve Ethernet L2 addresses when modifying QP") Signed-off-by: Moshe Lazer <moshel@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:45 -04:00
Or Gerlitz	b092f84af2	IB/mlx4: Fix wrong usage of IPv4 protocol for multicast attach/detach commit `e9a7faf11a` upstream. The MLX4_PROT_IB_IPV4 protocol should only be used with RoCEv2 and such. Removing this wrong usage allows to run multicast applications over RoCE. Fixes: `d487ee7774` ("IB/mlx4: Use IBoE (RoCE) IP based GIDs in the port GID table") Reported-by: Carol Soto <clsoto@linux.vnet.ibm.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:45 -04:00
Majd Dibbiny	f8a4faf99f	IB/mlx4: Fix memory leak in __mlx4_ib_modify_qp commit `bede98e781` upstream. In case handle_eth_ud_smac_index fails, we need to free the allocated resources. Fixes: `2f5bb47368` ("mlx4: Add ref counting to port MAC table for RoCE") Signed-off-by: Majd Dibbiny <majd@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:45 -04:00
Dan Carpenter	aeda89ac0f	IB/mlx5: Fix error code in get_port_caps() commit `f614fc15ae` upstream. The current code returns success when kmalloc() fails. It should return an error code, -ENOMEM. Fixes: `e126ba97db` ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:45 -04:00
Roi Dayan	78a1437c7f	IB/iser: Use correct dma direction when unmapping SGs commit `c6c95ef4ce` upstream. We always unmap SGs with the same direction instead of unmapping with the direction the mapping was done, fix that. Fixes: `9a8b08fad2` ("IB/iser: Generalize iser_unmap_task_data and [...]") Signed-off-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Sagi Grimberg	caa2a1adfe	IB/iser: Fix memory regions possible leak commit `6606e6a2ff` upstream. When teardown process starts during live IO, we need to keep the memory regions pool (frmr/fmr) until all in-flight tasks are properly released, since each task may return a memory region to the pool. In order to do this, we pass a destroy flag to iser_free_ib_conn_res to indicate we can destroy the device and the memory regions pool. iser_conn_release will pass it as true and also DEVICE_REMOVAL event (we need to let the device to properly remove). Also, Since we conditionally call iser_free_rx_descriptors, remove the extra check on iser_conn->rx_descs. Fixes: `5426b1711f` ("IB/iser: Collapse cleanup and disconnect handlers") Reported-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Mitko Haralanov	bbc56fba25	IB/qib: Do not write EEPROM commit `18c0b82a3e` upstream. This changeset removes all the code that allows the driver to write to the EEPROM and update the recorded error counters and power on hours. These two stats are unused and writing them exposes a timing risk which could leave the EEPROM in a bad state preventing further normal operation of the HCA. Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Mitko Haralanov <mitko.haralanov@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Tony Battersby	26a344876a	sg: fix read() error reporting commit `3b524a683a` upstream. Fix SCSI generic read() incorrectly returning success after detecting an error. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Sebastian Andrzej Siewior	636697380e	locking/rtmutex: Avoid a NULL pointer dereference on deadlock commit `8d1e5a1a1c` upstream. With task_blocks_on_rt_mutex() returning early -EDEADLK we never add the waiter to the waitqueue. Later, we try to remove it via remove_waiter() and go boom in rt_mutex_top_waiter() because rb_entry() gives a NULL pointer. ( Tested on v3.18-RT where rtmutex is used for regular mutex and I tried to get one twice in a row. ) Not sure when this started but I guess `397335f004` ("rtmutex: Fix deadlock detector for real") or commit `3d5c9340d1` ("rtmutex: Handle deadlock detection smarter"). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1424187823-19600-1-git-send-email-bigeasy@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Hui Wang	e055b8cf33	ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk commit `70658b9949` upstream. BugLink: https://bugs.launchpad.net/bugs/1428947 Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:44 -04:00
Takashi Iwai	33da15b0eb	ALSA: hda - Disable runtime PM for Panther Point again commit `de5d0ad506` upstream. This is essentially a partial revert of the commit [`b1920c2110`: 'ALSA: hda - Enable runtime PM on Panther Point']. There was a bug report showing the HD-audio bus hang during runtime PM on HP Spectre XT. Reported-by: Dang Sananikone <dang.sananikone@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:43 -04:00
Jaroslav Kysela	fc30e76c8a	ALSA: hda: controller code - do not export static functions commit `37ed398839` upstream. It is a bad idea to export static functions. GCC for some platforms shows errors like: error: __ksymtab_azx_get_response causes a section type conflict Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-23 21:02:43 -04:00
Takashi Iwai	c78962a5cf	ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec commit `6426460e5d` upstream. BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need to give explicitly here. Reported-and-tested-by: Misan Thropos <misanthropos@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:29 -04:00
Takashi Iwai	10556d5c38	ALSA: pcm: Don't leave PREPARED state after draining commit `70372a7566` upstream. When a PCM draining is performed to an empty stream that has been already in PREPARED state, the current code just ignores and leaves as it is, although the drain is supposed to set all such streams to SETUP state. This patch covers that overlooked case. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:28 -04:00
Sebastian Andrzej Siewior	d2d74ad4fe	serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO" commit `ca8bb4aefb` upstream. This reverts commit `0aa525d118`. The conditional RX-FIFO read seems to cause spurious interrupts and we see just: \|serial8250: too much work for irq29 The previous behaviour was "default" for decades and Marvell's 88f6282 SoC might not be the only that relies on it. Therefore the Omap fix is reverted for now. Fixes: `0aa525d118` ("tty: serial: 8250_core: read only RX if there is something in the FIFO") Reported-By: Nicolas Schichan <nschichan@freebox.fr> Debuged-By: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:28 -04:00
Jiri Slaby	8ca9d12987	tty: fix up atime/mtime mess, take four commit `f0bf0bd079` upstream. This problem was taken care of three times already in * `b0de59b573` (TTY: do not update atime/mtime on read/write), * `37b7f3c765` (TTY: fix atime/mtime regression), and * `b0b885657b` (tty: fix up atime/mtime mess, take three) But it still misses one point. As John Paul correctly points out, we do not care about setting date. If somebody ever changes wall time backwards (by mistake for example), tty timestamps are never updated until the original wall time passes. So check the absolute difference of times and if it large than "8 seconds or so", always update the time. That means we will update immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the check, but it was always that way. Thanks John for serving me this so nicely debugged. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: John Paul Perry <john_paul.perry@alcatel-lucent.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:28 -04:00
Vineet Gupta	b7dc640d64	ARC: Fix KSTK_ESP() commit `13648b0118` upstream. /proc/<pid>/maps currently don't annotate stack vma with "[stack]" This is because KSTK_ESP ie expected to return usermode SP of tsk while currently it returns the kernel mode SP of a sleeping tsk. While the fix is trivial, we also need to adjust the ARC kernel stack unwinder to not use KSTK_SP and friends any more. Reported-and-suggested-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:27 -04:00
Chuck Lever	8ed378b171	SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock commit `813b00d63f` upstream. Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock. xprt_complete_bc_request() should do the same. Fixes: `2ea24497a1` ("SUNRPC: RPC callbacks may be split . . .") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:27 -04:00
Al Viro	ca261c91b5	sunrpc: fix braino in ->poll() commit `1711fd9add` upstream. POLL_OUT isn't what callers of ->poll() are expecting to see; it's actually __SI_POLL \| 2 and it's a siginfo code, not a poll bitmap bit... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Bruce Fields <bfields@fieldses.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:27 -04:00
Al Viro	208fb83dac	procfs: fix race between symlink removals and traversals commit `7e0e953bb0` upstream. use_pde()/unuse_pde() in ->follow_link()/->put_link() resp. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:27 -04:00
Al Viro	c74eb981fa	debugfs: leave freeing a symlink body until inode eviction commit `0db59e5929` upstream. As it is, we have debugfs_remove() racing with symlink traversals. Supply ->evict_inode() and do freeing there - inode will remain pinned until we are done with the symlink body. And rip the idiocy with checking if dentry is positive right after we'd verified debugfs_positive(), which is a stronger check... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:27 -04:00
Al Viro	be9eb99538	autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation commit `0a280962dc` upstream. X-Coverup: just ask spender Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:26 -04:00
Johan Hovold	318dc9ceff	USB: serial: fix tty-device error handling at probe commit `ca4383a394` upstream. Add missing error handling when registering the tty device at port probe. This avoids trying to remove an uninitialised character device when the port device is removed. Fixes: `1da177e4c3` ("Linux-2.6.12-rc2") Reported-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:26 -04:00
Johan Hovold	acc69639af	USB: serial: fix potential use-after-free after failed probe commit `07fdfc5e9f` upstream. Fix return value in probe error path, which could end up returning success (0) on errors. This could in turn lead to use-after-free or double free (e.g. in port_remove) when the port device is removed. Fixes: `c706ebdfc8` ("USB: usb-serial: call port_probe and port_remove at the right times") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:26 -04:00
Johan Hovold	2e52da5fbf	TTY: fix tty_wait_until_sent on 64-bit machines commit `79fbf4a550` upstream. Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an infinite timeout (0) would be passed to the underlying tty-driver's wait_until_sent-operation as a negative timeout (-1), causing it to return immediately. This manifests itself for example as tcdrain() returning immediately, drivers not honouring the drain flags when setting terminal attributes, or even dropped data on close as a requested infinite closing-wait timeout would be ignored. The first symptom was reported by Asier LLANO who noted that tcdrain() returned prematurely when using the ftdi_sio usb-serial driver. Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the underlying tty driver. Note that the serial-core wait_until_sent-implementation is not affected by this bug due to a lucky chance (comparison to an unsigned maximum timeout), and neither is the cyclades one that had an explicit check for negative timeouts, but all other tty drivers appear to be affected. Fixes: `1da177e4c3` ("Linux-2.6.12-rc2") Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:26 -04:00
Johan Hovold	ec02f95f55	USB: serial: fix infinite wait_until_sent timeout commit `f528bf4f57` upstream. Make sure to handle an infinite timeout (0). Note that wait_until_sent is currently never called with a 0-timeout argument due to a bug in tty_wait_until_sent. Fixes: `dcf0105039` ("USB: serial: add generic wait_until_sent implementation") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:26 -04:00
Johan Hovold	d6bc66d775	net: irda: fix wait_until_sent poll timeout commit `2c3fbe3cf2` upstream. In case an infinite timeout (0) is requested, the irda wait_until_sent implementation would use a zero poll timeout rather than the default 200ms. Note that wait_until_sent is currently never called with a 0-timeout argument due to a bug in tty_wait_until_sent. Fixes: `1da177e4c3` ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Jouni Malinen	13c54411be	mac80211: Send EAPOL frames at lowest rate commit `9c1c98a3bb` upstream. The current minstrel_ht rate control behavior is somewhat optimistic in trying to find optimum TX rate. While this is usually fine for normal Data frames, there are cases where a more conservative set of retry parameters would be beneficial to make the connection more robust. EAPOL frames are critical to the authentication and especially the EAPOL-Key message 4/4 (the last message in the 4-way handshake) is important to get through to the AP. If that message is lost, the only recovery mechanism in many cases is to reassociate with the AP and start from scratch. This can often be avoided by trying to send the frame with more conservative rate and/or with more link layer retries. In most cases, minstrel_ht is currently using the initial EAPOL-Key frames for probing higher rates and this results in only five link layer transmission attempts (one at high(ish) MCS and four at MCS0). While this works with most APs, it looks like there are some deployed APs that may have issues with the EAPOL frames using HT MCS immediately after association. Similarly, there may be issues in cases where the signal strength or radio environment is not good enough to be able to get frames through even at couple of MCS 0 tries. The best approach for this would likely to be to reduce the TX rate for the last rate (3rd rate parameter in the set) to a low basic rate (say, 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly requires some more effort. For now, we can start with a simple one-liner that forces the minimum rate to be used for EAPOL frames similarly how the TX rate is selected for the IEEE 802.11 Management frames. This does result in a small extra latency added to the cases where the AP would be able to receive the higher rate, but taken into account how small number of EAPOL frames are used, this is likely to be insignificant. A future optimization in the minstrel_ht design can also allow this patch to be reverted to get back to the more optimized initial TX rate. It should also be noted that many drivers that do not use minstrel as the rate control algorithm are already doing similar workarounds by forcing the lowest TX rate to be used for EAPOL frames. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Mathias Nyman	1d2dcde822	xhci: Workaround for PME stuck issues in Intel xhci commit `b8cb91e058` upstream. The xhci in Intel Sunrisepoint and Cherryview platforms need a driver workaround for a Stuck PME that might either block PME events in suspend, or create spurious PME events preventing runtime suspend. Workaround is to clear a internal PME flag, BIT(28) in a vendor specific PMCTRL register at offset 0x80a4, in both suspend resume callbacks Without this, xhci connected usb devices might never be able to wake up the system from suspend, or prevent device from going to suspend (xhci d3) Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Aleksander Morgado	662a8fbce7	xhci: fix reporting of 0-sized URBs in control endpoint commit `45ba2154d1` upstream. When a control transfer has a short data stage, the xHCI controller generates two transfer events: a COMP_SHORT_TX event that specifies the untransferred amount, and a COMP_SUCCESS event. But when the data stage is not short, only the COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless urb->actual_length was set already by a previous COMP_SHORT_TX event. The driver checks this by seeing whether urb->actual_length == 0, but this alone is the wrong test, as it is entirely possible for a short transfer to have an urb->actual_length = 0. This patch changes the xhci driver to rely on a new td->urb_length_set flag, which is set to true when a COMP_SHORT_TX event is received and the URB length updated at that stage. This fixes a bug which affected the HSO plugin, which relies on URBs with urb->actual_length == 0 to halt re-submitting the RX URB in the control endpoint. Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Mathias Nyman	cc405315a7	xhci: Allocate correct amount of scratchpad buffers commit `6596a926b0` upstream. Include the high order bit fields for Max scratchpad buffers when calculating how many scratchpad buffers are needed. I'm suprised this hasn't caused more issues, we never allocated more than 32 buffers even if xhci needed more. Either we got lucky and xhci never really used past that area, or then we got enough zeroed dma memory anyway. Should be backported as far back as possible Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Tested-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Maxime Ripard	9e3e203f16	usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks commit `1e7e4fb664` upstream. The commit `9737479285` ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window. However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock. Things get messy when EPROBE_DEFER is involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever. Fix this by running the quirks after the clock has been enabled by the driver. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:25 -04:00
Andrzej Pietrasiewicz	8bea8b4563	usb: gadget: configfs: don't NUL-terminate (sub)compatible ids commit `a0456399fb` upstream. The "Extended Compat ID OS Feature Descriptor Specification" does not require the (sub)compatible ids to be NUL-terminated, because they are placed in a fixed-size buffer and only unused parts of it should contain NULs. If the buffer is fully utilized, there is no place for NULs. Consequently, the code which uses desc->ext_compat_id never expects the data contained to be NUL terminated. If the compatible id is stored after sub-compatible id, and the compatible id is full length (8 bytes), the (useless) NUL terminator overwrites the first byte of the sub-compatible id. If the sub-compatible id is full length (8 bytes), the (useless) NUL terminator ends up out of the buffer. The situation can happen in the RNDIS function, where the buffer is a part of struct f_rndis_opts. The next member of struct f_rndis_opts is a mutex, so its first byte gets overwritten. The said byte is a part of a mutex'es member which contains the information on whether the muext is locked or not. This can lead to a deadlock, because, in a configfs-composed gadget when a function is linked into a configuration with config_usb_cfg_link(), usb_get_function() is called, which then calls rndis_alloc(), which tries locking the same mutex and (wrongly) finds it already locked. This patch eliminates NUL terminating of the (sub)compatible id. Fixes: `da4243145f`: "usb: gadget: configfs: OS Extended Compatibility descriptors support" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:24 -04:00
George Cherian	092140164c	usb: dwc3: dwc3-omap: Fix disable IRQ commit `96e5d31244` upstream. In the wrapper the IRQ disable should be done by writing 1's to the IRQ_CLR register. Existing code is broken because it instead writes zeros to IRQ_SET register. Fix this by adding functions dwc3_omap_write_irqmisc_clr() and dwc3_omap_write_irq0_clr() which do the right thing. Fixes: `72246da40f` ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:24 -04:00
Max Mansfield	e377af7025	usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards commit `c7d373c3f0` upstream. This patch integrates Cyber Cortex AV boards with the existing ftdi_jtag_quirk in order to use serial port 0 with JTAG which is required by the manufacturers' software. Steps: 2 [ftdi_sio_ids.h] 1. Defined the device PID [ftdi_sio.c] 2. Added a macro declaration to the ids array, in order to enable the jtag quirk for the device. Signed-off-by: Max Mansfield <max.m.mansfield@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:24 -04:00
Mark Glover	7ab630607a	USB: ftdi_sio: add PIDs for Actisense USB devices commit `f6950344d3` upstream. These product identifiers (PID) all deal with marine NMEA format data used on motor boats and yachts. We supply the programmed devices to Chetco, for use inside their equipment. The PIDs are a direct copy of our Windows device drivers (FTDI drivers with altered PIDs). Signed-off-by: Mark Glover <mark@actisense.com> [johan: edit commit message slightly ] Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:24 -04:00
Alan Stern	9705b41015	USB: usbfs: don't leak kernel data in siginfo commit `f0c2b68198` upstream. When a signal is delivered, the information in the siginfo structure is copied to userspace. Good security practice dicatates that the unused fields in this structure should be initialized to 0 so that random kernel stack data isn't exposed to the user. This patch adds such an initialization to the two places where usbfs raises signals. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Dave Mielke <dave@mielke.cc> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:24 -04:00
Johan Hovold	4057033425	USB: mxuport: fix null deref when used as a console commit `db81de767e` upstream. Fix null-pointer dereference at probe when the device is used as a console, in which case the tty argument to open will be NULL. Fixes: `ee467a1f20` ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:23 -04:00
Michiel vd Garde	e7d3ac3545	USB: serial: cp210x: Adding Seletek device id's commit `675af70856` upstream. These device ID's are not associated with the cp210x module currently, but should be. This patch allows the devices to operate upon connecting them to the usb bus as intended. Signed-off-by: Michiel van de Garde <mgparser@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:23 -04:00
Johan Hovold	64264c33bf	Revert "USB: serial: make bulk_out_size a lower limit" commit `bc4b1f486f` upstream. This reverts commit `5083fd7bdf`. A bulk-out size smaller than the end-point size is indeed valid. The offending commit broke the usb-debug driver for EHCI debug devices, which use 8-byte buffers. Fixes: `5083fd7bdf` ("USB: serial: make bulk_out_size a lower limit") Reported-by: "Li, Elvin" <elvin.li@intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:23 -04:00
Hans de Goede	ddcc85e52e	uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539 commit `59e980efaf` upstream. Like the JMicron JMS567 enclosures with the JMS539 choke on report-opcodes, so avoid it. Tested-and-reported-by: Tom Arild Naess <tanaess@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:23 -04:00
James Hogan	a3ee1048dd	KVM: MIPS: Fix trace event to save PC directly commit `b3cffac04e` upstream. Currently the guest exit trace event saves the VCPU pointer to the structure, and the guest PC is retrieved by dereferencing it when the event is printed rather than directly from the trace record. This isn't safe as the printing may occur long afterwards, after the PC has changed and potentially after the VCPU has been freed. Usually this results in the same (wrong) PC being printed for multiple trace events. It also isn't portable as userland has no way to access the VCPU data structure when interpreting the trace record itself. Lets save the actual PC in the structure so that the correct value is accessible later. Fixes: `669e846e6c` ("KVM/MIPS32: MIPS arch specific APIs for KVM") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:22 -04:00
Paolo Bonzini	c8b6504b25	KVM: emulate: fix CMPXCHG8B on 32-bit hosts commit `4ff6f8e61e` upstream. This has been broken for a long time: it broke first in 2.6.35, then was almost fixed in 2.6.36 but this one-liner slipped through the cracks. The bug shows up as an infinite loop in Windows 7 (and newer) boot on 32-bit hosts without EPT. Windows uses CMPXCHG8B to write to page tables, which causes a page fault if running without EPT; the emulator is then called from kvm_mmu_page_fault. The loop then happens if the higher 4 bytes are not 0; the common case for this is that the NX bit (bit 63) is 1. Fixes: `6550e1f165` Fixes: `16518d5ada` Reported-by: Erik Rull <erik.rull@rdsoftware.de> Tested-by: Erik Rull <erik.rull@rdsoftware.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:22 -04:00
Quentin Casasnovas	218c886394	Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref. commit `dd9ef135e3` upstream. Improper arithmetics when calculting the address of the extended ref could lead to an out of bounds memory read and kernel panic. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:22 -04:00
Filipe Manana	0ab9252919	Btrfs: fix data loss in the fast fsync path commit `3a8b36f378` upstream. When using the fast file fsync code path we can miss the fact that new writes happened since the last file fsync and therefore return without waiting for the IO to finish and write the new extents to the fsync log. Here's an example scenario where the fsync will miss the fact that new file data exists that wasn't yet durably persisted: 1. fs_info->last_trans_committed == N - 1 and current transaction is transaction N (fs_info->generation == N); 2. do a buffered write; 3. fsync our inode, this clears our inode's full sync flag, starts an ordered extent and waits for it to complete - when it completes at btrfs_finish_ordered_io(), the inode's last_trans is set to the value N (via btrfs_update_inode_fallback -> btrfs_update_inode -> btrfs_set_inode_last_trans); 4. transaction N is committed, so fs_info->last_trans_committed is now set to the value N and fs_info->generation remains with the value N; 5. do another buffered write, when this happens btrfs_file_write_iter sets our inode's last_trans to the value N + 1 (that is fs_info->generation + 1 == N + 1); 6. transaction N + 1 is started and fs_info->generation now has the value N + 1; 7. transaction N + 1 is committed, so fs_info->last_trans_committed is set to the value N + 1; 8. fsync our inode - because it doesn't have the full sync flag set, we only start the ordered extent, we don't wait for it to complete (only in a later phase) therefore its last_trans field has the value N + 1 set previously by btrfs_file_write_iter(), and so we have: inode->last_trans <= fs_info->last_trans_committed (N + 1) (N + 1) Which made us not log the last buffered write and exit the fsync handler immediately, returning success (0) to user space and resulting in data loss after a crash. This can actually be triggered deterministically and the following excerpt from a testcase I made for xfstests triggers the issue. It moves a dummy file across directories and then fsyncs the old parent directory - this is just to trigger a transaction commit, so moving files around isn't directly related to the issue but it was chosen because running 'sync' for example does more than just committing the current transaction, as it flushes/waits for all file data to be persisted. The issue can also happen at random periods, since the transaction kthread periodicaly commits the current transaction (about every 30 seconds by default). The body of the test is: _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create our main test file 'foo', the one we check for data loss. # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync' # bit from its flags (btrfs inode specific flags). $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \ -c "fsync" $SCRATCH_MNT/foo \| _filter_xfs_io # Now create one other file and 2 directories. We will move this second file # from one directory to the other later because it forces btrfs to commit its # currently open transaction if we fsync the old parent directory. This is # necessary to trigger the data loss bug that affected btrfs. mkdir $SCRATCH_MNT/testdir_1 touch $SCRATCH_MNT/testdir_1/bar mkdir $SCRATCH_MNT/testdir_2 # Make sure everything is durably persisted. sync # Write more 8Kb of data to our file. $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo \| _filter_xfs_io # Move our 'bar' file into a new directory. mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar # Fsync our first directory. Because it had a file moved into some other # directory, this made btrfs commit the currently open transaction. This is # a condition necessary to trigger the data loss bug. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1 # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of # data we wrote previously to be persisted and available if a crash happens. # This did not happen with btrfs, because of the transaction commit that # happened when we fsynced the parent directory. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # Now check that all data we wrote before are available. echo "File content after log replay:" od -t x1 $SCRATCH_MNT/foo status=0 exit The expected golden output for the test, which is what we get with this fix applied (or when running against ext3/4 and xfs), is: wrote 8192/8192 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 8192/8192 bytes at offset 8192 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) File content after log replay: 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb * 0040000 Without this fix applied, the output shows the test file does not have the second 8Kb extent that we successfully fsynced: wrote 8192/8192 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 8192/8192 bytes at offset 8192 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) File content after log replay: 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0020000 So fix this by skipping the fsync only if we're doing a full sync and if the inode's last_trans is <= fs_info->last_trans_committed, or if the inode is already in the log. Also remove setting the inode's last_trans in btrfs_file_write_iter since it's useless/unreliable. Also because btrfs_file_write_iter no longer sets inode->last_trans to fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't bail out if last_trans is 0, otherwise something as simple as the following example wouldn't log the second write on the last fsync: 1. write to file 2. fsync file 3. fsync file \|--> btrfs_inode_in_log() returns true and it set last_trans to 0 4. write to file \|--> btrfs_file_write_iter() no longers sets last_trans, so it remained with a value of 0 5. fsync \|--> inode->last_trans == 0, so it bails out without logging the second write A test case for xfstests will be sent soon. Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:22 -04:00
David Sterba	d771f1d494	btrfs: fix lost return value due to variable shadowing commit `1932b7be97` upstream. A block-local variable stores error code but btrfs_get_blocks_direct may not return it in the end as there's a ret defined in the function scope. Fixes: `d187663ef2` ("Btrfs: lock extents as we map them in DIO") Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:22 -04:00
Filipe Manana	67b67dfa59	Btrfs: fix fsync race leading to ordered extent memory leaks commit `4d884fceaa` upstream. We can have multiple fsync operations against the same file during the same transaction and they can collect the same ordered extents while they don't complete (still accessible from the inode's ordered tree). If this happens, those ordered extents will never get their reference counts decremented to 0, leading to memory leaks and inode leaks (an iput for an ordered extent's inode is scheduled only when the ordered extent's refcount drops to 0). The following sequence diagram explains this race: CPU 1 CPU 2 btrfs_sync_file() btrfs_sync_file() mutex_lock(inode->i_mutex) btrfs_log_inode() btrfs_get_logged_extents() --> collects ordered extent X --> increments ordered extent X's refcount btrfs_submit_logged_extents() mutex_unlock(inode->i_mutex) mutex_lock(inode->i_mutex) btrfs_sync_log() btrfs_wait_logged_extents() --> list_del_init(&ordered->log_list) btrfs_log_inode() btrfs_get_logged_extents() --> Adds ordered extent X to logged_list because at this point: list_empty(&ordered->log_list) && test_bit(BTRFS_ORDERED_LOGGED, &ordered->flags) == 0 --> Increments ordered extent X's refcount --> check if ordered extent's io is finished or not, start it if necessary and wait for it to finish --> sets bit BTRFS_ORDERED_LOGGED on ordered extent X's flags and adds it to trans->ordered btrfs_sync_log() finishes btrfs_submit_logged_extents() btrfs_log_inode() finishes mutex_unlock(inode->i_mutex) btrfs_sync_file() finishes btrfs_sync_log() btrfs_wait_logged_extents() --> Sees ordered extent X has the bit BTRFS_ORDERED_LOGGED set in its flags --> X's refcount is untouched btrfs_sync_log() finishes btrfs_sync_file() finishes btrfs_commit_transaction() --> called by transaction kthread for e.g. btrfs_wait_pending_ordered() --> waits for ordered extent X to complete --> decrements ordered extent X's refcount by 1 only, corresponding to the increment done by the fsync task ran by CPU 1 In the scenario of the above diagram, after the transaction commit, the ordered extent will remain with a refcount of 1 forever, leaking the ordered extent structure and preventing the i_count of its inode from ever decreasing to 0, since the delayed iput is scheduled only when the ordered extent's refcount drops to 0, preventing the inode from ever being evicted by the VFS. Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to mean that an ordered extent is already being processed by an fsync call, which will attach it to the current transaction, preventing it from being collected by subsequent fsync operations against the same inode. This race was introduced with the following change (added in 3.19 and backported to stable 3.18 and 3.17): Btrfs: make sure logged extents complete in the current transaction V3 commit `50d9aa99bd` I ran into this issue while running xfstests/generic/113 in a loop, which failed about 1 out of 10 runs with the following warning in dmesg: [ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]() [ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo ppy e1000 scsi_mod [last unloaded: btrfs] [ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G W 3.19.0-rc5-btrfs-next-4+ #1 [ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 2612.457709] 0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8 [ 2612.459829] 0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000 [ 2612.461564] ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068 [ 2612.463163] Call Trace: [ 2612.463719] [<ffffffff8142425e>] dump_stack+0x4c/0x65 [ 2612.464789] [<ffffffff81045308>] warn_slowpath_common+0xa1/0xbb [ 2612.466026] [<ffffffffa036da56>] ? free_fs_root+0x36/0x133 [btrfs] [ 2612.467247] [<ffffffff810453c5>] warn_slowpath_null+0x1a/0x1c [ 2612.468416] [<ffffffffa036da56>] free_fs_root+0x36/0x133 [btrfs] [ 2612.469625] [<ffffffffa036f2a7>] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs] [ 2612.471251] [<ffffffffa036f353>] btrfs_free_fs_roots+0xa4/0xd6 [btrfs] [ 2612.472536] [<ffffffff8142612e>] ? wait_for_completion+0x24/0x26 [ 2612.473742] [<ffffffffa0370bbc>] close_ctree+0x1f3/0x33c [btrfs] [ 2612.475477] [<ffffffff81059d1d>] ? destroy_workqueue+0x148/0x1ba [ 2612.476695] [<ffffffffa034e3da>] btrfs_put_super+0x19/0x1b [btrfs] [ 2612.477911] [<ffffffff81153e53>] generic_shutdown_super+0x73/0xef [ 2612.479106] [<ffffffff811540e2>] kill_anon_super+0x13/0x1e [ 2612.480226] [<ffffffffa034e1e3>] btrfs_kill_super+0x17/0x23 [btrfs] [ 2612.481471] [<ffffffff81154307>] deactivate_locked_super+0x3b/0x50 [ 2612.482686] [<ffffffff811547a7>] deactivate_super+0x3f/0x43 [ 2612.483791] [<ffffffff8116b3ed>] cleanup_mnt+0x59/0x78 [ 2612.484842] [<ffffffff8116b44c>] __cleanup_mnt+0x12/0x14 [ 2612.485900] [<ffffffff8105d019>] task_work_run+0x8f/0xbc [ 2612.486960] [<ffffffff810028d8>] do_notify_resume+0x5a/0x6b [ 2612.488083] [<ffffffff81236e5b>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 2612.489333] [<ffffffff8142a17f>] int_signal+0x12/0x17 [ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]--- [ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds. Have a nice day... Kmemleak confirmed the ordered extent leak (and btrfs inode specific structures such as delayed nodes): $ cat /sys/kernel/debug/kmemleak unreferenced object 0xffff880154290db0 (size 576): comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s) hex dump (first 32 bytes): 01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff .@.........N.... 00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff ..........)T.... backtrace: [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83 [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190 [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs] [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs] [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs] [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff88014ef11db0 (size 576): comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s) hex dump (first 32 bytes): 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff ...........N.... backtrace: [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83 [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190 [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs] [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs] [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs] [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff8800336feda8 (size 584): comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s) hex dump (first 32 bytes): 00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00 .@>........B.... 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 ................ backtrace: [<ffffffff8114eb34>] create_object+0x172/0x29a [<ffffffff8141d790>] kmemleak_alloc+0x25/0x41 [<ffffffff81141ae6>] kmemleak_alloc_recursive.constprop.52+0x16/0x18 [<ffffffff81145288>] kmem_cache_alloc+0xf7/0x198 [<ffffffffa0389243>] __btrfs_add_ordered_extent+0x43/0x309 [btrfs] [<ffffffffa038968b>] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs] [<ffffffffa03810e2>] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs] [<ffffffff81181349>] do_blockdev_direct_IO+0x62a/0xb47 [<ffffffff8118189a>] __blockdev_direct_IO+0x34/0x36 [<ffffffffa03776e5>] btrfs_direct_IO+0x16a/0x1e8 [btrfs] [<ffffffff81100373>] generic_file_direct_write+0xb8/0x12d [<ffffffffa038615c>] btrfs_file_write_iter+0x24b/0x42f [btrfs] [<ffffffff8118bb0d>] aio_run_iocb+0x2b7/0x32e [<ffffffff8118c99a>] do_io_submit+0x26e/0x2ff [<ffffffff8118ca3b>] SyS_io_submit+0x10/0x12 [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:21 -04:00
Alexander Usyskin	85f1ab8308	mei: make device disabled on stop unconditionally commit `6c15a8516b` upstream. Set the internal device state to to disabled after hardware reset in stop flow. This will cover cases when driver was not brought to disabled state because of an error and in stop flow we wish not to retry the reset. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:21 -04:00
Angelo Compagnucci	2c76bd8b40	iio:adc:mcp3422 Fix incorrect scales table commit `9e128ced38` upstream. This patch fixes uncorrect order of mcp3422_scales table, the values was erroneously transposed. It removes also an unused array and a wrong comment. Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:21 -04:00
Urs Fässler	328499bcb4	iio: ad5686: fix optional reference voltage declaration commit `da019f59cb` upstream. When not using the "_optional" function, a dummy regulator is returned and the driver fails to initialize. Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:21 -04:00
Kristina Martšenko	30fa0dbf67	iio: mxs-lradc: only update the buffer when its conversions have finished commit `89bb35e200` upstream. Using the touchscreen while running buffered capture results in the buffer reporting lots of wrong values, often just zeros. This is because we push readings to the buffer every time a touchscreen interrupt arrives, including when the buffer's own conversions have not yet finished. So let's only push to the buffer when its conversions are ready. Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Kristina Martšenko	9f074c6a2d	iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions commit `6abe0300a1` upstream. Reading a channel through sysfs, or starting a buffered capture, can occasionally turn off the touchscreen. This is because the read_raw() and buffer preenable()/postdisable() callbacks unschedule current conversions on all channels. If a delay channel happens to schedule a touchscreen conversion at the same time, the conversion gets cancelled and the touchscreen sequence stops. This is probably related to this note from the reference manual: "If a delay group schedules channels to be sampled and a manual write to the schedule field in CTRL0 occurs while the block is discarding samples, the LRADC will switch to the new schedule and will not sample the channels that were previously scheduled. The time window for this to happen is very small and lasts only while the LRADC is discarding samples." So make the callbacks only unschedule conversions for the channels they use. This means channel 0 for read_raw() and channels 0-5 for the buffer (if the touchscreen is enabled). Since the touchscreen uses different channels (6 and 7), it no longer gets turned off. This is tested and fixes the issue on i.MX28, but hasn't been tested on i.MX23. Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Kristina Martšenko	1322dc3bad	iio: mxs-lradc: make ADC reads not disable touchscreen interrupts commit `86bf7f3ef7` upstream. Reading a channel through sysfs, or starting a buffered capture, will currently turn off the touchscreen. This is because the read_raw() and buffer preenable()/postdisable() callbacks disable interrupts for all LRADC channels, including those the touchscreen uses. So make the callbacks only disable interrupts for the channels they use. This means channel 0 for read_raw() and channels 0-5 for the buffer (if the touchscreen is enabled). Since the touchscreen uses different channels (6 and 7), it no longer gets turned off. Note that only i.MX28 is affected by this issue, i.MX23 should be fine. Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Kristina Martšenko	567a6d5e27	iio: mxs-lradc: separate touchscreen and buffer virtual channels commit `f81197b8a3` upstream. The touchscreen was initially designed [1] to map all of its physical channels to one virtual channel, leaving buffered capture to use the remaining 7 virtual channels. When the touchscreen was reimplemented [2], it was made to use four virtual channels, which overlap and conflict with the channels the buffer uses. As a result, when the buffer is enabled, the touchscreen's virtual channels are remapped to whichever physical channels the buffer was configured with, causing the touchscreen to read those instead of the touch measurement channels. Effectively the touchscreen stops working. So here we separate the channels again, giving the touchscreen 2 virtual channels and the buffer 6. We can't give the touchscreen just 1 channel as before, as the current pressure calculation requires 2 channels to be read at the same time. This makes the touchscreen continue to work during buffered capture. It has been tested on i.MX28, but not on i.MX23. [1] `06ddd353f5` ("iio: mxs: Implement support for touchscreen") [2] `dee05308f6` ("Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection") Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Rasmus Villemoes	c0d65db7de	iio: imu: adis16400: Fix sign extension commit `19e353f2b3` upstream. The intention is obviously to sign-extend a 12 bit quantity. But because of C's promotion rules, the assignment is equivalent to "val16 &= 0xfff;". Use the proper API for this. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Stefan Wahren	ec23c856a5	iio: mxs-lradc: fix iio channel map regression commit `03305e535c` upstream. Since commit `c8231a9af8` ("iio: mxs-lradc: compute temperature from channel 8 and 9") with the removal of adc channel 9 there is no 1-1 mapping in the channel spec. All hwmon channel values above 9 are accessible via there index minus one. So add a hidden iio channel 9 to fix this issue. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:20 -04:00
Quentin Casasnovas	6ddd115f4c	x86/fpu/xsaves: Fix improper uses of __ex_table commit `06c8173eb9` upstream. Commit: `f31a9f7c71` ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") introduced alternative instructions for XSAVES/XRSTORS and commit: `adb9d526e9` ("x86/xsaves: Add xsaves and xrstors support for booting time") added support for the XSAVES/XRSTORS instructions at boot time. Unfortunately both failed to properly protect them against faulting: The 'xstate_fault' macro will use the closest label named '1' backward and that ends up in the .altinstr_replacement section rather than in .text. This means that the kernel will never find in the __ex_table the .text address where this instruction might fault, leading to serious problems if userspace manages to trigger the fault. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> Signed-off-by: Jamie Iles <jamie.iles@oracle.com> [ Improved the changelog, fixed some whitespace noise. ] Acked-by: Borislav Petkov <bp@alien8.de> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Allan Xavier <mr.a.xavier@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: `adb9d526e9` ("x86/xsaves: Add xsaves and xrstors support for booting time") Fixes: `f31a9f7c71` ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:19 -04:00
Andy Lutomirski	ce5dd33cbf	x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization commit `956421fbb7` upstream. 'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and the related state make sense for 'ret_from_sys_call'. This is entirely the wrong check. TS_COMPAT would make a little more sense, but there's really no point in keeping this optimization at all. This fixes a return to the wrong user CS if we came from int 0x80 in a 64-bit task. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net [ Backported from tip:x86/asm. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:19 -04:00
Nicholas Bellinger	cdc937a511	target: Check for LBA + sectors wrap-around in sbc_parse_cdb commit `aa179935ed` upstream. This patch adds a check to sbc_parse_cdb() in order to detect when an LBA + sector vs. end-of-device calculation wraps when the LBA is sufficently large enough (eg: 0xFFFFFFFFFFFFFFFF). Cc: Martin Petersen <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:19 -04:00
Nicholas Bellinger	f38a130bff	target: Add missing WRITE_SAME end-of-device sanity check commit `8e575c50a1` upstream. This patch adds a check to sbc_setup_write_same() to verify the incoming WRITE_SAME LBA + number of blocks does not exceed past the end-of-device. Also check for potential LBA wrap-around as well. Reported-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Martin Petersen <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:19 -04:00
Nicholas Bellinger	aff40baf1d	target: Fix PR_APTPL_BUF_LEN buffer size limitation commit `f161d4b44d` upstream. This patch addresses the original PR_APTPL_BUF_LEN = 8k limitiation for write-out of PR APTPL metadata that Martin has recently been running into. It changes core_scsi3_update_and_write_aptpl() to use vzalloc'ed memory instead of kzalloc, and increases the default hardcoded length to 256k. It also adds logic in core_scsi3_update_and_write_aptpl() to double the original length upon core_scsi3_update_aptpl_buf() failure, and retries until the vzalloc'ed buffer is large enough to accommodate the outgoing APTPL metadata. Reported-by: Martin Svec <martin.svec@zoner.cz> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:18 -04:00
Shobhit Kumar	e12d499e9a	drm/i915: Correct the IOSF Dev_FN field for IOSF transfers commit `d180d2bbb6` upstream. As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target device and not the source. So PCI_DEVFN(2,0) is not correct. Further the port ID should be enough to identify devices unless they are MFD. The SB_DevFn was intended to remove ambiguity in case of these MFD devices. For non MFD devices the recommendation for the target device IP was to ignore these fields, but not all of them followed the recommendation. Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0). It turned out that this did not follow the recommendation and expected 0 in this field. In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for all devices except target PCI devices. Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:18 -04:00
Michał Winiarski	5c8bf2b80c	drm/i915: Prevent use-after-free in invalidate_range_start callback commit `460822b0b1` upstream. It's possible for invalidate_range_start mmu notifier callback to race against userptr object release. If the gem object was released prior to obtaining the spinlock in invalidate_range_start we're hitting null pointer dereference. Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [Jani: added code comment suggested by Chris] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:18 -04:00
Daniel Vetter	4182c01b25	drm/i915: Drop vblank wait from intel_dp_link_down commit `0ca0968554` upstream. Nothing in Bspec seems to indicate that we actually needs this, and it looks like can't work since by this point the pipe is off and so vblanks won't really happen any more. Note that Bspec mentions that it takes a vblank for this bit to change, but _only_ when enabling. Dropping this code quenches an annoying backtrace introduced by the more anal checking since commit `51e31d49c8` Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait Note: This fixes the fallout from the above commit, but does not address the shortcomings of the IBX transcoder select workaround implementation discussed during review [1]. [1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:18 -04:00
Chris Wilson	2de5e09aaf	drm/i915: Insert a command barrier on BLT/BSD cache flushes commit `f0a1fb10e5` upstream. This looked like an odd regression from commit `ec5cc0f9b0` Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 12 10:28:55 2014 +0100 drm/i915: Restrict GPU boost to the RCS engine but in reality it undercovered a much older coherency bug. The issue that boosting the GPU frequency on the BCS ring was masking was that we could wake the CPU up after completion of a BCS batch and inspect memory prior to the write cache being fully evicted. In order to serialise the breadcrumb interrupt (and so ensure that the CPU's view of memory is coherent) we need to perform a post-sync operation in the MI_FLUSH_DW. v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists). Also fix the invalidate_domains mask in gen8_emit_flush() for ring != VCS. Testcase: gpuX-rcs-gpu-read-after-write Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:18 -04:00
Alex Deucher	93fd529dd1	drm/radeon: fix voltage setup on hawaii commit `09b6e85fc8` upstream. Missing parameter when fetching the real voltage values from atom. Fixes problems with dynamic clocking on certain boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87457 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:17 -04:00
Alex Deucher	c112fd1487	drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary commit `66c2b84ba6` upstream. Don't restrict it to just eDP panels. Some LVDS bridge chips require this. Fixes blank panels on resume on certain laptops. Noticed by mrnuke on IRC. bug: https://bugs.freedesktop.org/show_bug.cgi?id=42960 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:17 -04:00
Christian König	5b7776747b	drm/radeon: workaround for CP HW bug on CIK commit `a9c73a0e02` upstream. Emit the EOP twice to avoid cache flushing problems. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:17 -04:00
Alex Deucher	fee477d50f	drm/radeon: only enable kv/kb dpm interrupts once v3 commit `410af8d728` upstream. Enable at init and disable on fini. Workaround for hardware problems. v2 (chk): extend commit message v3: add new function Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> (v2) Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:17 -04:00
Michel Dänzer	22d4d7e796	drm/radeon: Don't try to enable write-combining without PAT commit `a53fa43873` upstream. Doing so can cause things to become slow. Print a warning at compile time and an informative message at runtime in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:17 -04:00
David Ung	c5131a9810	drm/tegra: Use correct relocation target offsets commit `31f40f8652` upstream. When copying a relocation from userspace, copy the correct target offset. Signed-off-by: David Ung <davidu@nvidia.com> Fixes: `961e3beae3` ("drm/tegra: Make job submission 64-bit safe") [treding@nvidia.com: provide a better commit message] Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Hugh Dickins	b7c386cf63	mm: fix negative nr_isolated counts commit `ff59909a07` upstream. The vmstat interfaces are good at hiding negative counts (at least when CONFIG_SMP); but if you peer behind the curtain, you find that nr_isolated_anon and nr_isolated_file soon go negative, and grow ever more negative: so they can absorb larger and larger numbers of isolated pages, yet still appear to be zero. I'm happy to avoid a congestion_wait() when too_many_isolated() myself; but I guess it's there for a good reason, in which case we ought to get too_many_isolated() working again. The imbalance comes from isolate_migratepages()'s ISOLATE_ABORT case: putback_movable_pages() decrements the NR_ISOLATED counts, but we forgot to call acct_isolated() to increment them. It is possible that the bug whcih this patch fixes could cause OOM kills when the system still has a lot of reclaimable page cache. Fixes: `edc2ca6124` ("mm, compaction: move pageblock checks up from isolate_migratepages_range()") Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Grazvydas Ignotas	463fb5a2cc	mm/memory.c: actually remap enough memory commit `9cb12d7b4c` upstream. For whatever reason, generic_access_phys() only remaps one page, but actually allows to access arbitrary size. It's quite easy to trigger large reads, like printing out large structure with gdb, which leads to a crash. Fix it by remapping correct size. Fixes: `28b2ee20c7` ("access_process_vm device memory infrastructure") Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Joonsoo Kim	42af81da88	mm/compaction: fix wrong order check in compact_finished() commit `372549c2a3` upstream. What we want to check here is whether there is highorder freepage in buddy list of other migratetype in order to steal it without fragmentation. But, current code just checks cc->order which means allocation request order. So, this is wrong. Without this fix, non-movable synchronous compaction below pageblock order would not stopped until compaction is complete, because migratetype of most pageblocks are movable and high order freepage made by compaction is usually on movable type buddy list. There is some report related to this bug. See below link. http://www.spinics.net/lists/linux-mm/msg81666.html Although the issued system still has load spike comes from compaction, this makes that system completely stable and responsive according to his report. stress-highalloc test in mmtests with non movable order 7 allocation doesn't show any notable difference in allocation success rate, but, it shows more compaction success rate. Compaction success rate (Compaction success * 100 / Compaction stalls, %) 18.47 : 28.94 Fixes: `1fb3f8ca0e` ("mm: compaction: capture a suitable high-order page immediately when it is made available") Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: David Rientjes <rientjes@google.com> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Roman Gushchin	f0f7d8f665	mm/nommu.c: fix arithmetic overflow in __vm_enough_memory() commit `8138a67a55` upstream. I noticed that "allowed" can easily overflow by falling below 0, because (total_vm / 32) can be larger than "allowed". The problem occurs in OVERCOMMIT_NONE mode. In this case, a huge allocation can success and overcommit the system (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall (system-wide), so system become unusable. The problem was masked out by commit `c9b1d0981f` ("mm: limit growth of 3% hardcoded other user reserve"), but it's easy to reproduce it on older kernels: 1) set overcommit_memory sysctl to 2 2) mmap() large file multiple times (with VM_SHARED flag) 3) try to malloc() large amount of memory It also can be reproduced on newer kernels, but miss-configured sysctl_user_reserve_kbytes is required. Fix this issue by switching to signed arithmetic here. Signed-off-by: Roman Gushchin <klamm@yandex-team.ru> Cc: Andrew Shewmaker <agshew@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Roman Gushchin	64ac32052a	mm/mmap.c: fix arithmetic overflow in __vm_enough_memory() commit `5703b087dc` upstream. I noticed, that "allowed" can easily overflow by falling below 0, because (total_vm / 32) can be larger than "allowed". The problem occurs in OVERCOMMIT_NONE mode. In this case, a huge allocation can success and overcommit the system (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall (system-wide), so system become unusable. The problem was masked out by commit `c9b1d0981f` ("mm: limit growth of 3% hardcoded other user reserve"), but it's easy to reproduce it on older kernels: 1) set overcommit_memory sysctl to 2 2) mmap() large file multiple times (with VM_SHARED flag) 3) try to malloc() large amount of memory It also can be reproduced on newer kernels, but miss-configured sysctl_user_reserve_kbytes is required. Fix this issue by switching to signed arithmetic here. [akpm@linux-foundation.org: use min_t] Signed-off-by: Roman Gushchin <klamm@yandex-team.ru> Cc: Andrew Shewmaker <agshew@gmail.com> Cc: Rik van Riel <riel@redhat.com> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Reviewed-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:16 -04:00
Vlastimil Babka	8473518c07	mm: when stealing freepages, also take pages created by splitting buddy page commit `99592d598e` upstream. When studying page stealing, I noticed some weird looking decisions in try_to_steal_freepages(). The first I assume is a bug (Patch 1), the following two patches were driven by evaluation. Testing was done with stress-highalloc of mmtests, using the mm_page_alloc_extfrag tracepoint and postprocessing to get counts of how often page stealing occurs for individual migratetypes, and what migratetypes are used for fallbacks. Arguably, the worst case of page stealing is when UNMOVABLE allocation steals from MOVABLE pageblock. RECLAIMABLE allocation stealing from MOVABLE allocation is also not ideal, so the goal is to minimize these two cases. The evaluation of v2 wasn't always clear win and Joonsoo questioned the results. Here I used different baseline which includes RFC compaction improvements from [1]. I found that the compaction improvements reduce variability of stress-highalloc, so there's less noise in the data. First, let's look at stress-highalloc configured to do sync compaction, and how these patches reduce page stealing events during the test. First column is after fresh reboot, other two are reiterations of test without reboot. That was all accumulater over 5 re-iterations (so the benchmark was run 5x3 times with 5 fresh restarts). Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-nothp-1 5-nothp-2 5-nothp-3 Page alloc extfrag event 10264225 8702233 10244125 Extfrag fragmenting 10263271 8701552 10243473 Extfrag fragmenting for unmovable 13595 17616 15960 Extfrag fragmenting unmovable placed with movable 7989 12193 8447 Extfrag fragmenting for reclaimable 658 1840 1817 Extfrag fragmenting reclaimable placed with movable 558 1677 1679 Extfrag fragmenting for movable 10249018 8682096 10225696 With Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-nothp-1 6-nothp-2 6-nothp-3 Page alloc extfrag event 11834954 9877523 9774860 Extfrag fragmenting 11833993 9876880 9774245 Extfrag fragmenting for unmovable 7342 16129 11712 Extfrag fragmenting unmovable placed with movable 4191 10547 6270 Extfrag fragmenting for reclaimable 373 1130 923 Extfrag fragmenting reclaimable placed with movable 302 906 738 Extfrag fragmenting for movable 11826278 9859621 9761610 With Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-nothp-1 7-nothp-2 7-nothp-3 Page alloc extfrag event 4725990 3668793 3807436 Extfrag fragmenting 4725104 3668252 3806898 Extfrag fragmenting for unmovable 6678 7974 7281 Extfrag fragmenting unmovable placed with movable 2051 3829 4017 Extfrag fragmenting for reclaimable 429 1208 1278 Extfrag fragmenting reclaimable placed with movable 369 976 1034 Extfrag fragmenting for movable 4717997 3659070 3798339 With Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-nothp-1 8-nothp-2 8-nothp-3 Page alloc extfrag event 5016183 4700142 3850633 Extfrag fragmenting 5015325 4699613 3850072 Extfrag fragmenting for unmovable 1312 3154 3088 Extfrag fragmenting unmovable placed with movable 1115 2777 2714 Extfrag fragmenting for reclaimable 437 1193 1097 Extfrag fragmenting reclaimable placed with movable 330 969 879 Extfrag fragmenting for movable 5013576 4695266 3845887 In v2 we've seen apparent regression with Patch 1 for unmovable events, this is now gone, suggesting it was indeed noise. Here, each patch improves the situation for unmovable events. Reclaimable is improved by patch 1 and then either the same modulo noise, or perhaps sligtly worse - a small price for unmovable improvements, IMHO. The number of movable allocations falling back to other migratetypes is most noisy, but it's reduced to half at Patch 2 nevertheless. These are least critical as compaction can move them around. If we look at success rates, the patches don't affect them, that didn't change. Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-nothp-1 5-nothp-2 5-nothp-3 Success 1 Min 49.00 ( 0.00%) 42.00 ( 14.29%) 41.00 ( 16.33%) Success 1 Mean 51.00 ( 0.00%) 45.00 ( 11.76%) 42.60 ( 16.47%) Success 1 Max 55.00 ( 0.00%) 51.00 ( 7.27%) 46.00 ( 16.36%) Success 2 Min 53.00 ( 0.00%) 47.00 ( 11.32%) 44.00 ( 16.98%) Success 2 Mean 59.60 ( 0.00%) 50.80 ( 14.77%) 48.20 ( 19.13%) Success 2 Max 64.00 ( 0.00%) 56.00 ( 12.50%) 52.00 ( 18.75%) Success 3 Min 84.00 ( 0.00%) 82.00 ( 2.38%) 78.00 ( 7.14%) Success 3 Mean 85.60 ( 0.00%) 82.80 ( 3.27%) 79.40 ( 7.24%) Success 3 Max 86.00 ( 0.00%) 83.00 ( 3.49%) 80.00 ( 6.98%) Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-nothp-1 6-nothp-2 6-nothp-3 Success 1 Min 49.00 ( 0.00%) 44.00 ( 10.20%) 44.00 ( 10.20%) Success 1 Mean 51.80 ( 0.00%) 46.00 ( 11.20%) 45.80 ( 11.58%) Success 1 Max 54.00 ( 0.00%) 49.00 ( 9.26%) 49.00 ( 9.26%) Success 2 Min 58.00 ( 0.00%) 49.00 ( 15.52%) 48.00 ( 17.24%) Success 2 Mean 60.40 ( 0.00%) 51.80 ( 14.24%) 50.80 ( 15.89%) Success 2 Max 63.00 ( 0.00%) 54.00 ( 14.29%) 55.00 ( 12.70%) Success 3 Min 84.00 ( 0.00%) 81.00 ( 3.57%) 79.00 ( 5.95%) Success 3 Mean 85.00 ( 0.00%) 81.60 ( 4.00%) 79.80 ( 6.12%) Success 3 Max 86.00 ( 0.00%) 82.00 ( 4.65%) 82.00 ( 4.65%) Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-nothp-1 7-nothp-2 7-nothp-3 Success 1 Min 50.00 ( 0.00%) 44.00 ( 12.00%) 39.00 ( 22.00%) Success 1 Mean 52.80 ( 0.00%) 45.60 ( 13.64%) 42.40 ( 19.70%) Success 1 Max 55.00 ( 0.00%) 46.00 ( 16.36%) 47.00 ( 14.55%) Success 2 Min 52.00 ( 0.00%) 48.00 ( 7.69%) 45.00 ( 13.46%) Success 2 Mean 53.40 ( 0.00%) 49.80 ( 6.74%) 48.80 ( 8.61%) Success 2 Max 57.00 ( 0.00%) 52.00 ( 8.77%) 52.00 ( 8.77%) Success 3 Min 84.00 ( 0.00%) 81.00 ( 3.57%) 79.00 ( 5.95%) Success 3 Mean 85.00 ( 0.00%) 82.40 ( 3.06%) 79.60 ( 6.35%) Success 3 Max 86.00 ( 0.00%) 83.00 ( 3.49%) 80.00 ( 6.98%) Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-nothp-1 8-nothp-2 8-nothp-3 Success 1 Min 46.00 ( 0.00%) 44.00 ( 4.35%) 42.00 ( 8.70%) Success 1 Mean 50.20 ( 0.00%) 45.60 ( 9.16%) 44.00 ( 12.35%) Success 1 Max 52.00 ( 0.00%) 47.00 ( 9.62%) 47.00 ( 9.62%) Success 2 Min 53.00 ( 0.00%) 49.00 ( 7.55%) 48.00 ( 9.43%) Success 2 Mean 55.80 ( 0.00%) 50.60 ( 9.32%) 49.00 ( 12.19%) Success 2 Max 59.00 ( 0.00%) 52.00 ( 11.86%) 51.00 ( 13.56%) Success 3 Min 84.00 ( 0.00%) 80.00 ( 4.76%) 79.00 ( 5.95%) Success 3 Mean 85.40 ( 0.00%) 81.60 ( 4.45%) 80.40 ( 5.85%) Success 3 Max 87.00 ( 0.00%) 83.00 ( 4.60%) 82.00 ( 5.75%) While there's no improvement here, I consider reduced fragmentation events to be worth on its own. Patch 2 also seems to reduce scanning for free pages, and migrations in compaction, suggesting it has somewhat less work to do: Patch 1: Compaction stalls 4153 3959 3978 Compaction success 1523 1441 1446 Compaction failures 2630 2517 2531 Page migrate success 4600827 4943120 5104348 Page migrate failure 19763 16656 17806 Compaction pages isolated 9597640 10305617 `10653541` Compaction migrate scanned 77828948 86533283 87137064 Compaction free scanned 517758295 521312840 521462251 Compaction cost 5503 5932 6110 Patch 2: Compaction stalls 3800 3450 3518 Compaction success 1421 1316 1317 Compaction failures 2379 2134 2201 Page migrate success `4160421` 4502708 4752148 Page migrate failure 19705 14340 14911 Compaction pages isolated 8731983 9382374 9910043 Compaction migrate scanned 98362797 96349194 98609686 Compaction free scanned 496512560 469502017 480442545 Compaction cost 5173 5526 5811 As with v2, /proc/pagetypeinfo appears unaffected with respect to numbers of unmovable and reclaimable pageblocks. Configuring the benchmark to allocate like THP page fault (i.e. no sync compaction) gives much noisier results for iterations 2 and 3 after reboot. This is not so surprising given how [1] offers lower improvements in this scenario due to less restarts after deferred compaction which would change compaction pivot. Baseline: 3.19-rc4 3.19-rc4 3.19-rc4 5-thp-1 5-thp-2 5-thp-3 Page alloc extfrag event 8148965 6227815 6646741 Extfrag fragmenting 8147872 6227130 6646117 Extfrag fragmenting for unmovable 10324 12942 15975 Extfrag fragmenting unmovable placed with movable 5972 8495 10907 Extfrag fragmenting for reclaimable 601 1707 2210 Extfrag fragmenting reclaimable placed with movable 520 1570 2000 Extfrag fragmenting for movable 8136947 6212481 6627932 Patch 1: 3.19-rc4 3.19-rc4 3.19-rc4 6-thp-1 6-thp-2 6-thp-3 Page alloc extfrag event 8345457 7574471 7020419 Extfrag fragmenting 8343546 7573777 7019718 Extfrag fragmenting for unmovable 10256 18535 30716 Extfrag fragmenting unmovable placed with movable 6893 11726 22181 Extfrag fragmenting for reclaimable 465 1208 1023 Extfrag fragmenting reclaimable placed with movable 353 996 843 Extfrag fragmenting for movable 8332825 7554034 6987979 Patch 2: 3.19-rc4 3.19-rc4 3.19-rc4 7-thp-1 7-thp-2 7-thp-3 Page alloc extfrag event 3512847 3020756 2891625 Extfrag fragmenting 3511940 3020185 2891059 Extfrag fragmenting for unmovable 9017 6892 6191 Extfrag fragmenting unmovable placed with movable 1524 3053 2435 Extfrag fragmenting for reclaimable 445 1081 1160 Extfrag fragmenting reclaimable placed with movable 375 918 986 Extfrag fragmenting for movable `3502478` 3012212 2883708 Patch 3: 3.19-rc4 3.19-rc4 3.19-rc4 8-thp-1 8-thp-2 8-thp-3 Page alloc extfrag event 3181699 `3082881` 2674164 Extfrag fragmenting 3180812 3082303 2673611 Extfrag fragmenting for unmovable 1201 4031 4040 Extfrag fragmenting unmovable placed with movable 974 3611 3645 Extfrag fragmenting for reclaimable 478 1165 1294 Extfrag fragmenting reclaimable placed with movable 387 985 1030 Extfrag fragmenting for movable 3179133 3077107 2668277 The improvements for first iteration are clear, the rest is much noisier and can appear like regression for Patch 1. Anyway, patch 2 rectifies it. Allocation success rates are again unaffected so there's no point in making this e-mail any longer. [1] http://marc.info/?l=linux-mm&m=142166196321125&w=2 This patch (of 3): When __rmqueue_fallback() is called to allocate a page of order X, it will find a page of order Y >= X of a fallback migratetype, which is different from the desired migratetype. With the help of try_to_steal_freepages(), it may change the migratetype (to the desired one) also of: 1) all currently free pages in the pageblock containing the fallback page 2) the fallback pageblock itself 3) buddy pages created by splitting the fallback page (when Y > X) These decisions take the order Y into account, as well as the desired migratetype, with the goal of preventing multiple fallback allocations that could e.g. distribute UNMOVABLE allocations among multiple pageblocks. Originally, decision for 1) has implied the decision for 3). Commit `47118af076` ("mm: mmzone: MIGRATE_CMA migration type added") changed that (probably unintentionally) so that the buddy pages in case 3) are always changed to the desired migratetype, except for CMA pageblocks. Commit `fef903efcf` ("mm/page_allo.c: restructure free-page stealing code and fix a bug") did some refactoring and added a comment that the case of 3) is intended. Commit `0cbef29a78` ("mm: __rmqueue_fallback() should respect pageblock type") removed the comment and tried to restore the original behavior where 1) implies 3), but due to the previous refactoring, the result is instead that only 2) implies 3) - and the conditions for 2) are less frequently met than conditions for 1). This may increase fragmentation in situations where the code decides to steal all free pages from the pageblock (case 1)), but then gives back the buddy pages produced by splitting. This patch restores the original intended logic where 1) implies 3). During testing with stress-highalloc from mmtests, this has shown to decrease the number of events where UNMOVABLE and RECLAIMABLE allocations steal from MOVABLE pageblocks, which can lead to permanent fragmentation. In some cases it has increased the number of events when MOVABLE allocations steal from UNMOVABLE or RECLAIMABLE pageblocks, but these are fixable by sync compaction and thus less harmful. Note that evaluation has shown that the behavior introduced by `47118af076` for buddy pages in case 3) is actually even better than the original logic, so the following patch will introduce it properly once again. For stable backports of this patch it makes thus sense to only fix versions containing `0cbef29a78`. [iamjoonsoo.kim@lge.com: tracepoint fix] Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Mel Gorman <mgorman@suse.de> Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: Minchan Kim <minchan@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:15 -04:00
Andrey Ryabinin	6f59e64868	mm, hugetlb: remove unnecessary lower bound on sysctl handlers"? commit `3cd7645de6` upstream. Commit `ed4d4902eb` ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity") replaced 'unsigned long hugetlb_zero' with 'int zero' leading to out-of-bounds access in proc_doulongvec_minmax(). Use '.extra1 = NULL' instead of '.extra1 = &zero'. Passing NULL is equivalent to passing minimal value, which is 0 for unsigned types. Fixes: `ed4d4902eb` ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity") Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Suggested-by: Manfred Spraul <manfred@colorfullife.com> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:15 -04:00
Naoya Horiguchi	ac369918c6	mm/hugetlb: add migration entry check in __unmap_hugepage_range commit `9fbc1f635f` upstream. If __unmap_hugepage_range() tries to unmap the address range over which hugepage migration is on the way, we get the wrong page because pte_page() doesn't work for migration entries. This patch simply clears the pte for migration entries as we do for hwpoison entries. Fixes: `290408d4a2` ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Rientjes <rientjes@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:15 -04:00
Naoya Horiguchi	fa94a39637	mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection commit `a8bda28d87` upstream. There is a race condition between hugepage migration and change_protection(), where hugetlb_change_protection() doesn't care about migration entries and wrongly overwrites them. That causes unexpected results like kernel crash. HWPoison entries also can cause the same problem. This patch adds is_hugetlb_entry_(migration\|hwpoisoned) check in this function to do proper actions. Fixes: `290408d4a2` ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Rientjes <rientjes@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:15 -04:00
Naoya Horiguchi	674eefded6	mm/hugetlb: fix getting refcount 0 page in hugetlb_fault() commit `0f792cf949` upstream. When running the test which causes the race as shown in the previous patch, we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault(). This race happens when pte turns into migration entry just after the first check of is_hugetlb_entry_migration() in hugetlb_fault() passed with false. To fix this, we need to check pte_present() again after huge_ptep_get(). This patch also reorders taking ptl and doing pte_page(), because pte_page() should be done in ptl. Due to this reordering, we need use trylock_page() in page != pagecache_page case to respect locking order. Fixes: `66aebce747` ("hugetlb: fix race condition in hugetlb_fault()") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Rientjes <rientjes@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:14 -04:00
Jiri Pirko	c3b2b0df73	team: don't traverse port list using rcu in team_set_mac_address [ Upstream commit `9215f437b8` ] Currently the list is traversed using rcu variant. That is not correct since dev_set_mac_address can be called which eventually calls rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this by remove the rcu usage here. Fixes: `3d249d4ca7` "net: introduce ethernet teaming device" Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:14 -04:00
Lorenzo Colitti	f009d6b5eb	net: ping: Return EAFNOSUPPORT when appropriate. [ Upstream commit `9145736d48` ] 1. For an IPv4 ping socket, ping_check_bind_addr does not check the family of the socket address that's passed in. Instead, make it behave like inet_bind, which enforces either that the address family is AF_INET, or that the family is AF_UNSPEC and the address is 0.0.0.0. 2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL if the socket family is not AF_INET6. Return EAFNOSUPPORT instead, for consistency with inet6_bind. 3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT instead of EINVAL if an incorrect socket address structure is passed in. 4. Make IPv6 ping sockets be IPv6-only. The code does not support IPv4, and it cannot easily be made to support IPv4 because the protocol numbers for ICMP and ICMPv6 are different. This makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead of making the socket unusable. Among other things, this fixes an oops that can be triggered by: int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP); struct sockaddr_in6 sin6 = { .sin6_family = AF_INET6, .sin6_addr = in6addr_any, }; bind(s, (struct sockaddr *) &sin6, sizeof(sin6)); Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241 Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:14 -04:00
Michal Kubeček	1b5d485e7e	udp: only allow UFO for packets from SOCK_DGRAM sockets [ Upstream commit `acf8dd0a9d` ] If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer checksum is to be computed on segmentation. However, in this case, skb->csum_start and skb->csum_offset are never set as raw socket transmit path bypasses udp_send_skb() where they are usually set. As a result, driver may access invalid memory when trying to calculate the checksum and store the result (as observed in virtio_net driver). Moreover, the very idea of modifying the userspace provided UDP header is IMHO against raw socket semantics (I wasn't able to find a document clearly stating this or the opposite, though). And while allowing CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit too intrusive change just to handle a corner case like this. Therefore disallowing UFO for packets from SOCK_DGRAM seems to be the best option. Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:14 -04:00
Ben Shelton	af5b76c9f3	usb: plusb: Add support for National Instruments host-to-host cable [ Upstream commit `42c972a1f3` ] The National Instruments USB Host-to-Host Cable is based on the Prolific PL-25A1 chipset. Add its VID/PID so the plusb driver will recognize it. Signed-off-by: Ben Shelton <ben.shelton@ni.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:14 -04:00
Eric Dumazet	0972883e7e	net: do not use rcu in rtnl_dump_ifinfo() [ Upstream commit `cac5e65e8a` ] We did a failed attempt in the past to only use rcu in rtnl dump operations (commit `e67f88dd12` "net: dont hold rtnl mutex during netlink dump callbacks") Now that dumps are holding RTNL anyway, there is no need to also use rcu locking, as it forbids any scheduling ability, like GFP_KERNEL allocations that controlling path should use instead of GFP_ATOMIC whenever possible. This should fix following splat Cong Wang reported : [ INFO: suspicious RCU usage. ] 3.19.0+ #805 Tainted: G W include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by ip/771: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8182b8f4>] netlink_dump+0x21/0x26c #1: (rcu_read_lock){......}, at: [<ffffffff817d785b>] rcu_read_lock+0x0/0x6e stack backtrace: CPU: 3 PID: 771 Comm: ip Tainted: G W 3.19.0+ #805 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6 ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd 00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758 Call Trace: [<ffffffff81a27457>] dump_stack+0x4c/0x65 [<ffffffff810b539b>] lockdep_rcu_suspicious+0x107/0x110 [<ffffffff8109796f>] rcu_preempt_sleep_check+0x45/0x47 [<ffffffff8109e457>] ___might_sleep+0x1d/0x1cb [<ffffffff8109e67d>] __might_sleep+0x78/0x80 [<ffffffff814b9b1f>] idr_alloc+0x45/0xd1 [<ffffffff810cb7ab>] ? rcu_read_lock_held+0x3b/0x3d [<ffffffff814b9f9d>] ? idr_for_each+0x53/0x101 [<ffffffff817c1383>] alloc_netid+0x61/0x69 [<ffffffff817c14c3>] __peernet2id+0x79/0x8d [<ffffffff817c1ab7>] peernet2id+0x13/0x1f [<ffffffff817d8673>] rtnl_fill_ifinfo+0xa8d/0xc20 [<ffffffff810b17d9>] ? __lock_is_held+0x39/0x52 [<ffffffff817d894f>] rtnl_dump_ifinfo+0x149/0x213 [<ffffffff8182b9c2>] netlink_dump+0xef/0x26c [<ffffffff8182bcba>] netlink_recvmsg+0x17b/0x2c5 [<ffffffff817b0adc>] __sock_recvmsg+0x4e/0x59 [<ffffffff817b1b40>] sock_recvmsg+0x3f/0x51 [<ffffffff817b1f9a>] ___sys_recvmsg+0xf6/0x1d9 [<ffffffff8115dc67>] ? handle_pte_fault+0x6e1/0xd3d [<ffffffff8100a3a0>] ? native_sched_clock+0x35/0x37 [<ffffffff8109f45b>] ? sched_clock_local+0x12/0x72 [<ffffffff8109f6ac>] ? sched_clock_cpu+0x9e/0xb7 [<ffffffff810cb7ab>] ? rcu_read_lock_held+0x3b/0x3d [<ffffffff811abde8>] ? __fcheck_files+0x4c/0x58 [<ffffffff811ac556>] ? __fget_light+0x2d/0x52 [<ffffffff817b376f>] __sys_recvmsg+0x42/0x60 [<ffffffff817b379f>] SyS_recvmsg+0x12/0x1c Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `0c7aecd4bd` ("netns: add rtnl cmd to add and get peer netns ids") Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reported-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:13 -04:00
Jaedon Shin	29db1c2ae7	net: bcmgenet: fix throughtput regression [ Upstream commit `4092e6acf5` ] This patch adds bcmgenet_tx_poll for the tx_rings. This can reduce the interrupt load and send xmit in network stack on time. This also separated for the completion of tx_ring16 from bcmgenet_poll. The bcmgenet_tx_reclaim of tx_ring[{0,1,2,3}] operative by an interrupt is to be not more than a certain number TxBDs. It is caused by too slowly reclaiming the transmitted skb. Therefore, performance degradation of xmit after `605ad7f` ("tcp: refine TSO autosizing"). Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:13 -04:00
Eric Dumazet	e2aaa2c053	macvtap: make sure neighbour code can push ethernet header [ Upstream commit `2f1d8b9e8a` ] Brian reported crashes using IPv6 traffic with macvtap/veth combo. I tracked the crashes in neigh_hh_output() -> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD); Neighbour code assumes headroom to push Ethernet header is at least 16 bytes. It appears macvtap has only 14 bytes available on arches where NET_IP_ALIGN is 0 (like x86) Effect is a corruption of 2 bytes right before skb->head, and possible crashes if accessing non existing memory. This fix should also increase IPv4 performance, as paranoid code in ip_finish_output2() wont have to call skb_realloc_headroom() Reported-by: Brian Rak <brak@vultr.com> Tested-by: Brian Rak <brak@vultr.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:13 -04:00
Catalin Marinas	7c03ec3e2d	net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send, recv}msg [ Upstream commit `d720d8cec5` ] With commit `a7526eb5d0` (net: Unbreak compat_sys_{send,recv}msg), the MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points, changing the kernel compat behaviour from the one before the commit it was trying to fix (`1be374a051`, net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg). On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native 32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by the kernel). However, on a 64-bit kernel, the compat ABI is different with commit `a7526eb5d0`. This patch changes the compat_sys_{send,recv}msg behaviour to the one prior to commit `1be374a051`. The problem was found running 32-bit LTP (sendmsg01) binary on an arm64 kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg() but the general rule is not to break user ABI (even when the user behaviour is not entirely sane). Fixes: `a7526eb5d0` (net: Unbreak compat_sys_{send,recv}msg) Cc: Andy Lutomirski <luto@amacapital.net> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:13 -04:00
Jiri Pirko	722243f16e	team: fix possible null pointer dereference in team_handle_frame [ Upstream commit `57e5956319` ] Currently following race is possible in team: CPU0 CPU1 team_port_del team_upper_dev_unlink priv_flags &= ~IFF_TEAM_PORT team_handle_frame team_port_get_rcu team_port_exists priv_flags & IFF_TEAM_PORT == 0 return NULL (instead of port got from rx_handler_data) netdev_rx_handler_unregister The thing is that the flag is removed before rx_handler is unregistered. If team_handle_frame is called in between, team_port_exists returns 0 and team_port_get_rcu will return NULL. So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister that team_handle_frame will always see valid rx_handler_data pointer. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Fixes: `3d249d4ca7` ("net: introduce ethernet teaming device") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:13 -04:00
Eric Dumazet	539500104f	net: pktgen: disable xmit_clone on virtual devices [ Upstream commit `52d6c8c6ca` ] Trying to use burst capability (aka xmit_more) on a virtual device like bonding is not supported. For example, skb might be queued multiple times on a qdisc, with various list corruptions. Fixes: `38b2cf2982` ("net: pktgen: packet bursting via skb->xmit_more") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Alexei Starovoitov <ast@plumgrid.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:12 -04:00
David S. Miller	4e7a29f315	Revert "r8169: add support for Byte Queue Limits" This reverts commit `1e91887685`. Revert BQL support in r8169 driver as several regressions point to this commit and we cannot figure out the real cause yet. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:12 -04:00
Matthew Thode	e664c2cc86	net: reject creation of netdev names with colons [ Upstream commit `a4176a9391` ] colons are used as a separator in netdev device lookup in dev_ioctl.c Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME Signed-off-by: Matthew Thode <mthode@mthode.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:12 -04:00
Eric Dumazet	4946f9d297	sock: sock_dequeue_err_skb() needs hard irq safety [ Upstream commit `997d5c3f44` ] Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb() from hard IRQ context. Therefore, sock_dequeue_err_skb() needs to block hard irq or corruptions or hangs can happen. Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `364a9e9324` ("sock: deduplicate errqueue dequeue") Fixes: `cb820f8e4b` ("net: Provide a generic socket error queue delivery method for Tx time stamps.") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:12 -04:00
Pravin B Shelar	91f3fc9b4d	openvswitch: Fix net exit. [ Upstream commit `7b4577a9da` ] Open vSwitch allows moving internal vport to different namespace while still connected to the bridge. But when namespace deleted OVS does not detach these vports, that results in dangling pointer to netdevice which causes kernel panic as follows. This issue is fixed by detaching all ovs ports from the deleted namespace at net-exit. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [<ffffffffa0aadaa5>] ovs_vport_locate+0x35/0x80 [openvswitch] Oops: 0000 [#1] SMP Call Trace: [<ffffffffa0aa6391>] lookup_vport+0x21/0xd0 [openvswitch] [<ffffffffa0aa65f9>] ovs_vport_cmd_get+0x59/0xf0 [openvswitch] [<ffffffff8167e07c>] genl_family_rcv_msg+0x1bc/0x3e0 [<ffffffff8167e319>] genl_rcv_msg+0x79/0xc0 [<ffffffff8167d919>] netlink_rcv_skb+0xb9/0xe0 [<ffffffff8167deac>] genl_rcv+0x2c/0x40 [<ffffffff8167cffd>] netlink_unicast+0x12d/0x1c0 [<ffffffff8167d3da>] netlink_sendmsg+0x34a/0x6b0 [<ffffffff8162e140>] sock_sendmsg+0xa0/0xe0 [<ffffffff8162e5e8>] ___sys_sendmsg+0x408/0x420 [<ffffffff8162f541>] __sys_sendmsg+0x51/0x90 [<ffffffff8162f592>] SyS_sendmsg+0x12/0x20 [<ffffffff81764ee9>] system_call_fastpath+0x12/0x17 Reported-by: Assaf Muller <amuller@redhat.com> Fixes: 46df7b81454("openvswitch: Add support for network namespaces.") Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Reviewed-by: Thomas Graf <tgraf@noironetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:11 -04:00
Ignacy Gawędzki	cbac74b71f	ematch: Fix auto-loading of ematch modules. [ Upstream commit `34eea79e26` ] In tcf_em_validate(), after calling request_module() to load the kind-specific module, set em->ops to NULL before returning -EAGAIN, so that module_put() is not called again by tcf_em_tree_destroy(). Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> Acked-by: Cong Wang <cwang@twopensource.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:11 -04:00
Guenter Roeck	e6aa677fd2	net: phy: Fix verification of EEE support in phy_init_eee [ Upstream commit `54da5a8be3` ] phy_init_eee uses phy_find_setting(phydev->speed, phydev->duplex) to find a valid entry in the settings array for the given speed and duplex value. For full duplex 1000baseT, this will return the first matching entry, which is the entry for 1000baseKX_Full. If the phy eee does not support 1000baseKX_Full, this entry will not match, causing phy_init_eee to fail for no good reason. Fixes: `9a9c56cb34` ("net: phy: fix a bug when verify the EEE support") Fixes: `3e7077067e` ("phy: Expand phy speed/duplex settings array") Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:11 -04:00
Alexander Drozdov	e95afb07dd	ipv4: ip_check_defrag should not assume that skb_network_offset is zero [ Upstream commit `3e32e733d1` ] ip_check_defrag() may be used by af_packet to defragment outgoing packets. skb_network_offset() of af_packet's outgoing packets is not zero. Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:11 -04:00
Alexander Drozdov	913c52e4ef	ipv4: ip_check_defrag should correctly check return value of skb_copy_bits [ Upstream commit `fba04a9e0c` ] skb_copy_bits() returns zero on success and negative value on error, so it is needed to invert the condition in ip_check_defrag(). Fixes: `1bf3751ec9` ("ipv4: ip_check_defrag must not modify skb before unsharing") Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:11 -04:00
Ignacy Gawędzki	aaf410beca	gen_stats.c: Duplicate xstats buffer for later use [ Upstream commit `1c4cff0cf5` ] The gnet_stats_copy_app() function gets called, more often than not, with its second argument a pointer to an automatic variable in the caller's stack. Therefore, to avoid copying garbage afterwards when calling gnet_stats_finish_copy(), this data is better copied to a dynamically allocated memory that gets freed after use. [xiyou.wangcong@gmail.com: remove a useless kfree()] Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:10 -04:00
WANG Cong	8652a96c84	rtnetlink: call ->dellink on failure when ->newlink exists [ Upstream commit `7afb8886a0` ] Ignacy reported that when eth0 is down and add a vlan device on top of it like: ip link add link eth0 name eth0.1 up type vlan id 1 We will get a refcount leak: unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2 The problem is when rtnl_configure_link() fails in rtnl_newlink(), we simply call unregister_device(), but for stacked device like vlan, we almost do nothing when we unregister the upper device, more work is done when we unregister the lower device, so call its ->dellink(). Reported-by: Ignacy Gawedzki <ignacy.gawedzki@green-communications.fr> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:10 -04:00
Martin KaFai Lau	677aa4a278	ipv6: fix ipv6_cow_metrics for non DST_HOST case [ Upstream commit `3b4711757d` ] ipv6_cow_metrics() currently assumes only DST_HOST routes require dynamic metrics allocation from inetpeer. The assumption breaks when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric. Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set() is called after the route is created. This patch creates the metrics array (by calling dst_cow_metrics_generic) in ipv6_cow_metrics(). Test: radvd.conf: interface qemubr0 { AdvLinkMTU 1300; AdvCurHopLimit 30; prefix fd00:face:face:face::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; Before: [root@qemu1 ~]# ip -6 r show \| egrep -v unreachable fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec fe80::/64 dev eth0 proto kernel metric 256 default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec After: [root@qemu1 ~]# ip -6 r show \| egrep -v unreachable fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu 1300 fe80::/64 dev eth0 proto kernel metric 256 mtu 1300 default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec mtu 1300 hoplimit 30 Fixes: `8e2ec63917` (ipv6: don't use inetpeer to store metrics for routes.) Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:10 -04:00
Eric Dumazet	82629d5f11	tcp: make sure skb is not shared before using skb_get() [ Upstream commit `ba34e6d9d3` ] IPv6 can keep a copy of SYN message using skb_get() in tcp_v6_conn_request() so that caller wont free the skb when calling kfree_skb() later. Therefore TCP fast open has to clone the skb it is queuing in child->sk_receive_queue, as all skbs consumed from receive_queue are freed using __kfree_skb() (ie assuming skb->users == 1) Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Fixes: `5b7ed0892f` ("tcp: move fastopen functions to tcp_fastopen.c") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:10 -04:00
Daniel Borkmann	33617dede0	rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY [ Upstream commit `364d5716a7` ] ifla_vf_policy[] is wrong in advertising its individual member types as NLA_BINARY since .type = NLA_BINARY in combination with .len declares the len member as max attribute length [0, len]. The issue is that when do_setvfinfo() is being called to set up a VF through ndo handler, we could set corrupted data if the attribute length is less than the size of the related structure itself. The intent is exactly the opposite, namely to make sure to pass at least data of minimum size of len. Fixes: `ebc08a6f47` ("rtnetlink: Add VF config code to rtnetlink") Cc: Mitch Williams <mitch.a.williams@intel.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:09 -04:00
Sabrina Dubroca	76936e5d2a	pktgen: fix UDP checksum computation [ Upstream commit `7744b5f369` ] This patch fixes two issues in UDP checksum computation in pktgen. First, the pseudo-header uses the source and destination IP addresses. Currently, the ports are used for IPv4. Second, the UDP checksum covers both header and data. So we need to generate the data earlier (move pktgen_finalize_skb up), and compute the checksum for UDP header + data. Fixes: `c26bf4a513` ("pktgen: Add UDPCSUM flag to support UDP checksums") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:09 -04:00
Daniel Borkmann	5cd5724b91	ipv6: addrconf: add missing validate_link_af handler [ Upstream commit `11b1f8288d` ] We still need a validate_link_af() handler with an appropriate nla policy, similarly as we have in IPv4 case, otherwise size validations are not being done properly in that case. Fixes: `f53adae4ea` ("net: ipv6: add tokenized interface identifier support") Fixes: `bc91b0f07a` ("ipv6: addrconf: implement address generation modes") Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:09 -04:00
Miroslav Urbanek	a7dc52c774	flowcache: Fix kernel panic in flow_cache_flush_task [ Upstream commit `233c96fc07` ] flow_cache_flush_task references a structure member flow_cache_gc_work where it should reference flow_cache_flush_task instead. Kernel panic occurs on kernels using IPsec during XFRM garbage collection. The garbage collection interval can be shortened using the following sysctl settings: net.ipv4.xfrm4_gc_thresh=4 net.ipv6.xfrm6_gc_thresh=4 With the default settings, our productions servers crash approximately once a week. With the settings above, they crash immediately. Fixes: `ca925cf153` ("flowcache: Make flow cache name space aware") Reported-by: Tomáš Charvát <tc@excello.cz> Tested-by: Jan Hejl <jh@excello.cz> Signed-off-by: Miroslav Urbanek <mu@miroslavurbanek.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>	2015-03-14 15:37:09 -04:00
Greg Kroah-Hartman	d1034e8379	Linux 3.18.9	2015-03-06 14:53:42 -08:00
Jan Kara	83b7094ac1	quota: Store maximum space limit in bytes commit `b10a08194c` upstream. Currently maximum space limit quota format supports is in blocks however since we store space limits in bytes, this is somewhat confusing. So store the maximum limit in bytes as well. Also rename the field to match the new unit and related inode field to match the new naming scheme. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:06 -08:00
Jiang Liu	1e5c8725fc	x86/irq: Fix regression caused by commit `b568b8601f` commit `1ea76fbadd` upstream. Commit `b568b8601f` ("Treat SCI interrupt as normal GSI interrupt") accidently removes support of legacy PIC interrupt when fixing a regression for Xen, which causes a nasty regression on HP/Compaq nc6000 where we fail to register the ACPI interrupt, and thus lose eg. thermal notifications leading a potentially overheated machine. So reintroduce support of legacy PIC based ACPI SCI interrupt. Reported-by: Ville Syrjälä <syrjala@sci.fi> Tested-by: Ville Syrjälä <syrjala@sci.fi> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Len Brown <len.brown@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Sander Eikelenboom <linux@eikelenboom.it> Cc: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/1424052673-22974-1-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:06 -08:00
Andy Shevchenko	25dd360c3c	x86: pmc-atom: Assign debugfs node as soon as possible commit `1b43d7125f` upstream. pmc_dbgfs_unregister() will be called when pmc->dbgfs_dir is unconditionally NULL on error path in pmc_dbgfs_register(). To prevent this we move the assignment to where is should be. Fixes: `f855911c1f` (x86/pmc_atom: Expose PMC device state and platform sleep state) Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Aubrey Li <aubrey.li@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Kumar P. Mahesh <mahesh.kumar.p@intel.com> Link: http://lkml.kernel.org/r/1421253575-22509-2-git-send-email-andriy.shevchenko@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:06 -08:00
Hector Marco-Gisbert	805f25c4d8	x86, mm/ASLR: Fix stack randomization on 64-bit systems commit `4e7c22d447` upstream. The issue is that the stack for processes is not properly randomized on 64 bit architectures due to an integer overflow. The affected function is randomize_stack_top() in file "fs/binfmt_elf.c": static unsigned long randomize_stack_top(unsigned long stack_top) { unsigned int random_variable = 0; if ((current->flags & PF_RANDOMIZE) && !(current->personality & ADDR_NO_RANDOMIZE)) { random_variable = get_random_int() & STACK_RND_MASK; random_variable <<= PAGE_SHIFT; } return PAGE_ALIGN(stack_top) + random_variable; return PAGE_ALIGN(stack_top) - random_variable; } Note that, it declares the "random_variable" variable as "unsigned int". Since the result of the shifting operation between STACK_RND_MASK (which is 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64): random_variable <<= PAGE_SHIFT; then the two leftmost bits are dropped when storing the result in the "random_variable". This variable shall be at least 34 bits long to hold the (22+12) result. These two dropped bits have an impact on the entropy of process stack. Concretely, the total stack entropy is reduced by four: from 2^28 to 2^30 (One fourth of expected entropy). This patch restores back the entropy by correcting the types involved in the operations in the functions randomize_stack_top() and stack_maxrandom_size(). The successful fix can be tested with: $ for i in `seq 1 10`; do cat /proc/self/maps \| grep stack; done 7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0 [stack] 7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0 [stack] 7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0 [stack] 7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0 [stack] ... Once corrected, the leading bytes should be between 7ffc and 7fff, rather than always being 7fff. Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es> Signed-off-by: Ismael Ripoll <iripoll@upv.es> [ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ] Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: CVE-2015-1593 Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.net Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:06 -08:00
Matt Fleming	55c0226ff0	x86/efi: Avoid triple faults during EFI mixed mode calls commit `96738c69a7` upstream. Andy pointed out that if an NMI or MCE is received while we're in the middle of an EFI mixed mode call a triple fault will occur. This can happen, for example, when issuing an EFI mixed mode call while running perf. The reason for the triple fault is that we execute the mixed mode call in 32-bit mode with paging disabled but with 64-bit kernel IDT handlers installed throughout the call. At Andy's suggestion, stop playing the games we currently do at runtime, such as disabling paging and installing a 32-bit GDT for __KERNEL_CS. We can simply switch to the __KERNEL32_CS descriptor before invoking firmware services, and run in compatibility mode. This way, if an NMI/MCE does occur the kernel IDT handler will execute correctly, since it'll jump to __KERNEL_CS automatically. However, this change is only possible post-ExitBootServices(). Before then the firmware "owns" the machine and expects for its 32-bit IDT handlers to be left intact to service interrupts, etc. So, we now need to distinguish between early boot and runtime invocations of EFI services. During early boot, we need to restore the GDT that the firmware expects to be present. We can only jump to the __KERNEL32_CS code segment for mixed mode calls after ExitBootServices() has been invoked. A liberal sprinkling of comments in the thunking code should make the differences in early and late environments more apparent. Reported-by: Andy Lutomirski <luto@amacapital.net> Tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:06 -08:00
Thadeu Lima de Souza Cascardo	b715907348	blk-throttle: check stats_cpu before reading it from sysfs commit `045c47ca30` upstream. When reading blkio.throttle.io_serviced in a recently created blkio cgroup, it's possible to race against the creation of a throttle policy, which delays the allocation of stats_cpu. Like other functions in the throttle code, just checking for a NULL stats_cpu prevents the following oops caused by that race. [ 1117.285199] Unable to handle kernel paging request for data at address 0x7fb4d0020 [ 1117.285252] Faulting instruction address: 0xc0000000003efa2c [ 1137.733921] Oops: Kernel access of bad area, sig: 11 [#1] [ 1137.733945] SMP NR_CPUS=2048 NUMA PowerNV [ 1137.734025] Modules linked in: bridge stp llc kvm_hv kvm binfmt_misc autofs4 [ 1137.734102] CPU: 3 PID: 5302 Comm: blkcgroup Not tainted 3.19.0 #5 [ 1137.734132] task: c000000f1d188b00 ti: c000000f1d210000 task.ti: c000000f1d210000 [ 1137.734167] NIP: c0000000003efa2c LR: c0000000003ef9f0 CTR: c0000000003ef980 [ 1137.734202] REGS: c000000f1d213500 TRAP: 0300 Not tainted (3.19.0) [ 1137.734230] MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 42008884 XER: 20000000 [ 1137.734325] CFAR: 0000000000008458 DAR: 00000007fb4d0020 DSISR: 40000000 SOFTE: 0 GPR00: c0000000003ed3a0 c000000f1d213780 c000000000c59538 0000000000000000 GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000 GPR08: ffffffffffffffff 00000007fb4d0020 00000007fb4d0000 c000000000780808 GPR12: 0000000022000888 c00000000fdc0d80 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 000001003e120200 c000000f1d5b0cc0 0000000000000200 0000000000000000 GPR24: 0000000000000001 c000000000c269e0 0000000000000020 c000000f1d5b0c80 GPR28: c000000000ca3a08 c000000000ca3dec c000000f1c667e00 c000000f1d213850 [ 1137.734886] NIP [c0000000003efa2c] .tg_prfill_cpu_rwstat+0xac/0x180 [ 1137.734915] LR [c0000000003ef9f0] .tg_prfill_cpu_rwstat+0x70/0x180 [ 1137.734943] Call Trace: [ 1137.734952] [c000000f1d213780] [d000000005560520] 0xd000000005560520 (unreliable) [ 1137.734996] [c000000f1d2138a0] [c0000000003ed3a0] .blkcg_print_blkgs+0xe0/0x1a0 [ 1137.735039] [c000000f1d213960] [c0000000003efb50] .tg_print_cpu_rwstat+0x50/0x70 [ 1137.735082] [c000000f1d2139e0] [c000000000104b48] .cgroup_seqfile_show+0x58/0x150 [ 1137.735125] [c000000f1d213a70] [c0000000002749dc] .kernfs_seq_show+0x3c/0x50 [ 1137.735161] [c000000f1d213ae0] [c000000000218630] .seq_read+0xe0/0x510 [ 1137.735197] [c000000f1d213bd0] [c000000000275b04] .kernfs_fop_read+0x164/0x200 [ 1137.735240] [c000000f1d213c80] [c0000000001eb8e0] .__vfs_read+0x30/0x80 [ 1137.735276] [c000000f1d213cf0] [c0000000001eb9c4] .vfs_read+0x94/0x1b0 [ 1137.735312] [c000000f1d213d90] [c0000000001ebb38] .SyS_read+0x58/0x100 [ 1137.735349] [c000000f1d213e30] [c000000000009218] syscall_exit+0x0/0x98 [ 1137.735383] Instruction dump: [ 1137.735405] 7c6307b4 7f891800 409d00b8 60000000 60420000 3d420004 392a63b0 786a1f24 [ 1137.735471] 7d49502a e93e01c8 7d495214 7d2ad214 <7cead02a> e9090008 e9490010 e9290018 And here is one code that allows to easily reproduce this, although this has first been found by running docker. void run(pid_t pid) { int n; int status; int fd; char buffer; buffer = memalign(BUFFER_ALIGN, BUFFER_SIZE); n = snprintf(buffer, BUFFER_SIZE, "%d\n", pid); fd = open(CGPATH "/test/tasks", O_WRONLY); write(fd, buffer, n); close(fd); if (fork() > 0) { fd = open("/dev/sda", O_RDONLY \| O_DIRECT); read(fd, buffer, 512); close(fd); wait(&status); } else { fd = open(CGPATH "/test/blkio.throttle.io_serviced", O_RDONLY); n = read(fd, buffer, BUFFER_SIZE); close(fd); } free(buffer); exit(0); } void test(void) { int status; mkdir(CGPATH "/test", 0666); if (fork() > 0) wait(&status); else run(getpid()); rmdir(CGPATH "/test"); } int main(int argc, char *argv) { int i; for (i = 0; i < NR_TESTS; i++) test(); return 0; } Reported-by: Ricardo Marin Matinata <rmm@br.ibm.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Filipe Manana	f8d6da8ab0	Btrfs: fix fsync data loss after adding hard link to inode commit `1a4bcf470c` upstream. We have a scenario where after the fsync log replay we can lose file data that had been previously fsync'ed if we added an hard link for our inode and after that we sync'ed the fsync log (for example by fsync'ing some other file or directory). This is because when adding an hard link we updated the inode item in the log tree with an i_size value of 0. At that point the new inode item was in memory only and a subsequent fsync log replay would not make us lose the file data. However if after adding the hard link we sync the log tree to disk, by fsync'ing some other file or directory for example, we ended up losing the file data after log replay, because the inode item in the persisted log tree had an an i_size of zero. This is easy to reproduce, and the following excerpt from my test for xfstests shows this: _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create one file with data and fsync it. # This made the btrfs fsync log persist the data and the inode metadata with # a correct inode->i_size (4096 bytes). $XFS_IO_PROG -f -c "pwrite -S 0xaa -b 4K 0 4K" -c "fsync" \ $SCRATCH_MNT/foo \| _filter_xfs_io # Now add one hard link to our file. This made the btrfs code update the fsync # log, in memory only, with an inode metadata having a size of 0. ln $SCRATCH_MNT/foo $SCRATCH_MNT/foo_link # Now force persistence of the fsync log to disk, for example, by fsyncing some # other file. touch $SCRATCH_MNT/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/bar # Before a power loss or crash, we could read the 4Kb of data from our file as # expected. echo "File content before:" od -t x1 $SCRATCH_MNT/foo # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # After the fsync log replay, because the fsync log had a value of 0 for our # inode's i_size, we couldn't read anymore the 4Kb of data that we previously # wrote and fsync'ed. The size of the file became 0 after the fsync log replay. echo "File content after:" od -t x1 $SCRATCH_MNT/foo Another alternative test, that doesn't need to fsync an inode in the same transaction it was created, is: _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create our test file with some data. $XFS_IO_PROG -f -c "pwrite -S 0xaa -b 8K 0 8K" \ $SCRATCH_MNT/foo \| _filter_xfs_io # Make sure the file is durably persisted. sync # Append some data to our file, to increase its size. $XFS_IO_PROG -f -c "pwrite -S 0xcc -b 4K 8K 4K" \ $SCRATCH_MNT/foo \| _filter_xfs_io # Fsync the file, so from this point on if a crash/power failure happens, our # new data is guaranteed to be there next time the fs is mounted. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo # Add one hard link to our file. This made btrfs write into the in memory fsync # log a special inode with generation 0 and an i_size of 0 too. Note that this # didn't update the inode in the fsync log on disk. ln $SCRATCH_MNT/foo $SCRATCH_MNT/foo_link # Now make sure the in memory fsync log is durably persisted. # Creating and fsync'ing another file will do it. touch $SCRATCH_MNT/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/bar # As expected, before the crash/power failure, we should be able to read the # 12Kb of file data. echo "File content before:" od -t x1 $SCRATCH_MNT/foo # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # After mounting the fs again, the fsync log was replayed. # The btrfs fsync log replay code didn't update the i_size of the persisted # inode because the inode item in the log had a special generation with a # value of 0 (and it couldn't know the correct i_size, since that inode item # had a 0 i_size too). This made the last 4Kb of file data inaccessible and # effectively lost. echo "File content after:" od -t x1 $SCRATCH_MNT/foo This isn't a new issue/regression. This problem has been around since the log tree code was added in 2008: Btrfs: Add a write ahead tree log to optimize synchronous operations (commit `e02119d5a7`) Test cases for xfstests follow soon. Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
David Sterba	751e276c00	btrfs: fix leak of path in btrfs_find_item commit `381cf6587f` upstream. If btrfs_find_item is called with NULL path it allocates one locally but does not free it. Affected paths are inserting an orphan item for a file and for a subvol root. Move the path allocation to the callers. Fixes: `3f870c2899` ("btrfs: expand btrfs_find_item() to include find_orphan_item functionality") Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
David Sterba	b4d32c3688	btrfs: set proper message level for skinny metadata commit `5efa0490cc` upstream. This has been confusing people for too long, the message is really just informative. Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Ilya Dryomov	cd95650259	libceph: fix double __remove_osd() problem commit `7eb71e0351` upstream. It turns out it's possible to get __remove_osd() called twice on the same OSD. That doesn't sit well with rb_erase() - depending on the shape of the tree we can get a NULL dereference, a soft lockup or a random crash at some point in the future as we end up touching freed memory. One scenario that I was able to reproduce is as follows: <osd3 is idle, on the osd lru list> <con reset - osd3> con_fault_finish() osd_reset() <osdmap - osd3 down> ceph_osdc_handle_map() <takes map_sem> kick_requests() <takes request_mutex> reset_changed_osds() __reset_osd() __remove_osd() <releases request_mutex> <releases map_sem> <takes map_sem> <takes request_mutex> __kick_osd_requests() __reset_osd() __remove_osd() <-- !!! A case can be made that osd refcounting is imperfect and reworking it would be a proper resolution, but for now Sage and I decided to fix this by adding a safe guard around __remove_osd(). Fixes: http://tracker.ceph.com/issues/8087 Cc: Sage Weil <sage@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Hans de Goede	b3b3972a8b	samsung-laptop: Add use_native_backlight quirk, and enable it on some models commit `4690555e13` upstream. Since kernel 3.14 the backlight control has been broken on various Samsung Atom based netbooks. This has been bisected and this problem happens since commit `b35684b8fa` ("drm/i915: do full backlight setup at enable time") This has been reported and discussed in detail here: http://lists.freedesktop.org/archives/intel-gfx/2014-July/049395.html Unfortunately no-one has been able to fix this. This only affects Samsung Atom netbooks, and the Linux kernel and the BIOS of those laptops have never worked well together. All affected laptops already have a quirk to avoid using the standard acpi-video interface and instead use the samsung specific SABI interface which samsung-laptop uses. It seems that recent fixes to the i915 driver have also broken backlight control through the SABI interface. The intel_backlight driver OTOH works fine, and also allows for finer grained backlight control. So add a new use_native_backlight quirk, and replace the broken_acpi_video quirk with this quirk for affected models. This new quirk disables acpi-video as before and also stops samsung-laptop from registering the SABI based samsung_laptop backlight interface, leaving only the working intel_backlight interface. This commit enables this new quirk for 3 models which are known to be affected, chances are that it needs to be used on other models too. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1094948 # N145P BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1115713 # N250P Reported-by: Bertrik Sikken <bertrik@sikken.nl> # N150P Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Chen Jie	37ae6d6884	jffs2: fix handling of corrupted summary length commit `164c24063a` upstream. sm->offset maybe wrong but magic maybe right, the offset do not have CRC. Badness at c00c7580 [verbose debug info unavailable] NIP: c00c7580 LR: c00c718c CTR: 00000014 REGS: df07bb40 TRAP: 0700 Not tainted (2.6.34.13-WR4.3.0.0_standard) MSR: 00029000 <EE,ME,CE> CR: 22084f84 XER: 00000000 TASK = df84d6e0[908] 'mount' THREAD: df07a000 GPR00: 00000001 df07bbf0 df84d6e0 00000000 00000001 00000000 df07bb58 00000041 GPR08: 00000041 c0638860 00000000 00000010 22084f88 100636c8 df814ff8 00000000 GPR16: df84d6e0 dfa558cc c05adb90 00000048 c0452d30 00000000 000240d0 000040d0 GPR24: 00000014 c05ae734 c05be2e0 00000000 00000001 00000000 00000000 c05ae730 NIP [c00c7580] __alloc_pages_nodemask+0x4d0/0x638 LR [c00c718c] __alloc_pages_nodemask+0xdc/0x638 Call Trace: [df07bbf0] [c00c718c] __alloc_pages_nodemask+0xdc/0x638 (unreliable) [df07bc90] [c00c7708] __get_free_pages+0x20/0x48 [df07bca0] [c00f4a40] __kmalloc+0x15c/0x1ec [df07bcd0] [c01fc880] jffs2_scan_medium+0xa58/0x14d0 [df07bd70] [c01ff38c] jffs2_do_mount_fs+0x1f4/0x6b4 [df07bdb0] [c020144c] jffs2_do_fill_super+0xa8/0x260 [df07bdd0] [c020230c] jffs2_fill_super+0x104/0x184 [df07be00] [c0335814] get_sb_mtd_aux+0x9c/0xec [df07be20] [c033596c] get_sb_mtd+0x84/0x1e8 [df07be60] [c0201ed0] jffs2_get_sb+0x1c/0x2c [df07be70] [c0103898] vfs_kern_mount+0x78/0x1e8 [df07bea0] [c0103a58] do_kern_mount+0x40/0x100 [df07bec0] [c011fe90] do_mount+0x240/0x890 [df07bf10] [c0120570] sys_mount+0x90/0xd8 [df07bf40] [c00110d8] ret_from_syscall+0x0/0x4 === Exception: c01 at 0xff61a34 LR = 0x100135f0 Instruction dump: 38800005 38600000 48010f41 4bfffe1c 4bfc2d15 4bfffe8c 72e90200 4082fc28 3d20c064 39298860 8809000d 68000001 <0f000000> 2f800000 419efc0c 38000001 mount: mounting /dev/mtdblock3 on /common failed: Input/output error Signed-off-by: Chen Jie <chenjie6@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Daniel J Blueman	6a35db9924	EDAC, amd64_edac: Prevent OOPS with >16 memory controllers commit `0c510cc83b` upstream. When DRAM errors occur on memory controllers after EDAC_MAX_MCS (16), the kernel fatally dereferences unallocated structures, see splat below; this occurs on at least NumaConnect systems. Fix by checking if a memory controller info structure was found. BUG: unable to handle kernel NULL pointer dereference at 0000000000000320 IP: [<ffffffff819f714f>] decode_bus_error+0x2f/0x2b0 PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0 Oops: 0000 [#2] SMP Modules linked in: CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G D 3.19.0 #1 Hardware name: Supermicro H8QGL/H8QGL, BIOS 3.5b 01/28/2015 task: ffff8807dbfb8c00 ti: ffff8807dd16c000 task.ti: ffff8807dd16c000 RIP: 0010:[<ffffffff819f714f>] [<ffffffff819f714f>] decode_bus_error+0x2f/0x2b0 RSP: 0000:ffff8907dfc03c48 EFLAGS: 00010297 RAX: 0000000000000001 RBX: 9c67400010080a13 RCX: 0000000000001dc6 RDX: 000000001dc61dc6 RSI: ffff8907dfc03df0 RDI: 000000000000001c RBP: ffff8907dfc03ce8 R08: 0000000000000000 R09: 0000000000000022 R10: ffff891fffa30380 R11: 00000000001cfc90 R12: 0000000000000008 R13: 0000000000000000 R14: 000000000000001c R15: 00009c6740001000 FS: 00007fa97ee18700(0000) GS:ffff8907dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000320 CR3: 0000003f889b8000 CR4: 00000000000407e0 Stack: 0000000000000000 ffff8907dfc03df0 0000000000000008 9c67400010080a13 000000000000001c 00009c6740001000 ffff8907dfc03c88 ffffffff810e4f9a ffff8907dfc03ce8 ffffffff81b375b9 0000000000000000 0000000000000010 Call Trace: <IRQ> ? vprintk_default ? printk amd_decode_mce notifier_call_chain atomic_notifier_call_chain mce_log machine_check_poll mce_timer_fn ? mce_cpu_restart call_timer_fn.isra.29 run_timer_softirq __do_softirq irq_exit smp_apic_timer_interrupt apic_timer_interrupt <EOI> ? down_read_trylock __do_page_fault ? __schedule do_page_fault page_fault Signed-off-by: Daniel J Blueman <daniel@numascale.com> Link: http://lkml.kernel.org/r/1424144078-24589-1-git-send-email-daniel@numascale.com [ Boris: massage commit message ] Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Borislav Petkov	90de8c9dc2	sb_edac: Fix detection on SNB machines commit `11249e7399` upstream. `d0585cd815` ("sb_edac: Claim a different PCI device") changed the probing of sb_edac to look for PCI device 0x3ca0: 3f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07) 00: 86 80 a0 3c 00 00 00 00 07 00 80 08 00 00 80 00 ... but we're matching for 0x3ca8, i.e. PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA in sbridge_probe() therefore the probing fails. Changing it to probe for 0x3ca0 (PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0), .i.e., the 14.0 device, fixes the issue and driver loads successfully again: [ 2449.013120] EDAC DEBUG: sbridge_init: [ 2449.017029] EDAC sbridge: Seeking for: PCI ID 8086:3ca0 [ 2449.022368] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca0 [ 2449.028498] EDAC sbridge: Seeking for: PCI ID 8086:3ca0 [ 2449.033768] EDAC sbridge: Seeking for: PCI ID 8086:3ca8 [ 2449.039028] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca8 [ 2449.045155] EDAC sbridge: Seeking for: PCI ID 8086:3ca8 ... Add a debug printk while at it to be able to catch the failure in the future and dump driver version on successful load. Fixes: `d0585cd815` ("sb_edac: Claim a different PCI device") Acked-by: Aristeu Rozanski <aris@redhat.com> Cc: Tony Luck <tony.luck@intel.com> Acked-by: Andy Lutomirski <luto@amacapital.net> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
Tomáš Hodek	177f6a7ea9	md/raid1: fix read balance when a drive is write-mostly. commit `d1901ef099` upstream. When a drive is marked write-mostly it should only be the target of reads if there is no other option. This behaviour was broken by commit `9dedf60313` md/raid1: read balance chooses idlest disk for SSD which causes a write-mostly device to be preferred is some cases. Restore correct behaviour by checking and setting best_dist_disk and best_pending_disk rather than best_disk. We only need to test one of these as they are both changed from -1 or >=0 at the same time. As we leave min_pending and best_dist unchanged, any non-write-mostly device will appear better than the write-mostly device. Reported-by: Tomáš Hodek <tomas.hodek@volny.cz> Reported-by: Dark Penguin <darkpenguin@yandex.ru> Signed-off-by: NeilBrown <neilb@suse.de> Link: http://marc.info/?l=linux-raid&m=135982797322422 Fixes: `9dedf60313` Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:05 -08:00
NeilBrown	dbf3bbd136	md/raid5: Fix livelock when array is both resyncing and degraded. commit `26ac107378` upstream. Commit `a7854487cd`: md: When RAID5 is dirty, force reconstruct-write instead of read-modify-write. Causes an RCW cycle to be forced even when the array is degraded. A degraded array cannot support RCW as that requires reading all data blocks, and one may be missing. Forcing an RCW when it is not possible causes a live-lock and the code spins, repeatedly deciding to do something that cannot succeed. So change the condition to only force RCW on non-degraded arrays. Reported-by: Manibalan P <pmanibalan@amiindia.co.in> Bisected-by: Jes Sorensen <Jes.Sorensen@redhat.com> Tested-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de> Fixes: `a7854487cd` Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:04 -08:00
Adrian Hunter	f2ee626bf6	perf tools: Fix probing for PERF_FLAG_FD_CLOEXEC flag commit `48536c9195` upstream. Commit `f6edb53c49` converted the probe to a CPU wide event first (pid == -1). For kernels that do not support the PERF_FLAG_FD_CLOEXEC flag the probe fails with EINVAL. Since this errno is not handled pid is not reset to 0 and the subsequent use of pid = -1 as an argument brings in an additional failure path if perf_event_paranoid > 0: $ perf record -- sleep 1 perf_event_open(..., 0) failed unexpectedly with error 13 (Permission denied) [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.007 MB /tmp/perf.data (11 samples) ] Also, ensure the fd of the confirmation check is closed and comment why pid = -1 is used. Needs to go to 3.18 stable tree as well. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Based-on-patch-by: David Ahern <david.ahern@oracle.com> Acked-by: David Ahern <david.ahern@oracle.com> Cc: David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/54EC610C.8000403@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:04 -08:00
Matthias Brugger	df1d6514e9	clocksource: mtk: Fix race conditions in probe code commit `d4a19eb3b1` upstream. We have two race conditions in the probe code which could lead to a null pointer dereference in the interrupt handler. The interrupt handler accesses the clockevent device, which may not yet be registered. First race condition happens when the interrupt handler gets registered before the interrupts get disabled. The second race condition happens when the interrupts get enabled, but the clockevent device is not yet registered. Fix that by disabling the interrupts before we register the interrupt and enable the interrupts after the clockevent device got registered. Reported-by: Gongbae Park <yongbae2@gmail.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:04 -08:00
James Hogan	32effd19f6	metag: Fix KSTK_EIP() and KSTK_ESP() macros commit `c2996cb29b` upstream. The KSTK_EIP() and KSTK_ESP() macros should return the user program counter (PC) and stack pointer (A0StP) of the given task. These are used to determine which VMA corresponds to the user stack in /proc/<pid>/maps, and for the user PC & A0StP in /proc/<pid>/stat. However for Meta the PC & A0StP from the task's kernel context are used, resulting in broken output. For example in following /proc/<pid>/maps output, the 3afff000-3b021000 VMA should be described as the stack: # cat /proc/self/maps ... 100b0000-100b1000 rwxp 00000000 00:00 0 [heap] 3afff000-3b021000 rwxp 00000000 00:00 0 And in the following /proc/<pid>/stat output, the PC is in kernel code (1074234964 = 0x40078654) and the A0StP is in the kernel heap (1335981392 = 0x4fa17550): # cat /proc/self/stat 51 (cat) R ... 1335981392 1074234964 ... Fix the definitions of KSTK_EIP() and KSTK_ESP() to use task_pt_regs(tsk)->ctx rather than (tsk)->thread.kernel_context. This gets the registers from the user context stored after the thread info at the base of the kernel stack, which is from the last entry into the kernel from userland, regardless of where in the kernel the task may have been interrupted, which results in the following more correct /proc/<pid>/maps output: # cat /proc/self/maps ... 0800b000-08070000 r-xp 00000000 00:02 207 /lib/libuClibc-0.9.34-git.so ... 100b0000-100b1000 rwxp 00000000 00:00 0 [heap] 3afff000-3b021000 rwxp 00000000 00:00 0 [stack] And /proc/<pid>/stat now correctly reports the PC in libuClibc (134320308 = 0x80190b4) and the A0StP in the [stack] region (989864576 = 0x3b002280): # cat /proc/self/stat 51 (cat) R ... 989864576 134320308 ... Reported-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-metag@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:04 -08:00
Jan Kara	1a5f213878	xfs: Fix quota type in quota structures when reusing quota file commit `dfcc70a8c8` upstream. For filesystems without separate project quota inode field in the superblock we just reuse project quota file for group quotas (and vice versa) if project quota file is allocated and we need group quota file. When we reuse the file, quota structures on disk suddenly have wrong type stored in d_flags though. Nobody really cares about this (although structure type reported to userspace was wrong as well) except that after commit `14bf61ffe6` (quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units) assertion in xfs_qm_scall_getquota() started to trigger on xfs/106 test (apparently I was testing without XFS_DEBUG so I didn't notice when submitting the above commit). Fix the problem by properly resetting ddq->d_flags when running quotacheck for a quota file. Reported-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:04 -08:00
Nicolas Saenz Julienne	171f992511	gpio: tps65912: fix wrong container_of arguments commit `2f97c20e5f` upstream. The gpio_chip operations receive a pointer the gpio_chip struct which is contained in the driver's private struct, yet the container_of call in those functions point to the mfd struct defined in include/linux/mfd/tps65912.h. Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
Hans Holmberg	7229e9bfe3	gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node commit `9cf75e9e4d` upstream. The change: `7b8792bbdf` gpiolib: of: Correct error handling in of_get_named_gpiod_flags assumed that only one gpio-chip is registred per of-node. Some drivers register more than one chip per of-node, so adjust the matching function of_gpiochip_find_and_xlate to not stop looking for chips if a node-match is found and the translation fails. Fixes: `7b8792bbdf` ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags") Signed-off-by: Hans Holmberg <hans.holmberg@intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Tested-by: Tyler Hall <tylerwhall@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
Catalin Marinas	a4fedc858d	arm64: compat Fix siginfo_t -> compat_siginfo_t conversion on big endian commit `9d42d48a34` upstream. The native (64-bit) sigval_t union contains sival_int (32-bit) and sival_ptr (64-bit). When a compat application invokes a syscall that takes a sigval_t value (as part of a larger structure, e.g. compat_sys_mq_notify, compat_sys_timer_create), the compat_sigval_t union is converted to the native sigval_t with sival_int overlapping with either the least or the most significant half of sival_ptr, depending on endianness. When the corresponding signal is delivered to a compat application, on big endian the current (compat_uptr_t)sival_ptr cast always returns 0 since sival_int corresponds to the top part of sival_ptr. This patch fixes copy_siginfo_to_user32() so that sival_int is copied to the compat_siginfo_t structure. Reported-by: Bamvor Jian Zhang <bamvor.zhangjian@huawei.com> Tested-by: Bamvor Jian Zhang <bamvor.zhangjian@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
Martin Vajnar	17392a1a49	hx4700: regulator: declare full constraints commit `a52d209336` upstream. Since the removal of CONFIG_REGULATOR_DUMMY option, the touchscreen stopped working. This patch enables the "replacement" for REGULATOR_DUMMY and allows the touchscreen to work even though there is no regulator for "vcc". Signed-off-by: Martin Vajnar <martin.vajnar@gmail.com> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
Jiang Liu	d7e48886e5	x86/xen: Treat SCI interrupt as normal GSI interrupt commit `b568b8601f` upstream. Currently Xen Domain0 has special treatment for ACPI SCI interrupt, that is initialize irq for ACPI SCI at early stage in a special way as: xen_init_IRQ() ->pci_xen_initial_domain() ->xen_setup_acpi_sci() Allocate and initialize irq for ACPI SCI Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on IOAPIC irqdomains through following path acpi_gsi_to_irq() ->mp_map_gsi_to_irq() ->mp_map_pin_to_irq() ->check IOAPIC irqdomain For PV domains, it uses Xen event based interrupt manangement and doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC. This causes Xen domain0 fail to install interrupt handler for ACPI SCI and all ACPI events will be lost. Please refer to: https://lkml.org/lkml/2014/12/19/178 So the fix is to get rid of special treatment for ACPI SCI, just treat ACPI SCI as normal GSI interrupt as: acpi_gsi_to_irq() ->acpi_register_gsi() ->acpi_register_gsi_xen() ->xen_register_gsi() With above change, there's no need for xen_setup_acpi_sci() anymore. The above change also works with bare metal kernel too. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Cc: Tony Luck <tony.luck@intel.com> Cc: xen-devel@lists.xenproject.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
David Hildenbrand	0b4a17fc63	KVM: s390: avoid memory leaks if __inject_vm() fails commit `428d53be5e` upstream. We have to delete the allocated interrupt info if __inject_vm() fails. Otherwise user space can keep flooding kvm with floating interrupts and provoke more and more memory leaks. Reported-by: Dominik Dingel <dingel@linux.vnet.ibm.com> Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:03 -08:00
David Hildenbrand	6d6cdcaf12	KVM: s390: floating irqs: fix user triggerable endless loop commit `8e2207cdd0` upstream. If a vm with no VCPUs is created, the injection of a floating irq leads to an endless loop in the kernel. Let's skip the search for a destination VCPU for a floating irq if no VCPUs were created. Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:02 -08:00
David Hildenbrand	6d351caba5	KVM: s390: base hrtimer on a monotonic clock commit `0ac96caf0f` upstream. The hrtimer that handles the wait with enabled timer interrupts should not be disturbed by changes of the host time. This patch changes our hrtimer to be based on a monotonic clock. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:02 -08:00
David Hildenbrand	ed9eb28550	KVM: s390: forward hrtimer if guest ckc not pending yet commit `2d00f75942` upstream. Patch `0759d0681c` ("KVM: s390: cleanup handle_wait by reusing kvm_vcpu_block") changed the way pending guest clock comparator interrupts are detected. It was assumed that as soon as the hrtimer wakes up, the condition for the guest ckc is satisfied. This is however only true as long as adjclock() doesn't speed up the monotonic clock. Reason is that the hrtimer is based on CLOCK_MONOTONIC, the guest clock comparator detection is based on the raw TOD clock. If CLOCK_MONOTONIC runs faster than the TOD clock, the hrtimer wakes the target VCPU up too early and the target VCPU will not detect any pending interrupts, therefore going back to sleep. It will never be woken up again because the hrtimer has finished. The VCPU is stuck. As a quick fix, we have to forward the hrtimer until the guest clock comparator is really due, to guarantee properly timed wake ups. As the hrtimer callback might be triggered on another cpu, we have to make sure that the timer is really stopped and not currently executing the callback on another cpu. This can happen if the vcpu thread is scheduled onto another physical cpu, but the timer base is not migrated. So lets use hrtimer_cancel instead of try_to_cancel. A proper fix might be to introduce a RAW based hrtimer. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:02 -08:00
Marcelo Tosatti	d204feb294	KVM: x86: update masterclock values on TSC writes commit `7f187922dd` upstream. When the guest writes to the TSC, the masterclock TSC copy must be updated as well along with the TSC_OFFSET update, otherwise a negative tsc_timestamp is calculated at kvm_guest_time_update. Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to "if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)" becomes redundant, so remove the do_request boolean and collapse everything into a single condition. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:02 -08:00
Jan Kara	f21d9d4448	udf: Check length of extended attributes and allocation descriptors commit `23b133bdc4` upstream. Check length of extended attributes and allocation descriptors when loading inodes from disk. Otherwise corrupted filesystems could confuse the code and make the kernel oops. Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:02 -08:00
Jan Kara	f4145654aa	udf: Remove repeated loads blocksize commit `7914495427` upstream. Store blocksize in a local variable in udf_fill_inode() since it is used a lot of times. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Markos Chandras	09f2e748e0	MIPS: HTW: Prevent accidental HTW start due to nested htw_{start, stop} commit `ed4cbc81ad` upstream. activate_mm() and switch_mm() call get_new_mmu_context() which in turn can enable the HTW before the entryhi is changed with the new ASID. Since the latter will enable the HTW in local_flush_tlb_all(), then there is a small timing window where the HTW is running with the new ASID but with an old pgd since the TLBMISS_HANDLER_SETUP_PGD hasn't assigned a new one yet. In order to prevent that, we introduce a simple htw counter to avoid starting HTW accidentally due to nested htw_{start,stop}() sequences. Moreover, since various IPI calls can enforce TLB flushing operations on a different core, such an operation may interrupt another htw_{stop,start} in progress leading inconsistent updates of the htw_seq variable. In order to avoid that, we disable the interrupts whenever we update that variable. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9118/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Alexey Brodkin	b3b345af59	ARC: fix page address calculation if PAGE_OFFSET != LINUX_LINK_BASE commit `06f34e1c28` upstream. We used to calculate page address differently in 2 cases: 1. In virt_to_page(x) we do --->8--- mem_map + (x - CONFIG_LINUX_LINK_BASE) >> PAGE_SHIFT --->8--- 2. In in pte_page(x) we do --->8--- mem_map + (pte_val(x) - PAGE_OFFSET) >> PAGE_SHIFT --->8--- That leads to problems in case PAGE_OFFSET != CONFIG_LINUX_LINK_BASE - different pages will be selected depending on where and how we calculate page address. In particular in the STAR 9000853582 when gdb attempted to read memory of another process it got improper page in get_user_pages() because this is exactly one of the places where we search for a page by pte_page(). The fix is trivial - we need to calculate page address similarly in both cases. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Stefan Agner	8f9b87b3dc	serial: fsl_lpuart: avoid new transfer while DMA is running commit `5f1437f61a` upstream. When the UART is in DMA receive mode (RDMAS set) and one character just arrived while another interrupt is handled (e.g. TX), the RDRF (receiver data register full flag) is set due to the water level of 1. But since the DMA will take care of this character, there is no need to handle it by calling lpuart_prepare_rx. Handling it leads to adding the RX timeout timer twice: [ 74.336698] Kernel BUG at 80053070 [verbose debug info unavailable] [ 74.342999] Internal error: Oops - BUG: 0 [#1] ARM0:00.00 khungtaskd [ 74.347817] Modules linked in: 0 S 0.0 0.0 0:00.00 writeback [ 74.350926] CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-rc3-00001-g39d78e2 #1788 [ 74.358617] Hardware name: Freescale Vybrid VF610 (Device Tree)t [ 74.364563] task: 807a7678 ti: 8079c000 task.ti: 8079c000 kblockd [ 74.370002] PC is at add_timer+0x24/0x28.0 0.0 0:00.09 kworker/u2:1 [ 74.373960] LR is at lpuart_int+0x15c/0x3d8 [ 74.378171] pc : [<80053070>] lr : [<802e0d88>] psr: a0010193 [ 74.378171] sp : 8079de10 ip : 8079de20 fp : 8079de1c [ 74.389694] r10: 807d44c0 r9 : 8688c300 r8 : 00000013 [ 74.394943] r7 : 20010193 r6 : 00000000 r5 : 000000a0 r4 : 86997210 [ 74.401498] r3 : ffffa7da r2 : 80817868 r1 : 86997210 r0 : 86997344 [ 74.408052] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 74.415489] Control: 10c5387d Table: 8611c059 DAC: 00000015 [ 74.421265] Process swapper (pid: 0, stack limit = 0x8079c230) ... Solve this by only execute the receiver path (lpuart_prepare_rx) if the DMA receive mode (RDMAS) is not set. Also, make sure the flag is cleared on initialization, in case it has been left set. This can be best reproduced using UART as a serial console, then running top while dd'ing data into the terminal. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Stefan Agner	5716a78103	serial: fsl_lpuart: delete timer on shutdown commit `4a8588a1cf` upstream. If the serial port gets closed while a RX transfer is in progress, the timer might fire after the serial port shutdown finished. This leads in a NULL pointer dereference: [ 7.508324] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 7.516590] pgd = 86348000 [ 7.519445] [00000000] pgd=86179831, pte=00000000, *ppte=00000000 [ 7.526145] Internal error: Oops: 17 [#1] ARM [ 7.530611] Modules linked in: [ 7.533876] CPU: 0 PID: 123 Comm: systemd Not tainted 3.19.0-rc3-00004-g5b11ea7 #1778 [ 7.541827] Hardware name: Freescale Vybrid VF610 (Device Tree) [ 7.547862] task: 861c3400 ti: 86ac8000 task.ti: 86ac8000 [ 7.553392] PC is at lpuart_timer_func+0x24/0xf8 [ 7.558127] LR is at lpuart_timer_func+0x20/0xf8 [ 7.562857] pc : [<802df99c>] lr : [<802df998>] psr: 600b0113 [ 7.562857] sp : 86ac9b90 ip : 86ac9b90 fp : 86ac9bbc [ 7.574467] r10: 80817180 r9 : 80817b98 r8 : 80817998 [ 7.579803] r7 : 807acee0 r6 : 86989000 r5 : 00000100 r4 : 86997210 [ 7.586444] r3 : 86ac8000 r2 : 86ac9bc0 r1 : 86997210 r0 : 00000000 [ 7.593085] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 7.600341] Control: 10c5387d Table: 86348059 DAC: 00000015 [ 7.606203] Process systemd (pid: 123, stack limit = 0x86ac8230) Setup the timer on UART startup which allows to delete the timer unconditionally on shutdown. This also saves the initialization on each transfer. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
John Stultz	20dcda8d40	ntp: Fixup adjtimex freq validation on 32-bit systems commit `29183a70b0` upstream. Additional validation of adjtimex freq values to avoid potential multiplication overflows were added in commit `5e5aeb4367` (time: adjtimex: Validate the ADJ_FREQUENCY values) Unfortunately the patch used LONG_MAX/MIN instead of LLONG_MAX/MIN, which was fine on 64-bit systems, but being much smaller on 32-bit systems caused false positives resulting in most direct frequency adjustments to fail w/ EINVAL. ntpd only does direct frequency adjustments at startup, so the issue was not as easily observed there, but other time sync applications like ptpd and chrony were more effected by the bug. See bugs: https://bugzilla.kernel.org/show_bug.cgi?id=92481 https://bugzilla.redhat.com/show_bug.cgi?id=1188074 This patch changes the checks to use LLONG_MAX for clarity, and additionally the checks are disabled on 32-bit systems since LLONG_MAX/PPM_SCALE is always larger then the 32-bit long freq value, so multiplication overflows aren't possible there. Reported-by: Josh Boyer <jwboyer@fedoraproject.org> Reported-by: George Joseph <george.joseph@fairview5.com> Tested-by: George Joseph <george.joseph@fairview5.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Sasha Levin <sasha.levin@oracle.com> Link: http://lkml.kernel.org/r/1423553436-29747-1-git-send-email-john.stultz@linaro.org [ Prettified the changelog and the comments a bit. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Jay Lan	ab66a1f3cf	kdb: fix incorrect counts in KDB summary command output commit `1467559232` upstream. The output of KDB 'summary' command should report MemTotal, MemFree and Buffers output in kB. Current codes report in unit of pages. A define of K(x) as is defined in the code, but not used. This patch would apply the define to convert the values to kB. Please include me on Cc on replies. I do not subscribe to linux-kernel. Signed-off-by: Jay Lan <jlan@sgi.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:01 -08:00
Arnd Bergmann	67d4f7810b	ARM: mvebu: build armada375-smp code conditionally commit `165235180f` upstream. mvebu_armada375_smp_wa_init is only used on armada 375 but is defined for all mvebu machines. As it calls a function that is only provided sometimes, this can result in a link error: arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init': :(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa' To solve this, we can just change the existing #ifdef around the function to also check for Armada375 SMP platforms. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: `305969fb62` ("ARM: mvebu: use the common function for Armada 375 SMP workaround") Cc: Andrew Lunn <andrew@lunn.ch> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Gregory Clement <gregory.clement@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Arnd Bergmann	9487809ac5	ARM: vexpress: use ARM_CPU_SUSPEND if needed commit `95fcedb027` upstream. The vexpress tc2 power management code calls mcpm_loopback, which is only available if ARM_CPU_SUSPEND is enabled, otherwise we get a link error: arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init': arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback' This explicitly selects ARM_CPU_SUSPEND like other platforms that need it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: `3592d7e002` ("ARM: 8082/1: TC2: test the MCPM loopback during boot") Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Dmitry Eremin-Solenikov	4a6cc3baa1	ARM: pxa: add regulator_has_full_constraints to poodle board file commit `9bc78f32c2` upstream. Add regulator_has_full_constraints() call to poodle board file to let regulator core know that we do not have any additional regulators left. This lets it substitute unprovided regulators with dummy ones. This fixes the following warnings that can be seen on poodle if regulators are enabled: ads7846 spi1.0: unable to get regulator: -517 spi spi1.0: Driver ads7846 requests probe deferral wm8731 0-001b: Failed to get supply 'AVDD': -517 wm8731 0-001b: Failed to request supplies: -517 wm8731 0-001b: ASoC: failed to probe component -517 Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Dmitry Eremin-Solenikov	30cb324e72	ARM: pxa: add regulator_has_full_constraints to corgi board file commit `271e80176a` upstream. Add regulator_has_full_constraints() call to corgi board file to let regulator core know that we do not have any additional regulators left. This lets it substitute unprovided regulators with dummy ones. This fixes the following warnings that can be seen on corgi if regulators are enabled: ads7846 spi1.0: unable to get regulator: -517 spi spi1.0: Driver ads7846 requests probe deferral wm8731 0-001b: Failed to get supply 'AVDD': -517 wm8731 0-001b: Failed to request supplies: -517 wm8731 0-001b: ASoC: failed to probe component -517 corgi-audio corgi-audio: ASoC: failed to instantiate card -517 Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Nicolas Pitre	612242425b	vt: provide notifications on selection changes commit `19e3ae6b4f` upstream. The vcs device's poll/fasync support relies on the vt notifier to signal changes to the screen content. Notifier invocations were missing for changes that comes through the selection interface though. Fix that. Tested with BRLTTY 5.2. Signed-off-by: Nicolas Pitre <nico@linaro.org> Cc: Dave Mielke <dave@mielke.cc> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Alan Stern	4e5b83d8e8	USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd) commit `074f9dd55f` upstream. Currently the USB stack assumes that all host controller drivers are capable of receiving wakeup requests from downstream devices. However, this isn't true for the isp1760-hcd driver, which means that it isn't safe to do a runtime suspend of any device attached to a root-hub port if the device requires wakeup. This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure and sets the flag in isp1760-hcd. The core is modified to prevent a direct child of the root hub from being put into runtime suspend with wakeup enabled if the flag is set. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Alan Stern	76730c9fb3	USB: don't cancel queued resets when unbinding drivers commit `524134d422` upstream. The USB stack provides a mechanism for drivers to request an asynchronous device reset (usb_queue_reset_device()). The mechanism uses a work item (reset_ws) embedded in the usb_interface structure used by the driver, and the reset is carried out by a work queue routine. The asynchronous reset can race with driver unbinding. When this happens, we try to cancel the queued reset before unbinding the driver, on the theory that the driver won't care about any resets once it is unbound. However, thanks to the fact that lockdep now tracks work queue accesses, this can provoke a lockdep warning in situations where the device reset causes another interface's driver to be unbound; see http://marc.info/?l=linux-usb&m=141893165203776&w=2 for an example. The reason is that the work routine for reset_ws in one interface calls cancel_queued_work() for the reset_ws in another interface. Lockdep thinks this might lead to a work routine trying to cancel itself. The simplest solution is not to cancel queued resets when unbinding drivers. This means we now need to acquire a reference to the usb_interface when queuing a reset_ws work item and to drop the reference when the work routine finishes. We also need to make sure that the usb_interface structure doesn't outlive its parent usb_device; this means acquiring and dropping a reference when the interface is created and destroyed. In addition, cancelling a queued reset can fail (if the device is in the middle of an earlier reset), and this can cause usb_reset_device() to try to rebind an interface that has been deallocated (see http://marc.info/?l=linux-usb&m=142175717016628&w=2 for details). Acquiring the extra references prevents this failure. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk> Reported-by: Olivier Sobrie <olivier@sobrie.be> Tested-by: Olivier Sobrie <olivier@sobrie.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Sebastian Andrzej Siewior	482b4b7132	usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN commit `5efd2ea8c9` upstream. the following error pops up during "testusb -a -t 10" \| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad dma) hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in hcd_buffer_alloc() returning memory which is 32 bytes aligned and it might by identified by buffer_offset() as another buffer. This means the buffer which is on a 32 byte boundary will not get freed, instead it tries to free another buffer with the error message. This patch fixes the issue by creating the smallest DMA buffer with the size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is smaller). This might be 32, 64 or even 128 bytes. The next three pools will have the size 128, 512 and 2048. In case the smallest pool is 128 bytes then we have only three pools instead of four (and zero the first entry in the array). The last pool size is always 2048 bytes which is the assumed PAGE_SIZE / 2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where we would end up with 8KiB buffer in case we have 16KiB pages. Instead I think it makes sense to have a common size(s) and extend them if there is need to. There is a BUILD_BUG_ON() now in case someone has a minalign of more than 128 bytes. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Alan Stern	7a0c5e1279	USB: fix use-after-free bug in usb_hcd_unlink_urb() commit `c99197902d` upstream. The usb_hcd_unlink_urb() routine in hcd.c contains two possible use-after-free errors. The dev_dbg() statement at the end of the routine dereferences urb and urb->dev even though both structures may have been deallocated. This patch fixes the problem by storing urb->dev in a local variable (avoiding the dereference of urb) and moving the dev_dbg() up before the usb_put_dev() call. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Joe Lawrence <joe.lawrence@stratus.com> Tested-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Lennart Sorensen	c865d81da7	USB: cp210x: add ID for RUGGEDCOM USB Serial Console commit `a6f0331236` upstream. Added the USB serial console device ID for Siemens Ruggedcom devices which have a USB port for their serial console. Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:53:00 -08:00
Alexander Usyskin	986718d908	mei: me: release hw from reset only during the reset flow commit `663b7ee951` upstream. We might enter the interrupt handler with hw_ready already set, but prior we actually started the reset flow. To soleve this we move the reset release from the interrupt handler to the HW start wait function which is part of the reset sequence. 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>	2015-03-06 14:53:00 -08:00
Alexander Usyskin	c27fd6eed4	mei: mask interrupt set bit on clean reset bit commit `1ab1e79b9f` upstream. We should mask interrupt set bit when writing back hcsr value in reset bit clean-up. This is refinement for mei: clean reset bit before reset commit `b13a65ef19` 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>	2015-03-06 14:52:59 -08:00
Cyrille Pitchen	7e4f91b4d0	tty/serial: at91: fix error handling in atmel_serial_probe() commit `6fbb9bdf0f` upstream. -EDEFER error wasn't handle properly by atmel_serial_probe(). As an example, when atmel_serial_probe() is called for the first time, we pass the test_and_set_bit() test to check whether the port has already been initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly returned before by clk_get(). Consequently atmel_serial_probe() used to return this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask. When atmel_serial_probe() was called for the second time, it used to fail on the test_and_set_bit() function then returning -EBUSY. When atmel_serial_probe() fails, this patch make it clear the port bit in the "atmel_ports_in_use" mask, if needed, before returning the error code. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Peter Hurley	07ed07acc2	tty: Prevent untrappable signals from malicious program commit `37480a0568` upstream. Commit `26df6d1340` ("tty: Add EXTPROC support for LINEMODE") allows a process which has opened a pty master to send _any_ signal to the process group of the pty slave. Although potentially exploitable by a malicious program running a setuid program on a pty slave, it's unknown if this exploit currently exists. Limit to signals actually used. Cc: Theodore Ts'o <tytso@mit.edu> Cc: Howard Chu <hyc@symas.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Matthew Wilcox	532f6e6ffd	axonram: Fix bug in direct_access commit `91117a2024` upstream. The 'pfn' returned by axonram was completely bogus, and has been since 2008. Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Andrey Ryabinin	3ddf67db2e	smack: fix possible use after frees in task_security() callers commit `6d1cff2a88` upstream. We hit use after free on dereferncing pointer to task_smack struct in smk_of_task() called from smack_task_to_inode(). task_security() macro uses task_cred_xxx() to get pointer to the task_smack. task_cred_xxx() could be used only for non-pointer members of task's credentials. It cannot be used for pointer members since what they point to may disapper after dropping RCU read lock. Mainly task_security() used this way: smk_of_task(task_security(p)) Intead of this introduce function smk_of_task_struct() which takes task_struct as argument and returns pointer to smk_known struct and do this under RCU read lock. Bogus task_security() macro is not used anymore, so remove it. KASan's report for this: AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600 ============================================================================= BUG kmalloc-64 (Tainted: PO): kasan error ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866 kmem_cache_alloc_trace+0x88/0x1bc new_task_smack+0x44/0xd8 smack_cred_prepare+0x48/0x21c security_prepare_creds+0x44/0x4c prepare_creds+0xdc/0x110 smack_setprocattr+0x104/0x150 security_setprocattr+0x4c/0x54 proc_pid_attr_write+0x12c/0x194 vfs_write+0x1b0/0x370 SyS_write+0x5c/0x94 ret_fast_syscall+0x0/0x48 INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564 kfree+0x270/0x290 smack_cred_free+0xc4/0xd0 security_cred_free+0x34/0x3c put_cred_rcu+0x58/0xcc rcu_process_callbacks+0x738/0x998 __do_softirq+0x264/0x4cc do_softirq+0x94/0xf4 irq_exit+0xbc/0x120 handle_IRQ+0x104/0x134 gic_handle_irq+0x70/0xac __irq_svc+0x44/0x78 _raw_spin_unlock+0x18/0x48 sync_inodes_sb+0x17c/0x1d8 sync_filesystem+0xac/0xfc vdfs_file_fsync+0x90/0xc0 vfs_fsync_range+0x74/0x7c INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080 INFO: Object 0xc4635600 @offset=5632 fp=0x (null) Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. Redzone c4635640: bb bb bb bb .... Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1 Backtrace: [<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24) r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140 [<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28) [<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144) [<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44) r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600 [<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538) r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7 [<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8) [<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70) r5:c4635600 r4:ca9da000 [<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44) r5:cca25e80 r4:c0ba9780 [<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178) r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124 [<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4) r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148 [<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108) [<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648) [<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88) [<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198) r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000 [<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34) [<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48) Read of size 4 by thread T834: Memory state around the buggy address: c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Steven Rostedt (Red Hat)	49c1bf0c2c	ring-buffer: Do not wake up a splice waiter when page is not full commit `1e0d6714ac` upstream. When an application connects to the ring buffer via splice, it can only read full pages. Splice does not work with partial pages. If there is not enough data to fill a page, the splice command will either block or return -EAGAIN (if set to nonblock). Code was added where if the page is not full, to just sleep again. The problem is, it will get woken up again on the next event. That is, when something is written into the ring buffer, if there is a waiter it will wake it up. The waiter would then check the buffer, see that it still does not have enough data to fill a page and go back to sleep. To make matters worse, when the waiter goes back to sleep, it could cause another event, which would wake it back up again to see it doesn't have enough data and sleep again. This produces a tremendous overhead and fills the ring buffer with noise. For example, recording sched_switch on an idle system for 10 seconds produces 25,350,475 events!!! Create another wait queue for those waiters wanting full pages. When an event is written, it only wakes up waiters if there's a full page of data. It does not wake up the waiter if the page is not yet full. After this change, recording sched_switch on an idle system for 10 seconds produces only 800 events. Getting rid of 25,349,675 useless events (99.9969% of events!!), is something to take seriously. Cc: Rabin Vincent <rabin@rab.in> Fixes: `e30f53aad2` "tracing: Do not busy wait in buffer splice" Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Paul Moore	e5b55e1b09	cipso: don't use IPCB() to locate the CIPSO IP option commit `04f81f0154` upstream. Using the IPCB() macro to get the IPv4 options is convenient, but unfortunately NetLabel often needs to examine the CIPSO option outside of the scope of the IP layer in the stack. While historically IPCB() worked above the IP layer, due to the inclusion of the inet_skb_param struct at the head of the {tcp,udp}_skb_cb structs, recent commit `971f10ec` ("tcp: better TCP_SKB_CB layout to reduce cache line misses") reordered the tcp_skb_cb struct and invalidated this IPCB() trick. This patch fixes the problem by creating a new function, cipso_v4_optptr(), which locates the CIPSO option inside the IP header without calling IPCB(). Unfortunately, this isn't as fast as a simple lookup so some additional tweaks were made to limit the use of this new function. Reported-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <pmoore@redhat.com> Tested-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Jeff Moyer	4a07d7db39	cfq-iosched: fix incorrect filing of rt async cfqq commit `c6ce194325` upstream. Hi, If you can manage to submit an async write as the first async I/O from the context of a process with realtime scheduling priority, then a cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It ends up in the best effort array, but actually has realtime I/O scheduling priority set in cfqq->ioprio. The reason is that cfq_get_queue assumes the default scheduling class and priority when there is no information present (i.e. when the async cfqq is created): static struct cfq_queue * cfq_get_queue(struct cfq_data cfqd, bool is_sync, struct cfq_io_cq cic, struct bio bio, gfp_t gfp_mask) { const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio); const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio); cic->ioprio starts out as 0, which is "invalid". So, class of 0 (IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so: async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio); static struct cfq_queue * cfq_async_queue_prio(struct cfq_data cfqd, int ioprio_class, int ioprio) { switch (ioprio_class) { case IOPRIO_CLASS_RT: return &cfqd->async_cfqq[0][ioprio]; case IOPRIO_CLASS_NONE: ioprio = IOPRIO_NORM; / fall through / case IOPRIO_CLASS_BE: return &cfqd->async_cfqq[1][ioprio]; case IOPRIO_CLASS_IDLE: return &cfqd->async_idle_cfqq; default: BUG(); } } Here, instead of returning a class mapped from the process' scheduling priority, we get back the bucket associated with IOPRIO_CLASS_BE. Now, there is no queue allocated there yet, so we create it: cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask); That function ends up doing this: cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync); cfq_init_prio_data(cfqq, cic); cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio data does this: ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio); switch (ioprio_class) { default: printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class); case IOPRIO_CLASS_NONE: / * no prio set, inherit CPU scheduling settings */ cfqq->ioprio = task_nice_ioprio(tsk); cfqq->ioprio_class = task_nice_ioclass(tsk); break; So we basically have two code paths that treat IOPRIO_CLASS_NONE differently, which results in an RT async cfqq filed into a best effort bucket. Attached is a patch which fixes the problem. I'm not sure how to make it cleaner. Suggestions would be welcome. Signed-off-by: Jeff Moyer <jmoyer@redhat.com> Tested-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Konstantin Khlebnikov	e83be4d104	cfq-iosched: handle failure of cfq group allocation commit `69abaffec7` upstream. Cfq_lookup_create_cfqg() allocates struct blkcg_gq using GFP_ATOMIC. In cfq_find_alloc_queue() possible allocation failure is not handled. As a result kernel oopses on NULL pointer dereference when cfq_link_cfqq_cfqg() calls cfqg_get() for NULL pointer. Bug was introduced in v3.5 in commit `cd1604fab4` ("blkcg: factor out blkio_group creation"). Prior to that commit cfq group lookup had returned pointer to root group as fallback. This patch handles this error using existing fallback oom_cfqq. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Vivek Goyal <vgoyal@redhat.com> Fixes: `cd1604fab4` ("blkcg: factor out blkio_group creation") Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Nicholas Bellinger	e78f848979	iscsi-target: Drop problematic active_ts_list usage commit `3fd7b60f2c` upstream. This patch drops legacy active_ts_list usage within iscsi_target_tq.c code. It was originally used to track the active thread sets during iscsi-target shutdown, and is no longer used by modern upstream code. Two people have reported list corruption using traditional iscsi-target and iser-target with the following backtrace, that appears to be related to iscsi_thread_set->ts_list being used across both active_ts_list and inactive_ts_list. [ 60.782534] ------------[ cut here ]------------ [ 60.782543] WARNING: CPU: 0 PID: 9430 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() [ 60.782545] list_del corruption, ffff88045b00d180->next is LIST_POISON1 (dead000000100100) [ 60.782546] Modules linked in: ib_srpt tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt ib_isert rdma_cm iw_cm ib_addr iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib ib_sa ib_mad ib_core mlx4_core dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core sg i2c_i801 lpc_ich mfd_core mtip32xx igb i2c_algo_bit i2c_core ptp pps_core ioatdma dca wmi ext3(F) jbd(F) mbcache(F) sd_mod(F) crc_t10dif(F) crct10dif_common(F) ahci(F) libahci(F) isci(F) libsas(F) scsi_transport_sas(F) [last unloaded: speedstep_lib] [ 60.782597] CPU: 0 PID: 9430 Comm: iscsi_ttx Tainted: GF 3.12.19+ #2 [ 60.782598] Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013 [ 60.782599] 0000000000000035 ffff88044de31d08 ffffffff81553ae7 0000000000000035 [ 60.782602] ffff88044de31d58 ffff88044de31d48 ffffffff8104d1cc 0000000000000002 [ 60.782605] ffff88045b00d180 ffff88045b00d0c0 ffff88045b00d0c0 ffff88044de31e58 [ 60.782607] Call Trace: [ 60.782611] [<ffffffff81553ae7>] dump_stack+0x49/0x62 [ 60.782615] [<ffffffff8104d1cc>] warn_slowpath_common+0x8c/0xc0 [ 60.782618] [<ffffffff8104d2b6>] warn_slowpath_fmt+0x46/0x50 [ 60.782620] [<ffffffff81280933>] __list_del_entry+0x63/0xd0 [ 60.782622] [<ffffffff812809b1>] list_del+0x11/0x40 [ 60.782630] [<ffffffffa06e7cf9>] iscsi_del_ts_from_active_list+0x29/0x50 [iscsi_target_mod] [ 60.782635] [<ffffffffa06e87b1>] iscsi_tx_thread_pre_handler+0xa1/0x180 [iscsi_target_mod] [ 60.782642] [<ffffffffa06fb9ae>] iscsi_target_tx_thread+0x4e/0x220 [iscsi_target_mod] [ 60.782647] [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod] [ 60.782652] [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod] [ 60.782655] [<ffffffff8106f99e>] kthread+0xce/0xe0 [ 60.782657] [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70 [ 60.782660] [<ffffffff8156026c>] ret_from_fork+0x7c/0xb0 [ 60.782662] [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70 [ 60.782663] ---[ end trace 9662f4a661d33965 ]--- Since this code is no longer used, go ahead and drop the problematic usage all-together. Reported-by: Gavin Guo <gavin.guo@canonical.com> Reported-by: Moussa Ba <moussaba@micron.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Tony Battersby	fe34c4e5d4	sg: fix EWOULDBLOCK errors with scsi-mq commit `7772855a99` upstream. With scsi-mq enabled, userspace programs can get unexpected EWOULDBLOCK (a.k.a. EAGAIN) errors when submitting commands to the SCSI generic driver. Fix by calling blk_get_request() with GFP_KERNEL instead of GFP_ATOMIC. Note: to avoid introducing a potential deadlock, this patch should be applied after the patch titled "sg: fix unkillable I/O wait deadlock with scsi-mq". Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Tested-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Tony Battersby	ba48f249ae	sg: fix unkillable I/O wait deadlock with scsi-mq commit `7568615c10` upstream. When using the write()/read() interface for submitting commands, the SCSI generic driver does not call blk_put_request() on a completed SCSI command until userspace calls read() to get the command completion. Since scsi-mq uses a fixed number of preallocated requests, this makes it possible for userspace to exhaust the entire preallocated supply of requests. For places in the kernel that call blk_get_request() with GFP_KERNEL, this can cause the calling process to deadlock in a permanent unkillable I/O wait in blk_get_request() -> ... -> bt_get(). For places in the kernel that call blk_get_request() with GFP_ATOMIC, this can cause blk_get_request() always to return -EWOULDBLOCK. Note that these problems happen only if scsi-mq is enabled. Prevent the problems by calling blk_put_request() as soon as the SCSI command completes instead of waiting for userspace to call read(). Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Tested-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:59 -08:00
Trond Myklebust	70bcf9f418	NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args commit `d8ba1f9714` upstream. If the call to decode_rc_list() fails due to a memory allocation error, then we need to truncate the array size to ensure that we only call kfree() on those pointer that were allocated. Reported-by: David Ramos <daramos@stanford.edu> Fixes: `4aece6a19c` ("nfs41: cb_sequence xdr implementation") Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:58 -08:00
Trond Myklebust	7952f4999f	NFSv4: Ensure we reference the inode for return-on-close in delegreturn commit `ea7c38fef0` upstream. If we have to do a return-on-close in the delegreturn code, then we must ensure that the inode and super block remain referenced. Cc: Peng Tao <tao.peng@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Reviewed-by: Peng Tao <tao.peng@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:58 -08:00
Trond Myklebust	bcc9c506f2	SUNRPC: NULL utsname dereference on NFS umount during namespace cleanup commit `03a9a42a1a` upstream. Fix an Oopsable condition when nsm_mon_unmon is called as part of the namespace cleanup, which now apparently happens after the utsname has been freed. Link: http://lkml.kernel.org/r/20150125220604.090121ae@neptune.home Reported-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:58 -08:00
Peng Tao	08be8f079c	nfs41: .init_read and .init_write can be called with valid pg_lseg commit `cb5d04bc39` upstream. With pgio refactoring in v3.15, .init_read and .init_write can be called with valid pgio->pg_lseg. file layout was fixed at that time by commit `c6194271f` (pnfs: filelayout: support non page aligned layouts). But the generic helper still needs to be fixed. Signed-off-by: Peng Tao <tao.peng@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:58 -08:00
honclo	052f8db44c	Added Little Endian support to vtpm module commit `eb71f8a5e3` upstream. The tpm_ibmvtpm module is affected by an unaligned access problem. ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is enabled in Power partition, which supports both little endian and big endian modes. We added little endian support to fix this problem: 1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS. 2) added be16_to_cpu and be32_to_cpu calls to make sure data received is in LE format on a LE OS. Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com> Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com> [phuewe: manually applied the patch :( ] Reviewed-by: Ashley Lai <ashley@ahsleylai.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:58 -08:00
Christophe Ricard	4243c6c895	tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send commit `1ba3b0b6f2` upstream. When sending data in tpm_stm_i2c_send, each loop iteration send buf. Send buf + i instead as the goal of this for loop is to send a number of byte from buf that fit in burstcnt. Once those byte are sent, we are supposed to send the next ones. The driver was working because the burstcount value returns always the maximum size for a TPM command or response. (0x800 for a command and 0x400 for a response). Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:57 -08:00
Hon Ching (Vicky) Lo	2a7a2065ba	tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma commit `84eb186bc3` upstream. There was an oops in tpm_ibmvtpm_get_desired_dma, which caused kernel panic during boot when vTPM is enabled in Power partition configured in AMS mode. vio_bus_probe calls vio_cmo_bus_probe which calls tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation. The problem is, vio_cmo_bus_probe is called before calling probe, which for vtpm is tpm_ibmvtpm_probe and it's this function that initializes and sets up vtpm's CRQ and gets required data values. Therefore, since this has not yet been done, NULL is returned in attempt to get the size for DMA allocation. We added a NULL check. In addition, a default buffer size will be set when NULL is returned. Signed-off-by: Hon Ching (Vicky) Lo <honclo@linux.vnet.ibm.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:57 -08:00
Kiran Padwal	73da074217	char: tpm: Add missing error check for devm_kzalloc commit `bb95cd34ba` upstream. Currently these driver are missing a check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com> Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:57 -08:00
David Howells	2bce1b5b27	TPM: Add new TPMs to the tail of the list to prevent inadvertent change of dev commit `398a1e71dc` upstream. Add newly registered TPMs to the tail of the list, not the beginning, so that things that are specifying TPM_ANY_NUM don't find that the device they're using has inadvertently changed. Adding a second device would break IMA, for instance. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:57 -08:00
Scot Doyle	675643b21a	tpm_tis: verify interrupt during init commit `448e9c55c1` upstream. Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do not send IRQs while also having an ACPI TPM entry indicating that they will be sent. These machines freeze on resume while the tpm_tis module waits for an IRQ, eventually timing out. When in interrupt mode, the tpm_tis module should receive an IRQ during module init. Fall back to polling mode if none is received when expected. Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> Tested-by: Michael Mullin <masmullin@gmail.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> [phuewe: minor checkpatch fixed] Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:57 -08:00
Florian Fainelli	c8fc365395	ARM: dts: BCM63xx: fix L2 cache properties commit `9df11828d9` upstream. The L2 cache properties were completely off with respect to what the hardware is configured for. Fix the cache-size, cache-line-size and cache-sets to reflect the L2 cache controller we have: 512KB, 16 ways and 32 bytes per cache-line. Fixes: `46d4bca044` ("ARM: BCM63XX: add BCM63138 minimal Device Tree") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Robert Nelson	0eb370c67b	ARM: dts: am335x-bone*: usb0 is hardwired for peripheral commit `67fd14b3ec` upstream. Fixes: http://bugs.elinux.org/issues/127 the bb.org community was seeing random reboots before this change. Signed-off-by: Robert Nelson <robertcnelson@gmail.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Dmitry Osipenko	120cd1125b	ARM: dts: tegra20: fix GR3D, DSI unit and reg base addresses commit `de47699d00` upstream. Commit `58ecb23f64` ("ARM: tegra: add missing unit addresses to DT") added unit address and changed reg base for GR3D and DSI host1x modules, but these addresses belongs to GR2D and TVO modules respectively. Fix it by changing modules unit and reg base addresses to proper ones. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Fixes: `58ecb23f64` (ARM: tegra: add missing unit addresses to DT) Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Lokesh Vutla	11cfd8b580	ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 commit `1c7e36bfc3` upstream. With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS. On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on BeagleBoard-X15, where we use UART3 for console, boot fails with DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod. For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig. Fixes: `90020c7b2c` ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data") Reviewed-by: Felipe Balbi <balbi@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Dmitry Eremin-Solenikov	d53ecbb367	ARM: 8284/1: sa1100: clear RCSR_SMR on resume commit `e461894dc2` upstream. StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset by entering the sleep mode. After we have resumed, there is little point in having that bit enabled. Moreover, if this bit is set before reboot, the bootloader can become confused. Thus clear the SMR bit on resume just before clearing the scratchpad (resume address) register. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Tony Battersby	7da36aa363	blk-mq: fix double-free in error path commit `564e559f2b` upstream. If the allocation of bt->bs fails, then bt->map can be freed twice, once in blk_mq_init_bitmap_tags() -> bt_alloc(), and once in blk_mq_init_bitmap_tags() -> bt_free(). Fix by setting the pointer to NULL after the first free. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:56 -08:00
Vikram Mulukutla	d2c8636c46	tracing: Fix unmapping loop in tracing_mark_write commit `7215853e98` upstream. Commit `6edb2a8a38` introduced an array map_pages that contains the addresses returned by kmap_atomic. However, when unmapping those pages, map_pages[0] is unmapped before map_pages[1], breaking the nesting requirement as specified in the documentation for kmap_atomic/kunmap_atomic. This was caught by the highmem debug code present in kunmap_atomic. Fix the loop to do the unmapping properly. Link: http://lkml.kernel.org/r/1418871056-6614-1-git-send-email-markivx@codeaurora.org Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Reported-by: Lime Yang <limey@codeaurora.org> Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:55 -08:00
Naoya Horiguchi	bebc511a44	mm/hugetlb: pmd_huge() returns true for non-present hugepage commit `cbef8478be` upstream. Migrating hugepages and hwpoisoned hugepages are considered as non-present hugepages, and they are referenced via migration entries and hwpoison entries in their page table slots. This behavior causes race condition because pmd_huge() doesn't tell non-huge pages from migrating/hwpoisoned hugepages. follow_page_mask() is one example where the kernel would call follow_page_pte() for such hugepage while this function is supposed to handle only normal pages. To avoid this, this patch makes pmd_huge() return true when pmd_none() is true and pmd_present() is false. We don't have to worry about mixing up non-present pmd entry with normal pmd (pointing to leaf level pte entry) because pmd_present() is true in normal pmd. The same race condition could happen in (x86-specific) gup_pmd_range(), where this patch simply adds pmd_present() check instead of pmd_huge(). This is because gup_pmd_range() is fast path. If we have non-present hugepage in this function, we will go into gup_huge_pmd(), then return 0 at flag mask check, and finally fall back to the slow path. Fixes: `290408d4a2` ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Rientjes <rientjes@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:55 -08:00
James Hogan	aa07e8092f	MIPS: Export MSA functions used by lose_fpu(1) for KVM commit `ca5d25642e` upstream. Export the _save_msa asm function used by the lose_fpu(1) macro to GPL modules so that KVM can make use of it when it is built as a module. This fixes the following build error when CONFIG_KVM=m and CONFIG_CPU_HAS_MSA=y due to commit `f798217dfd` ("KVM: MIPS: Don't leak FPU/DSP to guest"): ERROR: "_save_msa" [arch/mips/kvm/kvm.ko] undefined! Fixes: `f798217dfd` (KVM: MIPS: Don't leak FPU/DSP to guest) Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9261/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:55 -08:00
James Hogan	b91d95f9ce	MIPS: Export FP functions used by lose_fpu(1) for KVM commit `3ce465e04b` upstream. Export the _save_fp asm function used by the lose_fpu(1) macro to GPL modules so that KVM can make use of it when it is built as a module. This fixes the following build error when CONFIG_KVM=m due to commit `f798217dfd` ("KVM: MIPS: Don't leak FPU/DSP to guest"): ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined! Signed-off-by: James Hogan <james.hogan@imgtec.com> Fixes: `f798217dfd` (KVM: MIPS: Don't leak FPU/DSP to guest) Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9260/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:55 -08:00
Markos Chandras	e3201ff0ee	MIPS: asm: pgtable: Prevent HTW race when updating PTEs commit `fde3538a8a` upstream. Whenever we modify a page table entry, we need to ensure that the HTW will not fetch a stable entry. And for that to happen we need to ensure that HTW is stopped before we modify the said entry otherwise the HTW may already be in the process of reading that entry and fetching the old information. As a result of which, we replace the htw_reset() calls with htw_{stop,start} in more appropriate places. This also removes the remaining users of htw_reset() and as a result we drop that macro Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9116/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:55 -08:00
Markos Chandras	6ce23db8e9	MIPS: asm: pgtable: Add c0 hazards on HTW start/stop sequences commit `461d1597ff` upstream. When we use htw_{start,stop}() outside of htw_reset(), we need to ensure that c0 changes have been propagated properly before we attempt to continue with subsequence memory operations. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9114/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:54 -08:00
Markos Chandras	ef20dc5df0	MIPS: asm: asmmacro: Replace "add" instructions with "addu" commit `98a833c1fa` upstream. The "add" instruction is actually a macro in binutils and depending on the size of the immediate it can expand to an "addi" instruction. However, the "addi" instruction traps on overflows which is not something we want on address calculation. Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00121.html Cc: Paul Burton <paul.burton@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:54 -08:00
Markos Chandras	2aac25e44d	MIPS: kernel: cps-vec: Replace "addi" with "addiu" commit `acac4108df` upstream. The "addi" instruction will trap on overflows which is not something we need in this code, so we replace that with "addiu". Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00430.html Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:54 -08:00
Manuel Lauss	6a5f2ac063	MIPS: Alchemy: Fix cpu clock calculation commit `69e4e63ec8` upstream. The current code uses bits 0-6 of the sys_cpupll register to calculate core clock speed. However this is only valid on Au1300, on all earlier models the hardware only uses bits 0-5 to generate core clock. This fixes clock calculation on the MTX1 (Au1500), where bit 6 of cpupll is set as well, which ultimately lead the code to calculate a bogus cpu core clock and also uart base clock down the line. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Reported-by: John Crispin <blogic@openwrt.org> Tested-by: Bruno Randolf <br1@einfach.org> Cc: Linux-MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/9279/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:54 -08:00
James Hogan	22d0e08a28	KVM: MIPS: Don't leak FPU/DSP to guest commit `f798217dfd` upstream. The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by kvm_mips_set_c0_status() on a guest exit, presumably in case there is active state that needs saving if pre-emption occurs. However neither of these bits are cleared again when returning to the guest. This effectively gives the guest access to the FPU/DSP hardware after the first guest exit even though it is not aware of its presence, allowing FP instructions in guest user code to intermittently actually execute instead of trapping into the guest OS for emulation. It will then read & manipulate the hardware FP registers which technically belong to the user process (e.g. QEMU), or are stale from another user process. It can also crash the guest OS by causing an FP exception, for which a guest exception handler won't have been registered. First lets save and disable the FPU (and MSA) state with lose_fpu(1) before entering the guest. This simplifies the problem, especially for when guest FPU/MSA support is added in the future, and prevents FR=1 FPU state being live when the FR bit gets cleared for the guest, which according to the architecture causes the contents of the FPU and vector registers to become UNPREDICTABLE. We can then safely remove the enabling of the FPU in kvm_mips_set_c0_status(), since there should never be any active FPU or MSA state to save at pre-emption, which should plug the FPU leak. DSP state is always live rather than being lazily restored, so for that it is simpler to just clear the MX bit again when re-entering the guest. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Sanjay Lal <sanjayl@kymasys.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:54 -08:00
James Hogan	ceab52b508	KVM: MIPS: Disable HTW while in guest commit `c4c6f2cad9` upstream. Ensure any hardware page table walker (HTW) is disabled while in KVM guest mode, as KVM doesn't yet set up hardware page table walking for guest mappings so the wrong mappings would get loaded, resulting in the guest hanging or crashing once it reaches userland. The HTW is disabled and re-enabled around the call to __kvm_mips_vcpu_run() which does the initial switch into guest mode and the final switch out of guest context. Additionally it is enabled for the duration of guest exits (i.e. kvm_mips_handle_exit()), getting disabled again before returning back to guest or host. In all cases the HTW is only disabled in normal kernel mode while interrupts are disabled, so that the HTW doesn't get left disabled if the process is preempted. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:53 -08:00
Trond Myklebust	4a73309b58	NFS: struct nfs_commit_info.lock must always point to inode->i_lock commit `f4086a3d78` upstream. Commit `411a99adff` (nfs: clear_request_commit while holding i_lock) assumes that the nfs_commit_info always points to the inode->i_lock. For historical reasons, that is not the case for O_DIRECT writes. Cc: Weston Andros Adamson <dros@primarydata.com> Fixes: `411a99adff` ("nfs: clear_request_commit while holding i_lock") Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:53 -08:00
Jeff Layton	e616478fae	nfs: don't call blocking operations while !TASK_RUNNING commit `6ffa30d3f7` upstream. Bruce reported seeing this warning pop when mounting using v4.1: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0() do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810ff58f>] prepare_to_wait+0x2f/0x90 Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014 0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78 0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000 Call Trace: [<ffffffff8186ac78>] dump_stack+0x4c/0x65 [<ffffffff810ac9da>] warn_slowpath_common+0x8a/0xc0 [<ffffffff810aca65>] warn_slowpath_fmt+0x55/0x70 [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90 [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90 [<ffffffff810dd2ad>] __might_sleep+0xbd/0xd0 [<ffffffff8124c973>] kmem_cache_alloc_trace+0x243/0x430 [<ffffffff810d941e>] ? groups_alloc+0x3e/0x130 [<ffffffff810d941e>] groups_alloc+0x3e/0x130 [<ffffffffa0301b1e>] svcauth_unix_accept+0x16e/0x290 [sunrpc] [<ffffffffa0300571>] svc_authenticate+0xe1/0xf0 [sunrpc] [<ffffffffa02fc564>] svc_process_common+0x244/0x6a0 [sunrpc] [<ffffffffa02fd044>] bc_svc_process+0x1c4/0x260 [sunrpc] [<ffffffffa03d5478>] nfs41_callback_svc+0x128/0x1f0 [nfsv4] [<ffffffff810ff970>] ? wait_woken+0xc0/0xc0 [<ffffffffa03d5350>] ? nfs4_callback_svc+0x60/0x60 [nfsv4] [<ffffffff810d45bf>] kthread+0x11f/0x140 [<ffffffff810ea815>] ? local_clock+0x15/0x30 [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250 [<ffffffff81874bfc>] ret_from_fork+0x7c/0xb0 [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250 ---[ end trace 675220a11e30f4f2 ]--- nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE, which is just wrong. Fix that by finishing the wait immediately if we've found that the list has something on it. Also, we don't expect this kthread to accept signals, so we should be using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up hung task warnings from the watchdog, so have the schedule_timeout wake up every 60s if there's no callback activity. Reported-by: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:53 -08:00
Konstantin Khlebnikov	c08ed348db	proc/pagemap: walk page tables under pte lock commit `05fbf357d9` upstream. Lockless access to pte in pagemap_pte_range() might race with page migration and trigger BUG_ON(!PageLocked()) in migration_entry_to_page(): CPU A (pagemap) CPU B (migration) lock_page() try_to_unmap(page, TTU_MIGRATION...) make_migration_entry() set_pte_at() <read *pte> pte_to_pagemap_entry() remove_migration_ptes() unlock_page() if(is_migration_entry()) migration_entry_to_page() BUG_ON(!PageLocked(page)) Also lockless read might be non-atomic if pte is larger than wordsize. Other pte walkers (smaps, numa_maps, clear_refs) already lock ptes. Fixes: `052fb0d635` ("proc: report file/anon bit in /proc/pid/pagemap") Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Reported-by: Andrey Ryabinin <a.ryabinin@samsung.com> Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:53 -08:00
Marcin Wojtas	ac8623fa03	mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951 commit `a39128bcd6` upstream. According to erratum 'ERR-7878951' Armada 38x SDHCI controller has different capabilities than the ones shown in its registers: - it doesn't support the voltage switching: it can work either with 3.3V or 1.8V supply - it doesn't support the SDR104 mode - SDR50 mode doesn't need tuning The SDHCI_QUIRK_MISSING_CAPS quirk is used for updating the capabilities accordingly. [gregory.clement@free-electrons.com: port from 3.10] Fixes: `5491ce3f79` ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller") Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:53 -08:00
Gregory CLEMENT	2bca6f804f	mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor commit `d4b803c559` upstream. According to erratum 'FE-2946959' both SDR50 and DDR50 modes require specific clock adjustments in SDIO3 Configuration register. However, this register was not part of the device tree binding. Even if the binding can (and will) be extended we still need handling the case where this register was not available. In this case we use the SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities. This commit is based on the work done by Marcin Wojtas<mw@semihalf.com> Fixes: `5491ce3f79` ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller") Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Jisheng Zhang	dd553502d8	mmc: sdhci-pxav3: fix setting of pdata->clk_delay_cycles commit `14460dbaf7` upstream. Current code checks "clk_delay_cycles > 0" to know whether the optional "mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't touch clk_delay_cycles if the property is not set. And type of clk_delay_cycles is u32, so we may always set pdata->clk_delay_cycles as a random value. This patch fix this problem by check the return value of of_property_read_u32() to know whether the optional clk-delay-cycles is set or not. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Jisheng Zhang	4d025d8000	mmc: sdhci-pxav3: fix unbalanced clock issues during probe commit `62cf983ad8` upstream. Commit `0dcaa2499b` ("sdhci-pxav3: Fix runtime PM initialization") tries to fix one hang issue caused by calling sdhci_add_host() on a suspended device. The fix enables the clock twice, once by clk_prepare_enable() and another by pm_runtime_get_sync(), meaning that the clock will never be gated at runtime PM suspend. I observed the power consumption regression on Marvell BG2Q SoCs. In fact, the fix is not correct. There still be a very small window during which a runtime suspend might somehow occur after pm_runtime_enable() but before pm_runtime_get_sync(). This patch fixes all of the two problems by just incrementing the usage counter before pm_runtime_enable(). It also adjust the order of disabling runtime pm and storing the usage count in the error path to handle clock gating properly. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Russell King	1229822836	em28xx-audio: fix missing newlines, again commit `fbaa48d185` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-audio. Fix these. Fixes: `6d746f91f2` ("[media] em28xx-audio: implement em28xx_ops: suspend/resume hooks") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Russell King	21bfc5a1c0	em28xx-dvb: fix missing newlines commit `a084c57fc1` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-dvb. Fix these. Fixes: `ca2b46dacb` ("[media] em28xx-dvb: implement em28xx_ops: suspend/resume hooks") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Russell King	5d2093b38d	em28xx-video: fix missing newlines commit `32e63f0368` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-video. Fix these. Fixes: `a61f68119a` ("[media] em28xx-video: implement em28xx_ops: suspend/resume hooks") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:52 -08:00
Russell King	b7bd0ea28e	em28xx-core: fix missing newlines commit `522adc7c1f` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-core. Fix these. Fixes: `9c669b7314` ("[media] em28xx: add suspend/resume to em28xx_ops") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
Russell King	058eb677dd	em28xx-audio: fix missing newlines commit `7818b0aab8` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-audio. Fix these. Fixes: `1b3fd2d342` ("[media] em28xx-audio: don't hardcode audio URB calculus") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
Russell King	3c17bf17bb	em28xx-input: fix missing newlines commit `ebfd59cf54` upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-input. Fix these. Fixes: `5025076aad` ("[media] em28xx-input: implement em28xx_ops: suspend/resume hooks") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
Russell King	d28003a11c	em28xx: ensure "closing" messages terminate with a newline commit `0418ca6073` upstream. The lockdep splat addressed in a previous commit revealed that at least one message in em28xx-input.c was missing a new line: em28178 #0: Closing input extensionINFO: trying to register non-static key. Further inspection shows several other messages also miss a new line. These will be fixed in a subsequent patch. Fixes: `aa929ad783` ("[media] em28xx: print a message at disconnect") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
Arnd Bergmann	33b2fb5f10	timberdale: do not select TIMB_DMA commit `244829226f` upstream. The timberdale media driver requires the use of the respective dma engine driver, but that may not be enabled, causing a Kconfig warning: warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct dependencies (DMADEVICES && MFD_TIMBERDALE) This fixes the dependency by removing the inappropriate 'select' statement and replacing it with a direct dependency on the drivers that provide the services this needs. Fixes: `7155043c2d` ("[media] enable COMPILE_TEST for media drivers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
James Hogan	7497d7d1b6	rc-main: Re-apply filter for no-op protocol change commit `983c5bd26b` upstream. Since commit `da6e162d6a` ("[media] rc-core: simplify sysfs code"), when the IR protocol is set using the sysfs interface to the same set of protocols that are already set, store_protocols() does not refresh the scancode filter with the new protocol, even if it has already called the change_protocol() callback successfully. This results in the filter being disabled in the hardware and not re-enabled until the filter is set again using sysfs. Fix in store_protocols() by still re-applying the filter whenever the change_protocol() driver callback succeeded. The problem can be reproduced with the img-ir driver by setting a filter, and then setting the protocol to the same protocol that is already set: $ echo nec > protocols $ echo 0xffff > filter_mask $ echo nec > protocols After this, messages which don't match the filter were still being received. Fixes: `da6e162d6a` ("[media] rc-core: simplify sysfs code") Reported-by: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:51 -08:00
Sumit.Saxena@avagotech.com	aedfcf14cd	megaraid_sas: disable interrupt_mask before enabling hardware interrupts commit `c2ced1719a` upstream. Update driver "mask_interrupts" before enable/disable hardware interrupt in order to avoid missing interrupts because of "mask_interrupts" still set to 1 and hardware interrupts are enabled. Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Sumit.Saxena@avagotech.com	138fb06e30	megaraid_sas: fix the problem of non-existing VD exposed to host commit `ab2f0608e1` upstream. This patch will address the issue of SCSI device created at OS level for non existing VD. ldTgtIdtoLd[] array has size 256 for Extended VD firmware and 128 for legacy firmware. Accessing indices beyond array size (OS will send TUR, INQUIRY.. commands upto device index 255), may return valid LD value and that particular SCSI command will be SUCCESS and creating SCSI device for non existing target(VD). For legacy firmware (64 VD firmware), invalidates LD (by setting LD value to 0xff) in LdTgtIdtoLd[] array for device index beyond 127, so that invalid LD(0xff) value should be returned beyond device index beyond 127. Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Sumit.Saxena@avagotech.com	45e9f5c026	megaraid_sas: endianness related bug fixes and code optimization commit `200aed582d` upstream. This patch addresses below issues: 1) Few endianness bug fixes. 2) Break the iteration after (MAX_LOGICAL_DRIVES_EXT - 1)), instead of MAX_LOGICAL_DRIVES_EXT. 3) Optimization in MFI INIT frame before firing. 4) MFI IO frame should be 256bytes aligned. Code is optimized to reduce the size of frame for fusion adapters and make the MFI frame size calculation a bit transparent and readable. Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Dmitry Eremin-Solenikov	c2d3b46d39	power: gpio-charger: balance enable/disable_irq_wake calls commit `faeed51bb6` upstream. enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to generate the wakeup event (and thus resume should call disable_irq_wake). Currently gpio-charger driver has this logic inverted. Correct that thus correcting enable/disable_irq_wake() calls balance. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Krzysztof Kozlowski	ff5405c750	power: bq24190: Fix ignored supplicants commit `478913fdbd` upstream. The driver mismatched 'num_supplicants' with 'num_supplies' of power_supply structure. It provided list of supplicants (power_supply.supplied_to) but did not set the number of supplicants. Instead it set the num_supplies which is used when iterating over number of supplies (power_supply.supplied_from). As a result the list of supplicants was ignored by core because its size was 0. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `d7bf353fd0` ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Krzysztof Kozlowski	cba19a2bc3	power_supply: 88pm860x: Fix leaked power supply on probe fail commit `24727b45b4` upstream. Driver forgot to unregister power supply if request_threaded_irq() failed in probe(). In such case the memory associated with power supply leaked. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `a830d28b48` ("power_supply: Enable battery-charger for 88pm860x") Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Adrian Knoth	b52ef41312	ALSA: hdspm - Constrain periods to 2 on older cards commit `f0153c3d94` upstream. RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period sizes of 32-4096, this translates to 4-512 periods. The older RME cards have a variable buffer size but require exactly two periods. This patch enforces nperiods=2 on those cards. Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Hui Wang	42596d7999	ALSA: hda - enable mute led quirk for one more hp machine. commit `7976eb49cb` upstream. Otherwise, the mute led can't work at all. Tested-by: Taihsiang Ho <taihsiang.ho@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1410704 Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Takashi Iwai	d82c3f5eab	ALSA: hda - Set up GPIO for Toshiba Satellite S50D commit `4227de2a7e` upstream. Toshiba Satellite S50D laptop with an IDT codec uses the GPIO4 (0x10) as the master EAPD. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=915858 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:50 -08:00
Dan Carpenter	72753a3d9c	ALSA: off by one bug in snd_riptide_joystick_probe() commit `e4940626de` upstream. The problem here is that we check: if (dev >= SNDRV_CARDS) Then we increment "dev". if (!joystick_port[dev++]) Then we use it as an offset into a array with SNDRV_CARDS elements. if (!request_region(joystick_port[dev], 8, "Riptide gameport")) { This has 3 effects: 1) If you use the module option to specify the joystick port then it has to be shifted one space over. 2) The wrong error message will be printed on failure if you have over 32 cards. 3) Static checkers will correctly complain that are off by one. Fixes: `db1005ec6f` ('ALSA: riptide - Fix joystick resource handling') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Antti Palosaari	74945cb5fd	si2168: define symbol rate limits commit `f1ecc5d119` upstream. w_scan complains about missing symbol rate limits: This dvb driver is buggy: the symbol rate limits are undefined - please report to linuxtv.org Chip supports 1 to 7.2 MSymbol/s on DVB-C. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Malcolm Priestley	c51d7f70f1	lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb commit `15e1ce3318` upstream. A quirk of some older firmwares that report endpoint pipe type as PIPE_BULK but the endpoint otheriwse functions as interrupt. Check if usb_endpoint_type is USB_ENDPOINT_XFER_BULK and set as usb_rcvbulkpipe. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Malcolm Priestley	e4d75d07cb	lmedm04: Increase Interupt due time to 200 msec commit `cfcd7b8258` upstream. Ocassionally the device fails to report back an interrupt urb status which results in false no lock trigger on the RS2000 demodulator. Increase time from 60 msecs to 200 msecs. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Mika Westerberg	7ee6733bfc	ACPI / LPSS: Deassert resets for SPI host controllers on Braswell commit `3095794ae9` upstream. On some Braswell systems BIOS leaves resets for SPI host controllers active. This prevents the SPI driver from transferring messages on wire. Fix this in similar way that we do for I2C already by deasserting resets for the SPI host controllers. Reported-by: Yang A Fang <yang.a.fang@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Mika Westerberg	86e8d6bf5f	ACPI / LPSS: Always disable I2C host controllers commit `3293c7b8ec` upstream. On Baytrail and Braswell the BIOS might leave the I2C host controllers enabled, probably because it uses them for its own purposes. This is fine in normal cases because the I2C driver will disable the hardware when it is probed anyway. However, in case of suspend to disk it is different story. If the driver happens to be compiled as a module the boot kernel never loads the driver thus leaving host controllers enabled upon loading the hibernation image. The I2C host controller interrupt mask register has default value of 0x8ff, in other words it has most of the interrupts unmasked. When combined with the fact that the host controller is enabled, the driver immediately starts getting interrupts even before its resume hook is called (once IO-APIC is resumed). Since the driver is not prepared for this it will crash the kernel due to NULL pointer derefence because dev->msgs is NULL. Unfortunately we were not able to get full backtrace to from the console which could be reproduced here. In order to fix this even when the driver is compiled as module, we disable the I2C host controllers in byt_i2c_setup() before devices are created. Reported-by: Yu Chen <yu.c.chen@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Juergen Gross	bf14e5189d	xen-scsiback: mark pvscsi frontend request consumed only after last read commit `facb5732b0` upstream. A request in the ring buffer mustn't be read after it has been marked as consumed. Otherwise it might already have been reused by the frontend without violating the ring protocol. To avoid inconsistencies in the backend only work on a private copy of the request. This will ensure a malicious guest not being able to bypass consistency checks of the backend by modifying an active request. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:49 -08:00
Ross Lagerwall	beb843e55e	xen/manage: Fix USB interaction issues when resuming commit `72978b2fe2` upstream. Commit `61a734d305` ("xen/manage: Always freeze/thaw processes when suspend/resuming") ensured that userspace processes were always frozen before suspending to reduce interaction issues when resuming devices. However, freeze_processes() does not freeze kernel threads. Freeze kernel threads as well to prevent deadlocks with the khubd thread when resuming devices. This is what native suspend and resume does. Example deadlock: [ 7279.648010] [<ffffffff81446bde>] ? xen_poll_irq_timeout+0x3e/0x50 [ 7279.648010] [<ffffffff81448d60>] xen_poll_irq+0x10/0x20 [ 7279.648010] [<ffffffff81011723>] xen_lock_spinning+0xb3/0x120 [ 7279.648010] [<ffffffff810115d1>] __raw_callee_save_xen_lock_spinning+0x11/0x20 [ 7279.648010] [<ffffffff815620b6>] ? usb_control_msg+0xe6/0x120 [ 7279.648010] [<ffffffff81747e50>] ? _raw_spin_lock_irq+0x50/0x60 [ 7279.648010] [<ffffffff8174522c>] wait_for_completion+0xac/0x160 [ 7279.648010] [<ffffffff8109c520>] ? try_to_wake_up+0x2c0/0x2c0 [ 7279.648010] [<ffffffff814b60f2>] dpm_wait+0x32/0x40 [ 7279.648010] [<ffffffff814b6eb0>] device_resume+0x90/0x210 [ 7279.648010] [<ffffffff814b7d71>] dpm_resume+0x121/0x250 [ 7279.648010] [<ffffffff8144c570>] ? xenbus_dev_request_and_reply+0xc0/0xc0 [ 7279.648010] [<ffffffff814b80d5>] dpm_resume_end+0x15/0x30 [ 7279.648010] [<ffffffff81449fba>] do_suspend+0x10a/0x200 [ 7279.648010] [<ffffffff8144a2f0>] ? xen_pre_suspend+0x20/0x20 [ 7279.648010] [<ffffffff8144a1d0>] shutdown_handler+0x120/0x150 [ 7279.648010] [<ffffffff8144c60f>] xenwatch_thread+0x9f/0x160 [ 7279.648010] [<ffffffff810ac510>] ? finish_wait+0x80/0x80 [ 7279.648010] [<ffffffff8108d189>] kthread+0xc9/0xe0 [ 7279.648010] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7279.648010] [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0 [ 7279.648010] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds. [ 7441.219457] Tainted: G X 3.13.11-ckt12.kz #1 [ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 7441.225827] khubd D ffff88003f433440 0 89 2 0x00000000 [ 7441.229258] ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440 [ 7441.232959] ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000 [ 7441.236658] 0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e [ 7441.240415] Call Trace: [ 7441.241614] [<ffffffff817442f9>] schedule+0x29/0x70 [ 7441.243930] [<ffffffff81743406>] schedule_timeout+0x166/0x2c0 [ 7441.246681] [<ffffffff81075b80>] ? call_timer_fn+0x110/0x110 [ 7441.249339] [<ffffffff8174357e>] schedule_timeout_uninterruptible+0x1e/0x20 [ 7441.252644] [<ffffffff81077710>] msleep+0x20/0x30 [ 7441.254812] [<ffffffff81555f00>] hub_port_reset+0xf0/0x580 [ 7441.257400] [<ffffffff81558465>] hub_port_init+0x75/0xb40 [ 7441.259981] [<ffffffff814bb3c9>] ? update_autosuspend+0x39/0x60 [ 7441.262817] [<ffffffff814bb4f0>] ? pm_runtime_set_autosuspend_delay+0x50/0xa0 [ 7441.266212] [<ffffffff8155a64a>] hub_thread+0x71a/0x1750 [ 7441.268728] [<ffffffff810ac510>] ? finish_wait+0x80/0x80 [ 7441.271272] [<ffffffff81559f30>] ? usb_port_resume+0x670/0x670 [ 7441.274067] [<ffffffff8108d189>] kthread+0xc9/0xe0 [ 7441.276305] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7441.279131] [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0 [ 7441.281659] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:48 -08:00
Arnd Bergmann	8ebba75fe5	cpufreq: s3c: remove last use of resume_clocks callback commit `67fadaa276` upstream. Commit `32726d2d55` ("ARM: SAMSUNG: Remove legacy clock code") already removed the callback pointer, but there was one remaining user: drivers/cpufreq/s3c24xx-cpufreq.c: In function 's3c_cpufreq_resume_clocks': drivers/cpufreq/s3c24xx-cpufreq.c:149:14: error: 'struct s3c_cpufreq_info' has no member named 'resume_clocks' cpu_cur.info->resume_clocks(); ^ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: `32726d2d55` ("ARM: SAMSUNG: Remove legacy clock code") Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:48 -08:00
Arnd Bergmann	2b21e24709	cpufreq: s3c: remove incorrect __init annotations commit `61882b6317` upstream. The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register are marked init but are called from a context that might be run after the __init sections are discarded, as the compiler points out: WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init() WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register() This removes the __init markings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:48 -08:00
Mikulas Patocka	bfb4e3fb85	cpufreq: speedstep-smi: enable interrupts when waiting commit `d4d4eda237` upstream. On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the speedstep-smi driver sometimes loads and sometimes doesn't load with "change to state X failed" message. The hardware sometimes refuses to change frequency and in this case, we need to retry later. I found out that we need to enable interrupts while waiting. When we enable interrupts, the hardware blockage that prevents frequency transition resolves and the transition is possible. With disabled interrupts, the blockage doesn't resolve (no matter how long do we wait). The exact reasons for this hardware behavior are unknown. This patch enables interrupts in the function speedstep_set_state that can be called with disabled interrupts. However, this function is called with disabled interrupts only from speedstep_get_freqs, so it shouldn't cause any problem. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:48 -08:00
Viresh Kumar	125c662fd5	cpufreq: Set cpufreq_cpu_data to NULL before putting kobject commit `6ffae8c06f` upstream. In __cpufreq_remove_dev_finish(), per-cpu 'cpufreq_cpu_data' needs to be cleared before calling kobject_put(&policy->kobj) and under cpufreq_driver_lock. Otherwise, if someone else calls cpufreq_cpu_get() in parallel with it, they can obtain a non-NULL policy from that after kobject_put(&policy->kobj) was executed. Consider this case: Thread A Thread B cpufreq_cpu_get() acquire cpufreq_driver_lock read-per-cpu cpufreq_cpu_data kobject_put(&policy->kobj); kobject_get(&policy->kobj); ... per_cpu(&cpufreq_cpu_data, cpu) = NULL And this will result in a warning like this one: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4 at include/linux/kref.h:47 kobject_get+0x41/0x50() Modules linked in: acpi_cpufreq(+) nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c sd_mod ixgbe igb mdio ahci hwmon ... Call Trace: [<ffffffff81661b14>] dump_stack+0x46/0x58 [<ffffffff81072b61>] warn_slowpath_common+0x81/0xa0 [<ffffffff81072c7a>] warn_slowpath_null+0x1a/0x20 [<ffffffff812e16d1>] kobject_get+0x41/0x50 [<ffffffff815262a5>] cpufreq_cpu_get+0x75/0xc0 [<ffffffff81527c3e>] cpufreq_update_policy+0x2e/0x1f0 [<ffffffff810b8cb2>] ? up+0x32/0x50 [<ffffffff81381aa9>] ? acpi_ns_get_node+0xcb/0xf2 [<ffffffff81381efd>] ? acpi_evaluate_object+0x22c/0x252 [<ffffffff813824f6>] ? acpi_get_handle+0x95/0xc0 [<ffffffff81360967>] ? acpi_has_method+0x25/0x40 [<ffffffff81391e08>] acpi_processor_ppc_has_changed+0x77/0x82 [<ffffffff81089566>] ? move_linked_works+0x66/0x90 [<ffffffff8138e8ed>] acpi_processor_notify+0x58/0xe7 [<ffffffff8137410c>] acpi_ev_notify_dispatch+0x44/0x5c [<ffffffff8135f293>] acpi_os_execute_deferred+0x15/0x22 [<ffffffff8108c910>] process_one_work+0x160/0x410 [<ffffffff8108d05b>] worker_thread+0x11b/0x520 [<ffffffff8108cf40>] ? rescuer_thread+0x380/0x380 [<ffffffff81092421>] kthread+0xe1/0x100 [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0 [<ffffffff81669ebc>] ret_from_fork+0x7c/0xb0 [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0 ---[ end trace 89e66eb9795efdf7 ]--- The actual code flow is as follows: Thread A: Workqueue: kacpi_notify acpi_processor_notify() acpi_processor_ppc_has_changed() cpufreq_update_policy() cpufreq_cpu_get() kobject_get() Thread B: xenbus_thread() xenbus_thread() msg->u.watch.handle->callback() handle_vcpu_hotplug_event() vcpu_hotplug() cpu_down() __cpu_notify(CPU_POST_DEAD..) cpufreq_cpu_callback() __cpufreq_remove_dev_finish() cpufreq_policy_put_kobj() kobject_put() cpufreq_cpu_get() gets the policy from per-cpu variable cpufreq_cpu_data under cpufreq_driver_lock, and once it gets a valid policy it expects it to not be freed until cpufreq_cpu_put() is called. But the race happens when another thread puts the kobject first and updates cpufreq_cpu_data before or later. And so the first thread gets a valid policy structure and before it does kobject_get() on it, the second one has already done kobject_put(). Fix this by setting cpufreq_cpu_data to NULL before putting the kobject and that too under locks. Reported-by: Ethan Zhao <ethan.zhao@oracle.com> Reported-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:47 -08:00
Larry Finger	66d955dfea	rtlwifi: Remove logging statement that is no longer needed commit `aeb2d2a4c0` upstream. In commit `e9538cf4f9` ("rtlwifi: Fix error when accessing unmapped memory in skb"), a printk was included to indicate that the condition had been reached. There is now enough evidence from other users that the fix is working. That logging statement can now be removed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:47 -08:00
Larry Finger	78eb509c60	rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO commit `6d4beca377` upstream. This driver utilizes a FIFO buffer for RX descriptors. There are four places in the code where it calculates the number of free slots. Several of those locations do the calculation incorrectly. To fix these and to prevent future mistakes, a common inline routine is created. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:47 -08:00
Troy Tan	31151ff618	rtlwifi: rtl8192ee: Fix DMA stalls commit `21b39ddb5b` upstream. There are instances where the DMA engine stalls. The new code detects such stalls and restarts DMA without needing a power reset. Signed-off-by: Troy Tan <troy_tan@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:47 -08:00
Troy Tan	791f7ad909	rtlwifi: rtl8192ee: Fix parsing of received packet commit `92ff754240` upstream. The firmware supplies two kinds of packets via the RX mechanism. Besides the normal data received over the air, these packets may contain bluetooth status and other information. The present code fails to detect which kind of information was received. Signed-off-by: Troy Tan <troy_tan@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:47 -08:00
Troy Tan	67861ed5ca	rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write point commit `6e5f443616` upstream. Initially, the routine to update the write point in the FIFO buffer was coded to save CPU time by not doing the calculation every interrupt. This was an error and results in TX hangs. Signed-off-by: Troy Tan <troy_tan@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Troy Tan	db8ecaa9bd	rtlwifi: rtl8192ee: Fix adhoc fail commit `b661a5da57` upstream. When the buffer descriptor index exceeds 2, then a TX HANG condition will result. Signed-off-by: Troy Tan <troy_tan@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Arnd Bergmann	d71cea8e09	ASoC: davinci: fix DM365_EVM codec selection commit `f9a7ba3269` upstream. An earlier bug fix of mine made the SND_DM365_VOICE_CODEC symbol tristate to avoid creating an undefined reference from the davinci-vcif.c driver to the davinci_soc_platform_register function that may be in a module. However, this may now lead to a different error on randconfig kernels: "warning: SND_DM365_VOICE_CODEC creates inconsistent choice state" This happens because we now have a choice statement with one bool and one tristate option, and the latter might not support being set to 'y' because of dependencies. This new change turns the other option into 'tristate' as well, which avoids the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: `19926c6de0` ("ASoC: davinci: vcif must be a module if SND_DAVINCI_SOC is") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Lars-Peter Clausen	a09c233326	ASoC: mioa701_wm9713: Fix speaker event commit `7331ea474e` upstream. Commit `f6b2a04590` ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM setup") converted the driver to register the board level DAPM elements with the card's DAPM context rather than the CODEC's DAPM context. The change overlooked that the speaker widget event callback accesses the widget's codec field which is only valid if the widget has been registered in a CODEC DAPM context. This patch modifies the callback to take an alternative route to get the CODEC. Fixes: `f6b2a04590` ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM setup") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Bard Liao	e1f2c1786c	ASoC: rt5670: Set use_single_rw flag for regmap commit `92b133f251` upstream. RT5670 doesn't support auto incrementing writes so driver should set the use_single_rw flag for regmap. Signed-off-by: Bard Liao <bardliao@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Michel Dänzer	9ada148d27	PCI: Fix infinite loop with ROM image of size 0 commit `16b036af31` upstream. If the image size would ever read as 0, pci_get_rom_size() could keep processing the same image over and over again. Exit the loop if we ever read a length of zero. This fixes a soft lockup on boot when the radeon driver calls pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card. [bhelgaas: changelog, reference] Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973 Reported-by: Federico <federicotg@gmail.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Ricardo Ribalda Delgado	c38fae9fef	PCI: Generate uppercase hex for modalias var in uevent commit `145b3fe579` upstream. Some implementations of modprobe fail to load the driver for a PCI device automatically because the "interface" part of the modalias from the kernel is lowercase, and the modalias from file2alias is uppercase. The "interface" is the low-order byte of the Class Code, defined in PCI r3.0, Appendix D. Most interface types defined in the spec do not use alpha characters, so they won't be affected. For example, 00h, 01h, 10h, 20h, etc. are unaffected. Print the "interface" byte of the Class Code in uppercase hex, as we already do for the Vendor ID, Device ID, Class, etc. Commit `89ec3dcf17` ("PCI: Generate uppercase hex for modalias interface class") fixed only half of the problem. Some udev implementations rely on the uevent file and not the modalias file. Fixes: `d1ded203ad` ("PCI: add MODALIAS to hotplug event for pci devices") Fixes: `89ec3dcf17` ("PCI: Generate uppercase hex for modalias interface class") Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Seth Forshee	dff8c9d3be	HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events commit `6d00f37e49` upstream. `d1c7e29e8d` (HID: i2c-hid: prevent buffer overflow in early IRQ) changed hid_get_input() to read ihid->bufsize bytes, which can be more than wMaxInputLength. This is the case with the Dell XPS 13 9343, and it is causing events to be missed. In some cases the missed events are releases, which can cause the cursor to jump or freeze, among other problems. Limit the number of bytes read to min(wMaxInputLength, ihid->bufsize) to prevent such problems. Fixes: `d1c7e29e8d` "HID: i2c-hid: prevent buffer overflow in early IRQ" Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:46 -08:00
Luciano Coelho	e8f143e4a2	iwlwifi: mvm: always use mac color zero commit `5523d11cc4` upstream. We don't really need to use different mac colors when adding mac contexts, because they're not used anywhere. In fact, the firmware doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401 when we reach that. Remove the color increment to use always zero and avoid reaching 255. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Luciano Coelho	71ed878760	iwlwifi: mvm: fix failure path when power_update fails in add_interface commit `fd66fc1caf` upstream. When iwl_mvm_power_update_mac() is called, we have already added the mac context, so if this call fails we should remove the mac. Fixes: commit `e5e7aa8e25` ('iwlwifi: mvm: refactor power code') Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Eyal Shapira	77786bd9e9	iwlwifi: mvm: validate tid and sta_id in ba_notif commit `2cee4762c5` upstream. These are coming from the FW and are used to access arrays. Bad values can cause an out of bounds access so discard such ba_notifs and warn. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Emmanuel Grumbach	eba54079b6	iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN commit `cd8f438405` upstream. The base address of the scheduler in the device's memory (SRAM) comes from two different sources. The periphery register and the alive notification from the firmware. We have a check in iwl_pcie_tx_start that ensures that they are the same. When we resume from WoWLAN, the firmware may have crashed for whatever reason. In that case, the whole device may be reset which means that the periphery register will hold a meaningless value. When we come to compare trans_pcie->scd_base_addr (which really holds the value we had when we loaded the WoWLAN firmware upon suspend) and the current value of the register, we don't see a match unsurprisingly. Trick the check to avoid a loud yet harmless WARN. Note that when the WoWLAN has crashed, we will see that in iwl_trans_pcie_d3_resume which will let the op_mode know. Once the op_mode is informed that the WowLAN firmware has crashed, it can't do much besides resetting the whole device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Jan Kara	ed6e4acbfe	fsnotify: fix handling of renames in audit commit `6ee8e25fc3` upstream. Commit `e9fd702a58` ("audit: convert audit watches to use fsnotify instead of inotify") broke handling of renames in audit. Audit code wants to update inode number of an inode corresponding to watched name in a directory. When something gets renamed into a directory to a watched name, inotify previously passed moved inode to audit code however new fsnotify code passes directory inode where the change happened. That confuses audit and it starts watching parent directory instead of a file in a directory. This can be observed for example by doing: cd /tmp touch foo bar auditctl -w /tmp/foo touch foo mv bar foo touch foo In audit log we see events like: type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1 ... type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE ... and that's it - we see event for the first touch after creating the audit rule, we see events for rename but we don't see any event for the last touch. However we start seeing events for unrelated stuff happening in /tmp. Fix the problem by passing moved inode as data in the FS_MOVED_FROM and FS_MOVED_TO events instead of the directory where the change happens. This doesn't introduce any new problems because noone besides audit_watch.c cares about the passed value: fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events. fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all. fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH. kernel/audit_tree.c doesn't care about passed 'data' at all. kernel/audit_watch.c expects moved inode as 'data'. Fixes: `e9fd702a58` ("audit: convert audit watches to use fsnotify instead of inotify") Signed-off-by: Jan Kara <jack@suse.cz> Cc: Paul Moore <paul@paul-moore.com> Cc: Eric Paris <eparis@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Dave Chinner	0dc8a9c0a5	xfs: set superblock buffer type correctly commit `3443a3bca5` upstream. When the superblock is modified in a transaction, the commonly modified fields are not actually copied to the superblock buffer to avoid the buffer lock becoming a serialisation point. However, there are some other operations that modify the superblock fields within the transaction that don't directly log to the superblock but rely on the changes to be applied during the transaction commit (to minimise the buffer lock hold time). When we do this, we fail to mark the buffer log item as being a superblock buffer and that can lead to the buffer not being marked with the corect type in the log and hence causing recovery issues. Fix it by setting the type correctly, similar to xfs_mod_sb()... Tested-by: Jan Kara <jack@suse.cz> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Dave Chinner	32363816fc	xfs: set buf types when converting extent formats commit `fe22d552b8` upstream. Conversion from local to extent format does not set the buffer type correctly on the new extent buffer when a symlink data is moved out of line. Fix the symlink code and leave a comment in the generic bmap code reminding us that the format-specific data copy needs to set the destination buffer type appropriately. Tested-by: Jan Kara <jack@suse.cz> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:45 -08:00
Dave Chinner	4c60b12835	xfs: inode unlink does not set AGI buffer type commit `f19b872b08` upstream. This leads to log recovery throwing errors like: XFS (md0): Mounting V5 Filesystem XFS (md0): Starting recovery (logdev: internal) XFS (md0): Unknown buffer type 0! XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1 ffff8800ffc53800: 58 41 47 49 ..... Which is the AGI buffer magic number. Ensure that we set the type appropriately in both unlink list addition and removal. Tested-by: Jan Kara <jack@suse.cz> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Dave Chinner	3d2dae943e	xfs: ensure buffer types are set correctly commit `0d612fb570` upstream. Jan Kara reported that log recovery was finding buffers with invalid types in them. This should not happen, and indicates a bug in the logging of buffers. To catch this, add asserts to the buffer formatting code to ensure that the buffer type is in range when the transaction is committed. We don't set a type on buffers being marked stale - they are not going to get replayed, the format item exists only for recovery to be able to prevent replay of the buffer, so the type does not matter. Hence that needs special casing here. Reported-by: Jan Kara <jack@suse.cz> Tested-by: Jan Kara <jack@suse.cz> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
George Spelvin	b2c618c9c6	random: Fix fast_mix() function commit `19acc77a36` upstream. There was a bad typo in commit `43759d4f42` ("random: use an improved fast_mix() function") and I didn't notice because it "looked right", so I saw what I expected to see when I reviewed it. Only months later did I look and notice it's not the Threefish-inspired mix function that I had designed and optimized. Mea Culpa. Each input bit still has a chance to affect each output bit, and the fast pool is spilled long before it fills, so it's not a total disaster, but it's definitely not the intended great improvement. I'm still working on finding better rotation constants. These are good enough, but since it's unrolled twice, it's possible to get better mixing for free by using eight different constants rather than repeating the same four. Signed-off-by: George Spelvin <linux@horizon.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Matej Dubovy	8b602c56a2	Bluetooth: btusb: Add support for Lite-On (04ca) Broadcom based, BCM43142 commit `8f0c304c69` upstream. Please add support for sub BT chip on the combo card Broadcom 43142A0 (in Lenovo E145), 04ca:2007 /sys/kernel/debug/usb/devices T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=2007 Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM43142A0 S: SerialNumber=28E347EC73BD C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Firmware for 04ca:2007 can be extracted from the latest Lenovo E145 Bluetooth driver for Windows (driver is however described as BCM20702 but contains also firwmare for BCM43142). Search for BCM43142A0_001.001.011.0122.0153.hex within hex files, then it must be converted using hex2hcd utility. Rename file to BCM43142A0-04ca-2007.hcd, then move to /lib/firmware/brcm/. Signed-off-by: Matej Dubovy <matej.dubovy@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Marcel Holtmann	004db5881b	Bluetooth: btusb: Add support for Dynex/Insignia USB dongles commit `d049f4e513` upstream. The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require firmware update before operation. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=19ff ProdID=0239 Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Since this is an unsual USB vendor ID (0x19ff), these dongles are added via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for mainstream Broadcom based dongles. The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex which needs to be converted using hex2hcd utility and then installed as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully operational. Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e With this firmware the device reports support for connectionless slave broadcast (master and slave) feature used by 3D Glasses and TVs. < HCI Command: Read Local Extended Features (0x04\|0x0004) plen 1 Page: 2 > HCI Event: Command Complete (0x0e) plen 14 Read Local Extended Features (0x04\|0x0004) ncmd 1 Status: Success (0x00) Page: 2/2 Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Connectionless Slave Broadcast - Master Connectionless Slave Broadcast - Slave Synchronization Train Synchronization Scan However there are some flaws with this feature. The Set Event Mask Page 2 command is actually not supported and with that all connectionless slave broadcast events are always enabled. < HCI Command: Set Event Mask Page 2 (0x03\|0x0063) plen 8 Mask: 0x00000000000f0000 Synchronization Train Received Connectionless Slave Broadcast Receive Connectionless Slave Broadcast Timeout Truncated Page Complete > HCI Event: Command Complete (0x0e) plen 4 Set Event Mask Page 2 (0x03\|0x0063) ncmd 1 Status: Unknown HCI Command (0x01) In addition the Synchronization Train Received event is actually broken on this controller. It mixes up the order of parameters. According to the Bluetooth Core specification the fields are like this: struct hci_ev_sync_train_received { __u8 status; bdaddr_t bdaddr; __le32 offset; __u8 map[10]; __u8 lt_addr; __le32 instant; __le16 interval; __u8 service_data; } __packed; This controller however sends the service_data as 5th parameter instead of having it as last parameter. struct hci_ev_sync_train_received { __u8 status; bdaddr_t bdaddr; __le32 offset; __u8 map[10]; __u8 service_data; __u8 lt_addr; __le32 instant; __le16 interval; } __packed; So anybody trying to use this hardware for utilizing connectionless slave broadcast receivers (aka 3D Glasses), be warned about this shortcoming. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Rick Dunn	0cfe1a4be3	Bluetooth: btusb: Add Broadcom patchram support for ASUSTek devices commit `9a5abdaaf9` upstream. T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17cf Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=54271E3298CD C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Firmware is extracted from the latest Broadcom BCM4352 Windows driver by extracting the zip and searching the .hex file names for '17cf'. The hex file must then be converted to hcd format using the hex2hcd utility and then moved to /lib/firmware/brcm/. Signed-off-by: Rick Dunn <rick@rickdunn.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Johan Hedberg	f879c09458	Bluetooth: Fix valid Identity Address check commit `e12af489b9` upstream. According to the Bluetooth core specification valid identity addresses are either Public Device Addresses or Static Random Addresses. IRKs received with any other type of address should be discarded since we cannot assume to know the permanent identity of the peer device. This patch fixes a missing check for the Identity Address when receiving the Identity Address Information SMP PDU. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Dmitry Tunin	c86e12f019	Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device commit `033efa920a` upstream. Add support of 13d3:3423 device. BugLink: https://bugs.launchpad.net/bugs/1411193 T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3423 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Adam Lee	a73e33ea08	Bluetooth: ath3k: workaround the compatibility issue with xHCI controller commit `c561a5753d` upstream. BugLink: https://bugs.launchpad.net/bugs/1400215 ath3k devices fail to load firmwares on xHCI buses, but work well on EHCI, this might be a compatibility issue between xHCI and ath3k chips. As my testing result, those chips will work on xHCI buses again with this patch. This workaround is from Qualcomm, they also did some workarounds in Windows driver. Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-03-06 14:52:44 -08:00
Greg Kroah-Hartman	e5c9f0bba1	Linux 3.18.8	2015-02-26 17:49:36 -08:00
Austin Lund	bdb39ccebc	media/rc: Send sync space information on the lirc device commit `a8f29e89f2` upstream. Userspace expects to see a long space before the first pulse is sent on the lirc device. Currently, if a long time has passed and a new packet is started, the lirc codec just returns and doesn't send anything. This makes lircd ignore many perfectly valid signals unless they are sent in quick sucession. When a reset event is delivered, we cannot know anything about the duration of the space. But it should be safe to assume it has been a long time and we just set the duration to maximum. Signed-off-by: Austin Lund <austin.lund@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:02 -08:00
Eric Sandeen	4e55dad93e	ext4: ignore journal checksum on remount; don't fail commit `2d5b86e048` upstream. As of v3.18, ext4 started rejecting a remount which changes the journal_checksum option. Prior to that, it was simply ignored; the problem here is that if someone has this in their fstab for the root fs, now the box fails to boot properly, because remount of root with the new options will fail, and the box proceeds with a readonly root. I think it is a little nicer behavior to accept the option, but warn that it's being ignored, rather than failing the mount, but that might be a subjective matter... Reported-by: Cónräd <conradsand.arma@gmail.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:02 -08:00
Eric Dumazet	a17ad4adff	net: sched: fix panic in rate estimators [ Upstream commit `0d32ef8cef` ] Doing the following commands on a non idle network device panics the box instantly, because cpu_bstats gets overwritten by stats. tc qdisc add dev eth0 root <your_favorite_qdisc> ... some traffic (one packet is enough) ... tc qdisc replace dev eth0 root est 1sec 4sec <your_favorite_qdisc> [ 325.355596] BUG: unable to handle kernel paging request at ffff8841dc5a074c [ 325.362609] IP: [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90 [ 325.369158] PGD `1fa7067` PUD 0 [ 325.372254] Oops: 0000 [#1] SMP [ 325.375514] Modules linked in: ... [ 325.398346] CPU: 13 PID: 14313 Comm: tc Not tainted 3.19.0-smp-DEV #1163 [ 325.412042] task: ffff8800793ab5d0 ti: ffff881ff2fa4000 task.ti: ffff881ff2fa4000 [ 325.419518] RIP: 0010:[<ffffffff81541c9e>] [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90 [ 325.428506] RSP: 0018:ffff881ff2fa7928 EFLAGS: 00010286 [ 325.433824] RAX: 000000000000000c RBX: ffff881ff2fa796c RCX: 000000000000000c [ 325.440988] RDX: ffff8841dc5a0744 RSI: 0000000000000060 RDI: 0000000000000060 [ 325.448120] RBP: ffff881ff2fa7948 R08: ffffffff81cd4f80 R09: 0000000000000000 [ 325.455268] R10: ffff883ff223e400 R11: 0000000000000000 R12: 000000015cba0744 [ 325.462405] R13: ffffffff81cd4f80 R14: ffff883ff223e460 R15: ffff883feea0722c [ 325.469536] FS: 00007f2ee30fa700(0000) GS:ffff88407fa20000(0000) knlGS:0000000000000000 [ 325.477630] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 325.483380] CR2: ffff8841dc5a074c CR3: 0000003feeae9000 CR4: 00000000001407e0 [ 325.490510] Stack: [ 325.492524] ffff883feea0722c ffff883fef719dc0 ffff883feea0722c ffff883ff223e4a0 [ 325.499990] ffff881ff2fa79a8 ffffffff815424ee ffff883ff223e49c 000000015cba0744 [ 325.507460] 00000000f2fa7978 0000000000000000 ffff881ff2fa79a8 ffff883ff223e4a0 [ 325.514956] Call Trace: [ 325.517412] [<ffffffff815424ee>] gen_new_estimator+0x8e/0x230 [ 325.523250] [<ffffffff815427aa>] gen_replace_estimator+0x4a/0x60 [ 325.529349] [<ffffffff815718ab>] tc_modify_qdisc+0x52b/0x590 [ 325.535117] [<ffffffff8155edd0>] rtnetlink_rcv_msg+0xa0/0x240 [ 325.540963] [<ffffffff8155ed30>] ? __rtnl_unlock+0x20/0x20 [ 325.546532] [<ffffffff8157f811>] netlink_rcv_skb+0xb1/0xc0 [ 325.552145] [<ffffffff8155b355>] rtnetlink_rcv+0x25/0x40 [ 325.557558] [<ffffffff8157f0d8>] netlink_unicast+0x168/0x220 [ 325.563317] [<ffffffff8157f47c>] netlink_sendmsg+0x2ec/0x3e0 Lets play safe and not use an union : percpu 'pointers' are mostly read anyway, and we have typically few qdiscs per host. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: John Fastabend <john.fastabend@gmail.com> Fixes: `22e0f8b932` ("net: sched: make bstats per cpu and estimator RCU safe") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:02 -08:00
Haiyang Zhang	d2ddce3df7	hyperv: Fix the error processing in netvsc_send() [ Upstream commit `d953ca4ddf` ] The existing code frees the skb in EAGAIN case, in which the skb will be retried from upper layer and used again. Also, the existing code doesn't free send buffer slot in error case, because there is no completion message for unsent packets. This patch fixes these problems. (Please also include this patch for stable trees. Thanks!) Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:02 -08:00
Saran Maruti Ramanara	6743ca71e1	net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param [ Upstream commit `cfbf654efc` ] When making use of RFC5061, section 4.2.4. for setting the primary IP address, we're passing a wrong parameter header to param_type2af(), resulting always in NULL being returned. At this point, param.p points to a sctp_addip_param struct, containing a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation id. Followed by that, as also presented in RFC5061 section 4.2.4., comes the actual sctp_addr_param, which also contains a sctp_paramhdr, but this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that param_type2af() can make use of. Since we already hold a pointer to addr_param from previous line, just reuse it for param_type2af(). Fixes: `d6de309759` ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT") Signed-off-by: Saran Maruti Ramanara <saran.neti@telus.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Florian Westphal	15f7f69a6b	ppp: deflate: never return len larger than output buffer [ Upstream commit `e2a4800e75` ] When we've run out of space in the output buffer to store more data, we will call zlib_deflate with a NULL output buffer until we've consumed remaining input. When this happens, olen contains the size the output buffer would have consumed iff we'd have had enough room. This can later cause skb_over_panic when ppp_generic skb_put()s the returned length. Reported-by: Iain Douglas <centos@1n6.org.uk> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Eric Dumazet	b974d00b77	ipv4: tcp: get rid of ugly unicast_sock [ Upstream commit `bdbbb8527b` ] In commit `be9f4a44e7` ("ipv4: tcp: remove per net tcp_sock") I tried to address contention on a socket lock, but the solution I chose was horrible : commit `3a7c384ffd` ("ipv4: tcp: unicast_sock should not land outside of TCP stack") addressed a selinux regression. commit `0980e56e50` ("ipv4: tcp: set unicast_sock uc_ttl to -1") took care of another regression. commit `b5ec8eeac4` ("ipv4: fix ip_send_skb()") fixed another regression. commit `811230cd85` ("tcp: ipv4: initialize unicast_sock sk_pacing_rate") was another shot in the dark. Really, just use a proper socket per cpu, and remove the skb_orphan() call, to re-enable flow control. This solves a serious problem with FQ packet scheduler when used in hostile environments, as we do not want to allocate a flow structure for every RST packet sent in response to a spoofed packet. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Eric Dumazet	617417f999	tcp: ipv4: initialize unicast_sock sk_pacing_rate [ Upstream commit `811230cd85` ] When I added sk_pacing_rate field, I forgot to initialize its value in the per cpu unicast_sock used in ip_send_unicast_reply() This means that for sch_fq users, RST packets, or ACK packets sent on behalf of TIME_WAIT sockets might be sent to slowly or even dropped once we reach the per flow limit. Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `95bd09eb27` ("tcp: TSO packets automatic sizing") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Roopa Prabhu	7a0189390e	bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify [ Upstream commit `59ccaaaa49` ] Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081 This patch avoids calling rtnl_notify if the device ndo_bridge_getlink handler does not return any bytes in the skb. Alternately, the skb->len check can be moved inside rtnl_notify. For the bridge vlan case described in 92081, there is also a fix needed in bridge driver to generate a proper notification. Will fix that in subsequent patch. v2: rebase patch on net tree Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Christoph Hellwig	db4d24bc7f	net: don't OOPS on socket aio [ Upstream commit `06539d3071` ] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Govindarajulu Varadarajan	e3b175f60e	bnx2x: fix napi poll return value for repoll [ Upstream commit `24e579c889` ] With the commit `d75b1ade56` ("net: less interrupt masking in NAPI") napi repoll is done only when work_done == budget. When in busy_poll is we return 0 in napi_poll. We should return budget. Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Hannes Frederic Sowa	b0e791661b	ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too [ Upstream commit `6e9e16e614` ] Lubomir Rintel reported that during replacing a route the interface reference counter isn't correctly decremented. To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>: \| [root@rhel7-5 lkundrak]# sh -x lal \| + ip link add dev0 type dummy \| + ip link set dev0 up \| + ip link add dev1 type dummy \| + ip link set dev1 up \| + ip addr add 2001:db8:8086::2/64 dev dev0 \| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20 \| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10 \| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20 \| + ip link del dev0 type dummy \| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ... \| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2 \| \| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ... \| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2 During replacement of a rt6_info we must walk all parent nodes and check if the to be replaced rt6_info got propagated. If so, replace it with an alive one. Fixes: `4a287eba2d` ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag") Reported-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Tested-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
subashab@codeaurora.org	3a06a68b40	ping: Fix race in free in receive path [ Upstream commit `fc752f1f43` ] An exception is seen in ICMP ping receive path where the skb destructor sock_rfree() tries to access a freed socket. This happens because ping_rcv() releases socket reference with sock_put() and this internally frees up the socket. Later icmp_rcv() will try to free the skb and as part of this, skb destructor is called and which leads to a kernel panic as the socket is freed already in ping_rcv(). -->\|exception -007\|sk_mem_uncharge -007\|sock_rfree -008\|skb_release_head_state -009\|skb_release_all -009\|__kfree_skb -010\|kfree_skb -011\|icmp_rcv -012\|ip_local_deliver_finish Fix this incorrect free by cloning this skb and processing this cloned skb instead. This patch was suggested by Eric Dumazet Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Herbert Xu	faf8cf001d	udp_diag: Fix socket skipping within chain [ Upstream commit `86f3cddbc3` ] While working on rhashtable walking I noticed that the UDP diag dumping code is buggy. In particular, the socket skipping within a chain never happens, even though we record the number of sockets that should be skipped. As this code was supposedly copied from TCP, this patch does what TCP does and resets num before we walk a chain. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:01 -08:00
Hannes Frederic Sowa	9ad1a959ac	ipv4: try to cache dst_entries which would cause a redirect [ Upstream commit `df4d92549f` ] Not caching dst_entries which cause redirects could be exploited by hosts on the same subnet, causing a severe DoS attack. This effect aggravated since commit `f886497212` ("ipv4: fix dst race in sk_dst_get()"). Lookups causing redirects will be allocated with DST_NOCACHE set which will force dst_release to free them via RCU. Unfortunately waiting for RCU grace period just takes too long, we can end up with >1M dst_entries waiting to be released and the system will run OOM. rcuos threads cannot catch up under high softirq load. Attaching the flag to emit a redirect later on to the specific skb allows us to cache those dst_entries thus reducing the pressure on allocation and deallocation. This issue was discovered by Marcelo Leitner. Cc: Julian Anastasov <ja@ssi.bg> Signed-off-by: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Daniel Borkmann	c75e4b05b5	net: sctp: fix slab corruption from use after free on INIT collisions [ Upstream commit `600ddd6825` ] When hitting an INIT collision case during the 4WHS with AUTH enabled, as already described in detail in commit `1be9a950c6` ("net: sctp: inherit auth_capable on INIT collisions"), it can happen that we occasionally still remotely trigger the following panic on server side which seems to have been uncovered after the fix from commit `1be9a950c6` ... [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff [ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230 [ 533.940559] PGD 5030f2067 PUD 0 [ 533.957104] Oops: 0000 [#1] SMP [ 533.974283] Modules linked in: sctp mlx4_en [...] [ 534.939704] Call Trace: [ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0 [ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0 [ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170 [ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0 [ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50 [ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp] [ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0 [ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b ... or depending on the the application, for example this one: [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0 [ 1370.054568] PGD 633c94067 PUD 0 [ 1370.070446] Oops: 0000 [#1] SMP [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...] [ 1370.963431] Call Trace: [ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960 [ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960 [ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170 [ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130 [ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b With slab debugging enabled, we can see that the poison has been overwritten: [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494 [ 669.826424] __slab_alloc+0x4bf/0x566 [ 669.826433] __kmalloc+0x280/0x310 [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp] [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp] [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp] [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...] [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494 [ 669.826635] __slab_free+0x39/0x2a8 [ 669.826643] kfree+0x1d6/0x230 [ 669.826650] kzfree+0x31/0x40 [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp] [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp] [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp] Since this only triggers in some collision-cases with AUTH, the problem at heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice when having refcnt 1, once directly in sctp_assoc_update() and yet again from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on the already kzfree'd memory, which is also consistent with the observation of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected at a later point in time when poison is checked on new allocation). Reference counting of auth keys revisited: Shared keys for AUTH chunks are being stored in endpoints and associations in endpoint_shared_keys list. On endpoint creation, a null key is being added; on association creation, all endpoint shared keys are being cached and thus cloned over to the association. struct sctp_shared_key only holds a pointer to the actual key bytes, that is, struct sctp_auth_bytes which keeps track of users internally through refcounting. Naturally, on assoc or enpoint destruction, sctp_shared_key are being destroyed directly and the reference on sctp_auth_bytes dropped. User space can add keys to either list via setsockopt(2) through struct sctp_authkey and by passing that to sctp_auth_set_key() which replaces or adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes with refcount 1 and in case of replacement drops the reference on the old sctp_auth_bytes. A key can be set active from user space through setsockopt() on the id via sctp_auth_set_active_key(), which iterates through either endpoint_shared_keys and in case of an assoc, invokes (one of various places) sctp_auth_asoc_init_active_key(). sctp_auth_asoc_init_active_key() computes the actual secret from local's and peer's random, hmac and shared key parameters and returns a new key directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops the reference if there was a previous one. The secret, which where we eventually double drop the ref comes from sctp_auth_asoc_set_secret() with intitial refcount of 1, which also stays unchanged eventually in sctp_assoc_update(). This key is later being used for crypto layer to set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac(). To close the loop: asoc->asoc_shared_key is freshly allocated secret material and independant of the sctp_shared_key management keeping track of only shared keys in endpoints and assocs. Hence, also commit `4184b2a79a` ("net: sctp: fix memory leak in auth key management") is independant of this bug here since it concerns a different layer (though same structures being used eventually). asoc->asoc_shared_key is reference dropped correctly on assoc destruction in sctp_association_free() and when active keys are being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is to remove that sctp_auth_key_put() from there which fixes these panics. Fixes: `730fc3d05c` ("[SCTP]: Implete SCTP-AUTH parameter processing") Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Eric Dumazet	e452612a3d	netxen: fix netxen_nic_poll() logic [ Upstream commit `6088beef3f` ] NAPI poll logic now enforces that a poller returns exactly the budget when it wants to be called again. If a driver limits TX completion, it has to return budget as well when the limit is hit, not the number of received packets. Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `d75b1ade56` ("net: less interrupt masking in NAPI") Cc: Manish Chopra <manish.chopra@qlogic.com> Acked-by: Manish Chopra <manish.chopra@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Hagen Paul Pfeifer	eb48900591	ipv6: stop sending PTB packets for MTU < 1280 [ Upstream commit `9d289715eb` ] Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments. See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused. [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00 Signed-off-by: Fernando Gont <fgont@si6networks.com> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Eric Dumazet	9e4cc1ed83	net: rps: fix cpu unplug [ Upstream commit `ac64da0b83` ] softnet_data.input_pkt_queue is protected by a spinlock that we must hold when transferring packets from victim queue to an active one. This is because other cpus could still be trying to enqueue packets into victim queue. A second problem is that when we transfert the NAPI poll_list from victim to current cpu, we absolutely need to special case the percpu backlog, because we do not want to add complex locking to protect process_queue : Only owner cpu is allowed to manipulate it, unless cpu is offline. Based on initial patch from Prasad Sodagudi & Subash Abhinov Kasiviswanathan. This version is better because we do not slow down packet processing, only make migration safer. Reported-by: Prasad Sodagudi <psodagud@codeaurora.org> Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Willem de Bruijn	8e9f6bdb35	ip: zero sockaddr returned on error queue [ Upstream commit `f812116b17` ] The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That structure is defined and allocated on the stack as struct { struct sock_extended_err ee; struct sockaddr_in(6) offender; } errhdr; The second part is only initialized for certain SO_EE_ORIGIN values. Always initialize it completely. An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that would return uninitialized bytes. Signed-off-by: Willem de Bruijn <willemb@google.com> ---- Also verified that there is no padding between errhdr.ee and errhdr.offender that could leak additional kernel data. Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-26 17:49:00 -08:00
Greg Kroah-Hartman	a17f9bf1f7	Linux 3.18.7	2015-02-11 15:01:12 +08:00
Linus Torvalds	61cfce3e9a	x86: mm: move mmap_sem unlock from mm_fault_error() to caller commit `7fb08eca45` upstream. This replaces four copies in various stages of mm_fault_error() handling with just a single one. It will also allow for more natural placement of the unlocking after some further cleanup. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:57 +08:00
Steven Rostedt (Red Hat)	299f45902a	x86/tlb/trace: Do not trace on CPU that is offline commit `6c8465a82a` upstream. When taking a CPU down for suspend and resume, a tracepoint may be called when the CPU has been designated offline. As tracepoints require RCU for protection, they must not be called if the current CPU is offline. Unfortunately, trace_tlb_flush() is called in this scenario as was noted by LOCKDEP: ... Disabling non-boot CPUs ... intel_pstate CPU 1 exiting =============================== smpboot: CPU 1 didn't die... [ INFO: suspicious RCU usage. ] 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted ------------------------------- include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 0 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011 ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600 0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78 Call Trace: [<ffffffff817e370d>] dump_stack+0x4c/0x65 [<ffffffff810d6847>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff810b71a5>] idle_task_exit+0x205/0x2c0 [<ffffffff81054c4e>] play_dead_common+0xe/0x50 [<ffffffff81054ca5>] native_play_dead+0x15/0x140 [<ffffffff8102963f>] arch_cpu_idle_dead+0xf/0x20 [<ffffffff810cd89e>] cpu_startup_entry+0x37e/0x580 [<ffffffff81053e20>] start_secondary+0x140/0x150 intel_pstate CPU 2 exiting ... By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected code when the CPU is offline. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Fixes: `d17d8f9ded` "x86/mm: Add tracepoints for TLB flushes" Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Hansen <dave@sr71.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:57 +08:00
Steven Rostedt (Red Hat)	409b0c0169	tracing: Add condition check to RCU lockdep checks commit `a05d59a567` upstream. The trace_tlb_flush() tracepoint can be called when a CPU is going offline. When a CPU is offline, RCU is no longer watching that CPU and since the tracepoint is protected by RCU, it must not be called. To prevent the tlb_flush tracepoint from being called when the CPU is offline, it was converted to a TRACE_EVENT_CONDITION where the condition checks if the CPU is online before calling the tracepoint. Unfortunately, this was not enough to stop lockdep from complaining about it. Even though the RCU protected code of the tracepoint will never be called, the condition is hidden within the tracepoint, and even though the condition prevents RCU code from being called, the lockdep checks are outside the tracepoint (this is to test tracepoints even when they are not enabled). Even though tracepoints should be checked to be RCU safe when they are not enabled, the condition should still be considered when checking RCU. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Fixes: `3a630178fd` "tracing: generate RCU warnings even when tracepoints are disabled" Acked-by: Dave Hansen <dave@sr71.net> Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:56 +08:00
John Stultz	fef76eabdf	hrtimer: Fix incorrect tai offset calculation for non high-res timer systems commit `2d926c15d6` upstream. I noticed some CLOCK_TAI timer test failures on one of my less-frequently used configurations. And after digging in I found in `76f4108892` (Cleanup hrtimer accessors to the timekepeing state), the hrtimer_get_softirq_time tai offset calucation was incorrectly rewritten, as the tai offset we return shold be from CLOCK_MONOTONIC, and not CLOCK_REALTIME. This results in CLOCK_TAI timers expiring early on non-highres capable machines. This patch fixes the issue, calculating the tai time properly from the monotonic base. Signed-off-by: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1423097126-10236-1-git-send-email-john.stultz@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:56 +08:00
Lai Jiangshan	1c3a363299	smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() commit `4bee96860a` upstream. The following race exists in the smpboot percpu threads management: CPU0 CPU1 cpu_up(2) get_online_cpus(); smpboot_create_threads(2); smpboot_register_percpu_thread(); for_each_online_cpu(); __smpboot_create_thread(); __cpu_up(2); This results in a missing per cpu thread for the newly onlined cpu2 and in a NULL pointer dereference on a consecutive offline of that cpu. Proctect smpboot_register_percpu_thread() with get_online_cpus() to prevent that. [ tglx: Massaged changelog and removed the change in smpboot_unregister_percpu_thread() because that's an optimization and therefor not stable material. ] Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: David Rientjes <rientjes@google.com> Link: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:56 +08:00
Boris Ostrovsky	ff0d1886ef	x86, microcode: Return error from driver init code when loader is disabled commit `da63865a01` upstream. Commits `65cef1311d` ("x86, microcode: Add a disable chicken bit") and `a18a0f6850` ("x86, microcode: Don't initialize microcode code on paravirt") allow microcode driver skip initialization when microcode loading is not permitted. However, they don't prevent the driver from being loaded since the init code returns 0. If at some point later the driver gets unloaded this will result in an oops while trying to deregister the (never registered) device. To avoid this, make init code return an error on paravirt or when microcode loading is disabled. The driver will then never be loaded. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com Reported-by: James Digwall <james@dingwall.me.uk> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:56 +08:00
Sylwester Nawrocki	6ea9ca8008	ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs commit `fddcd30073` upstream. I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, "samsung,s3c6410-i2s" compatible should be used for them. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:56 +08:00
Takashi Iwai	dde496323a	ALSA: ak411x: Fix stall in work callback commit `4161b4505f` upstream. When ak4114 work calls its callback and the callback invokes ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding this, control the reentrance by introducing a refcount. Also flush_delayed_work() is replaced with cancel_delayed_work_sync(). The exactly same bug is present in ak4113.c and fixed as well. Reported-by: Pavel Hofman <pavel.hofman@ivitera.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Tested-by: Pavel Hofman <pavel.hofman@ivitera.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
Eric Nelson	085d9e9eea	ASoC: sgtl5000: add delay before first I2C access commit `58cc9c9a17` upstream. To quote from section 1.3.1 of the data sheet: The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start ... 1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK. Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
Bo Shen	c0c9fe847a	ASoC: atmel_ssc_dai: fix start event for I2S mode commit `a43bd7e125` upstream. According to the I2S specification information as following: - WS = 0, channel 1 (left) - WS = 1, channel 2 (right) So, the start event should be TF/RF falling edge. Reported-by: Songjun Wu <songjun.wu@atmel.com> Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
karl beldan	31bf97f511	lib/checksum.c: fix build for generic csum_tcpudp_nofold commit `9ce357795e` upstream. Fixed commit added from64to32 under _#ifndef do_csum_ but used it under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's robot reported TILEGX's). Move from64to32 under the latter. Fixes: `150ae0e946` ("lib/checksum.c: fix carry in csum_tcpudp_nofold") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
Mark Rutland	1fb326794a	arm64: Fix up /proc/cpuinfo commit `44b82b7700` upstream. Commit `d7a49086f2` (arm64: cpuinfo: print info for all CPUs) attempted to clean up /proc/cpuinfo, but due to concerns regarding further changes was reverted in commit `5e39977edf` (Revert "arm64: cpuinfo: print info for all CPUs"). There are two major issues with the arm64 /proc/cpuinfo format currently: * The "Features" line describes (only) the 64-bit hwcaps, which is problematic for some 32-bit applications which attempt to parse it. As the same names are used for analogous ISA features (e.g. aes) despite these generally being architecturally unrelated, it is not possible to simply append the 64-bit and 32-bit hwcaps in a manner that might not be misleading to some applications. Various potential solutions have appeared in vendor kernels. Typically the format of the Features line varies depending on whether the task is 32-bit. * Information is only printed regarding a single CPU. This does not match the ARM format, and does not provide sufficient information in big.LITTLE systems where CPUs are heterogeneous. The CPU information printed is queried from the current CPU's registers, which is racy w.r.t. cross-cpu migration. This patch attempts to solve these issues. The following changes are made: * When a task with a LINUX32 personality attempts to read /proc/cpuinfo, the "Features" line contains the decoded 32-bit hwcaps, as with the arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In the absense of compat support, the Features line is empty. The set of hwcaps injected into a task's auxval are unaffected. * Properties are printed per-cpu, as with the ARM port. The per-cpu information is queried from pre-recorded cpu information (as used by the sanity checks). * As with the previous attempt at fixing up /proc/cpuinfo, the hardware field is removed. The only users so far are 32-bit applications tied to particular boards, so no portable applications should be affected, and this should prevent future tying to particular boards. The following differences remain: * No model_name is printed, as this cannot be queried from the hardware and cannot be provided in a stable fashion. Use of the CPU {implementor,variant,part,revision} fields is sufficient to identify a CPU and is portable across arm and arm64. * The following system-wide properties are not provided, as they are not possible to provide generally. Programs relying on these are already tied to particular (32-bit only) boards: - Hardware - Revision - Serial No software has yet been identified for which these remaining differences are problematic. Cc: Greg Hackmann <ghackmann@google.com> Cc: Ian Campbell <ijc@hellion.org.uk> Cc: Serban Constantinescu <serban.constantinescu@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: cross-distro@lists.linaro.org Cc: linux-api@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
Peter Kümmel	e5e10c0289	kconfig: Fix warning "‘jump’ may be used uninitialized" commit `2d56030609` upstream. Warning: In file included from scripts/kconfig/zconf.tab.c:2537:0: scripts/kconfig/menu.c: In function ‘get_symbol_str’: scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump->offset = strlen(r->s); Simplifies the test logic because (head && local) means (jump != 0) and makes GCC happy when checking if the jump pointer was initialized. Signed-off-by: Peter Kümmel <syntheticpp@gmx.net> Signed-off-by: Michal Marek <mmarek@suse.cz> Cc: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:55 +08:00
Alex Deucher	4fb5076bf3	drm/radeon: properly set vm fragment size for TN/RL commit `a124d068bf` upstream. Should be the same as cayman. We don't use VM by default on NI parts so this isn't critical. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:54 +08:00
Ilija Hadzic	83108f2238	drm/radeon: fix the crash in test functions commit `92b712b739` upstream. radeon_copy_dma and radeon_copy_blit must be called with a valid reservation object. Otherwise a crash will be provoked. We borrow the object from vram BO. bug: https://bugs.freedesktop.org/show_bug.cgi?id=88464 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:54 +08:00
Ilija Hadzic	624ddd1be9	drm/radeon: fix the crash in benchmark functions commit `3f5e1b4f58` upstream. radeon_copy_dma and radeon_copy_blit must be called with a valid reservation object. Otherwise a crash will be provoked. We borrow the object from destination BO. bug: https://bugs.freedesktop.org/show_bug.cgi?id=88464 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:54 +08:00
Christian König	7530584f8c	drm/radeon: fix PLLs on RS880 and older v2 commit `72edd83cc9` upstream. This is a workaround for RS880 and older chips which seem to have an additional limit on the minimum PLL input frequency. v2: fix signed/unsigned warning bugs: https://bugzilla.kernel.org/show_bug.cgi?id=91861 https://bugzilla.kernel.org/show_bug.cgi?id=83461 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:54 +08:00
Alex Deucher	2a1398b331	drm/radeon: don't init gpuvm if accel is disabled (v3) commit `544143f9e0` upstream. If acceleration is disabled, it does not make sense to init gpuvm since nothing will use it. Moreover, if radeon_vm_init() gets called it uses accel to try and clear the pde tables, etc. which results in a bug. v2: handle vm_fini as well v3: handle bo_open/close as well Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88786 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:54 +08:00
Ryusuke Konishi	7bb9e4a06e	nilfs2: fix deadlock of segment constructor over I_SYNC flag commit `7ef3ff2fea` upstream. Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes(): nilfs_segctor_thread() nilfs_segctor_thread_construct() nilfs_segctor_unlock() nilfs_dispose_list() iput() iput_final() evict() inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes() * set I_SYNC flag on inode->i_state __writeback_single_inode() do_writepages() nilfs_writepages() nilfs_construct_dsync_segment() nilfs_segctor_sync() * wait for completion of segment constructor inode_sync_complete() * clear I_SYNC flag after __writeback_single_inode() completed writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback(). Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0. Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:53 +08:00
Michal Hocko	32a7d7c223	memcg, shmem: fix shmem migration to use lrucare commit `f5e03a4989` upstream. It has been reported that 965GM might trigger VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage) in mem_cgroup_migrate when shmem wants to replace a swap cache page because of shmem_should_replace_page (the page is allocated from an inappropriate zone). shmem_replace_page expects that the oldpage is not on LRU list and calls mem_cgroup_migrate without lrucare. This is obviously incorrect because swapcache pages might be on the LRU list (e.g. swapin readahead page). Fix this by enabling lrucare for the migration in shmem_replace_page. Also clarify that lrucare should be used even if one of the pages might be on LRU list. The BUG_ON will trigger only when CONFIG_DEBUG_VM is enabled but even without that the migration code might leave the old page on an inappropriate memcg' LRU which is not that critical because the page would get removed with its last reference but it is still confusing. Fixes: `0a31bc97c8` ("mm: memcontrol: rewrite uncharge API") Signed-off-by: Michal Hocko <mhocko@suse.cz> Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Dave Airlie <airlied@gmail.com> Acked-by: Hugh Dickins <hughd@google.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:53 +08:00
karl beldan	a01e1611c0	lib/checksum.c: fix carry in csum_tcpudp_nofold commit `150ae0e946` upstream. The carry from the 64->32bits folding was dropped, e.g with: saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1, csum_tcpudp_nofold returned 0 instead of 1. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mike Frysinger <vapier@gentoo.org> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:53 +08:00
Shiraz Hashim	00034998ed	mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range commit `23aaed6659` upstream. walk_page_range() silently skips vma having VM_PFNMAP set, which leads to undesirable behaviour at client end (who called walk_page_range). Userspace applications get the wrong data, so the effect is like just confusing users (if the applications just display the data) or sometimes killing the processes (if the applications do something with misunderstanding virtual addresses due to the wrong data.) For example for pagemap_read, when no callbacks are called against VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual address range at wrong index. Eventually userspace may get wrong pagemap data for a task. Corresponding to a VM_PFNMAP marked vma region, kernel may report mappings from subsequent vma regions. User space in turn may account more pages (than really are) to the task. In my case I was using procmem, procrack (Android utility) which uses pagemap interface to account RSS pages of a task. Due to this bug it was giving a wrong picture for vmas (with VM_PFNMAP set). Fixes: `a9ff785e44` ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas") Signed-off-by: Shiraz Hashim <shashim@codeaurora.org> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:53 +08:00
NeilBrown	d2d9e9edf9	md/raid5: fix another livelock caused by non-aligned writes. commit `b1b02fe97f` upstream. If a non-page-aligned write is destined for a device which is missing/faulty, we can deadlock. As the target device is missing, a read-modify-write cycle is not possible. As the write is not for a full-page, a recontruct-write cycle is not possible. This should be handled by logic in fetch_block() which notices there is a non-R5_OVERWRITE write to a missing device, and so loads all blocks. However since commit `67f455486d`, that code requires STRIPE_PREREAD_ACTIVE before it will active, and those circumstances never set STRIPE_PREREAD_ACTIVE. So: in handle_stripe_dirtying, if neither rmw or rcw was possible, set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set after a suitable delay. Fixes: `67f455486d` Reported-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:53 +08:00
Sachin Prabhu	0e8422433e	Complete oplock break jobs before closing file handle commit `ca7df8e0bb` upstream. Commit `c11f1df500` requires writers to wait for any pending oplock break handler to complete before proceeding to write. This is done by waiting on bit CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is cleared by the oplock break handler job queued on the workqueue once it has completed handling the oplock break allowing writers to proceed with writing to the file. While testing, it was noticed that the filehandle could be closed while there is a pending oplock break which results in the oplock break handler on the cifsiod workqueue being cancelled before it has had a chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit. Any subsequent attempt to write to this file hangs waiting for the CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared. We fix this by ensuring that we also clear the bit CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler from the workqueue. The bug was found by Red Hat QA while testing using ltp's fsstress command. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Acked-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Jeff Layton <jlayton@samba.org> Signed-off-by: Steve French <steve.french@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:52 +08:00
Will Deacon	714a56fcac	ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover commit `8e64806672` upstream. Commit `e1a5848e33` ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") removed the use of the reserved TTBR0 value for LPAE systems, since the ASID is held in the TTBR and can be updated atomicly with the pgd of the next mm. Unfortunately, this patch forgot to update flush_context, which deliberately avoids marking the local active ASID as allocated, since we used to switch via ASID zero and didn't need to allocate the ASID of the previous mm. The side-effect of this is that we can allocate the same ASID to the next mm and, between flushing the local TLB and updating TTBR0, we can perform speculative TLB fills for userspace nG mappings using the page table of the previous mm. The consequence of this is that the next mm can erroneously hit some mappings of the previous mm. Note that this was made significantly harder to hit by `a391263cd8` ("ARM: 8203/1: mm: try to re-use old ASID assignments following a rollover") but is still theoretically possible. This patch fixes the problem by removing the code from flush_context that forces the allocated ASID to zero for the local CPU. Many thanks to the Broadcom guys for tracking this one down. Fixes: `e1a5848e33` ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") Reported-by: Raymond Ngun <rngun@broadcom.com> Tested-by: Raymond Ngun <rngun@broadcom.com> Reviewed-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:52 +08:00
James Hogan	2e9560ee64	MIPS: traps: Fix inline asm ctc1 missing .set hardfloat commit `d76e9b9fc5` upstream. Commit `842dfc11ea` ("MIPS: Fix build with binutils 2.24.51+") in v3.18 enabled -msoft-float and sprinkled ".set hardfloat" where necessary to use FP instructions. However it missed enable_restore_fp_context() which since v3.17 does a ctc1 with inline assembly, causing the following assembler errors on Mentor's 2014.05 toolchain: {standard input}: Assembler messages: {standard input}:2913: Error: opcode not supported on this processor: mips32r2 (mips32r2) `ctc1 $2,$31' scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed Fix that to use the new write_32bit_cp1_register() macro so that ".set hardfloat" is automatically added when -msoft-float is in use. Fixes `842dfc11ea` ("MIPS: Fix build with binutils 2.24.51+") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9173/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:52 +08:00
James Hogan	061aa85590	MIPS: mipsregs.h: Add write_32bit_cp1_register() commit `5e32033e14` upstream. Add a write_32bit_cp1_register() macro to compliment the read_32bit_cp1_register() macro. This is to abstract whether .set hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT. The implementation of _read_32bit_cp1_register() .sets mips1 due to failure of gas v2.19 to assemble cfc1 for Octeon (see commit `25c3000300` ("MIPS: Override assembler target architecture for octeon.")). I haven't copied this over to _write_32bit_cp1_register() as I'm uncertain whether it applies to ctc1 too, or whether anybody cares about that version of binutils any longer. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9172/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:52 +08:00
Hemmo Nieminen	69ab8e5c2c	MIPS: Fix kernel lockup or crash after CPU offline/online commit `c7754e7510` upstream. As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: Hemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8953/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:52 +08:00
Aaro Koskinen	a88c24fa09	MIPS: OCTEON: fix kernel crash when offlining a CPU commit `63a87fe0d0` upstream. octeon_cpu_disable() will unconditionally enable interrupts when called. We can assume that the routine is always called with interrupts disabled, so just delete the incorrect local_irq_disable/enable(). The patch fixes the following crash when offlining a CPU: [ 93.818785] ------------[ cut here ]------------ [ 93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 flush_smp_call_function_queue+0x1c4/0x1d0() [ 93.836215] Modules linked in: [ 93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.19.0-rc4-octeon-los_b5f0 #1 [ 93.847212] Stack : 0000000000000001 ffffffff81b2cf90 0000000000000004 ffffffff81630000 0000000000000000 0000000000000000 0000000000000000 000000000000004a 0000000000000006 ffffffff8117e550 0000000000000000 0000000000000000 ffffffff81b30000 ffffffff81b26808 8000000032c77748 ffffffff81627e07 ffffffff81595ec8 ffffffff81b26808 000000000000000a 0000000000000001 0000000000000001 0000000000000003 0000000010008ce1 ffffffff815030c8 8000000032cbbb38 ffffffff8113d42c 0000000010008ce1 ffffffff8117f36c 8000000032c77300 8000000032cbba50 0000000000000001 ffffffff81503984 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff81121668 0000000000000000 0000000000000000 ... [ 93.912819] Call Trace: [ 93.915273] [<ffffffff81121668>] show_stack+0x68/0x80 [ 93.920335] [<ffffffff81503984>] dump_stack+0x6c/0x90 [ 93.925395] [<ffffffff8113d58c>] warn_slowpath_common+0x94/0xd8 [ 93.931324] [<ffffffff811a402c>] flush_smp_call_function_queue+0x1c4/0x1d0 [ 93.938208] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108 [ 93.943444] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8 [ 93.949286] [<ffffffff8113d704>] cpu_notify+0x24/0x60 [ 93.954348] [<ffffffff81501738>] take_cpu_down+0x38/0x58 [ 93.959670] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180 [ 93.965250] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160 [ 93.971093] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8 [ 93.976936] [<ffffffff8115ab04>] kthread+0xd4/0xf0 [ 93.981735] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c [ 93.987835] [ 93.989326] ---[ end trace c9e3815ee655bda9 ]--- [ 93.993951] Kernel bug detected[#1]: [ 93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: G W 3.19.0-rc4-octeon-los_b5f0 #1 [ 94.006591] task: 8000000032c77300 ti: 8000000032cb8000 task.ti: 8000000032cb8000 [ 94.014081] $ 0 : 0000000000000000 0000000010000ce1 0000000000000001 ffffffff81620000 [ 94.022146] $ 4 : 8000000002c72ac0 0000000000000000 00000000000001a7 ffffffff813b06f0 [ 94.030210] $ 8 : ffffffff813b20d8 0000000000000000 0000000000000000 ffffffff81630000 [ 94.038275] $12 : 0000000000000087 0000000000000000 0000000000000086 0000000000000000 [ 94.046339] $16 : ffffffff81623168 0000000000000001 0000000000000000 0000000000000008 [ 94.054405] $20 : 0000000000000001 0000000000000001 0000000000000001 0000000000000003 [ 94.062470] $24 : 0000000000000038 ffffffff813b7f10 [ 94.070536] $28 : 8000000032cb8000 8000000032cbbc20 0000000010008ce1 ffffffff811bcaf4 [ 94.078601] Hi : 0000000000f188e8 [ 94.082179] Lo : d4fdf3b646c09d55 [ 94.085760] epc : ffffffff811bc9d0 irq_work_run_list+0x8/0xf8 [ 94.091686] Tainted: G W [ 94.095613] ra : ffffffff811bcaf4 irq_work_run+0x34/0x60 [ 94.101192] Status: 10000ce3 KX SX UX KERNEL EXL IE [ 94.106235] Cause : 40808034 [ 94.109119] PrId : 000d9301 (Cavium Octeon II) [ 94.113653] Modules linked in: [ 94.116721] Process migration/1 (pid: 10, threadinfo=8000000032cb8000, task=8000000032c77300, tls=0000000000000000) [ 94.127168] Stack : 8000000002c74c80 ffffffff811a4128 0000000000000001 ffffffff81635720 fffffffffffffff2 ffffffff8115bacc 80000000320fbce0 80000000320fbca4 80000000320fbc80 0000000000000002 0000000000000004 ffffffff8113d704 80000000320fbce0 ffffffff81501738 0000000000000003 ffffffff811b343c 8000000002c72aa0 8000000002c72aa8 ffffffff8159cae8 ffffffff8159caa0 ffffffff81650000 80000000320fbbf0 80000000320fbc80 ffffffff811b32e8 0000000000000000 ffffffff811b3768 ffffffff81622b80 ffffffff815148a8 8000000032c77300 8000000002c73e80 ffffffff815148a8 8000000032c77300 ffffffff81622b80 ffffffff815148a8 8000000032c77300 ffffffff81503f48 ffffffff8115ea0c ffffffff81620000 0000000000000000 ffffffff81174d64 ... [ 94.192771] Call Trace: [ 94.195222] [<ffffffff811bc9d0>] irq_work_run_list+0x8/0xf8 [ 94.200802] [<ffffffff811bcaf4>] irq_work_run+0x34/0x60 [ 94.206036] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108 [ 94.211269] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8 [ 94.217111] [<ffffffff8113d704>] cpu_notify+0x24/0x60 [ 94.222171] [<ffffffff81501738>] take_cpu_down+0x38/0x58 [ 94.227491] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180 [ 94.233072] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160 [ 94.238914] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8 [ 94.244757] [<ffffffff8115ab04>] kthread+0xd4/0xf0 [ 94.249555] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c [ 94.255654] [ 94.257146] Code: a2423c40 40026000 30420001 <00020336> dc820000 10400037 00000000 0000010f 0000010f [ 94.267183] ---[ end trace c9e3815ee655bdaa ]--- [ 94.271804] Fatal exception: panic in 5 seconds Reported-by: Hemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8952/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:51 +08:00
Felix Fietkau	83c9c2c5a8	MIPS: IRQ: Fix disable_irq on CPU IRQs commit `a3e6c1eff5` upstream. If the irq_chip does not define .irq_disable, any call to disable_irq will defer disabling the IRQ until it fires while marked as disabled. This assumes that the handler function checks for this condition, which handle_percpu_irq does not. In this case, calling disable_irq leads to an IRQ storm, if the interrupt fires while disabled. This optimization is only useful when disabling the IRQ is slow, which is not true for the MIPS CPU IRQ. Disable this optimization by implementing .irq_disable and .irq_enable Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8949/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:51 +08:00
David Daney	dbbd278880	MIPS: Fix C0_Pagegrain[IEC] support. commit `9ead8632bb` upstream. The following commits: `5890f70f15` (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions) `6575b1d417` (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions) break the kernel for all existing MIPS CPUs that implement the CP0_PageGrain[IEC] bit. They cause the TLB exception handlers to be generated without the legacy execute-inhibit handling, but never set the CP0_PageGrain[IEC] bit to activate the use of dedicated exception vectors for execute-inhibit exceptions. The result is that upon detection of an execute-inhibit violation, we loop forever in the TLB exception handlers instead of sending SIGSEGV to the task. If we are generating TLB exception handlers expecting separate vectors, we must also enable the CP0_PageGrain[IEC] feature. The bug was introduced in kernel version 3.17. Signed-off-by: David Daney <david.daney@cavium.com> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/8880/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:51 +08:00
Brian King	458919c470	sd: Fix max transfer length for 4k disks commit `3a9794d329` upstream. The following patch fixes an issue observed with 4k sector disks where the max_hw_sectors attribute was getting set too large in sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units of SCSI logical blocks and queue_max_hw_sectors is in units of 512 byte blocks, on a 4k sector disk, every time we went through sd_revalidate_disk, we were taking the current value of queue_max_hw_sectors and increasing it by a factor of 8. Fix this by only shifting sdkp->max_xfer_blocks. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:51 +08:00
Robin Gong	0ee291a9b4	spi: imx: use pio mode for i.mx6dl commit `a02bb401f8` upstream. For TKT238285 hardware issue which may cause txfifo store data twice can only be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl. Fixes: `f62caccd12` (spi: spi-imx: add DMA support) Signed-off-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:51 +08:00
Bhuvanchandra DV	6fe528da40	spi: spi-fsl-dspi: Remove usage of devm_kzalloc commit `973fbce69e` upstream. devm_* API was supposed to be used only in probe function call. Memory is allocated at 'probe' and free automatically at 'remove'. Usage of devm_* functions outside probe sometimes leads to memory leak. Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead. Also add the dspi_cleanup function to free the controller data upon cleanup. Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Myron Stowe	96c55843d5	PCI: Handle read-only BARs on AMD CS553x devices commit `06cf35f903` upstream. Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after `36e8164882` ("PCI: Restore detection of read-only BARs"). Prior to `36e8164882`, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to `36e8164882`, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: `36e8164882` ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf Reported-and-tested-by: Nix <nix@esperi.org.uk> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Charlotte Richardson	42dcb70566	PCI: Add NEC variants to Stratus ftServer PCIe DMI check commit `51ac3d2f0c` upstream. NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: `1278998f8f` ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by: Charlotte Richardson <charlotte.richardson@stratus.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Lucas Stach	0df05be2d8	PCI: designware: Reject MSI-X IRQs commit `19c5392eb1` upstream. The DesignWare PCIe MSI hardware does not support MSI-X IRQs. Setting those up failed as a side effect of a bug which was fixed by `91f8ae823f` ("PCI: designware: Setup and clear exactly one MSI at a time"). Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly; otherwise devices trying to use them may end up with incorrectly working interrupts. Fixes: `91f8ae823f` ("PCI: designware: Setup and clear exactly one MSI at a time") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Sonic Zhang	9a42a8a458	gpio: mcp23s08: handle default gpio base commit `b184c388f7` upstream. Create default gpio base if neither device node nor platform data is defined. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Antonio Fiol <antonio@fiol.es> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Johan Hovold	64f2260ea2	gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low commit `49d2ca84e4` upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when setting the gpio-line polarity. Fixes: `0769746183` ("gpiolib: add support for changing value polarity in sysfs") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Johan Hovold	22f837c860	gpio: sysfs: fix memory leak in gpiod_export_link commit `0f303db08d` upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when creating a link. Fixes: `a4177ee7f1` ("gpiolib: allow exported GPIO nodes to be named using sysfs links") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-11 15:00:50 +08:00
Greg Kroah-Hartman	9960914954	Linux 3.18.6	2015-02-06 06:53:48 -08:00
Stefano Stabellini	a6df136317	xen/arm/arm64: introduce xen_arch_need_swiotlb commit `a4dba13089` upstream. Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer. On ARM and ARM64, if the page involved is a foreign page and the device is not coherent, we need to bounce because at unmap time we cannot execute any required cache maintenance operations (we don't know how to find the pfn from the mfn). No change of behaviour for x86. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:10 -08:00
Catalin Marinas	b2f21d1b7b	clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64 commit `d6ad369130` upstream. Commit `0b46b8a718` (clocksource: arch_timer: Fix code to use physical timers when requested) introduces the use of physical counters in the ARM architected timer driver. However, he arm64 kernel uses CNTVCT in VDSO. When booting in EL2, the kernel switches to the physical timers to make things easier for KVM but it continues to use the virtual counter both in user and kernel. While in such scenario CNTVCT == CNTPCT (since CNTVOFF is initialised by the kernel to 0), we want to spot firmware bugs corrupting CNTVOFF early (which would affect CNTVCT). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: `0b46b8a718` ("clocksource: arch_timer: Fix code to use physical timers when requested") Cc: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Viktor Babrian	793332a443	can: c_can: end pending transmission on network stop (ifdown) commit `7ffd7b4e16` upstream. Put controller into init mode in network stop to end pending transmissions. The issue is observed in cases when transmitted frame is not acked. Signed-off-by: Viktor Babrian <babrian.viktor@renyi.mta.hu> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Andrew Duggan	427a5746b4	HID: rmi: Check for additional ACM registers appended to F11 data report commit `8414947a20` upstream. If a touchpad reports the F11 data40 register then this indicates that the touchpad reports additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention report. These additional bytes shift the position of the F30 button data causing the driver to incorrectly report button state when this functionality is present. This patch accounts for the additional data in the report. Fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533 Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Stephane Eranian	ce9555406a	perf/rapl: Fix crash in rapl_scale() commit `98b008dff8` upstream. This patch fixes a systematic crash in rapl_scale() due to an invalid pointer. The bug was introduced by commit: `89cbc76768` ("x86: Replace __get_cpu_var uses") The fix is simple. Just put the parenthesis where it needs to be, i.e., around rapl_pmu. To my surprise, the compiler was not complaining about passing an integer instead of a pointer. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Tested-by: Vince Weaver <vincent.weaver@maine.edu> Fixes: `89cbc76768` ("x86: Replace __get_cpu_var uses") Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: cl@linux.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20150122203834.GA10228@thinkpad Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Kan Liang	09c0adc993	perf/x86/intel: Add model number for Airmont commit `ef454caeb7` upstream. Intel Airmont supports the same architectural and non-architectural performance monitoring events as Silvermont. Signed-off-by: Kan Liang <kan.liang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1421913053-99803-1-git-send-email-kan.liang@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Greg Thelen	5a4a00b10a	memcg: remove extra newlines from memcg oom kill log commit `0346dadbf0` upstream. Commit `e61734c55c` ("cgroup: remove cgroup->name") added two extra newlines to memcg oom kill log messages. This makes dmesg hard to read and parse. The issue affects 3.15+. Example: Task in /t <<< extra #1 killed as a result of limit of /t <<< extra #2 memory: usage 102400kB, limit 102400kB, failcnt 274712 Remove the extra newlines from memcg oom kill messages, so the messages look like: Task in /t killed as a result of limit of /t memory: usage 102400kB, limit 102400kB, failcnt 240649 Fixes: `e61734c55c` ("cgroup: remove cgroup->name") Signed-off-by: Greg Thelen <gthelen@google.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Jan Kara	8a71cc4d08	quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units commit `14bf61ffe6` upstream. Currently ->get_dqblk() and ->set_dqblk() use struct fs_disk_quota which tracks space limits and usage in 512-byte blocks. However VFS quotas track usage in bytes (as some filesystems require that) and we need to somehow pass this information. Upto now it wasn't a problem because we didn't do any unit conversion (thus VFS quota routines happily stuck number of bytes into d_bcount field of struct fd_disk_quota). Only if you tried to use Q_XGETQUOTA or Q_XSETQLIM for VFS quotas (or Q_GETQUOTA / Q_SETQUOTA for XFS quotas), you got bogus results. Hardly anyone tried this but reportedly some Samba users hit the problem in practice. So when we want interfaces compatible we need to fix this. We bite the bullet and define another quota structure used for passing information from/to ->get_dqblk()/->set_dqblk. It's somewhat sad we have to have more conversion routines in fs/quota/quota.c and another copying of quota structure slows down getting of quota information by about 2% but it seems cleaner than overloading e.g. units of d_bcount to bytes. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:09 -08:00
Jeremiah Mahler	77ca136e76	drm/i915: fix inconsistent brightness after resume commit `13f3fbe827` upstream. commit `6dda730e55` Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness introduced a bug which resulted in inconsistent brightness levels on different machines. If a suspended was entered with the screen off some machines would resume with the screen at minimum brightness and others at maximum brightness. The following commands can be used to produce this behavior. xset dpms force off sleep 1 sudo systemctl suspend (resume ...) The root cause of this problem is a comparison which checks to see if the backlight level is zero when the panel is enabled. If it is zero, it is set to the maximum level. Unfortunately, not all machines have a minimum level of zero. On those machines the level is left at the minimum instead of begin set to the maximum. Fix the bug by updating the comparison to check for the minimum backlight level instead of zero. Also, expand the comparison for the possible case when the level is less than the minimum. Fixes: `6dda730e55` ("respect the VBT minimum backlight brightness") Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:08 -08:00
David Woodhouse	50a466845f	drm/i915: Init PPGTT before context enable commit `f48a01651b` upstream. Commit `82460d972` ("drm/i915: Rework ppgtt init to no require an aliasing ppgtt") introduced a regression on Broadwell, triggering the following IOMMU fault at startup: vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem dmar: DRHD: handling fault status reg 2 dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000 DMAR:[fault reason 23] Unknown fbcon: inteldrmfb (fb0) is primary device Further commentary from Daniel: I sugggested this change to David after staring at the offending patch for a while. I have no idea and theory whatsoever why this would upset the gpu less than the other way round. But it seems to work. David promised to chase hw people a bit more to get a more meaningful answer. Wrt the comment that this deletes: I've done some digging and afaict loading context before ppgtt enable was once required before our recent restructuring of the context/ppgtt init code: Before that context sw setup (i.e. allocating the default context) and hw setup was smashed together. Also the setup of the default context was the bit that actually allocated the aliasing ppgtt structures. Which is the reason for the context before ppgtt depency. Or was, since with all the untangling there's no no real depency any more (functional, who knows what the hw is doing), so the comment is just stale. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:08 -08:00
Rodrigo Vivi	bcee607f44	drm/i915: BDW Fix Halo PCI IDs marked as ULT. commit `6b96d705f3` upstream. BDW with PCI-IDs ended in "2" aren't ULT, but HALO. Let's fix it and at least allow VGA to work on this units. v2: forgot ammend and v1 doesn't compile Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220 Cc: Xion Zhang <xiong.y.zhang@intel.com> Cc: Guo Jinxian <jinxianx.guo@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:08 -08:00
Bob Paauwe	817697b83f	drm/i915: Only fence tiled region of object. commit `af1a7301c7` upstream. When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by: Dan Hettena <danh@ghs.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:08 -08:00
Rob Clark	e63fea1633	drm: fix fb-helper vs MST dangling connector ptrs (v2) commit `2148f18fdb` upstream. VT switch back/forth from console to xserver (for example) has potential to go horribly wrong if a dynamic DP MST connector ends up in the saved modeset that is restored when switching back to fbcon. When removing a dynamic connector, don't forget to clean up the saved state. v1: original v2: null out set->fb if no more connectors to avoid making i915 cranky Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968 Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:08 -08:00
Mugunthan V N	f1d5aa4663	drivers: net: cpsw: discard dual emac default vlan configuration commit `02a54164c5` upstream. In Dual EMAC, the default VLANs are used to segregate Rx packets between the ports, so adding the same default VLAN to the switch will affect the normal packet transfers. So returning error on addition of dual EMAC default VLANs. Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to break dual EMAC port separations. Fixes: `d9ba8f9e62` (driver: net: ethernet: cpsw: dual emac interface implementation) Reported-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Ashay Jaiswal	ba31c58d46	regulator: core: fix race condition in regulator_put() commit `83b0302d34` upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Andrey Ryabinin	198bcce84a	drivers/rtc/rtc-s5m.c: terminate s5m_rtc_id array with empty element commit `45cd15e600` upstream. Array of platform_device_id elements should be terminated with empty element. Fixes: `5bccae6ec4` ("rtc: s5m-rtc: add real-time clock driver for s5m8767") Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Mika Westerberg	072ef65108	spi/pxa2xx: Clear cur_chip pointer before starting next message commit `c957e8f084` upstream. Once the current message is finished, the driver notifies SPI core about this by calling spi_finalize_current_message(). This function queues next message to be transferred. If there are more messages in the queue, it is possible that the driver is asked to transfer the next message at this point. When spi_finalize_current_message() returns the driver clears the drv_data->cur_chip pointer to NULL. The problem is that if the driver already started the next message clearing drv_data->cur_chip will cause NULL pointer dereference which crashes the kernel like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] PGD 78bb8067 PUD 37712067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 RIP: 0010:[<ffffffffa0022bc8>] [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 Stack: ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 Call Trace: [<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform] [<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] [<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830 [<ffffffff81049679>] tasklet_action+0xa9/0xe0 [<ffffffff81049a0e>] __do_softirq+0xee/0x280 [<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40 [<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0 [<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150 [<ffffffff81060f9d>] kthread+0xcd/0xf0 [<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180 [<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0 Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). Reported-by: Martin Oldfield <m@mjoldfield.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Michel Dänzer	d483628b80	drm/radeon: Restore GART table contents after pinning it in VRAM v3 commit `5636d2f842` upstream. The GART table BO has to be moved out of VRAM for suspend/resume. Any updates to the GART table during that time were silently dropped without this change. This caused GPU lockups on resume in some cases, see the bug reports referenced below. This might also make GPU reset more robust in some cases, as we no longer rely on the GART table in VRAM being preserved across the GPU lockup/reset. v2: Add logic to radeon_gart_table_vram_pin directly instead of reinstating radeon_gart_restore v3: Move code after assignment of rdev->gart.table_addr so that the GART TLB flush can work as intended, add code comment explaining why we're doing this Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Michel Dänzer	588039c336	drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry commit `cb65890610` upstream. get_page_entry calculates the GART page table entry, which is just written to the GART page table by set_page_entry. This is a prerequisite for the following fix. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:07 -08:00
Thomas Hellstrom	c818bed668	drm/vmwgfx: Replace the hw mutex with a hw spinlock commit `496eb6fd2c` upstream. Fixes a case where we call vmw_fifo_idle() from within a wait function with task state !TASK_RUNNING, which is illegal. In addition, make the locking fine-grained, so that it is performed once for every read- and write operation. This is of course more costly, but we don't perform much register access in the timing critical paths anyway. Instead we have the extra benefit of being sure that we don't forget the hw lock around register accesses. I think currently the kms code was quite buggy w r t this. This fixes Red Hat Bugzilla Bug 1180796 Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:06 -08:00
Joe Thornber	bc8eeafab3	dm cache: fix missing ERR_PTR returns and handling commit `766a78882d` upstream. Commit `9b1cc9f251` ("dm cache: share cache-metadata object across inactive and active DM tables") mistakenly ignored the use of ERR_PTR returns. Restore missing IS_ERR checks and ERR_PTR returns where appropriate. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:06 -08:00
Joe Thornber	e046f3ddf3	dm thin: don't allow messages to be sent to a pool target in READ_ONLY or FAIL mode commit `2a7eaea02b` upstream. You can't modify the metadata in these modes. It's better to fail these messages immediately than let the block-manager deny write locks on metadata blocks. Otherwise these failed metadata changes will trigger 'needs_check' to get set in the metadata superblock -- requiring repair using the thin_check utility. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:06 -08:00
Thomas Petazzoni	6ab11bbf0e	ARM: mvebu: don't set the PL310 in I/O coherency mode when I/O coherency is disabled commit `dcad68876c` upstream. Since commit `f2c3c67f00` (merge commit that adds commit "ARM: mvebu: completely disable hardware I/O coherency"), we disable I/O coherency on Armada EBU platforms. However, we continue to initialize the coherency fabric, because this coherency fabric is needed on Armada XP for inter-CPU coherency. Unfortunately, due to this, we also continued to execute the coherency fabric initialization code for Armada 375/38x, which switched the PL310 into I/O coherent mode. This has the effect of disabling the outer cache sync operation: this is needed when I/O coherency is enabled to work around a PCIe/L2 deadlock. But obviously, when I/O coherency is disabled, having the outer cache sync operation is crucial. Therefore, this commit fixes the armada_375_380_coherency_init() so that the PL310 is switched to I/O coherent mode only if I/O coherency is enabled. Without this fix, all devices using DMA are broken on Armada 375/38x. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:06 -08:00
Jean-Christophe PLAGNIOL-VILLARD	d5b4818420	pinctrl: at91: allow to have disabled gpio bank commit `a0b957f306` upstream. Today we expect that all the bank are enabled, and count the number of banks used by the pinctrl based on it instead of using the last bank id enabled. So switch to it, set the chained IRQ at runtime based on enabled banks and wait only the number of enabled gpio controllers at probe time. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:06 -08:00
Johannes Berg	a916db4b25	nl80211: fix per-station group key get/del and memory leak commit `0fa7b39131` upstream. In case userspace attempts to obtain key information for or delete a unicast key, this is currently erroneously rejected unless the driver sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it was never noticed. Fix that, and while at it fix a potential memory leak: the error path in the get_key() function was placed after allocating a message but didn't free it - move it to a better place. Luckily admin permissions are needed to call this operation. Fixes: `e31b82136d` ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:05 -08:00
Luciano Coelho	d75bd2a694	mac80211: only roll back station states for WDS when suspending commit `2af81d6718` upstream. In normal cases (i.e. when we are fully associated), cfg80211 takes care of removing all the stations before calling suspend in mac80211. But in the corner case when we suspend during authentication or association, mac80211 needs to roll back the station states. But we shouldn't roll back the station states in the suspend function, because this is taken care of in other parts of the code, except for WDS interfaces. For AP types of interfaces, cfg80211 takes care of disconnecting all stations before calling the driver's suspend code. For station interfaces, this is done in the quiesce code. For WDS interfaces we still need to do it here, so move the code into a new switch case for WDS. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:05 -08:00
Mathy Vanhoef	aefbc0b5c6	mac80211: properly set CCK flag in radiotap commit `3a5c5e81d8` upstream. Fix a regression introduced by commit `a5e70697d0` ("mac80211: add radiotap flag and handling for 5/10 MHz") where the IEEE80211_CHAN_CCK channel type flag was incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by using the CCK flag again. Fixes: `a5e70697d0` ("mac80211: add radiotap flag and handling for 5/10 MHz") Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:05 -08:00
Trond Myklebust	0c217359ae	NFSv4.1: Fix an Oops in nfs41_walk_client_list commit `3175e1dcec` upstream. If we start state recovery on a client that failed to initialise correctly, then we are very likely to Oops. Reported-by: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Link: http://lkml.kernel.org/r/130621862.279655.1421851650684.JavaMail.zimbra@desy.de Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:05 -08:00
Peng Tao	19387f4d87	nfs: fix dio deadlock when O_DIRECT flag is flipped commit `ee8a1a8b16` upstream. We only support swap file calling nfs_direct_IO. However, application might be able to get to nfs_direct_IO if it toggles O_DIRECT flag during IO and it can deadlock because we grab inode->i_mutex in nfs_file_direct_write(). So return 0 for such case. Then the generic layer will fall back to buffer IO. Signed-off-by: Peng Tao <tao.peng@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:05 -08:00
Jochen Hein	203ba54a3d	Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857) commit `1d90d6d552` upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. With this patch the touchpad is detected: $ dmesg \| grep -E "(SYN\|i8042\|serio)" pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active) i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6 dmidecode excerpt for this laptop is: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Medion Product Name: Akoya E7225 Version: 1.0 Signed-off-by: Jochen Hein <jochen@jochen.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Rainer Koenig	424befd7b1	Input: elantech - add more Fujtisu notebooks to force crc_enabled commit `47c1ffb2b6` upstream. Add two more Fujitsu LIFEBOOK models that also ship with the Elantech touchpad and don't work with crc_disabled to the quirk list. Signed-off-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Peter Hutterer	74a0ac496f	Input: synaptics - adjust min/max for Lenovo ThinkPad X1 Carbon 2nd commit `8543cf1c24` upstream. LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model) Reported-and-tested-by: Bjoern Olausson <bjoern@olausson.de> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Paul Osmialowski	5e1b35cfd6	i2c: s3c2410: fix ABBA deadlock by keeping clock prepared commit `34e81ad5f0` upstream. This patch solves deadlock between clock prepare mutex and regmap mutex reported by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock of the i2c controller in a prepared state". [1] https://lkml.org/lkml/2014/7/2/171 [2] https://lkml.org/lkml/2014/7/2/207 On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was called, which calls clk_prepare() then clk_enable(). clk_prepare() takes prepare_lock mutex before proceeding. Note that i2c transfer functions are invoked from many places in kernel, typically with some other additional lock held. It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to proceed (so it needs to obtain clock related prepare_lock mutex during transfer preparation stage due to clk_prepare() call). At the same time other task on CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason) so it has taken prepare_lock mutex. CPU0: CPU1: clk_disable_unused() regulator_disable() clk_prepare_lock() map->lock(map->lock_arg) regmap_read() s3c24xx_i2c_xfer() map->lock(map->lock_arg) clk_prepare_lock() Implemented solution from [2] leaves i2c clock prepared. Preparation is done in s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared by clk_disable_unprepare() call. I've replaced this call with clk_disable() and I've added clk_unprepare() call in s3c24xx_i2c_remove(). The s3c24xx_i2c_xfer() function now uses clk_enable() instead of clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()). Signed-off-by: Paul Osmialowski <p.osmialowsk@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Hans de Goede	f1764f870c	uas: Add no-report-opcodes quirk for Simpletech devices with id 4971:8017 commit `8a870880bd` upstream. Like some other uas devices these devices hang when a report-opcodes scsi command is send to them. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1124119 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Dmitry Nezhevenko	6e340560ac	usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller commit `bf5c4136fa` upstream. It looks like FUA support is broken on JMicron 152d:2566 bridge: [223159.885704] sd 7:0:0:0: [sdc] Write Protect is off [223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08 [223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [223283.691677] sd 7:0:0:0: [sdc] [223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [223283.691681] sd 7:0:0:0: [sdc] [223283.691682] Sense Key : Illegal Request [current] [223283.691684] sd 7:0:0:0: [sdc] [223283.691685] Add. Sense: Invalid field in cdb [223283.691686] sd 7:0:0:0: [sdc] CDB: [223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00 [223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584 This patch adds blacklist flag so that sd will not use FUA Signed-off-by: Dmitry Nezhevenko <dion@dion.org.ua> Cc: Phil Dibowitz <phil@ipom.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Macpaul Lin	f97b23ddb4	USB: Add OTG PET device to TPL commit `e5dff0e804` upstream. OTG device shall support this device for allowing compliance automated testing. The modification is derived from Pavankumar and Vijayavardhans' previous work. Signed-off-by: Macpaul Lin <macpaul@gmail.com> Cc: Pavankumar Kondeti <pkondeti@codeaurora.org> Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Ilya Dryomov	0539097d55	rbd: fix rbd_dev_parent_get() when parent_overlap == 0 commit `ae43e9d05e` upstream. The comment for rbd_dev_parent_get() said * We must get the reference before checking for the overlap to * coordinate properly with zeroing the parent overlap in * rbd_dev_v2_parent_info() when an image gets flattened. We * drop it again if there is no overlap. but the "drop it again if there is no overlap" part was missing from the implementation. This lead to absurd parent_ref values for images with parent_overlap == 0, as parent_ref was incremented for each img_request and virtually never decremented. Fix this by leveraging the fact that refresh path calls rbd_dev_v2_parent_info() under header_rwsem and use it for read in rbd_dev_parent_get(), instead of messing around with atomics. Get rid of barriers in rbd_dev_v2_parent_info() while at it - I don't see what they'd pair with now and I suspect we are in a pretty miserable situation as far as proper locking goes regardless. Signed-off-by: Ilya Dryomov <idryomov@redhat.com> Reviewed-by: Josh Durgin <jdurgin@redhat.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Ilya Dryomov	186eb06e60	rbd: drop parent_ref in rbd_dev_unprobe() unconditionally commit `e69b8d414f` upstream. This effectively reverts the last hunk of `392a9dad7e` ("rbd: detect when clone image is flattened"). The problem with parent_overlap != 0 condition is that it's possible and completely valid to have an image with parent_overlap == 0 whose parent state needs to be cleaned up on unmap. The next commit, which drops the "clone image now standalone" logic, opens up another window of opportunity to hit this, but even without it # cat parent-ref.sh #!/bin/bash rbd create --image-format 2 --size 1 foo rbd snap create foo@snap rbd snap protect foo@snap rbd clone foo@snap bar rbd resize --allow-shrink --size 0 bar rbd resize --size 1 bar DEV=$(rbd map bar) rbd unmap $DEV leaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client hanging around. My thinking behind calling rbd_dev_parent_put() unconditionally is that there shouldn't be any requests in flight at that point in time as we are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused by flatten is delayed by in-flight requests, it will have finished by the time we reach rbd_dev_unprobe() caused by unmap, thus turning unconditional rbd_dev_parent_put() into a no-op. Fixes: http://tracker.ceph.com/issues/10352 Signed-off-by: Ilya Dryomov <idryomov@redhat.com> Reviewed-by: Josh Durgin <jdurgin@redhat.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:04 -08:00
Clemens Ladisch	a95d838145	ALSA: seq-dummy: remove deadlock-causing events on close commit `0767e95bb9` upstream. When the last subscriber to a "Through" port has been removed, the subscribed destination ports might still be active, so it would be wrong to send "all sounds off" and "reset controller" events to them. The proper place for such a shutdown would be the closing of the actual MIDI port (and close_substream() in rawmidi.c already can do this). This also fixes a deadlock when dummy_unuse() tries to send events to its own port that is already locked because it is being freed. Reported-by: Peter Billam <peter@www.pjb.com.au> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Laurent Dufour	71708851d3	powerpc/xmon: Fix another endiannes issue in RTAS call from xmon commit `e6eb2eba49` upstream. The commit `3b8a3c0109` ("powerpc/pseries: Fix endiannes issue in RTAS call from xmon") was fixing an endianness issue in the call made from xmon to RTAS. However, as Michael Ellerman noticed, this fix was not complete, the token value was not byte swapped. This lead to call an unexpected and most of the time unexisting RTAS function, which is silently ignored by RTAS. This fix addresses this hole. Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Ahmed S. Darwish	bccd8fd860	can: kvaser_usb: Fix state handling upon BUS_ERROR events commit `e638642b08` upstream. While being in an ERROR_WARNING state, and receiving further bus error events with error counters still in the ERROR_WARNING range of 97-127 inclusive, the state handling code erroneously reverts back to ERROR_ACTIVE. Per the CAN standard, only revert to ERROR_ACTIVE when the error counters are less than 96. Moreover, in certain Kvaser models, the BUS_ERROR flag is always set along with undefined bits in the M16C status register. Thus use bitwise operators instead of full equality for checking that register against bus errors. Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Ahmed S. Darwish	1c13b0f01a	can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT commit `14c10c2a1d` upstream. On some x86 laptops, plugging a Kvaser device again after an unplug makes the firmware always ignore the very first command. For such a case, provide some room for retries instead of completely exiting the driver init code. Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Ahmed S. Darwish	40b50e09ad	can: kvaser_usb: Send correct context to URB completion commit `3803fa6977` upstream. Send expected argument to the URB completion hander: a CAN netdevice instead of the network interface private context `kvaser_usb_net_priv'. This was discovered by having some garbage in the kernel log in place of the netdevice names: can0 and can1. Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Ahmed S. Darwish	97a4392559	can: kvaser_usb: Do not sleep in atomic context commit `ded5006667` upstream. Upon receiving a hardware event with the BUS_RESET flag set, the driver kills all of its anchored URBs and resets all of its transmit URB contexts. Unfortunately it does so under the context of URB completion handler `kvaser_usb_read_bulk_callback()', which is often called in an atomic context. While the device is flooded with many received error packets, usb_kill_urb() typically sleeps/reschedules till the transfer request of each killed URB in question completes, leading to the sleep in atomic bug. [3] In v2 submission of the original driver patch [1], it was stated that the URBs kill and tx contexts reset was needed since we don't receive any tx acknowledgments later and thus such resources will be locked down forever. Fortunately this is no longer needed since an earlier bugfix in this patch series is now applied: all tx URB contexts are reset upon CAN channel close. [2] Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF event, which is the recommended handling method advised by the device manufacturer. [1] http://article.gmane.org/gmane.linux.network/239442 http://www.webcitation.org/6Vr2yagAQ [2] can: kvaser_usb: Reset all URB tx contexts upon channel close `889b77f7fd` [3] Stacktrace: <IRQ> [<ffffffff8158de87>] dump_stack+0x45/0x57 [<ffffffff8158b60c>] __schedule_bug+0x41/0x4f [<ffffffff815904b1>] __schedule+0x5f1/0x700 [<ffffffff8159360a>] ? _raw_spin_unlock_irqrestore+0xa/0x10 [<ffffffff81590684>] schedule+0x24/0x70 [<ffffffff8147d0a5>] usb_kill_urb+0x65/0xa0 [<ffffffff81077970>] ? prepare_to_wait_event+0x110/0x110 [<ffffffff8147d7d8>] usb_kill_anchored_urbs+0x48/0x80 [<ffffffffa01f4028>] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb] [<ffffffffa01f45d0>] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb] [<ffffffff8108b14a>] ? vprintk_default+0x1a/0x20 [<ffffffffa01f5241>] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb] [<ffffffff8147a73e>] __usb_hcd_giveback_urb+0x5e/0xc0 [<ffffffff8147a8a1>] usb_hcd_giveback_urb+0x41/0x110 [<ffffffffa0008748>] finish_urb+0x98/0x180 [ohci_hcd] [<ffffffff810cd1a7>] ? acct_account_cputime+0x17/0x20 [<ffffffff81069f65>] ? local_clock+0x15/0x30 [<ffffffffa000a36b>] ohci_work+0x1fb/0x5a0 [ohci_hcd] [<ffffffff814fbb31>] ? process_backlog+0xb1/0x130 [<ffffffffa000cd5b>] ohci_irq+0xeb/0x270 [ohci_hcd] [<ffffffff81479fc1>] usb_hcd_irq+0x21/0x30 [<ffffffff8108bfd3>] handle_irq_event_percpu+0x43/0x120 [<ffffffff8108c0ed>] handle_irq_event+0x3d/0x60 [<ffffffff8108ec84>] handle_fasteoi_irq+0x74/0x110 [<ffffffff81004dfd>] handle_irq+0x1d/0x30 [<ffffffff81004727>] do_IRQ+0x57/0x100 [<ffffffff8159482a>] common_interrupt+0x6a/0x6a Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Jan Kara	f9525833c0	udf: Release preallocation on last writeable close commit `b07ef35244` upstream. Commit `6fb1ca92a6` "udf: Fix race between write(2) and close(2)" changed the condition when preallocation is released. The idea was that we don't want to release the preallocation for an inode on close when there are other writeable file descriptors for the inode. However the condition was written in the opposite way so we released preallocation only if there were other writeable file descriptors. Fix the problem by changing the condition properly. Fixes: `6fb1ca92a6` Reported-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Peter Ujfalusi	75229a2678	ASoC: omap-mcbsp: Correct CBM_CFS dai format configuration commit `20602e34cd` upstream. We should select FSR also to be driven by McBSP, not only FSX. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:03 -08:00
Geert Uytterhoeven	c78af34883	ASoC: simple-card: Fix crash in asoc_simple_card_unref() commit `7ddfdb5c5a` upstream. If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be called before dev_set_drvdata(), causing a NULL pointer dereference in asoc_simple_card_unref(): Unable to handle kernel NULL pointer dereference at virtual address 000000d4 ... PC is at asoc_simple_card_unref+0x14/0x48 LR is at asoc_simple_card_probe+0x3d4/0x40c This typically happens because asoc_simple_card_parse_of() returns -EPROBE_DEFER, but other failure modes are possible. devm_snd_soc_register_card()/snd_soc_register_card() may fail either before or after dev_set_drvdata(). Pass a snd_soc_card pointer instead of a platform_device pointer to asoc_simple_card_unref() to fix this. Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may optimize away the loop over card->dai_link, never actually dereferencing card, and thus avoiding the crash... Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: `e512e001da` ("ASoC: simple-card: Fix the reference count of device nodes") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:02 -08:00
Qais Yousef	971784f012	ASoC: soc-compress.c: fix NULL dereference commit `d3268a40d4` upstream. In soc_new_compress() when rtd->dai_link->dynamic is set, we create the pcm substreams with this call: ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num, 1, 0, &be_pcm); which passes 0 as capture_count leading to be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream being NULL, hence when trying to set rtd a few lines below we get an oops. Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as playback_count and capture_count to snd_pcm_new_internal(). Signed-off-by: Qais Yousef <qais.yousef@imgtec.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:02 -08:00
Aurelien BOUIN	260571582b	ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers commit `adc60298c8` upstream. The xDC field should have 5 bit width according to Reference Manual. Thus this patch fixes it. Signed-off-by: Aurelien BOUIN <a_bouin@yahoo.fr> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:02 -08:00
Peter Rosin	2b298f993f	ASoC: pcm512x: Fix DSP program selection commit `3a8e501984` upstream. The DSP programs are listed out of order. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Zidan Wang	aaadfdb3aa	ASoC: wm8960: Fix capture sample rate from 11250 to 11025 commit `22ee76dadd` upstream. wm8960 codec can't support sample rate 11250, it must be 11025. Signed-off-by: Zidan Wang <b50113@freescale.com> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Linus Torvalds	338dcaf53e	vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS commit `9c145c56d0` upstream. The stack guard page error case has long incorrectly caused a SIGBUS rather than a SIGSEGV, but nobody actually noticed until commit `fee7e49d45` ("mm: propagate error from stack expansion even for guard page") because that error case was never actually triggered in any normal situations. Now that we actually report the error, people noticed the wrong signal that resulted. So far, only the test suite of libsigsegv seems to have actually cared, but there are real applications that use libsigsegv, so let's not wait for any of those to break. Reported-and-tested-by: Takashi Iwai <tiwai@suse.de> Tested-by: Jan Engelhardt <jengelh@inai.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Guenter Roeck	4c0720f26e	arc: mm: Fix build failure commit `e262eb9381` upstream. Fix misspelled define. Fixes: `33692f2759` ("vm: add VM_FAULT_SIGSEGV handling support") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Linus Torvalds	da7f8de964	vm: add VM_FAULT_SIGSEGV handling support commit `33692f2759` upstream. The core VM already knows about VM_FAULT_SIGBUS, but cannot return a "you should SIGSEGV" error, because the SIGSEGV case was generally handled by the caller - usually the architecture fault handler. That results in lots of duplication - all the architecture fault handlers end up doing very similar "look up vma, check permissions, do retries etc" - but it generally works. However, there are cases where the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV. In particular, when accessing the stack guard page, libsigsegv expects a SIGSEGV. And it usually got one, because the stack growth is handled by that duplicated architecture fault handler. However, when the generic VM layer started propagating the error return from the stack expansion in commit `fee7e49d45` ("mm: propagate error from stack expansion even for guard page"), that now exposed the existing VM_FAULT_SIGBUS result to user space. And user space really expected SIGSEGV, not SIGBUS. To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those duplicate architecture fault handlers about it. They all already have the code to handle SIGSEGV, so it's about just tying that new return value to the existing code, but it's all a bit annoying. This is the mindless minimal patch to do this. A more extensive patch would be to try to gather up the mostly shared fault handling logic into one generic helper routine, and long-term we really should do that cleanup. Just from this patch, you can generally see that most architectures just copied (directly or indirectly) the old x86 way of doing things, but in the meantime that original x86 model has been improved to hold the VM semaphore for shorter times etc and to handle VM_FAULT_RETRY and other "newer" things, so it would be a good idea to bring all those improvements to the generic case and teach other architectures about them too. Reported-and-tested-by: Takashi Iwai <tiwai@suse.de> Tested-by: Jan Engelhardt <jengelh@inai.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Andy Shevchenko	7b483af8df	spi: dw-mid: fix FIFO size commit `67bf9cda4b` upstream. The FIFO size is 40 accordingly to the specifications, but this means 0x40, i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection for Intel MID devices. Fixes: `7063c0d942` (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:01 -08:00
Axel Lin	128e53423c	spi: dw: Fix detecting FIFO depth commit `d297933cc7` upstream. Current code tries to find the highest valid fifo depth by checking the value it wrote to DW_SPI_TXFLTR. There are a few problems in current code: 1) There is an off-by-one in dws->fifo_len setting because it assumes the latest register write fails so the latest valid value should be fifo - 1. 2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary to test fifo == 257. In the case fifo is 257, it means the latest valid setting is fifo = 256. So after the for loop iteration, we should check fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails. This patch fixes above issues. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-and-tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:00 -08:00
Kees Cook	179ac907a2	x86, build: replace Perl script with Shell script commit `d69911a68c` upstream. Commit `e6023367d7` ("x86, kaslr: Prevent .bss from overlaping initrd") added Perl to the required build environment. This reimplements in shell the Perl script used to find the size of the kernel with bss and brk added. Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Rob Landley <rob@landley.net> Acked-by: Rob Landley <rob@landley.net> Cc: Anca Emanuel <anca.emanuel@gmail.com> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Junjie Mao <eternal.n08@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-02-05 22:36:00 -08:00
Greg Kroah-Hartman	c2d6598eef	Linux 3.18.5	2015-01-29 17:41:03 -08:00
Mathias Krause	47e4434d89	crypto: add missing crypto module aliases commit `3e14dcf7cb` upstream. Commit `5d26a105b5` ("crypto: prefix module autoloading with "crypto-"") changed the automatic module loading when requesting crypto algorithms to prefix all module requests with "crypto-". This requires all crypto modules to have a crypto specific module alias even if their file name would otherwise match the requested crypto algorithm. Even though commit `5d26a105b5` added those aliases for a vast amount of modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO annotations to those files to make them get loaded automatically, again. This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work with kernels v3.18 and below. Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former won't work for crypto modules any more. Fixes: `5d26a105b5` ("crypto: prefix module autoloading with "crypto-"") Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Kees Cook	acc5ccb9fe	crypto: include crypto- module prefix in template commit `4943ba16bb` upstream. This adds the module loading prefix "crypto-" to the template lookup as well. For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly includes the "crypto-" prefix at every level, correctly rejecting "vfat": net-pf-38 algif-hash crypto-vfat(blowfish) crypto-vfat(blowfish)-all crypto-vfat Reported-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Kees Cook	f2efa8653b	crypto: prefix module autoloading with "crypto-" commit `5d26a105b5` upstream. This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Rafael J. Wysocki	c4302b5e47	ACPI / PM: Do not disable wakeup GPEs that have not been enabled commit `175f8e2650` upstream. In some cases acpi_device_wakeup() may be called to ensure wakeup power to be off for a given device even though that device's wakeup GPE has not been enabled so far. It calls acpi_disable_gpe() on a GPE that's not enabled and this causes ACPICA to return the AE_LIMIT status code from that call which then is reported as an error by the ACPICA's debug facilities (if enabled). This may lead to a fair amount of confusion, so introduce a new ACPI device wakeup flag to store the wakeup GPE status and avoid disabling wakeup GPEs that have not been enabled. Reported-and-tested-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
David Spinadel	11ba6ba933	iwlwifi: mvm: add a flag to enable match found notification commit `7e2a38831d` upstream. Add a flag that enables match found notification to align with FW API change. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
David Vrabel	840b131125	Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single" commit `dbdd74763f` upstream. This reverts commit `2c3fc8d26d`. This commit broke on x86 PV because entries in the generic SWIOTLB are indexed using (pseudo-)physical address not DMA address and these are not the same in a x86 PV guest. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Dan Carpenter	34be58049a	ipvs: uninitialized data with IP_VS_IPV6 commit `3b05ac3824` upstream. The app_tcp_pkt_out() function expects "*diff" to be set and ends up using uninitialized data if CONFIG_IP_VS_IPV6 is turned on. The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov for noticing that. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Pablo Neira Ayuso	4270214a95	netfilter: conntrack: fix race between confirmation and flush commit `8ca3f5e974` upstream. Commit `5195c14c8b` ("netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse") aimed to resolve the race condition between the confirmation (packet path) and the flush command (from control plane). However, it introduced a crash when several packets race to add a new conntrack, which seems easier to reproduce when nf_queue is in place. Fix this race, in __nf_conntrack_confirm(), by removing the CT from unconfirmed list before checking the DYING bit. In case race occured, re-add the CT to the dying list This patch also changes the verdict from NF_ACCEPT to NF_DROP when we lose race. Basically, the confirmation happens for the first packet that we see in a flow. If you just invoked conntrack -F once (which should be the common case), then this is likely to be the first packet of the flow (unless you already called flush anytime soon in the past). This should be hard to trigger, but better drop this packet, otherwise we leave things in inconsistent state since the destination will likely reply to this packet, but it will find no conntrack, unless the origin retransmits. The change of the verdict has been discussed in: https://www.marc.info/?l=linux-netdev&m=141588039530056&w=2 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Pablo Neira Ayuso	9eed1585b5	netfilter: nfnetlink: relax strict multicast group check from netlink_bind commit `62924af247` upstream. Relax the checking that was introduced in `97840cb` ("netfilter: nfnetlink: fix insufficient validation in nfnetlink_bind") when the subscription bitmask is used. Existing userspace code code may request to listen to all of the existing netlink groups by setting an all to one subscription group bitmask. Netlink already validates subscription via setsockopt() for us. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Pablo Neira Ayuso	436322eeda	netfilter: nf_tables: fix flush ruleset chain dependencies commit `a2f18db0c6` upstream. Jumping between chains doesn't mix well with flush ruleset. Rules from a different chain and set elements may still refer to us. [ 353.373791] ------------[ cut here ]------------ [ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159! [ 353.373896] invalid opcode: 0000 [#1] SMP [ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi [ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98 [ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW (1.17 ) 07/14/2010 [...] [ 353.375018] Call Trace: [ 353.375046] [<ffffffff81964c31>] ? nf_tables_commit+0x381/0x540 [ 353.375101] [<ffffffff81949118>] nfnetlink_rcv+0x3d8/0x4b0 [ 353.375150] [<ffffffff81943fc5>] netlink_unicast+0x105/0x1a0 [ 353.375200] [<ffffffff8194438e>] netlink_sendmsg+0x32e/0x790 [ 353.375253] [<ffffffff818f398e>] sock_sendmsg+0x8e/0xc0 [ 353.375300] [<ffffffff818f36b9>] ? move_addr_to_kernel.part.20+0x19/0x70 [ 353.375357] [<ffffffff818f44f9>] ? move_addr_to_kernel+0x19/0x30 [ 353.375410] [<ffffffff819016d2>] ? verify_iovec+0x42/0xd0 [ 353.375459] [<ffffffff818f3e10>] ___sys_sendmsg+0x3f0/0x400 [ 353.375510] [<ffffffff810615fa>] ? native_sched_clock+0x2a/0x90 [ 353.375563] [<ffffffff81176697>] ? acct_account_cputime+0x17/0x20 [ 353.375616] [<ffffffff8110dc78>] ? account_user_time+0x88/0xa0 [ 353.375667] [<ffffffff818f4bbd>] __sys_sendmsg+0x3d/0x80 [ 353.375719] [<ffffffff81b184f4>] ? int_check_syscall_exit_work+0x34/0x3d [ 353.375776] [<ffffffff818f4c0d>] SyS_sendmsg+0xd/0x20 [ 353.375823] [<ffffffff81b1826d>] system_call_fastpath+0x16/0x1b Release objects in this order: rules -> sets -> chains -> tables, to make sure no references to chains are held anymore. Reported-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.biz> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Pablo Neira Ayuso	7266a6b028	netfilter: nfnetlink: validate nfnetlink header from batch commit `9ea2aa8b7d` upstream. Make sure there is enough room for the nfnetlink header in the netlink messages that are part of the batch. There is a similar check in netlink_rcv_skb(). Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Michal Hocko	513c668203	mm: get rid of radix tree gfp mask for pagecache_get_page commit `45f87de57f` upstream. Commit `2457aec637` ("mm: non-atomically mark page accessed during page cache allocation where possible") has added a separate parameter for specifying gfp mask for radix tree allocations. Not only this is less than optimal from the API point of view because it is error prone, it is also buggy currently because grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then the radix tree allocation wouldn't obey the restriction and might recurse into filesystem and cause deadlocks. This is the case for most filesystems unfortunately because only ext4 and gfs2 are using AOP_FLAG_NOFS. Let's simply remove radix_gfp_mask parameter because the allocation context is same for both page cache and for the radix tree. Just make sure that the radix tree gets only the sane subset of the mask (e.g. do not pass __GFP_WRITE). Long term it is more preferable to convert remaining users of AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this interface even further. Reported-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:46 -08:00
Sasha Levin	8326fa8ec2	KEYS: close race between key lookup and freeing commit `a3a8784454` upstream. When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Suman Tripathi	101e595b88	ahci_xgene: Fix the endianess issue in APM X-Gene SoC AHCI SATA controller driver. commit `5c0b8e0de7` upstream. This patch fixes the big endian mode issue with function xgene_ahci_read_id. Signed-off-by: Suman Tripathi <stripathi@apm.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Andy Shevchenko	55f8b818e5	sata_dwc_460ex: fix resource leak on error path commit `4aaa71873d` upstream. DMA mapped IO should be unmapped on the error path in probe() and unconditionally on remove(). Fixes: `62936009f3` ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Bryan O'Donoghue	990785dcf5	x86/apic: Re-enable PCI_MSI support for non-SMP X86_32 commit `38a1dfda8e` upstream. Commit `0dbc6078c0` ('x86, build, pci: Fix PCI_MSI build on !SMP') introduced the dependency that X86_UP_APIC is only available when PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit UP systems because it disables both APIC and IO-APIC. But APIC support is architecturally required for PCI_MSI. The intention of the patch was to enforce APIC support when PCI_MSI is enabled, but failed to do so. Remove the !PCI_MSI dependency from X86_UP_APIC and enforce X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems. [ tglx: Massaged changelog ] Fixes `0dbc6078c0` 'x86, build, pci: Fix PCI_MSI build on !SMP' Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Andy Lutomirski	7b6b3d67f0	x86, tls: Interpret an all-zero struct user_desc as "no segment" commit `3669ef9fa7` upstream. The Witcher 2 did something like this to allocate a TLS segment index: struct user_desc u_info; bzero(&u_info, sizeof(u_info)); u_info.entry_number = (uint32_t)-1; syscall(SYS_set_thread_area, &u_info); Strictly speaking, this code was never correct. It should have set read_exec_only and seg_not_present to 1 to indicate that it wanted to find a free slot without putting anything there, or it should have put something sensible in the TLS slot if it wanted to allocate a TLS entry for real. The actual effect of this code was to allocate a bogus segment that could be used to exploit espfix. The set_thread_area hardening patches changed the behavior, causing set_thread_area to return -EINVAL and crashing the game. This changes set_thread_area to interpret this as a request to find a free slot and to leave it empty, which isn't quite what the game expects but should be close enough to keep it working. In particular, using the code above to allocate two segments will allocate the same segment both times. According to FrostbittenKing on Github, this fixes The Witcher 2. If this somehow still causes problems, we could instead allocate a limit==0 32-bit data segment, but that seems rather ugly to me. Fixes: `41bdc78544` x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Andy Lutomirski	e3b3b6d580	x86, tls, ldt: Stop checking lm in LDT_empty commit `e30ab185c4` upstream. 32-bit programs don't have an lm bit in their ABI, so they can't reliably cause LDT_empty to return true without resorting to memset. They shouldn't need to do this. This should fix a longstanding, if minor, issue in all 64-bit kernels as well as a potential regression in the TLS hardening code. Fixes: `41bdc78544` x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Nadav Amit	f84d9d8d9b	KVM: x86: Fix of previously incomplete fix for CVE-2014-8480 commit `63ea0a49ae` upstream. STR and SLDT with rip-relative operand can cause a host kernel oops. Mark them as DstMem as well. Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Nadav Amit	cb2567bf3e	KVM: x86: SYSENTER emulation is broken commit `f3747379ac` upstream. SYSENTER emulation is broken in several ways: 1. It misses the case of 16-bit code segments completely (CVE-2015-0239). 2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can still be set without causing #GP). 3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in legacy-mode. 4. There is some unneeded code. Fix it. Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Kees Cook	c546e47591	x86, boot: Skip relocs when load address unchanged commit `f285f4a21c` upstream. On 64-bit, relocation is not required unless the load address gets changed. Without this, relocations do unexpected things when the kernel is above 4G. Reported-by: Baoquan He <bhe@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Thomas D. <whissi@whissi.de> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Junjie Mao <eternal.n08@gmail.com> Cc: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Alexandre Demers	056ad39c15	x86/tsc: Change Fast TSC calibration failed from error to info commit `520452172e` upstream. Many users see this message when booting without knowning that it is of no importance and that TSC calibration may have succeeded by another way. As explained by Paul Bolle in http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein "Fast TSC calibration failed" should not be considered as an error since other calibration methods are being tried afterward. At most, those send a warning if they fail (not an error). So let's change the message from error to warning. [ tglx: Make if pr_info. It's really not important at all ] Fixes: `c767a54ba0` x86/debug: Add KERN_<LEVEL> to bare printks, convert printks to pr_<level> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
K. Y. Srinivasan	246b625243	x86, hyperv: Mark the Hyper-V clocksource as being continuous commit `32c6590d12` upstream. The Hyper-V clocksource is continuous; mark it accordingly. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Acked-by: jasowang@redhat.com Cc: gregkh@linuxfoundation.org Cc: devel@linuxdriverproject.org Cc: olaf@aepfle.de Cc: apw@canonical.com Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Tobias Jakobi	ec987a13d5	clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write commit `8c38d28ba8` upstream. EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask produces a number outside the range 0x00 to 0xff, which always results in execution of the default switch statement. Obviously this is wrong and git history shows that the bitmask inversion was incorrectly set during a refactoring of the MCT code. Fix this by putting the inversion at the correct position again. Acked-by: Kukjin Kim <kgene.kim@samsung.com> Reported-by: GP Orcullo <kinsamanka@gmail.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Jan Beulich	89a2e6efe2	x86, irq: Properly tag virtualization entry in /proc/interrupts commit `4a0d3107d6` upstream. The mis-naming likely was a copy-and-paste effect. Signed-off-by: Jan Beulich <jbeulich@suse.com> Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Gavin Li	449af2873e	irqchip: atmel-aic-common: Prevent clobbering of priority when changing IRQ type commit `91d1179212` upstream. This patch makes the bitmask for AIC_SRCTYPE consistent with that of its valid values, and prevents the priority field at bits 2:0 from being clobbered by an incorrect AND with the AIC_SRCTYPE mask. Signed-off-by: Gavin Li <gavinli@thegavinli.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Al Viro	24f1a316c4	fix deadlock in cifs_ioctl_clone() commit `378ff1a53b` upstream. It really needs to check that src is non-directory and use {un,}lock_two_nodirectories(). As it is, it's trivial to cause double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the last argument is an fd of directory, we are asking for trouble by violating the locking order - all directories go before all non-directories. If the last argument is an fd of parent directory, it has 50% odds of locking child before parent, which will cause AB-BA deadlock if we race with unlink(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:45 -08:00
Andrew Lunn	3436c0aadc	bus: mvebu-mbus: fix support of MBus window 13 commit `38bdf45f4a` upstream. On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't currently taking into account this special case, which means that when window 13 is actually used, the remap registers are left to 0, making the device using this MBus window unavailable. As a minimal fix for stable, don't use window 13. A full fix will follow later. Fixes: `fddddb52a6` ("bus: introduce an Marvell EBU MBus driver") Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Thomas Petazzoni	1f20756ce6	ARM: mvebu: completely disable hardware I/O coherency commit `8f1e8ee286` upstream. The current hardware I/O coherency is known to cause problems with DMA coherent buffers, as it still requires explicit I/O synchronization barriers, which is not compatible with the semantics expected by the Linux DMA coherent buffers API. So, in order to have enough time to validate a new solution based on automatic I/O synchronization barriers, this commit disables hardware I/O coherency entirely. Future patches will re-enable it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Fabio Estevam	7b915d382a	ARM: dts: imx25: Fix PWM "per" clocks commit `7ecd0bde5b` upstream. Currently PWM functionality is broken on mx25 due to the wrong assignment of the PWM "per" clock. According to Documentation/devicetree/bindings/clock/imx25-clock.txt: pwm_ipg_per 52 ,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock. With this change PWM can work fine on mx25. Reported-by: Carlos Soto <csotoalonso@gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Sasha Levin	e8e3b6ddd0	time: adjtimex: Validate the ADJ_FREQUENCY values commit `5e5aeb4367` upstream. Verify that the frequency value from userspace is valid and makes sense. Unverified values can cause overflows later on. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> [jstultz: Fix up bug for negative values and drop redunent cap check] Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Sasha Levin	5f4d5404ee	time: settimeofday: Validate the values of tv from user commit `6ada1fc0e1` upstream. An unvalidated user input is multiplied by a constant, which can result in an undefined behaviour for large values. While this is validated later, we should avoid triggering undefined behaviour. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> [jstultz: include trivial milisecond->microsecond correction noticed by Andy] Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Felipe Balbi	cfaa6851b0	irqchip: omap-intc: Fix legacy DMA regression commit `4b149e4174` upstream. commit `55601c9f24` (arm: omap: intc: switch over to linear irq domain) introduced a regression with SDMA legacy driver because that driver strictly depends on INTC's IRQs starting at NR_IRQs. Aparently irq_domain_add_linear() won't guarantee that, since we see a 7 IRQs difference when booting with and without the commit cited above. Until arch/arm/plat-omap/dma.c is properly fixed, we must maintain OMAP2/3 using irq_domain_add_legacy(). A FIXME note was added so people know to delete that code once that legacy DMA driver is fixed up. Fixes: `55601c9f24` (arm: omap: intc: switch over to linear irq domain) Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Joe Thornber	538c2bc4ec	dm cache: fix problematic dual use of a single migration count variable commit `a59db67656` upstream. Introduce a new variable to count the number of allocated migration structures. The existing variable cache->nr_migrations became overloaded. It was used to: i) track of the number of migrations in flight for the purposes of quiescing during suspend. ii) to estimate the amount of background IO occuring. Recent discard changes meant that REQ_DISCARD bios are processed with a migration. Discards are not background IO so nr_migrations was not incremented. However this could cause quiescing to complete early. (i) is now handled with a new variable cache->nr_allocated_migrations. cache->nr_migrations has been renamed cache->nr_io_migrations. cleanup_migration() is now called free_io_migration(), since it decrements that variable. Also, remove the unused cache->next_migration variable that got replaced with with prealloc_structs a while ago. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Joe Thornber	7bf9ed7e78	dm cache: share cache-metadata object across inactive and active DM tables commit `9b1cc9f251` upstream. If a DM table is reloaded with an inactive table when the device is not suspended (normal procedure for LVM2), then there will be two dm-bufio objects that can diverge. This can lead to a situation where the inactive table uses bufio to read metadata at the same time the active table writes metadata -- resulting in the inactive table having stale metadata buffers once it is promoted to the active table slot. Fix this by using reference counting and a global list of cache metadata objects to ensure there is only one metadata object per metadata device. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Hans Verkuil	7536e0dce3	vb2: fix vb2_thread_stop race conditions commit `6cf11ee630` upstream. The locking scheme inside the vb2 thread is unsafe when stopping the thread. In particular kthread_stop was called after internal data structures were cleaned up instead of doing that before. In addition, internal vb2 functions were called after threadio->stop was set to true and vb2_internal_streamoff was called. This is also not allowed. All this led to a variety of race conditions and kernel warnings and/or oopses. Fixed by moving the kthread_stop call up before the cleanup takes place, and by checking threadio->stop before calling internal vb2 queuing operations. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Matthias Schwarzott	5d9aa9e5e8	cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry commit `721f3223f2` upstream. Unconditionally attaching Si2161/Si2165 demod driver breaks Hauppauge WinTV Starburst. So create own card entry for this. Add card name comments to the subsystem ids. This fixes a regression introduced in 3.17 by `36efec48e2` ([media] cx23885: Add si2165 support for HVR-5500) Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> Tested-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Brian King	a2d8617dff	ipr: wait for aborted command responses commit `6cdb08172b` upstream. Fixes a race condition in abort handling that was injected when multiple interrupt support was added. When only a single interrupt is present, the adapter guarantees it will send responses for aborted commands prior to the response for the abort command itself. With multiple interrupts, these responses generally come back on different interrupts, so we need to ensure the abort thread waits until the aborted command is complete so we don't perform a double completion. This race condition was being hit frequently in environments which were triggering command timeouts, which was resulting in a double completion causing a kernel oops. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Reviewed-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Tested-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Alex Williamson	587a7ba37c	PCI: Mark Atheros AR93xx to avoid bus reset commit `c3e59ee4e7` upstream. Reports against the TL-WDN4800 card indicate that PCI bus reset of this Atheros device cause system lock-ups and resets. I've also been able to confirm this behavior on multiple systems. The device never returns from reset and attempts to access config space of the device after reset result in hangs. Blacklist bus reset for the device to avoid this issue. [bhelgaas: This regression appeared in v3.14. Andreas bisected it to `425c1b223d` ("PCI: Add Virtual Channel to save/restore support"), but we don't understand the mechanism by which that commit affects the reset path.] [bhelgaas: changelog, references] Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Reported-by: Andreas Hartmann <andihartmann@freenet.de> Tested-by: Andreas Hartmann <andihartmann@freenet.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Alex Williamson	b01f14468d	PCI: Add flag for devices where we can't use bus reset commit `f331a859e0` upstream. Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:44 -08:00
Yinghai Lu	33658764e9	x86/PCI: Clip bridge windows to fit in upstream windows commit `851b093692` upstream. Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Tested-by: Marek Kordik <kordikmarek@gmail.com> Fixes: `5b28541552` ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Yinghai Lu	73698b0099	PCI: Add pci_bus_clip_resource() to clip to fit upstream window commit `0f7e7aee2f` upstream. Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an upstream bridge window but is not completely contained by it, this clips the downstream window so it fits inside the upstream one. No functional change (this adds the function but no callers). [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: `5b28541552` ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Yinghai Lu	9f2e98fd13	PCI: Add pci_claim_bridge_resource() to clip window if necessary commit `8505e729a2` upstream. Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is like regular pci_claim_resource(), except that if we fail to claim the window, we check to see if we can reduce the size of the window and try again. This is for scenarios like this: pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff] pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref] pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref] The 00:01.0 window is illegal: it starts before the host bridge window, so we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref]. Previously we discarded the 00:01.0 window and tried to reassign that part of the hierarchy from scratch. That is a problem because Linux doesn't always assign things optimally. For example, in this case, BIOS put the 01:00.0 device in a prefetchable window below 4GB, but after `5b28541552`, Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0 device can't use it. Clipping the 00:01.0 window is less intrusive than completely reassigning things and is sufficient to let us use most of the BIOS configuration. Of course, it's possible that devices below 00:01.0 will no longer fit. If that's the case, we'll have to reassign things. But that's a separate problem. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: `5b28541552` ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Yinghai Lu	ad5fa86f4e	PCI: Pass bridge device, not bus, when updating bridge windows commit `3f2f4dc456` upstream. pci_setup_bridge_io(), pci_setup_bridge_mmio(), and pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges. Previously they accepted a pointer to the pci_bus of the secondary bus, then looked up the bridge leading to that bus. Pass the bridge directly, which will make it more convenient for future callers. No functional change. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: `5b28541552` ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Alex Deucher	d5adda6575	drm/radeon: use rv515_ring_start on r5xx commit `d8a74e1869` upstream. This was accidently lost in `76a0df859d`. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Alex Deucher	ff32f6aab7	drm/radeon: add si dpm quirk list commit `5615f890bc` upstream. This adds a quirks list to fix stability problems with certain SI boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Alex Deucher	4e77f9fb47	drm/radeon: add a dpm quirk list commit `4369a69ec6` upstream. Disable dpm on certain problematic boards rather than disabling dpm for the entire chip family since most boards work fine. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534 https://bugzilla.kernel.org/show_bug.cgi?id=83731 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Chris Wilson	8dcffdd314	drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES commit `226e5ae9e5` upstream. If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared if the mutex debugging is enabled which introduces a race in our mutex_is_locked_by() - i.e. we may inspect the old owner value before it is acquired by the new task. This is the root cause of this error: # diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c # index 5cf6731..3ef3736 100644 # --- a/kernel/locking/mutex-debug.c # +++ b/kernel/locking/mutex-debug.c # @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex lock) # DEBUG_LOCKS_WARN_ON(lock->owner != current); # # DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next); # - mutex_clear_owner(lock); # } # # / # * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug # * mutexes so that we can do it here after we've verified state. # */ # + mutex_clear_owner(lock); # atomic_set(&lock->count, 1); # } Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Chris Wilson	00647dbf51	drm/i915: Ban Haswell from using RCS flips commit `48bf5b2d00` upstream. Like Ivybridge, we have reports that we get random hangs when flipping with multiple pipes. Extend commit `2a92d5bca1` Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 8 10:40:29 2014 +0100 drm/i915: Disable RCS flips on Ivybridge to also apply to Haswell. Reported-and-tested-by: Scott Tsai <scottt.tw@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Michael Karcher	7cc613f0d1	scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore commit `1caf6aaaa4` upstream. Compiling SH with gcc-4.8 fails due to the -m32 option not being supported. From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783 CC init/main.o gcc-4.8: error: unrecognized command line option '-m32' ld: cannot find init/.tmp_mc_main.o: No such file or directory objcopy: 'init/.tmp_mx_main.o': No such file rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de Cc: Matt Fleming <matt@console-pimps.org> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Tejun Heo	8fdd4f7795	workqueue: fix subtle pool management issue which can stall whole worker_pool commit `29187a9eea` upstream. A worker_pool's forward progress is guaranteed by the fact that the last idle worker assumes the manager role to create more workers and summon the rescuers if creating workers doesn't succeed in timely manner before proceeding to execute work items. This manager role is implemented in manage_workers(), which indicates whether the worker may proceed to work item execution with its return value. This is necessary because multiple workers may contend for the manager role, and, if there already is a manager, others should proceed to work item execution. Unfortunately, the function also indicates that the worker may proceed to work item execution if need_to_create_worker() is false at the head of the function. need_to_create_worker() tests the following conditions. pending work items && !nr_running && !nr_idle The first and third conditions are protected by pool->lock and thus won't change while holding pool->lock; however, nr_running can change asynchronously as other workers block and resume and while it's likely to be zero, as someone woke this worker up in the first place, some other workers could have become runnable inbetween making it non-zero. If this happens, manage_worker() could return false even with zero nr_idle making the worker, the last idle one, proceed to execute work items. If then all workers of the pool end up blocking on a resource which can only be released by a work item which is pending on that pool, the whole pool can deadlock as there's no one to create more workers or summon the rescuers. This patch fixes the problem by removing the early exit condition from maybe_create_worker() and making manage_workers() return false iff there's already another manager, which ensures that the last worker doesn't start executing work items. We can leave the early exit condition alone and just ignore the return value but the only reason it was put there is because the manage_workers() used to perform both creations and destructions of workers and thus the function may be invoked while the pool is trying to reduce the number of workers. Now that manage_workers() is called only when more workers are needed, the only case this early exit condition is triggered is rare race conditions rendering it pointless. Tested with simulated workload and modified workqueue code which trigger the pool deadlock reliably without this patch. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Eric Sandeen <sandeen@sandeen.net> Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net Cc: Dave Chinner <david@fromorbit.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
Jason Lee Cragg	335b7ac3cd	ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210 commit `6455931186` upstream. Signed-off-by: Jason Lee Cragg <jcragg@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:43 -08:00
David Jeffery	362a0d61df	libata: prevent HSM state change race between ISR and PIO commit `ce75145267` upstream. It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG(). This problem is hard to reproduce making this patch hard to verify, but this fix will prevent the race. I have not been able to reproduce the problem, but here is a crash dump from a 2.6.32 kernel. On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE: crash> struct ata_port.hsm_task_state ffff881c1121c000 hsm_task_state = 0 Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(), which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value. PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd" #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92 #2 [ffff88008ba03a90] oops_end at ffffffff8152b510 #3 [ffff88008ba03ac0] die at ffffffff81010e0b #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74 #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95 #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b [exception RIP: ata_sff_hsm_move+317] RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097 RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000 RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000 RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000 R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0	2015-01-29 17:40:43 -08:00
Dan Williams	99bde8fc1c	libata: allow sata_sil24 to opt-out of tag ordered submission commit `72dd299d50` upstream. Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101 "Since commit `8a4aeec8d` "libata/ahci: accommodate tag ordered controllers" the access to the harddisk on the first SATA-port is failing on its first access. The access to the harddisk on the second port is working normal. When reverting the above commit, access to both harddisks is working fine again." Maintain tag ordered submission as the default, but allow sata_sil24 to continue with the old behavior. Cc: Tejun Heo <tj@kernel.org> Reported-by: Ronny Hegewald <Ronny.Hegewald@online.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Roger Tseng	28de6f351a	mfd: rtsx_usb: Fix runtime PM deadlock commit `b166010f6a` upstream. sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the device is awake while initializing a newly inserted card. Once it is called during suspending state and explicitly before rtsx_usb_suspend() acquires the same dev_mutex, both routine deadlock and further hang the driver because pm_runtime_get_sync() waits the pending PM operations. Fix this by using an empty suspend method. mmc_core always turns the LED off after a request is done and thus it is ok to remove the only rtsx_usb_turn_off_led() here. Fixes: `730876be25` ("mfd: Add realtek USB card reader driver") Signed-off-by: Roger Tseng <rogerable@realtek.com> [Lee: Removed newly unused variable] Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Felipe Balbi	5a8405ca21	mfd: tps65218: Make INT1 our status_base register commit `f29ae369a4` upstream. If we don't tell regmap-irq that our first status register is at offset 1, it will try to read offset zero, which is the chipid register. Fixes: `44b4dc6` mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Felipe Balbi	fc904760b4	mfd: tps65218: Make INT[12] and STATUS registers volatile commit `773328da24` upstream. STATUS register can be modified by the HW, so we should bypass cache because of that. In the case of INT[12] registers, they are the ones that actually clear the IRQ source at the time they are read. If we rely on the cache for them, we will never be able to clear the interrupt, which will cause our IRQ line to be disabled due to IRQ throttling. Fixes: `44b4dc6` mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Jim Lin	515939f381	pinctrl: Fix two deadlocks commit `db93facfb0` upstream. This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Stephen Boyd	ce441cb4f1	pinctrl: qcom: Don't iterate past end of function array commit `bcd53f858d` upstream. Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by: Timur Tabi <timur@codeaurora.org> Cc: Pramod Gurav <pramod.gurav@smartplayin.com> Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Ivan T. Ivanov <iivanov@mm-sol.com> Cc: Andy Gross <agross@codeaurora.org> Fixes: `327455817a` "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Oliver Hartkopp	b47d1db630	can: m_can: tag current CAN FD controllers as non-ISO commit `6cfda7fbeb` upstream. During the CAN FD standardization process within the ISO it turned out that the failure detection capability has to be improved. The CAN in Automation organization (CiA) defined the already implemented CAN FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as 'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937 Finally there will be three types of CAN FD controllers in the future: 1. ISO compliant (fixed) 2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c) 3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD) So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup. As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO must not be set in ctrlmode_supported of the current M_CAN driver. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Oliver Hartkopp	96bfa3859e	can: dev: fix crtlmode_supported check commit `9b1087aa5e` upstream. When changing flags in the CAN drivers ctrlmode the provided new content has to be checked whether the bits are allowed to be changed. The bits that are to be changed are given as a bitfield in cm->mask. Therefore checking against cm->flags is wrong as the content can hold any kind of values. The iproute2 tool sets the bits in cm->mask and cm->flags depending on the detected command line options. To be robust against bogus user space applications additionally sanitize the provided flags with the provided mask. Cc: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-29 17:40:42 -08:00
Greg Kroah-Hartman	71745ce1b8	Linux 3.18.4	2015-01-27 08:30:10 -08:00
Bandan Das	0bcd13a053	KVM: nVMX: Disable unrestricted mode if ept=0 commit `78051e3b7e` upstream. If L0 has disabled EPT, don't advertise unrestricted mode at all since it depends on EPT to run real mode code. Fixes: `92fbc7b195` Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bandan Das <bsd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:46 -08:00
Ville Syrjälä	3e038e9d2d	drm/i915: Kill check_power_well() calls commit `7f1241ed1a` upstream. pps_{lock,unlock}() call intel_display_power_{get,put}() outside pps_mutes to avoid deadlocks with the power_domain mutex. In theory during aux transfers we should usually have the relevant power domain references already held by some higher level code, so this should not result in much overhead (exception being userspace i2c-dev access). However thanks to the check_power_well() calls in intel_display_power_{get/put}() we end up doing a few Punit reads for each aux transfer. Obviously doing this for each byte transferred via i2c-over-aux is not a good idea. I can't think of a good way to keep check_power_well() while eliminating the overhead, so let's just remove check_power_well() entirely. Fixes a driver init time regression introduced by: commit `773538e860` Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:56 2014 +0300 drm/i915: Reset power sequencer pipe tracking when disp2d is off Credit goes to Jani for figuring this out. v2: Add the regression note in the commit message. Cc: Egbert Eich <eich@suse.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201 Tested-by: Wendy Wang <wendy.wang@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: s/intel_runtime_pm.c/intel_pm.c/g and wiggle for 3.18] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:46 -08:00
Nicholas Bellinger	65f81ccbd1	vhost-scsi: Add missing virtio-scsi -> TCM attribute conversion commit `4624386080` upstream. While looking at hch's recent conversion to drop the MSG__TAG definitions, I noticed a long standing bug in vhost-scsi where the VIRTIO_SCSI_S_ attribute definitions where incorrectly being passed directly into target_submit_cmd_map_sgls(). This patch adds the missing virtio-scsi to TCM/SAM task attribute conversion. Cc: Christoph Hellwig <hch@lst.de> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Nicholas Bellinger	82bc9d04f4	target: Drop arbitrary maximum I/O size limit commit `046ba64285` upstream. This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(), which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512 byte sector devices), and for hw_max_sectors is a backend driver dependent value. This limit is problematic because Linux initiators have only recently started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger than 4 MB in size. Currently when this happens, the following message will appear on the target resulting in I/Os being returned with non recoverable status: SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192 Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(), and convert the existing hw_max_sectors into a purely informational attribute used to represent the granuality that backend driver and/or subsystem code is splitting I/Os upon. Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw() to deal with the one special iovec limitiation case. v2 changes: - Drop hw_max_sectors check in sbc_parse_cdb() Reported-by: Lance Gropper <lance.gropper@qosserver.com> Reported-by: Stefan Priebe <s.priebe@profihost.ag> Cc: Christoph Hellwig <hch@lst.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Trond Myklebust	e7b2033159	LOCKD: Fix a race when initialising nlmsvc_timeout commit `06bed7d18c` upstream. This commit fixes a race whereby nlmclnt_init() first starts the lockd daemon, and then calls nlm_bind_host() with the expectation that nlmsvc_timeout has already been initialised. Unfortunately, there is no no synchronisation between lockd() and lockd_up() to guarantee that this is the case. Fix is to move the initialisation of nlmsvc_timeout into lockd_create_svc Fixes: `9a1b6bf818` ("LOCKD: Don't call utsname()->nodename...") Cc: Bruce Fields <bfields@fieldses.org> Cc: stable@vger.kernel.org # 3.10.x Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Michal Marek	90293ffa75	kbuild: Fix removal of the debian/ directory commit `a16c5f99a2` upstream. scripts/Makefile.clean treats absolute path specially, but $(objtree)/debian is no longer an absolute path since `7e1c0477` (kbuild: Use relative path for $(objtree). Work around this by checking if the path starts with $(objtree)/. Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com> Fixes: `7e1c0477` (kbuild: Use relative path for $(objtree) Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Daniel Borkmann	51fbc05597	x86, um: actually mark system call tables readonly commit `b485342bd7` upstream. Commit `a074335a37` ("x86, um: Mark system call tables readonly") was supposed to mark the sys_call_table in UML as RO by adding the const, but it doesn't have the desired effect as it's nevertheless being placed into the data section since __cacheline_aligned enforces sys_call_table being placed into .data..cacheline_aligned instead. We need to use the ____cacheline_aligned version instead to fix this issue. Before: $ nm -v arch/x86/um/sys_call_table_64.o \| grep -1 "sys_call_table" U sys_writev 0000000000000000 D sys_call_table 0000000000000000 D syscall_table_size After: $ nm -v arch/x86/um/sys_call_table_64.o \| grep -1 "sys_call_table" U sys_writev 0000000000000000 R sys_call_table 0000000000000000 D syscall_table_size Fixes: `a074335a37` ("x86, um: Mark system call tables readonly") Cc: H. Peter Anvin <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Richard Weinberger	b9d078ca44	um: Skip futex_atomic_cmpxchg_inatomic() test commit `f911d73105` upstream. futex_atomic_cmpxchg_inatomic() does not work on UML because it triggers a copy_from_user() in kernel context. On UML copy_from_user() can only be used if the kernel was called by a real user space process such that UML can use ptrace() to fetch the value. Reported-by: Miklos Szeredi <miklos@szeredi.hu> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Richard Weinberger <richard@nod.at> Tested-by: Daniel Walter <d.walter@0x90.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Dan Carpenter	dcd295f7be	decompress_bunzip2: off by one in get_next_block() commit `b5c8afe5be` upstream. "origPtr" is used as an offset into the bd->dbuf[] array. That array is allocated in start_bunzip() and has "bd->dbufSize" number of elements so the test here should be >= instead of >. Later we check "origPtr" again before using it as an offset so I don't know if this bug can be triggered in real life. Fixes: `bc22c17e12` ('bzip2/lzma: library support for gzip, bzip2 and lzma decompression') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Alain Knaff <alain@knaff.lu> Cc: Yinghai Lu <yinghai@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Lars-Peter Clausen	13b2e3a5c4	iio: ad799x: Fix ad7991/ad7995/ad7999 config setup commit `2eacc608b3` upstream. The ad7991/ad7995/ad7999 does not have a configuration register like the other devices that can be written and read. The configuration is written as part of the conversion sequence. Fixes: `0f7ddcc1bf` ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Tested-by: Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Mugunthan V N	8d622085d6	ARM: dts: dra7-evm: fix qspi device tree partition size commit `69d2626f97` upstream. 64KiB is allocated for qspi dtb partition which is not sufficient, so updating the partition table size to 512KiB for device tree partition. This also aligns the QSPI partition definitions between kernel and U-Boot. Fixes: `dc2dd5b8` ("ARM: dts: dra7: Add qspi device") Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Geert Uytterhoeven	7a66eeb23e	ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances commit `b0ddb319db` upstream. The sh73a0 INTC can't mask interrupts properly most likely due to a hardware bug. Set the .control_parent flag to delegate masking to the parent interrupt controller, like was already done for irqpin1. Without this, accessing the three-axis digital accelerometer ADXL345 on kzm9g through /dev/input/event1 causes an interrupt storm, which requires a power-cycle to recover from. This was inspired by a patch for arch/arm/boot/dts/sh73a0.dtsi from Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: `341eb5465f` ("ARM: shmobile: INTC External IRQ pin driver on sh73a0") Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Jisheng Zhang	25bcda837a	ARM: dts: berlin: add broken-cd and set bus width for eMMC in Marvell DMP DT commit `5adba7c2da` upstream. There's no card detection for the eMMC, so this patch adds the missing broken-cd property. This patch also sets bus width as 8 to add MMC_CAP_8_BIT_DATA in the Host capabilities. Fixes: `3047086dfd` ("ARM: dts: berlin: enable SD card reader and eMMC for the BG2Q DMP") Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:45 -08:00
Keerthy	4cb194fd5a	bus: omap_l3_noc: Correct returning IRQ_HANDLED unconditionally in the irq handler commit `c4cf0935a2` upstream. Correct returning IRQ_HANDLED unconditionally in the irq handler. Return IRQ_NONE for some interrupt which we do not expect to be handled in this handler. This prevents kernel stalling with back to back spurious interrupts. Fixes: `2722e56de6` ("OMAP4: l3: Introduce l3-interconnect error handling driver") Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Keerthy	397ee6685d	bus: omap_l3_noc: Add resume hook to restore context commit `61b43d4e91` upstream. On certain SoCs such as AM437x SoC, L3_noc error registers are maintained in power domain such as per domain which looses context as part of low power state such as RTC+DDR mode. On these platforms when we mask interrupts which we cannot handle, the source of these interrupts still remain on resume, however, the flag mux registers now contain their reset value (unmasked) - this breaks the system with infinite interrupts since we do not these interrupts to take place ever again. To handle this: restore the masking of interrupts which we have already recorded in the system as ones we cannot handle. Fixes: `2100b595b7` ("bus: omap_l3_noc: ignore masked out unclearable targets") Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Lennart Sorensen	fa036ea44c	ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode commit `999f934de1` upstream. If the boot loader enables HYP mode on the boot CPU, the secondary CPU also needs to call into the ROM to switch to HYP mode before booting. The firmwares on the omap5 and dra7xx unfortunately do not take care of this, so it has to be handled by the kernel. This patch is based on "[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs" by Santosh Shilimkar <santosh.shilimkar@ti.com>, except this version does not require a compile time CONFIG to control if it should enable HYP mode or not, it simply does it based on the mode of the boot CPU, so it works whether the CPU boots in SVC or HYP mode, and should even work as a guest kernel inside kvm if qemu decides to support emulating the omap5 or dra7xx. Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Lennart Sorensen	3af7a88e25	ARM: omap5/dra7xx: Fix frequency typos commit `572b24e6d8` upstream. The switch statement of the possible list of SYSCLK1 frequencies is missing a 0 in 4 out of the 7 frequencies. Fixes: `fa6d79d276` ("ARM: OMAP: Add initialisation for the real-time counter") Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Gary Bisson	73ea8acf0b	ARM: clk-imx6q: fix video divider for rev T0 1.0 commit `81ef447950` upstream. The post dividers do not work on i.MX6Q rev T0 1.0 so they must be fixed to 1. As the table index was wrong, a divider a of 4 could still be requested which implied the clock not to be set properly. This is the root cause of the HDMI not working at high resolution on rev T0 1.0 of the SoC. Signed-off-by: Gary Bisson <bisson.gary@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Dmitry Voytik	61bca51aff	ARM: imx6q: drop unnecessary semicolon commit `d2a10a1727` upstream. Drop unnecessary semicolon after closing curly bracket. Signed-off-by: Dmitry Voytik <voytikd@gmail.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Fabio Estevam	a3576e471f	ARM: dts: imx51-babbage: Fix ULPI PHY reset modelling commit `7a9f0604bd` upstream. GPIO2_5 is the reset GPIO for the USB3317 ULPI PHY. Instead of modelling it as a regulator, the correct approach is to use the 'reset_gpios' property of the "usb-nop-xceiv" node. GPIO1_7 is the reset GPIO for the USB2517 USB hub. As we currently don't have dt bindings to describe a HUB reset, let's keep using the regulator approach. Rename the regulator to 'reg_hub_reset' to better describe its function and bind it with the USB host1 port instead. USB host support has been introduced by commit `9bf206a9d1` ("ARM: dts: imx51-babbage: Add USB Host1 support"), which landed in 3.16 and it seems that USB has only been functional due to previous bootloader initialization. With this patch applied we can get USB host to work without relying on the bootloader. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Fabio Estevam	1fb91db57f	ARM: dts: imx25: Fix the SPI1 clocks commit `7a87e9cbc3` upstream. From Documentation/devicetree/bindings/clock/imx25-clock.txt: cspi1_ipg 78 cspi2_ipg 79 cspi3_ipg 80 , so fix the SPI1 clocks accordingly to avoid a kernel hang when trying to access SPI1. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Fabio Estevam	64c2607ba8	ARM: imx6sx: Set PLL2 as parent of QSPI clocks commit `7c168ed898` upstream. The default qspi2_clk_sel field of register CCM_CS2CDR contains '110' which is marked as 'reserved', so we can't rely on the default value. Provide a proper parent for QSPI clocks to avoid a kernel oops: [ 1.037920] Division by zero in kernel. [ 1.041807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204-00002-g5aa23e1 #2143 [ 1.050967] Hardware name: Freescale i.MX6 SoloX (Device Tree) [ 1.056853] Backtrace: [ 1.059360] [<80011ea0>] (dump_backtrace) from [<8001203c>] (show_stack+0x18/0x1c) [ 1.066982] r6:00000000 r5:00000000 r4:00000000 r3:00000000 [ 1.072754] [<80012024>] (show_stack) from [<806b7100>] (dump_stack+0x88/0xa4) [ 1.080038] [<806b7078>] (dump_stack) from [<80011d20>] (__div0+0x18/0x20) [ 1.086958] r5:be018500 r4:be017c00 [ 1.090600] [<80011d08>] (__div0) from [<802aa418>] (Ldiv0+0x8/0x10) [ 1.097012] [<80504fbc>] (clk_divider_set_rate) from [<80503ddc>] (clk_change_rate+0x14c/0x17c) [ 1.105759] r7:00000000 r6:00000000 r5:be018500 r4:00000000 [ 1.111516] [<80503c90>] (clk_change_rate) from [<80503ea0>] (clk_set_rate+0x94/0x98) [ 1.119391] r8:be7e0368 r7:00000000 r6:be11a000 r5:be018500 r4:00000000 r3:00000000 [ 1.127290] [<80503e0c>] (clk_set_rate) from [<80410558>] (fsl_qspi_probe+0x23c/0x75c) [ 1.135260] r5:be11a010 r4:be350010 [ 1.138900] [<8041031c>] (fsl_qspi_probe) from [<80385a18>] (platform_drv_probe+0x50/0xac) Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Nishanth Menon	2e953b8520	ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT commit `40d1746d2e` upstream. CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit `bbcf071969` ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'") Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with v3.18-rc1, commit `bbcf071969` and `fdc509b15e` came in via different trees causing the resultant v3.18-rc1 to be non-functional for cpufreq as default supported with omap2plus_defconfig. Fixes: `fdc509b15e` ("ARM: omap2plus_defconfig: Add cpufreq to defconfig") Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Dmitry Torokhov	d3c248b638	Input: I8042 - add Acer Aspire 7738 to the nomux list commit `9333caeaea` upstream. When KBC is in active multiplexing mode the touchpad on this laptop does not work. Reported-by: Bilal Koc <koc.bilo@googlemail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:44 -08:00
Srihari Vijayaraghavan	aae7cd96b4	Input: i8042 - reset keyboard to fix Elantech touchpad detection commit `148e9a711e` upstream. On some laptops, keyboard needs to be reset in order to successfully detect touchpad (e.g., some Gigabyte laptop models with Elantech touchpads). Without resettin keyboard touchpad pretends to be completely dead. Based on the original patch by Mateusz Jończyk this version has been expanded to include DMI based detection & application of the fix automatically on the affected models of laptops. This has been confirmed to fix problem by three users already on three different models of laptops. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331 Signed-off-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com> Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Tested-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com> Tested by: Zakariya Dehlawi <zdehlawi@gmail.com> Tested-by: Guillaum Bouchard <guillaum.bouchard@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Sam hung	17afe47690	Input: elantech - support new ICs types for version 4 commit `810aa0918b` upstream. This change allows the driver to recognize newer Elantech touchpads. Signed-off-by: Yi ju Hong <sam.hung@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Ahmed S. Darwish	17fb11ae0c	can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels commit `5e7e6e0c9b` upstream. Recent Leaf firmware versions (>= 3.1.557) do not allow to send commands for non-existing channels. If a command is sent for a non-existing channel, the firmware crashes. Reported-by: Christopher Storah <Christopher.Storah@invetech.com.au> Signed-off-by: Olivier Sobrie <olivier@sobrie.be> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Ahmed S. Darwish	9111e41c16	can: kvaser_usb: Reset all URB tx contexts upon channel close commit `889b77f7fd` upstream. Flooding the Kvaser CAN to USB dongle with multiple reads and writes in very high frequency (), closing the CAN channel while all the transmissions are on (#), opening the device again (@), then sending a small number of packets would make the driver enter an almost infinite loop of: [....] [15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context [....] _dragging the whole system down_ in the process due to the excessive logging output. Initially, this has caused random panics in the kernel due to a buggy error recovery path. That got fixed in an earlier commit.(%) This patch aims at solving the root cause. --> 16 tx URBs and contexts are allocated per CAN channel per USB device. Such URBs are protected by: a) A simple atomic counter, up to a value of MAX_TX_URBS (16) b) A flag in each URB context, stating if it's free c) The fact that ndo_start_xmit calls are themselves protected by the networking layers higher above After grabbing one of the tx URBs, if the driver noticed that all of them are now taken, it stops the netif transmission queue. Such queue is worken up again only if an acknowedgment was received from the firmware on one of our earlier-sent frames. Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP to the firmware, effectively closing all further communication. In the high traffic case, the atomic counter remains at MAX_TX_URBS, and all the URB contexts remain marked as active. While opening the channel again (@), it cannot send any further frames since no more free tx URB contexts are available. Reset all tx URB contexts upon CAN channel close. () 50 parallel instances of `cangen0 -g 0 -ix` (#) `ifconfig can0 down` (@) `ifconfig can0 up` (%) "can: kvaser_usb: Don't free packets when tight on URBs" Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Ahmed S. Darwish	198e0c9d00	can: kvaser_usb: Don't free packets when tight on URBs commit `b442723fce` upstream. Flooding the Kvaser CAN to USB dongle with multiple reads and writes in high frequency caused seemingly-random panics in the kernel. On further inspection, it seems the driver erroneously freed the to-be-transmitted packet upon getting tight on URBs and returning NETDEV_TX_BUSY, leading to invalid memory writes and double frees at a later point in time. Note: Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY is a driver bug in and out of itself: it means that our start/stop queue flow control is broken. This patch only fixes the (buggy) error handling code; the root cause shall be fixed in a later commit. Acked-by: Olivier Sobrie <olivier@sobrie.be> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Sebastian Andrzej Siewior	81699fed3c	usb: musb: stuff leak of struct usb_hcd commit `68693b8ea4` upstream. since the split of host+gadget mode in commit `74c2e93600` ("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: `74c2e93600` ("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>	2015-01-27 08:29:43 -08:00
Alan Stern	99688ecfbc	USB: EHCI: fix initialization bug in iso_stream_schedule() commit `6d89252a99` upstream. Commit `c3ee9b76aa` (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: `c3ee9b76aa` Reported-by: Joe Bryant <tenminjoe@yahoo.com> Tested-by: Joe Bryant <tenminjoe@yahoo.com> Tested-by: Martin Long <martin@longhome.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Johan Hovold	72934919ba	USB: console: fix potential use after free commit `32a4bf2e81` 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: `4a90f09b20` ("tty: usb-serial krefs") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Johan Hovold	68d91b4c79	USB: console: fix uninitialised ldisc semaphore commit `d269d4434c` 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: `36697529b5` ("tty: Replace ldisc locking with ldisc_sem") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Songjun Wu	f33e402782	usb: gadget: udc: atmel: fix possible oops when unloading module commit `5fb694f96e` 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: `914a3f3b37` ("USB: add atmel_usba_udc driver") Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Bo Shen	967e5620db	usb: gadget: udc: atmel: fix possible IN hang issue commit `6785a10344` 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: `914a3f3b37` (USB: add atmel_usba_udc driver) Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:43 -08:00
Bo Shen	c811188452	usb: gadget: udc: atmel: change setting for DMA commit `f40afdddeb` 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: `914a3f3b37` (USB: add atmel_usba_udc driver) Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Mario Schuknecht	84ac889bee	usb: gadget: gadgetfs: Free memory allocated by memdup_user() commit `b44be2462d` upstream. Commit `3b74c73f8d` switched over to memdup_user() in ep_write() function and removed kfree (kbuf). memdup_user() function allocates memory which is never freed. Fixes: `3b74c73` (usb: gadget: inode: switch over to memdup_user()) Signed-off-by: Mario Schuknecht <mario.schuknecht@dresearch-fe.de> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Johan Hovold	2c5d2dde06	USB: keyspan: fix null-deref at probe commit `b5122236bb` upstream. Fix null-pointer dereference during probe if the interface-status completion handler is called before the individual ports have been set up. Fixes: `f79b2d0fe8` ("USB: keyspan: fix NULL-pointer dereferences and memory leaks") Reported-by: Richard <richjunk@pacbell.net> Tested-by: Richard <richjunk@pacbell.net> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Reinhard Speyerer	14d38f7d80	USB: qcserial/option: make AT URCs work for Sierra Wireless MC73xx commit `d80c0d1418` 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 `70a3615fc0` ("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: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
David Peterson	34aa8bbd74	USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices commit `1ae78a4870` 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: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Preston Fick	ee4597bd5a	USB: cp210x: fix ID for production CEL MeshConnect USB Stick commit `90441b4dbe` 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: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Amit Virdi	11fb1b9574	usb: dwc3: gadget: Stop TRB preparation after limit is reached commit `39e60635a0` 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: `eeb720fb21` (usb: dwc3: gadget: add support for SG lists) Signed-off-by: Amit Virdi <amit.virdi@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Amit Virdi	64227c12bb	usb: dwc3: gadget: Fix TRB preparation during SG commit `ec512fb8e5` 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: `e5ba5ec833` (usb: dwc3: gadget: fix scatter gather implementation) Signed-off-by: Amit Virdi <amit.virdi@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Arseny Solokha	8db5755be1	OHCI: add a quirk for ULi M5237 blocking on reset commit `56abcab833` upstream. Commit `8dccddbc23` ("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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Johan Hovold	f0f49ab7a0	gpio: sysfs: fix gpio device-attribute leak commit `0915e6feb3` 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: `d8f388d8dc` ("gpio: sysfs interface") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Johan Hovold	3d6b88b342	gpio: sysfs: fix gpio-chip device-attribute leak commit `121b6a7995` 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: `d8f388d8dc` ("gpio: sysfs interface") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Johan Hovold	72d8d4dd17	gpio: fix sleep-while-atomic in gpiochip_remove commit `6798acaa01` 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: `9ef0d6f762` ("gpiolib: call pin removal in chip removal function") Fixes: `f23f1516b6` ("gpiolib: provide provision to register pin ranges") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:42 -08:00
Johan Hovold	2bc26f4444	gpio: fix memory leak and sleep-while-atomic commit `00acc3dc24` upstream. Fix memory leak and sleep-while-atomic in gpiochip_remove. The memory leak was introduced by `afa82fab5e` ("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 `1425052097` ("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: `afa82fab5e` ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") Fixes: `1425052097` ("gpio: add IRQ chip helpers in gpiolib") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Johan Hovold	e1c76d694f	gpio: fix memory and reference leaks in gpiochip_add error path commit `5539b3c938` 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: `391c970c0d` ("of/gpio: add default of_xlate function if device has a node pointer") Fixes: `664e3e5ac6` ("gpio / ACPI: register to ACPI events automatically") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Aaron Lu	fe7930b607	gpio: crystalcove: use handle_nested_irq commit `e733a2fb8c` 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=90521 Reported-and-tested-by: Brian Loften <bloften80@gmail.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Hans Holmberg	0dc7c71158	gpiolib: of: Correct error handling in of_get_named_gpiod_flags commit `7b8792bbdf` 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: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Johan Hovold	f32b586a9d	pinctrl: lantiq: remove bogus of_gpio_chip_add commit `41f632fe17` 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: `3f8c50c9b1` ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Jisheng Zhang	d384560254	ARM: dts: berlin: correct BG2Q's SM GPIO location. commit `5138d5c562` 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: `cedf57fc4f` ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Tyler Baker	a96747d8e1	reset: sunxi: fix spinlock initialization commit `41544f9f38` 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-optimus Signed-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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Hans de Goede	e77b867c93	uas: Add US_FL_NO_ATA_1X for 2 more Seagate disk enclosures commit `3ca8c71742` 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Hans de Goede	03642fd92a	uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS566 with usb-id 0bc2:a013 commit `c6fa3945c8` 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 <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Hans de Goede	887934ee2b	uas: Add US_FL_NO_ATA_1X for Seagate devices with usb-id 0bc2:a013 commit `e5797a3d07` 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: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Alexander Usyskin	ee45552ef3	mei: clean reset bit before reset commit `b13a65ef19` 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Trond Myklebust	60ff540168	NFSv4.1: Fix client id trunking on Linux commit `1fc0703af3` 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: `05f4c350ee` ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Steven Rostedt (Red Hat)	a2a15f402d	ftrace: Check both notrace and filter for old hash commit `7485058eea` 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Steven Rostedt (Red Hat)	edc9d33659	ftrace: Fix updating of filters for shared global_ops filters commit `8f86f83709` 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.org Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Steven Rostedt (Red Hat)	7769f8be6b	ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing commit `237d28db03` 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.org Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:41 -08:00
Simon Guinot	87a5d5643f	leds: netxbig: fix oops at probe time commit `0c86ac2c50` 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 `588a6a9928` ("leds: netxbig: fix attribute-creation race"). Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Mugunthan V N	76da8f966f	drivers: net: cpsw: fix multicast flush in dual emac mode commit `25906052d9` 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: `d9ba8f9` (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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Vasu Dev	d8682e1d26	i40e: adds FCoE configure option commit `776d4e9f5c` 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: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Eyal Shapira	87a1898761	iwlwifi: mvm: fix Rx with both chains commit `c93edc6393` upstream. commit `5c90422439` "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: `5c90422439` ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Catalin Marinas	27f16502f0	arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned" commit `0145058c3d` upstream. This patch partially reverts commit `421520ba98` (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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Tim Kryger	6a315939e6	mmc: sdhci: Set SDHCI_POWER_ON with external vmmc commit `3cbc6123a9` 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 `5222161` mmc: sdhci: Improve external VDD regulator support. Fixes: `52221610dd` (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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Anton Blanchard	e247868d3b	powernv: Fix OPAL tracepoint code commit `bfe5fda8e7` upstream. Patch `c49f63530b` ("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: `c49f63530b` ("powernv: Add OPAL tracepoints") Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
NeilBrown	d5471f896b	locks: fix NULL-deref in generic_delete_lease commit `52d304eb4e` upstream. commit `0efaa7e82f` locks: generic_delete_lease doesn't need a file_lock at all moves the call to fl->fl_lmops->lm_change() to a place in the code where fl might be a non-lease lock. When that happens, fl_lmops is NULL and an Oops ensures. So add an extra test to restore correct functioning. Reported-by: Linda Walsh <suse@tlinx.org> Link: https://bugzilla.suse.com/show_bug.cgi?id=912569 Fixes: `0efaa7e82f` Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Wei Yang	820b511fc4	vfio-pci: Fix the check on pci device type in vfio_pci_probe() commit `7c2e211f3c` upstream. Current vfio-pci just supports normal pci device, so vfio_pci_probe() will return if the pci device is not a normal device. While current code makes a mistake. PCI_HEADER_TYPE is the offset in configuration space of the device type, but we use this value to mask the type value. This patch fixs this by do the check directly on the pci_dev->hdr_type. Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Hans Verkuil	24a209fd9b	vivid: fix CROP_BOUNDS typo for video output commit `bb9ff07886` upstream. An error was returned if composing was not supported, instead of if cropping was not supported. A classic copy-and-paste bug. Found with v4l2-compliance. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
James Hogan	e6bd63e792	img-ir/hw: Fix potential deadlock stopping timer commit `ac03086067` upstream. The end timer is used for switching back from repeat code timings when no repeat codes have been received for a certain amount of time. When the protocol is changed, the end timer is deleted synchronously with del_timer_sync(), however this takes place while holding the main spin lock, and the timer handler also needs to acquire the spin lock. This opens the possibility of a deadlock on an SMP system if the protocol is changed just as the repeat timer is expiring. One CPU could end up in img_ir_set_decoder() holding the lock and waiting for the end timer to complete, while the other CPU is stuck in the timer handler spinning on the lock held by the first CPU. Lockdep also spots a possible lock inversion in the same code, since img_ir_set_decoder() acquires the img-ir lock before the timer lock, but the timer handler will try and acquire them the other way around: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.18.0-rc5+ #957 Not tainted --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); * DEADLOCK * This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); * DEADLOCK * This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Dylan Rajaratnam	7abbdc9589	img-ir/hw: Always read data to clear buffer commit `ea0de4ec54` upstream. A problem was found on Polaris where if the unit it booted via the power button on the infrared remote then the next button press on the remote would return the key code used to power on the unit. The sequence is: - The polaris powered off but with the powerdown controller (PDC) block still powered. - Press power key on remote, IR block receives the key. - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL or IMG_IR_RXDVALD2 are set. - Wait any amount of time. - Press any key. - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is unchanged since the powerup key data was never read. This is worked around by always reading the IMG_IR_DATA_x in img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or IMG_IR_RXDVALD2 bit is set. Signed-off-by: Dylan Rajaratnam <dylan.rajaratnam@imgtec.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Takashi Iwai	73db430b66	uvcvideo: Fix destruction order in uvc_delete() commit `2228d80dd0` upstream. We've got a bug report at disconnecting a Webcam, where the kernel spews warnings like below: WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90() sysfs group c0b2350c not found for kobject 'event3' CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1 Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013 11/12/2004 c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1 c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064 ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7 Call Trace: [<c0205ba6>] try_stack_unwind+0x156/0x170 [<c02046f3>] dump_trace+0x53/0x180 [<c0205c06>] show_trace_log_lvl+0x46/0x50 [<c0204871>] show_stack_log_lvl+0x51/0xe0 [<c0205c67>] show_stack+0x27/0x50 [<c0718c5b>] dump_stack+0x3e/0x4e [<c024b654>] warn_slowpath_common+0x84/0xa0 [<c024b6a3>] warn_slowpath_fmt+0x33/0x40 [<c03d1ec7>] sysfs_remove_group+0x87/0x90 [<c05a2c54>] device_del+0x34/0x180 [<c05e3989>] evdev_disconnect+0x19/0x50 [<c05e06fa>] __input_unregister_device+0x9a/0x140 [<c05e0845>] input_unregister_device+0x45/0x80 [<f854b1d6>] uvc_delete+0x26/0x110 [uvcvideo] [<f84d66f8>] v4l2_device_release+0x98/0xc0 [videodev] [<c05a25bb>] device_release+0x2b/0x90 [<c04ad8bf>] kobject_cleanup+0x6f/0x1a0 [<f84d5453>] v4l2_release+0x43/0x70 [videodev] [<c0372f31>] __fput+0xb1/0x1b0 [<c02650c1>] task_work_run+0x91/0xb0 [<c024d845>] do_exit+0x265/0x910 [<c024df64>] do_group_exit+0x34/0xa0 [<c025a76f>] get_signal_to_deliver+0x17f/0x590 [<c0201b6a>] do_signal+0x3a/0x960 [<c02024f7>] do_notify_resume+0x67/0x90 [<c071ebb5>] work_notifysig+0x30/0x3b [<b7739e60>] 0xb7739e5f ---[ end trace b1e56095a485b631 ]--- The cause is that uvc_status_cleanup() is called after usb_put_() in uvc_delete(). usb_put_() removes the sysfs parent and eventually removes the children recursively, so the later device_del() can't find its sysfs. The fix is simply rearrange the call orders in uvc_delete() so that the child is removed before the parent. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736 Reported-and-tested-by: Martin Pluskal <mpluskal@suse.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Mauro Carvalho Chehab	3971a1c954	sound: Update au0828 quirks table commit `678fa12fb8` upstream. The au0828 quirks table is currently not in sync with the au0828 media driver. Syncronize it and put them on the same order as found at au0828 driver, as all the au0828 devices with analog TV need the same quirks. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:40 -08:00
Mauro Carvalho Chehab	5eb7814b21	sound: simplify au0828 quirk table commit `5d1f00a20d` upstream. Add a macro to simplify au0828 quirk table. That makes easier to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Sakari Ailus	129d51a91f	smiapp: Take mutex during PLL update in sensor initialisation commit `f85698cd29` upstream. The mutex does not serialise anything in this case but avoids a lockdep warning from the control framework. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Frank Schaefer	8d5d2e1310	af9005: fix kernel panic on init if compiled without IR commit `2279948735` upstream. This patches fixes an ancient bug in the dvb_usb_af9005 driver, which has been reported at least in the following threads: https://lkml.org/lkml/2009/2/4/350 https://lkml.org/lkml/2014/9/18/558 If the driver is compiled in without any IR support (neither DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in af9005_usb_module_init() return pointers != NULL although the IR symbols are not available. This leads to the following oops: ... [ 8.529751] usbcore: registered new interface driver dvb_usb_af9005 [ 8.531584] BUG: unable to handle kernel paging request at 02e00000 [ 8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d [ 8.535613] *pde = 00000000 [ 8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC [ 8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1 [ 8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000 [ 8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0 [ 8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d [ 8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000 [ 8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c [ 8.541519] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690 [ 8.541519] Stack: [ 8.541519] 7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968 [ 8.541519] 89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200 [ 8.541519] 7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6 [ 8.541519] Call Trace: [ 8.541519] [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16 [ 8.541519] [<7d992a49>] do_one_initcall+0x77/0x106 [ 8.541519] [<7be3a800>] ? parameqn+0x2/0x35 [ 8.541519] [<7be3a966>] ? parse_args+0x113/0x25c [ 8.541519] [<7d992bc2>] kernel_init_freeable+0xea/0x167 [ 8.541519] [<7cf01070>] kernel_init+0x8/0xb8 [ 8.541519] [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30 [ 8.541519] [<7cf01068>] ? rest_init+0x10c/0x10c [ 8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb [ 8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c [ 8.541519] CR2: 0000000002e00000 [ 8.541519] ---[ end trace 768b6faf51370fc7 ]--- The prefered fix would be to convert the whole IR code to use the kernel IR infrastructure (which wasn't available at the time this driver had been created). Until anyone who still has this old hardware steps up an does the conversion, fix it by not calling the symbol_request calls if the driver is compiled in without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE). Due to the IR related pointers beeing NULL by default, IR support will then be disabled. The downside of this solution is, that it will no longer be possible to compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in. Please note that this patch has NOT been tested with all possible cases. I don't have the hardware and could only verify that it fixes the reported bug. Reported-by: Fengguag Wu <fengguang.wu@intel.com> Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Luca Olivetti <luca@ventoso.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Sakari Ailus	b5b7b720cb	smiapp-pll: Correct clock debug prints commit `bc47150ab9` upstream. The PLL flags were not used correctly. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Tomi Valkeinen	e5dcc09dd9	video/fbdev: fix defio's fsync commit `30ea9c5218` upstream. fb_deferred_io_fsync() returns the value of schedule_delayed_work() as an error code, but schedule_delayed_work() does not return an error. It returns true/false depending on whether the work was already queued. Fix this by ignoring the return value of schedule_delayed_work(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Tomi Valkeinen	7c73bd96b4	video/logo: prevent use of logos after they have been freed commit `92b004d1aa` upstream. If the probe of an fb driver has been deferred due to missing dependencies, and the probe is later ran when a module is loaded, the fbdev framework will try to find a logo to use. However, the logos are __initdata, and have already been freed. This causes sometimes page faults, if the logo memory is not mapped, sometimes other random crashes as the logo data is invalid, and sometimes nothing, if the fbdev decides to reject the logo (e.g. the random value depicting the logo's height is too big). This patch adds a late_initcall function to mark the logos as freed. In reality the logos are freed later, and fbdev probe may be ran between this late_initcall and the freeing of the logos. In that case we will miss drawing the logo, even if it would be possible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Bjørn Mork	bf80baa10a	x86/build: Clean auto-generated processor feature files commit `280dbc5723` upstream. Commit `9def39be4e` ("x86: Support compiling out human-friendly processor feature names") made two source file targets conditional. Such conditional targets will not be cleaned automatically by make mrproper. Fix by adding explicit clean-files targets for the two files. Fixes: `9def39be4e` ("x86: Support compiling out human-friendly processor feature names") Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: Josh Triplett <josh@joshtriplett.org> Link: http://lkml.kernel.org/r/1419335863-10608-1-git-send-email-bjorn@mork.no Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Felipe Balbi	7e20e84067	net: ethernet: cpsw: fix hangs with interrupts commit `7ce67a38f7` upstream. The CPSW IP implements pulse-signaled interrupts. Due to that we must write a correct, pre-defined value to the CPDMA_MACEOIVECTOR register so the controller generates a pulse on the correct IRQ line to signal the End Of Interrupt. The way the driver is written today, all four IRQ lines are requested using the same IRQ handler and, because of that, we could fall into situations where a TX IRQ fires but we tell the controller that we ended an RX IRQ (or vice-versa). This situation triggers an IRQ storm on the reserved IRQ 127 of INTC which will in turn call ack_bad_irq() which will, then, print a ton of: unexpected IRQ trap at vector 00 In order to fix the problem, we are moving all calls to cpdma_ctlr_eoi() inside the IRQ handler and making sure we always write the correct value to the CPDMA_MACEOIVECTOR register. Note that the algorithm assumes that IRQ numbers and value-to-be-written-to-EOI are proportional, meaning that a write of value 0 would trigger an EOI pulse for the RX_THRESHOLD Interrupt and that's the IRQ number sitting in the 0-th index of our irqs_table array. This, however, is safe at least for current implementations of CPSW so we will refrain from making the check smarter (and, as a side-effect, slower) until we actually have a platform where IRQ lines are swapped. This patch has been tested for several days with AM335x- and AM437x-based platforms. AM57x was left out because there are still pending patches to enable ethernet in mainline for that platform. A read of the TRM confirms the statement on previous paragraph. Reported-by: Yegor Yefremov <yegorslists@googlemail.com> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly) Signed-off-by: Felipe Balbi <balbi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Long Li	143b34a4a5	storvsc: ring buffer failures may result in I/O freeze commit `e86fb5e8ab` upstream. When ring buffer returns an error indicating retry, storvsc may not return a proper error code to SCSI when bounce buffer is not used. This has introduced I/O freeze on RAID running atop storvsc devices. This patch fixes it by always returning a proper error code. Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
James Bottomley	ac5a275b14	serial: fix parisc boot hang commit `68ed7e1c3d` upstream. This is a partial revert of `2f2dafe` (serial: serial_core.c: printk replacement) which gets us booting again. The real problem seems to be the _emit path in early boot. However, until we can root cause it, we need at least to get boot working. Fixes: `2f2dafe77d` Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
John David Anglin	52925954eb	parisc: fix out-of-register compiler error in ldcw inline assembler function commit `45db07382a` upstream. The __ldcw macro has a problem when its argument needs to be reloaded from memory. The output memory operand and the input register operand both need to be reloaded using a register in class R1_REGS when generating 64-bit code. This fails because there's only a single register in the class. Instead, use a memory clobber. This also makes the __ldcw macro a compiler memory barrier. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
zhendong chen	31b6929b57	dm: fix missed error code if .end_io isn't implemented by target_type commit `5164bece16` upstream. In bio-based DM's clone_endio(), when target_type doesn't implement .end_io (e.g. linear) r will be always be initialized 0. So if a WRITE SAME bio fails WRITE SAME will not be disabled as intended. Fix this by initializing r to error, rather than 0, in clone_endio(). Signed-off-by: Alex Chen <alex.chen@huawei.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Fixes: `7eee4ae2db` ("dm: disable WRITE SAME if it fails") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Mauro Carvalho Chehab	3b7dd6ec0f	bugon.cocci: fix Options at the macro commit `7426977c8e` upstream. The comma after --no-includes makes coccinelle to not run the script: /usr/bin/spatch -D report --very-quiet --no-show-diff --cocci-file ./scripts/coccinelle/misc/bugon.cocci --no-includes, --include-headers --patch . --dir drivers/media/platform/coda/ -I ./arch/x86/include -I arch/x86/include/generated -I include -I ./arch/x86/include/uapi -I arch/x86/include/generated/uapi -I ./include/uapi -I include/generated/uapi -I ./include/linux/kconfig.h Usage: spatch.opt --sp-file <SP> <infile> [-o <outfile>] [--iso-file <iso>] [options] Options are: --sp-file <file> the semantic patch file -o <file> the output file --in-place do the modification on the file directly --backup-suffix suffix to use when making a backup for inplace ... At least with Fedora 20 coccinelle package: coccinelle-1.0.0-0.rc20.1.fc21.x86_64 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Tested-by: Wolfram Sang <wsa@the-dreams.de> Fixes: `5be1df66` (Coccinelle: Script to replace if and BUG with BUG_ON) Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Jisheng Zhang	f12848067b	ARM: dts: berlin: fix io clk and add missing core clk for BG2Q sdhci2 host commit `96ed6046d3` upstream. On BG2Q, the sdhci2 host uses nfcecc for "io" clk and nfc for "core" clk. The shdci2 can't work without this patch due to the "core" clk is gated. Fixes: `0d859a6a9d` ("ARM: dts: berlin: add the SDHCI nodes for the BG2Q") Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:39 -08:00
Boris Brezillon	8f3922eea5	clk: at91: keep slow clk enabled to prevent system hang commit `dca1a4b5ff` upstream. All slow clk users are not properly claiming it (get + prepare + enable) before using it. If all users properly claiming this clock release it, the clock is disabled, but faulty users still depends on it, and the system hangs. This fix prevents the slow clock from being disabled, and should solve the hanging issue, but offending drivers should be patched to properly claim this clock. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Jisheng Zhang	cfde14bfad	clk: berlin: bg2q: remove non-exist "smemc" gate clock commit `b71e8ecd57` upstream. The "smemc" clock is removed on BG2Q SoCs. In fact, bit19 of clkenable register is for nfc. Current code use bit19 for non-exist "smemc" incorrectly, this prevents eMMC from working due to the sdhci's "core" clk is still gated. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Heiko Stuebner	94085032b4	clk: rockchip: fix rk3066 pll lock bit location commit `12551f0239` upstream. The bit locations indicating the locking status of the plls on rk3066 are shifted by one to the right when compared to the rk3188, bits [7:4] instead of [8:5] on the rk3188, thus indicating the locking state of the wrong pll or a completely different information in case of the gpll. The recently introduced pll init code exposed that problem on some rk3066 boards when it tried to bring the boot-pll value in line with the value from the rate table. Fix this by defining separate pll definitions for rk3066 with the correct locking indices. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Fixes: `2c14736c75` ("clk: rockchip: add clock driver for rk3188 and rk3066 clocks") Tested-by: FUKAUMI Naoki <naobsd@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Heiko Stuebner	a195f75321	clk: rockchip: fix rk3288 cpuclk core dividers commit `9880d4277f` upstream. Commit `0e5bdb3f9f` (clk: rockchip: switch to using the new cpuclk type for armclk) didn't take into account that the divider used on rk3288 are of the (n+1) type. The rk3066 and rk3188 socs use more complex divider types making it necessary for the list-elements to be the real register-values to write. Therefore reduce divider values in the table accordingly so that they really are the values that should be written to the registers and match the dividers actually specified for the rk3288. Reported-by: Sonny Rao <sonnyrao@chromium.org> Fixes: `0e5bdb3f9f` ("clk: rockchip: switch to using the new cpuclk type for armclk") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Kevin Hao	f3067bf776	Revert "clk: ppc-corenet: Fix Section mismatch warning" commit `176a107b86` upstream. This reverts commit `da788acb28`. That commit tried to fix the section mismatch warning by moving the ppc_corenet_clk_driver struct to init section. This is definitely wrong because the kernel would free the memories occupied by this struct after boot while this driver is still registered in the driver core. The kernel would panic when accessing this driver struct. Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Tomeu Vizoso	fcdb6d6101	clk: Don't try to use a struct clk* after it could have been freed commit `10cdfe54da` upstream. As __clk_release could call kfree on clk and then we wouldn't have a safe way of getting the module that owns the clock. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Fixes: `fcb0ee6a3d` ("clk: Implement clk_unregister") Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Stephen Boyd	e2481b604d	clk: Really fix deadlock with mmap_sem commit `89f7e9de59` upstream. Commit `6314b6796e` (clk: Don't hold prepare_lock across debugfs creation, 2014-09-04) forgot to update one place where we hold the prepare_lock while creating debugfs directories. This means we still have the chance of a deadlock that the commit was trying to fix. Actually fix it by moving the debugfs creation outside the prepare_lock. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Fixes: `6314b6796e` "clk: Don't hold prepare_lock across debugfs creation" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Michael Turquette <mturquette@linaro.org> [mturquette@linaro.org: removed lockdep_assert] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Krzysztof Kozlowski	e553baaa08	clk: samsung: Fix double add of syscore ops after driver rebind commit `c31844ffdb` upstream. During driver unbind the syscore ops were not unregistered which lead to double add on syscore list: $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/unbind $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/bind [ 1463.044061] ------------[ cut here ]------------ [ 1463.047255] WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36 __list_add+0x8c/0xc0() [ 1463.054613] list_add double add: new=c06e52c0, prev=c06e52c0, next=c06d5f84. [ 1463.061625] Modules linked in: [ 1463.064623] CPU: 0 PID: 1 Comm: bash Tainted: G W 3.18.0-rc5-next-20141121-00005-ga8fab06eab42-dirty #1022 [ 1463.075338] [<c0014e2c>] (unwind_backtrace) from [<c0011d80>] (show_stack+0x10/0x14) [ 1463.083046] [<c0011d80>] (show_stack) from [<c048bb70>] (dump_stack+0x70/0xbc) [ 1463.090236] [<c048bb70>] (dump_stack) from [<c00233d4>] (warn_slowpath_common+0x74/0xb0) [ 1463.098295] [<c00233d4>] (warn_slowpath_common) from [<c00234a4>] (warn_slowpath_fmt+0x30/0x40) [ 1463.106962] [<c00234a4>] (warn_slowpath_fmt) from [<c020fe80>] (__list_add+0x8c/0xc0) [ 1463.114760] [<c020fe80>] (__list_add) from [<c0282094>] (register_syscore_ops+0x30/0x3c) [ 1463.122819] [<c0282094>] (register_syscore_ops) from [<c0392f20>] (exynos_audss_clk_probe+0x36c/0x460) [ 1463.132091] [<c0392f20>] (exynos_audss_clk_probe) from [<c0283084>] (platform_drv_probe+0x48/0xa4) [ 1463.141013] [<c0283084>] (platform_drv_probe) from [<c0281a14>] (driver_probe_device+0x13c/0x37c) [ 1463.149852] [<c0281a14>] (driver_probe_device) from [<c0280560>] (bind_store+0x90/0xe0) [ 1463.157822] [<c0280560>] (bind_store) from [<c027fd10>] (drv_attr_store+0x20/0x2c) [ 1463.165363] [<c027fd10>] (drv_attr_store) from [<c0143898>] (sysfs_kf_write+0x4c/0x50) [ 1463.173252] [<c0143898>] (sysfs_kf_write) from [<c0142c80>] (kernfs_fop_write+0xbc/0x198) [ 1463.181395] [<c0142c80>] (kernfs_fop_write) from [<c00e2be0>] (vfs_write+0xa0/0x1a8) [ 1463.189104] [<c00e2be0>] (vfs_write) from [<c00e2f00>] (SyS_write+0x40/0x8c) [ 1463.196122] [<c00e2f00>] (SyS_write) from [<c000f2a0>] (ret_fast_syscall+0x0/0x48) [ 1463.203655] ---[ end trace 08f6710c9bc8d8f3 ]--- [ 1463.208244] exynos-audss-clk 3810000.audss-clock-controller: setup completed Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `1241ef94cc` ("clk: samsung: register audio subsystem clocks using common clock framework") Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Alan Stern	f8db847bcc	SCSI: fix regression in scsi_send_eh_cmnd() commit `511833acfc` upstream. Commit `ac61d19559` (scsi: set correct completion code in scsi_send_eh_cmnd()) introduced a bug. It changed the stored return value from a queuecommand call, but it didn't take into account that the return value was used again later on. This patch fixes the bug by changing the later usage. There is a big comment in the middle of scsi_send_eh_cmnd() which does a good job of explaining how the routine works. But it mentions a "rtn = FAILURE" value that doesn't exist in the code. This patch adjusts the code to match the comment (I assume the comment is right and the code is wrong). This fixes Bugzilla #88341. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Андрей Аладьев <aladjev.andrew@gmail.com> Tested-by: Андрей Аладьев <aladjev.andrew@gmail.com> Fixes: `ac61d19559` Acked-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Tony Battersby	7fbdd0ef30	scsi: fix random memory corruption with scsi-mq + T10 PI commit `120bb3e1e3` upstream. This fixes random memory corruption triggered when all three of the following are true: * scsi-mq enabled * T10 Protection Information (DIF) enabled * SCSI host with sg_tablesize > SCSI_MAX_SG_SEGMENTS (128) The symptoms of this bug are unpredictable memory corruption, BUG()s, oopses, lockups, etc., any of which may appear to be completely unrelated to the root cause. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Martin K. Petersen	5f5628fbda	scsi: blacklist RSOC for Microsoft iSCSI target devices commit `198a956a11` upstream. The Microsoft iSCSI target does not support REPORT SUPPORTED OPERATION CODES. Blacklist these devices so we don't attempt to send the command. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Tested-by: Mike Christie <michaelc@cs.wisc.edu> Reported-by: jazz@deti74.ru Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Sreekanth Reddy	f6637f8ef1	Revert "[SCSI] mpt3sas: Remove phys on topology change" commit `2311ce4d9c` upstream. This reverts commit `963ba22b90` ("mpt3sas: Remove phys on topology change") Reverting the previous mpt3sas drives patch changes, since we will observe below issue Issue: Drives connected Enclosure/Expander will unregister with SCSI Transport Layer, if any one remove and add expander cable with in DMD (Device Missing Delay) time period or even any one power-off and power-on the Enclosure with in the DMD period. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Sreekanth Reddy	f3018e1f5a	Revert "[SCSI] mpt2sas: Remove phys on topology change." commit `81a89c2d89` upstream. This reverts commit `3520f9c779` ("mpt2sas: Remove phys on topology change") Reverting the previous mpt2sas drives patch changes, since we will observe below issue Issue: Drives connected Enclosure/Expander will unregister with SCSI Transport Layer, if any one remove and add expander cable with in DMD (Device Missing Delay) time period or even any one power-off and power-on the Enclosure with in the DMD period. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Ville Syrjälä	527400f894	Revert "drm/i915: Preserve VGACNTR bits from the BIOS" commit `01f5a6261c` upstream. The VGA_2X_MODE bit apparently affects the display even when the VGA plane is disabled. The bit will set by the BIOS when the panel width is at least 1280 pixels. So by preserving the bit from the BIOS we end up with corrupted display on machines with such high res panels. I only have 1024x768 panels on my gen2 machines so never ran into this problem. The original reason for preserving the VGACNTR register was to make my 830 survive S3 with acpi_sleep=s3_bios option. However after further 830 fixes that option is no longer needed to make S3 work and preserving VGACNTR doesn't seem to be necessary without it, so we can just revert the entire patch. This reverts commit `69769f9a42` Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Aug 15 01:22:08 2014 +0300 drm/i915: Preserve VGACNTR bits from the BIOS Cc: Bruno Prémont <bonbons@linux-vserver.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:38 -08:00
Sagi Grimberg	5786521105	iscsi,iser-target: Expose supported protection ops according to t10_pi commit `23a548ee65` upstream. iSER will report supported protection operations based on the tpg attribute t10_pi settings and HCA PI offload capabilities. If the HCA does not support PI offload or tpg attribute t10_pi is not set, we fall to SW PI mode. In order to do that, we move iscsit_get_sup_prot_ops after connection tpg assignment. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	7737bb03f5	iser-target: Fix NULL dereference in SW mode DIF commit `302cc7c3ca` upstream. Fallback to software mode DIF if HCA does not support PI (without crashing obviously). It is still possible to run with backend protection and an unprotected frontend, so looking at the command prot_op is not enough. Check device PI capability on a per-IO basis (isert_prot_cmd inline static) to determine if we need to handle protection information. Trace: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffffa037f8b1>] isert_reg_sig_mr+0x351/0x3b0 [ib_isert] Call Trace: [<ffffffff812b003a>] ? swiotlb_map_sg_attrs+0x7a/0x130 [<ffffffffa038184d>] isert_reg_rdma+0x2fd/0x370 [ib_isert] [<ffffffff8108f2ec>] ? idle_balance+0x6c/0x2c0 [<ffffffffa0382b68>] isert_put_datain+0x68/0x210 [ib_isert] [<ffffffffa02acf5b>] lio_queue_data_in+0x2b/0x30 [iscsi_target_mod] [<ffffffffa02306eb>] target_complete_ok_work+0x21b/0x310 [target_core_mod] [<ffffffff8106ece2>] process_one_work+0x182/0x3b0 [<ffffffff8106fda0>] worker_thread+0x120/0x3c0 [<ffffffff8106fc80>] ? maybe_create_worker+0x190/0x190 [<ffffffff8107594e>] kthread+0xce/0xf0 [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8159a22c>] ret_from_fork+0x7c/0xb0 [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70 Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	80e47cd140	iser-target: Allocate PI contexts dynamically commit `570db170f3` upstream. This patch converts to allocate PI contexts dynamically in order avoid a potentially bogus np->tpg_np and associated NULL pointer dereference in isert_connect_request() during iser-target endpoint shutdown with multiple network portals. Also, there is really no need to allocate these at connection establishment since it is not guaranteed that all the IOs on that connection will be to a PI formatted device. We can do it in a lazy fashion so the initial burst will have a transient slow down, but very fast all IOs will allocate a PI context. Squashed: iser-target: Centralize PI context handling code Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	a536c94faf	iser-target: Fix implicit termination of connections commit `b02efbfc9a` upstream. In situations such as bond failover, The new session establishment implicitly invokes the termination of the old connection. So, we don't want to wait for the old connection wait_conn to completely terminate before we accept the new connection and post a login response. The solution is to deffer the comp_wait completion and the conn_put to a work so wait_conn will effectively be non-blocking (flush errors are assumed to come very fast). We allocate isert_release_wq with WQ_UNBOUND and WQ_UNBOUND_MAX_ACTIVE to spread the concurrency of release works. Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	b8444e9884	iser-target: Handle ADDR_CHANGE event for listener cm_id commit `ca6c1d82d1` upstream. The np listener cm_id will also get ADDR_CHANGE event upcall (in case it is bound to a specific IP). Handle it correctly by creating a new cm_id and implicitly destroy the old one. Since this is the second event a listener np cm_id may encounter, we move the np cm_id event handling to a routine. Squashed: iser-target: Move cma_id setup to a function Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	0105b025ad	iser-target: Fix connected_handler + teardown flow race commit `19e2090fb2` upstream. Take isert_conn pointer from cm_id->qp->qp_context. This will allow us to know that the cm_id context is always the network portal. This will make the cm_id event check (connection or network portal) more reliable. In order to avoid a NULL dereference in cma_id->qp->qp_context we destroy the qp after we destroy the cm_id (and make the dereference safe). session stablishment/teardown sequences can happen in parallel, we should take into account that connected_handler might race with connection teardown flow. Also, protect isert_conn->conn_device->active_qps decrement within the error patch during QP creation failure and the normal teardown path in isert_connect_release(). Squashed: iser-target: Decrement completion context active_qps in error flow Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	2413d956cd	iser-target: Parallelize CM connection establishment commit `2371e5da8c` upstream. There is no point in accepting a new CM request only when we are completely done with the last iscsi login. Instead we accept immediately, this will also cause the CM connection to reach connected state and the initiator is allowed to send the first login. We mark that we got the initial login and let iscsi layer pick it up when it gets there. This reduces the parallel login sequence by a factor of more then 4 (and more for multi-login) and also prevents the initiator (who does all logins in parallel) from giving up on login timeout expiration. In order to support multiple login requests sequence (CHAP) we call isert_rx_login_req from isert_rx_completion insead of letting isert_get_login_rx call it. Squashed: iser-target: Use kref_get_unless_zero in connected_handler iser-target: Acquire conn_mutex when changing connection state iser-target: Reject connect request in failure path Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	425ec46158	iser-target: Fix flush + disconnect completion handling commit `128e9cc845` upstream. ISER_CONN_UP state is not sufficient to know if we should wait for completion of flush errors and disconnected_handler event. Instead, split it to 2 states: - ISER_CONN_UP: Got to CM connected phase, This state indicates that we need to wait for a CM disconnect event before going to teardown. - ISER_CONN_FULL_FEATURE: Got to full feature phase after we posted login response, This state indicates that we posted recv buffers and we need to wait for flush completions before going to teardown. Also avoid deffering disconnected handler to a work, and handle it within disconnected handler. More work here is needed to handle DEVICE_REMOVAL event correctly (cleanup all resources). Squashed: iser-target: Don't deffer disconnected handler to a work Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Sagi Grimberg	988168465f	iscsi,iser-target: Initiate termination only once commit `954f23722b` upstream. Since commit `0fc4ea701f` ("Target/iser: Don't put isert_conn inside disconnected handler") we put the conn kref in isert_wait_conn, so we need .wait_conn to be invoked also in the error path. Introduce call to isert_conn_terminate (called under lock) which transitions the connection state to TERMINATING and calls rdma_disconnect. If the state is already teminating, just bail out back (temination started). Also, make sure to destroy the connection when getting a connect error event if didn't get to connected (state UP). Same for the handling of REJECTED and UNREACHABLE cma events. Squashed: iscsi-target: Add call to wait_conn in establishment error flow Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Nicholas Bellinger	2fc431d1bd	iscsi-target: Fail connection on short sendmsg writes commit `6bf6ca7515` upstream. This patch changes iscsit_do_tx_data() to fail on short writes when kernel_sendmsg() returns a value different than requested transfer length, returning -EPIPE and thus causing a connection reset to occur. This avoids a potential bug in the original code where a short write would result in kernel_sendmsg() being called again with the original iovec base + length. In practice this has not been an issue because iscsit_do_tx_data() is only used for transferring 48 byte headers + 4 byte digests, along with seldom used control payloads from NOPIN + TEXT_RSP + REJECT with less than 32k of data. So following Al's audit of iovec consumers, go ahead and fail the connection on short writes for now, and remove the bogus logic ahead of his proper upstream fix. Reported-by: Al Viro <viro@zeniv.linux.org.uk> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Thomas Gleixner	a27d8a2319	genirq: Prevent proc race against freeing of irq descriptors commit `c291ee6221` upstream. Since the rework of the sparse interrupt code to actually free the unused interrupt descriptors there exists a race between the /proc interfaces to the irq subsystem and the code which frees the interrupt descriptor. CPU0 CPU1 show_interrupts() desc = irq_to_desc(X); free_desc(desc) remove_from_radix_tree(); kfree(desc); raw_spinlock_irq(&desc->lock); /proc/interrupts is the only interface which can actively corrupt kernel memory via the lock access. /proc/stat can only read from freed memory. Extremly hard to trigger, but possible. The interfaces in /proc/irq/N/ are not affected by this because the removal of the proc file is serialized in procfs against concurrent readers/writers. The removal happens before the descriptor is freed. For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue as the descriptor is never freed. It's merely cleared out with the irq descriptor lock held. So any concurrent proc access will either see the old correct value or the cleared out ones. Protect the lookup and access to the irq descriptor in show_interrupts() with the sparse_irq_lock. Provide kstat_irqs_usr() which is protecting the lookup and access with sparse_irq_lock and switch /proc/stat to use it. Document the existing kstat_irqs interfaces so it's clear that the caller needs to take care about protection. The users of these interfaces are either not affected due to SPARSE_IRQ=n or already protected against removal. Fixes: `1f5a5b87f7` "genirq: Implement a sane sparse_irq allocator" Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Max Gurtovoy	f7146ce056	IB/iser: Fix possible SQ overflow commit `6ec9d4d231` upstream. Fix a regression was introduced in commit `6df5a128f0` ("IB/iser: Suppress scsi command send completions"). The sig_count was wrongly set to be static variable, thus it is possible that we won't reach to (sig_count % ISER_SIGNAL_BATCH) == 0 condition (due to races) and the send queue will be overflowed. Instead keep sig_count per connection. We don't need it to be atomic as we are safe under the iscsi session frwd_lock taken by libiscsi on the queuecommand path. Fixes: `6df5a128f0` ("IB/iser: Suppress scsi command send completions") Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Hannes Reinecke	1943a1a76b	tcm_loop: Fix wrong I_T nexus association commit `506787a2c7` upstream. tcm_loop has the I_T nexus associated with the HBA. This causes commands to become misdirected if the HBA has more than one target portal group; any command is then being sent to the first target portal group instead of the correct one. The nexus needs to be associated with the target portal group instead. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Kyle McMartin	937723cf83	uapi/linux/target_core_user.h: fix headers_install.sh badness commit `3875f15207` upstream. scripts/headers_install.sh will transform __packed to __attribute__((packed)), so the #ifndef is not necessary. (and, in fact, it's problematic, because we'll end up with the header containing: #ifndef __attribute__((packed)) #define __attribu... and so forth.) Signed-off-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Thomas Gleixner	97bb3ed647	tick/powerclamp: Remove tick_nohz_idle abuse commit `a5fd9733a3` upstream. commit `4dbd27711c` "tick: export nohz tick idle symbols for module use" was merged via the thermal tree without an explicit ack from the relevant maintainers. The exports are abused by the intel powerclamp driver which implements a fake idle state from a sched FIFO task. This causes all kinds of wreckage in the NOHZ core code which rightfully assumes that tick_nohz_idle_enter/exit() are only called from the idle task itself. Recent changes in the NOHZ core lead to a failure of the powerclamp driver and now people try to hack completely broken and backwards workarounds into the NOHZ core code. This is completely unacceptable and just papers over the real problem. There are way more subtle issues lurking around the corner. The real solution is to fix the powerclamp driver by rewriting it with a sane concept, but that's beyond the scope of this. So the only solution for now is to remove the calls into the core NOHZ code from the powerclamp trainwreck along with the exports. Fixes: `d6d71ee4a1` "PM: Introduce Intel PowerClamp Driver" Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Pan Jacob jun <jacob.jun.pan@intel.com> Cc: LKP <lkp@01.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Zhang Rui <rui.zhang@intel.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412181110110.17382@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:37 -08:00
Dominique Leuenberger	45145567d6	hp_accel: Add support for HP ZBook 15 commit `6583659e0f` upstream. HP ZBook 15 laptop needs a non-standard mapping (x_inverted). BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329 Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Hans de Goede	37c8f276b0	asus-nb-wmi: Add another wapf=4 quirk commit `841e11ccdf` upstream. Wifi on this laptop does not work unless asus-nb-wmi.wapf=4 is specified on the kerne commandline, add a quirk for this. BugLink: https://bugs.launchpad.net/bugs/1173681 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Larry Finger	42e62067a8	rtlwifi: Fix error when accessing unmapped memory in skb commit `e9538cf4f9` upstream. These drivers use 9100-byte receive buffers, thus allocating an skb requires an O(3) memory allocation. Under heavy memory loads and fragmentation, such a request can fail. Previous versions of the driver have dropped the packet and reused the old buffer; however, the new version introduced a bug in that it released the old buffer before trying to allocate a new one. The previous method is implemented here. The skb is unmapped before any attempt is made to allocate another. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Eric Biggers <ebiggers3@gmail.com> Cc: Eric Biggers <ebiggers3@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Larry Finger	7d01c211a8	rtlwifi: rtl8192ce: Set fw_ready flag commit `9a1dce3a05` upstream. The setting of this flag was missed in previous modifications. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Jouni Malinen	fff824488b	cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers commit `08f6f14777` upstream. The VHT supported channel width field is a two bit integer, not a bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and ended up rejecting 160 MHz channel width if the driver indicated support for both 160 and 80+80 MHz channels. Fixes: `3d9d1d6656` ("nl80211/cfg80211: support VHT channel configuration") (however, no real drivers had 160 MHz support it until 3.16) Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Arik Nemtsov	a7b2c7ffae	cfg80211: avoid mem leak on driver hint set commit `34f05f543f` upstream. In the already-set and intersect case of a driver-hint, the previous wiphy regdomain was not freed before being reset with a copy of the cfg80211 regdomain. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Emmanuel Grumbach	0a57c26d64	cfg80211: don't WARN about two consecutive Country IE hint commit `70dcec5a48` upstream. This can happen and there is no point in added more detection code lower in the stack. Catching these in one single point (cfg80211) is enough. Stop WARNING about this case. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=89001 Fixes: `2f1c6c572d` ("cfg80211: process non country IE conflicting first") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Luciano Coelho	65a39b3559	nl80211: check matches array length before acessing it commit `f89f46cf3a` upstream. If the userspace passes a malformed sched scan request (or a net detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH attribute without any nested matchsets, a NULL pointer dereference will occur. Fix this by checking that we do have matchsets in our array before trying to access it. BUG: unable to handle kernel NULL pointer dereference at 0000000000000024 IP: [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] PGD 865c067 PUD 865b067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat] CPU: 2 PID: 2442 Comm: iw Tainted: G O 3.17.2 #31 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000 RIP: 0010:[<ffffffffa002fd69>] [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] RSP: 0018:ffff880008d838d0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0 RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019 R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00 R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388 FS: 00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0 Stack: ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000 Call Trace: [<ffffffff814689c9>] ? nla_parse+0xb9/0x120 [<ffffffffa00306de>] nl80211_set_wowlan+0x75e/0x960 [cfg80211] [<ffffffff810bf3d5>] ? mark_held_locks+0x75/0xa0 [<ffffffff8161a77b>] genl_family_rcv_msg+0x18b/0x360 [<ffffffff810bf66d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8161a9d4>] genl_rcv_msg+0x84/0xc0 [<ffffffff8161a950>] ? genl_family_rcv_msg+0x360/0x360 [<ffffffff81618e79>] netlink_rcv_skb+0xa9/0xd0 [<ffffffff81619458>] genl_rcv+0x28/0x40 [<ffffffff816184a5>] netlink_unicast+0x105/0x180 [<ffffffff8161886f>] netlink_sendmsg+0x34f/0x7a0 [<ffffffff8105a097>] ? kvm_clock_read+0x27/0x40 [<ffffffff815c644d>] sock_sendmsg+0x8d/0xc0 [<ffffffff811a75c9>] ? might_fault+0xb9/0xc0 [<ffffffff811a756e>] ? might_fault+0x5e/0xc0 [<ffffffff815d5d26>] ? verify_iovec+0x56/0xe0 [<ffffffff815c73e0>] ___sys_sendmsg+0x3d0/0x3e0 [<ffffffff810a7be8>] ? sched_clock_cpu+0x98/0xd0 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff810bb39f>] ? up_read+0x1f/0x40 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff812146ed>] ? __fget_light+0x13d/0x160 [<ffffffff815c7b02>] __sys_sendmsg+0x42/0x80 [<ffffffff815c7b52>] SyS_sendmsg+0x12/0x20 [<ffffffff81751f69>] system_call_fastpath+0x16/0x1b Fixes: `ea73cbce4e` ("nl80211: fix scheduled scan RSSI matchset attribute confusion") Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Hans de Goede	7d277a0b5c	xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers commit `7f5c4d631a` upstream. Streams do not work reliabe on Fresco Logic FL1000G xhci controllers, trying to use them results in errors like this: 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001 As always I've ordered a pci-e addon card with a Fresco Logic controller for myself to see if I can come up with a better fix then the big hammer, in the mean time this will make uas devices work again (in usb-storage mode) for FL1000G users. Reported-by: Marcin Zajączkowski <mszpak@wp.pl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Mathias Nyman	cb7ac02a74	xhci: Check if slot is already in default state before moving it there commit `f161ead70f` upstream. Solves xhci error cases with debug messages: xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 xhci will give a context state error if we try to set a slot in default state to the same default state with a special address device command. Turns out this happends in several cases: - retry reading the device rescriptor in hub_port_init() - usb_reset_device() is called for a slot in default state - in resume path, usb_port_resume() calls hub_port_init() The default state is usually reached from most states with a reset device command without any context state errors, but using the address device command with BSA bit set (block set address) only works from the enabled state and will otherwise cause context error. solve this by checking if we are already in the default state before issuing a address device BSA=1 command. Fixes: `48fc7dbd52` ("usb: xhci: change enumeration scheme to 'new scheme'") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Ian Munsie	00ba02150d	cxl: Unmap MMIO regions when detaching a context commit `b123429e6a` upstream. If we need to force detach a context (e.g. due to EEH or simply force unbinding the driver) we should prevent the userspace contexts from being able to access the Problem State Area MMIO region further, which they may have mapped with mmap(). This patch unmaps any mapped MMIO regions when detaching a userspace context. Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Ian Munsie	3db65dba3a	cxl: Add timeout to process element commands commit `a98e6e9f4e` upstream. In the event that something goes wrong in the hardware and it is unable to complete a process element comment we would end up polling forever, effectively making the associated process unkillable. This patch adds a timeout to the process element command code path, so that we will give up if the hardware does not respond in a reasonable time. Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Ian Munsie	d4a26d119b	cxl: Change contexts_lock to a mutex to fix sleep while atomic bug commit `ee41d11d53` upstream. We had a known sleep while atomic bug if a CXL device was forcefully unbound while it was in use. This could occur as a result of EEH, or manually induced with something like this while the device was in use: echo 0000:01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind The issue was that in this code path we iterated over each context and forcefully detached it with the contexts_lock spin lock held, however the detach also needed to take the spu_mutex, and call schedule. This patch changes the contexts_lock to a mutex so that we are not in atomic context while doing the detach, thereby avoiding the sleep while atomic. Also delete the related TODO comment, which suggested an alternate solution which turned out to not be workable. Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Vineet Gupta	70819eaa82	ARC: [nsimosci] move peripherals to match model to FPGA commit `e8ef060b37` upstream. This allows the sdplite/Zebu images to run on OSCI simulation platform Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:36 -08:00
Rob Clark	a754520397	drm/irq: BUG_ON() -> WARN_ON() commit `7f907bf284` upstream. Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: Anand Moon <moon.linux@yahoo.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Ville Syrjälä	00a80b7549	drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4 commit `7d47559ee8` upstream. The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Chris Wilson	bb0edc80da	drm/i915: Disable PSMI sleep messages on all rings around context switches commit `2c55018347` upstream. There exists a current workaround to prevent a hang on context switch should the ring go to sleep in the middle of the restore, WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In spite of disabling arbitration (which prevents the ring from powering down during the critical section) we were still hitting hangs that had the hallmarks of the known erratum. That is we are still seeing hangs "on the last instruction in the context restore". By comparing -nightly (broken) with requests (working), we were able to deduce that it was the semaphore LRI cross-talk that reproduced the original failure. The key was that requests implemented deferred semaphore signalling, and disabling that, i.e. emitting the semaphore signal to every other ring after every batch restored the frequent hang. Explicitly disabling PSMI sleep on the RCS ring was insufficient, all the rings had to be awake to prevent the hangs. Fortunately, we can reduce the wakelock to the MI_SET_CONTEXT operation itself, and so should be able to limit the extra power implications. Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above products, we should apply this extra hammer for all of the same platforms despite so far that we have only been able to reproduce the hang on certain ivb and hsw models. The last question is whether we want to always use the extra hammer or only when we know semaphores are in operation. At the moment, we only use LRI on non-RCS rings for semaphores, but that may change in the future with the possibility of reintroducing this bug under subtle conditions. v2: Make it explicit that the PSMI LRI are an extension to the original workaround for the other rings. v3: Bikeshedding variable names and whitespacing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Peter Frühberger <fritsch@xbmc.org> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Chris Wilson	3ea5944abe	drm/i915: Force the CS stall for invalidate flushes commit `add284a3a2` upstream. In order to act as a full command barrier by itself, we need to tell the pipecontrol to actually stall the command streamer while the flush runs. We require the full command barrier before operations like MI_SET_CONTEXT, which currently rely on a prior invalidate flush. References: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Chris Wilson	1c61a71131	drm/i915: Invalidate media caches on gen7 commit `148b83d081` upstream. In the gen7 pipe control there is an extra bit to flush the media caches, so let's set it during cache invalidation flushes. v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec. Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Ilia Mirkin	715f7c8214	drm/nv4c/mc: disable msi commit `4761703bd0` upstream. Several users have, over time, reported issues with MSI on these IGPs. They're old, rarely available, and MSI doesn't provide such huge advantages on them. Just disable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492 Fixes: `fa8c9ac72f` ("drm/nv4c/mc: nv4x igp's have a different msi rearm register") Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Jesse Barnes	6ba4636adc	drm/i915: save/restore GMBUS freq across suspend/resume on gen4 commit `9f49c37635` upstream. Should probably just init this in the GMbus code all the time, based on the cdclk and HPLL like we do on newer platforms. Ville has code for that in a rework branch, but until then we can fix this bug fairly easily. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Nikolay <mar.kolya@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Dave Airlie	ddf6f9a4c9	drm/i915: resume MST after reading back hw state commit `e7d6f7d708` upstream. Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit WARN_ON, because the state checker is inconsistent with the hw. This fixes a bunch of WARN_ON's on resume after undocking. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Chris Wilson	a5872ca0a6	drm/i915: Only warn the first time we attempt to mmio whilst suspended commit `2b38705981` upstream. In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit `b2ec142cb0` Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Daniel Vetter	06b7ae708b	drm/i915: Disallow pin ioctl completely for kms drivers commit `d472fcc837` upstream. The problem here is that SNA pins batchbuffers to etch out a bit more performance. Iirc it started out as a w/a for i830M (which we've implemented in the kernel since a long time already). The problem is that the pin ioctl wasn't added in commit `d23db88c3a` Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 23 08:48:08 2014 +0200 drm/i915: Prevent negative relocation deltas from wrapping Fix this by simply disallowing pinning from userspace so that the kernel is in full control of batch placement again. Especially since distros are moving towards running X as non-root, so most users won't even be able to see any benefits. UMS support is dead now, but we need this minimal patch for backporting. Follow-up patch will remove the pin ioctl code completely. Note to backporters: You must have both commit `b45305fce5` Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 which laned in 3.8 and commit `c4d69da167` Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 8 14:25:41 2014 +0100 drm/i915: Evict CS TLBs between batches which is also marked cc: stable. Otherwise this could introduce a regression by disabling the userspace w/a without the kernel w/a being fully functional on i830/45. References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Daniel Vetter	0976457353	drm/i915: Don't complain about stolen conflicts on gen3 commit `0b6d24c019` upstream. Apparently stuff works that way on those machines. I agree with Chris' concern that this is a bit risky but imo worth a shot in -next just for fun. Afaics all these machines have the pci resources allocated like that by the BIOS, so I suspect that it's all ok. This regression goes back to commit `eaba1b8f33` Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 4 12:28:35 2013 +0100 drm/i915: Verify that our stolen memory doesn't conflict Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031 Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Alex Deucher	e8e547f61c	drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw commit `410cce2a6b` upstream. The check was already in place in the dp mode_valid check, but radeon_dp_get_dp_link_clock() never returned the high clock mode_valid was checking for because that function clipped the clock based on the hw capabilities. Add an explicit check in the mode_valid function. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87172 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Alex Deucher	2710eb292c	drm/radeon: adjust default bapm settings for KV commit `02ae7af53a` upstream. Enabling bapm seems to cause clocking problems on some KV configurations. Disable it by default for now. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Alex Deucher	ca01c8f06a	drm/radeon: fix sad_count check for dce3 commit `5665c3ebe5` upstream. Make it consistent with the sad code for other asics to deal with monitors that don't report sads. bug: https://bugzilla.kernel.org/show_bug.cgi?id=89461 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:35 -08:00
Alex Deucher	310a18b4d5	drm/radeon: KV has three PPLLs (v2) commit `fbedf1c3fc` upstream. Enable all three in the driver. Early documentation indicated the 3rd one was used for something else, but that is not the case. v2: handle disable as well Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Alex Deucher	65c48e05c6	drm/radeon: check the right ring in radeon_evict_flags() commit `5e5c21cac1` upstream. Check the that ring we are using for copies is functional rather than the GFX ring. On newer asics we use the DMA ring for bo moves. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Alex Deucher	b29b3ee327	drm/radeon: work around a hw bug in MGCG on CIK commit `4bb62c95a7` upstream. Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE to avoid unreliable doorbell updates in some cases. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Alex Deucher	0d0521465b	drm/radeon: fix typo in CI dpm disable commit `129acb7c0b` upstream. Need to disable DS, not enable it when disabling dpm. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Daniel Vetter	c3c16208d8	drm/dp-mst: Remove branches before dropping the reference commit `0391359ddf` upstream. When we unplug a dp mst branch we unreference the entire tree from the root towards the leaves. Which is ok, since that's the way the pointers and so also the refcounts go. But when we drop the reference we must make sure that we remove the branches/ports from the lists/pointers before dropping the reference. Otherwise the get_validated functions will still return it instead of returning NULL (which indicates a potentially on-going unplug). The mst branch destroy gets this right for ports: First it deletes the port from the ports list, then it unrefs. But the ports destroy function gets it wrong: First it unrefs, then it drops the ref. Which means a zombie mst branch can still be validate with get_validated_mstb_ref when it shouldn't. Fix this. This should address a backtrace Dave dug out somewhere on unplug: [<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper] [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper] [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper] [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper] [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper] [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915] [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915] [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915] [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915] [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915] [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915] [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper] [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper] [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper] [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper] [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>] drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>] ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>] ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>] intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>] intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>] i915_digport_work_func+0x96/0x120 [i915] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Dave Airlie	1cc635aa16	drm/dp: retry AUX transactions 32 times (v1.1) commit `19a93f042f` upstream. At least on two MST devices I've tested with, when they are link training downstream, they are totally unable to handle aux ch msgs, so they defer like nuts. I tried 16, it wasn't enough, 32 seems better. This fixes one Dell 4k monitor and one of the MST hubs. v1.1: fixup comment (Tom). Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Dave Airlie	f5f6dd6dad	drm/fb_helper: move deferred fb checking into restore mode (v2) commit `e2809c7db8` upstream. On MST systems the monitors don't appear when we set the fb up, but plymouth opens the drm device and holds it open while they come up, when plymouth finishes and lastclose gets called we don't do the delayed fb probe, so the monitor never appears on the console. Fix this by moving the delayed checking into the mode restore. v2: Daniel suggested that ->delayed_hotplug is set under the mode_config mutex, so we should check it under that as well, while we are in the area. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Tetsuo Handa	330841392a	drm/ttm: Avoid memory allocation from shrinker functions. commit `881fdaa5e4` upstream. Andrew Morton wrote: > On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > Andrew Morton wrote: > > > Poor ttm guys - this is a bit of a trap we set for them. > > > > Commit `a91576d791` ("drm/ttm: Pass GFP flags in order to avoid deadlock.") > > changed to use sc->gfp_mask rather than GFP_KERNEL. > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page ), > > - GFP_KERNEL); > > + pages_to_free = kmalloc(npages_to_free sizeof(struct page ), gfp); > > > > But this bug is caused by sc->gfp_mask containing some flags which are not > > in GFP_KERNEL, right? Then, I think > > > > - pages_to_free = kmalloc(npages_to_free sizeof(struct page ), gfp); > > + pages_to_free = kmalloc(npages_to_free sizeof(struct page ), gfp & GFP_KERNEL); > > > > would hide this bug. > > > > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) > > Well no - ttm_page_pool_free() should stop calling kmalloc altogether. > Just do > > struct page pages_to_free[16]; > > and rework the code to free 16 pages at a time. Easy. Well, ttm code wants to process 512 pages at a time for performance. Memory footprint increased by 512 * sizeof(struct page *) buffer is only 4096 bytes. What about using static buffer like below? ---------- >From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Thu, 13 Nov 2014 22:21:54 +0900 Subject: drm/ttm: Avoid memory allocation from shrinker functions. Commit `a91576d791` ("drm/ttm: Pass GFP flags in order to avoid deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags which are not in GFP_KERNEL. https://bugzilla.kernel.org/show_bug.cgi?id=87891 Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would avoid the BUG_ON(), but avoiding memory allocation from shrinker function is better and reliable fix. Shrinker function is already serialized by global lock, and clean up function is called after shrinker function is unregistered. Thus, we can use static buffer when called from shrinker function and clean up function. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Thomas Hellstrom	a869935d81	drm/vmwgfx: Fix fence event code commit `89669e7a7f` upstream. The commit "vmwgfx: Rework fence event action" introduced a number of bugs that are fixed with this commit: a) A forgotten return stateemnt. b) An if statement with identical branches. Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Thomas Hellstrom	ad2b9bb40a	drm/vmwgfx: Fix error printout on signals pending commit `e338c4c2b6` upstream. The function vmw_master_check() might return -ERESTARTSYS if there is a signal pending, indicating that the IOCTL should be rerun, potentially from user-space. At that point we shouldn't print out an error message since that is not an error condition. In short, avoid bloating the kernel log when a process refuses to die on SIGTERM. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Thomas Hellstrom	28c54a2613	drm/vmwgfx: Don't use memory accounting for kernel-side fence objects commit `1f563a6a46` upstream. Kernel side fence objects are used when unbinding resources and may thus be created as part of a memory reclaim operation. This might trigger recursive memory reclaims and result in the kernel running out of stack space. So a simple way out is to avoid accounting of these fence objects. In principle this is OK since while user-space can trigger the creation of such objects, it can't really hold on to them. However, their lifetime is quite long, so some form of accounting should perhaps be implemented in the future. Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 with low system memory settings. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Govindarajulu Varadarajan	4c056b89e5	enic: fix rx skb checksum [ Upstream commit `17e96834fd` ] Hardware always provides compliment of IP pseudo checksum. Stack expects whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set. This causes checksum error in nf & ovs. kernel: qg-19546f09-f2: hw csum failure kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1 kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014 kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0 kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00 kernel: Call Trace: kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40 kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70 kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20 kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100 kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4] kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0 kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch] kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack] kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4] kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0 kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140 kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380 Hardware verifies IP & tcp/udp header checksum but does not provide payload checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet. Cc: Jiri Benc <jbenc@redhat.com> Cc: Stefan Assmann <sassmann@redhat.com> Reported-by: Sunil Choudhary <schoudha@redhat.com> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Reviewed-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Jiri Pirko	58f2f9c8bd	team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin [ Upstream commit `b0d11b4278` ] This patch is fixing a race condition that may cause setting count_pending to -1, which results in unwanted big bulk of arp messages (in case of "notify peers"). Consider following scenario: count_pending == 2 CPU0 CPU1 team_notify_peers_work atomic_dec_and_test (dec count_pending to 1) schedule_delayed_work team_notify_peers atomic_add (adding 1 to count_pending) team_notify_peers_work atomic_dec_and_test (dec count_pending to 1) schedule_delayed_work team_notify_peers_work atomic_dec_and_test (dec count_pending to 0) schedule_delayed_work team_notify_peers_work atomic_dec_and_test (dec count_pending to -1) Fix this race by using atomic_dec_if_positive - that will prevent count_pending running under 0. Fixes: `fc423ff00d` ("team: add peer notification") Fixes: `492b200efd` ("team: add support for sending multicast rejoins") Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Eric Dumazet	ff9df482e8	alx: fix alx_poll() [ Upstream commit `7a05dc64e2` ] Commit `d75b1ade56` ("net: less interrupt masking in NAPI") uncovered wrong alx_poll() behavior. A NAPI poll() handler is supposed to return exactly the budget when/if napi_complete() has not been called. It is also supposed to return number of frames that were received, so that netdev_budget can have a meaning. Also, in case of TX pressure, we still have to dequeue received packets : alx_clean_rx_irq() has to be called even if alx_clean_tx_irq(alx) returns false, otherwise device is half duplex. Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `d75b1ade56` ("net: less interrupt masking in NAPI") Reported-by: Oded Gabbay <oded.gabbay@amd.com> Bisected-by: Oded Gabbay <oded.gabbay@amd.com> Tested-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:34 -08:00
Palik, Imre	2aab953657	xen-netback: fixing the propagation of the transmit shaper timeout [ Upstream commit `07ff890dae` ] Since `e9ce7cb6b1` ("xen-netback: Factor queue-specific data into queue struct"), the transimt shaper timeout is always set to 0. The value the user sets via xenbus is never propagated to the transmit shaper. This patch fixes the issue. Cc: Anthony Liguori <aliguori@amazon.com> Signed-off-by: Imre Palik <imrep@amazon.de> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Herbert Xu	04e5427dbe	tcp: Do not apply TSO segment limit to non-TSO packets [ Upstream commit `843925f33f` ] Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs. In fact the problem was completely unrelated to IPsec. The bug is also reproducible if you just disable TSO/GSO. The problem is that when the MSS goes down, existing queued packet on the TX queue that have not been transmitted yet all look like TSO packets and get treated as such. This then triggers a bug where tcp_mss_split_point tells us to generate a zero-sized packet on the TX queue. Once that happens we're screwed because the zero-sized packet can never be removed by ACKs. Fixes: `1485348d24` ("tcp: Apply device TSO segment limit earlier") Reported-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cheers, Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Maor Gottlieb	f3721ea3af	net/mlx4_core: Correcly update the mtt's offset in the MR re-reg flow [ Upstream commit `a51e0df4c1` ] Previously, mlx4_mt_rereg_write filled the MPT's entity_size with the old MTT's page shift, which could result in using an incorrect offset. Fix the initialization to be after we calculate the new MTT offset. In addition, assign mtt order to -1 after calling mlx4_mtt_cleanup. This is necessary in order to mark the MTT as invalid and avoid freeing it later. Fixes: `e630664` ('mlx4_core: Add helper functions to support MR re-registration') Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Jesse Gross	12d5e0bb53	net: Generalize ndo_gso_check to ndo_features_check [ Upstream commit `5f35227ea3` ] GSO isn't the only offload feature with restrictions that potentially can't be expressed with the current features mechanism. Checksum is another although it's a general issue that could in theory apply to anything. Even if it may be possible to implement these restrictions in other ways, it can result in duplicate code or inefficient per-packet behavior. This generalizes ndo_gso_check so that drivers can remove any features that don't make sense for a given packet, similar to netif_skb_features(). It also converts existing driver restrictions to the new format, completing the work that was done to support tunnel protocols since the issues apply to checksums as well. By actually removing features from the set that are used to do offloading, it solves another problem with the existing interface. In these cases, GSO would run with the original set of features and not do anything because it appears that segmentation is not required. CC: Tom Herbert <therbert@google.com> CC: Joe Stringer <joestringer@nicira.com> CC: Eric Dumazet <edumazet@google.com> CC: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Tom Herbert <therbert@google.com> Fixes: `04ffcb255f` ("net: Add ndo_gso_check") Tested-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Jay Vosburgh	3890e4287e	net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding [ Upstream commit `2c26d34bbc` ] When using VXLAN tunnels and a sky2 device, I have experienced checksum failures of the following type: [ 4297.761899] eth0: hw csum failure [...] [ 4297.765223] Call Trace: [ 4297.765224] <IRQ> [<ffffffff8172f026>] dump_stack+0x46/0x58 [ 4297.765235] [<ffffffff8162ba52>] netdev_rx_csum_fault+0x42/0x50 [ 4297.765238] [<ffffffff8161c1a0>] ? skb_push+0x40/0x40 [ 4297.765240] [<ffffffff8162325c>] __skb_checksum_complete+0xbc/0xd0 [ 4297.765243] [<ffffffff8168c602>] tcp_v4_rcv+0x2e2/0x950 [ 4297.765246] [<ffffffff81666ca0>] ? ip_rcv_finish+0x360/0x360 These are reliably reproduced in a network topology of: container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -> switch When VXLAN encapsulated traffic is received from a similarly configured peer, the above warning is generated in the receive processing of the encapsulated packet. Note that the warning is associated with the container eth0. The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and because the packet is an encapsulated Ethernet frame, the checksum generated by the hardware includes the inner protocol and Ethernet headers. The receive code is careful to update the skb->csum, except in __dev_forward_skb, as called by dev_forward_skb. __dev_forward_skb calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN) to skip over the Ethernet header, but does not update skb->csum when doing so. This patch resolves the problem by adding a call to skb_postpull_rcsum to update the skb->csum after the call to eth_type_trans. Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Thomas Graf	253ab52478	net: Reset secmark when scrubbing packet [ Upstream commit `b8fb4e0648` ] skb_scrub_packet() is called when a packet switches between a context such as between underlay and overlay, between namespaces, or between L3 subnets. While we already scrub the packet mark, connection tracking entry, and cached destination, the security mark/context is left intact. It seems wrong to inherit the security context of a packet when going from overlay to underlay or across forwarding paths. Signed-off-by: Thomas Graf <tgraf@suug.ch> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Toshiaki Makita	2986248256	net: Fix stacked vlan offload features computation [ Upstream commit `796f2da81b` ] When vlan tags are stacked, it is very likely that the outer tag is stored in skb->vlan_tci and skb->protocol shows the inner tag's vlan_proto. Currently netif_skb_features() first looks at skb->protocol even if there is the outer tag in vlan_tci, thus it incorrectly retrieves the protocol encapsulated by the inner vlan instead of the inner vlan protocol. This allows GSO packets to be passed to HW and they end up being corrupted. Fixes: `58e998c6d2` ("offloading: Force software GSO for multiple vlan tags.") Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Nicolas Dichtel	060e2832a5	tcp6: don't move IP6CB before xfrm6_policy_check() [ Upstream commit `2dc49d1680` ] When xfrm6_policy_check() is used, _decode_session6() is called after some intermediate functions. This function uses IP6CB(), thus TCP_SKB_CB() must be prepared after the call of xfrm6_policy_check(). Before this patch, scenarii with IPv6 + TCP + IPsec Transport are broken. Fixes: `971f10eca1` ("tcp: better TCP_SKB_CB layout to reduce cache line misses") Reported-by: Huaibin Wang <huaibin.wang@6wind.com> Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Amir Vadai	bfd6ab619c	net/mlx4_en: Doorbell is byteswapped in Little Endian archs [ Upstream commit `492f5add4b` ] iowrite32() will byteswap it's argument on big endian archs. iowrite32be() will byteswap on little endian archs. Since we don't want to do this unnecessary byteswap on the fast path, doorbell is stored in the NIC's native endianness. Using the right iowrite() according to the arch endianness. CC: Wei Yang <weiyang@linux.vnet.ibm.com> CC: David Laight <david.laight@aculab.com> Fixes: `6a4e812` ("net/mlx4_en: Avoid calling bswap in tx fast path") Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Antonio Quartulli	a67fa81c87	batman-adv: avoid NULL dereferences and fix if check [ Upstream commit `0d16449195` ] Gateway having bandwidth_down equal to zero are not accepted at all and so never added to the Gateway list. For this reason checking the bandwidth_down member in batadv_gw_out_of_range() is useless. This is probably a copy/paste error and this check was supposed to be "!gw_node" only. Moreover, the way the check is written now may also lead to a NULL dereference. Fix this by rewriting the if-condition properly. Introduced by `414254e342` ("batman-adv: tvlv - gateway download/upload bandwidth container") Signed-off-by: Antonio Quartulli <antonio@meshcoding.com> Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Sven Eckelmann	4a4867f657	batman-adv: Unify fragment size calculation [ Upstream commit `0402e444cd` ] The fragmentation code was replaced in `610bfc6bc9` ("batman-adv: Receive fragmented packets and merge") by an implementation which can handle up to 16 fragments of a packet. The packet is prepared for the split in fragments by the function batadv_frag_send_packet and the actual split is done by batadv_frag_create. Both functions calculate the size of a fragment themself. But their calculation differs because batadv_frag_send_packet also subtracts ETH_HLEN. Therefore, the check in batadv_frag_send_packet "can a full fragment can be created?" may return true even when batadv_frag_create cannot create a full fragment. The function batadv_frag_create doesn't check the size of the skb before splitting it and therefore might try to create a larger fragment than the remaining buffer. This creates an integer underflow and an invalid len is given to skb_split. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Sven Eckelmann	53fd27c1a2	batman-adv: Calculate extra tail size based on queued fragments [ Upstream commit `5b6698b0e4` ] The fragmentation code was replaced in `610bfc6bc9` ("batman-adv: Receive fragmented packets and merge"). The new code provided a mostly unused parameter skb for the merging function. It is used inside the function to calculate the additionally needed skb tailroom. But instead of increasing its own tailroom, it is only increasing the tailroom of the first queued skb. This is not correct in some situations because the first queued entry can be a different one than the parameter. An observed problem was: 1. packet with size 104, total_size 1464, fragno 1 was received - packet is queued 2. packet with size 1400, total_size 1464, fragno 0 was received - packet is queued at the end of the list 3. enough data was received and can be given to the merge function (1464 == (1400 - 20) + (104 - 20)) - merge functions gets 1400 byte large packet as skb argument 4. merge function gets first entry in queue (104 byte) - stored as skb_out 5. merge function calculates the required extra tail as total_size - skb->len - pskb_expand_head tail of skb_out with 64 bytes 6. merge function tries to squeeze the extra 1380 bytes from the second queued skb (1400 byte aka skb parameter) in the 64 extra tail bytes of skb_out Instead calculate the extra required tail bytes for skb_out also using skb_out instead of using the parameter skb. The skb parameter is only used to get the total_size from the last received packet. This is also the total_size used to decide that all fragments were received. Reported-by: Philipp Psurek <philipp.psurek@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Acked-by: Martin Hundebøll <martin@hundeboll.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Prashant Sreedharan	ea1e9a30ca	tg3: tg3_disable_ints using uninitialized mailbox value to disable interrupts [ Upstream commit `05b0aa5793` ] During driver load in tg3_init_one, if the driver detects DMA activity before intializing the chip tg3_halt is called. As part of tg3_halt interrupts are disabled using routine tg3_disable_ints. This routine was using mailbox value which was not initialized (default value is 0). As a result driver was writing 0x00000001 to pci config space register 0, which is the vendor id / device id. This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only the Vendor ID to identify Configuration Request Retry). Also this issue is only seen in older generation chipsets like 5722 because config space write to offset 0 from driver is possible. The newer generation chips ignore writes to offset 0. Also without commit a7877b17a667, for these older chips when a GRC reset is issued the Bootcode would reprogram the vendor id/device id, which is the reason this bug was masked earlier. Fixed by initializing the interrupt mailbox registers before calling tg3_halt. Please queue for -stable. Reported-by: Nils Holland <nholland@tisys.org> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
stephen hemminger	b7efdb64ac	in6: fix conflict with glibc [ Upstream commit `6d08acd2d3` ] Resolve conflicts between glibc definition of IPV6 socket options and those defined in Linux headers. Looks like earlier efforts to solve this did not cover all the definitions. It resolves warnings during iproute2 build. Please consider for stable as well. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:33 -08:00
Jason Wang	3614d566f7	net: drop the packet when fails to do software segmentation or header check [ Upstream commit `af6dabc9c7` ] Commit `cecda693a9` ("net: keep original skb which only needs header checking during software GSO") keeps the original skb for packets that only needs header check, but it doesn't drop the packet if software segmentation or header check were failed. Fixes `cecda693a9` ("net: keep original skb which only needs header checking during software GSO") Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
David Vrabel	639e13dad7	xen-netback: support frontends without feature-rx-notify again [ Upstram commit `26c0e10258` ] Commit `bc96f648df` (xen-netback: make feature-rx-notify mandatory) incorrectly assumed that there were no frontends in use that did not support this feature. But the frontend driver in MiniOS does not and since this is used by (qemu) stubdoms, these stopped working. Netback sort of works as-is in this mode except: - If there are no Rx requests and the internal Rx queue fills, only the drain timeout will wake the thread. The default drain timeout of 10 s would give unacceptable pauses. - If an Rx stall was detected and the internal Rx queue is drained, then the Rx thread would never wake. Handle these two cases (when feature-rx-notify is disabled) by: - Reducing the drain timeout to 30 ms. - Disabling Rx stall detection. Reported-by: John <jw@nuclearfallout.net> Tested-by: John <jw@nuclearfallout.net> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Jesse Gross	bce2a13e79	geneve: Fix races between socket add and release. [ Upstream commit `12069401d8` ] Currently, searching for a socket to add a reference to is not synchronized with deletion of sockets. This can result in use after free if there is another operation that is removing a socket at the same time. Solving this requires both holding the appropriate lock and checking the refcount to ensure that it has not already hit zero. Inspired by a related (but not exactly the same) issue in the VXLAN driver. Fixes: `0b5e8b8e` ("net: Add Geneve tunneling protocol driver") CC: Andy Zhou <azhou@nicira.com> Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Jesse Gross	4378fe7d79	geneve: Remove socket and offload handlers at destruction. [ Upstream commit `7ed767f731` ] Sockets aren't currently removed from the the global list when they are destroyed. In addition, offload handlers need to be cleaned up as well. Fixes: `0b5e8b8e` ("net: Add Geneve tunneling protocol driver") CC: Andy Zhou <azhou@nicira.com> Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Thomas Graf	3c030f1946	netlink: Don't reorder loads/stores before marking mmap netlink frame as available [ Upstream commit `a18e6a186f` ] Each mmap Netlink frame contains a status field which indicates whether the frame is unused, reserved, contains data or needs to be skipped. Both loads and stores may not be reordeded and must complete before the status field is changed and another CPU might pick up the frame for use. Use an smp_mb() to cover needs of both types of callers to netlink_set_status(), callers which have been reading data frame from the frame, and callers which have been filling or releasing and thus writing to the frame. - Example code path requiring a smp_rmb(): memcpy(skb->data, (void *)hdr + NL_MMAP_HDRLEN, hdr->nm_len); netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED); - Example code path requiring a smp_wmb(): hdr->nm_uid = from_kuid(sk_user_ns(sk), NETLINK_CB(skb).creds.uid); hdr->nm_gid = from_kgid(sk_user_ns(sk), NETLINK_CB(skb).creds.gid); netlink_frame_flush_dcache(hdr); netlink_set_status(hdr, NL_MMAP_STATUS_VALID); Fixes: f9c228 ("netlink: implement memory mapped recvmsg()") Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
David Miller	b68d3ab6b3	netlink: Always copy on mmap TX. [ Upstream commit `4682a03586` ] Checking the file f_count and the nlk->mapped count is not completely sufficient to prevent the mmap'd area contents from changing from under us during netlink mmap sendmsg() operations. Be careful to sample the header's length field only once, because this could change from under us as well. Fixes: `5fd96123ee` ("netlink: implement memory mapped sendmsg()") Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Ido Shamay	15c11606c9	net/mlx4: Cache line CQE/EQE stride fixes [ Upstream commit `c3f2511fea` ] This commit contains 2 fixes for the 128B CQE/EQE stride feaure. Wei found that mlx4_QUERY_HCA function marked the wrong capability in flags (64B CQE/EQE), when CQE/EQE stride feature was enabled. Also added small fix in initial CQE ownership bit assignment, when CQE is size is not default 32B. Fixes: `77507aa24` (net/mlx4: Enable CQE/EQE stride support) Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Timo Teräs	feb15ac362	gre: fix the inner mac header in nbma tunnel xmit path [ Upstream commit `8a0033a947` ] The NBMA GRE tunnels temporarily push GRE header that contain the per-packet NBMA destination on the skb via header ops early in xmit path. It is the later pulled before the real GRE header is constructed. The inner mac was thus set differently in nbma case: the GRE header has been pushed by neighbor layer, and mac header points to beginning of the temporary gre header (set by dev_queue_xmit). Now that the offloads expect mac header to point to the gre payload, fix the xmit patch to: - pull first the temporary gre header away - and reset mac header to point to gre payload This fixes tso to work again with nbma tunnels. Fixes: `14051f0452` ("gre: Use inner mac length when computing tunnel length") Signed-off-by: Timo Teräs <timo.teras@iki.fi> Cc: Tom Herbert <therbert@google.com> Cc: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-27 08:29:32 -08:00
Greg Kroah-Hartman	219b188d28	Linux 3.18.3	2015-01-16 07:04:08 -08:00
Linus Torvalds	f2f5d44bb4	mm: Don't count the stack guard page towards RLIMIT_STACK commit `690eac53da` upstream. Commit `fee7e49d45` ("mm: propagate error from stack expansion even for guard page") made sure that we return the error properly for stack growth conditions. It also theorized that counting the guard page towards the stack limit might break something, but also said "Let's see if anybody notices". Somebody did notice. Apparently android-x86 sets the stack limit very close to the limit indeed, and including the guard page in the rlimit check causes the android 'zygote' process problems. So this adds the (fairly trivial) code to make the stack rlimit check be against the actual real stack size, rather than the size of the vma that includes the guard page. Reported-and-tested-by: Chih-Wei Huang <cwhuang@android-x86.org> Cc: Jay Foad <jay.foad@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:57 -08:00
Linus Torvalds	c03aed64c4	mm: propagate error from stack expansion even for guard page commit `fee7e49d45` upstream. Jay Foad reports that the address sanitizer test (asan) sometimes gets confused by a stack pointer that ends up being outside the stack vma that is reported by /proc/maps. This happens due to an interaction between RLIMIT_STACK and the guard page: when we do the guard page check, we ignore the potential error from the stack expansion, which effectively results in a missing guard page, since the expected stack expansion won't have been done. And since /proc/maps explicitly ignores the guard page (commit `d7824370e2`: "mm: fix up some user-visible effects of the stack guard page"), the stack pointer ends up being outside the reported stack area. This is the minimal patch: it just propagates the error. It also effectively makes the guard page part of the stack limit, which in turn measn that the actual real stack is one page less than the stack limit. Let's see if anybody notices. We could teach acct_stack_growth() to allow an extra page for a grow-up/grow-down stack in the rlimit test, but I don't want to add more complexity if it isn't needed. Reported-and-tested-by: Jay Foad <jay.foad@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:57 -08:00
Vlastimil Babka	53bcf5c328	mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed commit `9e5e366172` upstream. Charles Shirron and Paul Cassella from Cray Inc have reported kswapd stuck in a busy loop with nothing left to balance, but kswapd_try_to_sleep() failing to sleep. Their analysis found the cause to be a combination of several factors: 1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait 2. The process has been killed (by OOM in this case), but has not yet been scheduled to remove itself from the waitqueue and die. 3. kswapd checks for throttled processes in prepare_kswapd_sleep(): if (waitqueue_active(&pgdat->pfmemalloc_wait)) { wake_up(&pgdat->pfmemalloc_wait); return false; // kswapd will not go to sleep } However, for a process that was already killed, wake_up() does not remove the process from the waitqueue, since try_to_wake_up() checks its state first and returns false when the process is no longer waiting. 4. kswapd is running on the same CPU as the only CPU that the process is allowed to run on (through cpus_allowed, or possibly single-cpu system). 5. CONFIG_PREEMPT_NONE=y kernel is used. If there's nothing to balance, kswapd encounters no voluntary preemption points and repeatedly fails prepare_kswapd_sleep(), blocking the process from running and removing itself from the waitqueue, which would let kswapd sleep. So, the source of the problem is that we prevent kswapd from going to sleep until there are processes waiting on the pfmemalloc_wait queue, and a process waiting on a queue is guaranteed to be removed from the queue only when it gets scheduled. This was done to make sure that no process is left sleeping on pfmemalloc_wait when kswapd itself goes to sleep. However, it isn't necessary to postpone kswapd sleep until the pfmemalloc_wait queue actually empties. To prevent processes from being left sleeping, it's actually enough to guarantee that all processes waiting on pfmemalloc_wait queue have been woken up by the time we put kswapd to sleep. This patch therefore fixes this issue by substituting 'wake_up' with 'wake_up_all' and removing 'return false' in the code snippet from prepare_kswapd_sleep() above. Note that if any process puts itself in the queue after this waitqueue_active() check, or after the wake up itself, it means that the process will also wake up kswapd - and since we are under prepare_to_wait(), the wake up won't be missed. Also we update the comment prepare_kswapd_sleep() to hopefully more clearly describe the races it is preventing. Fixes: `5515061d22` ("mm: throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:57 -08:00
Johannes Weiner	a78e877e9a	mm: protect set_page_dirty() from ongoing truncation commit `2d6d7f9828` upstream. Tejun, while reviewing the code, spotted the following race condition between the dirtying and truncation of a page: __set_page_dirty_nobuffers() __delete_from_page_cache() if (TestSetPageDirty(page)) page->mapping = NULL if (PageDirty()) dec_zone_page_state(page, NR_FILE_DIRTY); dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); if (page->mapping) account_page_dirtied(page) __inc_zone_page_state(page, NR_FILE_DIRTY); __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE. Dirtiers usually lock out truncation, either by holding the page lock directly, or in case of zap_pte_range(), by pinning the mapcount with the page table lock held. The notable exception to this rule, though, is do_wp_page(), for which this race exists. However, do_wp_page() already waits for a locked page to unlock before setting the dirty bit, in order to prevent a race where clear_page_dirty() misses the page bit in the presence of dirty ptes. Upgrade that wait to a fully locked set_page_dirty() to also cover the situation explained above. Afterwards, the code in set_page_dirty() dealing with a truncation race is no longer needed. Remove it. Reported-by: Tejun Heo <tj@kernel.org> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:57 -08:00
Oleg Nesterov	d73437ade6	exit: fix race between wait_consider_task() and wait_task_zombie() commit `3245d6acab` upstream. wait_consider_task() checks EXIT_ZOMBIE after EXIT_DEAD/EXIT_TRACE and both checks can fail if we race with EXIT_ZOMBIE -> EXIT_DEAD/EXIT_TRACE change in between, gcc needs to reload p->exit_state after security_task_wait(). In this case ->notask_error will be wrongly cleared and do_wait() can hang forever if it was the last eligible child. Many thanks to Arne who carefully investigated the problem. Note: this bug is very old but it was pure theoretical until commit `b3ab03160d` ("wait: completely ignore the EXIT_DEAD tasks"). Before this commit "-O2" was probably enough to guarantee that compiler won't read ->exit_state twice. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Arne Goedeke <el@laramies.com> Tested-by: Arne Goedeke <el@laramies.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:57 -08:00
Krzysztof Kozlowski	0324896e2e	mmc: sdhci: Fix sleep in atomic after inserting SD card commit `2836766a9d` upstream. Sleep in atomic context happened on Trats2 board after inserting or removing SD card because mmc_gpio_get_cd() was called under spin lock. Fix this by moving card detection earlier, before acquiring spin lock. The mmc_gpio_get_cd() call does not have to be protected by spin lock because it does not access any sdhci internal data. The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After moving it out side of spin lock it could theoretically race with driver removal but still there is no actual protection against manual card eject. Dmesg after inserting SD card: [ 41.663414] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1511 [ 41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1 [ 41.677580] INFO: lockdep is turned off. [ 41.681486] irq event stamp: 61972 [ 41.684872] hardirqs last enabled at (61971): [<c0490ee0>] _raw_spin_unlock_irq+0x24/0x5c [ 41.693118] hardirqs last disabled at (61972): [<c04907ac>] _raw_spin_lock_irq+0x18/0x54 [ 41.701190] softirqs last enabled at (61648): [<c0026fd4>] __do_softirq+0x234/0x2c8 [ 41.708914] softirqs last disabled at (61631): [<c00273a0>] irq_exit+0xd0/0x114 [ 41.716206] Preemption disabled at:[< (null)>] (null) [ 41.721500] [ 41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: G W 3.18.0-rc5-next-20141121 #883 [ 41.732111] Workqueue: kmmcd mmc_rescan [ 41.735945] [<c0014d2c>] (unwind_backtrace) from [<c0011c80>] (show_stack+0x10/0x14) [ 41.743661] [<c0011c80>] (show_stack) from [<c0489d14>] (dump_stack+0x70/0xbc) [ 41.750867] [<c0489d14>] (dump_stack) from [<c0228b74>] (gpiod_get_raw_value_cansleep+0x18/0x30) [ 41.759628] [<c0228b74>] (gpiod_get_raw_value_cansleep) from [<c03646e8>] (mmc_gpio_get_cd+0x38/0x58) [ 41.768821] [<c03646e8>] (mmc_gpio_get_cd) from [<c036d378>] (sdhci_request+0x50/0x1a4) [ 41.776808] [<c036d378>] (sdhci_request) from [<c0357934>] (mmc_start_request+0x138/0x268) [ 41.785051] [<c0357934>] (mmc_start_request) from [<c0357cc8>] (mmc_wait_for_req+0x58/0x1a0) [ 41.793469] [<c0357cc8>] (mmc_wait_for_req) from [<c0357e68>] (mmc_wait_for_cmd+0x58/0x78) [ 41.801714] [<c0357e68>] (mmc_wait_for_cmd) from [<c0361c00>] (mmc_io_rw_direct_host+0x98/0x124) [ 41.810480] [<c0361c00>] (mmc_io_rw_direct_host) from [<c03620f8>] (sdio_reset+0x2c/0x64) [ 41.818641] [<c03620f8>] (sdio_reset) from [<c035a3d8>] (mmc_rescan+0x254/0x2e4) [ 41.826028] [<c035a3d8>] (mmc_rescan) from [<c003a0e0>] (process_one_work+0x180/0x3f4) [ 41.833920] [<c003a0e0>] (process_one_work) from [<c003a3bc>] (worker_thread+0x34/0x4b0) [ 41.841991] [<c003a3bc>] (worker_thread) from [<c003fed8>] (kthread+0xe4/0x104) [ 41.849285] [<c003fed8>] (kthread) from [<c000f268>] (ret_from_fork+0x14/0x2c) [ 42.038276] mmc0: new high speed SDHC card at address 1234 Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: `94144a465d` ("mmc: sdhci: add get_cd() implementation") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Krzysztof Kozlowski	9abaccf3bf	regulator: s2mps11: Fix dw_mmc failure on Gear 2 commit `1222d8fe57` upstream. Invalid buck4 configuration for linear mapping of voltage in S2MPS14 regulators caused boot failure on Gear 2 (dw_mmc-exynos): [ 3.569137] EXT4-fs (mmcblk0p15): mounted filesystem with ordered data mode. Opts: (null) [ 3.571716] VFS: Mounted root (ext4 filesystem) readonly on device 179:15. [ 3.629842] mmcblk0: error -110 sending status command, retrying [ 3.630244] mmcblk0: error -110 sending status command, retrying [ 3.636292] mmcblk0: error -110 sending status command, aborting Buck4 voltage regulator has different minimal voltage value than other bucks. Commit merging multiple regulator description macros caused to use linear_min_sel from buck[1235] regulators as value for buck4. This lead to lower voltage of buck4 than required. Output of the buck4 is used internally as power source for LDO{3,4,7,11,19,20,21,23}. On Gear 2 board LDO11 is used as MMC regulator (V_EMMC_1.8V). Fixes: `5a867cf288` ("regulator: s2mps11: Optimize the regulator description macro") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Dave Airlie	cc01e9c0c8	nouveau: bring back legacy mmap handler commit `2036eaa740` upstream. nouveau userspace back at 1.0.1 used to call the X server DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts to map the sarea and fails if it can't. Since `884c6dabb0` from Daniel, this fails, but only ancient drivers would see it. Revert the nouveau bits of that fix. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Bruno Prémont	f4589f7bdc	drm/nouveau/nouveau: Do not BUG_ON(!spin_is_locked()) on UP commit `ff4c0d5213` upstream. On !SMP systems spinlocks do not exist. Thus checking of they are active will always fail. Use assert_spin_locked(lock); instead of BUG_ON(!spin_is_locked(lock)); to not BUG() on all UP systems. Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Hisashi Nakamura	f34d67febf	spi: sh-msiof: Add runtime PM lock in initializing commit `015760563e` upstream. SH-MSIOF driver is enabled autosuspend API of spi framework. But autosuspend framework doesn't work during initializing. So runtime PM lock is added in SH-MSIOF driver initializing. Fixes: `e2a0ba547b` (spi: sh-msiof: Convert to spi core auto_runtime_pm framework) Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Jiri Olsa	e8ff14951e	perf session: Do not fail on processing out of order event commit `f61ff6c06d` upstream. Linus reported perf report command being interrupted due to processing of 'out of order' event, with following error: Timestamp below last timeslice flush 0x5733a8 [0x28]: failed to process type: 3 I could reproduce the issue and in my case it was caused by one CPU (mmap) being behind during record and userspace mmap reader seeing the data after other CPUs data were already stored. This is expected under some circumstances because we need to limit the number of events that we queue for reordering when we receive a PERF_RECORD_FINISHED_ROUND or when we force flush due to memory pressure. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1417016371-30249-1-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Zhiqiang Zhang <zhangzhiqiang.zhang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Andi Kleen	7f5dada0d5	perf/x86/uncore/hsw-ep: Handle systems with only two SBOXes commit `5306c31c57` upstream. There was another report of a boot failure with a #GP fault in the uncore SBOX initialization. The earlier work around was not enough for this system. The boot was failing while trying to initialize the third SBOX. This patch detects parts with only two SBOXes and limits the number of SBOX units to two there. Stable material, as it affects boot problems on 3.18. Tested-by: Andreas Oehler <andreas@oehler-net.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1420583675-9163-1-git-send-email-andi@firstfloor.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Jiri Olsa	78a458e361	perf: Fix events installation during moving group commit `9fc81d8742` upstream. We allow PMU driver to change the cpu on which the event should be installed to. This happened in patch: `e2d37cd213` ("perf: Allow the PMU driver to choose the CPU on which to install events") This patch also forces all the group members to follow the currently opened events cpu if the group happened to be moved. This and the change of event->cpu in perf_install_in_context() function introduced in: `0cda4c0231` ("perf: Introduce perf_pmu_migrate_context()") forces group members to change their event->cpu, if the currently-opened-event's PMU changed the cpu and there is a group move. Above behaviour causes problem for breakpoint events, which uses event->cpu to touch cpu specific data for breakpoints accounting. By changing event->cpu, some breakpoints slots were wrongly accounted for given cpu. Vinces's perf fuzzer hit this issue and caused following WARN on my setup: WARNING: CPU: 0 PID: 20214 at arch/x86/kernel/hw_breakpoint.c:119 arch_install_hw_breakpoint+0x142/0x150() Can't find any breakpoint slot [...] This patch changes the group moving code to keep the event's original cpu. Reported-by: Vince Weaver <vince@deater.net> Signed-off-by: Jiri Olsa <jolsa@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vince@deater.net> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jolsa@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Jiri Olsa	8fa60ccc1c	perf/x86/intel/uncore: Make sure only uncore events are collected commit `af91568e76` upstream. The uncore_collect_events functions assumes that event group might contain only uncore events which is wrong, because it might contain any type of events. This bug leads to uncore framework touching 'not' uncore events, which could end up all sorts of bugs. One was triggered by Vince's perf fuzzer, when the uncore code touched breakpoint event private event space as if it was uncore event and caused BUG: BUG: unable to handle kernel paging request at ffffffff82822068 IP: [<ffffffff81020338>] uncore_assign_events+0x188/0x250 ... The code in uncore_assign_events() function was looking for event->hw.idx data while the event was initialized as a breakpoint with different members in event->hw union. This patch forces uncore_collect_events() to collect only uncore events. Reported-by: Vince Weaver <vince@deater.net> Signed-off-by: Jiri Olsa <jolsa@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jolsa@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Johannes Berg	a4a59e5833	Revert "mac80211: Fix accounting of the tailroom-needed counter" commit `1e359a5de8` upstream. This reverts commit `ca34e3b5c8`. It turns out that the p54 and cw2100 drivers assume that there's tailroom even when they don't say they really need it. However, there's currently no way for them to explicitly say they do need it, so for now revert this. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331. Fixes: `ca34e3b5c8` ("mac80211: Fix accounting of the tailroom-needed counter") Reported-by: Christopher Chavez <chrischavez@gmx.us> Bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Debugged-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Chris Mason	30e4fb85e8	Btrfs: don't delay inode ref updates during log replay commit `6f8960541b` upstream. Commit `1d52c78afb` (Btrfs: try not to ENOSPC on log replay) added a check to skip delayed inode updates during log replay because it confuses the enospc code. But the delayed processing will end up ignoring delayed refs from log replay because the inode itself wasn't put through the delayed code. This can end up triggering a warning at commit time: WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty+0x32/0x34() Which is repeated for each commit because we never process the delayed inode ref update. The fix used here is to change btrfs_delayed_delete_inode_ref to return an error if we're currently in log replay. The caller will do the ref deletion immediately and everything will work properly. Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Mathias Krause	087e791172	crypto: aesni - fix "by8" variant for 128 bit keys commit `0b1e95b2fa` upstream. The "by8" counter mode optimization is broken for 128 bit keys with input data longer than 128 bytes. It uses the wrong key material for en- and decryption. The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved in case we're handling more than 128 bytes of input data -- they won't get reloaded after the initial load. They must therefore be (a) loaded on the first iteration and (b) be preserved for the latter ones. The implementation for 128 bit keys does not comply with (a) nor (b). Fix this by bringing the implementation back to its original source and correctly load the key registers and preserve their values by not re-using the registers for other purposes. Kudos to James for reporting the issue and providing a test case showing the discrepancies. Reported-by: James Yonan <james@openvpn.net> Cc: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:56 -08:00
Vinson Lee	553aeac6c8	crypto: sha-mb - Add avx2_supported check. commit `0b8c960cf6` upstream. This patch fixes this allyesconfig target build error with older binutils. LD arch/x86/crypto/built-in.o ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory Signed-off-by: Vinson Lee <vlee@twitter.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Ard Biesheuvel	1a7227fe00	arm64/efi: add missing call to early_ioremap_reset() commit `0e63ea48b4` upstream. The early ioremap support introduced by patch `bf4b558eba` ("arm64: add early_ioremap support") failed to add a call to early_ioremap_reset() at an appropriate time. Without this call, invocations of early_ioremap etc. that are done too late will go unnoticed and may cause corruption. This is exactly what happened when the first user of this feature was added in patch `f84d02755f` ("arm64: add EFI runtime services"). The early mapping of the EFI memory map is unmapped during an early initcall, at which time the early ioremap support is long gone. Fix by adding the missing call to early_ioremap_reset() to setup_arch(), and move the offending early_memunmap() to right after the point where the early mapping of the EFI memory map is last used. Fixes: `f84d02755f` ("arm64: add EFI runtime services") Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Lorenzo Pieralisi	058ec24e2b	arm64: kernel: fix __cpu_suspend mm switch on warm-boot commit `f43c27188a` upstream. On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0 page tables on boot or to the active_mm mappings belonging to user space processes, it must never be set to swapper_pg_dir page tables mappings. When a CPU is booted its active_mm is set to init_mm even though its TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies that when __cpu_suspend is triggered the active_mm can point at init_mm even if the current TTBR0_EL1 register contains the reserved TTBR0_EL1 mappings. Therefore, the mm save and restore executed in __cpu_suspend might turn out to be erroneous in that, if the current->active_mm corresponds to init_mm, on resume from low power it ends up restoring in the TTBR0_EL1 the init_mm mappings that are global and can cause speculation of TLB entries which end up being propagated to user space. This patch fixes the issue by checking the active_mm pointer before restoring the TTBR0 mappings. If the current active_mm == &init_mm, the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of switching back to the active_mm, which is the expected behaviour corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered. Fixes: `95322526ef` ("arm64: kernel: cpu_{suspend/resume} implementation") Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Laura Abbott	734e756364	arm64: Move cpu_resume into the text section commit `c3684fbb44` upstream. The function cpu_resume currently lives in the .data section. There's no reason for it to be there since we can use relative instructions without a problem. Move a few cpu_resume data structures out of the assembly file so the .data annotation can be dropped completely and cpu_resume ends up in the read only text section. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Hans de Goede	b0bb76920d	Input: alps - v7: fix finger counting for > 2 fingers on clickpads commit `d27eb7931c` upstream. Protocol v7 uses the middle / right button bits on clickpads to communicate "location" information of a 3th touch (and possible 4th) touch on clickpads. Specifically when 3 touches are down, if one of the 3 touches is in the left / right button area, this will get reported in the middle / right button bits and the touchpad will still send a TWO type packet rather then a MULTI type packet, so when this happens we must add the finger reported in the button area to the finger count. Likewise we must also add fingers reported this way to the finger count when we get MULTI packets. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Hans de Goede	7b35ab6f00	Input: alps - v7: sometimes a single touch is reported in mt[1] commit `7091c443dd` upstream. The v7 proto differentiates between a primary touch (with high precision) and a secondary touch (with lower precision). Normally when 2 fingers are down and one is lifted the still present touch becomes the primary touch, but some traces have shown that this does not happen always. This commit deals with this by making alps_get_mt_count() not stop at the first empty mt slot, and if a touch is present in mt[1] and not mt[0] moving the data to mt[0] (for input_mt_assign_slots). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Hans de Goede	98eb06b6ca	Input: alps - v7: ignore new packets commit `8b23811535` upstream. NEW packets are send to indicate a discontinuity in the finger coordinate reporting. Specifically a finger may have moved from slot 0 to 1 or vice versa. INPUT_MT_TRACK takes care of this for us. NEW packets have 3 problems: 1) They do not contain middle / right button info (on non clickpads) this can be worked around by preserving the old button state 2) They do not contain an accurate fingercount, and they are typically send when the number of fingers changes. We cannot use the old finger count as that may mismatch with the amount of touch coordinates we've available in the NEW packet 3) Their x data for the second touch is inaccurate leading to a possible jump of the x coordinate by 16 units when the first non NEW packet comes in Since problems 2 & 3 cannot be worked around, just ignore them. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Rafael J. Wysocki	3dcf157fe8	ACPI / PM: Fix PM initialization for devices that are not present commit `1b1f3e1699` upstream. If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Aaron Lu	de42aa3d47	ACPI / video: Add some Samsung models to disable_native_backlight list commit `7d0b93499f` upstream. Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working native backlight control interface so restore their acpi_videoX interface. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221 Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651 For SAMSUNG 870Z5E/880Z5E/680Z5E: Reported-and-tested-by: Brent Saner <brent.saner@gmail.com> Reported-by: Vitaliy Filippov <vitalif@yourcmc.ru> Reported-by: Laszlo KREKACS <laszlo.krekacs.list@gmail.com> For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V: Reported-by: Vladimir Perepechin <vovochka13@gmail.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
J. Bruce Fields	9e80aeb7c7	rpc: fix xdr_truncate_encode to handle buffer ending on page boundary commit `49a068f82a` upstream. A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com> Tested-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com> Fixes: `3e19ce762b` "rpc: xdr_truncate_encode" Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Pavel Machek	713beaa02f	Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo" commit `4bf9636c39` upstream. Commit `9fc2105aea` ("ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo") breaks audio in python, and probably elsewhere, with message FATAL: cannot locate cpu MHz in /proc/cpuinfo I'm not the first one to hit it, see for example https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/ https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1 Reading original changelog, I have to say "Stop breaking working setups. You know who you are!". Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Nishanth Menon	95a76bd5fa	ARM: OMAP4: PM: Only do static dependency configuration in omap4_init_static_deps commit `9008d83fe9` upstream. Commit `705814b5ea` ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Moved logic generic for OMAP5+ as part of the init routine by introducing omap4_pm_init. However, the patch left the powerdomain initial setup, an unused omap4430 es1.0 check and a spurious log "Power Management for TI OMAP4." in the original code. Remove the duplicate code which is already present in omap4_pm_init from omap4_init_static_deps. As part of this change, also move the u-boot version print out of the static dependency function to the omap4_pm_init function. Fixes: `705814b5ea` ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:55 -08:00
Tomasz Figa	b8775da83d	ARM: dts: Enable PWM node by default for s3c64xx commit `5e794de514` upstream. The PWM block is required for system clock source so it must be always enabled. This patch fixes boot issues on SMDK6410 which did not have the node enabled explicitly for other purposes. Fixes: `eeb93d02` ("clocksource: of: Respect device tree node status") Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Lokesh Vutla	e3041d3505	ARM: dts: DRA7: wdt: Fix compatible property for watchdog node commit `be6688350a` upstream. OMAP wdt driver supports only ti,omap3-wdt compatible. In DRA7 dt wdt compatible property is defined as ti,omap4-wdt by mistake instead of ti,omap3-wdt. Correcting the typo. Fixes: `6e58b8f1da` ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Viresh Kumar	5573b6341c	ARM: defconfigs: use CONFIG_CPUFREQ_DT commit `9d312cd12e` upstream. CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit `bbcf071969` ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'") and some defconfigs are still using it instead of the new one. Use the renamed CONFIG_CPUFREQ_DT generic driver. Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Tomi Valkeinen	20cb719845	ARM: dts: am437x-sk-evm.dts: fix LCD timings commit `d73f825e6e` upstream. The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while they seem to work with a quick test, doing for example blank/unblank will give you a black display. This patch updates the timings to the 'typical' values from the LCD spec sheet. Also, the compatible string is completely bogus, as "osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on the board is a newhaven one. Update the compatible string to reflect this. Note that this hasn't caused any issues, as the "panel-dpi" matches the driver. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Felipe Balbi	4e5a37c496	ARM: dts: am437x-sk: fix lcd enable pin mux data commit `58230c2c44` upstream. Caused by a copy & paste error. Note that even with this bug AM437x SK display still works because GPIO mux mode is always enabled. It's still wrong to mux somebody else's pin. Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x isn't used for anything. While at that, also replace a pullup with a pulldown as that gpio should be normally low, not high. Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Andy Lutomirski	170f69f4cf	sched: Add missing rcu protection to wake_up_all_idle_cpus commit `fd7de1e8d5` upstream. Locklessly doing is_idle_task(rq->curr) is only okay because of RCU protection. The older variant of the broken code checked rq->curr == rq->idle instead and therefore didn't need RCU. Fixes: `f6be8af1c9` ("sched: Add new API wake_up_if_idle() to wake up the idle cpu") Signed-off-by: Andy Lutomirski <luto@amacapital.net> Reviewed-by: Chuansheng Liu <chuansheng.liu@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/729365dddca178506dfd0a9451006344cd6808bc.1417277372.git.luto@amacapital.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Luca Abeni	f88708af7a	sched/deadline: Avoid double-accounting in case of missed deadlines commit `269ad8015a` upstream. The dl_runtime_exceeded() function is supposed to ckeck if a SCHED_DEADLINE task must be throttled, by checking if its current runtime is <= 0. However, it also checks if the scheduling deadline has been missed (the current time is larger than the current scheduling deadline), further decreasing the runtime if this happens. This "double accounting" is wrong: - In case of partitioned scheduling (or single CPU), this happens if task_tick_dl() has been called later than expected (due to small HZ values). In this case, the current runtime is also negative, and replenish_dl_entity() can take care of the deadline miss by recharging the current runtime to a value smaller than dl_runtime - In case of global scheduling on multiple CPUs, scheduling deadlines can be missed even if the task did not consume more runtime than expected, hence penalizing the task is wrong This patch fix this problem by throttling a SCHED_DEADLINE task only when its runtime becomes negative, and not modifying the runtime Signed-off-by: Luca Abeni <luca.abeni@unitn.it> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@gmail.com> Cc: Dario Faggioli <raistlin@linux.it> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1418813432-20797-3-git-send-email-luca.abeni@unitn.it Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Luca Abeni	fbbd9c2a84	sched/deadline: Fix migration of SCHED_DEADLINE tasks commit `6a503c3be9` upstream. According to global EDF, tasks should be migrated between runqueues without checking if their scheduling deadlines and runtimes are valid. However, SCHED_DEADLINE currently performs such a check: a migration happens doing: deactivate_task(rq, next_task, 0); set_task_cpu(next_task, later_rq->cpu); activate_task(later_rq, next_task, 0); which ends up calling dequeue_task_dl(), setting the new CPU, and then calling enqueue_task_dl(). enqueue_task_dl() then calls enqueue_dl_entity(), which calls update_dl_entity(), which can modify scheduling deadline and runtime, breaking global EDF scheduling. As a result, some of the properties of global EDF are not respected: for example, a taskset {(30, 80), (40, 80), (120, 170)} scheduled on two cores can have unbounded response times for the third task even if 30/80+40/80+120/170 = 1.5809 < 2 This can be fixed by invoking update_dl_entity() only in case of wakeup, or if this is a new SCHED_DEADLINE task. Signed-off-by: Luca Abeni <luca.abeni@unitn.it> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@gmail.com> Cc: Dario Faggioli <raistlin@linux.it> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1418813432-20797-2-git-send-email-luca.abeni@unitn.it Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Johannes Berg	8b65e97d82	scripts/kernel-doc: don't eat struct members with __aligned commit `7b990789a4` upstream. The change from \d+ to .+ inside __aligned() means that the following structure: struct test { u8 a __aligned(2); u8 b __aligned(2); }; essentially gets modified to struct test { u8 a; }; for purposes of kernel-doc, thus dropping a struct member, which in turns causes warnings and invalid kernel-doc generation. Fix this by replacing the catch-all (".") with anything that's not a semicolon ("[^;]"). Fixes: `9dc30918b2` ("scripts/kernel-doc: handle struct member __aligned without numbers") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: Nishanth Menon <nm@ti.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Ryusuke Konishi	83d17827a7	nilfs2: fix the nilfs_iget() vs. nilfs_new_inode() races commit `705304a863` upstream. Same story as in commit `41080b5a24` ("nfsd race fixes: ext2") (similar ext2 fix) except that nilfs2 needs to use insert_inode_locked4() instead of insert_inode_locked() and a bug of a check for dead inodes needs to be fixed. If nilfs_iget() is called from nfsd after nilfs_new_inode() calls insert_inode_locked4(), nilfs_iget() will wait for unlock_new_inode() at the end of nilfs_mkdir()/nilfs_create()/etc to unlock the inode. If nilfs_iget() is called before nilfs_new_inode() calls insert_inode_locked4(), it will create an in-core inode and read its data from the on-disk inode. But, nilfs_iget() will find i_nlink equals zero and fail at nilfs_read_inode_common(), which will lead it to call iget_failed() and cleanly fail. However, this sanity check doesn't work as expected for reused on-disk inodes because they leave a non-zero value in i_mode field and it hinders the test of i_nlink. This patch also fixes the issue by removing the test on i_mode that nilfs2 doesn't need. Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Roger Quadros	53575aa5ba	mtd: nand: omap: Fix NAND enumeration on 3430 LDP commit `775a9134f4` upstream. 3430LDP has NAND flash with 32 bytes OOB size which is sufficient to hold BCH8 codes but the small page check introduced in commit `b491da7233` ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") considers anything below 64 bytes unsuitable for BCH4/8/16. There is another bug in that code where it doesn't skip the check for OMAP_ECC_HAM1_CODE_SW. Get rid of that small page check code as it is insufficient and redundant because we are checking for OOB available bytes vs ecc layout before calling nand_scan_tail(). Fixes: `b491da7233` ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:54 -08:00
Alison Chaiken	d019b4693b	MTD: m25p80: fix inconsistency in m25p_ids compared to spi_nor_ids commit `834b686552` upstream. As stated in `a5b7616c5`, "mtd: m25p80,spi-nor: Fix module aliases for m25p80", m25p_ids[] in m25p80.c needs to be kept in sync with spi_nor_ids[] in spi-nor.c. The change here corrects a misalignment. (We were missing m25px80 and we had a duplicate w25q128.) Signed-off-by: Alison Chaiken <alison_chaiken@mentor.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Brian Norris	8513071f76	mtd: tests: abort torturetest on erase errors commit `68f2981503` upstream. The torture test should quit once it actually induces an error in the flash. This step was accidentally removed during refactoring. Without this fix, the torturetest just continues infinitely, or until the maximum cycle count is reached. e.g.: ... [ 7619.218171] mtd_test: error -5 while erasing EB 100 [ 7619.297981] mtd_test: error -5 while erasing EB 100 [ 7619.377953] mtd_test: error -5 while erasing EB 100 [ 7619.457998] mtd_test: error -5 while erasing EB 100 [ 7619.537990] mtd_test: error -5 while erasing EB 100 ... Fixes: `6cf78358c9` ("mtd: mtd_torturetest: use mtd_test helpers") Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Dan Carpenter	d5f902afa4	ceph: do_sync is never initialized commit `021b77bee2` upstream. Probably this code was syncing a lot more often then intended because the do_sync variable wasn't set to zero. Fixes: `c62988ec09` ('ceph: avoid meaningless calling ceph_caps_revoking if sync_mode == WB_SYNC_ALL.') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ilya Dryomov <idryomov@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Aaron Lu	7e7912667d	ACPI / video: update the skip case for acpi_video_device_in_dod() commit `b4df463678` upstream. If the firmware has declared more than 8 video output devices, and the one that control the internal panel's backlight is listed after the first 8 output devices, the _DOD will not include it due to the current i915 operation region implementation. As a result, we will not create a backlight device for it while we should. Solve this problem by special case the firmware that has 8+ output devices in that if we see such a firmware, we do not test if the device is in _DOD list. The creation of the backlight device will also enable the firmware to emit events on backlight hotkey press when the acpi_osi= cmdline option is specified on those affected ASUS laptops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70241 Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de> Reported-and-tested-by: Dmitry Tunin <hanipouspilot@gmail.com> Reported-and-tested-by: Jimbo <jaime.91@hotmail.es> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Jeff Layton	bff467fabe	nfsd: fix fi_delegees leak when fi_had_conflict returns true commit `94ae1db226` upstream. Currently, nfs4_set_delegation takes a reference to an existing delegation and then checks to see if there is a conflict. If there is one, then it doesn't release that reference. Change the code to take the reference after the check and only if there is no conflict. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Benjamin Coddington	7599f17f05	nfsd4: fix xdr4 count of server in fs_location4 commit `bf7491f1be` upstream. Fix a bug where nfsd4_encode_components_esc() incorrectly calculates the length of server array in fs_location4--note that it is a count of the number of array elements, not a length in bytes. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Fixes: `082d4bd72a` (nfsd4: "backfill" using write_bytes_to_xdr_buf) Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Benjamin Coddington	6a4edf54d9	nfsd4: fix xdr4 inclusion of escaped char commit `5a64e56976` upstream. Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as an additional string encoding. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Fixes: `e7a0444aef` "nfsd: add IPv6 addr escaping to fs_location hosts" Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Rasmus Villemoes	fb0a855743	fs: nfsd: Fix signedness bug in compare_blob commit `ef17af2a81` upstream. Bugs similar to the one in `acbbe6fbb2` (kcmp: fix standard comparison bug) are in rich supply. In this variant, the problem is that struct xdr_netobj::len has type unsigned int, so the expression o1->len - o2->len _also_ has type unsigned int; it has completely well-defined semantics, and the result is some non-negative integer, which is always representable in a long long. But this means that if the conditional triggers, we are guaranteed to return a positive value from compare_blob. In this case it could be fixed by - res = o1->len - o2->len; + res = (long long)o1->len - (long long)o2->len; but I'd rather eliminate the usually broken 'return a - b;' idiom. Reviewed-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Vitaly Kuznetsov	cb64628f01	Drivers: hv: util: make struct hv_do_fcopy match Hyper-V host messages commit `31d4ea1a09` upstream. An attempt to fix fcopy on i586 (`bc5a5b0` Drivers: hv: util: Properly pack the data for file copy functionality) led to a regression on x86_64 (and actually didn't fix i586 breakage). Fcopy messages from Hyper-V host come in the following format: struct do_fcopy_hdr \| 36 bytes 0000 \| 4 bytes offset \| 8 bytes size \| 4 bytes data \| 6144 bytes On x86_64 struct hv_do_fcopy matched this format without ' __attribute__((packed))' and on i586 adding ' __attribute__((packed))' to it doesn't change anything. Keep the structure packed and add padding to match re reality. Tested both i586 and x86_64 on Hyper-V Server 2012 R2. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Vitaly Kuznetsov	ae4b4f11a5	Drivers: hv: vmbus: Fix a race condition when unregistering a device commit `04a258c162` upstream. When build with Debug the following crash is sometimes observed: Call Trace: [<ffffffff812b9600>] string+0x40/0x100 [<ffffffff812bb038>] vsnprintf+0x218/0x5e0 [<ffffffff810baf7d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff812bb4c1>] vscnprintf+0x11/0x30 [<ffffffff8107a2f0>] vprintk+0xd0/0x5c0 [<ffffffffa0051ea0>] ? vmbus_process_rescind_offer+0x0/0x110 [hv_vmbus] [<ffffffff8155c71c>] printk+0x41/0x45 [<ffffffffa004ebac>] vmbus_device_unregister+0x2c/0x40 [hv_vmbus] [<ffffffffa0051ecb>] vmbus_process_rescind_offer+0x2b/0x110 [hv_vmbus] ... This happens due to the following race: between 'if (channel->device_obj)' check in vmbus_process_rescind_offer() and pr_debug() in vmbus_device_unregister() the device can disappear. Fix the issue by taking an additional reference to the device before proceeding to vmbus_device_unregister(). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Christian Riesch	3db43085fc	n_tty: Fix read_buf race condition, increment read_head after pushing data commit `8bfbe2de76` upstream. Commit `19e2ad6a09` ("n_tty: Remove overflow tests from receive_buf() path") moved the increment of read_head into the arguments list of read_buf_addr(). Function calls represent a sequence point in C. Therefore read_head is incremented before the character c is placed in the buffer. Since the circular read buffer is a lock-less design since commit `6d76bd2618` ("n_tty: Make N_TTY ldisc receive path lockless"), this creates a race condition that leads to communication errors. This patch modifies the code to increment read_head _after_ the data is placed in the buffer and thus fixes the race for non-SMP machines. To fix the problem for SMP machines, memory barriers must be added in a separate patch. Signed-off-by: Christian Riesch <christian.riesch@omicron.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Jiri Slaby	66a2cbe36f	reiserfs: destroy allocated commit workqueue commit `fa0c554073` upstream. When resirefs is trying to mount a partition, it creates a commit workqueue (sbi->commit_wq). But when mount fails later, the workqueue is not freed. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: auxsvr@gmail.com Reported-by: Benoît Monin <benoit.monin@gmx.fr> Cc: Jan Kara <jack@suse.cz> Cc: reiserfs-devel@vger.kernel.org Fixes: `797d9016ce` Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:53 -08:00
Max Filippov	45f5afbe42	xtensa: fix kmap_prot definition commit `ff009ab6d4` upstream. Replace PAGE_KERNEL with PAGE_KERNEL_EXEC to allow copy_to_user_page invalidate icache for pages mapped with kmap. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Robert Baldyga	69db2635ad	serial: samsung: wait for transfer completion before clock disable commit `1ff383a4c3` upstream. This patch adds waiting until transmit buffer and shifter will be empty before clock disabling. Without this fix it's possible to have clock disabled while data was not transmited yet, which causes unproper state of TX line and problems in following data transfers. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Axel Lin	0fd0e781e9	tty: serial: men_z135_uart: Add terminating entry for men_z135_ids commit `6b1f40cf48` upstream. The mcb_device_id table is supposed to be zero-terminated. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Steven Rostedt (Red Hat)	2ce1eeb346	tracing/sched: Check preempt_count() for current when reading task->state commit `aee4e5f3d3` upstream. When recording the state of a task for the sched_switch tracepoint a check of task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is because, technically, a task being preempted is really in the TASK_RUNNING state, and that is what should be recorded when tracing a sched_switch, even if the task put itself into another state (it hasn't scheduled out in that state yet). But with the change to use per_cpu preempt counts, the task_thread_info(p)->preempt_count is no longer used, and instead task_preempt_count(p) is used. The problem is that this does not use the current preempt count but a stale one from a previous sched_switch. The task_preempt_count(p) uses saved_preempt_count and not preempt_count(). But for tracing sched_switch, if p is current, we really want preempt_count(). I hit this bug when I was tracing sleep and the call from do_nanosleep() scheduled out in the "RUNNING" state. sleep-4290 [000] 537272.259992: sched_switch: sleep:4290 [120] R ==> swapper/0:0 [120] sleep-4290 [000] 537272.260015: kernel_stack: <stack trace> => __schedule (ffffffff8150864a) => schedule (ffffffff815089f8) => do_nanosleep (ffffffff8150b76c) => hrtimer_nanosleep (ffffffff8108d66b) => SyS_nanosleep (ffffffff8108d750) => return_to_handler (ffffffff8150e8e5) => tracesys_phase2 (ffffffff8150c844) After a bit of hair pulling, I found that the state was really TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE set and caused the sched_switch tracepoint to show it as RUNNING. Link: http://lkml.kernel.org/r/20141210174428.3cb7542a@gandalf.local.home Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: `0102874755` "sched: Create more preempt_count accessors" Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Tejun Heo	02a59e2918	writeback: fix a subtle race condition in I_DIRTY clearing commit `9c6ac78eb3` upstream. After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and tests inode->i_state locklessly to see whether it already has all the necessary I_DIRTY bits set. The comment above the barrier doesn't contain any useful information - memory barriers can't ensure "changes are seen by all cpus" by itself. And it sure enough was broken. Please consider the following scenario. CPU 0 CPU 1 ------------------------------------------------------------------------------- enters __writeback_single_inode() grabs inode->i_lock tests PAGECACHE_TAG_DIRTY which is clear enters __set_page_dirty() grabs mapping->tree_lock sets PAGECACHE_TAG_DIRTY releases mapping->tree_lock leaves __set_page_dirty() enters __mark_inode_dirty() smp_mb() sees I_DIRTY_PAGES set leaves __mark_inode_dirty() clears I_DIRTY_PAGES releases inode->i_lock Now @inode has dirty pages w/ I_DIRTY_PAGES clear. This doesn't seem to lead to an immediately critical problem because requeue_inode() later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when deciding whether the inode needs to be requeued for IO and there are enough unintentional memory barriers inbetween, so while the inode ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the IO list. The lack of explicit barrier may also theoretically affect the other I_DIRTY bits which deal with metadata dirtiness. There is no guarantee that a strong enough barrier exists between I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied inode. Filesystem inode writeout path likely has enough stuff which can behave as full barrier but it's theoretically possible that the writeout may not see all the updates from ->dirty_inode(). Fix it by adding an explicit smp_mb() after I_DIRTY clearing. Note that I_DIRTY_PAGES needs a special treatment as it always needs to be cleared to be interlocked with the lockless test on __mark_inode_dirty() side. It's cleared unconditionally and reinstated after smp_mb() if the mapping still has dirty pages. Also add comments explaining how and why the barriers are paired. Lightly tested. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Philipp Reisner	7bde1727e9	drbd: Fix state change in case of connection timeout commit `9581f97a68` upstream. A connection timeout affects all volumes of a resource! Under the following conditions: A resource with multiple volumes AND ko-count >=1 AND a write request triggers the timeout (ko-count * timeout) DRBD's internal state gets confused. That in turn may lead to very miss leading follow up failures. E.g. "BUG: scheduling while atomic" Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Lars Ellenberg	af86a8a7cf	drbd: merge_bvec_fn: properly remap bvm->bi_bdev commit `3b9d35d744` upstream. This was not noticed for many years. Affects operation if md raid is used a backing device for DRBD. Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Oliver Neukum	f1a6540168	cdc-acm: memory leak in error case commit `d908f8478a` upstream. If probe() fails not only the attributes need to be removed but also the memory freed. Reported-by: Ahmed Tamrawi <ahmedtamrawi@gmail.com> Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Jens Axboe	ee9b142838	genhd: check for int overflow in disk_expand_part_tbl() commit `5fabcb4c33` upstream. We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition() with a user passed in partno value. If we pass in 0x7fffffff, the new target in disk_expand_part_tbl() overflows the 'int' and we access beyond the end of ptbl->part[] and even write to it when we do the rcu_assign_pointer() to assign the new partition. Reported-by: David Ramos <daramos@stanford.edu> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Steev Klimaszewski	5986bc8088	Add USB_EHCI_EXYNOS to multi_v7_defconfig commit `007487f1fd` upstream. Currently we enable Exynos devices in the multi v7 defconfig, however, when testing on my ODROID-U3, I noticed that USB was not working. Enabling this option causes USB to work, which enables networking support as well since the ODROID-U3 has networking on the USB bus. [arnd] Support for odroid-u3 was added in 3.10, so it would be nice to backport this fix at least that far. Signed-off-by: Steev Klimaszewski <steev@gentoo.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Martin Hauke	d58e9138ee	USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem commit `e7181d005e` upstream. Added new device layout "DEVICE_HWI" and also added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e) Signed-off-by: Martin Hauke <mardnh@gmx.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Ronald Wahl	e6e9495eae	usb: gadget: at91_udc: move prepare clk into process context commit `b2ba27a5c5` upstream. Commit `7628083227` (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:52 -08:00
Kazuya Mizuguchi	e2eb98070a	usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable() commit `11432050f0` upstream. This patch fixes an issue that the NULL pointer dereference happens when we uses g_audio driver. Since the g_audio driver will call usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(), the uep->pipe of renesas usbhs driver will be NULL. So, this patch adds a condition to avoid the oops. Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: `2f98382dc` (usb: renesas_usbhs: Add Renesas USBHS Gadget) Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Greg Kroah-Hartman	1a199fe9b2	USB: cdc-acm: check for valid interfaces commit `403dff4e2c` upstream. We need to check that we have both a valid data and control inteface for both types of headers (union and not union.) References: https://bugzilla.kernel.org/show_bug.cgi?id=83551 Reported-by: Simon Schubert <2+kernel@0x2c.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
NeilBrown	7e73b0028f	md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants. commit `108cef3aa4` upstream. It is critical that fetch_block() and handle_stripe_dirtying() are consistent in their analysis of what needs to be loaded. Otherwise raid5 can wait forever for a block that won't be loaded. Currently when writing to a RAID5 that is resyncing, to a location beyond the resync offset, handle_stripe_dirtying chooses a reconstruct-write cycle, but fetch_block() assumes a read-modify-write, and a lockup can happen. So treat that case just like RAID6, just as we do in handle_stripe_dirtying. RAID6 always does reconstruct-write. This bug was introduced when the behaviour of handle_stripe_dirtying was changed in 3.7, so the patch is suitable for any kernel since, though it will need careful merging for some versions. Fixes: `a7854487cd` Reported-by: Henry Cai <henryplusplus@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Aaron Plattner	b51e392363	ALSA: hda - Add new GPU codec ID 0x10de0072 to snd-hda commit `60834b73a9` upstream. Vendor ID 0x10de0072 is used by a yet-to-be-named GPU chip. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Takashi Iwai	d7e73a7186	ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecs commit `c507de88f6` upstream. stac_store_hints() does utterly wrong for masking the values for gpio_dir and gpio_data, likely due to copy&paste errors. Fortunately, this feature is used very rarely, so the impact must be really small. Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Daniel Mack	046a9bfa62	ALSA: snd-usb-caiaq: fix stream count check commit `49cdd5b641` upstream. Commit `897c329bc` ("ALSA: usb: caiaq: check for cdev->n_streams > 1") introduced a safety check to protect against bogus data provided by devices. However, the n_streams variable is already divided by CHANNELS_PER_STREAM, so the correct check is 'n_streams > 0'. Fix this to un-break support for stereo devices. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Takashi Sakamoto	9e31ed5fc6	ALSA: fireworks: fix an endianness bug for transaction length commit `92cb46584e` upstream. Although the 't->length' is a big-endian value, it's used without any conversion. This means that the driver always uses 'length' parameter. Fixes: 555e8a8f7f14("ALSA: fireworks: Add command/response functionality into hwdep interface") Reported-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Dan Carpenter	61654b8c51	ALSA: hda - using uninitialized data commit `69eba10e60` upstream. In olden times the snd_hda_param_read() function always set "*start_id" but in 2007 we introduced a new return and it causes uninitialized data bugs in a couple of the callers: print_codec_info() and hdmi_parse_codec(). Fixes: `e8a7f136f5` ('[ALSA] hda-intel - Improve HD-audio codec probing robustness') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:51 -08:00
Kailang Yang	721b64bdc1	ALSA: hda/realtek - Add new Dell desktop for ALC3234 headset mode commit `8b72415d8a` upstream. New Dell desktop needs to support headset mode for ALC3234. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Kailang Yang	4c95046961	ALSA: hda/realtek - New codec support for ALC256 commit `4344aec84b` upstream. Add new support for ALC256 codec. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Kailang Yang	a8302062ad	ALSA: hda/realtek - New codec support for ALC298 commit `506b62c33a` upstream. Add new support for ALC298 codec. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Jiri Jaburek	6c300cb1fb	ALSA: usb-audio: extend KEF X300A FU 10 tweak to Arcam rPAC commit `d70a1b9893` upstream. The Arcam rPAC seems to have the same problem - whenever anything (alsamixer, udevd, 3.9+ kernel from `60af3d037e`, ..) attempts to access mixer / control interface of the card, the firmware "locks up" the entire device, resulting in SNDRV_PCM_IOCTL_HW_PARAMS failed (-5): Input/output error from alsa-lib. Other operating systems can somehow read the mixer (there seems to be playback volume/mute), but any manipulation is ignored by the device (which has hardware volume controls). Signed-off-by: Jiri Jaburek <jjaburek@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Doug Anderson	989eae716a	i2c: designware: Fix falling time bindings doc commit `8e2596e81a` upstream. In (`6468276` i2c: designware: make SCL and SDA falling time configurable) new device tree properties were added for setting the falling time of SDA and SCL. The device tree bindings doc had a typo in it: it forgot the "-ns" suffix for both properies in the prose of the bindings. I assume this is a typo because: * The source code includes the "-ns" * The example in the bindings includes the "-ns". Fix the typo. Signed-off-by: Doug Anderson <dianders@chromium.org> Fixes: `6468276b22` ("i2c: designware: make SCL and SDA falling time configurable") Acked-by: Romain Baeriswyl <romain.baeriswyl@alitech.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Pali Rohár	c444aeae65	i8k: Add support for Dell Latitude E6440 commit `0f352239de` upstream. Dell Latitude E6440 needs same settings as E6540. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Ian Abbott	1a5773af11	misc: genwqe: check for error from get_user_pages_fast() commit `cf35d6e047` upstream. `genwqe_user_vmap()` calls `get_user_pages_fast()` and if the return value is less than the number of pages requested, it frees the pages and returns an error (`-EFAULT`). However, it fails to consider a negative error return value from `get_user_pages_fast()`. In that case, the test `if (rc < m->nr_pages)` will be false (due to promotion of `rc` to a large `unsigned int`) and the code will continue on to call `genwqe_map_pages()` with an invalid list of page pointers. Fix it by bailing out if `get_user_pages_fast()` returns a negative error value. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Alex Williamson	27be783535	driver core: Fix unbalanced device reference in drivers_probe commit `bb34cb6bbd` upstream. bus_find_device_by_name() acquires a device reference which is never released. This results in an object leak, which on older kernels results in failure to release all resources of PCI devices. libvirt uses drivers_probe to re-attach devices to the host after assignment and is therefore a common trigger for this leak. Example: # cd /sys/bus/pci/ # dmesg -C # echo 1 > devices/0000\:01\:00.0/sriov_numvfs # echo 0 > devices/0000\:01\:00.0/sriov_numvfs # dmesg \| grep 01:10 pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000 kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices' kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_cleanup, parent (null) kobject: '0000:01:10.0' (ffff8801d79cd0a8): calling ktype release kobject: '0000:01:10.0': free name [kobject freed as expected] # dmesg -C # echo 1 > devices/0000\:01\:00.0/sriov_numvfs # echo 0000:01:10.0 > drivers_probe # echo 0 > devices/0000\:01\:00.0/sriov_numvfs # dmesg \| grep 01:10 pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000 kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices' kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0' [no free] Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Andy Lutomirski	ccf8296923	x86, vdso: Use asm volatile in __getcpu commit `1ddf0b1b11` upstream. In Linux 3.18 and below, GCC hoists the lsl instructions in the pvclock code all the way to the beginning of __vdso_clock_gettime, slowing the non-paravirt case significantly. For unknown reasons, presumably related to the removal of a branch, the performance issue is gone as of `e76b027e64` x86,vdso: Use LSL unconditionally for vgetcpu but I don't trust GCC enough to expect the problem to stay fixed. There should be no correctness issue, because the __getcpu calls in __vdso_vlock_gettime were never necessary in the first place. Note to stable maintainers: In 3.18 and below, depending on configuration, gcc 4.9.2 generates code like this: 9c3: 44 0f 03 e8 lsl %ax,%r13d 9c7: 45 89 eb mov %r13d,%r11d 9ca: 0f 03 d8 lsl %ax,%ebx This patch won't apply as is to any released kernel, but I'll send a trivial backported version if needed. [ Backported by Andy Lutomirski. Should apply to all affected versions. This fixes a functionality bug as well as a performance bug: buggy kernels can infinite loop in __vdso_clock_gettime on affected compilers. See, for exammple: https://bugzilla.redhat.com/show_bug.cgi?id=1178975 ] Fixes: `51c19b4f59` x86: vdso: pvclock gettime support Cc: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:50 -08:00
Andy Lutomirski	ef44baf660	x86_64, vdso: Fix the vdso address randomization algorithm commit `394f56fe48` upstream. The theory behind vdso randomization is that it's mapped at a random offset above the top of the stack. To avoid wasting a page of memory for an extra page table, the vdso isn't supposed to extend past the lowest PMD into which it can fit. Other than that, the address should be a uniformly distributed address that meets all of the alignment requirements. The current algorithm is buggy: the vdso has about a 50% probability of being at the very end of a PMD. The current algorithm also has a decent chance of failing outright due to incorrect handling of the case where the top of the stack is near the top of its PMD. This fixes the implementation. The paxtest estimate of vdso "randomisation" improves from 11 bits to 18 bits. (Disclaimer: I don't know what the paxtest code is actually calculating.) It's worth noting that this algorithm is inherently biased: the vdso is more likely to end up near the end of its PMD than near the beginning. Ideally we would either nix the PMD sharing requirement or jointly randomize the vdso and the stack to reduce the bias. In the mean time, this is a considerable improvement with basically no risk of compatibility issues, since the allowed outputs of the algorithm are unchanged. As an easy test, doing this: for i in `seq 10000` do grep -P vdso /proc/self/maps \|cut -d- -f1 done \|sort \|uniq -d used to produce lots of output (1445 lines on my most recent run). A tiny subset looks like this: 7fffdfffe000 7fffe01fe000 7fffe05fe000 7fffe07fe000 7fffe09fe000 7fffe0bfe000 7fffe0dfe000 Note the suspicious fe000 endings. With the fix, I get a much more palatable 76 repeated addresses. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Paolo Bonzini	032e45d8b7	kvm: x86: drop severity of "generation wraparound" message commit `a629df7ead` upstream. Since most virtual machines raise this message once, it is a bit annoying. Make it KERN_DEBUG severity. Fixes: `7a2e8aaf0f` Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Christian Borntraeger	cec145a834	KVM: s390: Fix ipte locking commit `1365039d0c` upstream. ipte_unlock_siif uses cmpxchg to replace the in-memory data of the ipte lock together with ACCESS_ONCE for the intial read. union ipte_control { unsigned long val; struct { unsigned long k : 1; unsigned long kh : 31; unsigned long kg : 32; }; }; [...] static void ipte_unlock_siif(struct kvm_vcpu vcpu) { union ipte_control old, new, ic; ic = &vcpu->kvm->arch.sca->ipte_control; do { new = old = ACCESS_ONCE(*ic); new.kh--; if (!new.kh) new.k = 0; } while (cmpxchg(&ic->val, old.val, new.val) != old.val); if (!new.kh) wake_up(&vcpu->kvm->arch.ipte_wq); } The new value, is loaded twice from memory with gcc 4.7.2 of fedora 18, despite the ACCESS_ONCE: ---> l %r4,0(%r3) <--- load first 32 bit of lock (k and kh) in r4 alfi %r4,2147483647 <--- add -1 to r4 llgtr %r4,%r4 <--- zero out the sign bit of r4 lg %r1,0(%r3) <--- load all 64 bit of lock into new lgr %r2,%r1 <--- load the same into old risbg %r1,%r4,1,31,32 <--- shift and insert r4 into the bits 1-31 of new llihf %r4,2147483647 ngrk %r4,%r1,%r4 jne aa0 <ipte_unlock+0xf8> nihh %r1,32767 lgr %r4,%r2 csg %r4,%r1,0(%r3) cgr %r2,%r4 jne a70 <ipte_unlock+0xc8> If the memory value changes between the first load (l) and the second load (lg) we are broken. If that happens VCPU threads will hang (unkillable) in handle_ipte_interlock. Andreas Krebbel analyzed this and tracked it down to a compiler bug in that version: "while it is not that obvious the C99 standard basically forbids duplicating the memory access also in that case. For an argumentation of a similiar case please see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278#c43 For the implementation-defined cases regarding volatile there are some GCC-specific clarifications which can be found here: https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html#Volatiles I've tracked down the problem with a reduced testcase. The problem was that during a tree level optimization (SRA - scalar replacement of aggregates) the volatile marker is lost. And an RTL level optimizer (CSE - common subexpression elimination) then propagated the memory read into its second use introducing another access to the memory location. So indeed Christian's suspicion that the union access has something to do with it is correct (since it triggered the SRA optimization). This issue has been reported and fixed in the GCC 4.8 development cycle: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145" This patch replaces the ACCESS_ONCE scheme with a barrier() based scheme that should work for all supported compilers. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Christian Borntraeger	31408f1ad1	KVM: s390: flush CPU on load control commit `2dca485f87` upstream. some control register changes will flush some aspects of the CPU, e.g. POP explicitely mentions that for CR9-CR11 "TLBs may be cleared". Instead of trying to be clever and only flush on specific CRs, let play safe and flush on all lctl(g) as future machines might define new bits in CRs. Load control intercept should not happen that often. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Thomas Huth	c3e724b874	KVM: s390: Fix size of monitor-class number field commit `a36c539326` upstream. The monitor-class number field is only 16 bits, so we have to use a u16 pointer to access it. Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Paolo Bonzini	d3105d5637	kvm: x86: mask out XSAVES commit `b65d6e17fe` upstream. This feature is not supported inside KVM guests yet, because we do not emulate MSR_IA32_XSS. Mask it out. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Nadav Amit	09e365b46c	KVM: x86: em_ret_far overrides cpl commit `ab646f54f4` upstream. commit `d50eaa1803` ("KVM: x86: Perform limit checks when assigning EIP") mistakenly used zero as cpl on em_ret_far. Use the actual one. Fixes: `d50eaa1803` Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Paolo Bonzini	c4a525417c	KVM: x86: support XSAVES usage in the host commit `df1daba7d1` upstream. Userspace is expecting non-compacted format for KVM_GET_XSAVE, but struct xsave_struct might be using the compacted format. Convert in order to preserve userspace ABI. Likewise, userspace is passing non-compacted format for KVM_SET_XSAVE but the kernel will pass it to XRSTORS, and we need to convert back. Fixes: `f31a9f7c71` Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@linux.intel.com> Tested-by: Nadav Amit <namit@cs.technion.ac.il> Reviewed-by: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Paolo Bonzini	1f92632c5b	x86: export get_xsave_addr commit `ba7b39203a` upstream. get_xsave_addr is the API to access XSAVE states, and KVM would like to use it. Export it. Cc: x86@kernel.org Cc: H. Peter Anvin <hpa@linux.intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Giedrius Statkevičius	1cafdf529e	HID: Add a new id 0x501a for Genius MousePen i608X commit `2bacedada6` upstream. New Genius MousePen i608X devices have a new id 0x501a instead of the old 0x5011 so add a new #define with "_2" appended and change required places. The remaining two checkpatch warnings about line length being over 80 characters are present in the original files too and this patch was made in the same style (no line break). Just adding a new id and changing the required places should make the new device work without any issues according to the bug report in the following url. This patch was made according to and fixes: https://bugzilla.kernel.org/show_bug.cgi?id=67111 Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Karl Relton	4fe49b186f	HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO keyboard commit `da940db41d` upstream. Apple bluetooth wireless keyboard (sold in UK) has always reported zero for battery strength no matter what condition the batteries are actually in. With this patch applied (applying same quirk as other Apple keyboards), the battery strength is now correctly reported. Signed-off-by: Karl Relton <karllinuxtest.relton@ntlworld.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Mika Westerberg	e0c4b58501	HID: i2c-hid: Do not free buffers in i2c_hid_stop() commit `5b44c53aeb` upstream. When a hid driver that uses i2c-hid as transport is unloaded, the hid core will call i2c_hid_stop() which releases all the buffers associated with the device. This includes also the command buffer. Now, when the i2c-hid driver itself is unloaded it tries to power down the device by sending it PWR_SLEEP command. Since the command buffer is already released we get following crash: [ 79.691459] BUG: unable to handle kernel NULL pointer dereference at (null) [ 79.691532] IP: [<ffffffffa05bc049>] __i2c_hid_command+0x49/0x310 [i2c_hid] ... [ 79.693467] Call Trace: [ 79.693494] [<ffffffff810424e1>] ? __unmask_ioapic+0x21/0x30 [ 79.693537] [<ffffffff81042855>] ? unmask_ioapic+0x25/0x40 [ 79.693581] [<ffffffffa05bc35b>] ? i2c_hid_set_power+0x4b/0xa0 [i2c_hid] [ 79.693632] [<ffffffffa05bc3cf>] ? i2c_hid_runtime_resume+0x1f/0x30 [i2c_hid] [ 79.693689] [<ffffffff814c08fb>] ? __rpm_callback+0x2b/0x70 [ 79.693733] [<ffffffff814c0961>] ? rpm_callback+0x21/0x90 [ 79.693776] [<ffffffff814c0dec>] ? rpm_resume+0x41c/0x600 [ 79.693820] [<ffffffff814c1e1c>] ? __pm_runtime_resume+0x4c/0x80 [ 79.693868] [<ffffffff814b8588>] ? __device_release_driver+0x28/0x100 [ 79.693917] [<ffffffff814b8d90>] ? driver_detach+0xa0/0xb0 [ 79.693959] [<ffffffff814b82cc>] ? bus_remove_driver+0x4c/0xb0 [ 79.694006] [<ffffffff810d1cfd>] ? SyS_delete_module+0x11d/0x1d0 [ 79.694054] [<ffffffff8165f107>] ? int_signal+0x12/0x17 [ 79.694095] [<ffffffff8165ee69>] ? system_call_fastpath+0x12/0x17 Fix this so that we only free buffers when the i2c-hid driver itself is removed. Fixes: `34f439e4af` ("HID: i2c-hid: add runtime PM support") Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Dan Carpenter	8ccb93d2e2	HID: roccat: potential out of bounds in pyra_sysfs_write_settings() commit `606185b20c` upstream. This is a static checker fix. We write some binary settings to the sysfs file. One of the settings is the "->startup_profile". There isn't any checking to make sure it fits into the pyra->profile_settings[] array in the profile_activated() function. I added a check to pyra_sysfs_write_settings() in both places because I wasn't positive that the other callers were correct. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:49 -08:00
Gwendal Grignou	e788b6db96	HID: i2c-hid: prevent buffer overflow in early IRQ commit `d1c7e29e8d` upstream. Before ->start() is called, bufsize size is set to HID_MIN_BUFFER_SIZE, 64 bytes. While processing the IRQ, we were asking to receive up to wMaxInputLength bytes, which can be bigger than 64 bytes. Later, when ->start is run, a proper bufsize will be calculated. Given wMaxInputLength is said to be unreliable in other part of the code, set to receive only what we can even if it results in truncated reports. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Jean-Baptiste Maneyrol	db8bf51731	HID: i2c-hid: fix race condition reading reports commit `6296f4a8eb` upstream. Current driver uses a common buffer for reading reports either synchronously in i2c_hid_get_raw_report() and asynchronously in the interrupt handler. There is race condition if an interrupt arrives immediately after the report is received in i2c_hid_get_raw_report(); the common buffer is modified by the interrupt handler with the new report and then i2c_hid_get_raw_report() proceed using wrong data. Fix it by using a separate buffers for synchronous reports. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> [Antonio Borneo: cleanup, rebase to v3.17, submit mainline] Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Benjamin Tissoires	8bb664fb9e	HID: wacom: fix freeze on open when autosuspend is on commit `dff6741688` upstream. Since the conversion from USB to HID (in v3.17), some people reported a freeze on boot with the wacom driver. Hans managed to get a stacktrace: [ 240.272331] Call Trace: [ 240.272338] [<ffffffff813de7b9>] ? usb_hcd_submit_urb+0xa9/0xb10 [ 240.272347] [<ffffffff81555579>] schedule+0x29/0x70 [ 240.272355] [<ffffffff815559e6>] schedule_preempt_disabled+0x16/0x20 [ 240.272363] [<ffffffff81557365>] __mutex_lock_slowpath+0xe5/0x230 [ 240.272372] [<ffffffff815574c7>] mutex_lock+0x17/0x30 [ 240.272380] [<ffffffffa063c1d2>] wacom_resume+0x22/0x50 [wacom] [ 240.272396] [<ffffffffa01aea8a>] hid_resume_common+0xba/0x110 [usbhid] [ 240.272404] [<ffffffff813e5890>] ? usb_runtime_suspend+0x80/0x80 [ 240.272417] [<ffffffffa01aeb1d>] hid_resume+0x3d/0x70 [usbhid] [ 240.272425] [<ffffffff813e44a6>] usb_resume_interface.isra.6+0xb6/0x120 [ 240.272432] [<ffffffff813e4774>] usb_resume_both+0x74/0x140 [ 240.272439] [<ffffffff813e58aa>] usb_runtime_resume+0x1a/0x20 [ 240.272446] [<ffffffff813b1912>] __rpm_callback+0x32/0x70 [ 240.272453] [<ffffffff813b1976>] rpm_callback+0x26/0xa0 [ 240.272460] [<ffffffff813b2d71>] rpm_resume+0x4b1/0x690 [ 240.272468] [<ffffffff812ab992>] ? radix_tree_lookup_slot+0x22/0x50 [ 240.272475] [<ffffffff813b2c1a>] rpm_resume+0x35a/0x690 [ 240.272482] [<ffffffff8116e9c9>] ? zone_statistics+0x89/0xa0 [ 240.272489] [<ffffffff813b2f90>] __pm_runtime_resume+0x40/0x60 [ 240.272497] [<ffffffff813e4272>] usb_autopm_get_interface+0x22/0x60 [ 240.272509] [<ffffffffa01ae8d9>] usbhid_open+0x59/0xe0 [usbhid] [ 240.272517] [<ffffffffa063ac85>] wacom_open+0x35/0x50 [wacom] [ 240.272525] [<ffffffff813f37b9>] input_open_device+0x79/0xa0 [ 240.272534] [<ffffffffa048d1c1>] evdev_open+0x1b1/0x200 [evdev] [ 240.272543] [<ffffffff811c899e>] chrdev_open+0xae/0x1f0 [ 240.272549] [<ffffffff811c88f0>] ? cdev_put+0x30/0x30 [ 240.272556] [<ffffffff811c17e2>] do_dentry_open+0x1d2/0x320 [ 240.272562] [<ffffffff811c1cd1>] finish_open+0x31/0x50 [ 240.272571] [<ffffffff811d2202>] do_last.isra.36+0x652/0xe50 [ 240.272579] [<ffffffff811d2ac7>] path_openat+0xc7/0x6f0 [ 240.272586] [<ffffffff811cf012>] ? final_putname+0x22/0x50 [ 240.272594] [<ffffffff811d42d2>] ? user_path_at_empty+0x72/0xd0 [ 240.272602] [<ffffffff811d43fd>] do_filp_open+0x4d/0xc0 [...] So here, wacom_open is called, and then wacom_resume is called by the PM system. However, wacom_open already took the lock when wacom_resume tries to get it. Freeze. A little bit of history shows that this already happened in the past - commit `f6cd378372` ("Input: wacom - fix runtime PM related deadlock"), and the solution was to call first the PM function before taking the lock. The lock was introduced in commit commit `e722409445` ("Input: wacom - implement suspend and autosuspend") when the autosuspend feature has been added. Given that usbhid already takes care of this very same locking between suspend/resume, I think we can simply kill the lock in open/close. The lock is now used also with LEDs, so we can not remove it completely. Reported-by: Hans Spath <inbox-546@hans-spath.de> Tested-by: Hans Spath <inbox-546@hans-spath.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Benjamin Tissoires	15c1c0a1b1	HID: wacom: re-add accidentally dropped Lenovo PID commit `00d6f227a5` upstream. Dropped in the following commit: commit `a3e6f6543d` ("Input: wacom - keep wacom_ids ordered") Reported-by: Hans Spath <inbox-546@hans-spath.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Oliver Neukum	7e4cec4069	HID: yet another buggy ELAN touchscreen commit `a32c99e7ab` upstream. The touchscreen needs the same quirk as the other models. Signed-off-by: Oliver Neukum <oneukum@suse.de> Reported-by: Bryan Poling <poli0048@umn.edu> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Takashi Iwai	fa5e4747af	blk-mq: Fix uninitialized kobject at CPU hotplugging commit `06a41a99d1` upstream. When a CPU is hotplugged, the current blk-mq spews a warning like: kobject '(null)' (ffffe8ffffc8b5d8): tried to add an uninitialized object, something is seriously wrong. CPU: 1 PID: 1386 Comm: systemd-udevd Not tainted 3.18.0-rc7-2.g088d59b-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_171129-lamiak 04/01/2014 0000000000000000 0000000000000002 ffffffff81605f07 ffffe8ffffc8b5d8 ffffffff8132c7a0 ffff88023341d370 0000000000000020 ffff8800bb05bd58 ffff8800bb05bd08 000000000000a0a0 000000003f441940 0000000000000007 Call Trace: [<ffffffff81005306>] dump_trace+0x86/0x330 [<ffffffff81005644>] show_stack_log_lvl+0x94/0x170 [<ffffffff81006d21>] show_stack+0x21/0x50 [<ffffffff81605f07>] dump_stack+0x41/0x51 [<ffffffff8132c7a0>] kobject_add+0xa0/0xb0 [<ffffffff8130aee1>] blk_mq_register_hctx+0x91/0xb0 [<ffffffff8130b82e>] blk_mq_sysfs_register+0x3e/0x60 [<ffffffff81309298>] blk_mq_queue_reinit_notify+0xf8/0x190 [<ffffffff8107cfdc>] notifier_call_chain+0x4c/0x70 [<ffffffff8105fd23>] cpu_notify+0x23/0x50 [<ffffffff81060037>] _cpu_up+0x157/0x170 [<ffffffff810600d9>] cpu_up+0x89/0xb0 [<ffffffff815fa5b5>] cpu_subsys_online+0x35/0x80 [<ffffffff814323cd>] device_online+0x5d/0xa0 [<ffffffff81432485>] online_store+0x75/0x80 [<ffffffff81236a5a>] kernfs_fop_write+0xda/0x150 [<ffffffff811c5532>] vfs_write+0xb2/0x1f0 [<ffffffff811c5f42>] SyS_write+0x42/0xb0 [<ffffffff8160c4ed>] system_call_fastpath+0x16/0x1b [<00007f0132fb24e0>] 0x7f0132fb24e0 This is indeed because of an uninitialized kobject for blk_mq_ctx. The blk_mq_ctx kobjects are initialized in blk_mq_sysfs_init(), but it goes loop over hctx_for_each_ctx(), i.e. it initializes only for online CPUs. Thus, when a CPU is hotplugged, the ctx for the newly onlined CPU is registered without initialization. This patch fixes the issue by initializing the all ctx kobjects belonging to each queue. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=908794 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Bart Van Assche	3a6d400572	blk-mq: Fix a race between bt_clear_tag() and bt_get() commit `c38d185d4a` upstream. What we need is the following two guarantees: * Any thread that observes the effect of the test_and_set_bit() by __bt_get_word() also observes the preceding addition of 'current' to the appropriate wait list. This is guaranteed by the semantics of the spin_unlock() operation performed by prepare_and_wait(). Hence the conversion of test_and_set_bit_lock() into test_and_set_bit(). * The wait lists are examined by bt_clear() after the tag bit has been cleared. clear_bit_unlock() guarantees that any thread that observes that the bit has been cleared also observes the store operations preceding clear_bit_unlock(). However, clear_bit_unlock() does not prevent that the wait lists are examined before that the tag bit is cleared. Hence the addition of a memory barrier between clear_bit() and the wait list examination. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Robert Elliott <elliott@hp.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Bart Van Assche	d04e14ab47	blk-mq: Avoid that __bt_get_word() wraps multiple times commit `9e98e9d7cf` upstream. If __bt_get_word() is called with last_tag != 0, if the first find_next_zero_bit() fails, if after wrap-around the test_and_set_bit() call fails and find_next_zero_bit() succeeds, if the next test_and_set_bit() call fails and subsequently find_next_zero_bit() does not find a zero bit, then another wrap-around will occur. Avoid this by introducing an additional local variable. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Robert Elliott <elliott@hp.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Bart Van Assche	b041392d4f	blk-mq: Fix a use-after-free commit `45a9c9d909` upstream. blk-mq users are allowed to free the memory request_queue.tag_set points at after blk_cleanup_queue() has finished but before blk_release_queue() has started. This can happen e.g. in the SCSI core. The SCSI core namely embeds the tag_set structure in a SCSI host structure. The SCSI host structure is freed by scsi_host_dev_release(). This function is called after blk_cleanup_queue() finished but can be called before blk_release_queue(). This means that it is not safe to access request_queue.tag_set from inside blk_release_queue(). Hence remove the blk_sync_queue() call from blk_release_queue(). This call is not necessary - outstanding requests must have finished before blk_release_queue() is called. Additionally, move the blk_mq_free_queue() call from blk_release_queue() to blk_cleanup_queue() to avoid that struct request_queue.tag_set gets accessed after it has been freed. This patch avoids that the following kernel oops can be triggered when deleting a SCSI host for which scsi-mq was enabled: Call Trace: [<ffffffff8109a7c4>] lock_acquire+0xc4/0x270 [<ffffffff814ce111>] mutex_lock_nested+0x61/0x380 [<ffffffff812575f0>] blk_mq_free_queue+0x30/0x180 [<ffffffff8124d654>] blk_release_queue+0x84/0xd0 [<ffffffff8126c29b>] kobject_cleanup+0x7b/0x1a0 [<ffffffff8126c140>] kobject_put+0x30/0x70 [<ffffffff81245895>] blk_put_queue+0x15/0x20 [<ffffffff8125c409>] disk_release+0x99/0xd0 [<ffffffff8133d056>] device_release+0x36/0xb0 [<ffffffff8126c29b>] kobject_cleanup+0x7b/0x1a0 [<ffffffff8126c140>] kobject_put+0x30/0x70 [<ffffffff8125a78a>] put_disk+0x1a/0x20 [<ffffffff811d4cb5>] __blkdev_put+0x135/0x1b0 [<ffffffff811d56a0>] blkdev_put+0x50/0x160 [<ffffffff81199eb4>] kill_block_super+0x44/0x70 [<ffffffff8119a2a4>] deactivate_locked_super+0x44/0x60 [<ffffffff8119a87e>] deactivate_super+0x4e/0x70 [<ffffffff811b9833>] cleanup_mnt+0x43/0x90 [<ffffffff811b98d2>] __cleanup_mnt+0x12/0x20 [<ffffffff8107252c>] task_work_run+0xac/0xe0 [<ffffffff81002c01>] do_notify_resume+0x61/0xa0 [<ffffffff814d2c58>] int_signal+0x12/0x17 Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Robert Elliott <elliott@hp.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Jens Axboe	00de3a6421	blk-mq: use 'nr_cpu_ids' as highest CPU ID count for hwq <-> cpu map commit `a33c1ba291` upstream. We currently use num_possible_cpus(), but that breaks on sparc64 where the CPU ID space is discontig. Use nr_cpu_ids as the highest CPU ID instead, so we don't end up reading from invalid memory. Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Joerg Roedel	8c6aa9c5b0	iommu/vt-d: Fix dmar_domain leak in iommu_attach_device commit `62c22167dd` upstream. Since commit `1196c2f` a domain is only destroyed in the notifier path if it is hot-unplugged. This caused a domain leakage in iommu_attach_device when a driver was unbound from the device and bound to VFIO. In this case the device is attached to a new domain and unlinked from the old domain. At this point nothing points to the old domain anymore and its memory is leaked. Fix this by explicitly freeing the old domain in iommu_attach_domain. Fixes: `1196c2f` (iommu/vt-d: Fix dmar_domain leak in iommu_attach_device) Tested-by: Jerry Hoemann <jerry.hoemann@hp.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Jiang Liu	e7a4ae85b5	iommu/vt-d: Fix an off-by-one bug in __domain_mapping() commit `cc4f14aa17` upstream. There's an off-by-one bug in function __domain_mapping(), which may trigger the BUG_ON(nr_pages < lvl_pages) when (nr_pages + 1) & superpage_mask == 0 The issue was introduced by commit `9051aa0268` "intel-iommu: Combine domain_pfn_mapping() and domain_sg_mapping()", which sets sg_res to "nr_pages + 1" to avoid some of the 'sg_res==0' code paths. It's safe to remove extra "+1" because sg_res is only used to calculate page size now. Reported-And-Tested-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Acked-By: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:48 -08:00
Richard Weinberger	49b9926147	UBI: Fix double free after do_sync_erase() commit `aa5ad3b6eb` upstream. If the erase worker is unable to erase a PEB it will free the ubi_wl_entry itself. The failing ubi_wl_entry must not free()'d again after do_sync_erase() returns. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Richard Weinberger	85ce61f0ca	UBI: Fix invalid vfree() commit `f38aed975c` upstream. The logic of vfree()'ing vol->upd_buf is tied to vol->updating. In ubi_start_update() vol->updating is set long before vmalloc()'ing vol->upd_buf. If we encounter a write failure in ubi_start_update() before vmalloc() the UBI device release function will try to vfree() vol->upd_buf because vol->updating is set. Fix this by allocating vol->upd_buf directly after setting vol->updating. Fixes: [ 31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, volume is damaged [ 31.559340] ------------[ cut here ]------------ [ 31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 __vunmap+0xe3/0x110() [ 31.559344] Trying to vfree() nonexistent vm area (ffffc90001f2b000) [ 31.559345] Modules linked in: [ 31.565620] 0000000000000bba ffff88002a0cbdb0 ffffffff818f0497 ffff88003b9ba148 [ 31.566347] ffff88002a0cbde0 ffffffff8156f515 ffff88003b9ba148 0000000000000bba [ 31.567073] 0000000000000000 0000000000000000 ffff88002a0cbe88 ffffffff8156c10a [ 31.567793] Call Trace: [ 31.568034] [<ffffffff818f0497>] dump_stack+0x4e/0x7a [ 31.568510] [<ffffffff8156f515>] ubi_io_write_vid_hdr+0x155/0x160 [ 31.569084] [<ffffffff8156c10a>] ubi_eba_write_leb+0x23a/0x870 [ 31.569628] [<ffffffff81569b36>] vol_cdev_write+0x226/0x380 [ 31.570155] [<ffffffff81179265>] vfs_write+0xb5/0x1f0 [ 31.570627] [<ffffffff81179f8a>] SyS_pwrite64+0x6a/0xa0 [ 31.571123] [<ffffffff818fde12>] system_call_fastpath+0x16/0x1b Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Tony Lindgren	c7ba2d7949	pstore-ram: Allow optional mapping with pgprot_noncached commit `027bc8b082` upstream. On some ARMs the memory can be mapped pgprot_noncached() and still be working for atomic operations. As pointed out by Colin Cross <ccross@android.com>, in some cases you do want to use pgprot_noncached() if the SoC supports it to see a debug printk just before a write hanging the system. On ARMs, the atomic operations on strongly ordered memory are implementation defined. So let's provide an optional kernel parameter for configuring pgprot_noncached(), and use pgprot_writecombine() by default. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robherring2@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Rob Herring	dedfc0ec11	pstore-ram: Fix hangs by using write-combine mappings commit `7ae9cb8193` upstream. Currently trying to use pstore on at least ARMs can hang as we're mapping the peristent RAM with pgprot_noncached(). On ARMs, pgprot_noncached() will actually make the memory strongly ordered, and as the atomic operations pstore uses are implementation defined for strongly ordered memory, they may not work. So basically atomic operations have undefined behavior on ARM for device or strongly ordered memory types. Let's fix the issue by using write-combine variants for mappings. This corresponds to normal, non-cacheable memory on ARM. For many other architectures, this change does not change the mapping type as by default we have: #define pgprot_writecombine pgprot_noncached The reason why pgprot_noncached() was originaly used for pstore is because Colin Cross <ccross@android.com> had observed lost debug prints right before a device hanging write operation on some systems. For the platforms supporting pgprot_noncached(), we can add a an optional configuration option to support that. But let's get pstore working first before adding new features. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: linux-kernel@vger.kernel.org Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rob Herring <rob.herring@calxeda.com> [tony@atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Hante Meuleman	f2b80ae7e7	brcmfmac: Fix ifidx for rx data by msgbuf. commit `94a612086f` upstream. The ifidx provided by FW needs to be offsetted when receiving data packets. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Myron Stowe	efdb9b956a	PCI: Restore detection of read-only BARs commit `36e8164882` upstream. Commit `6ac665c63d` ("PCI: rewrite PCI BAR reading code") masked off low-order bits from 'l', but not from 'sz'. Both are passed to pci_size(), which compares 'base == maxbase' to check for read-only BARs. The masking of 'l' means that comparison will never be 'true', so the check for read-only BARs no longer works. Resolve this by also masking off the low-order bits of 'sz' before passing it into pci_size() as 'maxbase'. With this change, pci_size() will once again catch the problems that have been encountered to date: - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is disabled, this BAR is read-only and read as 0x00000008 [1] - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1] - Intel Sandy Bridge - Thermal Management Controller [8086:0103]; BAR 0 returning 0xfed98004 [2] - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0]; Bar 0 returning 0x00001a [3] Link: [1] https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9 ("PCI: probing read-only BARs" (pre-git)) Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331 Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991 Reported-by: William Unruh <unruh@physics.ubc.ca> Reported-by: Martin Lucina <martin@lucina.net> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Johan Hedberg	2b81cffdf4	Bluetooth: Fix accepting connections when not using mgmt commit `6a8fc95c87` upstream. When connectable mode is enabled (page scan on) through some non-mgmt method the HCI_CONNECTABLE flag will not be set. For backwards compatibility with user space versions not using mgmt we should not require HCI_CONNECTABLE to be set if HCI_MGMT is not set. Reported-by: Pali Rohár <pali.rohar@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Marcel Holtmann	ad976d1c00	Bluetooth: Fix controller configuration with HCI_QUIRK_INVALID_BDADDR commit `8bfe8442ff` upstream. When controllers set the HCI_QUIRK_INVALID_BDADDR flag, it is required by userspace to program a valid public Bluetooth device address into the controller before it can be used. After successful address configuration, the internal state changes and the controller runs the complete initialization procedure. However one small difference is that this is no longer the HCI_SETUP stage. The HCI_SETUP stage is only valid during initial controller setup. In this case the stack runs the initialization as part of the HCI_CONFIG stage. The controller version information, default name and supported commands are only stored during HCI_SETUP. While these information are static, they are not read initially when HCI_QUIRK_INVALID_BDADDR is set. So when running in HCI_CONFIG state, these information need to be updated as well. This especially impacts Bluetooth 4.1 and later controllers using extended feature pages and second event mask page. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Marcel Holtmann	0de8cd646b	Bluetooth: Clear LE white list when resetting controller commit `a4d5504d5c` upstream. The internal representation of the LE white list needs to be cleared when receiving a successful HCI_Reset command. A reset of the controller is expected to start with an empty LE white list. When the LE white list is not cleared on controller reset, the passive background scanning might skip programming the remote devices. Only changes to the LE white list are programmed when passive background is started. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Johan Hedberg	18368232e6	Bluetooth: Fix check for direct advertising commit `0b1db38ca2` upstream. These days we allow simultaneous LE scanning and advertising. Checking for whether advertising is enabled or not is therefore not a reliable way to determine whether directed advertising was used to trigger the connection creation. The appropriate place to check (instead of the hdev context) is the connection role that's stored in the hci_conn. This patch fixes such a check in le_conn_timeout() which could otherwise lead to incorrect HCI commands being sent. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Johan Hedberg	f3d02a6c4f	Bluetooth: Fix LE connection timeout deadlock commit `980ffc0a2c` upstream. The le_conn_timeout() may call hci_le_conn_failed() which in turn may call hci_conn_del(). Trying to use the _sync variant for cancelling the conn timeout from hci_conn_del() could therefore result in a deadlock. This patch converts hci_conn_del() to use the non-sync variant so the deadlock is not possible. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Alexander Aring	bff7d3f06a	Bluetooth: 6lowpan: fix skb_unshare behaviour commit `b0c42cd7b2` upstream. This patch reverts commit: `a7807d73` ("Bluetooth: 6lowpan: Avoid memory leak if memory allocation fails") which was wrong suggested by Alexander Aring. The function skb_unshare run also kfree_skb on failure. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:47 -08:00
Dmitry Tunin	767d883679	Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device commit `3bb30a7cdf` upstream. Add support for Bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. This Bluetooth module requires loading patch and sysconfig by ath3k driver. T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3408 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Richard Guy Briggs	ad233513d9	powerpc: add little endian flag to syscall_get_arch() commit `63f13448d8` upstream. Since both ppc and ppc64 have LE variants which are now reported by uname, add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC64LE variant. Without this, perf trace and auditctl fail. Mainline kernel reports ppc64le (per `a058801`) but there is no matching AUDIT_ARCH_PPC64LE. Since 32-bit PPC LE is not supported by audit, don't advertise it in AUDIT_ARCH_PPC* variants. See: https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html https://www.redhat.com/archives/linux-audit/2014-December/msg00004.html Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
sukadev@linux.vnet.ibm.com	5c7308f540	powerpc/perf/hv-24x7: Use per-cpu page buffer commit `f34b6c72c3` upstream. The 24x7 counters are continuously running and not updated on an interrupt. So we record the event counts when stopping the event or deleting it. But to "read" a single counter in 24x7, we allocate a page and pass it into the hypervisor (The HV returns the page full of counters from which we extract the specific counter for this event). We allocate a page using GFP_USER and when deleting the event, we end up with the following warning because we are blocking in interrupt context. [ 698.641709] BUG: scheduling while atomic: swapper/0/0/0x10010000 We could use GFP_ATOMIC but that could result in failures. Pre-allocate a buffer so we don't have to allocate in interrupt context. Further as Michael Ellerman suggested, use Per-CPU buffer so we only need to allocate once per CPU. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Paul Mackerras	27f1f15000	powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode commit `8117ac6a6c` upstream. Currently, when going idle, we set the flag indicating that we are in nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap (or sleep or rvwinkle) instruction, all with the MMU on. This is bad for two reasons: (a) the architecture specifies that those instructions must be executed with the MMU off, and in fact with only the SF, HV, ME and possibly RI bits set, and (b) this introduces a race, because as soon as we set the flag, another thread can switch the MMU to a guest context. If the race is lost, this thread will typically start looping on relocation-on ISIs at 0xc...4400. This fixes it by setting the MSR as required by the architecture before setting the flag or executing the nap/sleep/rvwinkle instruction. [ shreyas@linux.vnet.ibm.com: Edited to handle LE ] Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Mahesh Salgaonkar	6a7c1a47ac	powerpc/book3s: Fix partial invalidation of TLBs in MCE code. commit `682e77c861` upstream. The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting in partial invalidation of TLBs which is not right. This patch fixes that by passing IS=0xc00 to invalidate whole TLB for successful recovery from TLB and ERAT errors. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Anton Blanchard	4b43ad93ef	powerpc: Fix bad NULL pointer check in udbg_uart_getc_poll() commit `cd32e2dcc9` upstream. We have some code in udbg_uart_getc_poll() that tries to protect against a NULL udbg_uart_in, but gets it all wrong. Found with the LLVM static analyzer (scan-build). Fixes: `309257484c` ("powerpc: Cleanup udbg_16550 and add support for LPC PIO-only UARTs") Signed-off-by: Anton Blanchard <anton@samba.org> [mpe: Add some newlines for readability while we're here] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Steven Rostedt (Red Hat)	a7c3ff297f	ktest: Fix make_min_config to handle new assign_configs call commit `9972fc0b85` upstream. Commit `6071c22e17` "ktest: Rewrite the config-bisect to actually work" fixed the config-bisect to work nicely but in doing so it broke make_min_config by changing the way assign_configs works. The assign_configs function now adds the config to the hash even if it is disabled, but changes the hash value to be that of the line "# CONFIG_FOO is not set". Unfortunately, the make_min_config test only checks to see if the config is removed. It now needs to check if the config is in the hash and not set to be disabled. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Andrew Jackson	3b4a99e9a2	ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap commit `3475c3d034` upstream. Flush the FIFOs when the stream is prepared for use. This avoids an inadvertent swapping of the left/right channels if the FIFOs are not empty at startup. Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Peter Rosin	e41e3bb778	ASoC: pcm512x: Trigger auto-increment of register addresses on i2c commit `681a195603` upstream. When the codec is connected using i2c, it will only auto-increment register addresses if msb (0x80) of the register address byte is set. [Fixes cache sync if multiple adjacent registers are updated -- broonie] Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Jyri Sarha	c50176d643	ASoC: tlv320aic31xx: Fix off by one error in the loop stucture. commit `bbc686b346` upstream. Fix off by one read beyond the end of a table. Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Jarkko Nikula	877fd33fb3	ASoC: max98090: Fix ill-defined sidetone route commit `48826ee590` upstream. Commit `5fe5b767dc` ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") revealed ill-defined control in a route between "STENL Mux" and DACs in max98090.c: max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACL max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACL max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACL max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACR max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACR max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACR Since there is no control between "STENL Mux" and DACs the control name must be NULL not "NULL". Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Lars-Peter Clausen	bc87f9ec3b	ASoC: sigmadsp: Refuse to load firmware files with a non-supported version commit `50c0f21b42` upstream. Make sure to check the version field of the firmware header to make sure to not accidentally try to parse a firmware file with a different layout. Trying to do so can result in loading invalid firmware code to the device. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:46 -08:00
Takashi Iwai	d4527a1915	ASoC: eukrea-tlv320: Fix of_node_put() call with uninitialized object commit `077661b6ed` upstream. The of_node_put() call in eukrea_tlv320_probe() may take an uninitialized pointer, as compiler spotted out: sound/soc/fsl/eukrea-tlv320.c:221:14: warning: 'ssi_np' may be used uninitialized in this function [-Wuninitialized] This patch adds the proper NULL initializations as a fix. (codec_np is also NULL initialized just for consistency.) Fixes: `66f232908d` ('ASoC: eukrea-tlv320: Add DT support') Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Felix Fietkau	26487e2ed0	ath5k: fix hardware queue index assignment commit `9e4982f6a5` upstream. Like with ath9k, ath5k queues also need to be ordered by priority. queue_info->tqi_subtype already contains the correct index, so use it instead of relying on the order of ath5k_hw_setup_tx_queue calls. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Emmanuel Grumbach	fd6fc293ef	iwlwifi: add new device IDs for 3165 commit `55fd1ce820` upstream. A few device IDs were added, reflect this change in the driver. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Emmanuel Grumbach	3ce710b7e6	iwlwifi: mvm: update values for Smart Fifo commit `b4c82adcba` upstream. Interoperability issues were identified and root caused to the Smart Fifo watermarks. These issues arose with NetGear R7000. Fix this. Fixes: `1f3b0ff8ec` ("iwlwifi: mvm: Add Smart FIFO support") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Emmanuel Grumbach	e7fd25db83	iwlwifi: dvm: fix flush support for old firmware commit `5a12a07e44` upstream. Since the commit below, iwldvm sends the FLUSH command to the firmware. All the devices that use iwldvm have a firmware that expects the _v3 version of this command, besides 5150. 5150's latest available firmware still expects a _v2 version of the FLUSH command. This means that since the commit below, we had a mismatch for this specific device only. This mismatch led to the NMI below: Loaded firmware version: 8.24.2.2 Start IWL Error Log Dump: Status: 0x0000004C, count: 5 0x00000004 \| NMI_INTERRUPT_WDG 0x000006F4 \| uPc 0x000005BA \| branchlink1 0x000006F8 \| branchlink2 0x000008C2 \| interruptlink1 0x00005B02 \| interruptlink2 0x00000002 \| data1 0x07030000 \| data2 0x00000068 \| line 0x3E80510C \| beacon time 0x728A0EF4 \| tsf low 0x0000002A \| tsf hi 0x00000000 \| time gp1 0x01BDC977 \| time gp2 0x00000000 \| time gp3 0x00010818 \| uCode version 0x00000000 \| hw version 0x00484704 \| board version 0x00000002 \| hcmd 0x2FF23080 \| isr0 0x0103E000 \| isr1 0x0000001A \| isr2 0x1443FCC3 \| isr3 0x11800112 \| isr4 0x00000068 \| isr_pref 0x000000D4 \| wait_event 0x00000000 \| l2p_control 0x00000007 \| l2p_duration 0x00103040 \| l2p_mhvalid 0x00000007 \| l2p_addr_match 0x00000000 \| lmpm_pmg_sel 0x00000000 \| timestamp 0x00000200 \| flow_handler This was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=88961 Fixes: `a0855054e5` ("iwlwifi: dvm: drop non VO frames when flushing") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stefano Stabellini	2129c43d41	swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single commit `2c3fc8d26d` upstream. Need to pass the pointer within the swiotlb internal buffer to the swiotlb library, that in the case of xen_unmap_single is dev_addr, not paddr. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stefano Stabellini	2a8ba6426e	swiotlb-xen: call xen_dma_sync_single_for_device when appropriate commit `9490c6c67e` upstream. In xen_swiotlb_sync_single we always call xen_dma_sync_single_for_cpu, even when we should call xen_dma_sync_single_for_device. Fix that. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stefano Stabellini	e725243957	swiotlb-xen: remove BUG_ON in xen_bus_to_phys commit `c884227eaa` upstream. On x86 truncation cannot occur because config XEN depends on X86_64 \|\| (X86_32 && X86_PAE). On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma operation involves foreign grants. However in that case the physical address returned by xen_bus_to_phys is actually invalid (there is no mfn to pfn tracking for foreign grants on ARM) and it is not used. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stefano Stabellini	46b29c31e9	swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu commit `d6883e6f32` upstream. xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t handle as argument, not a physical address. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stephane Grosjean	7bb9bcde9c	can: peak_usb: fix memset() usage commit `dc50ddcd4c` upstream. This patchs fixes a misplaced call to memset() that fills the request buffer with 0. The problem was with sending PCAN_USBPRO_REQ_FCT requests, the content set by the caller was thus lost. With this patch, the memory area is zeroed only when requesting info from the device. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Stephane Grosjean	2eecaeb538	can: peak_usb: fix cleanup sequence order in case of error during init commit `af35d0f1cc` upstream. This patch sets the correct reverse sequence order to the instructions set to run, when any failure occurs during the initialization steps. It also adds the missing unregistration call of the can device if the failure appears after having been registered. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Felix Fietkau	0d3b34950b	ath9k: fix BE/BK queue order commit `78063d81d3` upstream. Hardware queues are ordered by priority. Use queue index 0 for BK, which has lower priority than BE. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:45 -08:00
Felix Fietkau	4ad54f0a78	ath9k_hw: fix hardware queue allocation commit `ad8fdccf9c` upstream. The driver passes the desired hardware queue index for a WMM data queue in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which instead relied on the order in which the function is called. Reported-by: Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Xue jiufei	234b25a3ac	ocfs2: fix the wrong directory passed to ocfs2_lookup_ino_from_name() when link file commit `53dc20b9a3` upstream. In ocfs2_link(), the parent directory inode passed to function ocfs2_lookup_ino_from_name() is wrong. Parameter dir is the parent of new_dentry not old_dentry. We should get old_dir from old_dentry and lookup old_dentry in old_dir in case another node remove the old dentry. With this change, hard linking works again, when paths are relative with at least one subdirectory. This is how the problem was reproducable: # mkdir a # mkdir b # touch a/test # ln a/test b/test ln: failed to create hard link `b/test' => `a/test': No such file or directory However when creating links in the same dir, it worked well. Now the link gets created. Fixes: `0e048316ff` ("ocfs2: check existence of old dentry in ocfs2_link()") Signed-off-by: joyce.xue <xuejiufei@huawei.com> Reported-by: Szabo Aron - UBIT <aron@ubit.hu> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Tested-by: Aron Szabo <aron@ubit.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Junxiao Bi	8f0613ea55	ocfs2: fix journal commit deadlock commit `136f49b917` upstream. For buffer write, page lock will be got in write_begin and released in write_end, in ocfs2_write_end_nolock(), before it unlock the page in ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask for the read lock of journal->j_trans_barrier. Holding page lock and ask for journal->j_trans_barrier breaks the locking order. This will cause a deadlock with journal commit threads, ocfs2cmt will get write lock of journal->j_trans_barrier first, then it wakes up kjournald2 to do the commit work, at last it waits until done. To commit journal, kjournald2 needs flushing data first, it needs get the cache page lock. Since some ocfs2 cluster locks are holding by write process, this deadlock may hung the whole cluster. unlock pages before ocfs2_run_deallocs() can fix the locking order, also put unlock before ocfs2_commit_trans() to make page lock is unlocked before j_trans_barrier to preserve unlocking order. Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Arnaud Ebalard	c75b302ac9	drivers/rtc/rtc-isl12057.c: fix masking of register values commit `5945b28803` upstream. When Intersil ISL12057 support was added by commit `70e123373c` ("rtc: Add support for Intersil ISL12057 I2C RTC chip"), two masks for time registers values imported from the device were either wrong or omitted, leading to additional bits from those registers to impact read values: - mask for hour register value when reading it in AM/PM mode. As AM/PM mode is not the usual mode used by the driver, this error would only have an impact on an externally configured RTC hour later read by the driver. - mask for month value. The lack of masking would provide an erroneous value if century bit is set. This patch fixes those two masks. Fixes: `70e123373c` ("rtc: Add support for Intersil ISL12057 I2C RTC chip") Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Peter Huewe <peter.huewe@infineon.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Grant Likely <grant.likely@linaro.org> Acked-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Johan Hovold	e376bf209a	rtc: omap: fix missing wakealarm attribute commit `7ecd9a3f06` upstream. The platform device must be registered as wakeup capable before registering the class device, or the wakealarm attribute will not be created. Also make sure to unregister the wakeup source on probe errors. Fixes: `1d2e2b65d0` ("rtc: omap: restore back (hard-code) wakeup support") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Felipe Balbi <balbi@ti.com> Tested-by: Felipe Balbi <balbi@ti.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Tony Lindgren <tony@atomide.com> Cc: Benot Cousson <bcousson@baylibre.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Keerthy J <j-keerthy@ti.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Johan Hovold	8b31123c85	rtc: omap: fix clock-source configuration commit `44c63a570a` upstream. This series fixes a few issues with the omap rtc-driver, cleans up a bit, adds device abstraction, and finally adds support for the PMIC control feature found in some revisions of this RTC IP block. Ultimately, this allows for powering off the Beaglebone and waking it up again on RTC alarms. This patch (of 20): Make sure not to reset the clock-source configuration when enabling the 32kHz clock mux. Until the clock source can be configured through device tree we must not overwrite settings made by the bootloader (e.g. clock-source selection). Fixes: `cd914bba03` ("drivers/rtc/rtc-omap.c: add support for enabling 32khz clock") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Felipe Balbi <balbi@ti.com> Tested-by: Felipe Balbi <balbi@ti.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Tony Lindgren <tony@atomide.com> Cc: Benot Cousson <bcousson@baylibre.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Keerthy J <j-keerthy@ti.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Guo Zeng	7d9c386fdd	drivers/rtc/rtc-sirfsoc.c: move hardware initilization earlier in probe commit `0e95325525` upstream. Move rtc register to be later than hardware initialization. The reason is that devm_rtc_device_register() will do read_time() which is a callback accessing hardware. This sometimes causes a hang in the hardware related callback. Signed-off-by: Guo Zeng <guo.zeng@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-16 06:59:44 -08:00
Greg Kroah-Hartman	e609d3fc31	Linux 3.18.2	2015-01-08 10:30:41 -08:00
Filipe Manana	3c6babf55d	Btrfs: fix fs corruption on transaction abort if device supports discard commit `678886bdc6` upstream. When we abort a transaction we iterate over all the ranges marked as dirty in fs_info->freed_extents[0] and fs_info->freed_extents[1], clear them from those trees, add them back (unpin) to the free space caches and, if the fs was mounted with "-o discard", perform a discard on those regions. Also, after adding the regions to the free space caches, a fitrim ioctl call can see those ranges in a block group's free space cache and perform a discard on the ranges, so the same issue can happen without "-o discard" as well. This causes corruption, affecting one or multiple btree nodes (in the worst case leaving the fs unmountable) because some of those ranges (the ones in the fs_info->pinned_extents tree) correspond to btree nodes/leafs that are referred by the last committed super block - breaking the rule that anything that was committed by a transaction is untouched until the next transaction commits successfully. I ran into this while running in a loop (for several hours) the fstest that I recently submitted: [PATCH] fstests: add btrfs test to stress chunk allocation/removal and fstrim The corruption always happened when a transaction aborted and then fsck complained like this: _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent * fsck.btrfs output * Check tree block failed, want=94945280, have=0 Check tree block failed, want=94945280, have=0 Check tree block failed, want=94945280, have=0 Check tree block failed, want=94945280, have=0 Check tree block failed, want=94945280, have=0 read block failed check_tree_block Couldn't open file system In this case 94945280 corresponded to the root of a tree. Using frace what I observed was the following sequence of steps happened: 1) transaction N started, fs_info->pinned_extents pointed to fs_info->freed_extents[0]; 2) node/eb 94945280 is created; 3) eb is persisted to disk; 4) transaction N commit starts, fs_info->pinned_extents now points to fs_info->freed_extents[1], and transaction N completes; 5) transaction N + 1 starts; 6) eb is COWed, and btrfs_free_tree_block() called for this eb; 7) eb range (94945280 to 94945280 + 16Kb) is added to fs_info->pinned_extents (fs_info->freed_extents[1]); 8) Something goes wrong in transaction N + 1, like hitting ENOSPC for example, and the transaction is aborted, turning the fs into readonly mode. The stack trace I got for example: [112065.253935] [<ffffffff8140c7b6>] dump_stack+0x4d/0x66 [112065.254271] [<ffffffff81042984>] warn_slowpath_common+0x7f/0x98 [112065.254567] [<ffffffffa0325990>] ? __btrfs_abort_transaction+0x50/0x10b [btrfs] [112065.261674] [<ffffffff810429e5>] warn_slowpath_fmt+0x48/0x50 [112065.261922] [<ffffffffa032949e>] ? btrfs_free_path+0x26/0x29 [btrfs] [112065.262211] [<ffffffffa0325990>] __btrfs_abort_transaction+0x50/0x10b [btrfs] [112065.262545] [<ffffffffa036b1d6>] btrfs_remove_chunk+0x537/0x58b [btrfs] [112065.262771] [<ffffffffa033840f>] btrfs_delete_unused_bgs+0x1de/0x21b [btrfs] [112065.263105] [<ffffffffa0343106>] cleaner_kthread+0x100/0x12f [btrfs] (...) [112065.264493] ---[ end trace dd7903a975a31a08 ]--- [112065.264673] BTRFS: error (device sdc) in btrfs_remove_chunk:2625: errno=-28 No space left [112065.264997] BTRFS info (device sdc): forced readonly 9) The clear kthread sees that the BTRFS_FS_STATE_ERROR bit is set in fs_info->fs_state and calls btrfs_cleanup_transaction(), which in turn calls btrfs_destroy_pinned_extent(); 10) Then btrfs_destroy_pinned_extent() iterates over all the ranges marked as dirty in fs_info->freed_extents[], and for each one it calls discard, if the fs was mounted with "-o discard", and adds the range to the free space cache of the respective block group; 11) btrfs_trim_block_group(), invoked from the fitrim ioctl code path, sees the free space entries and performs a discard; 12) After an umount and mount (or fsck), our eb's location on disk was full of zeroes, and it should have been untouched, because it was marked as dirty in the fs_info->pinned_extents tree, and therefore used by the trees that the last committed superblock points to. Fix this by not performing a discard and not adding the ranges to the free space caches - it's useless from this point since the fs is now in readonly mode and we won't write free space caches to disk anymore (otherwise we would leak space) nor any new superblock. By not adding the ranges to the free space caches, it prevents other code paths from allocating that space and write to it as well, therefore being safer and simpler. This isn't a new problem, as it's been present since 2011 (git commit `acce952b02`). Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:30 -08:00
Josef Bacik	9d15399d7a	Btrfs: make sure logged extents complete in the current transaction V3 commit `50d9aa99bd` upstream. Liu Bo pointed out that my previous fix would lose the generation update in the scenario I described. It is actually much worse than that, we could lose the entire extent if we lose power right after the transaction commits. Consider the following write extent 0-4k log extent in log tree commit transaction < power fail happens here ordered extent completes We would lose the 0-4k extent because it hasn't updated the actual fs tree, and the transaction commit will reset the log so it isn't replayed. If we lose power before the transaction commit we are save, otherwise we are not. Fix this by keeping track of all extents we logged in this transaction. Then when we go to commit the transaction make sure we wait for all of those ordered extents to complete before proceeding. This will make sure that if we lose power after the transaction commit we still have our data. This also fixes the problem of the improperly updated extent generation. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:30 -08:00
Josef Bacik	115f9146f7	Btrfs: do not move em to modified list when unpinning commit `a28046956c` upstream. We use the modified list to keep track of which extents have been modified so we know which ones are candidates for logging at fsync() time. Newly modified extents are added to the list at modification time, around the same time the ordered extent is created. We do this so that we don't have to wait for ordered extents to complete before we know what we need to log. The problem is when something like this happens log extent 0-4k on inode 1 copy csum for 0-4k from ordered extent into log sync log commit transaction log some other extent on inode 1 ordered extent for 0-4k completes and adds itself onto modified list again log changed extents see ordered extent for 0-4k has already been logged at this point we assume the csum has been copied sync log crash On replay we will see the extent 0-4k in the log, drop the original 0-4k extent which is the same one that we are replaying which also drops the csum, and then we won't find the csum in the log for that bytenr. This of course causes us to have errors about not having csums for certain ranges of our inode. So remove the modified list manipulation in unpin_extent_cache, any modified extents should have been added well before now, and we don't want them re-logged. This fixes my test that I could reliably reproduce this problem with. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:30 -08:00
David Sterba	37ea7a1f6b	btrfs: fix wrong accounting of raid1 data profile in statfs commit `0d95c1bec9` upstream. The sizes that are obtained from space infos are in raw units and have to be adjusted according to the raid factor. This was missing for f_bavail and df reported doubled size for raid1. Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Fixes: `ba7b6e62f4` ("btrfs: adjust statfs calculations according to raid profiles") Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:30 -08:00
Josef Bacik	d77fe802ae	Btrfs: make sure we wait on logged extents when fsycning two subvols commit `9dba8cf128` upstream. If we have two fsync()'s race on different subvols one will do all of its work to get into the log_tree, wait on it's outstanding IO, and then allow the log_tree to finish it's commit. The problem is we were just free'ing that subvols logged extents instead of waiting on them, so whoever lost the race wouldn't really have their data on disk. Fix this by waiting properly instead of freeing the logged extents. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:29 -08:00
Michael Halcrow	d7fad547c3	eCryptfs: Remove buggy and unnecessary write in file name decode routine commit `942080643b` upstream. Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the end of the allocated buffer during encrypted filename decoding. This fix corrects the issue by getting rid of the unnecessary 0 write when the current bit offset is 2. Signed-off-by: Michael Halcrow <mhalcrow@google.com> Reported-by: Dmitry Chernenkov <dmitryc@google.com> Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:29 -08:00
Tyler Hicks	bbeb37ea15	eCryptfs: Force RO mount when encrypted view is enabled commit `332b122d39` upstream. The ecryptfs_encrypted_view mount option greatly changes the functionality of an eCryptfs mount. Instead of encrypting and decrypting lower files, it provides a unified view of the encrypted files in the lower filesystem. The presence of the ecryptfs_encrypted_view mount option is intended to force a read-only mount and modifying files is not supported when the feature is in use. See the following commit for more information: `e77a56d` [PATCH] eCryptfs: Encrypted passthrough This patch forces the mount to be read-only when the ecryptfs_encrypted_view mount option is specified by setting the MS_RDONLY flag on the superblock. Additionally, this patch removes some broken logic in ecryptfs_open() that attempted to prevent modifications of files when the encrypted view feature was in use. The check in ecryptfs_open() was not sufficient to prevent file modifications using system calls that do not operate on a file descriptor. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Priya Bansal <p.bansal@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:29 -08:00
Jan Kara	41ba2abbb3	udf: Check component length before reading it commit `e237ec37ec` upstream. Check that length specified in a component of a symlink fits in the input buffer we are reading. Also properly ignore component length for component types that do not use it. Otherwise we read memory after end of buffer for corrupted udf image. Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:29 -08:00
Jan Kara	53fbe4cb77	udf: Verify symlink size before loading it commit `a1d47b2629` upstream. UDF specification allows arbitrarily large symlinks. However we support only symlinks at most one block large. Check the length of the symlink so that we don't access memory beyond end of the symlink block. Reported-by: Carl Henrik Lunde <chlunde@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:29 -08:00
Jan Kara	a6a4afa5c4	udf: Verify i_size when loading inode commit `e159332b9a` upstream. Verify that inode size is sane when loading inode with data stored in ICB. Otherwise we may get confused later when working with the inode and inode size is too big. Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:28 -08:00
Jan Kara	1a927faa55	udf: Check path length when reading symlink commit `0e5cc9a40a` upstream. Symlink reading code does not check whether the resulting path fits into the page provided by the generic code. This isn't as easy as just checking the symlink size because of various encoding conversions we perform on path. So we have to check whether there is still enough space in the buffer on the fly. Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:28 -08:00
Oleg Nesterov	9cc010cac4	exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting commit `24c037ebf5` upstream. alloc_pid() does get_pid_ns() beforehand but forgets to put_pid_ns() if it fails because disable_pid_allocation() was called by the exiting child_reaper. We could simply move get_pid_ns() down to successful return, but this fix tries to be as trivial as possible. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Sterling Alexander <stalexan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:28 -08:00
Joonsoo Kim	2f4f9b92b2	mm/CMA: fix boot regression due to physical address of high_memory commit `6b101e2a3c` upstream. high_memory isn't direct mapped memory so retrieving it's physical address isn't appropriate. But, it would be useful to check physical address of highmem boundary so it's justfiable to get physical address from it. In x86, there is a validation check if CONFIG_DEBUG_VIRTUAL and it triggers following boot failure reported by Ingo. ... BUG: Int 6: CR2 00f06f53 ... Call Trace: dump_stack+0x41/0x52 early_idt_handler+0x6b/0x6b cma_declare_contiguous+0x33/0x212 dma_contiguous_reserve_area+0x31/0x4e dma_contiguous_reserve+0x11d/0x125 setup_arch+0x7b5/0xb63 start_kernel+0xb8/0x3e6 i386_start_kernel+0x79/0x7d To fix boot regression, this patch implements workaround to avoid validation check in x86 when retrieving physical address of high_memory. __pa_nodebug() used by this patch is implemented only in x86 so there is no choice but to use dirty #ifdef. [akpm@linux-foundation.org: tweak comment] Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:28 -08:00
Jan Kara	522a8162a0	ncpfs: return proper error from NCP_IOC_SETROOT ioctl commit `a682e9c28c` upstream. If some error happens in NCP_IOC_SETROOT ioctl, the appropriate error return value is then (in most cases) just overwritten before we return. This can result in reporting success to userspace although error happened. This bug was introduced by commit `2e54eb96e2` ("BKL: Remove BKL from ncpfs"). Propagate the errors correctly. Coverity id: 1226925. Fixes: `2e54eb96e2` ("BKL: Remove BKL from ncpfs") Signed-off-by: Jan Kara <jack@suse.cz> Cc: Petr Vandrovec <petr@vandrovec.name> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:28 -08:00
Rabin Vincent	fa06c84a8c	crypto: af_alg - fix backlog handling commit `7e77bdebff` upstream. If a request is backlogged, it's complete() handler will get called twice: once with -EINPROGRESS, and once with the final error code. af_alg's complete handler, unlike other users, does not handle the -EINPROGRESS but instead always completes the completion that recvmsg() is waiting on. This can lead to a return to user space while the request is still pending in the driver. If userspace closes the sockets before the requests are handled by the driver, this will lead to use-after-frees (and potential crashes) in the kernel due to the tfm having been freed. The crashes can be easily reproduced (for example) by reducing the max queue length in cryptod.c and running the following (from http://www.chronox.de/libkcapi.html) on AES-NI capable hardware: $ while true; do kcapi -x 1 -e -c '__ecb-aes-aesni' \ -k 00000000000000000000000000000000 \ -p 00000000000000000000000000000000 >/dev/null & done Signed-off-by: Rabin Vincent <rabin.vincent@axis.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:27 -08:00
Richard Guy Briggs	3d7c0c1f60	audit: restore AUDIT_LOGINUID unset ABI commit `041d7b98ff` upstream. A regression was caused by commit `780a7654ce`: audit: Make testing for a valid loginuid explicit. (which in turn attempted to fix a regression caused by `e1760bd`) When audit_krule_to_data() fills in the rules to get a listing, there was a missing clause to convert back from AUDIT_LOGINUID_SET to AUDIT_LOGINUID. This broke userspace by not returning the same information that was sent and expected. The rule: auditctl -a exit,never -F auid=-1 gives: auditctl -l LIST_RULES: exit,never f24=0 syscall=all when it should give: LIST_RULES: exit,never auid=-1 (0xffffffff) syscall=all Tag it so that it is reported the same way it was set. Create a new private flags audit_krule field (pflags) to store it that won't interact with the public one from the API. Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:27 -08:00
Paul Moore	dbe0ca090f	audit: don't attempt to lookup PIDs when changing PID filtering audit rules commit `3640dcfa4f` upstream. Commit `f1dc4867` ("audit: anchor all pid references in the initial pid namespace") introduced a find_vpid() call when adding/removing audit rules with PID/PPID filters; unfortunately this is problematic as find_vpid() only works if there is a task with the associated PID alive on the system. The following commands demonstrate a simple reproducer. # auditctl -D # auditctl -l # autrace /bin/true # auditctl -l This patch resolves the problem by simply using the PID provided by the user without any additional validation, e.g. no calls to check to see if the task/PID exists. Cc: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <pmoore@redhat.com> Acked-by: Eric Paris <eparis@redhat.com> Reviewed-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:27 -08:00
Richard Guy Briggs	1110f3504d	audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb commit `54dc77d974` upstream. Eric Paris explains: Since kauditd_send_multicast_skb() gets called in audit_log_end(), which can come from any context (aka even a sleeping context) GFP_KERNEL can't be used. Since the audit_buffer knows what context it should use, pass that down and use that. See: https://lkml.org/lkml/2014/12/16/542 BUG: sleeping function called from invalid context at mm/slab.c:2849 in_atomic(): 1, irqs_disabled(): 0, pid: 885, name: sulogin 2 locks held by sulogin/885: #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff91152e30>] prepare_bprm_creds+0x28/0x8b #1: (tty_files_lock){+.+.+.}, at: [<ffffffff9123e787>] selinux_bprm_committing_creds+0x55/0x22b CPU: 1 PID: 885 Comm: sulogin Not tainted 3.18.0-next-20141216 #30 Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014 ffff880223744f10 ffff88022410f9b8 ffffffff916ba529 0000000000000375 ffff880223744f10 ffff88022410f9e8 ffffffff91063185 0000000000000006 0000000000000000 0000000000000000 0000000000000000 ffff88022410fa38 Call Trace: [<ffffffff916ba529>] dump_stack+0x50/0xa8 [<ffffffff91063185>] ___might_sleep+0x1b6/0x1be [<ffffffff910632a6>] __might_sleep+0x119/0x128 [<ffffffff91140720>] cache_alloc_debugcheck_before.isra.45+0x1d/0x1f [<ffffffff91141d81>] kmem_cache_alloc+0x43/0x1c9 [<ffffffff914e148d>] __alloc_skb+0x42/0x1a3 [<ffffffff914e2b62>] skb_copy+0x3e/0xa3 [<ffffffff910c263e>] audit_log_end+0x83/0x100 [<ffffffff9123b8d3>] ? avc_audit_pre_callback+0x103/0x103 [<ffffffff91252a73>] common_lsm_audit+0x441/0x450 [<ffffffff9123c163>] slow_avc_audit+0x63/0x67 [<ffffffff9123c42c>] avc_has_perm+0xca/0xe3 [<ffffffff9123dc2d>] inode_has_perm+0x5a/0x65 [<ffffffff9123e7ca>] selinux_bprm_committing_creds+0x98/0x22b [<ffffffff91239e64>] security_bprm_committing_creds+0xe/0x10 [<ffffffff911515e6>] install_exec_creds+0xe/0x79 [<ffffffff911974cf>] load_elf_binary+0xe36/0x10d7 [<ffffffff9115198e>] search_binary_handler+0x81/0x18c [<ffffffff91153376>] do_execveat_common.isra.31+0x4e3/0x7b7 [<ffffffff91153669>] do_execve+0x1f/0x21 [<ffffffff91153967>] SyS_execve+0x25/0x29 [<ffffffff916c61a9>] stub_execve+0x69/0xa0 Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Tested-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Signed-off-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:27 -08:00
Eric W. Biederman	b95660c47a	userns: Unbreak the unprivileged remount tests commit `db86da7cb7` upstream. A security fix in caused the way the unprivileged remount tests were using user namespaces to break. Tweak the way user namespaces are being used so the test works again. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:27 -08:00
Eric W. Biederman	57f8552358	userns: Allow setting gid_maps without privilege when setgroups is disabled commit `66d2f338ee` upstream. Now that setgroups can be disabled and not reenabled, setting gid_map without privielge can now be enabled when setgroups is disabled. This restores most of the functionality that was lost when unprivileged setting of gid_map was removed. Applications that use this functionality will need to check to see if they use setgroups or init_groups, and if they don't they can be fixed by simply disabling setgroups before writing to gid_map. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:26 -08:00
Eric W. Biederman	4a7215f134	userns: Add a knob to disable setgroups on a per user namespace basis commit `9cc46516dd` upstream. - Expose the knob to user space through a proc file /proc/<pid>/setgroups A value of "deny" means the setgroups system call is disabled in the current processes user namespace and can not be enabled in the future in this user namespace. A value of "allow" means the segtoups system call is enabled. - Descendant user namespaces inherit the value of setgroups from their parents. - A proc file is used (instead of a sysctl) as sysctls currently do not allow checking the permissions at open time. - Writing to the proc file is restricted to before the gid_map for the user namespace is set. This ensures that disabling setgroups at a user namespace level will never remove the ability to call setgroups from a process that already has that ability. A process may opt in to the setgroups disable for itself by creating, entering and configuring a user namespace or by calling setns on an existing user namespace with setgroups disabled. Processes without privileges already can not call setgroups so this is a noop. Prodcess with privilege become processes without privilege when entering a user namespace and as with any other path to dropping privilege they would not have the ability to call setgroups. So this remains within the bounds of what is possible without a knob to disable setgroups permanently in a user namespace. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:26 -08:00
Eric W. Biederman	54b8ced1ef	userns: Rename id_map_mutex to userns_state_mutex commit `f0d62aec93` upstream. Generalize id_map_mutex so it can be used for more state of a user namespace. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:26 -08:00
Eric W. Biederman	39d3003edf	userns: Only allow the creator of the userns unprivileged mappings commit `f95d7918bd` upstream. If you did not create the user namespace and are allowed to write to uid_map or gid_map you should already have the necessary privilege in the parent user namespace to establish any mapping you want so this will not affect userspace in practice. Limiting unprivileged uid mapping establishment to the creator of the user namespace makes it easier to verify all credentials obtained with the uid mapping can be obtained without the uid mapping without privilege. Limiting unprivileged gid mapping establishment (which is temporarily absent) to the creator of the user namespace also ensures that the combination of uid and gid can already be obtained without privilege. This is part of the fix for CVE-2014-8989. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:26 -08:00
Eric W. Biederman	335f060430	userns: Check euid no fsuid when establishing an unprivileged uid mapping commit `80dd00a237` upstream. setresuid allows the euid to be set to any of uid, euid, suid, and fsuid. Therefor it is safe to allow an unprivileged user to map their euid and use CAP_SETUID privileged with exactly that uid, as no new credentials can be obtained. I can not find a combination of existing system calls that allows setting uid, euid, suid, and fsuid from the fsuid making the previous use of fsuid for allowing unprivileged mappings a bug. This is part of a fix for CVE-2014-8989. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:25 -08:00
Eric W. Biederman	b9b97d5b16	userns: Don't allow unprivileged creation of gid mappings commit `be7c6dba23` upstream. As any gid mapping will allow and must allow for backwards compatibility dropping groups don't allow any gid mappings to be established without CAP_SETGID in the parent user namespace. For a small class of applications this change breaks userspace and removes useful functionality. This small class of applications includes tools/testing/selftests/mount/unprivilged-remount-test.c Most of the removed functionality will be added back with the addition of a one way knob to disable setgroups. Once setgroups is disabled setting the gid_map becomes as safe as setting the uid_map. For more common applications that set the uid_map and the gid_map with privilege this change will have no affect. This is part of a fix for CVE-2014-8989. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:25 -08:00
Eric W. Biederman	d5c3ebc439	userns: Don't allow setgroups until a gid mapping has been setablished commit `273d2c67c3` upstream. setgroups is unique in not needing a valid mapping before it can be called, in the case of setgroups(0, NULL) which drops all supplemental groups. The design of the user namespace assumes that CAP_SETGID can not actually be used until a gid mapping is established. Therefore add a helper function to see if the user namespace gid mapping has been established and call that function in the setgroups permission check. This is part of the fix for CVE-2014-8989, being able to drop groups without privilege using user namespaces. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:25 -08:00
Eric W. Biederman	d9a75912fc	userns: Document what the invariant required for safe unprivileged mappings. commit `0542f17bf2` upstream. The rule is simple. Don't allow anything that wouldn't be allowed without unprivileged mappings. It was previously overlooked that establishing gid mappings would allow dropping groups and potentially gaining permission to files and directories that had lesser permissions for a specific group than for all other users. This is the rule needed to fix CVE-2014-8989 and prevent any other security issues with new_idmap_permitted. The reason for this rule is that the unix permission model is old and there are programs out there somewhere that take advantage of every little corner of it. So allowing a uid or gid mapping to be established without privielge that would allow anything that would not be allowed without that mapping will result in expectations from some code somewhere being violated. Violated expectations about the behavior of the OS is a long way to say a security issue. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:25 -08:00
Eric W. Biederman	e726c9a0a2	groups: Consolidate the setgroups permission checks commit `7ff4d90b4c` upstream. Today there are 3 instances of setgroups and due to an oversight their permission checking has diverged. Add a common function so that they may all share the same permission checking code. This corrects the current oversight in the current permission checks and adds a helper to avoid this in the future. A user namespace security fix will update this new helper, shortly. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:25 -08:00
Eric W. Biederman	462c8c0b35	umount: Disallow unprivileged mount force commit `b2f5d4dc38` upstream. Forced unmount affects not just the mount namespace but the underlying superblock as well. Restrict forced unmount to the global root user for now. Otherwise it becomes possible a user in a less privileged mount namespace to force the shutdown of a superblock of a filesystem in a more privileged mount namespace, allowing a DOS attack on root. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:24 -08:00
Eric W. Biederman	fa0bad3f28	mnt: Update unprivileged remount test commit `4a44a19b47` upstream. - MNT_NODEV should be irrelevant except when reading back mount flags, no longer specify MNT_NODEV on remount. - Test MNT_NODEV on devpts where it is meaningful even for unprivileged mounts. - Add a test to verify that remount of a prexisting mount with the same flags is allowed and does not change those flags. - Cleanup up the definitions of MS_REC, MS_RELATIME, MS_STRICTATIME that are used when the code is built in an environment without them. - Correct the test error messages when tests fail. There were not 5 tests that tested MS_RELATIME. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:24 -08:00
Eric W. Biederman	80d4d8397a	mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount commit `3e1866410f` upstream. Now that remount is properly enforcing the rule that you can't remove nodev at least sandstorm.io is breaking when performing a remount. It turns out that there is an easy intuitive solution implicitly add nodev on remount when nodev was implicitly added on mount. Tested-by: Cedric Bosdonnat <cbosdonnat@suse.com> Tested-by: Richard Weinberger <richard@nod.at> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:24 -08:00
Luis Henriques	16811f0192	thermal: Fix error path in thermal_init() commit `9d367e5e7b` upstream. thermal_unregister_governors() and class_unregister() were being called in the wrong order. Fixes: `80a26a5c22` ("Thermal: build thermal governors into thermal_sys module") Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:24 -08:00
Eric W. Biederman	877c27dbaa	mnt: Fix a memory stomp in umount commit `c297abfdf1` upstream. While reviewing the code of umount_tree I realized that when we append to a preexisting unmounted list we do not change pprev of the former first item in the list. Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on the former first item of the list will stomp unmounted.first leaving it set to some random mount point which we are likely to free soon. This isn't likely to hit, but if it does I don't know how anyone could track it down. [ This happened because we don't have all the same operations for hlist's as we do for normal doubly-linked lists. In particular, list_splice() is easy on our standard doubly-linked lists, while hlist_splice() doesn't exist and needs both start/end entries of the hlist. And commit `38129a13e6` incorrectly open-coded that missing hlist_splice(). We should think about making these kinds of "mindless" conversions easier to get right by adding the missing hlist helpers - Linus ] Fixes: `38129a13e6` switch mnt_hash to hlist Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:24 -08:00
Johannes Berg	9e2a8e62a4	mac80211: free management frame keys when removing station commit `28a9bc6812` upstream. When writing the code to allow per-station GTKs, I neglected to take into account the management frame keys (index 4 and 5) when freeing the station and only added code to free the first four data frame keys. Fix this by iterating the array of keys over the right length. Fixes: `e31b82136d` ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:23 -08:00
Andreas Müller	4286afc166	mac80211: fix multicast LED blinking and counter commit `d025933e29` upstream. As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount" stopped being incremented after the use-after-free fix. Furthermore, the RX-LED will be triggered by every multicast frame (which wouldn't happen before) which wouldn't allow the LED to rest at all. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the patch. Fixes: `b8fff407a1` ("mac80211: fix use-after-free in defragmentation") Signed-off-by: Andreas Müller <goo@stapelspeicher.org> [rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:23 -08:00
Jes Sorensen	83a67ffcf1	mac80211: avoid using uninitialized stack data commit `7e6225a160` upstream. Avoid a case where we would access uninitialized stack data if the AP advertises HT support without 40MHz channel support. Fixes: `f3000e1b43` ("mac80211: fix broken use of VHT/20Mhz with some APs") Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:23 -08:00
Felix Fietkau	0a6626aa24	mac80211: copy chandef from AP vif to VLANs commit `2967e031d4` upstream. Instead of keeping track of all those special cases where VLAN interfaces have no bss_conf.chandef, just make sure they have the same as the AP interface they belong to. Among others, this fixes a crash getting a VLAN's channel from userspace since a NULL channel is returned as a good result (return value 0) for VLANs since the commit below. Fixes: `c12bc4885f` ("mac80211: return the vif's chandef in ieee80211_cfg_get_channel()") Signed-off-by: Felix Fietkau <nbd@openwrt.org> [rewrite commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:23 -08:00
Takashi Iwai	a481fd1277	KEYS: Fix stale key registration at error path commit `b26bdde5bb` upstream. When loading encrypted-keys module, if the last check of aes_get_sizes() in init_encrypted() fails, the driver just returns an error without unregistering its key type. This results in the stale entry in the list. In addition to memory leaks, this leads to a kernel crash when registering a new key type later. This patch fixes the problem by swapping the calls of aes_get_sizes() and register_key_type(), and releasing resources properly at the error paths. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:23 -08:00
Borislav Petkov	f3d4175f05	x86/microcode/intel: Fish out the stashed microcode for the BSP commit `25cdb9c868` upstream. I'm such a moron! The simple solution of saving the BSP patch for use on resume was too simple (and wrong!), hint: sizeof(struct microcode_intel). What needs to be done instead is to fish out the microcode patch we have stashed previously and apply that on the BSP in case the late loader hasn't been utilized. So do that instead. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20141208110820.GB20057@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:22 -08:00
Borislav Petkov	d239198442	x86, microcode: Reload microcode on resume commit `fbae4ba8c4` upstream. Normally, we do reapply microcode on resume. However, in the cases where that microcode comes from the early loader and the late loader hasn't been utilized yet, there's no easy way for us to go and apply the patch applied during boot by the early loader. Thus, reuse the patch stashed by the early loader for the BSP. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:22 -08:00
Boris Ostrovsky	44c4db3ab0	x86, microcode: Don't initialize microcode code on paravirt commit `a18a0f6850` upstream. Paravirtual guests are not expected to load microcode into processors and therefore it is not necessary to initialize microcode loading logic. In fact, under certain circumstances initializing this logic may cause the guest to crash. Specifically, 32-bit kernels use __pa_nodebug() macro which does not work in Xen (the code path that leads to this macro happens during resume when we call mc_bp_resume()->load_ucode_ap() ->check_loader_disabled_ap()) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:22 -08:00
Borislav Petkov	97d0906a89	x86, microcode, intel: Drop unused parameter commit `47768626c6` upstream. apply_microcode_early() doesn't use mc_saved_data, kill it. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:22 -08:00
Borislav Petkov	6a76bc2d9e	x86, microcode, AMD: Do not use smp_processor_id() in preemtible context commit `2ef84b3bb9` upstream. Hand down the cpu number instead, otherwise lockdep screams when doing echo 1 > /sys/devices/system/cpu/microcode/reload. BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470 caller is debug_smp_processor_id+0x12/0x20 CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26 ... Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1417428741-4501-1-git-send-email-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:22 -08:00
Jan Kara	9c0f8266e9	isofs: Fix unchecked printing of ER records commit `4e2024624e` upstream. We didn't check length of rock ridge ER records before printing them. Thus corrupted isofs image can cause us to access and print some memory behind the buffer with obvious consequences. Reported-and-tested-by: Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Andy Lutomirski	743fce2698	x86/tls: Don't validate lm in set_thread_area() after all commit `3fb2f4237b` upstream. It turns out that there's a lurking ABI issue. GCC, when compiling this in a 32-bit program: struct user_desc desc = { .entry_number = idx, .base_addr = base, .limit = 0xfffff, .seg_32bit = 1, .contents = 0, /* Data, grow-up */ .read_exec_only = 0, .limit_in_pages = 1, .seg_not_present = 0, .useable = 0, }; will leave .lm uninitialized. This means that anything in the kernel that reads user_desc.lm for 32-bit tasks is unreliable. Revert the .lm check in set_thread_area(). The value never did anything in the first place. Fixes: `0e58af4e1d` ("x86/tls: Disallow unusual TLS segments") Signed-off-by: Andy Lutomirski <luto@amacapital.net> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Andy Lutomirski	afe83db5dd	x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs commit `7ddc6a2199` upstream. These functions can be executed on the int3 stack, so kprobes are dangerous. Tracing is probably a bad idea, too. Fixes: `b645af2d59` ("x86_64, traps: Rework bad_iret") Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Uwe Kleine-König	8f8c0add0c	ARM: mvebu: fix ordering in Armada 370 .dtsi commit `ab1e853721` upstream. Commit `a095b1c78a` ("ARM: mvebu: sort DT nodes by address") missed placing the system-controller in the correct order. Fixes: `a095b1c78a` ("ARM: mvebu: sort DT nodes by address") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/20141114204333.GS27002@pengutronix.de Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Thomas Petazzoni	6e9c89c406	ARM: mvebu: remove conflicting muxing on Armada 370 DB commit `b4607572ef` upstream. Back when audio was enabled, the muxing of some MPP pins was causing problems. However, since commit `fea038ed55` ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board"), those problematic MPP pins have been assigned a proper muxing for the Ethernet interfaces. This proper muxing is now conflicting with the hog pins muxing that had been added as part of `249f382250` ("ARM: mvebu: add audio support to Armada 370 DB"). Therefore, this commit simply removes the hog pins muxing, which solves a warning a boot time due to the conflicting muxing requirements. Fixes: `fea038ed55` ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board") Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1414512524-24466-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Thomas Petazzoni	a35da78ef3	ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP commit `e553554536` upstream. Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada 38x and Armada XP requires a certain number of conditions: - On Armada 370, the cache policy must be set to write-allocate. - On Armada 375, 38x and XP, the cache policy must be set to write-allocate, the pages must be mapped with the shareable attribute, and the SMP bit must be set Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none of these conditions are met. With Armada 370, the situation is worse: since the processor is single core, regardless of whether CONFIG_SMP or !CONFIG_SMP is used, the cache policy will be set to write-back by the kernel and not write-allocate. Since solving this problem turns out to be quite complicated, and we don't want to let users with a mainline kernel known to have infrequent but existing data corruptions, this commit proposes to simply disable hardware I/O coherency in situations where it is known not to work. And basically, the is_smp() function of the kernel tells us whether it is OK to enable hardware I/O coherency or not, so this commit slightly refactors the coherency_type() function to return COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate type of the coherency fabric in the other case. Thanks to this, the I/O coherency fabric will no longer be used at all in !CONFIG_SMP configurations. It will continue to be used in CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x (which are multiple cores processors), but will no longer be used on Armada 370 (which is a single core processor). In the process, it simplifies the implementation of the coherency_type() function, and adds a missing call to of_node_put(). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: `e60304f8cb` ("arm: mvebu: Add hardware I/O Coherency support") Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:21 -08:00
Thomas Petazzoni	57aefed9b2	ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric commit `30cdef9710` upstream. The ll_add_cpu_to_smp_group(), ll_enable_coherency() and ll_disable_coherency() are used on Armada XP to control the coherency fabric. However, they make the assumption that the coherency fabric is always available, which is currently a correct assumption but will no longer be true with a followup commit that disables the usage of the coherency fabric when the conditions are not met to use it. Therefore, this commit modifies those functions so that they check the return value of ll_get_coherency_base(), and if the return value is 0, they simply return without configuring anything in the coherency fabric. The ll_get_coherency_base() function is also modified to properly return 0 when the function is called with the MMU disabled. In this case, it normally returns the physical address of the coherency fabric, but we now check if the virtual address is 0, and if that's case, return a physical address of 0 to indicate that the coherency fabric is not enabled. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:20 -08:00
Dmitry Osipenko	9658243788	ARM: tegra: Re-add removed SoC id macro to tegra_resume() commit `e4a680099a` upstream. Commit `d127e9c` ("ARM: tegra: make tegra_resume can work with current and later chips") removed tegra_get_soc_id macro leaving used cpu register corrupted after branching to v7_invalidate_l1() and as result causing execution of unintended code on tegra20. Possibly it was expected that r6 would be SoC id func argument since common cpu reset handler is setting r6 before branching to tegra_resume(), but neither tegra20_lp1_reset() nor tegra30_lp1_reset() aren't setting r6 register before jumping to resume function. Fix it by re-adding macro. Fixes: `d127e9c` (ARM: tegra: make tegra_resume can work with current and later chips) Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:20 -08:00
Thierry Reding	3faf430475	drm/tegra: gem: dumb: pitch and size are outputs commit `dc6057ecb3` upstream. When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB IOCTL, only the width, height, bpp and flags parameters are inputs. The caller is not guaranteed to zero out or set handle, pitch and size, so the driver must not treat these values as possible inputs. Fixes a bug where running the Weston compositor on Tegra DRM would cause an attempt to allocate a 3 GiB framebuffer to be allocated. Fixes: `de2ba664c3` ("gpu: host1x: drm: Add memory manager and fb") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:20 -08:00
Zi Shen Lim	f324cda693	arm64: bpf: lift restriction on last instruction commit `51c9fbb1b1` upstream. Earlier implementation assumed last instruction is BPF_EXIT. Since this is no longer a restriction in eBPF, we remove this limitation. Per Alexei Starovoitov [1]: > classic BPF has a restriction that last insn is always BPF_RET. > eBPF doesn't have BPF_RET instruction and this restriction. > It has BPF_EXIT insn which can appear anywhere in the program > one or more times and it doesn't have to be last insn. [1] https://lkml.org/lkml/2014/11/27/2 Fixes: `e54bcde3d6` ("arm64: eBPF JIT compiler") Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:20 -08:00
Catalin Marinas	516e433a15	arm64: Add COMPAT_HWCAP_LPAE commit `7d57511d2d` upstream. Commit `a469abd0f8` (ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions) introduces HWCAP_ELF for 32-bit ARM applications. As LPAE is always present on arm64, report the corresponding compat HWCAP to user space. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:20 -08:00
Mikulas Patocka	ffcc89dbcb	dm thin: fix a race in thin_dtr commit `17181fb7a0` upstream. As long as struct thin_c is in the list, anyone can grab a reference of it. Consequently, we must wait for the reference count to drop to zero after we remove the structure from the list, not before. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Joe Thornber	2409f5131d	dm thin: fix missing out-of-data-space to write mode transition if blocks are released commit `2c43fd26e4` upstream. Discard bios and thin device deletion have the potential to release data blocks. If the thin-pool is in out-of-data-space mode, and blocks were released, transition the thin-pool back to full write mode. The correct time to do this is just after the thin-pool metadata commit. It cannot be done before the commit because the space maps will not allow immediate reuse of the data blocks in case there's a rollback following power failure. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Joe Thornber	52259b6ce8	dm thin: fix inability to discard blocks when in out-of-data-space mode commit `45ec9bd0fd` upstream. When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard function pointer was incorrectly being set to process_prepared_discard_passdown rather than process_prepared_discard. This incorrect function pointer meant the discard was being passed down, but not effecting the mapping. As such any discard that was issued, in an attempt to reclaim blocks, would not successfully free data space. Reported-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Dan Carpenter	5226f8886a	dm space map metadata: fix sm_bootstrap_get_nr_blocks() commit `c1c6156fe4` upstream. This function isn't right and it causes a static checker warning: drivers/md/dm-thin.c:3016 maybe_resize_data_dev() error: potentially using uninitialized 'sb_data_size'. It should set "*count" and return zero on success the same as the sm_metadata_get_nr_blocks() function does earlier. Fixes: `3241b1d3e0` ('dm: add persistent data library') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Joe Thornber	734a3fb29c	dm cache: fix spurious cell_defer when dealing with partial block at end of device commit `f824a2af3d` upstream. We never bother caching a partial block that is at the back end of the origin device. No cell ever gets locked, but the calling code was assuming it was and trying to release it. Now the code only releases if the cell has been set to a non NULL value. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Joe Thornber	7a9cdc4c90	dm cache: dirty flag was mistakenly being cleared when promoting via overwrite commit `1e32134a5a` upstream. If the incoming bio is a WRITE and completely covers a block then we don't bother to do any copying for a promotion operation. Once this is done the cache block and origin block will be different, so we need to set it to 'dirty'. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:19 -08:00
Joe Thornber	4df99e3c89	dm cache: only use overwrite optimisation for promotion when in writeback mode commit `f29a3147e2` upstream. Overwrite causes the cache block and origin blocks to diverge, which is only allowed in writeback mode. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:18 -08:00
Milan Broz	6425e7b0c8	dm crypt: use memzero_explicit for on-stack buffer commit `1a71d6ffe1` upstream. Use memzero_explicit to cleanup sensitive data allocated on stack to prevent the compiler from optimizing and removing memset() calls. Signed-off-by: Milan Broz <gmazyland@gmail.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:18 -08:00
Darrick J. Wong	3c737ac94b	dm bufio: fix memleak when using a dm_buffer's inline bio commit `445559cdcb` upstream. When dm-bufio sets out to use the bio built into a struct dm_buffer to issue an IO, it needs to call bio_reset after it's done with the bio so that we can free things attached to the bio such as the integrity payload. Therefore, inject our own endio callback to take care of the bio_reset after calling submit_io's end_io callback. Test case: 1. modprobe scsi_debug delay=0 dif=1 dix=199 ato=1 dev_size_mb=300 2. Set up a dm-bufio client, e.g. dm-verity, on the scsi_debug device 3. Repeatedly read metadata and watch kmalloc-192 leak! Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:18 -08:00
Mikulas Patocka	6fac18d0ad	dcache: fix kmemcheck warning in switch_names commit `08d4f77222` upstream. This patch fixes kmemcheck warning in switch_names. The function switch_names swaps inline names of two dentries. It swaps full arrays d_iname, no matter how many bytes are really used by the strings. Reading data beyond string ends results in kmemcheck warning. We fix the bug by marking both arrays as fully initialized. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:18 -08:00
Peng Tao	a8897f2679	nfs41: fix nfs4_proc_layoutget error handling commit `4bd5a980de` upstream. nfs4_layoutget_release() drops layout hdr refcnt. Grab the refcnt early so that it is safe to call .release in case nfs4_alloc_pages fails. Signed-off-by: Peng Tao <tao.peng@primarydata.com> Fixes: `a47970ff78` ("NFSv4.1: Hold reference to layout hdr in layoutget") Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:18 -08:00
Jan Kara	243cc955de	f2fs: fix possible data corruption in f2fs_write_begin() commit `9234f3190b` upstream. f2fs_write_begin() doesn't initialize the 'dn' variable if the inode has inline data. However it uses its contents to decide whether it should just zero out the page or load data to it. Thus if we are unlucky we can zero out page contents instead of loading inline data into a page. CC: Changman Lee <cm224.lee@samsung.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Jan Kara	8744de7f08	f2fs: avoid returning uninitialized value to userspace from f2fs_trim_fs() commit `9bd27ae4aa` upstream. If user specifies too low end sector for trimming, f2fs_trim_fs() will use uninitialized value as a number of trimmed blocks and returns it to userspace. Initialize number of trimmed blocks early to avoid the problem. Coverity-id: 1248809 Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Hannes Reinecke	83b12edd3f	scsi: correct return values for .eh_abort_handler implementations commit `b6c92b7e0a` upstream. The .eh_abort_handler needs to return SUCCESS, FAILED, or FAST_IO_FAIL. So fixup all callers to adhere to this requirement. Reviewed-by: Robert Elliott <elliott@hp.com> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Markus Pargmann	2e36a0161b	regulator: anatop: Set default voltage selector for vddpu commit `fe08be3ec8` upstream. The code reads the default voltage selector from its register. If the bootloader disables the regulator, the default voltage selector will be 0 which results in faulty behaviour of this regulator driver. This patch sets a default voltage selector for vddpu if it is not set in the register. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Sumit.Saxena@avagotech.com	9d91d6e03e	megaraid_sas: dndinaness related bug fixes commit `6e755ddc29` upstream. This patch addresses few endianness related bug fixes. Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Sumit.Saxena@avagotech.com	803bb7e995	megaraid_sas: corrected return of wait_event from abort frame path commit `170c238701` upstream. Corrected wait_event() call which was waiting for wrong completion status (0xFF). Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:17 -08:00
Peter Guo	1c45bf4396	mmc: sdhci-pci-o2micro: Fix Dell E5440 issue commit `6380ea099c` upstream. Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue. Fixes: `01acf6917a` (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts) Signed-off-by: Peter Guo <peter.guo@bayhubtech.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:16 -08:00
Baruch Siach	bc70ec2659	mmc: block: add newline to sysfs display of force_ro commit `0031a98a85` upstream. Make force_ro consistent with other sysfs entries. Fixes: `371a689f64` ('mmc: MMC boot partitions support') Cc: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:16 -08:00
Ulf Hansson	8d5112b646	mmc: omap_hsmmc: Fix UHS card with DDR50 support commit `903101a839` upstream. The commit, mmc: omap: clarify DDR timing mode between SD-UHS and eMMC, switched omap_hsmmc to support MMC DDR mode instead of UHS DDR50 mode. Add UHS DDR50 mode again and this time let's also keep the MMC DDR mode. Fixes: `5438ad95a5` (mmc: omap: clarify DDR timing mode between SD-UHS and eMMC) Reported-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:16 -08:00
James Hogan	31b54953c5	mmc: dw_mmc: avoid write to CDTHRCTL on older versions commit `66dfd10173` upstream. Commit `f1d2736c81` (mmc: dw_mmc: control card read threshold) added dw_mci_ctrl_rd_thld() with an unconditional write to the CDTHRCTL register at offset 0x100. However before version 240a, the FIFO region started at 0x100, so the write messes with the FIFO and completely breaks the driver. If the version id < 240A, return early from dw_mci_ctl_rd_thld() so as not to hit this problem. Fixes: `f1d2736c81` (mmc: dw_mmc: control card read threshold) Signed-off-by: James Hogan <james.hogan@imgtec.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:16 -08:00
Dmitry Eremin-Solenikov	39a67594a7	mfd: tc6393xb: Fail ohci suspend if full state restore is required commit `1a5fb99de4` upstream. Some boards with TC6393XB chip require full state restore during system resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000 tosa is one of them). Failing to do so would result in ohci Oops on resume due to internal memory contentes being changed. Fail ohci suspend on tc6393xb is full state restore is required. Recommended workaround is to unbind tmio-ohci driver before suspend and rebind it after resume. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:16 -08:00
Tony Lindgren	ff1589b52f	mfd: twl4030-power: Fix regression with missing compatible flag commit `1b9b46d05f` upstream. Commit `e7cd1d1eb1` ("mfd: twl4030-power: Add generic reset configuration") accidentally removed the compatible flag for "ti,twl4030-power" that should be there as documented in the binding. If "ti,twl4030-power" only the poweroff configuration is done by the driver. Fixes: `e7cd1d1eb1` ("mfd: twl4030-power: Add generic reset configuration") Reported-by: "Dr. H. Nikolaus Schaller" <hns@goldelico.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:15 -08:00
Sonny Rao	82c236bcbe	clocksource: arch_timer: Fix code to use physical timers when requested commit `0b46b8a718` upstream. This is a bug fix for using physical arch timers when the arch_timer_use_virtual boolean is false. It restores the arch_counter_get_cntpct() function after removal in `0d651e4e` "clocksource: arch_timer: use virtual counters" We need this on certain ARMv7 systems which are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset between the virtual and physical counters. Each core gets a different random offset. * The device boots in "Secure SVC" mode. * Nothing has touched the reset value of CNTHCTL.PL1PCEN or CNTHCTL.PL1PCTEN (both default to 1 at reset) One example of such as system is RK3288 where it is much simpler to use the physical counter since there's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. Fixes: `0d651e4e65` ("clocksource: arch_timer: use virtual counters") Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:15 -08:00
Hante Meuleman	0fb5df0d6a	brcmfmac: Fix bitmap malloc bug in msgbuf. commit `333c2aa029` upstream. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:15 -08:00
Andy Lutomirski	ead468da11	x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit commit `29fa682546` upstream. paravirt_enabled has the following effects: - Disables the F00F bug workaround warning. There is no F00F bug workaround any more because Linux's standard IDT handling already works around the F00F bug, but the warning still exists. This is only cosmetic, and, in any event, there is no such thing as KVM on a CPU with the F00F bug. - Disables 32-bit APM BIOS detection. On a KVM paravirt system, there should be no APM BIOS anyway. - Disables tboot. I think that the tboot code should check the CPUID hypervisor bit directly if it matters. - paravirt_enabled disables espfix32. espfix32 should not be disabled under KVM paravirt. The last point is the purpose of this patch. It fixes a leak of the high 16 bits of the kernel stack address on 32-bit KVM paravirt guests. Fixes CVE-2014-8134. Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:15 -08:00
Andy Lutomirski	a1f3f3d87a	x86_64, switch_to(): Load TLS descriptors before switching DS and ES commit `f647d7c155` upstream. Otherwise, if buggy user code points DS or ES into the TLS array, they would be corrupted after a context switch. This also significantly improves the comments and documents some gotchas in the code. Before this patch, the both tests below failed. With this patch, the es test passes, although the gsbase test still fails. ----- begin es test ----- /* * Copyright (c) 2014 Andy Lutomirski * GPL v2 / static unsigned short GDT3(int idx) { return (idx << 3) \| 3; } static int create_tls(int idx, unsigned int base) { struct user_desc desc = { .entry_number = idx, .base_addr = base, .limit = 0xfffff, .seg_32bit = 1, .contents = 0, / Data, grow-up / .read_exec_only = 0, .limit_in_pages = 1, .seg_not_present = 0, .useable = 0, }; if (syscall(SYS_set_thread_area, &desc) != 0) err(1, "set_thread_area"); return desc.entry_number; } int main() { int idx = create_tls(-1, 0); printf("Allocated GDT index %d\n", idx); unsigned short orig_es; asm volatile ("mov %%es,%0" : "=rm" (orig_es)); int errors = 0; int total = 1000; for (int i = 0; i < total; i++) { asm volatile ("mov %0,%%es" : : "rm" (GDT3(idx))); usleep(100); unsigned short es; asm volatile ("mov %%es,%0" : "=rm" (es)); asm volatile ("mov %0,%%es" : : "rm" (orig_es)); if (es != GDT3(idx)) { if (errors == 0) printf("[FAIL]\tES changed from 0x%hx to 0x%hx\n", GDT3(idx), es); errors++; } } if (errors) { printf("[FAIL]\tES was corrupted %d/%d times\n", errors, total); return 1; } else { printf("[OK]\tES was preserved\n"); return 0; } } ----- end es test ----- ----- begin gsbase test ----- / * gsbase.c, a gsbase test * Copyright (c) 2014 Andy Lutomirski * GPL v2 / static unsigned char testptr, testptr2; static unsigned char read_gs_testvals(void) { unsigned char ret; asm volatile ("movb %%gs:%1, %0" : "=r" (ret) : "m" (testptr)); return ret; } int main() { int errors = 0; testptr = mmap((void )0x200000000UL, 1, PROT_READ \| PROT_WRITE, MAP_PRIVATE \| MAP_FIXED \| MAP_ANONYMOUS, -1, 0); if (testptr == MAP_FAILED) err(1, "mmap"); testptr2 = mmap((void )0x300000000UL, 1, PROT_READ \| PROT_WRITE, MAP_PRIVATE \| MAP_FIXED \| MAP_ANONYMOUS, -1, 0); if (testptr2 == MAP_FAILED) err(1, "mmap"); testptr = 0; testptr2 = 1; if (syscall(SYS_arch_prctl, ARCH_SET_GS, (unsigned long)testptr2 - (unsigned long)testptr) != 0) err(1, "ARCH_SET_GS"); usleep(100); if (read_gs_testvals() == 1) { printf("[OK]\tARCH_SET_GS worked\n"); } else { printf("[FAIL]\tARCH_SET_GS failed\n"); errors++; } asm volatile ("mov %0,%%gs" : : "r" (0)); if (read_gs_testvals() == 0) { printf("[OK]\tWriting 0 to gs worked\n"); } else { printf("[FAIL]\tWriting 0 to gs failed\n"); errors++; } usleep(100); if (read_gs_testvals() == 0) { printf("[OK]\tgsbase is still zero\n"); } else { printf("[FAIL]\tgsbase was corrupted\n"); errors++; } return errors == 0 ? 0 : 1; } ----- end gsbase test ----- Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: Andi Kleen <andi@firstfloor.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/509d27c9fec78217691c3dad91cec87e1006b34a.1418075657.git.luto@amacapital.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:15 -08:00
Andy Lutomirski	7cc556d2e1	x86/tls: Disallow unusual TLS segments commit `0e58af4e1d` upstream. Users have no business installing custom code segments into the GDT, and segments that are not present but are otherwise valid are a historical source of interesting attacks. For completeness, block attempts to set the L bit. (Prior to this patch, the L bit would have been silently dropped.) This is an ABI break. I've checked glibc, musl, and Wine, and none of them look like they'll have any trouble. Note to stable maintainers: this is a hardening patch that fixes no known bugs. Given the possibility of ABI issues, this probably shouldn't be backported quickly. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:14 -08:00
Andy Lutomirski	b9372b87cd	x86/tls: Validate TLS entries to protect espfix commit `41bdc78544` upstream. Installing a 16-bit RW data segment into the GDT defeats espfix. AFAICT this will not affect glibc, Wine, or dosemu at all. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:14 -08:00
Jan Kara	b6d20edb6e	isofs: Fix infinite looping over CE entries commit `f54e18f1b8` upstream. Rock Ridge extensions define so called Continuation Entries (CE) which define where is further space with Rock Ridge data. Corrupted isofs image can contain arbitrarily long chain of these, including a one containing loop and thus causing kernel to end in an infinite loop when traversing these entries. Limit the traversal to 32 entries which should be more than enough space to store all the Rock Ridge data. Reported-by: P J P <ppandit@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2015-01-08 10:30:14 -08:00
Greg Kroah-Hartman	39ca4845f1	Linux 3.18.1	2014-12-16 09:39:45 -08:00
Takashi Iwai	72e9a6c522	ALSA: usb-audio: Don't resubmit pending URBs at MIDI error recovery commit `66139a48ce` upstream. In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input URBs to reactivate the MIDI stream, but this causes the error when some of URBs are still pending like: WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70() URB ef705c40 submitted while active CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1 Hardware name: FOXCONN TPS01/TPS01, BIOS 080015 03/23/2010 c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000 c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0 f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f Call Trace: [<c0205df6>] try_stack_unwind+0x156/0x170 [<c020482a>] dump_trace+0x5a/0x1b0 [<c0205e56>] show_trace_log_lvl+0x46/0x50 [<c02049d1>] show_stack_log_lvl+0x51/0xe0 [<c0205eb7>] show_stack+0x27/0x50 [<c078deaf>] dump_stack+0x45/0x65 [<c024c884>] warn_slowpath_common+0x84/0xa0 [<c024c8d3>] warn_slowpath_fmt+0x33/0x40 [<c061ac4f>] usb_submit_urb+0x5f/0x70 [<f7974104>] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib] [<f797483a>] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib] [<c02570c0>] call_timer_fn+0x30/0x130 [<c0257442>] run_timer_softirq+0x1c2/0x260 [<c0251493>] __do_softirq+0xc3/0x270 [<c0204732>] do_softirq_own_stack+0x22/0x30 [<c025186d>] irq_exit+0x8d/0xa0 [<c0795228>] smp_apic_timer_interrupt+0x38/0x50 [<c0794a3c>] apic_timer_interrupt+0x34/0x3c [<c0673d9e>] cpuidle_enter_state+0x3e/0xd0 [<c028bb8d>] cpu_idle_loop+0x29d/0x3e0 [<c028bd23>] cpu_startup_entry+0x53/0x60 [<c0bfac1e>] start_kernel+0x415/0x41a For avoiding these errors, check the pending URBs and skip resubmitting such ones. Reported-and-tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:07 -08:00
Takashi Iwai	bf5f983f3b	ALSA: hda - Fix built-in mic at resume on Lenovo Ideapad S210 commit `fedb2245cb` upstream. The built-in mic boost volume gets almost muted after suspend/resume on Lenovo Ideapad S210. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88121 Reported-and-tested-by: Roman Kagan <rkagan@mail.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:07 -08:00
Takashi Iwai	a12df59274	ALSA: hda - Add EAPD fixup for ASUS Z99He laptop commit `f62f5eff3d` upstream. The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A codec like another ASUS machine. Reported-and-tested-by: Dmitry V. Zimin <pfzim@mail.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:07 -08:00
Al Viro	6c1fbfffec	deal with deadlock in d_walk() commit `ca5358ef75` upstream. ... by not hitting rename_retry for reasons other than rename having happened. In other words, do _not_ restart when finding that between unlocking the child and locking the parent the former got into __dentry_kill(). Skip the killed siblings instead... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Al Viro	679829c2e5	move d_rcu from overlapping d_child to overlapping d_alias commit `946e51f2bf` upstream. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Larry Finger	3fd3a62433	rtlwifi: rtl8192ce: Fix missing interrupt ready flag commit `87141db084` upstream. Proper operation with the rewritten PCI mini driver requires that a flag be set when interrupts are enabled. This flag was missed. This patch is one of three needed to fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Catalin Iacob <iacobcatalin@gmail.com> Tested-by: Catalin Iacob <iacobcatalin@gmail.com> Cc: Catalin Iacob <iacobcatalin@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Larry Finger	9cd1d3eb26	rtlwifi: rtl8192ce: Fix kernel crashes due to missing callback entry commit `f892914c03` upstream. In the major update of the rtlwifi-family of drivers, one of the callback entries was missed, which leads to memory corruption. Unfortunately, this corruption never caused a kernel oops, but showed up in other parts of the system. This patch is one of three needed to fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Catalin Iacob <iacobcatalin@gmail.com> Tested-by: Catalin Iacob <iacobcatalin@gmail.com> Cc: Catalin Iacob <iacobcatalin@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Larry Finger	9297b375ec	rtlwifi: rtl8192ce: Fix editing error that causes silent memory corruption commit `99a82f734a` upstream. In the major update of the rtlwifi-family of drivers, there was an editing mistake. Unfortunately, this particular error leads to memory corruption that silently leads to failure of the system. This patch is one of three needed to fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Catalin Iacob <iacobcatalin@gmail.com> Tested-by: Catalin Iacob <iacobcatalin@gmail.com> Cc: Catalin Iacob <iacobcatalin@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Daniel Borkmann	4b1c83d8c3	netlink: use jhash as hashfn for rhashtable [ Upstream commit `7f19fc5e0b` ] For netlink, we shouldn't be using arch_fast_hash() as a hashing discipline, but rather jhash() instead. Since netlink sockets can be opened by any user, a local attacker would be able to easily create collisions with the DPDK-derived arch_fast_hash(), which trades off performance for security by using crc32 CPU instructions on x86_64. While it might have a legimite use case in other places, it should be avoided in netlink context, though. As rhashtable's API is very flexible, we could later on still decide on other hashing disciplines, if legitimate. Reference: http://thread.gmane.org/gmane.linux.kernel/1844123 Fixes: `e341694e3e` ("netlink: Convert netlink_lookup() to use RCU protected hash table") Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Thomas Graf <tgraf@suug.ch> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
Valdis.Kletnieks@vt.edu	01da9f8b6b	net: fix suspicious rcu_dereference_check in net/sched/sch_fq_codel.c [ Upstream commit `69204cf7eb` ] commit `46e5da40ae` (net: qdisc: use rcu prefix and silence sparse warnings) triggers a spurious warning: net/sched/sch_fq_codel.c:97 suspicious rcu_dereference_check() usage! The code should be using the _bh variant of rcu_dereference. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:06 -08:00
David Vrabel	21ac2deb8e	xen-netfront: use correct linear area after linearizing an skb [ Upstream commit `11d3d2a16c` ] Commit `97a6d1bb2b` (xen-netfront: Fix handling packets on compound pages with skb_linearize) attempted to fix a problem where an skb that would have required too many slots would be dropped causing TCP connections to stall. However, it filled in the first slot using the original buffer and not the new one and would use the wrong offset and grant access to the wrong page. Netback would notice the malformed request and stop all traffic on the VIF, reporting: vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144 vif vif-3-0 vif3.0: fatal error; disabling device Reported-by: Anthony Wright <anthony@overnetdata.com> Tested-by: Anthony Wright <anthony@overnetdata.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Eric Dumazet	7efe8f1bb7	tcp: fix more NULL deref after prequeue changes [ Upstream commit `0f85feae6b` ] When I cooked commit `c3658e8d0f` ("tcp: fix possible NULL dereference in tcp_vX_send_reset()") I missed other spots we could deref a NULL skb_dst(skb) Again, if a socket is provided, we do not need skb_dst() to get a pointer to network namespace : sock_net(sk) is good enough. Reported-by: Dann Frazier <dann.frazier@canonical.com> Bisected-by: Dann Frazier <dann.frazier@canonical.com> Tested-by: Dann Frazier <dann.frazier@canonical.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: `ca777eff51` ("tcp: remove dst refcount false sharing for prequeue mode") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Daniel Borkmann	ab12ec41d8	net: sctp: use MAX_HEADER for headroom reserve in output path [ Upstream commit `9772b54c55` ] To accomodate for enough headroom for tunnels, use MAX_HEADER instead of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs of trinity an skb_under_panic() via SCTP output path (see reference). I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere in other protocols might be one possible cause for this. In any case, it looks like accounting on chunks themself seems to look good as the skb already passed the SCTP output path and did not hit any skb_over_panic(). Given tunneling was enabled in his .config, the headroom would have been expanded by MAX_HEADER in this case. Reported-by: Robert Święcki <robert@swiecki.net> Reference: https://lkml.org/lkml/2014/12/1/507 Fixes: `594ccc14df` ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().") Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Eric Dumazet	e7b7e0c27c	net: mvneta: fix race condition in mvneta_tx() [ Upstream commit `5f478b4103` ] mvneta_tx() dereferences skb to get skb->len too late, as hardware might have completed the transmit and TX completion could have freed the skb from another cpu. Fixes: `71f6d1b31f` ("net: mvneta: replace Tx timer with a real interrupt") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
willy tarreau	9823d713bf	net: mvneta: fix Tx interrupt delay [ Upstream commit `aebea2ba0f` ] The mvneta driver sets the amount of Tx coalesce packets to 16 by default. Normally that does not cause any trouble since the driver uses a much larger Tx ring size (532 packets). But some sockets might run with very small buffers, much smaller than the equivalent of 16 packets. This is what ping is doing for example, by setting SNDBUF to 324 bytes rounded up to 2kB by the kernel. The problem is that there is no documented method to force a specific packet to emit an interrupt (eg: the last of the ring) nor is it possible to make the NIC emit an interrupt after a given delay. In this case, it causes trouble, because when ping sends packets over its raw socket, the few first packets leave the system, and the first 15 packets will be emitted without an IRQ being generated, so without the skbs being freed. And since the socket's buffer is small, there's no way to reach that amount of packets, and the ping ends up with "send: no buffer available" after sending 6 packets. Running with 3 instances of ping in parallel is enough to hide the problem, because with 6 packets per instance, that's 18 packets total, which is enough to grant a Tx interrupt before all are sent. The original driver in the LSP kernel worked around this design flaw by using a software timer to clean up the Tx descriptors. This timer was slow and caused terrible network performance on some Tx-bound workloads (such as routing) but was enough to make tools like ping work correctly. Instead here, we simply set the packet counts before interrupt to 1. This ensures that each packet sent will produce an interrupt. NAPI takes care of coalescing interrupts since the interrupt is disabled once generated. No measurable performance impact nor CPU usage were observed on small nor large packets, including when saturating the link on Tx, and this fixes tools like ping which rely on too small a send buffer. If one wants to increase this value for certain workloads where it is safe to do so, "ethtool -C $dev tx-frames" will override this default setting. This fix needs to be applied to stable kernels starting with 3.10. Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Denis Kirjanov	6c2f1fef82	mips: bpf: Fix broken BPF_MOD [ Upstream commit `2e46477a12` ] Remove optimize_div() from BPF_MOD \| BPF_K case since we don't know the dividend and fix the emit_mod() by reading the mod operation result from HI register Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org> Reviewed-by: Markos Chandras <markos.chandras@imgtec.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Pravin B Shelar	3e496d49f3	openvswitch: Fix flow mask validation. [ Upstream commit `f2a01517f2` ] Following patch fixes typo in the flow validation. This prevented installation of ARP and IPv6 flows. Fixes: `19e7a3df72` ("openvswitch: Fix NDP flow mask validation") Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Reviewed-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:05 -08:00
Tom Herbert	435dcf66f0	gre: Set inner mac header in gro complete [ Upstream commit `6fb2a75673` ] Set the inner mac header to point to the GRE payload when doing GRO. This is needed if we proceed to send the packet through GRE GSO which now uses the inner mac header instead of inner network header to determine the length of encapsulation headers. Fixes: `14051f0452` ("gre: Use inner mac length when computing tunnel length") Reported-by: Wolfgang Walter <linux@stwm.de> Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:04 -08:00
Marcelo Leitner	8407165b42	Fix race condition between vxlan_sock_add and vxlan_sock_release [ Upstream commit `00c83b01d5` ] Currently, when trying to reuse a socket, vxlan_sock_add will grab vn->sock_lock, locate a reusable socket, inc refcount and release vn->sock_lock. But vxlan_sock_release() will first decrement refcount, and then grab that lock. refcnt operations are atomic but as currently we have deferred works which hold vs->refcnt each, this might happen, leading to a use after free (specially after vxlan_igmp_leave): CPU 1 CPU 2 deferred work vxlan_sock_add ... ... spin_lock(&vn->sock_lock) vs = vxlan_find_sock(); vxlan_sock_release dec vs->refcnt, reaches 0 spin_lock(&vn->sock_lock) vxlan_sock_hold(vs), refcnt=1 spin_unlock(&vn->sock_lock) hlist_del_rcu(&vs->hlist); vxlan_notify_del_rx_port(vs) spin_unlock(&vn->sock_lock) So when we look for a reusable socket, we check if it wasn't freed already before reusing it. Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com> Fixes: `7c47cedf43` ("vxlan: move IGMP join/leave to work queue") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2014-12-16 09:39:04 -08:00

30581 changed files with 1496628 additions and 3667692 deletions

1

.get_maintainer.ignore

View File

		`@@ -1 +0,0 @@`
			`Christoph Hellwig <hch@lst.de>`

16

.gitignore vendored

View File

 *.order
 *.elf
 *.bin
-*.tar
 *.gz
 *.bz2
 *.lzma
 modules.builtin
 Module.symvers
 *.dwo
-*.su
 #
 # Top-level generic files
 /TAGS
 /linux
 /vmlinux
-/vmlinux.32
-/vmlinux-gdb.py
 /vmlinuz
 /System.map
 /Module.markers
 #
 /debian/
-#
-# tar directory (make tar*-pkg)
-#
-/tar-install/
 #
 # git files that we don't want to ignore even it they are dot-files
 #
 GSYMS
 GTAGS
-# id-utils files
-ID
 *.orig
 *~
 \#*#
 # Leavings from module signing
 #
 extra_certificates
-signing_key.pem
 signing_key.priv
 signing_key.x509
 x509.genkey
 # Kconfig presets
 all.config
-# Kdevelop4
-*.kdev4

17

.mailmap

View File

 Al Viro <viro@ftp.linux.org.uk>
 Al Viro <viro@zenIV.linux.org.uk>
 Andreas Herrmann <aherrman@de.ibm.com>
-Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
+Andrew Morton <akpm@osdl.org>
-Andrew Morton <akpm@linux-foundation.org>
 Andrew Vasquez <andrew.vasquez@qlogic.com>
 Andy Adamson <andros@citi.umich.edu>
 Archit Taneja <archit@ti.com>
 Greg Kroah-Hartman <greg@kroah.com>
 Henk Vergonet <Henk.Vergonet@gmail.com>
 Henrik Kretzschmar <henne@nachtwindheim.de>
-Henrik Rydberg <rydberg@bitmath.org>
 Herbert Xu <herbert@gondor.apana.org.au>
 Jacob Shin <Jacob.Shin@amd.com>
 James Bottomley <jejb@mulgrave.(none)>
 James Bottomley <jejb@titanic.il.steeleye.com>
 James E Wilson <wilson@specifix.com>
 James Ketrenos <jketreno@io.(none)>
-<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
 Jean Tourrilhes <jt@hpl.hp.com>
 Jeff Garzik <jgarzik@pretzel.yyz.us>
 Jens Axboe <axboe@suse.de>
 Juha Yrjola <juha.yrjola@solidboot.com>
 Kay Sievers <kay.sievers@vrfy.org>
 Kenneth W Chen <kenneth.w.chen@intel.com>
-Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
 Koushik <raghavendra.koushik@neterion.com>
 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
 Leonid I Ananiev <leonid.i.ananiev@intel.com>
 Michael Buesch <m@bues.ch>
 Michel Dänzer <michel@tungstengraphics.com>
 Mitesh shah <mshah@teja.com>
-Mohit Kumar <mohit.kumar@st.com> <mohit.kumar.dhaka@gmail.com>
 Morten Welinder <terra@gnome.org>
 Morten Welinder <welinder@anemone.rentec.com>
 Morten Welinder <welinder@darter.rentec.com>
 Peter A Jonsson <pj@ludd.ltu.se>
 Peter Oruba <peter@oruba.de>
 Peter Oruba <peter.oruba@amd.com>
-Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
 Praveen BP <praveenbp@ti.com>
 Rajesh Shah <rajesh.shah@intel.com>
 Ralf Baechle <ralf@linux-mips.org>
 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
-Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
 Rémi Denis-Courmont <rdenis@simphalempin.com>
-Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
 Rudolf Marek <R.Marek@sh.cvut.cz>
 Rui Saraiva <rmps@joel.ist.utl.pt>
 Sachin P Sant <ssant@in.ibm.com>
 Sam Ravnborg <sam@mars.ravnborg.org>
-Santosh Shilimkar <ssantosh@kernel.org>
-Santosh Shilimkar <santosh.shilimkar@oracle.org>
 Sascha Hauer <s.hauer@pengutronix.de>
 S.Çağlar Onur <caglar@pardus.org.tr>
 Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
 Simon Kelley <simon@thekelleys.org.uk>
 Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
 Stephen Hemminger <shemminger@osdl.org>
-Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
 Sumit Semwal <sumit.semwal@ti.com>
 Tejun Heo <htejun@gmail.com>
 Thomas Graf <tgraf@suug.ch>
 Uwe Kleine-König <ukl@pengutronix.de>
 Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
 Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
-Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
+Viresh Kumar <viresh.linux@gmail.com> <viresh.kumar@st.com>
-Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
-Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
 Takashi YOSHII <takashi.yoshii.zj@renesas.com>
 Yusuke Goda <goda.yusuke@renesas.com>
 Gustavo Padovan <gustavo@las.ic.unicamp.br>

67

CREDITS

View File

 S: (ask for current address)
 S: Finland
-N: Thomas Abraham
-E: thomas.ab@samsung.com
-D: Samsung pin controller driver
 N: Dragos Acostachioaie
 E: dragos@iname.com
 W: http://www.arbornet.org/~dragos
 E: balasub@cis.ohio-state.edu
 D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
-N: Chris Ball
-E: chris@printf.net
-D: Former maintainer of the MMC/SD/SDIO subsystem.
 N: Dario Ballabio
 E: ballabio_dario@emc.com
 E: dario.ballabio@tiscalinet.it
 W: http://paulbristow.net/linux/idefloppy.html
 D: Maintainer of IDE/ATAPI floppy driver
-N: Stefano Brivio
-E: stefano.brivio@polimi.it
-D: Broadcom B43 driver
 N: Dominik Brodowski
 E: linux@brodo.de
 W: http://www.brodo.de/
 S: 80050-430 - Curitiba - Paraná
 S: Brazil
-N: Oded Gabbay
-E: oded.gabbay@gmail.com
-D: AMD KFD maintainer
-S: 12 Shraga Raphaeli
-S: Petah-Tikva, 4906418
-S: Israel
 N: Kumar Gala
 E: galak@kernel.crashing.org
 D: Embedded PowerPC 6xx/7xx/74xx/82xx/83xx/85xx support
 S: USA
 N: Dave Jones
-E: davej@codemonkey.org.uk
+E: davej@redhat.com
 W: http://www.codemonkey.org.uk
 D: Assorted VIA x86 support.
 D: 2.5 AGPGART overhaul.
 D: CPUFREQ maintenance.
-D: Fedora kernel maintenance (2003-2014).
+D: Fedora kernel maintenance.
-D: 'Trinity' and similar fuzz testing work.
 D: Misc/Other.
+S: 314 Littleton Rd, Westford, MA 01886, USA
 N: Martin Josfsson
 E: gandalf@wlug.westbo.se
 S: Gurgaon, India
 S: Kuala Lumpur, Malaysia
-N: Mohit Kumar
-D: ST Microelectronics SPEAr13xx PCI host bridge driver
-D: Synopsys Designware PCI host bridge driver
 N: Gabor Kuti
 M: seasons@falcon.sch.bme.hu
 M: seasons@makosteszta.sote.hu
 S: Valladolid 47009
 S: Spain
-N: Jens Osterkamp
-E: jens@de.ibm.com
-D: Maintainer of Spidernet network driver for Cell
 N: Gadi Oxman
 E: gadio@netvision.net.il
 D: Original author and maintainer of IDE/ATAPI floppy/tape drivers
 S: Santa Clara, CA 95052
 S: USA
-N: Anil Ravindranath
-E: anil_ravindranath@pmc-sierra.com
-D: PMC-Sierra MaxRAID driver
 N: Eric S. Raymond
 E: esr@thyrsus.com
 W: http://www.tuxedo.org/~esr/
 D: Generic Z8530 driver, AX.25 DAMA slave implementation
 D: Several AX.25 hacks
-N: Ricardo Ribalda Delgado
-E: ricardo.ribalda@gmail.com
-W: http://ribalda.com
-D: PLX USB338x driver
-D: PCA9634 driver
-D: Option GTM671WFS
-D: Fintek F81216A
-D: Various kernel hacks
-S: Qtechnology A/S
-S: Valby Langgade 142
-S: 2500 Valby
-S: Denmark
 N: Francois-Rene Rideau
 E: fare@tunes.org
 W: http://www.tunes.org/~fare
 S: 75013 Paris
 S: France
-N: Aleksa Sarai
-E: cyphar@cyphar.com
-W: https://www.cyphar.com/
-D: `pids` cgroup subsystem
 N: Dipankar Sarma
 E: dipankar@in.ibm.com
 D: RCU
+N: Yoshinori Sato
+E: ysato@users.sourceforge.jp
+D: uClinux for Renesas H8/300 (H8300)
+D: http://uclinux-h8.sourceforge.jp/
 N: Hannu Savolainen
 E: hannu@opensound.com
 D: Maintainer of the sound drivers until 2.1.x days.
 D: Co-author of German book ``Linux-Kernel-Programmierung''
 D: Co-founder of Berlin Linux User Group
-N: Andrew Victor
-E: linux@maxim.org.za
-W: http://maxim.org.za/at91_26.html
-D: First maintainer of Atmel ARM-based SoC, aka AT91
-D: Introduced support for at91rm9200, the first chip of AT91 family
-S: South Africa
 N: Riku Voipio
 E: riku.voipio@iki.fi
 D: Author of PCA9532 LED and Fintek f75375s hwmon driver

28

Documentation/00-INDEX

View File

 	- How to do DMA with ISA (and LPC) devices.
 DMA-attributes.txt
 	- listing of the various possible attributes a DMA region can have
+dmatest.txt
+	- how to compile, configure and use the dmatest system.
 DocBook/
 	- directory with DocBook templates etc. for kernel documentation.
 EDID/
 	-info on the Digital Signature Verification API
 dma-buf-sharing.txt
 	- the DMA Buffer Sharing API Guide
+dmaengine.txt
+	-the DMA Engine API Guide
 dontdiff
 	- file containing a list of files that should never be diff'ed.
 driver-model/
 	- directory with information on human interface devices
 highuid.txt
 	- notes on the change from 16 bit to 32 bit user/group IDs.
-hsi.txt
-	- HSI subsystem overview.
 hwspinlock.txt
 	- hardware spinlock provides hardware assistance for synchronization
 timers/
 	- documents the kernel probes debugging feature.
 kref.txt
 	- docs on adding reference counters (krefs) to kernel objects.
-kselftest.txt
-	- small unittests for (some) individual codepaths in the kernel.
 laptops/
 	- directory with laptop related info and laptop driver documentation.
 ldm.txt
 	- directory with info about LED handling under Linux.
 local_ops.txt
 	- semantics and behavior of local atomic operations.
+lockdep-design.txt
+	- documentation on the runtime locking correctness validator.
 locking/
 	- directory with info about kernel locking primitives
+lockstat.txt
+	- info on collecting statistics on locks (and contention).
 lockup-watchdogs.txt
 	- info on soft and hard lockup detectors (aka nmi_watchdog).
 logo.gif
 	- full colour GIF image of Linux logo (penguin - Tux).
 logo.txt
 	- info on creator of above logo & site to get additional images from.
-lzo.txt
-	- kernel LZO decompressor input formats
 m68k/
 	- directory with info about Linux on Motorola 68k architecture.
 magic-number.txt
 	- list of magic numbers used to mark/protect kernel data structures.
-mailbox.txt
-	- How to write drivers for the common mailbox framework (IPC).
 md.txt
 	- info on boot arguments for the multiple devices driver.
 media-framework.txt
 	- directory with info about memory technology devices (flash)
 mono.txt
 	- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
+mutex-design.txt
+	- info on the generic mutex subsystem.
 namespaces/
 	- directory with various information about namespaces
 netlabel/
 	- a description of what robust futexes are.
 rpmsg.txt
 	- info on the Remote Processor Messaging (rpmsg) Framework
+rt-mutex-design.txt
+	- description of the RealTime mutex implementation design.
+rt-mutex.txt
+	- desc. of RT-mutex subsystem with PI (Priority Inheritance) support.
 rtc.txt
 	- notes on how to use the Real Time Clock (aka CMOS clock) driver.
 s390/
 	- info on how to obtain and use the sparse tool for typechecking.
 spi/
 	- overview of Linux kernel Serial Peripheral Interface (SPI) support.
+spinlocks.txt
+	- info on using spinlocks to provide exclusive access in kernel.
 stable_api_nonsense.txt
 	- info on why the kernel does not have a stable in-kernel api or abi.
 stable_kernel_rules.txt
 	- directory with info about Intel Wireless Wimax Connections
 workqueue.txt
 	- information on the Concurrency Managed Workqueue implementation
+ww-mutex-design.txt
+	- Intro to Mutex wait/would deadlock handling.s
 x86/x86_64/
 	- directory with info on Linux support for AMD x86-64 (Hammer) machines.
-xillybus.txt
-	- Overview and basic ui of xillybus driver
 xtensa/
 	- directory with documents relating to arch/xtensa port/implementation
 xz.txt

119

Documentation/ABI/obsolete/sysfs-block-zram

View File

-What:		/sys/block/zram<id>/num_reads
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The num_reads file is read-only and specifies the number of
-		reads (failed or successful) done on this device.
-		Now accessible via zram<id>/stat node.
-What:		/sys/block/zram<id>/num_writes
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The num_writes file is read-only and specifies the number of
-		writes (failed or successful) done on this device.
-		Now accessible via zram<id>/stat node.
-What:		/sys/block/zram<id>/invalid_io
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The invalid_io file is read-only and specifies the number of
-		non-page-size-aligned I/O requests issued to this device.
-		Now accessible via zram<id>/io_stat node.
-What:		/sys/block/zram<id>/failed_reads
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The failed_reads file is read-only and specifies the number of
-		failed reads happened on this device.
-		Now accessible via zram<id>/io_stat node.
-What:		/sys/block/zram<id>/failed_writes
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The failed_writes file is read-only and specifies the number of
-		failed writes happened on this device.
-		Now accessible via zram<id>/io_stat node.
-What:		/sys/block/zram<id>/notify_free
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The notify_free file is read-only. Depending on device usage
-		scenario it may account a) the number of pages freed because
-		of swap slot free notifications or b) the number of pages freed
-		because of REQ_DISCARD requests sent by bio. The former ones
-		are sent to a swap block device when a swap slot is freed, which
-		implies that this disk is being used as a swap disk. The latter
-		ones are sent by filesystem mounted with discard option,
-		whenever some data blocks are getting discarded.
-		Now accessible via zram<id>/io_stat node.
-What:		/sys/block/zram<id>/zero_pages
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The zero_pages file is read-only and specifies number of zero
-		filled pages written to this disk. No memory is allocated for
-		such pages.
-		Now accessible via zram<id>/mm_stat node.
-What:		/sys/block/zram<id>/orig_data_size
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The orig_data_size file is read-only and specifies uncompressed
-		size of data stored in this disk. This excludes zero-filled
-		pages (zero_pages) since no memory is allocated for them.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-What:		/sys/block/zram<id>/compr_data_size
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The compr_data_size file is read-only and specifies compressed
-		size of data stored in this disk. So, compression ratio can be
-		calculated using orig_data_size and this statistic.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-What:		/sys/block/zram<id>/mem_used_total
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_used_total file is read-only and specifies the amount
-		of memory, including allocator fragmentation and metadata
-		overhead, allocated for this disk. So, allocator space
-		efficiency can be calculated using compr_data_size and this
-		statistic.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-What:		/sys/block/zram<id>/mem_used_max
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_used_max file is read/write and specifies the amount
-		of maximum memory zram have consumed to store compressed data.
-		For resetting the value, you should write "0". Otherwise,
-		you could see -EINVAL.
-		Unit: bytes
-		Downgraded to write-only node: so it's possible to set new
-		value only; its current value is stored in zram<id>/mm_stat
-		node.
-What:		/sys/block/zram<id>/mem_limit
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_limit file is read/write and specifies the maximum
-		amount of memory ZRAM can use to store the compressed data.
-		The limit could be changed in run time and "0" means disable
-		the limit.  No limit is the initial state.  Unit: bytes
-		Downgraded to write-only node: so it's possible to set new
-		value only; its current value is stored in zram<id>/mm_stat
-		node.

97

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus

View File

-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The integer value of this attribute ranges from 0-4.
-                When read, this attribute returns the number of the actual
-                profile. This value is persistent, so its equivalent to the
-                profile that's active when the mouse is powered on next time.
-		When written, this file sets the number of the startup profile
-		and the mouse activates this profile immediately.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
 Date:		October 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Please read binary attribute info which contains firmware version.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info
-Date:		November 2012
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns general data like firmware version.
-		When written, the device can be reset.
-		The data is 8 bytes long.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store a macro with max 500 key/button strokes
-		internally.
-		When written, this file lets one set the sequence for a specific
-		button for a specific profile. Button and profile numbers are
-		included in written data. The data has to be 2082 bytes long.
-		This file is writeonly.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons
-Date:		August 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_buttons holds information about button layout.
-		When written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 77 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_settings holds information like resolution, sensitivity
-		and light effects.
-		When written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 43 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		This file is readonly.
 		Write control to select profile and read profile_settings instead.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse has a tracking- and a distance-control-unit. These
-		can be activated/deactivated and the lift-off distance can be
-		set. The data has to be 6 bytes long.
-		This file is writeonly.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk
-Date:		May 2011
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	Used to active some easy* functions of the mouse from outside.
-		The data has to be 16 bytes long.
-		This file is writeonly.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When written a calibration process for the tracking control unit
-		can be initiated/cancelled. Also lets one read/write sensor
-		registers.
-		The data has to be 4 bytes long.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read the mouse returns a 30x30 pixel image of the
-		sampled underground. This works only in the course of a
-		calibration process initiated with tcu.
-		The returned data is 1028 bytes in size.
-		This file is readonly.
-Users:		http://roccat.sourceforge.net

50

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus

View File

 		Has never been used. If bookkeeping is done, it's done in userland tools.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile
-Date:		January 2011
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The integer value of this attribute ranges from 0-4.
-		When read, this attribute returns the number of the active
-		profile.
-		When written, the mouse activates this profile immediately.
-		The profile that's active when powered down is the same that's
-		active when the mouse is powered on.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Obsoleted by binary sysfs attribute "info".
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info
-Date:		November 2012
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns general data like firmware version.
-		When written, the device can be reset.
-		The data is 6 bytes long.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons
-Date:		January 2011
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_buttons holds information about button layout.
-		When written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 23 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings
-Date:		January 2011
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_settings holds information like resolution, sensitivity
-		and light effects.
-		When written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 16 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>

50

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra

View File

 		Please use binary attribute "info" which provides this information.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
-Date:		November 2012
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns general data like firmware version.
-		When written, the device can be reset.
-		The data is 6 bytes long.
-Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
-Date:		August 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_buttons holds information about button layout.
-		When written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 19 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
-Date:		August 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store 5 profiles which can be switched by the
-		press of a button. A profile is split in settings and buttons.
-		profile_settings holds information like resolution, sensitivity
-		and light effects.
-		When written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 13 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile to read.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 		Write control to select profile and read profile_settings instead.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
-Date:		August 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns the settings stored in the mouse.
-		The size of the data is 3 bytes and holds information on the
-		startup_profile.
-		When written, this file lets write settings back to the mouse.
-		The data has to be 3 bytes long. The mouse will reject invalid
-		data.
-Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>

14

Documentation/ABI/stable/sysfs-bus-usb

View File

 KernelVersion:	2.6.25
 Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
 Description:
-		If CONFIG_PM is enabled, then this file is present.  When read,
+		If CONFIG_PM_RUNTIME is enabled then this file
-		it returns the total time (in msec) that the USB device has been
+		is present.  When read, it returns the total time (in msec)
-		connected to the machine.  This file is read-only.
+		that the USB device has been connected to the machine.  This
+		file is read-only.
 Users:
 		PowerTOP <powertop@lists.01.org>
 		https://01.org/powertop/
 KernelVersion:	2.6.25
 Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
 Description:
-		If CONFIG_PM is enabled, then this file is present.  When read,
+		If CONFIG_PM_RUNTIME is enabled then this file
-		it returns the total time (in msec) that the USB device has been
+		is present.  When read, it returns the total time (in msec)
-		active, i.e. not in a suspended state.  This file is read-only.
+		that the USB device has been active, i.e. not in a suspended
+		state.  This file is read-only.
 		Tools can use this file and the connected_duration file to
 		compute the percentage of time that a device has been active.

29

Documentation/ABI/stable/sysfs-bus-vmbus

View File

-What:		/sys/bus/vmbus/devices/vmbus_*/id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus child_relid of the device's primary channel
-Users:		tools/hv/lsvmbus
-What:		/sys/bus/vmbus/devices/vmbus_*/class_id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus interface type GUID of the device
-Users:		tools/hv/lsvmbus
-What:		/sys/bus/vmbus/devices/vmbus_*/device_id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus interface instance GUID of the device
-Users:		tools/hv/lsvmbus
-What:		/sys/bus/vmbus/devices/vmbus_*/channel_vp_mapping
-Date:		Jul 2015
-KernelVersion:	4.2.0
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The mapping of which primary/sub channels are bound to which
-		Virtual Processors.
-		Format: <channel's child_relid:the bound cpu's number>
-Users:		tools/hv/lsvmbus

11

Documentation/ABI/stable/sysfs-bus-w1

View File

-What:		/sys/bus/w1/devices/.../w1_master_timeout_us
-Date:		April 2015
-Contact:	Dmitry Khromov <dk@icelogic.net>
-Description:	Bus scanning interval, microseconds component.
-		Some of 1-Wire devices commonly associated with physical access
-		control systems are attached/generate presence for as short as
-ms - hence the tens-to-hundreds milliseconds scan intervals
-		are required.
-		see Documentation/w1/w1.generic for detailed information.
-Users:		any user space application which wants to know bus scanning
-		interval

26

Documentation/ABI/stable/sysfs-class-tpm

View File

-What:		/sys/class/tpm/tpmX/device/
+What:		/sys/class/misc/tpmX/device/
 Date:		April 2005
 KernelVersion:	2.6.12
 Contact:	tpmdd-devel@lists.sf.net
 		the properties of that TPM chip
-What:		/sys/class/tpm/tpmX/device/active
+What:		/sys/class/misc/tpmX/device/active
 Date:		April 2006
 KernelVersion:	2.6.17
 Contact:	tpmdd-devel@lists.sf.net
 		section 17 for more information on which commands are
 		available.
-What:		/sys/class/tpm/tpmX/device/cancel
+What:		/sys/class/misc/tpmX/device/cancel
 Date:		June 2005
 KernelVersion:	2.6.13
 Contact:	tpmdd-devel@lists.sf.net
 		pending TPM command. Writing any value to cancel will call the
 		TPM vendor specific cancel operation.
-What:		/sys/class/tpm/tpmX/device/caps
+What:		/sys/class/misc/tpmX/device/caps
 Date:		April 2005
 KernelVersion:	2.6.12
 Contact:	tpmdd-devel@lists.sf.net
 		the chip supports. Firmware version is that of the chip and
 		is manufacturer specific.
-What:		/sys/class/tpm/tpmX/device/durations
+What:		/sys/class/misc/tpmX/device/durations
 Date:		March 2011
 KernelVersion:	3.1
 Contact:	tpmdd-devel@lists.sf.net
 		scaled to be displayed in usecs. In this case "[adjusted]"
 		will be displayed in place of "[original]".
-What:		/sys/class/tpm/tpmX/device/enabled
+What:		/sys/class/misc/tpmX/device/enabled
 Date:		April 2006
 KernelVersion:	2.6.17
 Contact:	tpmdd-devel@lists.sf.net
 		may be visible but produce a '0' after some operation that
 		disables the TPM.
-What:		/sys/class/tpm/tpmX/device/owned
+What:		/sys/class/misc/tpmX/device/owned
 Date:		April 2006
 KernelVersion:	2.6.17
 Contact:	tpmdd-devel@lists.sf.net
 		ordinal has been executed successfully in the chip. A '0'
 		indicates that ownership hasn't been taken.
-What:		/sys/class/tpm/tpmX/device/pcrs
+What:		/sys/class/misc/tpmX/device/pcrs
 Date:		April 2005
 KernelVersion:	2.6.12
 Contact:	tpmdd-devel@lists.sf.net
 .2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
 		long. Use the "caps" property to determine TPM version.
-What:		/sys/class/tpm/tpmX/device/pubek
+What:		/sys/class/misc/tpmX/device/pubek
 Date:		April 2005
 KernelVersion:	2.6.12
 Contact:	tpmdd-devel@lists.sf.net
 		owner's authorization. Since the TPM driver doesn't store any
 		secrets, it can't authorize its own request for the pubek,
 		making it unaccessible. The public endorsement key is gener-
-		ated at TPM manufacture time and exists for the life of the
+		ated at TPM menufacture time and exists for the life of the
 		chip.
 		Example output:
 		Modulus Length: 256 (bytes)
 		Modulus:	The 256 byte Endorsement Key modulus
-What:		/sys/class/tpm/tpmX/device/temp_deactivated
+What:		/sys/class/misc/tpmX/device/temp_deactivated
 Date:		April 2006
 KernelVersion:	2.6.17
 Contact:	tpmdd-devel@lists.sf.net
 Description:	The "temp_deactivated" property returns a '1' if the chip has
-		been temporarily deactivated, usually until the next power
+		been temporarily dectivated, usually until the next power
 		cycle. Whether a warm boot (reboot) will clear a TPM chip
 		from a temp_deactivated state is platform specific.
-What:		/sys/class/tpm/tpmX/device/timeouts
+What:		/sys/class/misc/tpmX/device/timeouts
 Date:		March 2011
 KernelVersion:	3.1
 Contact:	tpmdd-devel@lists.sf.net

93

Documentation/ABI/stable/sysfs-class-udc

View File

-What:		/sys/class/udc/<udc>/a_alt_hnp_support
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates if an OTG A-Host supports HNP at an alternate port.
-Users:
-What:		/sys/class/udc/<udc>/a_hnp_support
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates if an OTG A-Host supports HNP at this port.
-Users:
-What:		/sys/class/udc/<udc>/b_hnp_enable
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates if an OTG A-Host enabled HNP support.
-Users:
-What:		/sys/class/udc/<udc>/current_speed
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates the current negotiated speed at this port.
-Users:
-What:		/sys/class/udc/<udc>/is_a_peripheral
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates that this port is the default Host on an OTG session
-		but HNP was used to switch roles.
-Users:
-What:		/sys/class/udc/<udc>/is_otg
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates that this port support OTG.
-Users:
-What:		/sys/class/udc/<udc>/maximum_speed
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates the maximum USB speed supported by this port.
-Users:
-What:		/sys/class/udc/<udc>/maximum_speed
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates the maximum USB speed supported by this port.
-Users:
-What:		/sys/class/udc/<udc>/soft_connect
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Allows users to disconnect data pullup resistors thus causing a
-		logical disconnection from the USB Host.
-Users:
-What:		/sys/class/udc/<udc>/srp
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Allows users to manually start Session Request Protocol.
-Users:
-What:		/sys/class/udc/<udc>/state
-Date:		June 2011
-KernelVersion:	3.1
-Contact:	Felipe Balbi <balbi@kernel.org>
-Description:
-		Indicates current state of the USB Device Controller. Valid
-		states are: 'not-attached', 'attached', 'powered',
-		'reconnecting', 'unauthenticated', 'default', 'addressed',
-		'configured', and 'suspended'; however not all USB Device
-		Controllers support reporting all states.
-Users:

10

Documentation/ABI/stable/sysfs-devices

View File

-# Note: This documents additional properties of any device beyond what
-# is documented in Documentation/sysfs-rules.txt
-What:		/sys/devices/*/of_path
-Date:		February 2015
-Contact:	Device Tree mailing list <devicetree@vger.kernel.org>
-Description:
-		Any device associated with a device-tree node will have
-		an of_path symlink pointing to the corresponding device
-		node in /sys/firmware/devicetree/

25

Documentation/ABI/stable/sysfs-driver-ib_srp

View File

 		  only safe with partial memory descriptor list support enabled
 		  (allow_ext_sg=1).
 		* comp_vector, a number in the range 0..n-1 specifying the
-		  MSI-X completion vector of the first RDMA channel. Some
+		  MSI-X completion vector. Some HCA's allocate multiple (n)
-		  HCA's allocate multiple (n) MSI-X vectors per HCA port. If
+		  MSI-X vectors per HCA port. If the IRQ affinity masks of
-		  the IRQ affinity masks of these interrupts have been
+		  these interrupts have been configured such that each MSI-X
-		  configured such that each MSI-X interrupt is handled by a
+		  interrupt is handled by a different CPU then the comp_vector
-		  different CPU then the comp_vector parameter can be used to
+		  parameter can be used to spread the SRP completion workload
-		  spread the SRP completion workload over multiple CPU's.
+		  over multiple CPU's.
 		* tl_retry_count, a number in the range 2..7 specifying the
 		  IB RC retry count.
 		* queue_size, the maximum number of commands that the
 		descriptor list in an SRP_CMD when communicating with an SRP
 		target.
-What:		/sys/class/scsi_host/host<n>/ch_count
-Date:		April 1, 2015
-KernelVersion:	3.19
-Contact:	linux-rdma@vger.kernel.org
-Description:	Number of RDMA channels used for communication with the SRP
-		target.
 What:		/sys/class/scsi_host/host<n>/cmd_sg_entries
 Date:		May 19, 2011
 KernelVersion:	2.6.39
 Description:	Maximum number of data buffer descriptors that may be sent to
 		the target in a single SRP_CMD request.
-What:		/sys/class/scsi_host/host<n>/comp_vector
-Date:		September 2, 2013
-KernelVersion:	3.11
-Contact:	linux-rdma@vger.kernel.org
-Description:	Completion vector used for the first RDMA channel.
 What:		/sys/class/scsi_host/host<n>/dgid
 Date:		June 17, 2006
 KernelVersion:	2.6.17

6

Documentation/ABI/stable/sysfs-driver-w1_ds28ea00

View File

-What:		/sys/bus/w1/devices/.../w1_seq
-Date:		Apr 2015
-Contact:	Matt Campbell <mattrcampbell@gmail.com>
-Description:	Support for the DS28EA00 chain sequence function
-		see Documentation/w1/slaves/w1_therm for detailed information
-Users:		any user space application which wants to communicate with DS28EA00

2

Documentation/ABI/stable/sysfs-firmware-opal-elog

View File

 				Shortly after acknowledging it, the log
 				entry will be removed from sysfs.
 				Reading this file will list the supported
-				operations (currently just acknowledge).
+				operations (curently just acknowledge).

2

Documentation/ABI/testing/configfs-spear-pcie-gadget

View File

 What:		/config/pcie-gadget
 Date:		Feb 2011
 KernelVersion:	2.6.37
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 	Interface is used to configure selected dual mode PCIe controller

48

Documentation/ABI/testing/configfs-stp-policy

View File

-What:		/config/stp-policy
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		This group contains policies mandating Master/Channel allocation
-		for software sources wishing to send trace data over an STM
-		device.
-What:		/config/stp-policy/<device>.<policy>
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		This group is the root of a policy; its name is a concatenation
-		of an stm device name to which this policy applies and an
-		arbitrary string. If <device> part doesn't match an existing
-		stm device, mkdir will fail with ENODEV; if that device already
-		has a policy assigned to it, mkdir will fail with EBUSY.
-What:		/config/stp-policy/<device>.<policy>/device
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		STM device to which this policy applies, read only. Same as the
-		<device> component of its parent directory.
-What:		/config/stp-policy/<device>.<policy>/<node>
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Policy node is a string identifier that software clients will
-		use to request a master/channel to be allocated and assigned to
-		them.
-What:		/config/stp-policy/<device>.<policy>/<node>/masters
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Range of masters from which to allocate for users of this node.
-		Write two numbers: the first master and the last master number.
-What:		/config/stp-policy/<device>.<policy>/<node>/channels
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Range of channels from which to allocate for users of this node.
-		Write two numbers: the first channel and the last channel
-		number.

11

Documentation/ABI/testing/configfs-usb-gadget-hid

View File

-What:		/config/usb-gadget/gadget/functions/hid.name
-Date:		Nov 2014
-KernelVersion:	3.19
-Description:
-		The attributes:
-		protocol	- HID protocol to use
-		report_desc	- blob corresponding to HID report descriptors
-				except the data passed through /dev/hidg<N>
-		report_length	- HID report length
-		subclass	- HID device subclass to use

2

Documentation/ABI/testing/configfs-usb-gadget-loopback

View File

 		The attributes:
 		qlen		- depth of loopback queue
-		buflen		- buffer length
+		bulk_buflen	- buffer length

12

Documentation/ABI/testing/configfs-usb-gadget-midi

View File

-What:		/config/usb-gadget/gadget/functions/midi.name
-Date:		Nov 2014
-KernelVersion:	3.19
-Description:
-		The attributes:
-		index		- index value for the USB MIDI adapter
-		id		- ID string for the USB MIDI adapter
-		buflen		- MIDI buffer length
-		qlen		- USB read request queue length
-		in_ports	- number of MIDI input ports
-		out_ports	- number of MIDI output ports

9

Documentation/ABI/testing/configfs-usb-gadget-printer

View File

-What:		/config/usb-gadget/gadget/functions/printer.name
-Date:		Apr 2015
-KernelVersion:	4.1
-Description:
-		The attributes:
-		pnp_string	- Data to be passed to the host in pnp string
-		q_len		- Number of requests per endpoint

2

Documentation/ABI/testing/configfs-usb-gadget-sourcesink

View File

 		isoc_maxpacket	- 0 - 1023 (fs), 0 - 1024 (hs/ss)
 		isoc_mult	- 0..2 (hs/ss only)
 		isoc_maxburst	- 0..15 (ss only)
-		buflen		- buffer length
+		qlen		- buffer length

265

Documentation/ABI/testing/configfs-usb-gadget-uvc

View File

-What:		/config/usb-gadget/gadget/functions/uvc.name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	UVC function directory
-		streaming_maxburst	- 0..15 (ss only)
-		streaming_maxpacket	- 1..1023 (fs), 1..3072 (hs/ss)
-		streaming_interval	- 1..16
-What:		/config/usb-gadget/gadget/functions/uvc.name/control
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Control descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/class
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/class/ss
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Super speed control class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/class/fs
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Full speed control class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/terminal
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Terminal descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/terminal/output
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Output terminal descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Default output terminal descriptors
-		All attributes read only:
-		iTerminal	- index of string descriptor
-		bSourceID 	- id of the terminal to which this terminal
-				is connected
-		bAssocTerminal	- id of the input terminal to which this output
-				terminal is associated
-		wTerminalType	- terminal type
-		bTerminalID	- a non-zero id of this terminal
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Camera terminal descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera/default
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Default camera terminal descriptors
-		All attributes read only:
-		bmControls		- bitmap specifying which controls are
-					supported for the video stream
-		wOcularFocalLength	- the value of Locular
-		wObjectiveFocalLengthMax- the value of Lmin
-		wObjectiveFocalLengthMin- the value of Lmax
-		iTerminal		- index of string descriptor
-		bAssocTerminal		- id of the output terminal to which
-					this terminal is connected
-		wTerminalType		- terminal type
-		bTerminalID		- a non-zero id of this terminal
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/processing
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Processing unit descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/processing/default
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Default processing unit descriptors
-		All attributes read only:
-		iProcessing	- index of string descriptor
-		bmControls	- bitmap specifying which controls are
-				supported for the video stream
-		wMaxMultiplier	- maximum digital magnification x100
-		bSourceID	- id of the terminal to which this unit is
-				connected
-		bUnitID		- a non-zero id of this unit
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/header
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Control header descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/control/header/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific control header descriptors
-dwClockFrequency
-bcdUVC
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Streaming descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/class
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Streaming class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/class/ss
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Super speed streaming class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/class/hs
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	High speed streaming class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/class/fs
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Full speed streaming class descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Color matching descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/default
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Default color matching descriptors
-		All attributes read only:
-		bMatrixCoefficients	- matrix used to compute luma and
-					chroma values from the color primaries
-		bTransferCharacteristics- optoelectronic transfer
-					characteristic of the source picutre,
-					also called the gamma function
-		bColorPrimaries		- color primaries and the reference
-					white
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	MJPEG format descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific MJPEG format descriptors
-		All attributes read only,
-		except bmaControls and bDefaultFrameIndex:
-		bmaControls		- this format's data for bmaControls in
-					the streaming header
-		bmInterfaceFlags	- specifies interlace information,
-					read-only
-		bAspectRatioY		- the X dimension of the picture aspect
-					ratio, read-only
-		bAspectRatioX		- the Y dimension of the picture aspect
-					ratio, read-only
-		bmFlags			- characteristics of this format,
-					read-only
-		bDefaultFrameIndex	- optimum frame index for this stream
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific MJPEG frame descriptors
-		dwFrameInterval		- indicates how frame interval can be
-					programmed; a number of values
-					separated by newline can be specified
-		dwDefaultFrameInterval	- the frame interval the device would
-					like to use as default
-		dwMaxVideoFrameBufferSize- the maximum number of bytes the
-					compressor will produce for a video
-					frame or still image
-		dwMaxBitRate		- the maximum bit rate at the shortest
-					frame interval in bps
-		dwMinBitRate		- the minimum bit rate at the longest
-					frame interval in bps
-		wHeight			- height of decoded bitmap frame in px
-		wWidth			- width of decoded bitmam frame in px
-		bmCapabilities		- still image support, fixed frame-rate
-					support
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Uncompressed format descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific uncompressed format descriptors
-		bmaControls		- this format's data for bmaControls in
-					the streaming header
-		bmInterfaceFlags	- specifies interlace information,
-					read-only
-		bAspectRatioY		- the X dimension of the picture aspect
-					ratio, read-only
-		bAspectRatioX		- the Y dimension of the picture aspect
-					ratio, read-only
-		bDefaultFrameIndex	- optimum frame index for this stream
-		bBitsPerPixel		- number of bits per pixel used to
-					specify color in the decoded video
-					frame
-		guidFormat		- globally unique id used to identify
-					stream-encoding format
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific uncompressed frame descriptors
-		dwFrameInterval		- indicates how frame interval can be
-					programmed; a number of values
-					separated by newline can be specified
-		dwDefaultFrameInterval	- the frame interval the device would
-					like to use as default
-		dwMaxVideoFrameBufferSize- the maximum number of bytes the
-					compressor will produce for a video
-					frame or still image
-		dwMaxBitRate		- the maximum bit rate at the shortest
-					frame interval in bps
-		dwMinBitRate		- the minimum bit rate at the longest
-					frame interval in bps
-		wHeight			- height of decoded bitmap frame in px
-		wWidth			- width of decoded bitmam frame in px
-		bmCapabilities		- still image support, fixed frame-rate
-					support
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/header
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Streaming header descriptors
-What:		/config/usb-gadget/gadget/functions/uvc.name/streaming/header/name
-Date:		Dec 2014
-KernelVersion:	3.20
-Description:	Specific streaming header descriptors
-		All attributes read only:
-		bTriggerUsage		- how the host software will respond to
-					a hardware trigger interrupt event
-		bTriggerSupport		- flag specifying if hardware
-					triggering is supported
-		bStillCaptureMethod	- method of still image caputre
-					supported
-		bTerminalLink		- id of the output terminal to which
-					the video endpoint of this interface
-					is connected
-		bmInfo			- capabilities of this video streaming
-					interface

9

Documentation/ABI/testing/dev-kmsg

View File

 		logic is used internally when messages are printed to the
 		console, /proc/kmsg or the syslog() syscall.
-		By default, kernel tries to avoid fragments by concatenating
-		when it can and fragments are rare; however, when extended
-		console support is enabled, the in-kernel concatenation is
-		disabled and /dev/kmsg output will contain more fragments. If
-		the log consumer performs concatenation, the end result
-		should be the same. In the future, the in-kernel concatenation
-		may be removed entirely and /dev/kmsg users are recommended to
-		implement fragment handling.
 Users:		dmesg(1), userspace kernel log consumers

26

Documentation/ABI/testing/ima_policy

View File

 		action: measure | dont_measure | appraise | dont_appraise | audit
 		condition:= base | lsm  [option]
 			base:	[[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
-				[euid=] [fowner=]]
+				 [fowner]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
 			option:	[[appraise_type=]] [permit_directio]
 		base: 	func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]
-			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
+			mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
-			       [[^]MAY_EXEC]
 			fsmagic:= hex value
 			fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
 			uid:= decimal value
-			euid:= decimal value
 			fowner:=decimal value
 		lsm:  	are LSM specific
 		option:	appraise_type:= [imasig]
 			dont_measure fsmagic=0x01021994
 			dont_appraise fsmagic=0x01021994
 			# RAMFS_MAGIC
+			dont_measure fsmagic=0x858458f6
 			dont_appraise fsmagic=0x858458f6
-			# DEVPTS_SUPER_MAGIC
-			dont_measure fsmagic=0x1cd1
-			dont_appraise fsmagic=0x1cd1
-			# BINFMTFS_MAGIC
-			dont_measure fsmagic=0x42494e4d
-			dont_appraise fsmagic=0x42494e4d
 			# SECURITYFS_MAGIC
 			dont_measure fsmagic=0x73636673
 			dont_appraise fsmagic=0x73636673
-			# SELINUX_MAGIC
-			dont_measure fsmagic=0xf97cff8c
-			dont_appraise fsmagic=0xf97cff8c
-			# CGROUP_SUPER_MAGIC
-			dont_measure fsmagic=0x27e0eb
-			dont_appraise fsmagic=0x27e0eb
-			# NSFS_MAGIC
-			dont_measure fsmagic=0x6e736673
-			dont_appraise fsmagic=0x6e736673
 			measure func=BPRM_CHECK
 			measure func=FILE_MMAP mask=MAY_EXEC
 		Examples of LSM specific definitions:
 		SELinux:
+			# SELINUX_MAGIC
+			dont_measure fsmagic=0xf97cff8c
+			dont_appraise fsmagic=0xf97cff8c
 			dont_measure obj_type=var_log_t
 			dont_appraise obj_type=var_log_t
 			dont_measure obj_type=auditd_log_t

11

Documentation/ABI/testing/sysfs-ata

View File

 :	SATA_PMP_GSCR_SII_GPIO
 	Only valid if the device is a PM.
-trim
-	Shows the DSM TRIM mode currently used by the device. Valid
-	values are:
-	unsupported:		Drive does not support DSM TRIM
-	unqueued:		Drive supports unqueued DSM TRIM only
-	queued:			Drive supports queued DSM TRIM
-	forced_unqueued:	Drive's queued DSM support is known to be
-				buggy and only unqueued TRIM commands
-				are sent
 spdn_cnt
 	Number of time libata decided to lower the speed of link due to errors.

7

Documentation/ABI/testing/sysfs-block

View File

 		Indicates whether a storage device is capable of storing
 		integrity metadata. Set if the device is T10 PI-capable.
-What:		/sys/block/<disk>/integrity/protection_interval_bytes
-Date:		July 2015
-Contact:	Martin K. Petersen <martin.petersen@oracle.com>
-Description:
-		Describes the number of data bytes which are protected
-		by one integrity tuple. Typically the device's logical
-		block size.
 What:		/sys/block/<disk>/integrity/write_generate
 Date:		June 2008

22

Documentation/ABI/testing/sysfs-block-dm

View File

 		Contains the value 1 while the device is suspended.
 		Otherwise it contains 0. Read-only attribute.
 Users:		util-linux, device-mapper udev rules
-What:		/sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	dm-devel@redhat.com
-Description:	Allow control over how long a request that is a
-		reasonable merge candidate can be queued on the request
-		queue.  The resolution of this deadline is in
-		microseconds (ranging from 1 to 100000 usecs).
-		Setting this attribute to 0 (the default) will disable
-		request-based DM's merge heuristic and associated extra
-		accounting.  This attribute is not applicable to
-		bio-based DM devices so it will only ever report 0 for
-		them.
-What:		/sys/block/dm-<num>/dm/use_blk_mq
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	dm-devel@redhat.com
-Description:	Request-based Device-mapper blk-mq I/O path mode.
-		Contains the value 1 if the device is using blk-mq.
-		Otherwise it contains 0. Read-only attribute.

25

Documentation/ABI/testing/sysfs-block-zram

View File

 		amount of memory ZRAM can use to store the compressed data.  The
 		limit could be changed in run time and "0" means disable the
 		limit.  No limit is the initial state.  Unit: bytes
-What:		/sys/block/zram<id>/compact
-Date:		August 2015
-Contact:	Minchan Kim <minchan@kernel.org>
-Description:
-		The compact file is write-only and trigger compaction for
-		allocator zrm uses. The allocator moves some objects so that
-		it could free fragment space.
-What:		/sys/block/zram<id>/io_stat
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The io_stat file is read-only and accumulates device's I/O
-		statistics not accounted by block layer. For example,
-		failed_reads, failed_writes, etc. File format is similar to
-		block layer statistics file format.
-What:		/sys/block/zram<id>/mm_stat
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mm_stat file is read-only and represents device's mm
-		statistics (orig_data_size, compr_data_size, etc.) in a format
-		similar to block layer statistics file format.

20

Documentation/ABI/testing/sysfs-bus-amba

View File

-What:		/sys/bus/amba/devices/.../driver_override
-Date:		September 2014
-Contact:	Antonios Motakis <a.motakis@virtualopensystems.com>
-Description:
-		This file allows the driver for a device to be specified which
-		will override standard OF, ACPI, ID table, and name matching.
-		When specified, only a driver with a name matching the value
-		written to driver_override will have an opportunity to bind to
-		the device. The override is specified by writing a string to the
-		driver_override file (echo vfio-amba > driver_override)	and may
-		be cleared with an empty string (echo > driver_override).
-		This returns the device to standard matching rules binding.
-		Writing to driver_override does not automatically unbind the
-		device from its current driver or make any attempt to
-		automatically load the specified driver. If no driver with a
-		matching name is currently loaded in the kernel, the device will
-		not bind to any driver. This also allows devices to opt-out of
-		driver binding using a driver_override name such as "none".
-		Only a single driver may be specified in the override, there is
-		no support for parsing delimiters.

24

Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10

View File

-What:		/sys/bus/coresight/devices/<memory_map>.etb/enable_sink
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Add/remove a sink from a trace path.  There can be multiple
-		source for a single sink.
-		ex: echo 1 > /sys/bus/coresight/devices/20010000.etb/enable_sink
-What:		/sys/bus/coresight/devices/<memory_map>.etb/status
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) List various control and status registers.  The specific
-		layout and content is driver specific.
-What:		/sys/bus/coresight/devices/<memory_map>.etb/trigger_cntr
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Disables write access to the Trace RAM by stopping the
-		formatter after a defined number of words have been stored
-		following the trigger event. The number of 32-bit words written
-		into the Trace RAM following the trigger event is equal to the
-		value stored in this register+1 (from ARM ETB-TRM).

322

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x

View File

-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_source
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Enable/disable tracing on this specific trace entiry.
-		Enabling a source implies the source has been configured
-		properly and a sink has been identidifed for it.  The path
-		of coresight components linking the source to the sink is
-		configured and managed automatically by the coresight framework.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	Select which address comparator or pair (of comparators) to
-		work with.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_acctype
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Used in conjunction with @addr_idx.  Specifies
-		characteristics about the address comparator being configure,
-		for example the access type, the kind of instruction to trace,
-		processor contect ID to trigger on, etc.  Individual fields in
-		the access type register may vary on the version of the trace
-		entity.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_range
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Used in conjunction with @addr_idx.  Specifies the range of
-		addresses to trigger on.  Inclusion or exclusion is specificed
-		in the corresponding access type register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
-		address to trigger on, highly influenced by the configuration
-		options of the corresponding access type register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_start
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
-		address to start tracing on, highly influenced by the
-		configuration options of the corresponding access type register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_stop
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
-		address to stop tracing on, highly influenced by the
-		configuration options of the corresponding access type register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_idx
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Specifies the counter to work on.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used in conjunction with cntr_idx, give access to the
-		counter event register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_val
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used in conjunction with cntr_idx, give access to the
-		counter value register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_val
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used in conjunction with cntr_idx, give access to the
-		counter reload value register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used in conjunction with cntr_idx, give access to the
-		counter reload event register.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_idx
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Specifies the index of the context ID register to be
-		selected.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_mask
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Mask to apply to all the context ID comparator.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used with the ctxid_idx, specify with context ID to trigger
-		on.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines which event triggers a trace.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/etmsr
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Gives access to the ETM status register, which holds
-		programming information and status on certains events.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/fifofull_level
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Number of byte left in the fifo before considering it full.
-		Depending on the tracer's version, can also hold threshold for
-		data suppression.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mode
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Interface with the driver's 'mode' field, controlling
-		various aspect of the trace entity such as time stamping,
-		context ID size and cycle accurate tracing.  Driver specific
-		and bound to change depending on the driver.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_addr_cmp
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(R) Provides the number of address comparators pairs accessible
-		on a trace unit, as specified by bit 3:0 of register ETMCCR.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_cntr
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(R) Provides the number of counters accessible on a trace unit,
-		as specified by bit 15:13 of register ETMCCR.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_ctxid_cmp
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(R) Provides the number of context ID comparator available on a
-		trace unit, as specified by bit 25:24 of register ETMCCR.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/reset
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(W) Cancels all configuration on a trace unit and set it back
-		to its boot configuration.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_12_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 1 to state 2.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_13_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 1 to state 3.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_21_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 2 to state 1.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_23_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 2 to state 3.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_31_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 3 to state 1.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_32_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines the event that causes the sequencer to transition
-		from state 3 to state 2.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/curr_seq_state
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(R) Holds the current state of the sequencer.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/sync_freq
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Holds the trace synchronization frequency value - must be
-		programmed with the various implementation behavior in mind.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/timestamp_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Defines an event that requests the insertion of a timestamp
-		into the trace stream.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/traceid
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Holds the trace ID that will appear in the trace stream
-		coming from this trace entity.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Define the event that controls the trigger.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cpu
-Date:		October 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RO) Holds the cpu number this tracer is affined to.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Configuration Code register
-		(0x004).  The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccer
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Configuration Code Extension
-		register (0x1e8).  The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmscr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM System Configuration
-		register (0x014).  The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmidr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM ID register (0x1e4).  The
-		value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmcr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Main Control register (0x000).
-		The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtraceidr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace ID register (0x200).
-		The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmteevr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace Enable Event register
-		(0x020). The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace Start/Stop Conrol
-		register (0x018). The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Enable Conrol #1
-		register (0x024). The value is read directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Enable Conrol #2
-		register (0x01c). The value is read directly from the HW.

450

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x

View File

-What:		/sys/bus/coresight/devices/<memory_map>.etm/enable_source
-Date:		April 2015
-KernelVersion:  4.01
-Contact:        Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Enable/disable tracing on this specific trace entiry.
-		Enabling a source implies the source has been configured
-		properly and a sink has been identidifed for it.  The path
-		of coresight components linking the source to the sink is
-		configured and managed automatically by the coresight framework.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cpu
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) The CPU this tracing entity is associated with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of PE comparator inputs that are
-		available for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of address comparator pairs that are
-		available for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of counters that are available for
-		tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates how many external inputs are implemented.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/numcidc
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of Context ID comparators that are
-		available for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/numvmidc
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of VMID comparators that are available
-		for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of sequencer states that are
-		implemented.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_resource
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of resource selection pairs that are
-		available for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of single-shot comparator controls that
-		are available for tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/reset
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(W) Cancels all configuration on a trace unit and set it back
-		to its boot configuration.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mode
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls various modes supported by this ETM, for example
-		P0 instruction tracing, branch broadcast, cycle counting and
-		context ID tracing.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/pe
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls which PE to trace.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the tracing of arbitrary events from bank 0 to 3.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_instren
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the behavior of the events in bank 0 to 3.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_ts
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the insertion of global timestamps in the trace
-		streams.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/syncfreq
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls how often trace synchronization requests occur.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Sets the threshold value for cycle counting.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls which regions in the memory map are enabled to
-		use branch broadcasting.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls instruction trace filtering.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) In Secure state, each bit controls whether instruction
-		tracing is enabled for the corresponding exception level.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) In non-secure state, each bit controls whether instruction
-		tracing is enabled for the corresponding exception level.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which address comparator or pair (of comparators) to
-		work with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls what type of comparison the trace unit performs.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_single
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used to setup single address comparator values.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_range
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used to setup address range comparator values.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which sequensor.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_state
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Use this to set, or read, the sequencer state.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Moves the sequencer state to a specific state.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Moves the sequencer to state 0 when a programmed event
-		occurs.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which counter unit to work with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) This sets or returns the reload count value of the
-		specific counter.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_val
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) This sets or returns the current count value of the
-                specific counter.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the operation of the selected counter.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/res_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which resource selection unit to work with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the selection of the resources in the trace unit.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Select which context ID comparator to work with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Get/Set the context ID comparator value to trigger on.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Mask for all 8 context ID comparator value
-		registers (if implemented).
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Select which virtual machine ID comparator to work with.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_val
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Get/Set the virtual machine ID comparator value to
-		trigger on.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Mask for all 8 virtual machine ID comparator value
-		registers (if implemented).
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the OS Lock Status Register (0x304).
-		The value it taken directly  from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Power Down Control Register
-		(0x310).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Power Down Status Register
-		(0x314).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the SW Lock Status Register
-		(0xFB4).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Authentication Status Register
-		(0xFB8).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Device ID Register
-		(0xFC8).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Device Type Register
-		(0xFCC).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID0 Register
-		(0xFE0).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID1 Register
-		(0xFE4).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID2 Register
-		(0xFE8).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID3 Register
-		(0xFEC).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the tracing capabilities of the trace unit (0x1E0).
-		The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the tracing capabilities of the trace unit (0x1E4).
-		The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the maximum size of the data value, data address,
-		VMID, context ID and instuction address in the trace unit
-		(0x1E8).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the value associated with various resources
-		available to the trace unit.  See the Trace Macrocell
-		architecture specification for more details (0x1E8).
-		The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns how many resources the trace unit supports (0x1F0).
-		The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns how many resources the trace unit supports (0x1F4).
-		The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the maximum speculation depth of the instruction
-		trace stream. (0x180).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of P0 right-hand keys that the trace unit
-		can use (0x184).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of P1 right-hand keys that the trace unit
-		can use (0x188).  The value is taken directly from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of special P1 right-hand keys that the
-		trace unit can use (0x18C).  The value is taken directly from
-		the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of conditional P1 right-hand keys that
-		the trace unit can use (0x190).  The value is taken directly
-		from the HW.
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of special conditional P1 right-hand keys
-		that the trace unit can use (0x194).  The value is taken
-		directly from the HW.

12

Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel

View File

-What:		/sys/bus/coresight/devices/<memory_map>.funnel/funnel_ctrl
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Enables the slave ports and defines the hold time of the
-		slave ports.
-What:		/sys/bus/coresight/devices/<memory_map>.funnel/priority
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Defines input port priority order.

8

Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc

View File

-What:		/sys/bus/coresight/devices/<memory_map>.tmc/trigger_cntr
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Disables write access to the Trace RAM by stopping the
-		formatter after a defined number of words have been stored
-		following the trigger event. Additional interface for this
-		driver are expected to be added as it matures.

6

Documentation/ABI/testing/sysfs-bus-event_source-devices-events

View File

 			event=0x2abc
 			event=0x423,inv,cmask=0x3
 			domain=0x1,offset=0x8,starting_index=0xffff
-			domain=0x1,offset=0x8,core=?
 		Each of the assignments indicates a value to be assigned to a
 		particular set of bits (as defined by the format file
 		corresponding to the <term>) in the perf_event structure passed
 		to the perf_open syscall.
-		In the case of the last example, a value replacing "?" would
-		need to be provided by the user selecting the particular event.
-		This is referred to as "event parameterization". Event
-		parameters have the format 'param=?'.
 What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
 Date: 2014/02/24
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>

22

Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7

View File

 Description:
 		Exposes the "version" field of the 24x7 catalog. This is also
 		extractable from the provided binary "catalog" sysfs entry.
-What:		/sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
-Date:		February 2014
-Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
-Description:
-		Provides the description of a particular event as provided by
-		the firmware. If firmware does not provide a description, no
-		file will be created.
-		Note that the event-name lacks the domain suffix appended for
-		events in the events/ dir.
-What:		/sys/bus/event_source/devices/hv_24x7/event_long_descs/<event-name>
-Date:		February 2014
-Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
-Description:
-		Provides the "long" description of a particular event as
-		provided by the firmware. If firmware does not provide a
-		description, no file will be created.
-		Note that the event-name lacks the domain suffix appended for
-		events in the events/ dir.

12

Documentation/ABI/testing/sysfs-bus-fcoe

View File

 Attributes:
-	fcf_dev_loss_tmo: Device loss timeout period (see below). Changing
+	fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
 			  this value will change the dev_loss_tmo for all
 			  FCFs discovered by this controller.
 	lesb/err_block:   Link Error Status Block (LESB) block error count.
 	lesb/fcs_error:   Link Error Status Block (LESB) Fibre Channel
-			  Services error count.
+			  Serivces error count.
 Notes: ctlr_X (global increment starting at 0)
 		     fabric.
 	selected:    1 indicates that the switch has been selected for use;
-indicates that the switch will not be used.
+indicates that the swich will not be used.
 	fc_map:      The Fibre Channel MAP
 	mac:         The FCF's MAC address
-	fka_period:  The FIP Keep-Alive period
+	fka_peroid:  The FIP Keep-Alive peroid
 	fabric_state: The internal kernel state
 		      "Unknown" - Initialization value
 		      "Connected" - Host is connected to the FCF
 		      "Deleted" - FCF is being removed from the system
-	dev_loss_tmo: The device loss timeout period for this FCF.
+	dev_loss_tmo: The device loss timeout peroid for this FCF.
-Notes: A device loss infrastructure similar to the FC Transport's
+Notes: A device loss infrastructre similar to the FC Transport's
        is present in fcoe_sysfs. It is nice to have so that a
        link flapping adapter doesn't continually advance the count
        used to identify the discovered FCF. FCFs will exist in a

487

Documentation/ABI/testing/sysfs-bus-iio

View File

 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_raw
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 		unique to allow association with event codes. Units after
 		application of scale and offset are millivolts.
-		Channels with 'i' and 'q' modifiers always exist in pairs and both
-		channels refer to the same signal. The 'i' channel contains the in-phase
-		component of the signal while the 'q' channel contains the quadrature
-		component.
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 		is required is a consistent labeling.  Units after application
 		of scale and offset are millivolts.
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw
-KernelVersion:	3.17
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw (unscaled no bias removal etc.) current measurement from
-		channel Y. In special cases where the channel does not
-		correspond to externally available input one of the named
-		versions may be used. The number must always be specified and
-		unique to allow association with event codes. Units after
-		application of scale and offset are milliamps.
 What:		/sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
 KernelVersion:	3.2
 Contact:	linux-iio@vger.kernel.org
 		Raw pressure measurement from channel Y. Units after
 		application of scale and offset are kilopascal.
-What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_input
-What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_input
-KernelVersion:	3.8
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Scaled pressure measurement from channel Y, in kilopascal.
 What:		/sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
 KernelVersion:	3.14
 Contact:	linux-iio@vger.kernel.org
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_i_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_i_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_tempY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_temp_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_rot_offset
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 		to the _raw output.
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
 What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_supply_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_q_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_q_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_energy_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_distance_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
 what		/sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
-What:		/sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 		production inaccuracies).  If shared across all channels,
 		<type>_calibscale is used.
-What:		/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
-What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
-What:		/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
-What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Gender of the user (e.g.: male, female) used by some pedometers
-		to compute the stride length, distance, speed and activity
-		type.
-What:		/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
-What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
-What:		/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
-What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Lists all available gender values (e.g.: male, female).
-What:		/sys/bus/iio/devices/iio:deviceX/in_activity_calibheight
-What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibheight
-What:		/sys/bus/iio/devices/iio:deviceX/in_distance_calibheight
-What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_calibheight
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Height of the user (in meters) used by some pedometers
-		to compute the stride length, distance, speed and activity
-		type.
-What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibweight
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Weight of the user (in kg). It is needed by some pedometers
-		to compute the calories burnt by the user.
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
-What:		/sys/.../iio:deviceX/in_anglvel_scale_available
-What:		/sys/.../iio:deviceX/in_magn_scale_available
-What:		/sys/.../iio:deviceX/in_illuminance_scale_available
-What:		/sys/.../iio:deviceX/in_intensity_scale_available
-What:		/sys/.../iio:deviceX/in_proximity_scale_available
 What:		/sys/.../iio:deviceX/in_voltageX_scale_available
 What:		/sys/.../iio:deviceX/in_voltage-voltage_scale_available
 What:		/sys/.../iio:deviceX/out_voltageX_scale_available
 		are listed in this attribute.
 What		/sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
-What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain
-What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain
-What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain
-What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_clear_hardwaregain
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 		to the underlying data channel, then this parameter
 		gives the 3dB frequency of the filter in Hz.
-What:		/sys/.../in_accel_filter_high_pass_3db_frequency
-What:		/sys/.../in_anglvel_filter_high_pass_3db_frequency
-What:		/sys/.../in_magn_filter_high_pass_3db_frequency
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a known or controllable high pass filter is applied
-		to the underlying data channel, then this parameter
-		gives the 3dB frequency of the filter in Hz.
 What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
 What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
 KernelVersion:	2.6.37
 		outX_powerdown_mode_available. If Y is not present the
 		mode is shared across all outputs.
-What:		/sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
+What:		/sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
 What:		/sys/.../iio:deviceX/out_voltage_powerdown_mode_available
-What:		/sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
+What:		/sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
 What:		/sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
 KernelVersion:	2.6.38
 Contact:	linux-iio@vger.kernel.org
 What:		/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
-What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:		/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:		/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion:	2.6.37
 		a given event type is enabled a future point (and not those for
 		whatever event was previously enabled).
-What:		/sys/.../events/in_accel_thresh_rising_value
-What:		/sys/.../events/in_accel_thresh_falling_value
 What:		/sys/.../events/in_accel_x_raw_thresh_rising_value
 What:		/sys/.../events/in_accel_x_raw_thresh_falling_value
 What:		/sys/.../events/in_accel_y_raw_thresh_rising_value
 		value is in raw device units or in processed units (as _raw
 		and _input do on sysfs direct channel read attributes).
-What:		/sys/.../events/in_accel_scale
-What:		/sys/.../events/in_accel_peak_scale
-What:		/sys/.../events/in_anglvel_scale
-What:		/sys/.../events/in_magn_scale
-What:		/sys/.../events/in_rot_from_north_magnetic_scale
-What:		/sys/.../events/in_rot_from_north_true_scale
-What:		/sys/.../events/in_voltage_scale
-What:		/sys/.../events/in_voltage_supply_scale
-What:		/sys/.../events/in_temp_scale
-What:		/sys/.../events/in_illuminance_scale
-What:		/sys/.../events/in_proximity_scale
-KernelVersion:	3.21
-Contact:	linux-iio@vger.kernel.org
-Description:
-                Specifies the conversion factor from the standard units
-                to device specific units used to set the event trigger
-                threshold.
 What:		/sys/.../events/in_accel_x_thresh_rising_hysteresis
 What:		/sys/.../events/in_accel_x_thresh_falling_hysteresis
 What:		/sys/.../events/in_accel_x_thresh_either_hysteresis
 What:		/sys/.../events/in_accel_x_thresh_rising_period
 What:		/sys/.../events/in_accel_x_thresh_falling_period
-What:		/sys/.../events/in_accel_x_roc_rising_period
+hat:		/sys/.../events/in_accel_x_roc_rising_period
 What:		/sys/.../events/in_accel_x_roc_falling_period
 What:		/sys/.../events/in_accel_y_thresh_rising_period
 What:		/sys/.../events/in_accel_y_thresh_falling_period
 What:		/sys/.../events/in_accel_x&y&z_mag_falling_period
 What:		/sys/.../events/in_intensity0_thresh_period
 What:		/sys/.../events/in_proximity0_thresh_period
-What:		/sys/.../events/in_activity_still_thresh_rising_period
-What:		/sys/.../events/in_activity_still_thresh_falling_period
-What:		/sys/.../events/in_activity_walking_thresh_rising_period
-What:		/sys/.../events/in_activity_walking_thresh_falling_period
-What:		/sys/.../events/in_activity_jogging_thresh_rising_period
-What:		/sys/.../events/in_activity_jogging_thresh_falling_period
-What:		/sys/.../events/in_activity_running_thresh_rising_period
-What:		/sys/.../events/in_activity_running_thresh_falling_period
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
 		met before an event is generated. If direction is not
 		specified then this period applies to both directions.
-What:		/sys/.../events/in_accel_thresh_rising_low_pass_filter_3db
-What:		/sys/.../events/in_anglvel_thresh_rising_low_pass_filter_3db
-What:		/sys/.../events/in_magn_thresh_rising_low_pass_filter_3db
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a low pass filter can be applied to the event generation
-		this property gives its 3db frequency in Hz.
-		A value of zero disables the filter.
-What:		/sys/.../events/in_accel_thresh_rising_high_pass_filter_3db
-What:		/sys/.../events/in_anglvel_thresh_rising_high_pass_filter_3db
-What:		/sys/.../events/in_magn_thresh_rising_high_pass_filter_3db
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a high pass filter can be applied to the event generation
-		this property gives its 3db frequency in Hz.
-		A value of zero disables the filter.
-What:		/sys/.../events/in_activity_still_thresh_rising_en
-What:		/sys/.../events/in_activity_still_thresh_falling_en
-What:		/sys/.../events/in_activity_walking_thresh_rising_en
-What:		/sys/.../events/in_activity_walking_thresh_falling_en
-What:		/sys/.../events/in_activity_jogging_thresh_rising_en
-What:		/sys/.../events/in_activity_jogging_thresh_falling_en
-What:		/sys/.../events/in_activity_running_thresh_rising_en
-What:		/sys/.../events/in_activity_running_thresh_falling_en
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Enables or disables activitity events. Depending on direction
-		an event is generated when sensor ENTERS or LEAVES a given state.
-What:		/sys/.../events/in_activity_still_thresh_rising_value
-What:		/sys/.../events/in_activity_still_thresh_falling_value
-What:		/sys/.../events/in_activity_walking_thresh_rising_value
-What:		/sys/.../events/in_activity_walking_thresh_falling_value
-What:		/sys/.../events/in_activity_jogging_thresh_rising_value
-What:		/sys/.../events/in_activity_jogging_thresh_falling_value
-What:		/sys/.../events/in_activity_running_thresh_rising_value
-What:		/sys/.../events/in_activity_running_thresh_falling_value
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Confidence value (in units as percentage) to be used
-		for deciding when an event should be generated. E.g for
-		running: If the confidence value reported by the sensor
-		is greater than in_activity_running_thresh_rising_value
-		then the sensor ENTERS running state. Conversely, if the
-		confidence value reported by the sensor is lower than
-		in_activity_running_thresh_falling_value then the sensor
-		is LEAVING running state.
 What:		/sys/.../iio:deviceX/events/in_accel_mag_en
 What:		/sys/.../iio:deviceX/events/in_accel_mag_rising_en
 What:		/sys/.../iio:deviceX/events/in_accel_mag_falling_en
 		number or direction is not specified, applies to all channels of
 		this type.
-What:		/sys/.../events/in_steps_change_en
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Event generated when channel passes a threshold on the absolute
-		change in value. E.g. for steps: a step change event is
-		generated each time the user takes N steps, where N is set using
-		in_steps_change_value.
-What:		/sys/.../events/in_steps_change_value
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Specifies the value of change threshold that the
-		device is comparing against for the events enabled by
-		<type>[Y][_name]_roc[_rising|falling|]_en. E.g. for steps:
-		if set to 3, a step change event will be generated every 3
-		steps.
 What:		/sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Number of scans contained by the buffer.
+What:		/sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum
+KernelVersion:	2.6.37
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Bytes per scan.  Due to alignment fun, the scan may be larger
+		than implied directly by the scan_element parameters.
 What:		/sys/bus/iio/devices/iio:deviceX/buffer/enable
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_en
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_en
 What:		/sys/.../iio:deviceX/scan_elements/in_incli_x_en
 What:		/sys/.../iio:deviceX/scan_elements/in_incli_y_en
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_en
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_en
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_en
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_type
 What:		/sys/.../iio:deviceX/scan_elements/in_voltage_type
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_type
 What:		/sys/.../iio:deviceX/scan_elements/in_timestamp_type
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_type
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_type
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_type
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_index
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_x_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_y_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_z_index
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_index
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_index
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_index
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
 		and the relevant _type attributes to establish the data storage
 		format.
-What:		/sys/.../iio:deviceX/in_activity_still_input
-What:		/sys/.../iio:deviceX/in_activity_walking_input
-What:		/sys/.../iio:deviceX/in_activity_jogging_input
-What:		/sys/.../iio:deviceX/in_activity_running_input
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to read the confidence for an activity
-		expressed in units as percentage.
 What:		/sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw
 KernelVersion:	2.6.38
 Contact:	linux-iio@vger.kernel.org
 		For a list of available output power modes read
 		in_accel_power_mode_available.
-What:		/sys/.../iio:deviceX/in_energy_input
-What:		/sys/.../iio:deviceX/in_energy_raw
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to read the energy value reported by the
-		device (e.g.: human activity sensors report energy burnt by the
-		user). Units after application of scale are Joules.
-What:		/sys/.../iio:deviceX/in_distance_input
-What:		/sys/.../iio:deviceX/in_distance_raw
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to read the distance covered by the user
-		since the last reboot while activated. Units after application
-		of scale are meters.
 What:		/sys/bus/iio/devices/iio:deviceX/store_eeprom
 KernelVersion:	3.4.0
 Contact:	linux-iio@vger.kernel.org
 		object is near the sensor, usually be observing
 		reflectivity of infrared or ultrasound emitted.
 		Often these sensors are unit less and as such conversion
-		to SI units is not possible. Higher proximity measurements
+		to SI units is not possible.  Where it is, the units should
-		indicate closer objects, and vice versa.
+		be meters.
-What:		/sys/.../iio:deviceX/in_illuminance_input
-What:		/sys/.../iio:deviceX/in_illuminance_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_input
 What:		/sys/.../iio:deviceX/in_illuminanceY_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_mean_raw
-What:		/sys/.../iio:deviceX/in_illuminance_ir_raw
-What:		/sys/.../iio:deviceX/in_illuminance_clear_raw
 KernelVersion:	3.4
 Contact:	linux-iio@vger.kernel.org
 Description:
 		This attribute is used to get/set the integration time in
 		seconds.
-What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Number of seconds in which to compute speed.
 What:		/sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw
 KernelVersion:	3.15
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Raw value of rotation from true/magnetic north measured with
 		or without compensation from tilt sensors.
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_i_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_q_raw
-KernelVersion:	3.18
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw current measurement from channel X. Units are in milliamps
-		after application of scale and offset. If no offset or scale is
-		present, output should be considered as processed with the
-		unit in milliamps.
-		Channels with 'i' and 'q' modifiers always exist in pairs and both
-		channels refer to the same signal. The 'i' channel contains the in-phase
-		component of the signal while the 'q' channel contains the quadrature
-		component.
-What:		/sys/.../iio:deviceX/in_energy_en
-What:		/sys/.../iio:deviceX/in_distance_en
-What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
-What:		/sys/.../iio:deviceX/in_steps_en
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Activates a device feature that runs in firmware/hardware.
-		E.g. for steps: the pedometer saves power while not used;
-		when activated, it will count the steps taken by the user in
-		firmware and export them through in_steps_input.
-What:		/sys/.../iio:deviceX/in_steps_input
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to read the number of steps taken by the user
-		since the last reboot while activated.
-What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_input
-What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_raw
-KernelVersion:	3.19
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to read the current speed value of the
-		user (which is the norm or magnitude of the velocity vector).
-		Units after application of scale are m/s.
-What:		/sys/.../iio:deviceX/in_steps_debounce_count
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Specifies the number of steps that must occur within
-		in_steps_filter_debounce_time for the pedometer to decide the
-		consumer is making steps.
-What:		/sys/.../iio:deviceX/in_steps_debounce_time
-KernelVersion:	4.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Specifies number of seconds in which we compute the steps
-		that occur in order to decide if the consumer is making steps.
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/watermark
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the maximum number of scan
-		elements to wait for.
-		Poll will block until the watermark is reached.
-		Blocking read will wait until the minimum between the requested
-		read amount or the low water mark is available.
-		Non-blocking read will retrieve the available samples from the
-		buffer even if there are less samples then watermark level. This
-		allows the application to block on poll with a timeout and read
-		the available samples after the timeout expires and thus have a
-		maximum delay guarantee.
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_enabled
-KernelVersion: 4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		A read-only boolean value that indicates if the hardware fifo is
-		currently enabled or disabled. If the device does not have a
-		hardware fifo this entry is not present.
-		The hardware fifo is enabled when the buffer is enabled if the
-		current hardware fifo watermark level is set and other current
-		device settings allows it (e.g. if a trigger is set that samples
-		data differently that the hardware fifo does then hardware fifo
-		will not enabled).
-		If the hardware fifo is enabled and the level of the hardware
-		fifo reaches the hardware fifo watermark level the device will
-		flush its hardware fifo to the device buffer. Doing a non
-		blocking read on the device when no samples are present in the
-		device buffer will also force a flush.
-		When the hardware fifo is enabled there is no need to use a
-		trigger to use buffer mode since the watermark settings
-		guarantees that the hardware fifo is flushed to the device
-		buffer.
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark
-KernelVersion: 4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Read-only entry that contains a single integer specifying the
-		current watermark level for the hardware fifo. If the device
-		does not have a hardware fifo this entry is not present.
-		The watermark level for the hardware fifo is set by the driver
-		based on the value set by the user in buffer/watermark but
-		taking into account hardware limitations (e.g. most hardware
-		buffers are limited to 32-64 samples, some hardware buffers
-		watermarks are fixed or have minimum levels).  A value of 0
-		means that the hardware watermark is unset.
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_min
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the minimum watermark level
-		for the hardware fifo of this device. If the device does not
-		have a hardware fifo this entry is not present.
-		If the user sets buffer/watermark to a value less than this one,
-		then the hardware watermark will remain unset.
-What:	       /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_max
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the maximum watermark level
-		for the hardware fifo of this device. If the device does not
-		have a hardware fifo this entry is not present.
-		If the user sets buffer/watermark to a value greater than this
-		one, then the hardware watermark will be capped at this value.
-What:	       /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_available
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A list of positive integers specifying the available watermark
-		levels for the hardware fifo. This entry is optional and if it
-		is not present it means that all the values between
-		hwfifo_watermark_min and hwfifo_watermark_max are supported.
-		If the user sets buffer/watermark to a value greater than
-		hwfifo_watermak_min but not equal to any of the values in this
-		list, the driver will chose an appropriate value for the
-		hardware fifo watermark level.
-What:		/sys/bus/iio/devices/iio:deviceX/in_temp_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_tempX_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_temp_object_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibemissivity
-KernelVersion:	4.1
-Contact:	linux-iio@vger.kernel.org
-Description:
-		The emissivity ratio of the surface in the field of view of the
-		contactless temperature sensor.  Emissivity varies from 0 to 1,
-		with 1 being the emissivity of a black body.
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_x_oversampling_ratio
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_y_oversampling_ratio
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_z_oversampling_ratio
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Hardware applied number of measurements for acquiring one
-		data point. The HW will do <type>[_name]_oversampling_ratio
-		measurements and return the average value as output data. Each
-		value resulted from <type>[_name]_oversampling_ratio measurements
-		is considered as one sample for <type>[_name]_sampling_frequency.
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw (unscaled no offset etc.) percentage reading of a substance.
-What:		/sys/bus/iio/devices/iio:deviceX/in_resistance_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_resistance_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw (unscaled no offset etc.) resistance reading that can be processed
-		into an ohm value.
-What:		/sys/bus/iio/devices/iio:deviceX/heater_enable
-KernelVersion:	4.1.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		'1' (enable) or '0' (disable) specifying the enable
-		of heater function. Same reading values apply
-		This ABI is especially applicable for humidity sensors
-		to heatup the device and get rid of any condensation
-		in some humidity environment

43

Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435

View File

-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Program sensor type for threshold detector inputs.
-		Could be either "GND-Open" or "Supply-Open" mode. Y is a
-		threshold detector input channel. Channels 0..7, 8..15, 16..23
-		and 24..31 has common sensor types.
-What:		/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Channel Y low voltage threshold. If sensor input voltage goes lower then
-		this value then the threshold falling event is pushed.
-		Depending on in_voltageY_sensing_mode the low voltage threshold
-		is separately set for "GND-Open" and "Supply-Open" modes.
-		Channels 0..31 have common low threshold values, but could have different
-		sensing_modes.
-		The low voltage threshold range is between 2..21V.
-		Hysteresis between low and high thresholds can not be lower then 2 and
-		can not be odd.
-		If falling threshold results hysteresis to odd value then rising
-		threshold is automatically subtracted by one.
-What:		/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Channel Y high voltage threshold. If sensor input voltage goes higher then
-		this value then the threshold rising event is pushed.
-		Depending on in_voltageY_sensing_mode the high voltage threshold
-		is separately set for "GND-Open" and "Supply-Open" modes.
-		Channels 0..31 have common high threshold values, but could have different
-		sensing_modes.
-		The high voltage threshold range is between 3..22V.
-		Hysteresis between low and high thresholds can not be lower then 2 and
-		can not be odd.
-		If rising threshold results hysteresis to odd value then falling
-		threshold is automatically appended by one.

7

Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x

View File

-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw
-Date:		September 2015
-KernelVersion:	4.3
-Contact:	Matt Ranostay <mranostay@gmail.com>
-Description:
-		Get the raw calibration VOC value from the sensor.
-		This value has little application outside of calibration.

9

Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x

View File

-What:		/sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Controls the heater device within the humidity sensor to get
-		rid of excess condensation.
-		Valid control values are 0 = OFF, and 1 = ON.

8

Documentation/ABI/testing/sysfs-bus-iio-meas-spec

View File

-What:           /sys/bus/iio/devices/iio:deviceX/battery_low
-KernelVersion:  4.1.0
-Contact:        linux-iio@vger.kernel.org
-Description:
-                Reading returns either '1' or '0'. '1' means that the
-                battery level supplied to sensor is below 2.25V.
-                This ABI is available for tsys02d, htu21, ms8607
-		This ABI is available for htu21, ms8607

31

Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs

View File

 		automated testing or in situations, where other trigger methods
 		are not applicable. For example no RTC or spare GPIOs.
 		X is the IIO index of the trigger.
-What:		/sys/bus/iio/devices/triggerX/name
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		The name attribute holds a description string for the current
-		trigger. In order to associate the trigger with an IIO device
-		one should write this name string to
-		/sys/bus/iio/devices/iio:deviceY/trigger/current_trigger.
-What:		/sys/bus/iio/devices/iio_sysfs_trigger/add_trigger
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is provided by the iio-trig-sysfs stand-alone
-		driver and it is used to activate the creation of a new trigger.
-		In order to achieve this, one should write a positive integer
-		into the associated file, which will serve as the id of the
-		trigger. If the trigger with the specified id is already present
-		in the system, an invalid argument message will be returned.
-What:		/sys/bus/iio/devices/iio_sysfs_trigger/remove_trigger
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to unregister and delete a previously
-		created trigger from the list of available triggers. In order to
-		achieve this, one should write a positive integer into the
-		associated file, representing the id of the trigger that needs
-		to be removed. If the trigger can't be found, an invalid
-		argument message will be returned to the user.

7

Documentation/ABI/testing/sysfs-bus-iio-vf610

View File

-What:		/sys/bus/iio/devices/iio:deviceX/conversion_mode
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Specifies the hardware conversion mode used. The three
-		available modes are "normal", "high-speed" and "low-power",
-		where the last is the default mode.

49

Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth

View File

-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/masters/*
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure output ports for STP masters. Writing -1
-		disables a master; any
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_port
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Output port type:
-: not present,
-: MSU (Memory Storage Unit)
-: CTP (Common Trace Port)
-: PTI (MIPI PTI).
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_drop
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Data retention policy setting: keep (0) or drop (1)
-		incoming data while output port is in reset.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_null
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) STP NULL packet generation: enabled (1) or disabled (0).
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_flush
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Force flush data from byte packing buffer for the output
-		port.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_reset
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Output port is in reset (1).
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_smcfreq
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) STP sync packet frequency for the port. Specifies the
-		number of clocks between mainenance packets.

33

Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc

View File

-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/wrap
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC buffer wrapping. 1 == wrapping enabled.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/mode
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC operating mode:
-		  - "single", for contiguous buffer mode (high-order alloc);
-		  - "multi", for multiblock mode;
-		  - "ExI", for DCI handler mode;
-		  - "debug", for debug mode.
-		If operating mode changes, existing buffer is deallocated,
-		provided there are no active users and tracing is not enabled,
-		otherwise the write will fail.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/nr_pages
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC buffer size for "single" or "multi" modes.
-		In single mode, this is a single number of pages, has to be
-		power of 2. In multiblock mode, this is a comma-separated list
-		of numbers of pages for each window to be allocated. Number of
-		windows is not limited.
-		Writing to this file deallocates existing buffer (provided
-		there are no active users and tracing is not enabled) and then
-		allocates a new one.

24

Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti

View File

-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/mode
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure PTI output width. Currently supported values
-		are 4, 8, 12, 16.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/freerunning_clock
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) 0: PTI trace clock acts as a strobe which only toggles
-		when there is trace data to send. 1: PTI trace clock is a
-		free-running clock.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/clock_divider
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure PTI port clock divider:
-		 - 0: Intel TH clock rate,
-		 - 1: 1/2 Intel TH clock rate,
-		 - 2: 1/4 Intel TH clock rate,
-		 - 3: 1/8 Intel TH clock rate.

13

Documentation/ABI/testing/sysfs-bus-intel_th-output-devices

View File

-What:		/sys/bus/intel_th/devices/<intel_th_id>-<device><id>/active
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Writes of 1 or 0 enable or disable trace output to this
-		output device. Reads return current status.
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/port
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Port number, corresponding to this output device on the
-		switch (GTH).

23

Documentation/ABI/testing/sysfs-bus-mei

View File

 Contact:	Samuel Ortiz <sameo@linux.intel.com>
 		linux-mei@linux.intel.com
 Description:	Stores the same MODALIAS value emitted by uevent
-		Format: mei:<mei device name>:<device uuid>:
+		Format: mei:<mei device name>
-What:		/sys/bus/mei/devices/.../name
-Date:		May 2015
-KernelVersion:	4.2
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client device name
-		Format: string
-What:		/sys/bus/mei/devices/.../uuid
-Date:		May 2015
-KernelVersion:	4.2
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client device uuid
-		Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-What:		/sys/bus/mei/devices/.../version
-Date:		Aug 2015
-KernelVersion:	4.3
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client protocol version
-		Format: %d

13

Documentation/ABI/testing/sysfs-bus-pci

View File

 		opt-out of driver binding using a driver_override name such as
 		"none".  Only a single driver may be specified in the override,
 		there is no support for parsing delimiters.
-What:		/sys/bus/pci/devices/.../numa_node
-Date:		Oct 2014
-Contact:	Prarit Bhargava <prarit@redhat.com>
-Description:
-		This file contains the NUMA node to which the PCI device is
-		attached, or -1 if the node is unknown.  The initial value
-		comes from an ACPI _PXM method or a similar firmware
-		source.  If that is missing or incorrect, this file can be
-		written to override the node.  In that case, please report
-		a firmware bug to the system vendor.  Writing to this file
-		taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
-		reduces the supportability of your system.

8

Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio

View File

-What:		/sys/bus/pci/drivers/janz-cmodio/.../modulbus_number
-Date:		May 2010
-KernelVersion:	2.6.35
-Contact:	Ira W. Snyder <ira.snyder@gmail.com>
-Description:
-		Value representing the HEX switch S2 of the janz carrier board CMOD-IO or CAN-PCI2
-		Read-only: value of the configuration switch (0..15)

55

Documentation/ABI/testing/sysfs-bus-usb

View File

-What:		/sys/bus/usb/devices/INTERFACE/authorized
-Date:		August 2015
-Description:
-		This allows to authorize (1) or deauthorize (0)
-		individual interfaces instead a whole device
-		in contrast to the device authorization.
-		If a deauthorized interface will be authorized
-		so the driver probing must be triggered manually
-		by writing INTERFACE to /sys/bus/usb/drivers_probe
-		This allows to avoid side-effects with drivers
-		that need multiple interfaces.
-		A deauthorized interface cannot be probed or claimed.
-What:		/sys/bus/usb/devices/usbX/interface_authorized_default
-Date:		August 2015
-Description:
-		This is used as value that determines if interfaces
-		would be authorized by default.
-		The value can be 1 or 0. It's by default 1.
 What:		/sys/bus/usb/device/.../authorized
 Date:		July 2008
 KernelVersion:	2.6.26
 Date:		September 2011
 Contact:	Andiry Xu <andiry.xu@amd.com>
 Description:
-		If CONFIG_PM is set and a USB 2.0 lpm-capable device is plugged
+		If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
-		in to a xHCI host which support link PM, it will perform a LPM
+		is plugged in to a xHCI host which support link PM, it will
-		test; if the test is passed and host supports USB2 hardware LPM
+		perform a LPM test; if the test is passed and host supports
-		(xHCI 1.0 feature), USB2 hardware LPM will be enabled for the
+		USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
-		device and the USB device directory will contain a file named
+		be enabled for the device and the USB device directory will
-		power/usb2_hardware_lpm.  The file holds a string value (enable
+		contain a file named power/usb2_hardware_lpm.  The file holds
-		or disable) indicating whether or not USB2 hardware LPM is
+		a string value (enable or disable) indicating whether or not
-		enabled for the device. Developer can write y/Y/1 or n/N/0 to
+		USB2 hardware LPM is enabled for the device. Developer can
-		the file to enable/disable the feature.
+		write y/Y/1 or n/N/0 to the file to enable/disable the
+		feature.
-What:		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u1
-		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
-Date:		November 2015
-Contact:	Kevin Strasser <kevin.strasser@linux.intel.com>
-		Lu Baolu <baolu.lu@linux.intel.com>
-Description:
-		If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
-		in to a xHCI host which supports link PM, it will check if U1
-		and U2 exit latencies have been set in the BOS descriptor; if
-		the check is passed and the host supports USB3 hardware LPM,
-		USB3 hardware LPM will be enabled for the device and the USB
-		device directory will contain two files named
-		power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
-		files hold a string value (enable or disable) indicating whether
-		or not USB3 hardware LPM U1 or U2 is enabled for the device.
 What:		/sys/bus/usb/devices/.../removable
 Date:		February 2012

12

Documentation/ABI/testing/sysfs-bus-usb-lvstest

View File

 What:		/sys/bus/usb/devices/.../get_dev_desc
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "Get Device Descriptor"
 		for Link Layer Validation device. It is needed for TD.7.06.
 What:		/sys/bus/usb/devices/.../u1_timeout
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Set "U1 timeout" for the downstream port where Link Layer
 		Validation device is connected. Timeout value must be between 0
 What:		/sys/bus/usb/devices/.../u2_timeout
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Set "U2 timeout" for the downstream port where Link Layer
 		Validation device is connected. Timeout value must be between 0
 What:		/sys/bus/usb/devices/.../hot_reset
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "Reset" for Link Layer Validation
 		device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
 What:		/sys/bus/usb/devices/.../u3_entry
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "U3 entry" for Link Layer
 		Validation device. It is needed for TD.7.35 and TD.7.36.
 What:		/sys/bus/usb/devices/.../u3_exit
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "U3 exit" for Link Layer
 		Validation device. It is needed for TD.7.36.

110

Documentation/ABI/testing/sysfs-class-cxl

View File

-Note: Attributes that are shared between devices are stored in the directory
-pointed to by the symlink device/.
-Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
-/sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.
 Slave contexts (eg. /sys/class/cxl/afu0.0s):
-What:           /sys/class/cxl/<afu>/afu_err_buf
-Date:           September 2014
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-                AFU Error Buffer contents. The contents of this file are
-		application specific and depends on the AFU being used.
-		Applications interacting with the AFU can use this attribute
-		to know about the current error condition and take appropriate
-		action like logging the event etc.
 What:           /sys/class/cxl/<afu>/irqs_max
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
                 that hardware can support (eg. 2037). Write values will limit
                 userspace applications to that many userspace interrupts. Must
                 be >= irqs_min.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/irqs_min
 Date:           September 2014
                 userspace must request on a CXL_START_WORK ioctl. Userspace may
                 omit the num_interrupts field in the START_WORK IOCTL to get
                 this minimum automatically.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/mmio_size
 Date:           September 2014
 Description:    read only
                 Decimal value of the size of the MMIO space that may be mmaped
                 by userspace.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/modes_supported
 Date:           September 2014
 Description:    read only
                 List of the modes this AFU supports. One per line.
                 Valid entries are: "dedicated_process" and "afu_directed"
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/mode
 Date:           September 2014
                 The current mode the AFU is using. Will be one of the modes
                 given in modes_supported. Writing will change the mode
                 provided that no user contexts are attached.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/prefault_mode
                                  descriptor as an effective address and
                                  prefault what it points to.
                         all: all segments process calling START_WORK maps.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/reset
 Date:           September 2014
 Description:    write only
                 Writing 1 here will reset the AFU provided there are not
                 contexts active on the AFU.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>/api_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the current version of the kernel/user API.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<afu>/api_version_compatible
+What:           /sys/class/cxl/<afu>/api_version_com
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the the lowest version of the userspace API
                 this this kernel supports.
-Users:		https://github.com/ibm-capi/libcxl
-AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):
-An AFU may optionally export one or more PCIe like configuration records, known
-as AFU configuration records, which will show up here (if present).
-What:           /sys/class/cxl/<afu>/cr<config num>/vendor
-Date:           February 2015
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-		Hexadecimal value of the vendor ID found in this AFU
-		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<afu>/cr<config num>/device
-Date:           February 2015
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-		Hexadecimal value of the device ID found in this AFU
-		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<afu>/cr<config num>/class
-Date:           February 2015
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-		Hexadecimal value of the class code found in this AFU
-		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<afu>/cr<config num>/config
-Date:           February 2015
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-		This binary file provides raw access to the AFU configuration
-		record. The format is expected to match the either the standard
-		or extended configuration space defined by the PCIe
-		specification.
-Users:		https://github.com/ibm-capi/libcxl
 Description:    read only
                 Decimal value of the size of the MMIO space that may be mmaped
                 by userspace. This includes all slave contexts space also.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>m/pp_mmio_len
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the Per Process MMIO space length.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<afu>m/pp_mmio_off
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the Per Process MMIO space offset.
-Users:		https://github.com/ibm-capi/libcxl
 Card info (eg. /sys/class/cxl/card0)
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Identifies the CAIA Version the card implements.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<card>/psl_revision
+What:           /sys/class/cxl/<card>/psl_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Identifies the revision level of the PSL.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<card>/base_image
 Date:           September 2014
                 that support loadable PSLs. For FPGAs this field identifies
                 the image contained in the on-adapter flash which is loaded
                 during the initial program load.
-Users:		https://github.com/ibm-capi/libcxl
 What:           /sys/class/cxl/<card>/image_loaded
 Date:           September 2014
 Description:    read only
                 Will return "user" or "factory" depending on the image loaded
                 onto the card.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<card>/load_image_on_perst
-Date:           December 2014
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read/write
-                Valid entries are "none", "user", and "factory".
-                "none" means PERST will not cause image to be loaded to the
-                card.  A power cycle is required to load the image.
-                "none" could be useful for debugging because the trace arrays
-                are preserved.
-                "user" and "factory" means PERST will cause either the user or
-                user or factory image to be loaded.
-                Default is to reload on PERST whichever image the card has
-                loaded.
-Users:		https://github.com/ibm-capi/libcxl
-What:           /sys/class/cxl/<card>/reset
-Date:           October 2014
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    write only
-                Writing 1 will issue a PERST to card which may cause the card
-                to reload the FPGA depending on load_image_on_perst.
-Users:		https://github.com/ibm-capi/libcxl
-What:		/sys/class/cxl/<card>/perst_reloads_same_image
-Date:		July 2015
-Contact:	linuxppc-dev@lists.ozlabs.org
-Description:	read/write
-		Trust that when an image is reloaded via PERST, it will not
-		have changed.
-= don't trust, the image may be different (default)
-= trust that the image will not change.
-Users:		https://github.com/ibm-capi/libcxl

37

Documentation/ABI/testing/sysfs-class-fpga-manager

View File

-What:		/sys/class/fpga_manager/<fpga>/name
-Date:		August 2015
-KernelVersion:	4.3
-Contact:	Alan Tull <atull@opensource.altera.com>
-Description:	Name of low level fpga manager driver.
-What:		/sys/class/fpga_manager/<fpga>/state
-Date:		August 2015
-KernelVersion:	4.3
-Contact:	Alan Tull <atull@opensource.altera.com>
-Description:	Read fpga manager state as a string.
-		The intent is to provide enough detail that if something goes
-		wrong during FPGA programming (something that the driver can't
-		fix) then userspace can know, i.e. if the firmware request
-		fails, that could be due to not being able to find the firmware
-		file.
-		This is a superset of FPGA states and fpga manager driver
-		states.  The fpga manager driver is walking through these steps
-		to get the FPGA into a known operating state.  It's a sequence,
-		though some steps may get skipped.  Valid FPGA states will vary
-		by manufacturer; this is a superset.
-		* unknown		= can't determine state
-		* power off		= FPGA power is off
-		* power up		= FPGA reports power is up
-		* reset			= FPGA held in reset state
-		* firmware request	= firmware class request in progress
-		* firmware request error = firmware request failed
-		* write init		= preparing FPGA for programming
-		* write init error	= Error while preparing FPGA for
-					  programming
-		* write			= FPGA ready to receive image data
-		* write error		= Error while programming
-		* write complete	= Doing post programming steps
-		* write complete error	= Error while doing post programming
-		* operating		= FPGA is programmed and operating

80

Documentation/ABI/testing/sysfs-class-led-flash

View File

-What:		/sys/class/leds/<led>/flash_brightness
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Set the brightness of this LED in the flash strobe mode, in
-		microamperes. The file is created only for the flash LED devices
-		that support setting flash brightness.
-		The value is between 0 and
-		/sys/class/leds/<led>/max_flash_brightness.
-What:		/sys/class/leds/<led>/max_flash_brightness
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Maximum brightness level for this LED in the flash strobe mode,
-		in microamperes.
-What:		/sys/class/leds/<led>/flash_timeout
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Hardware timeout for flash, in microseconds. The flash strobe
-		is stopped after this period of time has passed from the start
-		of the strobe. The file is created only for the flash LED
-		devices that support setting flash timeout.
-What:		/sys/class/leds/<led>/max_flash_timeout
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Maximum flash timeout for this LED, in microseconds.
-What:		/sys/class/leds/<led>/flash_strobe
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Flash strobe state. When written with 1 it triggers flash strobe
-		and when written with 0 it turns the flash off.
-		On read 1 means that flash is currently strobing and 0 means
-		that flash is off.
-What:		/sys/class/leds/<led>/flash_fault
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Space separated list of flash faults that may have occurred.
-		Flash faults are re-read after strobing the flash. Possible
-		flash faults:
-		* led-over-voltage - flash controller voltage to the flash LED
-			has exceeded the limit specific to the flash controller
-		* flash-timeout-exceeded - the flash strobe was still on when
-			the timeout set by the user has expired; not all flash
-			controllers may set this in all such conditions
-		* controller-over-temperature - the flash controller has
-			overheated
-		* controller-short-circuit - the short circuit protection
-			of the flash controller has been triggered
-		* led-power-supply-over-current - current in the LED power
-			supply has exceeded the limit specific to the flash
-			controller
-		* indicator-led-fault - the flash controller has detected
-			a short or open circuit condition on the indicator LED
-		* led-under-voltage - flash controller voltage to the flash
-			LED has been below the minimum limit specific to
-			the flash
-		* controller-under-voltage - the input voltage of the flash
-			controller is below the limit under which strobing the
-			flash at full current will not be possible;
-			the condition persists until this flag is no longer set
-		* led-over-temperature - the temperature of the LED has exceeded
-			its allowed upper limit

15

Documentation/ABI/testing/sysfs-class-mei

View File

 		The /sys/class/mei/meiN directory is created for
 		each probed mei device
-What:		/sys/class/mei/meiN/fw_status
-Date:		Nov 2014
-KernelVersion:	3.19
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Display fw status registers content
-		The ME FW writes its status information into fw status
-		registers for BIOS and OS to monitor fw health.
-		The register contains running state, power management
-		state, error codes, and others. The way the registers
-		are decoded depends on PCH or SoC generation.
-		Also number of registers varies between 1 and 6
-		depending on generation.

29

Documentation/ABI/testing/sysfs-class-mic.txt

View File

 		When read, this entry provides the current state of an Intel
 		MIC device in the context of the card OS. Possible values that
 		will be read are:
-		"ready" - The MIC device is ready to boot the card OS. On
+		"offline" - The MIC device is ready to boot the card OS. On
 		reading this entry after an OSPM resume, a "boot" has to be
 		written to this entry if the card was previously shutdown
 		during OSPM suspend.
-		"booting" - The MIC device has initiated booting a card OS.
+		"online" - The MIC device has initiated booting a card OS.
-		"online" - The MIC device has completed boot and is online
 		"shutting_down" - The card OS is shutting down.
-		"resetting" - A reset has been initiated for the MIC device
 		"reset_failed" - The MIC device has failed to reset.
+		"suspending" - The MIC device is currently being prepared for
+		suspend. On reading this entry, a "suspend" has to be written
+		to the state sysfs entry to ensure the card is shutdown during
+		OSPM suspend.
+		"suspended" - The MIC device has been suspended.
 		When written, this sysfs entry triggers different state change
 		operations depending upon the current state of the card OS.
 			sysfs entries.
 		"reset" - Initiates device reset.
 		"shutdown" - Initiates card OS shutdown.
+		"suspend" - Initiates card OS shutdown and also marks the card
+		as suspended.
 What:		/sys/class/mic/mic(x)/shutdown_status
 Date:		October 2013
 		the card. This sysfs entry can be written with the following
 		valid strings:
 		a) linux - Boot a Linux image.
-		b) flash - Boot an image for flash updates.
+		b) elf - Boot an elf image for flash updates.
 What:		/sys/class/mic/mic(x)/log_buf_addr
 Date:		October 2013
 		daemon to set the log buffer length address. The correct log
 		buffer length address to be written can be found in the
 		System.map file of the card OS.
-What:		/sys/class/mic/mic(x)/heartbeat_enable
-Date:		March 2015
-KernelVersion:	3.20
-Contact:	Ashutosh Dixit <ashutosh.dixit@intel.com>
-Description:
-		The MIC drivers detect and inform user space about card crashes
-		via a heartbeat mechanism (see the description of
-		shutdown_status above). User space can turn off this
-		notification by setting heartbeat_enable to 0 and enable it by
-		setting this entry to 1. If this notification is disabled it is
-		the responsibility of user space to detect card crashes via
-		alternative means such as a network ping. This setting is
-		enabled by default.

10

Documentation/ABI/testing/sysfs-class-mtd

View File

 		The number of blocks that are marked as reserved, if any, in
 		this partition. These are typically used to store the in-flash
 		bad block table (BBT).
-What:		/sys/class/mtd/mtdX/offset
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		For a partition, the offset of that partition from the start
-		of the master device in bytes. This attribute is absent on
-		main devices, so it can be used to distinguish between
-		partitions and devices that aren't partitions.

35

Documentation/ABI/testing/sysfs-class-net

View File

 		Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
 		address.
-What:		/sys/class/net/<bridge iface>/bridge/group_fwd_mask
-Date:		January 2012
-KernelVersion:	3.2
-Contact:	netdev@vger.kernel.org
-Description:
-		Bitmask to allow forwarding of link local frames with address
--80-C2-00-00-0X on a bridge device. Only values that set bits
-		not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h
-		allowed.
-		Default value 0 does not forward any link local frames.
-		Restricted bits:
-: 01-80-C2-00-00-00 Bridge Group Address used for STP
-: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE
-: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad
-		Any values not setting these bits can be used. Take special
-		care when forwarding control frames e.g. 802.1X-PAE or LLDP.
 What:		/sys/class/net/<iface>/broadcast
 Date:		April 2005
 KernelVersion:	2.6.12
 		Indicates the interface unique physical port identifier within
 		the NIC, as a string.
-What:		/sys/class/net/<iface>/phys_port_name
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	netdev@vger.kernel.org
-Description:
-		Indicates the interface physical port name within the NIC,
-		as a string.
 What:		/sys/class/net/<iface>/speed
 Date:		October 2009
 KernelVersion:	2.6.33
 Description:
 		Indicates the interface protocol type as a decimal value. See
 		include/uapi/linux/if_arp.h for all possible values.
-What:		/sys/class/net/<iface>/phys_switch_id
-Date:		November 2014
-KernelVersion:	3.19
-Contact:	netdev@vger.kernel.org
-Description:
-		Indicates the unique physical switch identifier of a switch this
-		port belongs to, as a string.

19

Documentation/ABI/testing/sysfs-class-net-janz-ican3

View File

-What:		/sys/class/net/<iface>/termination
-Date:		May 2010
-KernelVersion:	2.6.35
-Contact:	Ira W. Snyder <ira.snyder@gmail.com>
-Description:
-		Value representing the can bus termination
-		Default: 1 (termination active)
-		Reading: get actual termination state
-		Writing: set actual termination state (0=no termination, 1=termination active)
-What:		/sys/class/net/<iface>/fwinfo
-Date:		May 2015
-KernelVersion:	3.19
-Contact:	Andreas Gröger <andreas24groeger@gmail.com>
-Description:
-		Firmware stamp of ican3 module
-		Read-only: 32 byte string identification of the ICAN3 module
-		(known values: "JANZ-ICAN3 ICANOS 1.xx", "JANZ-ICAN3 CAL/CANopen 1.xx")

8

Documentation/ABI/testing/sysfs-class-net-queues

View File

 		Indicates the number of transmit timeout events seen by this
 		network interface transmit queue.
-What:		/sys/class/<iface>/queues/tx-<queue>/tx_maxrate
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	netdev@vger.kernel.org
-Description:
-		A Mbps max-rate set for the queue, a value of zero means disabled,
-		default is disabled.
 What:		/sys/class/<iface>/queues/tx-<queue>/xps_cpus
 Date:		November 2010
 KernelVersion:	2.6.38

100

Documentation/ABI/testing/sysfs-class-power

View File

 		Valid values:
 		- 5, 6 or 7 (hours),
 		- 0: disabled.
-What:		/sys/class/power_supply/max77693-charger/device/fast_charge_timer
-Date:		January 2015
-KernelVersion:	3.19.0
-Contact:	Krzysztof Kozlowski <k.kozlowski@samsung.com>
-Description:
-		This entry shows and sets the maximum time the max77693
-		charger operates in fast-charge mode. When the timer expires
-		the device will terminate fast-charge mode (charging current
-		will drop to 0 A) and will trigger interrupt.
-		Valid values:
-		- 4 - 16 (hours), step by 2 (rounded down)
-		- 0: disabled.
-What:		/sys/class/power_supply/max77693-charger/device/top_off_threshold_current
-Date:		January 2015
-KernelVersion:	3.19.0
-Contact:	Krzysztof Kozlowski <k.kozlowski@samsung.com>
-Description:
-		This entry shows and sets the charging current threshold for
-		entering top-off charging mode. When charging current in fast
-		charge mode drops below this value, the charger will trigger
-		interrupt and start top-off charging mode.
-		Valid values:
-		- 100000 - 200000 (microamps), step by 25000 (rounded down)
-		- 200000 - 350000 (microamps), step by 50000 (rounded down)
-		- 0: disabled.
-What:		/sys/class/power_supply/max77693-charger/device/top_off_timer
-Date:		January 2015
-KernelVersion:	3.19.0
-Contact:	Krzysztof Kozlowski <k.kozlowski@samsung.com>
-Description:
-		This entry shows and sets the maximum time the max77693
-		charger operates in top-off charge mode. When the timer expires
-		the device will terminate top-off charge mode (charging current
-		will drop to 0 A) and will trigger interrupt.
-		Valid values:
-		- 0 - 70 (minutes), step by 10 (rounded down)
-What:		/sys/class/power_supply/bq24257-charger/ovp_voltage
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry configures the overvoltage protection feature of bq24257-
-		type charger devices. This feature protects the device and other
-		components against damage from overvoltage on the input supply. See
-		device datasheet for details.
-		Valid values:
-		- 6000000, 6500000, 7000000, 8000000, 9000000, 9500000, 10000000,
-		  10500000 (all uV)
-What:		/sys/class/power_supply/bq24257-charger/in_dpm_voltage
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry configures the input dynamic power path management voltage of
-		bq24257-type charger devices. Once the supply drops to the configured
-		voltage, the input current limit is reduced down to prevent the further
-		drop of the supply. When the IC enters this mode, the charge current is
-		lower than the set value. See device datasheet for details.
-		Valid values:
-		- 4200000, 4280000, 4360000, 4440000, 4520000, 4600000, 4680000,
-		  4760000 (all uV)
-What:		/sys/class/power_supply/bq24257-charger/high_impedance_enable
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry allows enabling the high-impedance mode of bq24257-type
-		charger devices. If enabled, it places the charger IC into low power
-		standby mode with the switch mode controller disabled. When disabled,
-		the charger operates normally. See device datasheet for details.
-		Valid values:
-		- 1: enabled
-		- 0: disabled
-What:		/sys/class/power_supply/bq24257-charger/sysoff_enable
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry allows enabling the sysoff mode of bq24257-type charger
-		devices. If enabled and the input is removed, the internal battery FET
-		is turned off in order to reduce the leakage from the BAT pin to less
-		than 1uA. Note that on some devices/systems this disconnects the battery
-		from the system. See device datasheet for details.
-		Valid values:
-		- 1: enabled
-		- 0: disabled

45

Documentation/ABI/testing/sysfs-class-power-twl4030

View File

-What: /sys/class/power_supply/twl4030_ac/max_current
-      /sys/class/power_supply/twl4030_usb/max_current
-Description:
-	Read/Write limit on current which may
-	be drawn from the ac (Accessory Charger) or
-	USB port.
-	Value is in micro-Amps.
-	Value is set automatically to an appropriate
-	value when a cable is plugged or unplugged.
-	Value can the set by writing to the attribute.
-	The change will only persist until the next
-	plug event.  These event are reported via udev.
-What: /sys/class/power_supply/twl4030_usb/mode
-Description:
-	Changing mode for USB port.
-	Writing to this can disable charging.
-	Possible values are:
-		"auto" - draw power as appropriate for detected
-			 power source and battery status.
-		"off"  - do not draw any power.
-		"continuous"
-		       - activate mode described as "linear" in
-		         TWL data sheets.  This uses whatever
-			 current is available and doesn't switch off
-			 when voltage drops.
-			 This is useful for unstable power sources
-			 such as bicycle dynamo, but care should
-			 be taken that battery is not over-charged.
-What: /sys/class/power_supply/twl4030_ac/mode
-Description:
-	Changing mode for 'ac' port.
-	Writing to this can disable charging.
-	Possible values are:
-		"auto" - draw power as appropriate for detected
-			 power source and battery status.
-		"off"  - do not draw any power.

109

Documentation/ABI/testing/sysfs-class-scsi_tape

View File

-What:           /sys/class/scsi_tape/*/stats/in_flight
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Show the number of I/Os currently in-flight between the st
-		module and the SCSI mid-layer.
-Users:
-What:           /sys/class/scsi_tape/*/stats/io_ns
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time spent waiting for all I/O
-                to and from the tape drive to complete. This includes all
-                reads, writes, and other SCSI commands issued to the tape
-                drive. An example of other SCSI commands would be tape
-                movement such as a rewind when a rewind tape device is
-                closed. This item is measured in nanoseconds.
-                To determine the amount of time spent waiting for other I/O
-                to complete subtract read_ns and write_ns from this value.
-Users:
-What:           /sys/class/scsi_tape/*/stats/other_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		The number of I/O requests issued to the tape drive other
-		than SCSI read/write requests.
-Users:
-What:           /sys/class/scsi_tape/*/stats/read_byte_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of bytes requested from the tape drive.
-		This value is presented in bytes because tape drives support
-		variable length block sizes.
-Users:
-What:           /sys/class/scsi_tape/*/stats/read_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of read requests issued to the tape
-		drive.
-Users:
-What:           /sys/class/scsi_tape/*/stats/read_ns
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time in nanoseconds waiting for
-		read I/O requests to complete.
-Users:
-What:           /sys/class/scsi_tape/*/stats/write_byte_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of bytes written to the tape drive.
-		This value is presented in bytes because tape drives support
-		variable length block sizes.
-Users:
-What:           /sys/class/scsi_tape/*/stats/write_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of write requests issued to the tape
-		drive.
-Users:
-What:           /sys/class/scsi_tape/*/stats/write_ms
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time in nanoseconds waiting for
-		write I/O requests to complete.
-Users:
-What:           /sys/class/scsi_tape/*/stats/resid_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the number of times we found that a residual >0
-		was found when the SCSI midlayer indicated that there was
-		an error. For reads this may be a case of someone issuing
-		reads greater than the block size.
-Users:

14

Documentation/ABI/testing/sysfs-class-stm

View File

-What:		/sys/class/stm/<stm>/masters
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		Shows first and last available to software master numbers on
-		this STM device.
-What:		/sys/class/stm/<stm>/channels
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		Shows the number of channels per master on this STM device.

11

Documentation/ABI/testing/sysfs-class-stm_source

View File

-What:		/sys/class/stm_source/<stm_source>/stm_source_link
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		stm_source device linkage to stm device, where its tracing data
-		is directed. Reads return an existing connection or "<none>" if
-		this stm_source is not connected to any stm device yet.
-		Write an existing (registered) stm device's name here to
-		connect that device. If a device is already connected to this
-		stm_source, it will first be disconnected.

24

Documentation/ABI/testing/sysfs-class-zram

View File

-What:		/sys/class/zram-control/
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The zram-control/ class sub-directory belongs to zram
-		device class
-What:		/sys/class/zram-control/hot_add
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		RO attribute. Read operation will cause zram to add a new
-		device and return its device id back to user (so one can
-		use /dev/zram<id>), or error code.
-What:		/sys/class/zram-control/hot_remove
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		WO attribute. Remove a specific /dev/zramX device, where X
-		is a device_id provided by user.

49

Documentation/ABI/testing/sysfs-devices-system-cpu

View File

 What:		/sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
 Date:		August 2008
 KernelVersion:	2.6.27
-Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Contact:	discuss@x86-64.org
 Description:	Disable L3 cache indices
 		These files exist in every CPU's cache/index3 directory. Each
 		frequency range.
 		More details can be found in Documentation/cpu-freq/intel-pstate.txt
-What:		/sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below>
-Date:		July 2014(documented, existed before August 2008)
-Contact:	Sudeep Holla <sudeep.holla@arm.com>
-		Linux kernel mailing list <linux-kernel@vger.kernel.org>
-Description:	Parameters for the CPU cache attributes
-		allocation_policy:
-			- WriteAllocate: allocate a memory location to a cache line
-					 on a cache miss because of a write
-			- ReadAllocate: allocate a memory location to a cache line
-					on a cache miss because of a read
-			- ReadWriteAllocate: both writeallocate and readallocate
-		attributes: LEGACY used only on IA64 and is same as write_policy
-		coherency_line_size: the minimum amount of data in bytes that gets
-				     transferred from memory to cache
-		level: the cache hierarchy in the multi-level cache configuration
-		number_of_sets: total number of sets in the cache, a set is a
-				collection of cache lines with the same cache index
-		physical_line_partition: number of physical cache line per cache tag
-		shared_cpu_list: the list of logical cpus sharing the cache
-		shared_cpu_map: logical cpu mask containing the list of cpus sharing
-				the cache
-		size: the total cache size in kB
-		type:
-			- Instruction: cache that only holds instructions
-			- Data: cache that only caches data
-			- Unified: cache that holds both data and instructions
-		ways_of_associativity: degree of freedom in placing a particular block
-					of memory in the cache
-		write_policy:
-			- WriteThrough: data is written to both the cache line
-					and to the block in the lower-level memory
-			- WriteBack: data is written only to the cache line and
-				     the modified cache line is written to main
-				     memory only when it is replaced

10

Documentation/ABI/testing/sysfs-driver-hid

View File

 		report descriptor.
 		This file cannot be written.
 Users:		HIDAPI library (http://www.signal11.us/oss/hidapi)
-What:		For USB devices	: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
-		For BT devices	: /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
-		Symlink		: /sys/class/hidraw/hidraw<num>/device/country
-Date:		February 2015
-KernelVersion:	3.19
-Contact:	Olivier Gay <ogay@logitech.com>
-Description:	When read, this file returns the hex integer value in ASCII
-		of the device's HID country code (e.g. 21 for US).
-		This file cannot be written.

15

Documentation/ABI/testing/sysfs-driver-hid-corsair

View File

-What:		/sys/bus/drivers/corsair/<dev>/macro_mode
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Clement Vuchener <clement.vuchener@gmail.com>
-Description:	Get/set the current playback mode. "SW" for software mode
-		where G-keys triggers their regular key codes. "HW" for
-		hardware playback mode where the G-keys play their macro
-		from the on-board memory.
-What:		/sys/bus/drivers/corsair/<dev>/current_profile
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Clement Vuchener <clement.vuchener@gmail.com>
-Description:	Get/set the current selected profile. Values are from 1 to 3.

49

Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff

View File

-What:		/sys/bus/hid/drivers/logitech/<dev>/range
+What:		/sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
 Date:		July 2011
 KernelVersion:	3.2
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
+Contact:	Michal Malý <madcatxster@gmail.com>
 Description:	Display minimum, maximum and current range of the steering
 		wheel. Writing a value within min and max boundaries sets the
 		range of the wheel.
-What:		/sys/bus/hid/drivers/logitech/<dev>/alternate_modes
-Date:		Feb 2015
-KernelVersion:	4.1
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
-Description:	Displays a set of alternate modes supported by a wheel. Each
-		mode is listed as follows:
-		  Tag: Mode Name
-		Currently active mode is marked with an asterisk. List also
-		contains an abstract item "native" which always denotes the
-		native mode of the wheel. Echoing the mode tag switches the
-		wheel into the corresponding mode. Depending on the exact model
-		of the wheel not all listed modes might always be selectable.
-		If a wheel cannot be switched into the desired mode, -EINVAL
-		is returned accompanied with an explanatory message in the
-		kernel log.
-		This entry is not created for devices that have only one mode.
-		Currently supported mode switches:
-		Driving Force Pro:
-		  DF-EX --> DFP
-		G25:
-		  DF-EX --> DFP --> G25
-		G27:
-		  DF-EX <*> DFP <-> G25 <-> G27
-		  DF-EX <*--------> G25 <-> G27
-		  DF-EX <*----------------> G27
-		DFGT:
-		  DF-EX <*> DFP <-> DFGT
-		  DF-EX <*--------> DFGT
-		* hid_logitech module must be loaded with lg4ff_no_autoswitch=1
-		  parameter set in order for the switch to DF-EX mode to work.
-What:		/sys/bus/hid/drivers/logitech/<dev>/real_id
-Date:		Feb 2015
-KernelVersion:	4.1
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
-Description:	Displays the real model of the wheel regardless of any
-		alternate mode the wheel might be switched to.
-		It is a read-only value.
-		This entry is not created for devices that have only one mode.

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo → Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo

View File

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku → Documentation/ABI/testing/sysfs-driver-hid-roccat-isku

View File

96

Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus Normal file

View File

+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The integer value of this attribute ranges from 0-4.
+                When read, this attribute returns the number of the actual
+                profile. This value is persistent, so its equivalent to the
+                profile that's active when the mouse is powered on next time.
+		When written, this file sets the number of the startup profile
+		and the mouse activates this profile immediately.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info
+Date:		November 2012
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read, this file returns general data like firmware version.
+		When written, the device can be reset.
+		The data is 8 bytes long.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store a macro with max 500 key/button strokes
+		internally.
+		When written, this file lets one set the sequence for a specific
+		button for a specific profile. Button and profile numbers are
+		included in written data. The data has to be 2082 bytes long.
+		This file is writeonly.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons
+Date:		August 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_buttons holds information about button layout.
+		When written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 77 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_settings holds information like resolution, sensitivity
+		and light effects.
+		When written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 43 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse has a tracking- and a distance-control-unit. These
+		can be activated/deactivated and the lift-off distance can be
+		set. The data has to be 6 bytes long.
+		This file is writeonly.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk
+Date:		May 2011
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	Used to active some easy* functions of the mouse from outside.
+		The data has to be 16 bytes long.
+		This file is writeonly.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When written a calibration process for the tracking control unit
+		can be initiated/cancelled. Also lets one read/write sensor
+		registers.
+		The data has to be 4 bytes long.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read the mouse returns a 30x30 pixel image of the
+		sampled underground. This works only in the course of a
+		calibration process initiated with tcu.
+		The returned data is 1028 bytes in size.
+		This file is readonly.
+Users:		http://roccat.sourceforge.net

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure → Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure

View File

49

Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus Normal file

View File

+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile
+Date:		January 2011
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The integer value of this attribute ranges from 0-4.
+		When read, this attribute returns the number of the active
+		profile.
+		When written, the mouse activates this profile immediately.
+		The profile that's active when powered down is the same that's
+		active when the mouse is powered on.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info
+Date:		November 2012
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read, this file returns general data like firmware version.
+		When written, the device can be reset.
+		The data is 6 bytes long.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons
+Date:		January 2011
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_buttons holds information about button layout.
+		When written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 23 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings
+Date:		January 2011
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_settings holds information like resolution, sensitivity
+		and light effects.
+		When written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 16 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua → Documentation/ABI/testing/sysfs-driver-hid-roccat-lua

View File

49

Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra Normal file

View File

+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
+Date:		November 2012
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read, this file returns general data like firmware version.
+		When written, the device can be reset.
+		The data is 6 bytes long.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
+Date:		August 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_settings holds information like resolution, sensitivity
+		and light effects.
+		When written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 13 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
+Date:		August 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store 5 profiles which can be switched by the
+		press of a button. A profile is split in settings and buttons.
+		profile_buttons holds information about button layout.
+		When written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 19 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
+Date:		August 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read, this file returns the settings stored in the mouse.
+		The size of the data is 3 bytes and holds information on the
+		startup_profile.
+		When written, this file lets write settings back to the mouse.
+		The data has to be 3 bytes long. The mouse will reject invalid
+		data.
+Users:		http://roccat.sourceforge.net

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos → Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos

View File

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu → Documentation/ABI/testing/sysfs-driver-hid-roccat-savu

View File

11

Documentation/ABI/testing/sysfs-driver-input-axp-pek

View File

-What:		/sys/class/input/input(x)/device/startup
-Date:		March 2014
-Contact:	Carlo Caione <carlo@caione.org>
-Description:	Startup time in us. Board is powered on if the button is pressed
-		for more than <startup_time>
-What:		/sys/class/input/input(x)/device/shutdown
-Date:		March 2014
-Contact:	Carlo Caione <carlo@caione.org>
-Description:	Shutdown time in us. Board is powered off if the button is pressed
-		for more than <shutdown_time>

19

Documentation/ABI/testing/sysfs-driver-ppi

View File

-What:		/sys/class/tpm/tpmX/ppi/
+What:		/sys/devices/pnp0/<bus-num>/ppi/
 Date:		August 2012
 Kernel Version:	3.6
 Contact:	xiaoyan.zhang@intel.com
 		folder makes sense. The folder path can be got by command
 		'find /sys/ -name 'pcrs''. For the detail information of PPI,
 		please refer to the PPI specification from
 		http://www.trustedcomputinggroup.org/
-		In Linux 4.2 ppi was moved to the character device directory.
+What:		/sys/devices/pnp0/<bus-num>/ppi/version
-		A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards
-		compatibility.
-What:		/sys/class/tpm/tpmX/ppi/version
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
 		platform.
 		This file is readonly.
-What:		/sys/class/tpm/tpmX/ppi/request
+What:		/sys/devices/pnp0/<bus-num>/ppi/request
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
 		integer value range from 1 to 160, and 0 means no request.
 		This file can be read and written.
-What:		/sys/class/tpm/tpmX/ppi/response
+What:		/sys/devices/pnp0/00:<bus-num>/ppi/response
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
 		: <response description>".
 		This file is readonly.
-What:		/sys/class/tpm/tpmX/ppi/transition_action
+What:		/sys/devices/pnp0/<bus-num>/ppi/transition_action
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
 		description>".
 		This file is readonly.
-What:		/sys/class/tpm/tpmX/ppi/tcg_operations
+What:		/sys/devices/pnp0/<bus-num>/ppi/tcg_operations
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
 		This attribute is only supported by PPI version 1.2+.
 		This file is readonly.
-What:		/sys/class/tpm/tpmX/ppi/vs_operations
+What:		/sys/devices/pnp0/<bus-num>/ppi/vs_operations
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:

8

Documentation/ABI/testing/sysfs-driver-samsung-laptop

View File

 Description:	Use your USB ports to charge devices, even
 		when your laptop is powered off.
 means enabled, 0 means disabled.
-What:		/sys/devices/platform/samsung/lid_handling
-Date:		December 11, 2014
-KernelVersion:	3.19
-Contact:	Julijonas Kikutis <julijonas.kikutis@gmail.com>
-Description:	Some Samsung laptops handle lid closing quicker and
-		only handle lid opening with this mode enabled.
-means enabled, 0 means disabled.

12

Documentation/ABI/testing/sysfs-driver-st

View File

-What:		/sys/bus/scsi/drivers/st/debug_flag
-Date:		October 2015
-Kernel Version:	?.?
-Contact:	shane.seymour@hpe.com
-Description:
-		This file allows you to turn debug output from the st driver
-		off if you write a '0' to the file or on if you write a '1'.
-		Note that debug output requires that the module be compiled
-		with the #define DEBUG set to a non-zero value (this is the
-		default). If DEBUG is set to 0 then this file will not
-		appear in sysfs as its presence is conditional upon debug
-		output support being compiled into the module.

22

Documentation/ABI/testing/sysfs-driver-sunxi-sid Normal file

View File

+What:		/sys/devices/*/<our-device>/eeprom
+Date:		August 2013
+Contact:	Oliver Schinagl <oliver@schinagl.nl>
+Description:	read-only access to the SID (Security-ID) on current
+		A-series SoC's from Allwinner. Currently supports A10, A10s, A13
+		and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
+		whereas the newer A20 SoC exposes 512 bytes split into sections.
+		Besides the 16 bytes of SID, there's also an SJTAG area,
+		HDMI-HDCP key and some custom keys. Below a quick overview, for
+		details see the user manual:
+x000  128 bit root-key (sun[457]i)
+x010  128 bit boot-key (sun7i)
+x020   64 bit security-jtag-key (sun7i)
+x028   16 bit key configuration (sun7i)
+x02b   16 bit custom-vendor-key (sun7i)
+x02c  320 bit low general key (sun7i)
+x040   32 bit read-control access (sun7i)
+x064  224 bit low general key (sun7i)
+x080 2304 bit HDCP-key (sun7i)
+x1a0  768 bit high general key (sun7i)
+Users:		any user space application which wants to read the SID on
+		Allwinner's A-series of CPU's.

181

Documentation/ABI/testing/sysfs-driver-toshiba_acpi

View File

-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_mode
-Date:		June 8, 2014
-KernelVersion:	3.15
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the keyboard backlight operation mode, valid
-		values are:
-			* 0x1  -> FN-Z
-			* 0x2  -> AUTO (also called TIMER)
-			* 0x8  -> ON
-			* 0x10 -> OFF
-		Note that from kernel 3.16 onwards this file accepts all listed
-		parameters, kernel 3.15 only accepts the first two (FN-Z and
-		AUTO).
-		Also note that toggling this value on type 1 devices, requires
-		a reboot for changes to take effect.
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
-Date:		June 8, 2014
-KernelVersion:	3.15
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the timeout of the keyboard backlight
-		whenever the operation mode is set to AUTO (or TIMER),
-		valid values range from 0-60.
-		Note that the kernel 3.15 only had support for the first
-		keyboard type, the kernel 3.16 added support for the second
-		type and the range accepted for type 2 is 1-60.
-		See the entry named "kbd_type"
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/position
-Date:		June 8, 2014
-KernelVersion:	3.15
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file shows the absolute position of the built-in
-		accelereometer.
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/touchpad
-Date:		June 8, 2014
-KernelVersion:	3.15
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This files controls the status of the touchpad and pointing
-		stick (if available), valid values are:
-			* 0 -> OFF
-			* 1 -> ON
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/available_kbd_modes
-Date:		August 3, 2014
-KernelVersion:	3.16
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file shows the supported keyboard backlight modes
-		the system supports, which can be:
-			* 0x1  -> FN-Z
-			* 0x2  -> AUTO (also called TIMER)
-			* 0x8  -> ON
-			* 0x10 -> OFF
-		Note that not all keyboard types support the listed modes.
-		See the entry named "available_kbd_modes"
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_type
-Date:		August 3, 2014
-KernelVersion:	3.16
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file shows the current keyboard backlight type,
-		which can be:
-			* 1 -> Type 1, supporting modes FN-Z and AUTO
-			* 2 -> Type 2, supporting modes TIMER, ON and OFF
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Sleep & Charge charging mode, which
-		can be:
-			* 0 -> Disabled		(0x00)
-			* 1 -> Alternate	(0x09)
-			* 2 -> Auto		(0x21)
-			* 3 -> Typical		(0x11)
-		Note that from kernel 4.1 onwards this file accepts all listed
-		values, kernel 4.0 only supports the first three.
-		Note that this feature only works when connected to power, if
-		you want to use it under battery, see the entry named
-		"sleep_functions_on_battery"
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Sleep Functions under battery, and
-		set the level at which point they will be disabled, accepted
-		values can be:
-			* 0	-> Disabled
-			* 1-100	-> Battery level to disable sleep functions
-		Currently it prints two values, the first one indicates if the
-		feature is enabled or disabled, while the second one shows the
-		current battery level set.
-		Note that when the value is set to disabled, the sleep function
-		will only work when connected to power.
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Rapid Charge state, which can be:
-			* 0 -> Disabled
-			* 1 -> Enabled
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the Sleep & Music state, which values can be:
-			* 0 -> Disabled
-			* 1 -> Enabled
-		Note that this feature only works when connected to power, if
-		you want to use it under battery, see the entry named
-		"sleep_functions_on_battery"
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
-Date:		February 12, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file shows the current version of the driver
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
-Date:		February 12, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the state of the internal fan, valid
-		values are:
-			* 0 -> OFF
-			* 1 -> ON
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
-Date:		February 12, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the Special Functions (hotkeys) operation
-		mode, valid values are:
-			* 0 -> Normal Operation
-			* 1 -> Special Functions
-		In the "Normal Operation" mode, the F{1-12} keys are as usual
-		and the hotkeys are accessed via FN-F{1-12}.
-		In the "Special Functions" mode, the F{1-12} keys trigger the
-		hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
-Date:		February 12, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls whether the laptop should turn ON whenever
-		the LID is opened, valid values are:
-			* 0 -> Disabled
-			* 1 -> Enabled
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
-Date:		February 12, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB 3 functionality, valid values are:
-			* 0 -> Disabled (Acts as a regular USB 2)
-			* 1 -> Enabled (Full USB 3 functionality)
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba

20

Documentation/ABI/testing/sysfs-driver-toshiba_haps

View File

-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
-Date:		August 16, 2014
-KernelVersion:	3.17
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the built-in accelerometer protection level,
-		valid values are:
-			* 0 -> Disabled
-			* 1 -> Low
-			* 2 -> Medium
-			* 3 -> High
-		The default potection value is set to 2 (Medium).
-Users:		KToshiba
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
-Date:		August 16, 2014
-KernelVersion:	3.17
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file turns off the built-in accelerometer for a few
-		seconds and then restore normal operation. Accepting 1 as the
-		only parameter.

19

Documentation/ABI/testing/sysfs-driver-wacom

View File

 		The format is also scrambled, like in the USB mode, and it can
 		be summarized by converting 76543210 into GECA6420.
 					    HGFEDCBA      HFDB7531
-What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/unpair_remote
-Date:		July 2015
-Contact:	linux-input@vger.kernel.org
-Description:
-		Writing the character sequence '*' followed by a newline to
-		this file will delete all of the current pairings on the
-		device. Other character sequences are reserved. This file is
-		write only.
-What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/remote_mode
-Date:		July 2015
-Contact:	linux-input@vger.kernel.org
-Description:
-		Reading from this file reports the mode status of the
-		remote as indicated by the LED lights on the device. If no
-		reports have been received from the paired device, reading
-		from this file will report '-1'. The mode is read-only
-		and cannot be set through the driver.

110

Documentation/ABI/testing/sysfs-firmware-dmi Normal file

View File

+What:		/sys/firmware/dmi/
+Date:		February 2011
+Contact:	Mike Waychison <mikew@google.com>
+Description:
+		Many machines' firmware (x86 and ia64) export DMI /
+		SMBIOS tables to the operating system.  Getting at this
+		information is often valuable to userland, especially in
+		cases where there are OEM extensions used.
+		The kernel itself does not rely on the majority of the
+		information in these tables being correct.  It equally
+		cannot ensure that the data as exported to userland is
+		without error either.
+		DMI is structured as a large table of entries, where
+		each entry has a common header indicating the type and
+		length of the entry, as well as a firmware-provided
+		'handle' that is supposed to be unique amongst all
+		entries.
+		Some entries are required by the specification, but many
+		others are optional.  In general though, users should
+		never expect to find a specific entry type on their
+		system unless they know for certain what their firmware
+		is doing.  Machine to machine experiences will vary.
+		Multiple entries of the same type are allowed.  In order
+		to handle these duplicate entry types, each entry is
+		assigned by the operating system an 'instance', which is
+		derived from an entry type's ordinal position.  That is
+		to say, if there are 'N' multiple entries with the same type
+		'T' in the DMI tables (adjacent or spread apart, it
+		doesn't matter), they will be represented in sysfs as
+		entries "T-0" through "T-(N-1)":
+		Example entry directories:
+			/sys/firmware/dmi/entries/17-0
+			/sys/firmware/dmi/entries/17-1
+			/sys/firmware/dmi/entries/17-2
+			/sys/firmware/dmi/entries/17-3
+			...
+		Instance numbers are used in lieu of the firmware
+		assigned entry handles as the kernel itself makes no
+		guarantees that handles as exported are unique, and
+		there are likely firmware images that get this wrong in
+		the wild.
+		Each DMI entry in sysfs has the common header values
+		exported as attributes:
+		handle	: The 16bit 'handle' that is assigned to this
+			  entry by the firmware.  This handle may be
+			  referred to by other entries.
+		length	: The length of the entry, as presented in the
+			  entry itself.  Note that this is _not the
+			  total count of bytes associated with the
+			  entry_.  This value represents the length of
+			  the "formatted" portion of the entry.  This
+			  "formatted" region is sometimes followed by
+			  the "unformatted" region composed of nul
+			  terminated strings, with termination signalled
+			  by a two nul characters in series.
+		raw	: The raw bytes of the entry. This includes the
+			  "formatted" portion of the entry, the
+			  "unformatted" strings portion of the entry,
+			  and the two terminating nul characters.
+		type	: The type of the entry.  This value is the same
+			  as found in the directory name.  It indicates
+			  how the rest of the entry should be interpreted.
+		instance: The instance ordinal of the entry for the
+			  given type.  This value is the same as found
+			  in the parent directory name.
+		position: The ordinal position (zero-based) of the entry
+			  within the entirety of the DMI entry table.
+		=== Entry Specialization ===
+		Some entry types may have other information available in
+		sysfs.  Not all types are specialized.
+		--- Type 15 - System Event Log ---
+		This entry allows the firmware to export a log of
+		events the system has taken.  This information is
+		typically backed by nvram, but the implementation
+		details are abstracted by this table.  This entry's data
+		is exported in the directory:
+		/sys/firmware/dmi/entries/15-0/system_event_log
+		and has the following attributes (documented in the
+		SMBIOS / DMI specification under "System Event Log (Type 15)":
+		area_length
+		header_start_offset
+		data_start_offset
+		access_method
+		status
+		change_token
+		access_method_address
+		header_format
+		per_log_type_descriptor_length
+		type_descriptors_supported_count
+		As well, the kernel exports the binary attribute:
+		raw_event_log	: The raw binary bits of the event log
+				  as described by the DMI entry.

110

Documentation/ABI/testing/sysfs-firmware-dmi-entries

View File

-What:		/sys/firmware/dmi/entries/
-Date:		February 2011
-Contact:	Mike Waychison <mikew@google.com>
-Description:
-		Many machines' firmware (x86 and ia64) export DMI /
-		SMBIOS tables to the operating system.  Getting at this
-		information is often valuable to userland, especially in
-		cases where there are OEM extensions used.
-		The kernel itself does not rely on the majority of the
-		information in these tables being correct.  It equally
-		cannot ensure that the data as exported to userland is
-		without error either.
-		DMI is structured as a large table of entries, where
-		each entry has a common header indicating the type and
-		length of the entry, as well as a firmware-provided
-		'handle' that is supposed to be unique amongst all
-		entries.
-		Some entries are required by the specification, but many
-		others are optional.  In general though, users should
-		never expect to find a specific entry type on their
-		system unless they know for certain what their firmware
-		is doing.  Machine to machine experiences will vary.
-		Multiple entries of the same type are allowed.  In order
-		to handle these duplicate entry types, each entry is
-		assigned by the operating system an 'instance', which is
-		derived from an entry type's ordinal position.  That is
-		to say, if there are 'N' multiple entries with the same type
-		'T' in the DMI tables (adjacent or spread apart, it
-		doesn't matter), they will be represented in sysfs as
-		entries "T-0" through "T-(N-1)":
-		Example entry directories:
-			/sys/firmware/dmi/entries/17-0
-			/sys/firmware/dmi/entries/17-1
-			/sys/firmware/dmi/entries/17-2
-			/sys/firmware/dmi/entries/17-3
-			...
-		Instance numbers are used in lieu of the firmware
-		assigned entry handles as the kernel itself makes no
-		guarantees that handles as exported are unique, and
-		there are likely firmware images that get this wrong in
-		the wild.
-		Each DMI entry in sysfs has the common header values
-		exported as attributes:
-		handle	: The 16bit 'handle' that is assigned to this
-			  entry by the firmware.  This handle may be
-			  referred to by other entries.
-		length	: The length of the entry, as presented in the
-			  entry itself.  Note that this is _not the
-			  total count of bytes associated with the
-			  entry_.  This value represents the length of
-			  the "formatted" portion of the entry.  This
-			  "formatted" region is sometimes followed by
-			  the "unformatted" region composed of nul
-			  terminated strings, with termination signalled
-			  by a two nul characters in series.
-		raw	: The raw bytes of the entry. This includes the
-			  "formatted" portion of the entry, the
-			  "unformatted" strings portion of the entry,
-			  and the two terminating nul characters.
-		type	: The type of the entry.  This value is the same
-			  as found in the directory name.  It indicates
-			  how the rest of the entry should be interpreted.
-		instance: The instance ordinal of the entry for the
-			  given type.  This value is the same as found
-			  in the parent directory name.
-		position: The ordinal position (zero-based) of the entry
-			  within the entirety of the DMI entry table.
-		=== Entry Specialization ===
-		Some entry types may have other information available in
-		sysfs.  Not all types are specialized.
-		--- Type 15 - System Event Log ---
-		This entry allows the firmware to export a log of
-		events the system has taken.  This information is
-		typically backed by nvram, but the implementation
-		details are abstracted by this table.  This entry's data
-		is exported in the directory:
-		/sys/firmware/dmi/entries/15-0/system_event_log
-		and has the following attributes (documented in the
-		SMBIOS / DMI specification under "System Event Log (Type 15)":
-		area_length
-		header_start_offset
-		data_start_offset
-		access_method
-		status
-		change_token
-		access_method_address
-		header_format
-		per_log_type_descriptor_length
-		type_descriptors_supported_count
-		As well, the kernel exports the binary attribute:
-		raw_event_log	: The raw binary bits of the event log
-				  as described by the DMI entry.

22

Documentation/ABI/testing/sysfs-firmware-dmi-tables

View File

-What:		/sys/firmware/dmi/tables/
-Date:		April 2015
-Contact:	Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
-Description:
-		The firmware provides DMI structures as a packed list of
-		data referenced by a SMBIOS table entry point. The SMBIOS
-		entry point contains general information, like SMBIOS
-		version, DMI table size, etc. The structure, content and
-		size of SMBIOS entry point is dependent on SMBIOS version.
-		The format of SMBIOS entry point and DMI structures
-		can be read in SMBIOS specification.
-		The dmi/tables provides raw SMBIOS entry point and DMI tables
-		through sysfs as an alternative to utilities reading them
-		from /dev/mem. The raw SMBIOS entry point and DMI table are
-		presented as binary attributes and are accessible via:
-		/sys/firmware/dmi/tables/smbios_entry_point
-		/sys/firmware/dmi/tables/DMI
-		The complete DMI information can be obtained using these two
-		tables.

10

Documentation/ABI/testing/sysfs-firmware-efi

View File

 Description:	It shows the physical address of config table entry in the EFI
 		system table.
 Users:		Kexec
-What:		/sys/firmware/efi/systab
-Date:		April 2005
-Contact:	linux-efi@vger.kernel.org
-Description:	Displays the physical addresses of all EFI Configuration
-		Tables found via the EFI System Table. The order in
-		which the tables are printed forms an ABI and newer
-		versions are always printed first, i.e. ACPI20 comes
-		before ACPI.
-Users:		dmidecode

81

Documentation/ABI/testing/sysfs-firmware-efi-esrt

View File

-What:		/sys/firmware/efi/esrt/
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Provides userland access to read the EFI System Resource Table
-		(ESRT), a catalog of firmware for which can be updated with
-		the UEFI UpdateCapsule mechanism described in section 7.5 of
-		the UEFI Standard.
-Users:		fwupdate - https://github.com/rhinstaller/fwupdate
-What:		/sys/firmware/efi/esrt/fw_resource_count
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The number of entries in the ESRT
-What:		/sys/firmware/efi/esrt/fw_resource_count_max
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The maximum number of entries that /could/ be registered
-		in the allocation the table is currently in.  This is
-		really only useful to the system firmware itself.
-What:		/sys/firmware/efi/esrt/fw_resource_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The version of the ESRT structure provided by the firmware.
-What:		/sys/firmware/efi/esrt/entries/entry$N/
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Each ESRT entry is identified by a GUID, and each gets a
-		subdirectory under entries/ .
-		example: /sys/firmware/efi/esrt/entries/entry0/
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_type
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	What kind of firmware entry this is:
-- Unknown
-- System Firmware
-- Device Firmware
-- UEFI Driver
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_class
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	This is the entry's guid, and will match the directory name.
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The version of the firmware currently installed.  This is a
--bit unsigned integer.
-What:		/sys/firmware/efi/esrt/entries/entry$N/lowest_supported_fw_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The lowest version of the firmware that can be installed.
-What:		/sys/firmware/efi/esrt/entries/entry$N/capsule_flags
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Flags that must be passed to UpdateCapsule()
-What:		/sys/firmware/efi/esrt/entries/entry$N/last_attempt_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The last firmware version for which an update was attempted.
-What:		/sys/firmware/efi/esrt/entries/entry$N/last_attempt_status
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The result of the last firmware update attempt for the
-		firmware resource entry.
-- Success
-- Insufficient resources
-- Incorrect version
-- Invalid format
-- Authentication error
-- AC power event
-- Battery power event

18

Documentation/ABI/testing/sysfs-fs-f2fs

View File

 Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
 Description:
 		 Controls the memory footprint used by f2fs.
-What:		/sys/fs/f2fs/<disk>/trim_sections
-Date:		February 2015
-Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
-Description:
-		 Controls the trimming rate in batch mode.
-What:		/sys/fs/f2fs/<disk>/cp_interval
-Date:		October 2015
-Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
-Description:
-		 Controls the checkpoint timing.
-What:		/sys/fs/f2fs/<disk>/ra_nid_pages
-Date:		October 2015
-Contact:	"Chao Yu" <chao2.yu@samsung.com>
-Description:
-		 Controls the count of nid pages to be readaheaded.

3

Documentation/ABI/testing/sysfs-gpio

View File

     /sys/class/gpio
 	/export ... asks the kernel to export a GPIO to userspace
 	/unexport ... to return a GPIO to the kernel
-	/gpioN ... for each exported GPIO #N OR
+	/gpioN ... for each exported GPIO #N
-	/<LINE-NAME> ... for a properly named GPIO line
 	    /value ... always readable, writes fail for input GPIOs
 	    /direction ... r/w as: in, out (default low); write: high, low
 	    /edge ... r/w as: none, falling, rising, both

Compare commits

1444 Commits raspberryp ... linux_stab

1 .get_maintainer.ignore Unescape Escape View File

16 .gitignore vendored Unescape Escape View File

17 .mailmap Unescape Escape View File

67 CREDITS Unescape Escape View File

28 Documentation/00-INDEX Unescape Escape View File

119 Documentation/ABI/obsolete/sysfs-block-zram Unescape Escape View File

97 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus Unescape Escape View File

50 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus Unescape Escape View File

50 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra Unescape Escape View File

14 Documentation/ABI/stable/sysfs-bus-usb Unescape Escape View File

29 Documentation/ABI/stable/sysfs-bus-vmbus Unescape Escape View File

11 Documentation/ABI/stable/sysfs-bus-w1 Unescape Escape View File

26 Documentation/ABI/stable/sysfs-class-tpm Unescape Escape View File

93 Documentation/ABI/stable/sysfs-class-udc Unescape Escape View File

10 Documentation/ABI/stable/sysfs-devices Unescape Escape View File

25 Documentation/ABI/stable/sysfs-driver-ib_srp Unescape Escape View File

6 Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 Unescape Escape View File

2 Documentation/ABI/stable/sysfs-firmware-opal-elog Unescape Escape View File

2 Documentation/ABI/testing/configfs-spear-pcie-gadget Unescape Escape View File

48 Documentation/ABI/testing/configfs-stp-policy Unescape Escape View File

11 Documentation/ABI/testing/configfs-usb-gadget-hid Unescape Escape View File

2 Documentation/ABI/testing/configfs-usb-gadget-loopback Unescape Escape View File

12 Documentation/ABI/testing/configfs-usb-gadget-midi Unescape Escape View File

9 Documentation/ABI/testing/configfs-usb-gadget-printer Unescape Escape View File

2 Documentation/ABI/testing/configfs-usb-gadget-sourcesink Unescape Escape View File

265 Documentation/ABI/testing/configfs-usb-gadget-uvc Unescape Escape View File

9 Documentation/ABI/testing/dev-kmsg Unescape Escape View File

26 Documentation/ABI/testing/ima_policy Unescape Escape View File

11 Documentation/ABI/testing/sysfs-ata Unescape Escape View File

7 Documentation/ABI/testing/sysfs-block Unescape Escape View File

22 Documentation/ABI/testing/sysfs-block-dm Unescape Escape View File

25 Documentation/ABI/testing/sysfs-block-zram Unescape Escape View File

20 Documentation/ABI/testing/sysfs-bus-amba Unescape Escape View File

24 Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10 Unescape Escape View File

322 Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x Unescape Escape View File

450 Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x Unescape Escape View File

12 Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel Unescape Escape View File

8 Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc Unescape Escape View File

6 Documentation/ABI/testing/sysfs-bus-event_source-devices-events Unescape Escape View File

22 Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 Unescape Escape View File

12 Documentation/ABI/testing/sysfs-bus-fcoe Unescape Escape View File

487 Documentation/ABI/testing/sysfs-bus-iio Unescape Escape View File

43 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 Unescape Escape View File

7 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x Unescape Escape View File

9 Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x Unescape Escape View File

8 Documentation/ABI/testing/sysfs-bus-iio-meas-spec Unescape Escape View File

31 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs Unescape Escape View File

7 Documentation/ABI/testing/sysfs-bus-iio-vf610 Unescape Escape View File

49 Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth Unescape Escape View File

33 Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc Unescape Escape View File

24 Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti Unescape Escape View File

13 Documentation/ABI/testing/sysfs-bus-intel_th-output-devices Unescape Escape View File

23 Documentation/ABI/testing/sysfs-bus-mei Unescape Escape View File

13 Documentation/ABI/testing/sysfs-bus-pci Unescape Escape View File

8 Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio Unescape Escape View File

55 Documentation/ABI/testing/sysfs-bus-usb Unescape Escape View File

12 Documentation/ABI/testing/sysfs-bus-usb-lvstest Unescape Escape View File

110 Documentation/ABI/testing/sysfs-class-cxl Unescape Escape View File

37 Documentation/ABI/testing/sysfs-class-fpga-manager Unescape Escape View File

80 Documentation/ABI/testing/sysfs-class-led-flash Unescape Escape View File

15 Documentation/ABI/testing/sysfs-class-mei Unescape Escape View File

29 Documentation/ABI/testing/sysfs-class-mic.txt Unescape Escape View File

10 Documentation/ABI/testing/sysfs-class-mtd Unescape Escape View File

35 Documentation/ABI/testing/sysfs-class-net Unescape Escape View File

19 Documentation/ABI/testing/sysfs-class-net-janz-ican3 Unescape Escape View File

8 Documentation/ABI/testing/sysfs-class-net-queues Unescape Escape View File

100 Documentation/ABI/testing/sysfs-class-power Unescape Escape View File

45 Documentation/ABI/testing/sysfs-class-power-twl4030 Unescape Escape View File

109 Documentation/ABI/testing/sysfs-class-scsi_tape Unescape Escape View File

14 Documentation/ABI/testing/sysfs-class-stm Unescape Escape View File

11 Documentation/ABI/testing/sysfs-class-stm_source Unescape Escape View File

24 Documentation/ABI/testing/sysfs-class-zram Unescape Escape View File

49 Documentation/ABI/testing/sysfs-devices-system-cpu Unescape Escape View File

10 Documentation/ABI/testing/sysfs-driver-hid Unescape Escape View File

15 Documentation/ABI/testing/sysfs-driver-hid-corsair Unescape Escape View File

49 Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff Unescape Escape View File

0 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo → Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo Unescape Escape View File

0 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku → Documentation/ABI/testing/sysfs-driver-hid-roccat-isku Unescape Escape View File

1444 Commits

raspberryp ... linux_stab

1

.get_maintainer.ignore

View File

16

.gitignore vendored

View File

17

.mailmap

View File

67

CREDITS

View File

28

Documentation/00-INDEX

View File

119

Documentation/ABI/obsolete/sysfs-block-zram

View File

97

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus

View File

50

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus

View File

50

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra

View File

14

Documentation/ABI/stable/sysfs-bus-usb

View File

29

Documentation/ABI/stable/sysfs-bus-vmbus

View File

11

Documentation/ABI/stable/sysfs-bus-w1

View File

26

Documentation/ABI/stable/sysfs-class-tpm

View File

93

Documentation/ABI/stable/sysfs-class-udc

View File

10

Documentation/ABI/stable/sysfs-devices

View File

25

Documentation/ABI/stable/sysfs-driver-ib_srp

View File

6

Documentation/ABI/stable/sysfs-driver-w1_ds28ea00

View File

2

Documentation/ABI/stable/sysfs-firmware-opal-elog

View File

2

Documentation/ABI/testing/configfs-spear-pcie-gadget

View File

48

Documentation/ABI/testing/configfs-stp-policy

View File

11

Documentation/ABI/testing/configfs-usb-gadget-hid

View File

2

Documentation/ABI/testing/configfs-usb-gadget-loopback

View File

12

Documentation/ABI/testing/configfs-usb-gadget-midi

View File

9

Documentation/ABI/testing/configfs-usb-gadget-printer

View File

2

Documentation/ABI/testing/configfs-usb-gadget-sourcesink

View File

265

Documentation/ABI/testing/configfs-usb-gadget-uvc

View File

9

Documentation/ABI/testing/dev-kmsg

View File

26

Documentation/ABI/testing/ima_policy

View File

11

Documentation/ABI/testing/sysfs-ata

View File

7

Documentation/ABI/testing/sysfs-block

View File

22

Documentation/ABI/testing/sysfs-block-dm

View File

25

Documentation/ABI/testing/sysfs-block-zram

View File

20

Documentation/ABI/testing/sysfs-bus-amba

View File

24

Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10

View File

322

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x

View File

450

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x

View File

12

Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel

View File

8

Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc

View File

6

Documentation/ABI/testing/sysfs-bus-event_source-devices-events

View File

22

Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7

View File

12

Documentation/ABI/testing/sysfs-bus-fcoe

View File

487

Documentation/ABI/testing/sysfs-bus-iio

View File

43

Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435

View File

7

Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x

View File

9

Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x

View File

8

Documentation/ABI/testing/sysfs-bus-iio-meas-spec

View File

31

Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs

View File

7

Documentation/ABI/testing/sysfs-bus-iio-vf610

View File

49

Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth

View File

33

Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc

View File

24

Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti

View File

13

Documentation/ABI/testing/sysfs-bus-intel_th-output-devices

View File

23

Documentation/ABI/testing/sysfs-bus-mei

View File

13

Documentation/ABI/testing/sysfs-bus-pci

View File

8

Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio

View File

55

Documentation/ABI/testing/sysfs-bus-usb

View File

12

Documentation/ABI/testing/sysfs-bus-usb-lvstest

View File

110

Documentation/ABI/testing/sysfs-class-cxl

View File

37

Documentation/ABI/testing/sysfs-class-fpga-manager

View File

80

Documentation/ABI/testing/sysfs-class-led-flash

View File

15

Documentation/ABI/testing/sysfs-class-mei

View File

29

Documentation/ABI/testing/sysfs-class-mic.txt

View File

10

Documentation/ABI/testing/sysfs-class-mtd

View File

35

Documentation/ABI/testing/sysfs-class-net

View File

19

Documentation/ABI/testing/sysfs-class-net-janz-ican3

View File

8

Documentation/ABI/testing/sysfs-class-net-queues

View File

100

Documentation/ABI/testing/sysfs-class-power

View File

45

Documentation/ABI/testing/sysfs-class-power-twl4030

View File

109

Documentation/ABI/testing/sysfs-class-scsi_tape

View File

14

Documentation/ABI/testing/sysfs-class-stm

View File

11

Documentation/ABI/testing/sysfs-class-stm_source

View File

24

Documentation/ABI/testing/sysfs-class-zram

View File

49

Documentation/ABI/testing/sysfs-devices-system-cpu

View File

10

Documentation/ABI/testing/sysfs-driver-hid

View File

15

Documentation/ABI/testing/sysfs-driver-hid-corsair

View File

49

Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff

View File

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo → Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo

View File

0

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku → Documentation/ABI/testing/sysfs-driver-hid-roccat-isku

View File

96

Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus Normal file

View File