- 08 11月, 2016 5 次提交
-
-
由 Guoqing Jiang 提交于
It is possible that bitmap_storage_alloc could return -ENOMEM, and some member inside store could be allocated such as filemap. To avoid memory leak, we need to call bitmap_file_unmap to free those members in the bitmap_resize. Reviewed-by: NNeilBrown <neilb@suse.com> Signed-off-by: NGuoqing Jiang <gqjiang@suse.com> Signed-off-by: NShaohua Li <shli@fb.com>
-
由 Tomasz Majchrzak 提交于
Revert commit 11367799 ("md: Prevent IO hold during accessing to faulty raid5 array") as it doesn't comply with commit c3cce6cd ("md/raid5: ensure device failure recorded before write request returns."). That change is not required anymore as the problem is resolved by commit 16f88949 ("md: report 'write_pending' state when array in sync") - read request is stuck as array state is not reported correctly via sysfs attribute. Signed-off-by: NTomasz Majchrzak <tomasz.majchrzak@intel.com> Signed-off-by: NShaohua Li <shli@fb.com>
-
由 Tomasz Majchrzak 提交于
When raid1/raid10 array fails to write to one of the drives, the request is added to bio_end_io_list and finished by personality thread. The thread doesn't handle it as long as MD_CHANGE_PENDING flag is set. In case of external metadata this flag is cleared, however the thread is not woken up. It causes request to be blocked for few seconds (until another action on the array wakes up the thread) or to get stuck indefinitely. Wake up personality thread once MD_CHANGE_PENDING has been cleared. Moving 'restart_array' call after the flag is cleared it not a solution because in read-write mode the call doesn't wake up the thread. Signed-off-by: NTomasz Majchrzak <tomasz.majchrzak@intel.com> Signed-off-by: NShaohua Li <shli@fb.com>
-
由 Tomasz Majchrzak 提交于
If external metadata handler supports bad blocks and unacknowledged bad blocks are present, don't report disk via sysfs as faulty. Such situation can be still handled so disk just has to be blocked for a moment. It makes it consistent with kernel state as corresponding rdev flag is also not set. When the disk in being unblocked there are few cases: 1. Disk has been in blocked and faulty state, it is being unblocked but it still remains in faulty state. Metadata handler will remove it from array in the next call. 2. There is no bad block support in external metadata handler and bad blocks are present - put the disk in blocked and faulty state (see case 1). 3. There is bad block support in external metadata handler and all bad blocks are acknowledged - clear all flags, continue. 4. There is bad block support in external metadata handler but there are still unacknowledged bad blocks - clear all flags, continue. It is fine to clear Blocked flag because it was probably not set anyway (if it was it is case 1). BlockedBadBlocks flag can also be cleared because the request waiting for it will set it again when it finds out that some bad block is still not acknowledged. Recovery is not necessary but there are no problems if the flag is set. Sysfs rdev state is still reported as blocked (due to unacknowledged bad blocks) so metadata handler will process remaining bad blocks and unblock disk again. Signed-off-by: NTomasz Majchrzak <tomasz.majchrzak@intel.com> Signed-off-by: NShaohua Li <shli@fb.com>
-
由 Tomasz Majchrzak 提交于
Add new rdev flag which external metadata handler can use to switch on/off bad block support. If new bad block is encountered, notify it via rdev 'unacknowledged_bad_blocks' sysfs file. If bad block has been cleared, notify update to rdev 'bad_blocks' sysfs file. When bad blocks support is being removed, just clear rdev flag. It is not necessary to reset badblocks->shift field. If there are bad blocks cleared or added at the same time, it is ok for those changes to be applied to the structure. The array is in blocked state and the drive which cannot handle bad blocks any more will be removed from the array before it is unlocked. Simplify state_show function by adding a separator at the end of each string and overwrite last separator with new line. Signed-off-by: NTomasz Majchrzak <tomasz.majchrzak@intel.com> Reviewed-by: NArtur Paszkiewicz <artur.paszkiewicz@intel.com> Signed-off-by: NShaohua Li <shli@fb.com>
-
- 05 11月, 2016 7 次提交
-
-
由 Ooi, Joyce 提交于
User is unable to access to input-X-yyy and feature-X-yyy where X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy) in HID sensor custom sysfs interface. This is because when creating the attribute, the attribute index is written to using %x (hex). However, when reading and writing values into the attribute, the attribute index is scanned using %d (decimal). Hence, user is unable to access to attributes with index in hex values (e.g. 'a', 'b', 'c') but able to access to attributes with index in decimal values (e.g. 1, 2, 3,..). This fix will change input-%d-%x-%s and feature-%d-%x-%s to input-%x-%x-%s and feature-%x-%x-%s in show_values() and store_values() accordingly. Signed-off-by: NOoi, Joyce <joyce.ooi@intel.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Srinivas Pandruvada 提交于
On some platforms ISH interrupt is shared, which causes request_irq to fail. This requires IRQF_SHARED irq flag. But IRQF_NO_SUSPEND and IRQF_SHARED should not be used together, so removed IRQF_NO_SUSPEND flag. Anyway this driver doesn't require IRQF_NO_SUSPEND, as this interrupt is not required during "noirq" phases of suspending and resuming devices as well as during the time when nonboot CPUs are taken offline and brought back online. Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Even Xu 提交于
When built as a module, modprobe followed by rmmod can fail because DMA was still active. So to fix this, DMA needs to be disabled during module exit. This change disables DMA during modules exit and change the ISH PCI device status to D3. Signed-off-by: NEven Xu <even.xu@intel.com> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Even Xu 提交于
Add a new function ish_disable_dma() and move DMA disable operations here, so that this functionality can be reused. Signed-off-by: NEven Xu <even.xu@intel.com> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Even Xu 提交于
Same operations are done in ish_hw_start() and _ish_hw_reset() to wakeup ISH device. Consolidate them by introducing a new function ish_wakeup() and move the code there. Signed-off-by: NEven Xu <even.xu@intel.com> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Niklas Cassel 提交于
dw_pcie_iatu_unroll_enabled() reads a dbi_base register. Reading any dbi_base register before pp->ops->host_init has been called causes "imprecise external abort" on platforms like ARTPEC-6, where the PCIe module is disabled at boot and first enabled in pp->ops->host_init. Move dw_pcie_iatu_unroll_enabled() to dw_pcie_setup_rc(), since it is after pp->ops->host_init, but before pp->iatu_unroll_enabled is actually used. Fixes: a0601a47 ("PCI: designware: Add iATU Unroll feature") Tested-by: NJames Le Cuirot <chewi@gentoo.org> Signed-off-by: NNiklas Cassel <niklas.cassel@axis.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJoao Pinto <jpinto@synopsys.com> Acked-by: NOlof Johansson <olof@lixom.net>
-
由 Vladimir Zapolskiy 提交于
Race condition between registering an I2C device driver and deregistering an I2C adapter device which is assumed to manage that I2C device may lead to a NULL pointer dereference due to the uninitialized list head of driver clients. The root cause of the issue is that the I2C bus may know about the registered device driver and thus it is matched by bus_for_each_drv(), but the list of clients is not initialized and commonly it is NULL, because I2C device drivers define struct i2c_driver as static and clients field is expected to be initialized by I2C core: i2c_register_driver() i2c_del_adapter() driver_register() ... bus_add_driver() ... ... bus_for_each_drv(..., __process_removed_adapter) ... i2c_do_del_adapter() ... list_for_each_entry_safe(..., &driver->clients, ...) INIT_LIST_HEAD(&driver->clients); To solve the problem it is sufficient to do clients list head initialization before calling driver_register(). The problem was found while using an I2C device driver with a sluggish registration routine on a bus provided by a physically detachable I2C master controller, but practically the oops may be reproduced under the race between arbitraty I2C device driver registration and managing I2C bus device removal e.g. by unbinding the latter over sysfs: % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind Unable to handle kernel NULL pointer dereference at virtual address 00000000 Internal error: Oops: 17 [#1] SMP ARM CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: e5ada400 task.stack: e4936000 PC is at i2c_do_del_adapter+0x20/0xcc LR is at __process_removed_adapter+0x14/0x1c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 35bd004a DAC: 00000051 Process sh (pid: 533, stack limit = 0xe4936210) Stack: (0xe4937d28 to 0xe4938000) Backtrace: [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c) [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0) [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284) [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx]) [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44) [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c) [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34) [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104) [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34) [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54) [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214) [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120) [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170) [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8) [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c) Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
- 04 11月, 2016 3 次提交
-
-
由 Oliver Neukum 提交于
Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state. Signed-off-by: NOliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Borislav Petkov 提交于
Fix drivers/hid/intel-ish-hid/ipc/pci-ish.c:247:12: warning: ‘ish_suspend’ defined but not used [-Wunused-function] static int ish_suspend(struct device *device) ^ drivers/hid/intel-ish-hid/ipc/pci-ish.c:282:12: warning: ‘ish_resume’ defined but not used [-Wunused-function] static int ish_resume(struct device *device) ^ by sticking them in the CONFIG_PM range too. Signed-off-by: NBorislav Petkov <bp@suse.de> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Wei Yongjun <weiyongjun1@huawei.com> Cc: linux-input@vger.kernel.org Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Srinivas Pandruvada 提交于
When report count is more than one and report size is not 4 bytes, then we need some packing into result buffer from the caller of function sensor_hub_get_feature. By default the value extracted from a field is 4 bytes from hid core (using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even if report size if less than 4 byte. So when we copy data to user buffer in sensor_hub_get_feature, we need to only copy report size bytes even when report count is more than 1. This is not an issue for most of the sensor hub fields as report count will be 1 where we already copy only report size bytes, but some string fields like description, it is a problem as the report count will be more than 1. For example: Field(6) Physical(Sensor.OtherCustom) Application(Sensor.Sensor) Usage(11) Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Sensor.0306 Report Size(16) Report Count(11) Here since the report size is 2 bytes, we will have 2 additional bytes of 0s copied into user buffer, if we directly copy to user buffer from report->field[]->value This change will copy report size bytes into the buffer of caller for each usage report->field[]->value. So for example without this change, the data displayed for a custom sensor field "sensor-model": 76 00 101 00 110 00 111 00 118 00 111 (truncated to report count of 11) With change 76 101 110 111 118 111 32 89 111 103 97 ("Lenovo Yoga" in ASCII ) Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 03 11月, 2016 3 次提交
-
-
由 Stefan Richter 提交于
RFC 2734 defines the datagram_size field in fragment encapsulation headers thus: datagram_size: The encoded size of the entire IP datagram. The value of datagram_size [...] SHALL be one less than the value of Total Length in the datagram's IP header (see STD 5, RFC 791). Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got this field with a -/+1 offset: ether1394_tx() /* transmit */ ether1394_encapsulate_prep() hdr->ff.dg_size = dg_size - 1; ether1394_data_handler() /* receive */ if (hdr->common.lf == ETH1394_HDR_LF_FF) dg_size = hdr->ff.dg_size + 1; else dg_size = hdr->sf.dg_size + 1; Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500 byte sized datagrams in fragments with datagram_size=1499 if link fragmentation is required. Only firewire-net sets and gets datagram_size without this offset. The result is lacking interoperability of firewire-net with OS X, Windows XP, and presumably Linux' eth1394. (I did not test with the latter.) For example, FTP data transfers to a Linux firewire-net box with max_rec smaller than the 1500 bytes MTU - from OS X fail entirely, - from Win XP start out with a bunch of fragmented datagrams which time out, then continue with unfragmented datagrams because Win XP temporarily reduces the MTU to 576 bytes. So let's fix firewire-net's datagram_size accessors. Note that firewire-net thereby loses interoperability with unpatched firewire-net, but only if link fragmentation is employed. (This happens with large broadcast datagrams, and with large datagrams on several FireWire CardBus cards with smaller max_rec than equivalent PCI cards, and it can be worked around by setting a small enough MTU.) Cc: stable@vger.kernel.org Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
The IP-over-1394 driver firewire-net lacked input validation when handling incoming fragmented datagrams. A maliciously formed fragment with a respectively large datagram_offset would cause a memcpy past the datagram buffer. So, drop any packets carrying a fragment with offset + length larger than datagram_size. In addition, ensure that - GASP header, unfragmented encapsulation header, or fragment encapsulation header actually exists before we access it, - the encapsulated datagram or fragment is of nonzero size. Reported-by: NEyal Itkin <eyal.itkin@gmail.com> Reviewed-by: NEyal Itkin <eyal.itkin@gmail.com> Fixes: CVE 2016-8633 Cc: stable@vger.kernel.org Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Gerd Hoffmann 提交于
virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and because of that it must be called for disabled planes too. Ask drm_atomic_helper_commit_planes to do that. v2: update to use new drm_atomic_helper_commit_planes() API. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 11月, 2016 1 次提交
-
-
由 Jason Gunthorpe 提交于
This fixes the irq allocation in this driver to not print: irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated Which happens because the driver already called irq_alloc_descs() and so the change to use irq_domain_add_simple resulted in calling irq_alloc_descs() twice. Modernize the irq allocation in this driver to use the irq_domain_add_linear flow directly and eliminate the use of irq_domain_add_simple/legacy Fixes: ce931f57 ("gpio/mvebu: convert to use irq_domain_add_simple()") Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 01 11月, 2016 3 次提交
-
-
由 Peter Wu 提交于
Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of such blocks) and as a result power_resources is set to false even if _PR3 exists. Fixes: 692a17dc ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398Reported-and-tested-by: NRick Kerkhof <rick.2889@gmail.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Masahiro Yamada 提交于
Sylvain Lemieux reports the LPC32xx GPIO driver is broken since commit 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are broken too. Those drivers register multiple gpio_chip that are associated to a single OF node, and their own .of_xlate() checks if the passed gpio_chip is valid. Now, the problem is of_find_gpiochip_by_node() returns the first gpio_chip found to match the given node. So, .of_xlate() fails, except for the first GPIO bank. Reverting the commit could be a solution, but I do not want to go back to the mess of struct gg_data. Another solution here is to take the match by a node pointer and the success of .of_xlate(). It is a bit clumsy to call .of_xlate twice; for gpio_chip matching and for really getting the gpio_desc index. Perhaps, our long-term goal might be to convert the drivers to single chip registration, but this commit will solve the problem until then. Fixes: 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data") Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reported-by: NSylvain Lemieux <slemieux.tyco@gmail.com> Tested-by: NDavid Lechner <david@lechnology.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Lars-Peter Clausen 提交于
When allocating a new line handle or event a file is allocated that it is associated to. The file is attached to a file descriptor of the current process and the file descriptor is returned to userspace using copy_to_user(). If this copy operation fails the line handle or event allocation is aborted, all acquired resources are freed and an error is returned. But the file struct is not freed and left attached to the userspace application and even though the file descriptor number was not copied it is trivial to guess. If a userspace application performs a IOCTL on such a left over file descriptor it will trigger a use-after-free and if the file descriptor is closed (latest when the application exits) a double-free is triggered. anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a file descriptor for the current process and install the file struct in the file descriptor. As soon as the file struct is installed in the file descriptor it is accessible by userspace (even if the IOCTL itself hasn't completed yet), this means uninstalling the fd on the error path is not an option, since userspace might already got a reference to the file. Instead anon_inode_getfd() needs to be broken into its individual steps. The allocation of the file struct and file descriptor is done first, then the copy_to_user() is executed and only if it succeeds the file is installed. Since the file struct is reference counted it can not be just freed, but its reference needs to be dropped, which will also call the release() callback, which will free the state attached to the file. So in this case the normal error cleanup path should not be taken. Cc: stable@vger.kernel.org Fixes: d932cd49 ("gpio: free handles in fringe cases") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 31 10月, 2016 9 次提交
-
-
由 Jarkko Sakkinen 提交于
Removal of this check was not properly amended to the original commit. Cc: stable@vger.kernel.org Fixes: 0c541332 ("tpm: use tpm_pcr_read_dev() in tpm_do_selftest()") Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
由 Michael S. Tsirkin 提交于
This inline function is unused on configurations where dma_map/unmap are empty macros. Make the function inline to avoid gcc errors because of an unused static function. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Elfring 提交于
The local variable "err" will be set to an appropriate value by a following statement. Thus omit the explicit initialisation at the beginning. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Elfring 提交于
Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Juergen Gross 提交于
Remove unused file config.c Signed-off-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Matt Redfearn 提交于
Commit c6017e79 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call stack like this: WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433 free_buf+0x1a8/0x288 Call Trace: [<8040c538>] show_stack+0x74/0xc0 [<80757240>] dump_stack+0xd0/0x110 [<80430d98>] __warn+0xfc/0x130 [<80430ee0>] warn_slowpath_null+0x2c/0x3c [<807e7c6c>] free_buf+0x1a8/0x288 [<807ea590>] remove_port_data+0x50/0xac [<807ea6a0>] unplug_port+0xb4/0x1bc [<807ea858>] virtcons_remove+0xb0/0xfc [<807b6734>] virtio_dev_remove+0x58/0xc0 [<807f918c>] __device_release_driver+0xac/0x134 [<807f924c>] device_release_driver+0x38/0x50 [<807f7edc>] bus_remove_device+0xfc/0x130 [<807f4b74>] device_del+0x17c/0x21c [<807f4c38>] device_unregister+0x24/0x38 [<807b6b50>] unregister_virtio_device+0x28/0x44 Fix this by restructuring the loops to allow the locks to only be taken where it is necessary to protect the vqs, and release it while the buffer is being freed. Fixes: c6017e79 ("virtio: console: add locks around buffer removal in port unplug path") Cc: stable@vger.kernel.org Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Konstantin Neumoin 提交于
The following commit 'fad7b7b2 (virtio_balloon: Use a workqueue instead of "vballoon" kthread)' has added a regression. Original code with kthread starts the thread inside probe and checks the necessity to update balloon inside the thread immediately. Nowadays the code behaves differently. Work is queued only on the first command from the host after the negotiation. Thus there is a window especially at the guest startup or the module reloading when the balloon size is not updated until the notification from the host. This patch adds balloon size check at the end of the probe to match original behaviour. Signed-off-by: NKonstantin Neumoin <kneumoin@virtuozzo.com> Signed-off-by: NDenis V. Lunev <den@openvz.org> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Ladi Prosek 提交于
According to the spec, if the VIRTIO_RING_F_EVENT_IDX feature bit is negotiated the driver MUST set flags to 0. Not dirtying the available ring in virtqueue_disable_cb also has a minor positive performance impact, improving L1 dcache load missed by ~0.5% in vring_bench. Writes to the used event field (vring_used_event) are still unconditional. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: <stable@vger.kernel.org> # f277ec42 virtio_ring: shadow available Cc: <stable@vger.kernel.org> Signed-off-by: NLadi Prosek <lprosek@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Will Deacon 提交于
Legacy virtio defines the virtqueue base using a 32-bit PFN field, with a read-only register indicating a fixed page size of 4k. This can cause problems for DMA allocators that allocate top down from the DMA mask, which is set to 64 bits. In this case, the addresses are silently truncated to 44-bit, leading to IOMMU faults, failure to read from the queue or data corruption. This patch restricts the coherent DMA mask for legacy PCI virtio devices to 44 bits, which matches the specification. Cc: stable@vger.kernel.org Cc: Andy Lutomirski <luto@kernel.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Benjamin Serebrin <serebrin@google.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 30 10月, 2016 9 次提交
-
-
由 pravin shelar 提交于
This patch is similar to earlier vxlan patch. Geneve device close operation frees geneve socket. This operation can race with geneve-xmit function which dereferences geneve socket. Following patch uses RCU mechanism to avoid this situation. Signed-off-by: NPravin B Shelar <pshelar@ovn.org> Acked-by: NJohn W. Linville <linville@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 pravin shelar 提交于
When vxlan device is closed vxlan socket is freed. This operation can race with vxlan-xmit function which dereferences vxlan socket. Following patch uses RCU mechanism to avoid this situation. Signed-off-by: NPravin B Shelar <pshelar@ovn.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mintz, Yuval 提交于
Driver allocates a shadow array for transmitted SKBs with X entries; That means valid indices are {0,...,X - 1}. [X == 8191] Problem is the driver also uses X as a mask for a producer/consumer in order to choose the right entry in the array which allows access to entry X which is out of bounds. To fix this, simply allocate X + 1 entries in the shadow array. Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roger Quadros 提交于
This PHY has a compatible register set with DP83848x so add support for it. Acked-by: NAndrew F. Davis <afd@ti.com> Signed-off-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
When MTU is changed from 9000 to 1500 while there is burst of inbound 9000 bytes packets, adaptor sometimes delivers 9000 bytes packets to 1500 bytes buffers. This causes memory corruption and sometimes crash. This is because of a race condition in adaptor between "RQ disable" clearing descriptor mini-cache and mini-cache valid bit being set by completion of descriptor fetch. This can result in stale RQ desc being cached and used when packets arrive. In this case, the stale descriptor have old MTU value. Solution is to write RQ->disable twice. The first write will stop any further desc fetches, allowing the second disable to clear the mini-cache valid bit without danger of a race. Also, the check for rq->running becoming 0 after writing rq->enable to 0 is not done properly. When incoming packets are flooding the interface, rq->running will pulse high for each dropped packet. Since the driver was waiting for 10us between each poll, it is possible to see rq->running = 1 1000 times in a row, even though it is not actually stuck running. This results in false failure of vnic_rq_disable(). Fix is to try more than 1000 time without delay between polls to ensure we do not miss when running goes low. In old adaptors rq->enable needs to be re-written to 0 when posted_index is reset in vnic_rq_clean() in order to keep rq->prefetch_index in sync. Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Thomas Falcon 提交于
Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Thomas Falcon 提交于
Schedule these XPORT event tasks in the shared workqueue so that IRQs are not freed in an interrupt context when sub-CRQs are released. Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
This reverts commit 8d7533e5. It introduced kbuild failures, new version coming. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tariq Toukan 提交于
Following the previous patch, as an optimization, the slave will not even bother sending the DUMP_ETH_STATS command over the comm channel. Signed-off-by: NTariq Toukan <tariqt@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-