- 06 Dec, 2014 40 commits
-
-
OGAWA Hirofumi authored
ratelimit_state initialization of printk_ratelimited() seems broken. This fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock properly. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Joe Perches <joe@perches.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit d8521fcc) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Yong Zhang authored
When __ratelimit() returns 1 this means that we can go ahead. Signed-off-by:
Yong Zhang <yong.zhang@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
This reverts commit c8cdf3f9, applied on linux 2.6.32.53 stable release, as it can introduce the following build error while building 2.6.32.y on armel: linux-2.6.32/drivers/mmc/host/mmci.c: In function 'mmci_cmd_irq': linux-2.6.32/drivers/mmc/host/mmci.c:237: error: implicit declaration of function 'dma_inprogress' linux-2.6.32/drivers/mmc/host/mmci.c:238: error: implicit declaration of function 'mmci_dma_data_error' Aparently the commit was wrongly pushed into 2.6.32, since it depends on commit c8ebae37 ("ARM: mmci: add dmaengine-based DMA support"), not present on 2.6.32. Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 80375fc4) (cherry picked from commit HEAD) Signed-off-by:
-
Tyler Hicks authored
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a page, zeroes out the appropriate portions, and then encrypts the page before writing it to the lower filesystem. It was unkillable and due to the lack of sparse file support could result in tying up a large portion of system resources, while encrypting pages of zeros, with no way for the truncate operation to be stopped from userspace. This patch adds the ability for ecryptfs_write() to detect a pending fatal signal and return as gracefully as possible. The intent is to leave the lower file in a useable state, while still allowing a user to break out of the encryption loop. If a pending fatal signal is detected, the eCryptfs inode size is updated to reflect the modified inode size and then -EINTR is returned. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Cc: <stable@vger.kernel.org> (cherry picked from commit 5e6f0d76) Signed-off-by:
-
Joe Perches authored
Add a printk_ratelimited statement expression macro that uses a per-call ratelimit_state so that multiple subsystems output messages are not suppressed by a global __ratelimit state. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: s/_rl/_ratelimited/g] Signed-off-by:
Joe Perches <joe@perches.com> Cc: Naohiro Ooiwa <nooiwa@miraclelinux.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
don't do aggregation related stuff for 'AP mode client power save handling' if aggregation is not enabled in the driver, otherwise it will lead to panic because those data structures won't be never intialized in 'ath_tx_node_init' if aggregation is disabled EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k] EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000 ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860 task.ti=f40dc000) Stack: 0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac f40e1cb0 f8186741 f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001 c0b4ba43 00000000 0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac f2a30000 00010020 Call Trace: [<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k] [<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k] [<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350 [mac80211] [<c018dc75>] ? __module_address+0x95/0xb0 [<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211] [<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0 [mac80211] [<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211] [<c018440b>] ? trace_hardirqs_on+0xb/0x10 [<c056936e>] ? skb_queue_tail+0x3e/0x50 [<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750 [mac80211] [<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211] [<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211] [<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k] [<c0151b7e>] tasklet_action+0xbe/0x180 Cc: stable@kernel.org Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Reported-by:
Ashwin Mendonca <ashwinloyal@gmail.com> Tested-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> (cherry picked from commit b25bfda3) Signed-off-by:
-
Ulf Hansson authored
When getting a cmd irq during an ongoing data transfer with dma, the dma job were never terminated. This is now corrected. Cc: <stable@vger.kernel.org> Tested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Per Forlin <per.forlin@stericsson.com> Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> (cherry picked from commit 3b6e3c73) Signed-off-by:
-
Linus Torvalds authored
This reverts commit de28f25e. It results in resume problems for various people. See for example http://thread.gmane.org/gmane.linux.kernel/1233033 http://thread.gmane.org/gmane.linux.kernel/1233389 http://thread.gmane.org/gmane.linux.kernel/1233159 http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877 and the fedora and ubuntu bug reports https://bugzilla.redhat.com/show_bug.cgi?id=767248 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569 which got bisected down to the stable version of this commit. Reported-by:
Jonathan Nieder <jrnieder@gmail.com> Reported-by:
Phil Miller <mille121@illinois.edu> Reported-by:
Philip Langdale <philipl@overt.org> Reported-by:
Tim Gardner <tim.gardner@canonical.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg KH <gregkh@suse.de> Cc: stable@kernel.org # for stable kernels that applied the original Signed-off-by:
-
Thomas Gleixner authored
commit de28f25e upstream. If a device is shutdown, then there might be a pending interrupt, which will be processed after we reenable interrupts, which causes the original handler to be run. If the old handler is the (broadcast) periodic handler the shutdown state might hang the kernel completely. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> (cherry picked from commit d88048a3)
-
Johannes Weiner authored
Commit 3812c8c8 ("mm: memcg: do not trap chargers with full callstack on OOM") assumed that only a few places that can trigger a memcg OOM situation do not return VM_FAULT_OOM, like optional page cache readahead. But there are many more and it's impractical to annotate them all. First of all, we don't want to invoke the OOM killer when the failed allocation is gracefully handled, so defer the actual kill to the end of the fault handling as well. This simplifies the code quite a bit for added bonus. Second, since a failed allocation might not be the abrupt end of the fault, the memcg OOM handler needs to be re-entrant until the fault finishes for subsequent allocation attempts. If an allocation is attempted after the task already OOMed, allow it to bypass the limit so that it can quickly finish the fault and invoke the OOM killer. Reported-by:
azurIt <azurit@pobox.sk> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: <stable@kernel.org> Signed-off-by:
-
Fabian Frederick authored
According to commit 5f16f322 ext4: atomically set inode->i_flags in ext4_set_inode_flags() Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Cc: "Theodore Ts'o" <tytso@mit.edu> (cherry picked from commit 24e4a0f3) Signed-off-by:
-
Theodore Ts'o authored
commit 5f16f322 upstream. Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. js: there is no change for ext4. This patch defines merely inode_set_flags for jffs in the next patch. I wonder why do we have both inode_set_flags and set_mask_bits? Looks like an improperly resolved merge conflict. Reported-by:
John Sullivan <jsrhbz@kanargh.force9.co.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Jiri Slaby <jslaby@suse.cz> (cherry picked from commit ec81c281)
-
Qi Yong authored
The original minix zmap blocks calculation was correct, in the formula of: sbi->s_nzones - sbi->s_firstdatazone + 1 It is sp->s_zones - (sp->s_firstdatazone - 1) in the minix3 source code. But a later commit 016e8d44 ("fs/minix: Verify bitmap block counts before mounting") has changed it unfortunately as: sbi->s_nzones - (sbi->s_firstdatazone + 1) This would show free blocks one block less than the real when the total data blocks are in "full zmap blocks plus one". This patch corrects that zmap blocks calculation and tidy a printk message while at it. Signed-off-by:
Qi Yong <qiyong@fc-cn.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andreas Rohner authored
Under normal circumstances nilfs_sync_fs() writes out the super block, which causes a flush of the underlying block device. But this depends on the THE_NILFS_SB_DIRTY flag, which is only set if the pointer to the last segment crosses a segment boundary. So if only a small amount of data is written before the call to nilfs_sync_fs(), no flush of the block device occurs. In the above case an additional call to blkdev_issue_flush() is needed. To prevent unnecessary overhead, the new flag nilfs->ns_flushed_device is introduced, which is cleared whenever new logs are written and set whenever the block device is flushed. For convenience the function nilfs_flush_device() is added, which contains the above logic. Signed-off-by:
Andreas Rohner <andreas.rohner@gmx.net> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Al Viro authored
It actually goes back to 2004 ([PATCH] Concurrent O_SYNC write support) when sync_page_range() had been introduced; generic_file_write{,v}() correctly synced pos_after_write - written .. pos_after_write - 1 but generic_file_aio_write() synced pos_before_write .. pos_before_write + written - 1 instead. Which is not the same thing with O_APPEND, obviously. A couple of years later correct variant had been killed off when everything switched to use of generic_file_aio_write(). All users of generic_file_aio_write() are affected, and the same bug has been copied into other instances of ->aio_write(). The fix is trivial; the only subtle point is that generic_write_sync() ought to be inlined to avoid calculations useless for the majority of calls. Signed-off-by:Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit d311d79d) Signed-off-by:
-
Jiri Bohac authored
This fixes an old regression introduced by commit b0d0d915 (ipx: remove the BKL). When a recvmsg syscall blocks waiting for new data, no data can be sent on the same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked. This breaks mars-nwe (NetWare emulator): - the ncpserv process reads the request using recvmsg - ncpserv forks and spawns nwconn - ncpserv calls a (blocking) recvmsg and waits for new requests - nwconn deadlocks in sendmsg on the same socket Commit b0d0d915 has simply replaced BKL locking with lock_sock/release_sock. Unlike now, BKL got unlocked while sleeping, so a blocking recvmsg did not block a concurrent sendmsg. Only keep the socket locked while actually working with the socket data and release it prior to calling skb_recv_datagram(). Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 01462405) Signed-off-by:
-
Mathias Krause authored
pptp_getname() only partially initializes the stack variable sa, particularly only fills the pptp part of the sa_addr union. The code thereby discloses 16 bytes of kernel stack memory via getsockname(). Fix this by memset(0)'ing the union before. Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
-
Martin Hauke authored
Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e) Signed-off-by:
Martin Hauke <mardnh@gmx.de> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Alexey Khoroshilov authored
In case of any failure ieee802154fake_probe() just calls unregister_netdev(). But it does not look safe to unregister netdevice before it was registered. The patch implements straightforward resource deallocation in case of failure in ieee802154fake_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Panu Matilainen authored
Trying to add an unreachable route incorrectly returns -ESRCH if if custom FIB rules are present: [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4 RTNETLINK answers: Network is unreachable [root@localhost ~]# ip rule add to 55.66.77.88 table 200 [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4 RTNETLINK answers: No such process [root@localhost ~]# Commit 83886b6b ("[NET]: Change "not found" return value for rule lookup") changed fib_rules_lookup() to use -ESRCH as a "not found" code internally, but for user space it should be translated into -ENETUNREACH. Handle the translation centrally in ipv4-specific fib_lookup(), leaving the DECnet case alone. On a related note, commit b7a71b51 ("ipv4: removed redundant conditional") removed a similar translation from ip_route_input_slow() prematurely AIUI. Fixes: b7a71b51 ("ipv4: removed redundant conditional") Signed-off-by:
Panu Matilainen <pmatilai@redhat.com> Signed-off-by:
-
Vincent BENAYOUN authored
There could be a signed overflow in the following code. The expression, (32-logmask) is comprised between 0 and 31 included. It may be equal to 31. In such a case the left shift will produce a signed integer overflow. According to the C99 Standard, this is an undefined behavior. A simple fix is to replace the signed int 1 with the unsigned int 1U. Signed-off-by:
Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com> Signed-off-by:
-
David S. Miller authored
We are reading the memory location, so we have to have a memory constraint in there purely for the sake of showing the data flow to the compiler. Reported-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Sougata Santra authored
Concurrent access to alloc_blocks in hfsplus_inode_info() is protected by extents_lock mutex. This patch fixes two instances where alloc_blocks modification was not protected with this lock. This fixes possible allocation bitmap corruption in race conditions while extending and truncating files. [akpm@linux-foundation.org: take extents_lock before taking a copy of ->alloc_blocks] [akpm@linux-foundation.org: remove now-unused label `out'] Signed-off-by:
Sougata Santra <sougata@tuxera.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Vyacheslav Dubeyko authored
Current implementation of HFS+ driver has small issue with remount option. Namely, for example, you are unable to remount from RO mode into RW mode by means of command "mount -o remount,rw /dev/loop0 /mnt/hfsplus". Trying to execute sequence of commands results in an error message: mount /dev/loop0 /mnt/hfsplus mount -o remount,ro /dev/loop0 /mnt/hfsplus mount -o remount,rw /dev/loop0 /mnt/hfsplus mount: you must specify the filesystem type mount -t hfsplus -o remount,rw /dev/loop0 /mnt/hfsplus mount: /mnt/hfsplus not mounted or bad option The reason of such issue is failure of mount syscall: mount("/dev/loop0", "/mnt/hfsplus", 0x2282a60, MS_MGC_VAL|MS_REMOUNT, NULL) = -1 EINVAL (Invalid argument) Namely, hfsplus_parse_options_remount() method receives empty "input" argument and return false in such case. As a result, hfsplus_remount() returns -EINVAL error code. This patch fixes the issue by means of return true for the case of empty "input" argument in hfsplus_parse_options_remount() method. Signed-off-by:Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Dan Carpenter authored
We fixed the call to request_mem_region() in commit 3354f73b ("drivers/vlynq/vlynq.c: fix resource size off by 1 error"). But we need to fix the call the release_mem_region() as well. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Martyn Welch authored
The ca91cx42 and tsi148 VME bridges use the width of reads and writes on the PCI bus in part to control the width of the cycles on the VME bus. It is important that we can control the width of cycles on the VME bus as some VME hardware requires cycles of a specific width. The memcpy_toio() and memcpy_fromio() functions do not provide sufficient control, so instead loop using ioread functions. Reported-by:
Michael Kenney <mfkenney@gmail.com> Signed-off-by:
Martyn Welch <martyn.welch@ge.com> Signed-off-by:
-
Joe Schultz authored
This patch corrects a typo where "vme_base" was used instead of "*vme_base". The typo resulted in an incorrect value being returned to userspace (via vme_user). It also removes the following compile warning on some platforms: warning: cast from pointer to integer of different size [asierra: commit title/log rewording] Signed-off-by:
Joe Schultz <jschultz@xes-inc.com> Signed-off-by:
Aaron Sierra <asierra@xes-inc.com> Signed-off-by:
-
Joe Schultz authored
Previously, tsi148_master_set() assumed the address contained in its PCI bus resource represented the actual PCI bus address. This is a fine assumption on some platforms. However, on platforms that don't use a 1:1 (CPU:PCI) mapping this results in the tsi148 driver configuring an invalid master window translation. This patch updates the vme_tsi148 driver to first convert the address contained in the PCI bus resource into a PCI bus address before using it. [asierra: account for pcibios_resource_to_bus() prototype change] Signed-off-by:
-
Ezequiel Garcia authored
This Multi-IO card has one serial 16550-like and one parallel port connector. Here's the lspci output, after this commit is applied: 03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550]) Subsystem: Device 4348:5053 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at cf00 [size=8] Region 1: I/O ports at ce00 [size=8] Kernel driver in use: parport_serial Kernel modules: 8250_pci, parport_serial This commit adds an entry with the device ID to the blacklist declared in 8250_pci to prevent the driver from taking ownership. Also, and as was done for the 2S/1P variant, add a quirk to skip autodetection and set the correct type to 16550A clone. Proper entries are added to parport_serial, to support the device parallel and serial ports. Cc: Gianluca Anzolin <gianluca@sottospazio.it> Cc: Alan Cox <alan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Arnd Bergmann authored
commit dabd1468 "PCMCIA: sa1111: remove duplicated initializers" incorrectly moved some code into the pcmcia_jornada720_init, causing a few build errors, and for unknown reasons, the driver lacks an inclusion of <linux/io.h>, so we get the build errors, and more: sa1111_jornada720.c: In function 'pcmcia_jornada720_init': sa1111_jornada720.c:101:3: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration] GRER |= 0x00000002; ^ sa1111_jornada720.c:104:3: warning: passing argument 1 of 'sa1111_set_io_dir' from incompatible pointer type [enabled by default] sa1111_set_io_dir(dev, pin, 0, 0); ^ This patch uses the SA1111_DEV() to convert the dev pointer to the correct type before passing it and adds the missing include. Signed-off-by:
-
Arnd Bergmann authored
The lubbock platform uses the sa1111 companion chip with a pxa250 CPU, which means it requires both the PCMCIA_SA1111 and the PCMCIA_PXA2XX code to be built into the kernel. Unfortunately, the Makefile and Kconfig don't agree on how this is accomplished, leading to a situation where you get this link error when building a lubbock kernel with PCMCIA_SA1111 enabled but PCMCIA_PXA2XX disabled: ERROR: "pxa2xx_configure_sockets" [drivers/pcmcia/sa1111_cs.ko] undefined! ERROR: "pxa2xx_drv_pcmcia_ops" [drivers/pcmcia/sa1111_cs.ko] undefined! ERROR: "pxa2xx_drv_pcmcia_add_one" [drivers/pcmcia/sa1111_cs.ko] undefined! This patch changes the Kconfig code to disallow that particular configuration. Signed-off-by:
-
Arnd Bergmann authored
When building a iPAQ H3100-only kernel with PCMCIA enabled, we get this build error: ERROR: "pcmcia_h3600_init" [drivers/pcmcia/sa1100_cs.ko] undefined! The defconfig normally works fine because it enables both H3100 and H3600 support. This patch fixes the Makefile to build the driver if at least one of the two machines are selected. Signed-off-by:
-
Dmitry Eremin-Solenikov authored
Sharp SL-6000 (tosa) touchscreen needs wider limits to properly map all points on the screen. Expand ranges in abs_x and abs_y arrays according to the touchscreen area. Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit 859abd1d) Signed-off-by:
-
Tobias Klauser authored
In altera_ps2_close, the data register (offset 0) is written instead of the control register (offset 4), leading to the RX interrupt not being disabled. Fix this by calling writel() with the offset for the proper register. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Dan Carpenter authored
The lock has been freed in usbvision_release() so there is no need to call mutex_unlock() here. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 470a9147) Signed-off-by:
-
Micky Ching authored
Add cancel_work_sync() in rtsx_pci_ms_drv_remove() to cancel pending request work when removing the driver. Signed-off-by:
Micky Ching <micky_ching@realsil.com.cn> Cc: Samuel Ortiz <sameo@linux.intel.com> says: Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alex Dubov <oakad@yahoo.com> Cc: Roger Tseng <rogerable@realtek.com> Cc: Wei WANG <wei_wang@realsil.com.cn> Signed-off-by:
-
Pranith Kumar authored
The rcu_gp_kthread_wake() function checks for three conditions before waking up grace period kthreads: * Is the thread we are trying to wake up the current thread? * Are the gp_flags zero? (all threads wait on non-zero gp_flags condition) * Is there no thread created for this flavour, hence nothing to wake up? If any one of these condition is true, we do not call wake_up(). It was found that there are quite a few avoidable wake ups both during idle time and under stress induced by rcutorture. Idle: Total:66000, unnecessary:66000, case1:61827, case2:66000, case3:0 Total:68000, unnecessary:68000, case1:63696, case2:68000, case3:0 rcutorture: Total:254000, unnecessary:254000, case1:199913, case2:254000, case3:0 Total:256000, unnecessary:256000, case1:201784, case2:256000, case3:0 Here case{1-3} are the cases listed above. We can avoid these wake ups by using rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads. There is a comment about an implied barrier supplied by the wake_up() logic. This barrier is necessary for the awakened thread to see the updated ->gp_flags. This flag is always being updated with the root node lock held. Also, the awakened thread tries to acquire the root node lock before reading ->gp_flags because of which there is proper ordering. Hence this commit tries to avoid calling wake_up() whenever we can by using rcu_gp_kthread_wake() function. Signed-off-by:Pranith Kumar <bobby.prani@gmail.com> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> (cherry picked from commit 2aa792e6) Signed-off-by:
-
Pali Rohár authored
Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS protocol V3 packets with bit7 set in last byte. More often it can be reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing cover above touchpad. If bit7 in last packet byte is set then it is not valid ALPS packet. I was told that ALPS devices never send these packets. It is not know yet who send those packets, it could be Dell EC, bug in BIOS and also bug in touchpad firmware... With this patch alps driver does not process those invalid packets, but instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state, getting back in sync with the next byte and spam dmesg we return PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks on the next byte and report PSMOUSE_BAD_DATA then. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Tested-by:
-
Greg Kurz authored
The add_early_randomness() function in drivers/char/hw_random/core.c passes a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall() returns four 64-bit values and trashes 16 bytes on the stack. This bug has been lying around for a long time. It got unveiled by: commit d3cc7996 Author: Amit Shah <amit.shah@redhat.com> Date: Thu Jul 10 15:42:34 2014 +0530 hwrng: fetch randomness only after device init It may trig a oops while loading or unloading the pseries-rng module for both PowerVM and PowerKVM guests. This patch does two things: - pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe since we're not on a hot path. - move to the new read API so that we know the return buffer size for sure. Cc: stable@vger.kernel.org Signed-off-by:
Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 24c65bc7) Signed-off-by:
-
Cristian Stoica authored
Replace equivalent (and partially incorrect) scatter-gather functions with ones from crypto-API. The replacement is motivated by page-faults in sg_copy_part triggered by successive calls to crypto_hash_update. The following fault appears after calling crypto_ahash_update twice, first with 13 and then with 285 bytes: Unable to handle kernel paging request for data at address 0x00000008 Faulting instruction address: 0xf9bf9a8c Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 CoreNet Generic Modules linked in: tcrypt(+) caamhash caam_jr caam tls CPU: 6 PID: 1497 Comm: cryptomgr_test Not tainted 3.12.19-rt30-QorIQ-SDK-V1.6+g9fda9f2 #75 task: e9308530 ti: e700e000 task.ti: e700e000 NIP: f9bf9a8c LR: f9bfcf28 CTR: c0019ea0 REGS: e700fb80 TRAP: 0300 Not tainted (3.12.19-rt30-QorIQ-SDK-V1.6+g9fda9f2) MSR: 00029002 <CE,EE,ME> CR: 44f92024 XER: 20000000 DEAR: 00000008, ESR: 00000000 GPR00: f9bfcf28 e700fc30 e9308530 e70b1e55 00000000 ffffffdd e70b1e54 0bebf888 GPR08: 902c7ef5 c0e771e2 00000002 00000888 c0019ea0 00000000 00000000 c07a4154 GPR16: c08d0000 e91a8f9c 00000001 e98fb400 00000100 e9c83028 e70b1e08 e70b1d48 GPR24: e992ce10 e70b1dc8 f9bfe4f4 e70b1e55 ffffffdd e70b1ce0 00000000 00000000 NIP [f9bf9a8c] sg_copy+0x1c/0x100 [caamhash] LR [f9bfcf28] ahash_update_no_ctx+0x628/0x660 [caamhash] Call Trace: [e700fc30] [f9bf9c50] sg_copy_part+0xe0/0x160 [caamhash] (unreliable) [e700fc50] [f9bfcf28] ahash_update_no_ctx+0x628/0x660 [caamhash] [e700fcb0] [f954e19c] crypto_tls_genicv+0x13c/0x300 [tls] [e700fd10] [f954e65c] crypto_tls_encrypt+0x5c/0x260 [tls] [e700fd40] [c02250ec] __test_aead.constprop.9+0x2bc/0xb70 [e700fe40] [c02259f0] alg_test_aead+0x50/0xc0 [e700fe60] [c02241e4] alg_test+0x114/0x2e0 [e700fee0] [c022276c] cryptomgr_test+0x4c/0x60 [e700fef0] [c004f658] kthread+0x98/0xa0 [e700ff40] [c000fd04] ret_from_kernel_thread+0x5c/0x64 Signed-off-by:
-
