- 18 Mar, 2015 40 commits
-
-
Ryusuke Konishi authored
commit 957ed60b 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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ilya Nelkenbaum authored
commit c2be9dc0 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: dd5f03be ("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:
-
Haggai Eran authored
commit 4fc701ea upstream. When the last on-demand paging MR is released the notifier count is left non-zero so that concurrent page faults will have to abort. If a new MR is then registered, the counter is reset. However, the decision is made to put the new MR in the list waiting for the notifier count to reach zero, before the counter is reset. An invalidation or another MR registration can release the MR to handle page faults, but without such an event the MR can wait forever. The patch fixes this issue by adding a check whether the MR is the first on-demand paging MR when deciding whether it is ready to handle page faults. If it is the first MR, we know that there are no mmu notifiers running in parallel to the registration. Fixes: 882214e2 ("IB/core: Implement support for MMU notifiers regarding on demand paging regions") Signed-off-by:
Haggai Eran <haggaie@mellanox.com> Signed-off-by:
Shachar Raindel <raindel@mellanox.com> Signed-off-by:
-
Moshe Lazer authored
commit 0fb8bcf0 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: ed4c54e5 ("IB/core: Resolve Ethernet L2 addresses when modifying QP") Signed-off-by:
Moshe Lazer <moshel@mellanox.com> Signed-off-by:
-
Or Gerlitz authored
commit e9a7faf1 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: d487ee77 ("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:
-
Majd Dibbiny authored
commit bede98e7 upstream. In case handle_eth_ud_smac_index fails, we need to free the allocated resources. Fixes: 2f5bb473 ("mlx4: Add ref counting to port MAC table for RoCE") Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
-
Dan Carpenter authored
commit f614fc15 upstream. The current code returns success when kmalloc() fails. It should return an error code, -ENOMEM. Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Roi Dayan authored
commit c6c95ef4 upstream. We always unmap SGs with the same direction instead of unmapping with the direction the mapping was done, fix that. Fixes: 9a8b08fa ("IB/iser: Generalize iser_unmap_task_data and [...]") Signed-off-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
-
Sagi Grimberg authored
commit 6606e6a2 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: 5426b171 ("IB/iser: Collapse cleanup and disconnect handlers") Reported-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
Mitko Haralanov authored
commit 18c0b82a 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:
-
Tony Battersby authored
commit 3b524a68 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:
-
Sebastian Andrzej Siewior authored
commit 8d1e5a1a 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 397335f0 ("rtmutex: Fix deadlock detector for real") or commit 3d5c9340 ("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.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Hui Wang authored
commit 70658b99 upstream. BugLink: https://bugs.launchpad.net/bugs/1428947Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Sakamoto authored
commit f2b14c0b upstream. The amdtp_stream_wait_callback() doesn't return minus value and the return code is not for error code. This commit fixes with a propper condition and an error code. Fixes: f3699e2c ('ALSA: oxfw: Change the way to start stream') Reported-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Takashi Iwai authored
commit de5d0ad5 upstream. This is essentially a partial revert of the commit [b1920c21: '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:
-
Jaroslav Kysela authored
commit 37ed3988 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 Sakamoto authored
commit dec84316 upstream. A part of these drivers, especially BeBoB driver, are programmed to wait some events. Thus the drivers should not destroy any data in .remove() context. This commit moves some destructors from 'struct fw_driver.remove()' to 'struct snd_card.private_free()' to shutdown safely. Signed-off-by:
-
Takashi Sakamoto authored
commit d23c2cc4 upstream. Currently stream destructor in each driver has a problem to be called in a context in which sound card object is released, because the destructors call amdtp_stream_pcm_abort() and touch PCM runtime data. The PCM runtime data is destroyed in application's context with snd_pcm_close(), on the other hand PCM substream data is destroyed after sound card object is released, in most case after all of ALSA character devices are released. When PCM runtime is destroyed and PCM substream is remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes Null-pointer-dereference. This commit changes stream destructors and allows each driver to call it after releasing runtime. Signed-off-by:
-
Takashi Sakamoto authored
commit c6f224dc upstream. AMDTP helper functions increment/decrement reference counter for an instance of FireWire unit, while it's complicated for each driver to process error state. In previous commit, each driver has the role of reference counting. This commit removes this role from the helper function. Signed-off-by:
-
Takashi Sakamoto authored
commit 12ed7192 upstream. Fireworks and Dice drivers try to touch instances of FireWire unit after sound card object is released, while references to the unit is decremented in .remove(). When unplugging during streaming, sound card object is released after .remove(), thus Fireworks and Dice drivers causes GPF or Null-pointer-dereferencing to application processes because an instance of FireWire unit was already released. This commit adds reference-counting for FireWire unit in drivers to allow them to touch an instance of FireWire unit after .remove(). In most case, any operations after .remove() may be failed safely. Signed-off-by:
-
Takashi Iwai authored
commit 6426460e 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 authored
commit 70372a75 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:
-
Sebastian Andrzej Siewior authored
commit ca8bb4ae upstream. This reverts commit 0aa525d1. 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: 0aa525d1 ("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:
-
Jiri Slaby authored
commit f0bf0bd0 upstream. This problem was taken care of three times already in * b0de59b5 (TTY: do not update atime/mtime on read/write), * 37b7f3c7 (TTY: fix atime/mtime regression), and * b0b88565 (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:
-
Vineet Gupta authored
commit 13648b01 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:
-
Chuck Lever authored
commit 813b00d6 upstream. Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock. xprt_complete_bc_request() should do the same. Fixes: 2ea24497 ("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:
-
Al Viro authored
commit 1711fd9a 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:
-
Al Viro authored
commit 7e0e953b upstream. use_pde()/unuse_pde() in ->follow_link()/->put_link() resp. Signed-off-by:
-
Al Viro authored
commit 0db59e59 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:
-
Rasmus Villemoes authored
commit 76bf3f6b upstream. %pD for struct file*, %pd for struct dentry*. Fixes: a455589f ("assorted conversions to %p[dD]") Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Al Viro authored
commit 0a280962 upstream. X-Coverup: just ask spender Signed-off-by:
-
Johan Hovold authored
commit ca4383a3 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: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
Johan Hovold <johan@kernel.org> Acked-by:
Greg Kroah-Hartman <greg@kroah.com> Signed-off-by:
-
Johan Hovold authored
commit 07fdfc5e 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: c706ebdf ("USB: usb-serial: call port_probe and port_remove at the right times") Signed-off-by:
-
Johan Hovold authored
commit 79fbf4a5 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: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
ZIV-Asier Llano Palacios <asier.llano@cgglobal.com> Signed-off-by:
-
Johan Hovold authored
commit f528bf4f 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: dcf01050 ("USB: serial: add generic wait_until_sent implementation") Signed-off-by:
-
Johan Hovold authored
commit 2c3fbe3c 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: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Luciano Coelho authored
commit 688b1ecf upstream. The call to cfg80211_ch_switch_notify() should be at the end of the ieee80211_chswitch_post_beacon() function, because it should only be sent if everything succeeded. Fixes: d04b5ac9 ("cfg80211/mac80211: allow any interface to send channel switch notifications") Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Jouni Malinen authored
commit 9c1c98a3 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:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
-
Mathias Nyman authored
commit b8cb91e0 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:
-
Aleksander Morgado authored
commit 45ba2154 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:
-
