- 26 Apr, 2018 40 commits
-
-
Vitaly Kuznetsov authored
[ Upstream commit 617ab45c ] When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature was deliberately suppressed as a precaution: back then PCID was never exposed to Hyper-V guests and it wasn't clear what will happen if some day it becomes available. The day came and PCID/INVPCID features are already exposed on certain Hyper-V hosts. >From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with PCID. In particular the usage of PCID is per-cpu based: the same mm gets different CR3 values on different CPUs. If the hypercall does exact matching this will fail. However, this is not the case. David Zhang explains: "In practice, the AddressSpace argument is ignored on any VM that supports PCIDs. Architecturally, the AddressSpace argument must match the CR3 with PCID bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in long mode). The flush hypercalls flush all PCIDs for the specified AddressSpace." With this, PCID can be enabled. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: David Zhang <dazhan@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: devel@linuxdriverproject.org Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Aditya Bhandari <adityabh@microsoft.com> Link: https://lkml.kernel.org/r/20180124103629.29980-1-vkuznets@redhat.comSigned-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ngai-Mint Kwan authored
[ Upstream commit cf315ea5 ] When a VF is under PF VLAN assignment: ip link set <pf> vf <#> vlan <vid> This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg": failed to kill vid 0081/<vid> for device <vf> This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message. Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs. The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before. However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways. Signed-off-by:
Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Daniel Hua authored
[ Upstream commit 3a532852 ] Problem description: After ethernet cable connect and disconnect for several iterations on a device with i210, tx timestamp will stop being put into the socket. Steps to reproduce: 1. Setup a device with i210 and wire it to a 802.1AS capable switch ( Extreme Networks Summit x440 is used in our case) 2. Have the gptp daemon running on the device and make sure it is synced with the switch 3. Have the switch disable and enable the port, wait for the device gets resynced with the switch 4. Iterates step 3 until the device is not albe to get resynced 5. Review the log in dmesg and you will see warning message "igb : clearing Tx timestamp hang" Root cause: If ptp_tx_work() gets scheduled just before the port gets disabled, a LINK DOWN event will be processed before ptp_tx_work(), which may cause timeout in ptp_tx_work(). In the timeout logic, the TSYNCTXCTL's TXTT bit (Transmit timestamp valid bit) is not cleared, causing no new timestamp loaded to TXSTMP register. Consequently therefore, no new interrupt is triggerred by TSICR.TXTS bit and no more Tx timestamp send to the socket. Signed-off-by:
Daniel Hua <daniel.hua@ni.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Corinna Vinschen authored
[ Upstream commit 177132df ] Before libvirt modifies the MAC address and vlan tag for an SRIOV VF for use by a virtual machine (either using vfio device assignment or macvtap passthru mode), it saves the current MAC address and vlan tag so that it can reset them to their original value when the guest is done. Libvirt can't leave the VF MAC set to the value used by the now-defunct guest since it may be started again later using a different VF, but it certainly shouldn't just pick any random value, either. So it saves the state of everything prior to using the VF, and resets it to that. The igb driver initializes the MAC addresses of all VFs to 00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK netlink message, also visible in the list of VFs in the output of "ip link show"). But when libvirt attempts to restore the MAC address back to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the kernel responds with "Invalid argument". Forbidding a reset back to the original value leaves the VF MAC at the value set for the now-defunct virtual machine. Especially on a system with NetworkManager enabled, this has very bad consequences, since NetworkManager forces all interfacess to be IFF_UP all the time - if the same virtual machine is restarted using a different VF (or even on a different host), there will be multiple interfaces watching for traffic with the same MAC address. To allow libvirt to revert to the original state, we need a way to remove the administrative set MAC on a VF, to allow normal host operation again, and to reset/overwrite the VF MAC via VF netdev. This patch implements the outlined scenario by allowing to set the VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF. igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0, so it's possible to reset the VF MAC back to the original value via the VF netdev. Note: Recent patches to libvirt allow for a workaround if the NIC isn't capable of resetting the administrative MAC back to all 0, but in theory the NIC should allow resetting the MAC in the first place. Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Tested-by:
Aaron Brown <arron.f.brown@intel.com> Signed-off-by:
-
Jeffy Chen authored
[ Upstream commit fde7f9db ] The rt5514 dsp captures pcm data through spi directly, so we should not use rockchip-i2s as it's cpu dai like other codecs. Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again. Reported-by:
Jimmy Cheng-Yi Chiang <cychiang@google.com> Fixes: (72cfb0f2 ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp) Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Tested-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Eryu Guan authored
[ Upstream commit 6b136a24 ] Attributes that only implement .seq_ops are read-only, any write to them should be rejected. But currently kernel would crash when writing to such debugfs entries, e.g. chmod +w /sys/kernel/debug/block/<dev>/requeue_list echo 0 > /sys/kernel/debug/block/<dev>/requeue_list chmod -w /sys/kernel/debug/block/<dev>/requeue_list Fix it by returning -EPERM in blk_mq_debugfs_write() when writing to such attributes. Cc: Ming Lei <ming.lei@redhat.com> Signed-off-by:
Eryu Guan <eguan@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
David Hildenbrand authored
[ Upstream commit b3ecd4aa ] Another VCPU might try to modify the SCB while we are creating the shadow SCB. In general this is no problem - unless the compiler decides to not load values once, but e.g. twice. For us, this is only relevant when checking/working with such values. E.g. the prefix value, the mso, state of transactional execution and addresses of satellite blocks. E.g. if we blindly forward values (e.g. general purpose registers or execution controls after masking), we don't care. Leaving unpin_blocks() untouched for now, will handle it separately. The worst thing right now that I can see would be a missed prefix un/remap (mso, prefix, tx) or using wrong guest addresses. Nothing critical, but let's try to avoid unpredictable behavior. Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20180116171526.12343-2-david@redhat.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
David Herrmann authored
[ Upstream commit 587d8628 ] This patch prevents the thinkpad_acpi driver from warning about 2 event codes returned for keyboard palm-detection. No behavioral changes, other than suppressing the warning in the kernel log. The events are still forwarded via acpi-netlink channels. We could, optionally, decide to forward the event through a input-switch on the tpacpi input device. However, so far no suitable input-code exists, and no similar drivers report such events. Hence, leave it an acpi event for now. Note that the event-codes are named based on empirical studies. On the ThinkPad X1 5th Gen the sensor can be found underneath the arrow key. Cc: Matthew Thode <mthode@mthode.org> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Acked-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Alan Brady authored
[ Upstream commit e0346f9f ] If we receive the link status message from PF with link up before queues are actually enabled, it will trigger a TX hang. This fixes the issue by ignoring a link up message if the VF state is not yet in RUNNING state. Signed-off-by:
Alan Brady <alan.brady@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Avinash Dayanand authored
[ Upstream commit 06aa040f ] When a host disables and enables a PF device, all the associated VFs are removed and added back in. It also generates a PFR which in turn resets all the connected VFs. This behaviour is different from that of Linux guest on Linux host. Hence we end up in a situation where there's a PFR and device removal at the same time. And watchdog doesn't have a clue about this and schedules a reset_task. This patch adds code to send signal to reset_task that the device is currently being removed. Signed-off-by:
Avinash Dayanand <avinash.dayanand@intel.com> Tested-by:
-
Prashant Bhole authored
[ Upstream commit 78368781 ] Bug: BPF programs and maps related to sockmaps test exist in memory even after test_maps ends. This patch fixes it as a short term workaround (sockmap kernel side needs real fixing) by empyting sockmaps when test ends. Fixes: 6f6d33f3 ("bpf: selftests add sockmap tests") Signed-off-by:
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> [ daniel: Note on workaround. ] Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Goldwyn Rodrigues authored
[ Upstream commit 20d59023 ] We inadvertently set it again on the source bio, but we need to set it on the new split bio instead. Fixes: fbbaf700 ("block: trace completion of all bios.") Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit e58decc9 ] Fix to return error code -EINVAL instead of 0 when num_vfs above limit_vfs, as done elsewhere in this function. Fixes: 0dc78621 ("nfp: handle SR-IOV already enabled when driver is probing") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 7ad81482 ] We get the "new_profile_index" value from the mouse device when we're handling raw events. Smatch taints it as untrusted data and complains that we need a bounds check. This seems like a reasonable warning otherwise there is a small read beyond the end of the array. Fixes: 0e70f97f ("HID: roccat: Add support for Kova[+] mouse") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Silvan Jegen <s.jegen@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Andi Shyti authored
[ Upstream commit cba04cdf ] The interrupt is requested before the device is powered on and it's value in some cases cannot be reliable. It happens on some devices that an interrupt is generated as soon as requested before having the chance to disable the irq. Set the irq flag as IRQ_NOAUTOEN before requesting it. This patch mutes the error: stmfts 2-0049: failed to read events: -11 received sometimes during boot time. Signed-off-by:
Andi Shyti <andi.shyti@samsung.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 96d5eaa9 ] While testing with the ARM specific memset() macro removed, I ran into a compiler warning that shows an old bug: drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done': drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] It turns out that the definition of the scsi_cmd structure changed back in linux-2.6.25, so now we clear only four bytes (sizeof(pointer)) instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we actually need to initialize the buffer here, but it's clear that if we do it, we should use the correct size. Fixes: de25deb1 ("[SCSI] use dynamically allocated sense buffer") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Xose Vazquez Perez authored
[ Upstream commit 3f884a0a ] Replace "" with NULL for product revision level, and merge TEXEL duplicate entries. Cc: Hannes Reinecke <hare@suse.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com> Cc: SCSI ML <linux-scsi@vger.kernel.org> Signed-off-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by:
-
Sheng Yong authored
[ Upstream commit a9d572c7 ] When io_bits is set, GCing encrypted block may hit the following hungtask. Since io_bits requires aligned block address, f2fs_submit_page_write may return -EAGAIN if new_blkaddr does not satisify io_bits alignment. As a result, the encrypted page will never be writtenback. This patch makes move_data_block aware the EAGAIN error and cancel the writeback. [ 246.751371] INFO: task kworker/u4:4:797 blocked for more than 90 seconds. [ 246.752423] Not tainted 4.15.0-rc4+ #11 [ 246.754176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.755336] kworker/u4:4 D25448 797 2 0x80000000 [ 246.755597] Workqueue: writeback wb_workfn (flush-7:0) [ 246.755616] Call Trace: [ 246.755695] ? __schedule+0x322/0xa90 [ 246.755761] ? blk_init_request_from_bio+0x120/0x120 [ 246.755773] ? pci_mmcfg_check_reserved+0xb0/0xb0 [ 246.755801] ? __radix_tree_create+0x19e/0x200 [ 246.755813] ? delete_node+0x136/0x370 [ 246.755838] schedule+0x43/0xc0 [ 246.755904] io_schedule+0x17/0x40 [ 246.755939] wait_on_page_bit_common+0x17b/0x240 [ 246.755950] ? wake_page_function+0xa0/0xa0 [ 246.755961] ? add_to_page_cache_lru+0x160/0x160 [ 246.755972] ? page_cache_tree_insert+0x170/0x170 [ 246.755983] ? __lru_cache_add+0x96/0xb0 [ 246.756086] __filemap_fdatawait_range+0x14f/0x1c0 [ 246.756097] ? wait_on_page_bit_common+0x240/0x240 [ 246.756120] ? __wake_up_locked_key_bookmark+0x20/0x20 [ 246.756167] ? wait_on_all_pages_writeback+0xc9/0x100 [ 246.756179] ? __remove_ino_entry+0x120/0x120 [ 246.756192] ? wait_woken+0x100/0x100 [ 246.756204] filemap_fdatawait_range+0x9/0x20 [ 246.756216] write_checkpoint+0x18a1/0x1f00 [ 246.756254] ? blk_get_request+0x10/0x10 [ 246.756265] ? cpumask_next_and+0x43/0x60 [ 246.756279] ? f2fs_sync_inode_meta+0x160/0x160 [ 246.756289] ? remove_element.isra.4+0xa0/0xa0 [ 246.756300] ? __put_compound_page+0x40/0x40 [ 246.756310] ? f2fs_sync_fs+0xec/0x1c0 [ 246.756320] ? f2fs_sync_fs+0x120/0x1c0 [ 246.756329] f2fs_sync_fs+0x120/0x1c0 [ 246.756357] ? trace_event_raw_event_f2fs__page+0x260/0x260 [ 246.756393] ? ata_build_rw_tf+0x173/0x410 [ 246.756397] f2fs_balance_fs_bg+0x198/0x390 [ 246.756405] ? drop_inmem_page+0x230/0x230 [ 246.756415] ? ahci_qc_prep+0x1bb/0x2e0 [ 246.756418] ? ahci_qc_issue+0x1df/0x290 [ 246.756422] ? __accumulate_pelt_segments+0x42/0xd0 [ 246.756426] ? f2fs_write_node_pages+0xd1/0x380 [ 246.756429] f2fs_write_node_pages+0xd1/0x380 [ 246.756437] ? sync_node_pages+0x8f0/0x8f0 [ 246.756440] ? update_curr+0x53/0x220 [ 246.756444] ? __accumulate_pelt_segments+0xa2/0xd0 [ 246.756448] ? __update_load_avg_se.isra.39+0x349/0x360 [ 246.756452] ? do_writepages+0x2a/0xa0 [ 246.756456] do_writepages+0x2a/0xa0 [ 246.756460] __writeback_single_inode+0x70/0x490 [ 246.756463] ? check_preempt_wakeup+0x199/0x310 [ 246.756467] writeback_sb_inodes+0x2a2/0x660 [ 246.756471] ? is_empty_dir_inode+0x40/0x40 [ 246.756474] ? __writeback_single_inode+0x490/0x490 [ 246.756477] ? string+0xbf/0xf0 [ 246.756480] ? down_read_trylock+0x35/0x60 [ 246.756484] __writeback_inodes_wb+0x9f/0xf0 [ 246.756488] wb_writeback+0x41d/0x4b0 [ 246.756492] ? writeback_inodes_wb.constprop.55+0x150/0x150 [ 246.756498] ? set_worker_desc+0xf7/0x130 [ 246.756502] ? current_is_workqueue_rescuer+0x60/0x60 [ 246.756511] ? _find_next_bit+0x2c/0xa0 [ 246.756514] ? wb_workfn+0x400/0x5d0 [ 246.756518] wb_workfn+0x400/0x5d0 [ 246.756521] ? finish_task_switch+0xdf/0x2a0 [ 246.756525] ? inode_wait_for_writeback+0x30/0x30 [ 246.756529] process_one_work+0x3a7/0x6f0 [ 246.756533] worker_thread+0x82/0x750 [ 246.756537] kthread+0x16f/0x1c0 [ 246.756541] ? trace_event_raw_event_workqueue_work+0x110/0x110 [ 246.756544] ? kthread_create_worker_on_cpu+0xb0/0xb0 [ 246.756548] ret_from_fork+0x1f/0x30 Signed-off-by:
Sheng Yong <shengyong1@huawei.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 00db63c1 ] If valid netdevice is not found for RoCE, GID table should not be searched with NULL netdevice. Doing so causes the search routines to ignore the netdev argument and may match the wrong GID table entry if the netdev is deleted. Fixes: abae1b71 ("IB/cma: cma_validate_port should verify the port and netdevice") Signed-off-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Liu Bo authored
[ Upstream commit 7583d8d0 ] Before rbio_orig_end_io() goes to free rbio, rbio may get merged with more bios from other rbios and rbio->bio_list becomes non-empty, in that case, these newly merged bios don't end properly. Once unlock_stripe() is done, rbio->bio_list will not be updated any more and we can call bio_endio() on all queued bios. It should only happen in error-out cases, the normal path of recover and full stripe write have already set RBIO_RMW_LOCKED_BIT to disable merge before doing IO, so rbio_orig_end_io() called by them doesn't have the above issue. Reported-by:
Jérôme Carretero <cJ-ko@zougloub.eu> Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Liu Bo authored
[ Upstream commit 18e83ac7 ] This fixes a corner case that is caused by a race of dio write vs dio read/write. Here is how the race could happen. Suppose that no extent map has been loaded into memory yet. There is a file extent [0, 32K), two jobs are running concurrently against it, t1 is doing dio write to [8K, 32K) and t2 is doing dio read from [0, 4K) or [4K, 8K). t1 goes ahead of t2 and splits em [0, 32K) to em [0K, 8K) and [8K 32K). ------------------------------------------------------ t1 t2 btrfs_get_blocks_direct() btrfs_get_blocks_direct() -> btrfs_get_extent() -> btrfs_get_extent() -> lookup_extent_mapping() -> add_extent_mapping() -> lookup_extent_mapping() # load [0, 32K) -> btrfs_new_extent_direct() -> btrfs_drop_extent_cache() # split [0, 32K) and # drop [8K, 32K) -> add_extent_mapping() # add [8K, 32K) -> add_extent_mapping() # handle -EEXIST when adding # [0, 32K) ------------------------------------------------------ About how t2(dio read/write) runs into -EEXIST: a) add_extent_mapping() gets -EEXIST for adding em [0, 32k), b) search_extent_mapping() then returns [0, 8k) as the existing em, even though start == existing->start, em is [0, 32k) so that extent_map_end(em) > extent_map_end(existing), i.e. 32k > 8k, c) then it goes thru merge_extent_mapping() which tries to add a [8k, 8k) (with a length 0) and returns -EEXIST as [8k, 32k) is already in tree, d) so btrfs_get_extent() ends up returning -EEXIST to dio read/write, which is confusing applications. Here I conclude all the possible situations, 1) start < existing->start +-----------+em+-----------+ +--prev---+ | +-------------+ | | | | | | | +---------+ + +---+existing++ ++ + | + start 2) start == existing->start +------------em------------+ | +-------------+ | | | | | + +----existing-+ + | | + start 3) start > existing->start && start < (existing->start + existing->len) +------------em------------+ | +-------------+ | | | | | + +----existing-+ + | | + start 4) start >= (existing->start + existing->len) +-----------+em+-----------+ | +-------------+ | +--next---+ | | | | | | + +---+existing++ + +---------+ + | + start As we can see, it turns out that if start is within existing em (front inclusive), then the existing em should be returned as is, otherwise, we try our best to merge candidate em with sibling ems to form a larger em (in order to reduce the total number of em). Reported-by:
David Vallender <david.vallender@landmark.co.uk> Signed-off-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
-
Anand Jain authored
[ Upstream commit 6f794e3c ] It appears from the original commit [1] that there isn't any design specific reason not to fail the mount instead of just warning. This patch will change it to fail. [1] commit 319e4d06 btrfs: Enhance super validation check Fixes: 319e4d06 ("btrfs: Enhance super validation check") Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
-
Liu Bo authored
[ Upstream commit 762221f0 ] The raid6 corruption is that, suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice, - the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild, - if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild, however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content. We've fixed normal reads to rebuild raid6 correctly with more retries in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix scrub to do the exactly same rebuild process. [1]: https://patchwork.kernel.org/patch/10091755/Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit 9ea2c7c9 ] When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then the level variable is going to be 7 (this is the max height of the tree). On the other hand btrfs_cow_block is always called with "level + 1" as an index into the nodes and slots arrays. This leads to an out of bounds access. Admittdely this will be benign since an OOB access of the nodes array will likely read the 0th element from the slots array, which in this case is going to be 0 (since we start CoW at the top of the tree). The OOB access into the slots array in turn will read the 0th and 1st values of the locks array, which would both be 0 at the time. However, this benign behavior relies on the fact that the path being passed hasn't been initialised, if it has already been used to query a btree then it could potentially have populated the nodes/slots arrays. Fix it by explicitly checking if we are at level 7 (the maximum allowed index in nodes/slots arrays) and explicitly call the CoW routine with NULL for parent's node/slot. Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Fixes-coverity-id: 711515 Reviewed-by:
-
Liu Bo authored
[ Upstream commit 343e4fc1 ] Setting plug can merge adjacent IOs before dispatching IOs to the disk driver. Without plug, it'd not be a problem for single disk usecases, but for multiple disks using raid profile, a large IO can be split to several IOs of stripe length, and plug can be helpful to bring them together for each disk so that we can save several disk access. Moreover, fsync issues synchronous writes, so plug can really take effect. Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit e749d328 ] Fix to return a negative error code from the request_irq() error handling case instead of 0, as done elsewhere in this function. Fixes: dce143c3 ("ipmi/powernv: Convert to irq event interface") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
weiyongjun (A) authored
[ Upstream commit 0ddcff49 ] 'hwname' is malloced in hwsim_new_radio_nl() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: ff4dd73d ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Ulf Magnusson authored
[ Upstream commit 5b1374b3 ] Only the E_NOT operand and not the E_NOT node itself was freed, due to accidentally returning too early in expr_free(). Outline of leak: switch (e->type) { ... case E_NOT: expr_free(e->left.expr); return; ... } *Never reached, 'e' leaked* free(e); Fix by changing the 'return' to a 'break'. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 44,448 bytes in 1,852 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 1,608 bytes in 67 blocks ... Signed-off-by:
Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Ulf Magnusson authored
[ Upstream commit ae7440ef ] expr_trans_compare() always allocates and returns a new expression, giving the following leak outline: ... *Allocate* basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no); ... for (menu = parent->next; menu; menu = menu->next) { ... *Copy* dep2 = expr_copy(basedep); ... *Free copy* expr_free(dep2); } *basedep lost!* Fix by freeing 'basedep' after the loop. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,376 bytes in 14,349 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 44,448 bytes in 1,852 blocks ... Signed-off-by:
-
Ulf Magnusson authored
[ Upstream commit 0724a7c3 ] If a 'mainmenu' entry appeared in the Kconfig files, two things would leak: - The 'struct property' allocated for the default "Linux Kernel Configuration" prompt. - The string for the T_WORD/T_WORD_QUOTE prompt after the T_MAINMENU token, allocated on the heap in zconf.l. To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches if there's no 'mainmenu' and adds the default prompt. That means the prompt only gets allocated once regardless of whether there's a 'mainmenu' statement or not, and managing it becomes simple. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,568 bytes in 14,352 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 344,440 bytes in 14,350 blocks ... Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit f541c09e ] According to all published information, the watchdog disable bit for SB800 compatible controllers is bit 1 of PM register 0x48, not bit 2. For the most part that doesn't matter in practice, since the bit has to be cleared to enable watchdog address decoding, which is the default setting, but it still needs to be fixed. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Niklas Cassel authored
[ Upstream commit 80db6f08 ] Some hardware can operate in either "host" or "endpoint" mode, which means there can be both a host bridge driver and an endpoint driver for the same device. Those drivers share a lot of code, so sometimes they live in the same source file. The host bridge driver requires CONFIG_PCI=y because it enumerates PCI devices below the bridge using the PCI core. The endpoint driver does not require CONFIG_PCI=y because it runs in an embedded kernel on the other side of the device, e.g., on an adapter card. pci-dra7xx.c contains both host and endpoint drivers. If we select only the endpoint driver (CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y), the unneeded host driver is still compiled. It references pci_irqd_intx_xlate(), which is not present when CONFIG_PCI=n, which causes this error: drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared here (not in a function) Add a dummy pci_irqd_intx_xlate() for the CONFIG_PCI=n case. [bhelgaas: changelog] Signed-off-by:
Niklas Cassel <niklas.cassel@axis.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
James Hogan authored
[ Upstream commit 5f2483eb ] Make doesn't expand shell style "vmlinuz.{32,ecoff,bin,srec}" to the 4 separate files, so none of these files get cleaned up by make clean. List the files separately instead. Fixes: ec335292 ("MIPS: Remove all generated vmlinuz* files on "make clean"") Signed-off-by:
James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18491/Signed-off-by:
-
Jan Chochol authored
[ Upstream commit cbebc6ef ] Since commit 57e62324 ("NFS: Store the legacy idmapper result in the keyring") nfs_idmap_cache_timeout changed units from jiffies to seconds. Unfortunately sysctl interface was not updated accordingly. As a effect updating /proc/sys/fs/nfs/idmap_cache_timeout with some value will incorrectly multiply this value by HZ. Also reading /proc/sys/fs/nfs/idmap_cache_timeout will show real value divided by HZ. Fixes: 57e62324 ("NFS: Store the legacy idmapper result in the keyring") Signed-off-by:
Jan Chochol <jan@chochol.info> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 246d8b18 ] polling the completion queue directly does not interfere with the existing polling logic, hence drop the requirement. Be aware that running ib_process_cq_direct with non IB_POLL_DIRECT CQ may trigger concurrent CQ processing. This can be used for polling mode ULPs. Cc: Bart Van Assche <bart.vanassche@wdc.com> Reported-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> [maxg: added wcs array argument to __ib_process_cq] Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Maxime Chevallier authored
[ Upstream commit 44a5f423 ] When performing a read using FIFO mode, the spi controller shifts out the last 2 bytes that were written in a previous transfer on MOSI. This undocumented behaviour can cause devices to misinterpret the transfer, so we explicitly clear the WFIFO before each read. This behaviour was noticed on EspressoBin. Signed-off-by:
Maxime Chevallier <maxime.chevallier@smile.fr> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit fb7d38a7 ] On Meson8b the only valid input clock is MPLL2. The bootloader configures that to run at 500002394Hz which cannot be divided evenly down to 125MHz using the m250_div clock. Currently the common clock framework chooses a m250_div of 2 - with the internal fixed "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz above the requested 125MHz). Letting the common clock framework propagate the rate changes up to the parent of m250_mux allows us to get the best possible clock rate. With this patch the common clock framework calculates a rate of very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock (which is the mux input). Dividing that by 2 (which is an internal, fixed divider for the RGMII TX clock) gives us an RGMII TX clock of 124999850Hz (which is only 150Hz off the requested 125MHz, compared to 1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel sources). SoCs from the Meson GX series are not affected by this change because the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine since it's running at 1GHz, so it's already a multiple of 250MHz and 125MHz). Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Suggested-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
-
Martin Blumenstingl authored
[ Upstream commit 433c6cab ] Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The exact rate is 500002394Hz, which is calculated in drivers/clk/meson/clk-mpll.c using the following formula: DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm) Odroid-C1's u-boot configures MPLL2 with the following values: - SDM_DEN = 16384 - SDM = 1638 - N2 = 5 The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the common clock framework chooses a divider which is too big to generate the 250MHz clock (a divider of 2 would be needed, but this is rounded up to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1 because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds, the IP block internally divides that down to 25MHz on 100Mbit/s connections and 2.5MHz on 10Mbit/s connections - we don't need any special configuration for that). Round the divider to the closest value to prevent this issue on Meson8b. This means we'll now end up with a clock rate for the RGMII TX clock of 125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz. This has no effect on the Meson GX SoCs since there fclk_div2 is used as input clock, which has a rate of 1000MHz (and thus is divisible cleanly to 250MHz and 125MHz). Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Reported-by:
Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit c877154d ] fs/ubifs/tnc.c: In function ‘search_dh_cookie’: fs/ubifs/tnc.c:1893: warning: ‘err’ is used uninitialized in this function Indeed, err is always used uninitialized. According to an original review comment from Hyunchul, acknowledged by Richard, err should be initialized to -ENOENT to avoid the first call to tnc_next(). But we can achieve the same by reordering the code. Fixes: 781f675e ("ubifs: Fix unlink code wrt. double hash lookups") Reported-by:
Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Ming Lei authored
[ Upstream commit 7df938fb ] We know this WARN_ON is harmless and in reality it may be trigged, so convert it to printk() and dump_stack() to avoid to confusing people. Also add comment about two releated races here. Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Stefan Haberland <sth@linux.vnet.ibm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "jianchao.wang" <jianchao.w.wang@oracle.com> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
