20 Jan, 2021
21 commits
-
commit 31e203e09f036f48e7c567c2d32df0196bbd303f upstream.
After full/fast commit, entries in staging queue are promoted to main
queue. In ext4_fs_cleanup function, it splice to staging queue to
staging queue.Fixes: aa75f4d3daaeb ("ext4: main fast-commit commit path")
Signed-off-by: Daejun Park
Reviewed-by: Harshad Shirwadkar
Link: https://lore.kernel.org/r/20201230094851epcms2p6eeead8cc984379b37b2efd21af90fd1a@epcms2p6
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 23dd561ad9eae02b4d51bb502fe4e1a0666e9567 upstream.
1: ext4_iget/ext4_find_extent never returns NULL, use IS_ERR
instead of IS_ERR_OR_NULL to fix this.2: ext4_fc_replay_inode should set the inode to NULL when IS_ERR.
and go to call iput properly.Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
Signed-off-by: Yi Li
Reviewed-by: Jan Kara
Link: https://lore.kernel.org/r/20201230033827.3996064-1-yili@winhong.com
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 55ed4560774d81d7343223b8fd2784c530a9c6c1 upstream.
Add ftrace.instance.INSTANCE.tracing_on support to ftrace2bconf.sh
and bconf2ftrace.sh.commit 8490db06f914 ("tracing/boot: Add per-instance tracing_on
option support") added the per-instance tracing_on option,
but forgot to update the helper scripts.Link: https://lkml.kernel.org/r/160749166410.3497930.14204335886811029800.stgit@devnote2
Cc: stable@vger.kernel.org
Fixes: 8490db06f914 ("tracing/boot: Add per-instance tracing_on option support")
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman -
commit 7bb83f6fc4ee84e95d0ac0d14452c2619fb3fe70 upstream.
Enable the notrace function check on the architecture which doesn't
support kprobes on ftrace but support dynamic ftrace. This notrace
function check is not only for the kprobes on ftrace but also
sw-breakpoint based kprobes.
Thus there is no reason to limit this check for the arch which
supports kprobes on ftrace.This also changes the dependency of Kconfig. Because kprobe event
uses the function tracer's address list for identifying notrace
function, if the CONFIG_DYNAMIC_FTRACE=n, it can not check whether
the target function is notrace or not.Link: https://lkml.kernel.org/r/20210105065730.2634785-1-naveen.n.rao@linux.vnet.ibm.com
Link: https://lkml.kernel.org/r/161007957862.114704.4512260007555399463.stgit@devnote2Cc: stable@vger.kernel.org
Fixes: 45408c4f92506 ("tracing: kprobes: Prohibit probing on notrace function")
Acked-by: Naveen N. Rao
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman -
commit cc5f7e2fcbe396f2f461cd67c872af771a334bca upstream.
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
voltage before the reset sequence is initiated. On most boards, this
assumption is true at boot-up, so initialization succeeds.However, when we try to initialize the chip with incorrect supply
voltages, it will not respond to I2C requests. sii902x_probe() fails
with -ENXIO.To resolve this, look for the "iovcc" and "cvcc12" regulators, and
make sure they are enabled before starting the reset sequence. If
these supplies are not available in devicetree, then they will default
to dummy-regulator. In that case everything will work like before.This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode.
On this board, the supplies would be set by the second stage
bootloader, which does not run in falcon mode.Signed-off-by: Alexandru Gagniuc
Signed-off-by: Sam Ravnborg
[Fix checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-2-mr.nuke.me@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 4c1e054322da99cbfd293a5fddf283f2fdb3e2d0 upstream.
The sii902x chip family requires IO and core voltages to reach the
correct voltage before chip initialization. Add binding for describing
the two supplies.Signed-off-by: Alexandru Gagniuc
Acked-by: Rob Herring
Signed-off-by: Sam Ravnborg
Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-3-mr.nuke.me@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 91b5e26731c5d409d6134603afc061617639933e upstream.
Separate the hardware initialization code from setting up the data
structures and parsing the device tree. The purpose of this change is
to provide a single exit point and avoid a waterfall of 'goto's in
the subsequent patch.Signed-off-by: Alexandru Gagniuc
Signed-off-by: Sam Ravnborg
Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-1-mr.nuke.me@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit bb83d5fb550bb7db75b29e6342417fda2bbb691c upstream.
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.The CPU mode takeover code added in commit 5b1ec9ac7ab5
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.Fixes: 5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Lyude Paul
Cc: # v5.1+
Reviewed-by: Lyude Paul
Signed-off-by: Jani Nikula
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
(cherry picked from commit 0d4ced1c5bfe649196877d90442d4fd618e19153)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit ffaf97899c4a58b9fefb11534f730785443611a8 upstream.
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
based on plaform and the number of EU based on the number of slices and
subslices. This is a fixed number per platform/gt, so appropriately
limit the number of threads we spawn to match the device.v2: Oversaturate the system with tasks to force execution on every HW
thread; if the thread idles it is returned to the pool and may be reused
again before an unused thread.v3: Fix more state commands, which was causing Baytrail to barf.
v4: STATE_CACHE_INVALIDATE requires a stall on IvybridgeCloses: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Prathap Kumar Valsan
Cc: Akeem G Abodunrin
Cc: Jon Bloomfield
Cc: Rodrigo Vivi
Cc: Randy Wright
Cc: stable@vger.kernel.org # v5.7+
Reviewed-by: Akeem G Abodunrin
Reviewed-by: Rodrigo Vivi
Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-1-chris@chris-wilson.co.uk
(cherry picked from commit eebfb32e26851662d24ea86dd381fd0f83cd4b47)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 984cadea032b103c5824a5f29d0a36b3e9df6333 upstream.
The clear-residuals mitigation is a relatively heavy hammer and under some
circumstances the user may wish to forgo the context isolation in order
to meet some performance requirement. Introduce a generic module
parameter to allow selectively enabling/disabling different mitigations.To disable just the clear-residuals mitigation (on Ivybridge, Baytrail,
or Haswell) use the module parameter: i915.mitigations=auto,!residualsCloses: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Rodrigo Vivi
Cc: stable@vger.kernel.org # v5.7
Reviewed-by: Jon Bloomfield
Reviewed-by: Rodrigo Vivi
Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-3-chris@chris-wilson.co.uk
(cherry picked from commit f7452c7cbd5b5dfb9a6c84cb20bea04c89be50cd)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 53f1e7f6a1720f8299b5283857eedc8f07d29533 upstream.
add DID 0x164C into pciidlist under CHIP_RENOIR family.
Signed-off-by: mengwang
Reviewed-by: Huang Rui
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org # 5.10.x
Signed-off-by: Greg Kroah-Hartman -
commit 4eec66c014e9a406d8d453de958f6791d05427e4 upstream.
commit a861736dae64 ("drm/amd/display: Fixed Intermittent blue screen on OLED panel")
causes power regression for many users. It seems that this change causes
the MCLK to get forced high; this creates a regression for many users
since their devices were not able to drop to a low state after this
change. For this reason, this reverts commit
a861736dae644a0d7abbca0c638ae6aad28feeb8.Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1407
Cc: Aurabindo Pillai
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Naveed Ashfaq
Cc: Hersen Wu
Cc: Roman Li
Acked-by: Alex Deucher
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit ff9346dbabbb6595c5c20d90d88ae4a2247487a9 upstream.
This fix bug 210921 where DRM_INFO floods log when hitting an unsupported ASIC in
amdgpu_device_asic_has_dc_support(). This info should be only called once.Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210921
Signed-off-by: Alexandre Demers
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 21702c8cae51535e09b91341a069503c6ef3d2a3 upstream.
Add green_sardine PCI id support and map it to renoir asic type.
v2: add apu flag
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
Reviewed-by: Huang Rui
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org # 5.10.x
Signed-off-by: Greg Kroah-Hartman -
commit ad0a6bad44758afa3b440c254a24999a0c7e35d5 upstream.
We've observed crashes due to an empty cpu mask in
hyperv_flush_tlb_others. Obviously the cpu mask in question is changed
between the cpumask_empty call at the beginning of the function and when
it is actually used later.One theory is that an interrupt comes in between and a code path ends up
changing the mask. Move the check after interrupt has been disabled to
see if it fixes the issue.Signed-off-by: Wei Liu
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20210105175043.28325-1-wei.liu@kernel.org
Reviewed-by: Michael Kelley
Signed-off-by: Greg Kroah-Hartman -
commit 5c6679b5cb120f07652418524ab186ac47680b49 upstream.
A widget's "dirty" list_head, much like its "list" list_head, eventually
chains back to a list_head on the snd_soc_card itself. This means that
the list can stick around even after the widget (or all widgets) have
been freed. Currently, however, widgets that are in the dirty list when
freed remain there, corrupting the entire list and leading to memory
errors and undefined behavior when the list is next accessed or
modified.I encountered this issue when a component failed to probe relatively
late in snd_soc_bind_card(), causing it to bail out and call
soc_cleanup_card_resources(), which eventually called
snd_soc_dapm_free() with widgets that were still dirty from when they'd
been added.Fixes: db432b414e20 ("ASoC: Do DAPM power checks only for widgets changed since last run")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hebb
Reviewed-by: Charles Keepax
Link: https://lore.kernel.org/r/f8b5f031d50122bf1a9bfc9cae046badf4a7a31a.1607822410.git.tommyhebb@gmail.com
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 1f092d1c8819679d78a7d9c62a46d4939d217a9d upstream.
The ThinkPad X395 latop does not have the internal digital
microphone connected to the AMD's ACP bridge, but it's advertised
via BIOS. The internal microphone is connected to the HDA codec.Use DMI to block the microphone PCM device for this platform.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1892115
Cc:
Signed-off-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20201227164109.269973-1-perex@perex.cz
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3e096a2112b7b407549020cf095e2a425f00fabb upstream.
MIXART.txt has been converted to ReST and renamed. Fix the reference
in alsa-configuration.rst.Fixes: 3d8e81862ce4 ("ALSA: doc: ReSTize MIXART.txt")
Signed-off-by: Jonathan Neuschäfer
Cc:
Link: https://lore.kernel.org/r/20210101221942.1068388-1-j.neuschaefer@gmx.net
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 91bc156817a3c2007332b64b4f85c32aafbbbea6 upstream.
* The HP ZBook Fury 15/17 G7 Mobile Workstation are using ALC285 codec
which is using 0x04 to control mute LED and 0x01 to control micmute LED.* The right channel speaker is no sound and it needs to expose GPIO1 for
initialing AMP.Add quirks to support them.
Signed-off-by: Jeremy Szu
Cc:
Link: https://lore.kernel.org/r/20210106130549.100532-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 29b665cc51e8b602bf2a275734349494776e3dbc upstream.
Some extent io trees are initialized with NULL private member (e.g.
btrfs_device::alloc_state and btrfs_fs_info::excluded_extents).
Dereference of a NULL tree->private as inode pointer will cause panic.Pass tree->fs_info as it's known to be valid in all cases.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208929
Fixes: 05912a3c04eb ("btrfs: drop extent_io_ops::tree_fs_info callback")
CC: stable@vger.kernel.org # 4.19+
Reviewed-by: Anand Jain
Signed-off-by: Su Yue
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman -
commit 50e31ef486afe60f128d42fb9620e2a63172c15c upstream.
[BUG]
There are several bug reports about recent kernel unable to relocate
certain data block groups.Sometimes the error just goes away, but there is one reporter who can
reproduce it reliably.The dmesg would look like:
[438.260483] BTRFS info (device dm-10): balance: start -dvrange=34625344765952..34625344765953
[438.269018] BTRFS info (device dm-10): relocating block group 34625344765952 flags data|raid1
[450.439609] BTRFS info (device dm-10): found 167 extents, stage: move data extents
[463.501781] BTRFS info (device dm-10): balance: ended with status: -2[CAUSE]
The ENOENT error is returned from the following call chain:add_data_references()
|- delete_v1_space_cache();
|- if (!found)
return -ENOENT;The variable @found is set to true if we find a data extent whose
disk bytenr matches parameter @data_bytes.With extra debugging, the offending tree block looks like this:
leaf bytenr = 42676709441536, data_bytenr = 34626327621632
ctime 1567904822.739884119 (2019-09-08 03:07:02)
mtime 0.0 (1970-01-01 01:00:00)
otime 0.0 (1970-01-01 01:00:00)
item 27 key (51933 EXTENT_DATA 0) itemoff 9854 itemsize 53
generation 1517381 type 2 (prealloc)
prealloc data disk byte 34626327621632 nr 262144 <<<
prealloc data offset 0 nr 262144
item 28 key (52262 ROOT_ITEM 0) itemoff 9415 itemsize 439
generation 2618893 root_dirid 256 bytenr 42677048360960 level 3 refs 1
lastsnap 2618893 byte_limit 0 bytes_used 5557338112 flags 0x0(none)
uuid d0d4361f-d231-6d40-8901-fe506e4b2b53Although item 27 has disk bytenr 34626327621632, which matches the
data_bytenr, its type is prealloc, not reg.
This makes the existing code skip that item, and return ENOENT.[FIX]
The code is modified in commit 19b546d7a1b2 ("btrfs: relocation: Use
btrfs_find_all_leafs to locate data extent parent tree leaves"), before
that commit, we use something like"if (type == BTRFS_FILE_EXTENT_INLINE) continue;"
But in that offending commit, we use (type == BTRFS_FILE_EXTENT_REG),
ignoring BTRFS_FILE_EXTENT_PREALLOC.Fix it by also checking BTRFS_FILE_EXTENT_PREALLOC.
Reported-by: Stéphane Lesimple
Link: https://lore.kernel.org/linux-btrfs/505cabfa88575ed6dbe7cb922d8914fb@lesimple.fr
Fixes: 19b546d7a1b2 ("btrfs: relocation: Use btrfs_find_all_leafs to locate data extent parent tree leaves")
CC: stable@vger.kernel.org # 5.6+
Tested-By: Stéphane Lesimple
Reviewed-by: Su Yue
Signed-off-by: Qu Wenruo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
17 Jan, 2021
19 commits
-
Tested-by: Jon Hunter
Tested-by: Shuah Khan
Tested-by: Guenter Roeck
Tested-by: Linux Kernel Functional Testing
Tested-by: Pavel Machek (CIP)
Link: https://lore.kernel.org/r/20210115122006.047132306@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
commit 4a443a51776ca9847942523cf987a330894d3a31 upstream.
To pick the changes from:
3ceb6543e9cf6ed8 ("fscrypt: remove kernel-internal constants from UAPI header")
That don't result in any changes in tooling, just addressing this perf
build warning:Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h'
diff -u tools/include/uapi/linux/fscrypt.h include/uapi/linux/fscrypt.hCc: Adrian Hunter
Cc: Eric Biggers
Cc: Ian Rogers
Cc: Jiri Olsa
Cc: Namhyung Kim
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit 7d6763ab77b3c047cf7d31ca7c4b799808a684a6 upstream.
Commit a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on
open/close") left unused variables behind, thus generating a warning
at compilation time. Remove those variables.Fixes: a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on open/close")
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Link: https://patchwork.freedesktop.org/patch/msgid/20201101173817.831769-1-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman -
commit f6bcb4c7f366905b66ce8ffca7190118244bb642 upstream.
This code will leak "map->debugfs_name" because the if statement is
reversed so it only frees NULL pointers instead of non-NULL. In
fact the if statement is not required and should just be removed
because kfree() accepts NULL pointers.Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Signed-off-by: Dan Carpenter
Link: https://lore.kernel.org/r/X/RQpfAwRdLg0GqQ@mwanda
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 54970a2fbb673f090b7f02d7f57b10b2e0707155 upstream.
syzbot reproduces BUG_ON in skb_checksum_help():
tun creates (bogus) skb with huge partial-checksummed area and
small ip packet inside. Then ip_rcv trims the skb based on size
of internal ip packet, after that csum offset points beyond of
trimmed skb. Then checksum_tg() called via netfilter hook
triggers BUG_ON:offset = skb_checksum_start_offset(skb);
BUG_ON(offset >= skb_headlen(skb));To work around the problem this patch forces pskb_trim_rcsum_slow()
to return -EINVAL in described scenario. It allows its callers to
drop such kind of packets.Link: https://syzkaller.appspot.com/bug?id=b419a5ca95062664fe1a60b764621eb4526e2cd0
Reported-by: syzbot+7010af67ced6105e5ab6@syzkaller.appspotmail.com
Signed-off-by: Vasily Averin
Acked-by: Willem de Bruijn
Link: https://lore.kernel.org/r/1b2494af-2c56-8ee2-7bc0-923fcad1cdf8@virtuozzo.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman -
commit aebf5db917055b38f4945ed6d621d9f07a44ff30 upstream.
Make sure that bdgrab() is done on the 'block_device' instance before
referring to it for avoiding use-after-free.Cc:
Reported-by: syzbot+825f0f9657d4e528046e@syzkaller.appspotmail.com
Signed-off-by: Ming Lei
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit b42b3a2744b3e8f427de79896720c72823af91ad upstream.
Initialize the sockaddr_can structure to prevent a data leak to user space.
Suggested-by: Cong Wang
Reported-by: syzbot+057884e2f453e8afebc8@syzkaller.appspotmail.com
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Signed-off-by: Oliver Hartkopp
Link: https://lore.kernel.org/r/20210112091643.11789-1-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 3a21777c6ee99749bac10727b3c17e5bcfebe5c1 upstream.
We had kernel panic, it is caused by unload module and last
close confirmation.call trace:
[1196029.743127] free_sess+0x15/0x50 [rtrs_client]
[1196029.743128] rtrs_clt_close+0x4c/0x70 [rtrs_client]
[1196029.743129] ? rnbd_clt_unmap_device+0x1b0/0x1b0 [rnbd_client]
[1196029.743130] close_rtrs+0x25/0x50 [rnbd_client]
[1196029.743131] rnbd_client_exit+0x93/0xb99 [rnbd_client]
[1196029.743132] __x64_sys_delete_module+0x190/0x260And in the crashdump confirmation kworker is also running.
PID: 6943 TASK: ffff9e2ac8098000 CPU: 4 COMMAND: "kworker/4:2"
#0 [ffffb206cf337c30] __schedule at ffffffff9f93f891
#1 [ffffb206cf337cc8] schedule at ffffffff9f93fe98
#2 [ffffb206cf337cd0] schedule_timeout at ffffffff9f943938
#3 [ffffb206cf337d50] wait_for_completion at ffffffff9f9410a7
#4 [ffffb206cf337da0] __flush_work at ffffffff9f08ce0e
#5 [ffffb206cf337e20] rtrs_clt_close_conns at ffffffffc0d5f668 [rtrs_client]
#6 [ffffb206cf337e48] rtrs_clt_close at ffffffffc0d5f801 [rtrs_client]
#7 [ffffb206cf337e68] close_rtrs at ffffffffc0d26255 [rnbd_client]
#8 [ffffb206cf337e78] free_sess at ffffffffc0d262ad [rnbd_client]
#9 [ffffb206cf337e88] rnbd_clt_put_dev at ffffffffc0d266a7 [rnbd_client]The problem is both code path try to close same session, which lead to
panic.To fix it, just skip the sess if the refcount already drop to 0.
Fixes: f7a7a5c228d4 ("block/rnbd: client: main functionality")
Signed-off-by: Jack Wang
Reviewed-by: Gioh Kim
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit b1b95cb5c0a9694d47d5f845ba97e226cfda957d upstream.
Rollback the reservation in the completion ring when we get a
NETDEV_TX_BUSY. When this error is received from the driver, we are
supposed to let the user application retry the transmit again. And in
order to do this, we need to roll back the failed send so it can be
retried. Unfortunately, we did not cancel the reservation we had made
in the completion ring. By not doing this, we actually make the
completion ring one entry smaller per NETDEV_TX_BUSY error we get, and
after enough of these errors the completion ring will be of size zero
and transmit will stop working.Fix this by cancelling the reservation when we get a NETDEV_TX_BUSY
error.Fixes: 642e450b6b59 ("xsk: Do not discard packet when NETDEV_TX_BUSY")
Reported-by: Xuan Zhuo
Signed-off-by: Magnus Karlsson
Signed-off-by: Daniel Borkmann
Acked-by: Björn Töpel
Link: https://lore.kernel.org/bpf/20201218134525.13119-3-magnus.karlsson@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit f09ced4053bc0a2094a12b60b646114c966ef4c6 upstream.
Fix a race when multiple sockets are simultaneously calling sendto()
when the completion ring is shared in the SKB case. This is the case
when you share the same netdev and queue id through the
XDP_SHARED_UMEM bind flag. The problem is that multiple processes can
be in xsk_generic_xmit() and call the backpressure mechanism in
xskq_prod_reserve(xs->pool->cq). As this is a shared resource in this
specific scenario, a race might occur since the rings are
single-producer single-consumer.Fix this by moving the tx_completion_lock from the socket to the pool
as the pool is shared between the sockets that share the completion
ring. (The pool is not shared when this is not the case.) And then
protect the accesses to xskq_prod_reserve() with this lock. The
tx_completion_lock is renamed cq_lock to better reflect that it
protects accesses to the potentially shared completion ring.Fixes: 35fcde7f8deb ("xsk: support for Tx")
Reported-by: Xuan Zhuo
Signed-off-by: Magnus Karlsson
Signed-off-by: Daniel Borkmann
Acked-by: Björn Töpel
Link: https://lore.kernel.org/bpf/20201218134525.13119-2-magnus.karlsson@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 2a5f1b67ec577fb1544b563086e0377f095f88e2 upstream.
We reset the guest's view of PMCR_EL0 unconditionally, based on
the host's view of this register. It is however legal for an
implementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register
when no PMU is available, sidestepping the issue entirely.
If no PMU is available, the guest is not able to request
a virtual PMU anyway, so not doing nothing is the right thing
to do!It is unlikely that this bug can hit any HW implementation
though, as they all provide a PMU. It has been found using nested
virt with the host KVM not implementing the PMU itself.Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")
Reviewed-by: Alexandru Elisei
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20201210083059.1277162-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit a5c9ca76a1c61fb5e4c35de8eb25aa925b03c9e4 upstream.
For IPv6 traffic, mausezahn needs to be invoked with '-6'. Otherwise an
error is returned:# ip netns exec me mausezahn veth1 -B 2001:db8:101::2 -A 2001:db8:91::1 -c 0 -t tcp "dp=1-1023, flags=syn"
Failed to set source IPv4 address. Please check if source is set to a valid IPv4 address.
Invalid command line parameters!Fixes: 7c741868ceab ("selftests: Add torture tests to nexthop tests")
Signed-off-by: Ido Schimmel
Reviewed-by: Petr Machata
Reviewed-by: David Ahern
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman -
commit 0d136f5cd9a7ba6ded7f8ff17e8b1ba680f37625 upstream.
The error message says that "Jumbo frames are not supported on XDP", but
the code checks for mtu > MVNETA_MAX_RX_BUF_SIZE, not mtu > 1500.Fix this error message.
Signed-off-by: Marek Behún
Fixes: 0db51da7a8e9 ("net: mvneta: add basic XDP support")
Cc: Lorenzo Bianconi
Cc: Thomas Petazzoni
Link: https://lore.kernel.org/r/20210105172333.21613-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman -
commit 9397d66212cdf7a21c66523f1583e5d63a609e84 upstream.
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a
single global pm_qos does not suffice. (One connector may disable the
dma-latency boost prematurely while the second is still depending on
it.) Instead of a single global pm_qos, track the pm_qos request for
each intel_dp.v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini
Fixes: 9ee32fea5fe8 ("drm/i915: irq-drive the dp aux communication")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Imre Deak
Reviewed-by: Imre Deak
Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
(cherry picked from commit b3304591f14b437b6bccd8dbff06006c11837031)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 87508224485323ce2d4e7fb929ec80f51adcc238 upstream.
Force link UP can be enabled by bootloader during tftpboot
and breaks NFS support.
Force link UP disabled during port init procedure.Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
Signed-off-by: Stefan Chulski
Acked-by: Marcin Wojtas
Link: https://lore.kernel.org/r/1608216735-14501-1-git-send-email-stefanc@marvell.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman -
commit df6b92fa40050e59ea89784294bf6d04c0c47705 upstream.
According to the datasheet pm8009's HFS515 regulators have 16mV
resolution rather than declared 1.6 mV. Correct the resolution.Signed-off-by: Dmitry Baryshkov
Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
Reviewed-by: Vinod Koul
Link: https://lore.kernel.org/r/20201231122348.637917-3-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 45ba7b195a369f35cb39094fdb32efe5908b34ad upstream.
Commit d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST") deletes
CONFIG_KVM_ARM_HOST option, it should use CONFIG_KVM instead.Just remove CONFIG_KVM_ARM_HOST here.
Fixes: d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST")
Signed-off-by: Shannon Zhao
Acked-by: Catalin Marinas
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/1609760324-92271-1-git-send-email-shannon.zhao@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman -
commit 69931e11288520c250152180ecf9b6ac5e6e40ed upstream.
Without this, the driver runs into a link failure
arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe':
slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write':
slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table'Fixes: c37d4a0085c5 ("Maxim/driver: Add driver for maxim ds26522")
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit cffa4b2122f5f3e53cf3d529bbc74651f95856d5 upstream.
After initializing the regmap through
syscon_regmap_lookup_by_compatible, then regmap_attach_dev to the
device, because the debugfs_name has been allocated, there is no
need to redistribute it againunreferenced object 0xd8399b80 (size 64):
comm "swapper/0", pid 1, jiffies 4294937641 (age 278.590s)
hex dump (first 32 bytes):
64 75 6d 6d 79 2d 69 6f 6d 75 78 63 2d 67 70 72
dummy-iomuxc-gpr
40 32 30 65 34 30 30 30 00 7f 52 5b d8 7e 42 69
@20e4000..R[.~Bi
backtrace:
[] kasprintf+0x2c/0x54
[] regmap_debugfs_init+0xdc/0x2fc
[] __regmap_init+0xc38/0xd88
[] of_syscon_register+0x168/0x294
[] device_node_get_regmap+0x6c/0x98
[] imx6ul_init_machine+0x20/0x88
[] customize_machine+0x1c/0x30
[] do_one_initcall+0x80/0x3ac
[] kernel_init_freeable+0x170/0x1f0
[] kernel_init+0x8/0x120
[] ret_from_fork+0x14/0x20
[] 0x0Fixes: 9b947a13e7f6 ("regmap: use debugfs even when no device")
Signed-off-by: Xiaolei Wang
Link: https://lore.kernel.org/r/20201229105046.41984-1-xiaolei.wang@windriver.com
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
