* [PATCH 5.4 01/86] i2c: bpmp-tegra: Ignore unknown I2C_M flags
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 02/86] platform/x86: i2c-multi-instantiate: Dont create platform device for INT3515 ACPI nodes Greg Kroah-Hartman
` (87 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikko Perttunen, Wolfram Sang
From: Mikko Perttunen <mperttunen@nvidia.com>
commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream.
In order to not to start returning errors when new I2C_M flags are
added, change behavior to just ignore all flags that we don't know
about. This includes the I2C_M_DMA_SAFE flag that already exists but
causes -EINVAL to be returned for valid transactions.
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-tegra-bpmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-tegra-bpmp.c
+++ b/drivers/i2c/busses/i2c-tegra-bpmp.c
@@ -80,7 +80,7 @@ static int tegra_bpmp_xlate_flags(u16 fl
flags &= ~I2C_M_RECV_LEN;
}
- return (flags != 0) ? -EINVAL : 0;
+ return 0;
}
/**
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 02/86] platform/x86: i2c-multi-instantiate: Dont create platform device for INT3515 ACPI nodes
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 01/86] i2c: bpmp-tegra: Ignore unknown I2C_M flags Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 03/86] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634 Greg Kroah-Hartman
` (86 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Moody Salem, Heikki Krogerus, Hans de Goede
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
commit 9bba96275576da0cf78ede62aeb2fc975ed8a32d upstream.
There are several reports about the tps6598x causing
interrupt flood on boards with the INT3515 ACPI node, which
then causes instability. There appears to be several
problems with the interrupt. One problem is that the
I2CSerialBus resources do not always map to the Interrupt
resource with the same index, but that is not the only
problem. We have not been able to come up with a solution
for all the issues, and because of that disabling the device
for now.
The PD controller on these platforms is autonomous, and the
purpose for the driver is primarily to supply status to the
userspace, so this will not affect any functionality.
Reported-by: Moody Salem <moody@uniswap.org>
Fixes: a3dd034a1707 ("ACPI / scan: Create platform device for INT3515 ACPI nodes")
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883511
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201223143644.33341-1-heikki.krogerus@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/i2c-multi-instantiate.c | 31 ++++++++++++++++++++-------
1 file changed, 23 insertions(+), 8 deletions(-)
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -166,13 +166,29 @@ static const struct i2c_inst_data bsg215
{}
};
-static const struct i2c_inst_data int3515_data[] = {
- { "tps6598x", IRQ_RESOURCE_APIC, 0 },
- { "tps6598x", IRQ_RESOURCE_APIC, 1 },
- { "tps6598x", IRQ_RESOURCE_APIC, 2 },
- { "tps6598x", IRQ_RESOURCE_APIC, 3 },
- {}
-};
+/*
+ * Device with _HID INT3515 (TI PD controllers) has some unresolved interrupt
+ * issues. The most common problem seen is interrupt flood.
+ *
+ * There are at least two known causes. Firstly, on some boards, the
+ * I2CSerialBus resource index does not match the Interrupt resource, i.e. they
+ * are not one-to-one mapped like in the array below. Secondly, on some boards
+ * the IRQ line from the PD controller is not actually connected at all. But the
+ * interrupt flood is also seen on some boards where those are not a problem, so
+ * there are some other problems as well.
+ *
+ * Because of the issues with the interrupt, the device is disabled for now. If
+ * you wish to debug the issues, uncomment the below, and add an entry for the
+ * INT3515 device to the i2c_multi_instance_ids table.
+ *
+ * static const struct i2c_inst_data int3515_data[] = {
+ * { "tps6598x", IRQ_RESOURCE_APIC, 0 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 1 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 2 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 3 },
+ * { }
+ * };
+ */
/*
* Note new device-ids must also be added to i2c_multi_instantiate_ids in
@@ -181,7 +197,6 @@ static const struct i2c_inst_data int351
static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
{ "BSG1160", (unsigned long)bsg1160_data },
{ "BSG2150", (unsigned long)bsg2150_data },
- { "INT3515", (unsigned long)int3515_data },
{ }
};
MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 03/86] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 01/86] i2c: bpmp-tegra: Ignore unknown I2C_M flags Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 02/86] platform/x86: i2c-multi-instantiate: Dont create platform device for INT3515 ACPI nodes Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 04/86] ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info() Greg Kroah-Hartman
` (85 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jiaxun Yang, Hans de Goede
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
commit f419e5940f1d9892ea6f45acdaca572b9e73ff39 upstream.
Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not
use EC to switch touchpad.
Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked
unexpectedly.
Writing VPCCMD_W_TOUCHPAD may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: stable@vger.kernel.org # 5.4+
--
v2: Specify touchpad to ELAN0634
v3: Stupid missing ! in v2
v4: Correct acpi_dev_present usage (Hans)
Link: https://lore.kernel.org/r/20210107144438.12605-1-jiaxun.yang@flygoat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/ideapad-laptop.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct
} else if (attr == &dev_attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == &dev_attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value)) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platf
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
+ priv->has_touchpad_switch = !acpi_dev_present("ELAN0634", NULL, -1);
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platf
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg))
ideapad_register_rfkill(priv, i);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 04/86] ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 03/86] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634 Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 05/86] ALSA: hda/via: Add minimum mute flag Greg Kroah-Hartman
` (84 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+e42504ff21cff05a595f, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 217bfbb8b0bfa24619b11ab75c135fec99b99b20 upstream.
snd_seq_oss_synth_make_info() didn't check the error code from
snd_seq_oss_midi_make_info(), and this leads to the call of strlcpy()
with the uninitialized string as the source, which may lead to the
access over the limit.
Add the proper error check for avoiding the failure.
Reported-by: syzbot+e42504ff21cff05a595f@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210115093428.15882-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/oss/seq_oss_synth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/core/seq/oss/seq_oss_synth.c
+++ b/sound/core/seq/oss/seq_oss_synth.c
@@ -611,7 +611,8 @@ snd_seq_oss_synth_make_info(struct seq_o
if (info->is_midi) {
struct midi_info minf;
- snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf);
+ if (snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf))
+ return -ENXIO;
inf->synth_type = SYNTH_TYPE_MIDI;
inf->synth_subtype = 0;
inf->nr_voices = 16;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 05/86] ALSA: hda/via: Add minimum mute flag
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 04/86] ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info() Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 06/86] ACPI: scan: Make acpi_bus_get_device() clear return pointer on error Greg Kroah-Hartman
` (83 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 67ea698c3950d10925be33c21ca49ffb64e21842 upstream.
It turned out that VIA codecs also mute the sound in the lowest mixer
level. Turn on the dac_min_mute flag to indicate the mute-as-minimum
in TLV like already done in Conexant and IDT codecs.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210559
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210114072453.11379-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_via.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_via.c
+++ b/sound/pci/hda/patch_via.c
@@ -113,6 +113,7 @@ static struct via_spec *via_new_spec(str
spec->codec_type = VT1708S;
spec->gen.indep_hp = 1;
spec->gen.keep_eapd_on = 1;
+ spec->gen.dac_min_mute = 1;
spec->gen.pcm_playback_hook = via_playback_pcm_hook;
spec->gen.add_stereo_mix_input = HDA_HINT_STEREO_MIX_AUTO;
codec->power_save_node = 1;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 06/86] ACPI: scan: Make acpi_bus_get_device() clear return pointer on error
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 05/86] ALSA: hda/via: Add minimum mute flag Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 07/86] btrfs: dont get an EINTR during drop_snapshot for reloc Greg Kroah-Hartman
` (82 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pierre-Louis Bossart, Hans de Goede,
Rafael J. Wysocki, Rafael J . Wysocki
From: Hans de Goede <hdegoede@redhat.com>
commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream.
Set the acpi_device pointer which acpi_bus_get_device() returns-by-
reference to NULL on errors.
We've recently had 2 cases where callers of acpi_bus_get_device()
did not properly error check the return value, so set the returned-
by-reference acpi_device pointer to NULL, because at least some
callers of acpi_bus_get_device() expect that to be done on errors.
[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan:
Defer enumeration of devices with _DEP lists") which caused it to
be much more likely to occur on some systems, but the real defect
had been introduced by an earlier commit. ]
Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA")
Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device")
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Diagnosed-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: All applicable <stable@vger.kernel.org>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/scan.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -587,6 +587,8 @@ static int acpi_get_device_data(acpi_han
if (!device)
return -EINVAL;
+ *device = NULL;
+
status = acpi_get_data_full(handle, acpi_scan_drop_device,
(void **)device, callback);
if (ACPI_FAILURE(status) || !*device) {
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 07/86] btrfs: dont get an EINTR during drop_snapshot for reloc
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 06/86] ACPI: scan: Make acpi_bus_get_device() clear return pointer on error Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 08/86] btrfs: fix lockdep splat in btrfs_recover_relocation Greg Kroah-Hartman
` (81 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit 18d3bff411c8d46d40537483bdc0b61b33ce0371 upstream.
This was partially fixed by f3e3d9cc3525 ("btrfs: avoid possible signal
interruption of btrfs_drop_snapshot() on relocation tree"), however it
missed a spot when we restart a trans handle because we need to end the
transaction. The fix is the same, simply use btrfs_join_transaction()
instead of btrfs_start_transaction() when deleting reloc roots.
Fixes: f3e3d9cc3525 ("btrfs: avoid possible signal interruption of btrfs_drop_snapshot() on relocation tree")
CC: stable@vger.kernel.org # 5.4+
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent-tree.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5390,7 +5390,15 @@ int btrfs_drop_snapshot(struct btrfs_roo
goto out_free;
}
- trans = btrfs_start_transaction(tree_root, 0);
+ /*
+ * Use join to avoid potential EINTR from transaction
+ * start. See wait_reserve_ticket and the whole
+ * reservation callchain.
+ */
+ if (for_reloc)
+ trans = btrfs_join_transaction(tree_root);
+ else
+ trans = btrfs_start_transaction(tree_root, 0);
if (IS_ERR(trans)) {
err = PTR_ERR(trans);
goto out_free;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 08/86] btrfs: fix lockdep splat in btrfs_recover_relocation
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 07/86] btrfs: dont get an EINTR during drop_snapshot for reloc Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 09/86] btrfs: dont clear ret in btrfs_start_dirty_block_groups Greg Kroah-Hartman
` (80 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qu Wenruo, Johannes Thumshirn,
Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit fb286100974e7239af243bc2255a52f29442f9c8 upstream.
While testing the error paths of relocation I hit the following lockdep
splat:
======================================================
WARNING: possible circular locking dependency detected
5.10.0-rc6+ #217 Not tainted
------------------------------------------------------
mount/779 is trying to acquire lock:
ffffa0e676945418 (&fs_info->balance_mutex){+.+.}-{3:3}, at: btrfs_recover_balance+0x2f0/0x340
but task is already holding lock:
ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (btrfs-root-00){++++}-{3:3}:
down_read_nested+0x43/0x130
__btrfs_tree_read_lock+0x27/0x100
btrfs_read_lock_root_node+0x31/0x40
btrfs_search_slot+0x462/0x8f0
btrfs_update_root+0x55/0x2b0
btrfs_drop_snapshot+0x398/0x750
clean_dirty_subvols+0xdf/0x120
btrfs_recover_relocation+0x534/0x5a0
btrfs_start_pre_rw_mount+0xcb/0x170
open_ctree+0x151f/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #1 (sb_internal#2){.+.+}-{0:0}:
start_transaction+0x444/0x700
insert_balance_item.isra.0+0x37/0x320
btrfs_balance+0x354/0xf40
btrfs_ioctl_balance+0x2cf/0x380
__x64_sys_ioctl+0x83/0xb0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (&fs_info->balance_mutex){+.+.}-{3:3}:
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
__mutex_lock+0x7e/0x7b0
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Chain exists of:
&fs_info->balance_mutex --> sb_internal#2 --> btrfs-root-00
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(btrfs-root-00);
lock(sb_internal#2);
lock(btrfs-root-00);
lock(&fs_info->balance_mutex);
*** DEADLOCK ***
2 locks held by mount/779:
#0: ffffa0e60dc040e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at: alloc_super+0xb5/0x380
#1: ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100
stack backtrace:
CPU: 0 PID: 779 Comm: mount Not tainted 5.10.0-rc6+ #217
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x8b/0xb0
check_noncircular+0xcf/0xf0
? trace_call_bpf+0x139/0x260
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
? btrfs_recover_balance+0x2f0/0x340
__mutex_lock+0x7e/0x7b0
? btrfs_recover_balance+0x2f0/0x340
? btrfs_recover_balance+0x2f0/0x340
? rcu_read_lock_sched_held+0x3f/0x80
? kmem_cache_alloc_trace+0x2c4/0x2f0
? btrfs_get_64+0x5e/0x100
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
? rcu_read_lock_sched_held+0x3f/0x80
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
? __kmalloc_track_caller+0x2f2/0x320
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
? capable+0x3a/0x60
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
This is straightforward to fix, simply release the path before we setup
the balance_ctl.
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4409,6 +4409,8 @@ int btrfs_recover_balance(struct btrfs_f
btrfs_warn(fs_info,
"balance: cannot set exclusive op status, resume manually");
+ btrfs_release_path(path);
+
mutex_lock(&fs_info->balance_mutex);
BUG_ON(fs_info->balance_ctl);
spin_lock(&fs_info->balance_lock);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 09/86] btrfs: dont clear ret in btrfs_start_dirty_block_groups
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 08/86] btrfs: fix lockdep splat in btrfs_recover_relocation Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 10/86] btrfs: send: fix invalid clone operations when cloning from the same file and root Greg Kroah-Hartman
` (79 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qu Wenruo, Johannes Thumshirn,
Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit 34d1eb0e599875064955a74712f08ff14c8e3d5f upstream.
If we fail to update a block group item in the loop we'll break, however
we'll do btrfs_run_delayed_refs and lose our error value in ret, and
thus not clean up properly. Fix this by only running the delayed refs
if there was no failure.
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/block-group.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -2497,7 +2497,8 @@ again:
* Go through delayed refs for all the stuff we've just kicked off
* and then loop back (just once)
*/
- ret = btrfs_run_delayed_refs(trans, 0);
+ if (!ret)
+ ret = btrfs_run_delayed_refs(trans, 0);
if (!ret && loops == 0) {
loops++;
spin_lock(&cur_trans->dirty_bgs_lock);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 10/86] btrfs: send: fix invalid clone operations when cloning from the same file and root
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 09/86] btrfs: dont clear ret in btrfs_start_dirty_block_groups Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 11/86] mmc: core: dont initialize block size from ext_csd if not present Greg Kroah-Hartman
` (78 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Massimo B.,
Josef Bacik, Filipe Manana, David Sterba
From: Filipe Manana <fdmanana@suse.com>
commit 518837e65068c385dddc0a87b3e577c8be7c13b1 upstream.
When an incremental send finds an extent that is shared, it checks which
file extent items in the range refer to that extent, and for those it
emits clone operations, while for others it emits regular write operations
to avoid corruption at the destination (as described and fixed by commit
d906d49fc5f4 ("Btrfs: send, fix file corruption due to incorrect cloning
operations")).
However when the root we are cloning from is the send root, we are cloning
from the inode currently being processed and the source file range has
several extent items that partially point to the desired extent, with an
offset smaller than the offset in the file extent item for the range we
want to clone into, it can cause the algorithm to issue a clone operation
that starts at the current eof of the file being processed in the receiver
side, in which case the receiver will fail, with EINVAL, when attempting
to execute the clone operation.
Example reproducer:
$ cat test-send-clone.sh
#!/bin/bash
DEV=/dev/sdi
MNT=/mnt/sdi
mkfs.btrfs -f $DEV >/dev/null
mount $DEV $MNT
# Create our test file with a single and large extent (1M) and with
# different content for different file ranges that will be reflinked
# later.
xfs_io -f \
-c "pwrite -S 0xab 0 128K" \
-c "pwrite -S 0xcd 128K 128K" \
-c "pwrite -S 0xef 256K 256K" \
-c "pwrite -S 0x1a 512K 512K" \
$MNT/foobar
btrfs subvolume snapshot -r $MNT $MNT/snap1
btrfs send -f /tmp/snap1.send $MNT/snap1
# Now do a series of changes to our file such that we end up with
# different parts of the extent reflinked into different file offsets
# and we overwrite a large part of the extent too, so no file extent
# items refer to that part that was overwritten. This used to confuse
# the algorithm used by the kernel to figure out which file ranges to
# clone, making it attempt to clone from a source range starting at
# the current eof of the file, resulting in the receiver to fail since
# it is an invalid clone operation.
#
xfs_io -c "reflink $MNT/foobar 64K 1M 960K" \
-c "reflink $MNT/foobar 0K 512K 256K" \
-c "reflink $MNT/foobar 512K 128K 256K" \
-c "pwrite -S 0x73 384K 640K" \
$MNT/foobar
btrfs subvolume snapshot -r $MNT $MNT/snap2
btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2
echo -e "\nFile digest in the original filesystem:"
md5sum $MNT/snap2/foobar
# Now unmount the filesystem, create a new one, mount it and try to
# apply both send streams to recreate both snapshots.
umount $DEV
mkfs.btrfs -f $DEV >/dev/null
mount $DEV $MNT
btrfs receive -f /tmp/snap1.send $MNT
btrfs receive -f /tmp/snap2.send $MNT
# Must match what we got in the original filesystem of course.
echo -e "\nFile digest in the new filesystem:"
md5sum $MNT/snap2/foobar
umount $MNT
When running the reproducer, the incremental send operation fails due to
an invalid clone operation:
$ ./test-send-clone.sh
wrote 131072/131072 bytes at offset 0
128 KiB, 32 ops; 0.0015 sec (80.906 MiB/sec and 20711.9741 ops/sec)
wrote 131072/131072 bytes at offset 131072
128 KiB, 32 ops; 0.0013 sec (90.514 MiB/sec and 23171.6148 ops/sec)
wrote 262144/262144 bytes at offset 262144
256 KiB, 64 ops; 0.0025 sec (98.270 MiB/sec and 25157.2327 ops/sec)
wrote 524288/524288 bytes at offset 524288
512 KiB, 128 ops; 0.0052 sec (95.730 MiB/sec and 24506.9883 ops/sec)
Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1'
At subvol /mnt/sdi/snap1
linked 983040/983040 bytes at offset 1048576
960 KiB, 1 ops; 0.0006 sec (1.419 GiB/sec and 1550.3876 ops/sec)
linked 262144/262144 bytes at offset 524288
256 KiB, 1 ops; 0.0020 sec (120.192 MiB/sec and 480.7692 ops/sec)
linked 262144/262144 bytes at offset 131072
256 KiB, 1 ops; 0.0018 sec (133.833 MiB/sec and 535.3319 ops/sec)
wrote 655360/655360 bytes at offset 393216
640 KiB, 160 ops; 0.0093 sec (66.781 MiB/sec and 17095.8436 ops/sec)
Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2'
At subvol /mnt/sdi/snap2
File digest in the original filesystem:
9c13c61cb0b9f5abf45344375cb04dfa /mnt/sdi/snap2/foobar
At subvol snap1
At snapshot snap2
ERROR: failed to clone extents to foobar: Invalid argument
File digest in the new filesystem:
132f0396da8f48d2e667196bff882cfc /mnt/sdi/snap2/foobar
The clone operation is invalid because its source range starts at the
current eof of the file in the receiver, causing the receiver to get
an EINVAL error from the clone operation when attempting it.
For the example above, what happens is the following:
1) When processing the extent at file offset 1M, the algorithm checks that
the extent is shared and can be (fully or partially) found at file
offset 0.
At this point the file has a size (and eof) of 1M at the receiver;
2) It finds that our extent item at file offset 1M has a data offset of
64K and, since the file extent item at file offset 0 has a data offset
of 0, it issues a clone operation, from the same file and root, that
has a source range offset of 64K, destination offset of 1M and a length
of 64K, since the extent item at file offset 0 refers only to the first
128K of the shared extent.
After this clone operation, the file size (and eof) at the receiver is
increased from 1M to 1088K (1M + 64K);
3) Now there's still 896K (960K - 64K) of data left to clone or write, so
it checks for the next file extent item, which starts at file offset
128K. This file extent item has a data offset of 0 and a length of
256K, so a clone operation with a source range offset of 256K, a
destination offset of 1088K (1M + 64K) and length of 128K is issued.
After this operation the file size (and eof) at the receiver increases
from 1088K to 1216K (1088K + 128K);
4) Now there's still 768K (896K - 128K) of data left to clone or write, so
it checks for the next file extent item, located at file offset 384K.
This file extent item points to a different extent, not the one we want
to clone, with a length of 640K. So we issue a write operation into the
file range 1216K (1088K + 128K, end of the last clone operation), with
a length of 640K and with a data matching the one we can find for that
range in send root.
After this operation, the file size (and eof) at the receiver increases
from 1216K to 1856K (1216K + 640K);
5) Now there's still 128K (768K - 640K) of data left to clone or write, so
we look into the file extent item, which is for file offset 1M and it
points to the extent we want to clone, with a data offset of 64K and a
length of 960K.
However this matches the file offset we started with, the start of the
range to clone into. So we can't for sure find any file extent item
from here onwards with the rest of the data we want to clone, yet we
proceed and since the file extent item points to the shared extent,
with a data offset of 64K, we issue a clone operation with a source
range starting at file offset 1856K, which matches the file extent
item's offset, 1M, plus the amount of data cloned and written so far,
which is 64K (step 2) + 128K (step 3) + 640K (step 4). This clone
operation is invalid since the source range offset matches the current
eof of the file in the receiver. We should have stopped looking for
extents to clone at this point and instead fallback to write, which
would simply the contain the data in the file range from 1856K to
1856K + 128K.
So fix this by stopping the loop that looks for file ranges to clone at
clone_range() when we reach the current eof of the file being processed,
if we are cloning from the same file and using the send root as the clone
root. This ensures any data not yet cloned will be sent to the receiver
through a write operation.
A test case for fstests will follow soon.
Reported-by: Massimo B. <massimo.b@gmx.net>
Link: https://lore.kernel.org/linux-btrfs/6ae34776e85912960a253a8327068a892998e685.camel@gmx.net/
Fixes: 11f2069c113e ("Btrfs: send, allow clone operations within the same file")
CC: stable@vger.kernel.org # 5.5+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/send.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -5519,6 +5519,21 @@ static int clone_range(struct send_ctx *
break;
offset += clone_len;
clone_root->offset += clone_len;
+
+ /*
+ * If we are cloning from the file we are currently processing,
+ * and using the send root as the clone root, we must stop once
+ * the current clone offset reaches the current eof of the file
+ * at the receiver, otherwise we would issue an invalid clone
+ * operation (source range going beyond eof) and cause the
+ * receiver to fail. So if we reach the current eof, bail out
+ * and fallback to a regular write.
+ */
+ if (clone_root->root == sctx->send_root &&
+ clone_root->ino == sctx->cur_ino &&
+ clone_root->offset >= sctx->cur_inode_next_write_offset)
+ break;
+
data_offset += clone_len;
next:
path->slots[0]++;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 11/86] mmc: core: dont initialize block size from ext_csd if not present
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 10/86] btrfs: send: fix invalid clone operations when cloning from the same file and root Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 12/86] mmc: sdhci-xenon: fix 1.8v regulator stabilization Greg Kroah-Hartman
` (77 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Collingbourne, Damien Le Moal,
Adrian Hunter, Ulf Hansson
From: Peter Collingbourne <pcc@google.com>
commit b503087445ce7e45fabdee87ca9e460d5b5b5168 upstream.
If extended CSD was not available, the eMMC driver would incorrectly
set the block size to 0, as the data_sector_size field of ext_csd
was never initialized. This issue was exposed by commit 817046ecddbc
("block: Align max_hw_sectors to logical blocksize") which caused
max_sectors and max_hw_sectors to be set to 0 after setting the block
size to 0, resulting in a kernel panic in bio_split when attempting
to read from the device. Fix it by only reading the block size from
ext_csd if it is available.
Fixes: a5075eb94837 ("mmc: block: Allow disabling 512B sector size emulation")
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Link: https://linux-review.googlesource.com/id/If244d178da4d86b52034459438fec295b02d6e60
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210114201405.2934886-1-pcc@google.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/queue.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -370,8 +370,10 @@ static void mmc_setup_queue(struct mmc_q
"merging was advertised but not possible");
blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
- if (mmc_card_mmc(card))
+ if (mmc_card_mmc(card) && card->ext_csd.data_sector_size) {
block_size = card->ext_csd.data_sector_size;
+ WARN_ON(block_size != 512 && block_size != 4096);
+ }
blk_queue_logical_block_size(mq->queue, block_size);
/*
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 12/86] mmc: sdhci-xenon: fix 1.8v regulator stabilization
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 11/86] mmc: core: dont initialize block size from ext_csd if not present Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 13/86] dm: avoid filesystem lookup in dm_get_dev_t() Greg Kroah-Hartman
` (76 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alex Leibovich, Marcin Wojtas,
Adrian Hunter, Ulf Hansson
From: Alex Leibovich <alexl@marvell.com>
commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream.
Automatic Clock Gating is a feature used for the power consumption
optimisation. It turned out that during early init phase it may prevent the
stable voltage switch to 1.8V - due to that on some platforms an endless
printout in dmesg can be observed: "mmc1: 1.8V regulator output did not
became stable" Fix the problem by disabling the ACG at very beginning of
the sdhci_init and let that be enabled later.
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality")
Signed-off-by: Alex Leibovich <alexl@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: stable@vger.kernel.org
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-xenon.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -167,7 +167,12 @@ static void xenon_reset_exit(struct sdhc
/* Disable tuning request and auto-retuning again */
xenon_retune_setup(host);
- xenon_set_acg(host, true);
+ /*
+ * The ACG should be turned off at the early init time, in order
+ * to solve a possible issues with the 1.8V regulator stabilization.
+ * The feature is enabled in later stage.
+ */
+ xenon_set_acg(host, false);
xenon_set_sdclk_off_idle(host, sdhc_id, false);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 13/86] dm: avoid filesystem lookup in dm_get_dev_t()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 12/86] mmc: sdhci-xenon: fix 1.8v regulator stabilization Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 14/86] dm integrity: fix a crash if "recalculate" used without "internal_hash" Greg Kroah-Hartman
` (75 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hannes Reinecke, Martin Wilck,
Christoph Hellwig, Mike Snitzer
From: Hannes Reinecke <hare@suse.de>
commit 809b1e4945774c9ec5619a8f4e2189b7b3833c0c upstream.
This reverts commit
644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()")
dm_get_dev_t() is just used to convert an arbitrary 'path' string
into a dev_t. It doesn't presume that the device is present; that
check will be done later, as the only caller is dm_get_device(),
which does a dm_get_table_device() later on, which will properly
open the device.
So if the path string already _is_ in major:minor representation
we can convert it directly, avoiding a recursion into the filesystem
to lookup the block device.
This avoids a hang in multipath_message() when the filesystem is
inaccessible.
Fixes: 644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()")
Cc: stable@vger.kernel.org
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-table.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -428,14 +428,23 @@ int dm_get_device(struct dm_target *ti,
{
int r;
dev_t dev;
+ unsigned int major, minor;
+ char dummy;
struct dm_dev_internal *dd;
struct dm_table *t = ti->table;
BUG_ON(!t);
- dev = dm_get_dev_t(path);
- if (!dev)
- return -ENODEV;
+ if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) {
+ /* Extract the major/minor numbers */
+ dev = MKDEV(major, minor);
+ if (MAJOR(dev) != major || MINOR(dev) != minor)
+ return -EOVERFLOW;
+ } else {
+ dev = dm_get_dev_t(path);
+ if (!dev)
+ return -ENODEV;
+ }
dd = find_device(&t->devices, dev);
if (!dd) {
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 14/86] dm integrity: fix a crash if "recalculate" used without "internal_hash"
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 13/86] dm: avoid filesystem lookup in dm_get_dev_t() Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 15/86] drm/atomic: put state on error path Greg Kroah-Hartman
` (74 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
From: Mikulas Patocka <mpatocka@redhat.com>
commit 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 upstream.
Recalculate can only be specified with internal_hash.
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-integrity.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -4059,6 +4059,12 @@ try_smaller_buffer:
r = -ENOMEM;
goto bad;
}
+ } else {
+ if (ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING)) {
+ ti->error = "Recalculate can only be specified with internal_hash";
+ r = -EINVAL;
+ goto bad;
+ }
}
ic->bufio = dm_bufio_client_create(ic->meta_dev ? ic->meta_dev->bdev : ic->dev->bdev,
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 15/86] drm/atomic: put state on error path
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 14/86] dm integrity: fix a crash if "recalculate" used without "internal_hash" Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 16/86] drm/syncobj: Fix use-after-free Greg Kroah-Hartman
` (73 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pan Bian, Daniel Vetter
From: Pan Bian <bianpan2016@163.com>
commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream.
Put the state before returning error code.
Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2016@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2948,7 +2948,7 @@ int drm_atomic_helper_set_config(struct
ret = handle_conflicting_encoders(state, true);
if (ret)
- return ret;
+ goto fail;
ret = drm_atomic_commit(state);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 16/86] drm/syncobj: Fix use-after-free
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 15/86] drm/atomic: put state on error path Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:38 ` [PATCH 5.4 17/86] drm/i915/gt: Prevent use of engine->wa_ctx after error Greg Kroah-Hartman
` (72 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Vetter, Christian König,
Lionel Landwerlin, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, dri-devel
From: Daniel Vetter <daniel.vetter@ffwll.ch>
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in drm_syncobj_find_fence v4")
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.2+
Link: https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_syncobj.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -326,19 +326,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(&wait, 0, sizeof(wait));
wait.task = current;
@@ -370,6 +369,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, &wait);
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 17/86] drm/i915/gt: Prevent use of engine->wa_ctx after error
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 16/86] drm/syncobj: Fix use-after-free Greg Kroah-Hartman
@ 2021-01-25 18:38 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 18/86] ASoC: Intel: haswell: Add missing pm_ops Greg Kroah-Hartman
` (71 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Roper, Chris Wilson,
Tvrtko Ursulin, Mika Kuoppala, Jani Nikula
From: Chris Wilson <chris@chris-wilson.co.uk>
commit 488751a0ef9b5ce572c47301ce62d54fc6b5a74d upstream.
On error we unpin and free the wa_ctx.vma, but do not clear any of the
derived flags. During lrc_init, we look at the flags and attempt to
dereference the wa_ctx.vma if they are set. To protect the error path
where we try to limp along without the wa_ctx, make sure we clear those
flags!
Reported-by: Matt Roper <matthew.d.roper@intel.com>
Fixes: 604a8f6f1e33 ("drm/i915/lrc: Only enable per-context and per-bb buffers if set")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.15+
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-1-chris@chris-wilson.co.uk
(cherry-picked from 5b4dc95cf7f573e927fbbd406ebe54225d41b9b2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118095332.458813-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2245,6 +2245,9 @@ err:
static void lrc_destroy_wa_ctx(struct intel_engine_cs *engine)
{
i915_vma_unpin_and_release(&engine->wa_ctx.vma, 0);
+
+ /* Called on error unwind, clear all flags to prevent further use */
+ memset(&engine->wa_ctx, 0, sizeof(engine->wa_ctx));
}
typedef u32 *(*wa_bb_func_t)(struct intel_engine_cs *engine, u32 *batch);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 18/86] ASoC: Intel: haswell: Add missing pm_ops
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2021-01-25 18:38 ` [PATCH 5.4 17/86] drm/i915/gt: Prevent use of engine->wa_ctx after error Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 19/86] HID: multitouch: Enable multi-input for Synaptics pointstick/touchpad device Greg Kroah-Hartman
` (70 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Cezary Rojewski, Mark Brown, Sasha Levin
From: Cezary Rojewski <cezary.rojewski@intel.com>
[ Upstream commit bb224c3e3e41d940612d4cc9573289cdbd5cb8f5 ]
haswell machine board is missing pm_ops what prevents it from undergoing
suspend-resume procedure successfully. Assign default snd_soc_pm_ops so
this is no longer the case.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20201217105401.27865-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/haswell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/intel/boards/haswell.c b/sound/soc/intel/boards/haswell.c
index 3dadf9bff796a..cf47fd9cd506b 100644
--- a/sound/soc/intel/boards/haswell.c
+++ b/sound/soc/intel/boards/haswell.c
@@ -206,6 +206,7 @@ static struct platform_driver haswell_audio = {
.probe = haswell_audio_probe,
.driver = {
.name = "haswell-audio",
+ .pm = &snd_soc_pm_ops,
},
};
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 19/86] HID: multitouch: Enable multi-input for Synaptics pointstick/touchpad device
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 18/86] ASoC: Intel: haswell: Add missing pm_ops Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 20/86] dm integrity: select CRYPTO_SKCIPHER Greg Kroah-Hartman
` (69 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Jiri Kosina, Sasha Levin
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit c3d6eb6e54373f297313b65c1f2319d36914d579 ]
Pointstick and its left/right buttons on HP EliteBook 850 G7 need
multi-input quirk to work correctly.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-multitouch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 128d8f4319b9f..d91e6679afb18 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -2084,6 +2084,10 @@ static const struct hid_device_id mt_devices[] = {
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_SYNAPTICS, 0xce08) },
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_SYNAPTICS, 0xce09) },
+
/* TopSeed panels */
{ .driver_data = MT_CLS_TOPSEED,
MT_USB_DEVICE(USB_VENDOR_ID_TOPSEED2,
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 20/86] dm integrity: select CRYPTO_SKCIPHER
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 19/86] HID: multitouch: Enable multi-input for Synaptics pointstick/touchpad device Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 21/86] scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback Greg Kroah-Hartman
` (68 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Anthony Iliopoulos, Mike Snitzer,
Sasha Levin
From: Anthony Iliopoulos <ailiop@suse.com>
[ Upstream commit f7b347acb5f6c29d9229bb64893d8b6a2c7949fb ]
The integrity target relies on skcipher for encryption/decryption, but
certain kernel configurations may not enable CRYPTO_SKCIPHER, leading to
compilation errors due to unresolved symbols. Explicitly select
CRYPTO_SKCIPHER for DM_INTEGRITY, since it is unconditionally dependent
on it.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index aa98953f4462e..7dd6e98257c72 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -565,6 +565,7 @@ config DM_INTEGRITY
select BLK_DEV_INTEGRITY
select DM_BUFIO
select CRYPTO
+ select CRYPTO_SKCIPHER
select ASYNC_XOR
---help---
This device-mapper target emulates a block device that has
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 21/86] scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 20/86] dm integrity: select CRYPTO_SKCIPHER Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 22/86] scsi: qedi: Correct max length of CHAP secret Greg Kroah-Hartman
` (67 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Avri Altman, Stanley Chu, Can Guo,
Martin K. Petersen, Sasha Levin
From: Can Guo <cang@codeaurora.org>
[ Upstream commit 35fc4cd34426c242ab015ef280853b7bff101f48 ]
Users can initiate resets to specific SCSI device/target/host through
IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host
_reset_handler() callbacks is initialized with a request whose tag is -1.
In this case it is not right for eh_device_reset_handler() callback to
count on the LUN get from hba->lrb[-1]. Fix it by getting LUN from the SCSI
device associated with the SCSI cmd.
Link: https://lore.kernel.org/r/1609157080-26283-1-git-send-email-cang@codeaurora.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b888117f4ecd3..476ef8044ae59 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5980,19 +5980,16 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd)
{
struct Scsi_Host *host;
struct ufs_hba *hba;
- unsigned int tag;
u32 pos;
int err;
- u8 resp = 0xF;
- struct ufshcd_lrb *lrbp;
+ u8 resp = 0xF, lun;
unsigned long flags;
host = cmd->device->host;
hba = shost_priv(host);
- tag = cmd->request->tag;
- lrbp = &hba->lrb[tag];
- err = ufshcd_issue_tm_cmd(hba, lrbp->lun, 0, UFS_LOGICAL_RESET, &resp);
+ lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun);
+ err = ufshcd_issue_tm_cmd(hba, lun, 0, UFS_LOGICAL_RESET, &resp);
if (err || resp != UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
if (!err)
err = resp;
@@ -6001,7 +5998,7 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd)
/* clear the commands that were pending for corresponding LUN */
for_each_set_bit(pos, &hba->outstanding_reqs, hba->nutrs) {
- if (hba->lrb[pos].lun == lrbp->lun) {
+ if (hba->lrb[pos].lun == lun) {
err = ufshcd_clear_cmd(hba, pos);
if (err)
break;
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 22/86] scsi: qedi: Correct max length of CHAP secret
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 21/86] scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 23/86] scsi: sd: Suppress spurious errors when WRITE SAME is being disabled Greg Kroah-Hartman
` (66 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lee Duncan, Nilesh Javali,
Martin K. Petersen, Sasha Levin
From: Nilesh Javali <njavali@marvell.com>
[ Upstream commit d50c7986fbf0e2167279e110a2ed5bd8e811c660 ]
The CHAP secret displayed garbage characters causing iSCSI login
authentication failure. Correct the CHAP password max length.
Link: https://lore.kernel.org/r/20201217105144.8055-1-njavali@marvell.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/qedi/qedi_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
index 35c96ea2653be..fdd966fea7f6a 100644
--- a/drivers/scsi/qedi/qedi_main.c
+++ b/drivers/scsi/qedi/qedi_main.c
@@ -2175,7 +2175,7 @@ qedi_show_boot_tgt_info(struct qedi_ctx *qedi, int type,
chap_name);
break;
case ISCSI_BOOT_TGT_CHAP_SECRET:
- rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_NAME_MAX_LEN,
+ rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_PWD_MAX_LEN,
chap_secret);
break;
case ISCSI_BOOT_TGT_REV_CHAP_NAME:
@@ -2183,7 +2183,7 @@ qedi_show_boot_tgt_info(struct qedi_ctx *qedi, int type,
mchap_name);
break;
case ISCSI_BOOT_TGT_REV_CHAP_SECRET:
- rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_NAME_MAX_LEN,
+ rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_PWD_MAX_LEN,
mchap_secret);
break;
case ISCSI_BOOT_TGT_FLAGS:
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 23/86] scsi: sd: Suppress spurious errors when WRITE SAME is being disabled
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 22/86] scsi: qedi: Correct max length of CHAP secret Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 24/86] riscv: Fix kernel time_init() Greg Kroah-Hartman
` (65 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, Ewan D. Milne,
Martin K. Petersen, Sasha Levin
From: Ewan D. Milne <emilne@redhat.com>
[ Upstream commit e5cc9002caafacbaa8dab878d17a313192c3b03b ]
The block layer code will split a large zeroout request into multiple bios
and if WRITE SAME is disabled because the storage device reports that it
does not support it (or support the length used), we can get an error
message from the block layer despite the setting of RQF_QUIET on the first
request. This is because more than one request may have already been
submitted.
Fix this by setting RQF_QUIET when BLK_STS_TARGET is returned to fail the
request early, we don't need to log a message because we did not actually
submit the command to the device, and the block layer code will handle the
error by submitting individual write bios.
Link: https://lore.kernel.org/r/20201207221021.28243-1-emilne@redhat.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/sd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6a2f8bacfacea..f55249766d224 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -934,8 +934,10 @@ static blk_status_t sd_setup_write_zeroes_cmnd(struct scsi_cmnd *cmd)
}
}
- if (sdp->no_write_same)
+ if (sdp->no_write_same) {
+ rq->rq_flags |= RQF_QUIET;
return BLK_STS_TARGET;
+ }
if (sdkp->ws16 || lba > 0xffffffff || nr_blocks > 0xffff)
return sd_setup_write_same16_cmnd(cmd, false);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 24/86] riscv: Fix kernel time_init()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 23/86] scsi: sd: Suppress spurious errors when WRITE SAME is being disabled Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 25/86] riscv: Fix sifive serial driver Greg Kroah-Hartman
` (64 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Damien Le Moal, Stephen Boyd,
Palmer Dabbelt, Sasha Levin
From: Damien Le Moal <damien.lemoal@wdc.com>
[ Upstream commit 11f4c2e940e2f317c9d8fb5a79702f2a4a02ff98 ]
If of_clk_init() is not called in time_init(), clock providers defined
in the system device tree are not initialized, resulting in failures for
other devices to initialize due to missing clocks.
Similarly to other architectures and to the default kernel time_init()
implementation, call of_clk_init() before executing timer_probe() in
time_init().
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/riscv/kernel/time.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/time.c b/arch/riscv/kernel/time.c
index 6a53c02e9c734..8aa70b519e04f 100644
--- a/arch/riscv/kernel/time.c
+++ b/arch/riscv/kernel/time.c
@@ -4,6 +4,7 @@
* Copyright (C) 2017 SiFive
*/
+#include <linux/of_clk.h>
#include <linux/clocksource.h>
#include <linux/delay.h>
#include <asm/sbi.h>
@@ -24,5 +25,7 @@ void __init time_init(void)
riscv_timebase = prop;
lpj_fine = riscv_timebase / HZ;
+
+ of_clk_init(NULL);
timer_probe();
}
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 25/86] riscv: Fix sifive serial driver
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 24/86] riscv: Fix kernel time_init() Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 26/86] HID: logitech-dj: add the G602 receiver Greg Kroah-Hartman
` (63 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Damien Le Moal, Palmer Dabbelt, Sasha Levin
From: Damien Le Moal <damien.lemoal@wdc.com>
[ Upstream commit 1f1496a923b6ba16679074fe77100e1b53cdb880 ]
Setup the port uartclk in sifive_serial_probe() so that the base baud
rate is correctly printed during device probe instead of always showing
"0". I.e. the probe message is changed from
38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1,
base_baud = 0) is a SiFive UART v0
to the correct:
38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1,
base_baud = 115200) is a SiFive UART v0
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/sifive.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/sifive.c b/drivers/tty/serial/sifive.c
index b4343c6aa6512..6a2dc823ea828 100644
--- a/drivers/tty/serial/sifive.c
+++ b/drivers/tty/serial/sifive.c
@@ -973,6 +973,7 @@ static int sifive_serial_probe(struct platform_device *pdev)
/* Set up clock divider */
ssp->clkin_rate = clk_get_rate(ssp->clk);
ssp->baud_rate = SIFIVE_DEFAULT_BAUD_RATE;
+ ssp->port.uartclk = ssp->baud_rate * 16;
__ssp_update_div(ssp);
platform_set_drvdata(pdev, ssp);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 26/86] HID: logitech-dj: add the G602 receiver
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 25/86] riscv: Fix sifive serial driver Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 27/86] HID: Ignore battery for Elan touchscreen on ASUS UX550 Greg Kroah-Hartman
` (62 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Filipe Laíns, Jiri Kosina, Sasha Levin
From: Filipe Laíns <lains@archlinux.org>
[ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
Tested. The device gets correctly exported to userspace and I can see
mouse and keyboard events.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-dj.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 54d811fdcdb44..e5550a5bf49d0 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1862,6 +1862,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
0xc531),
.driver_data = recvr_type_gaming_hidpp},
+ { /* Logitech G602 receiver (0xc537) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ 0xc537),
+ .driver_data = recvr_type_gaming_hidpp},
{ /* Logitech lightspeed receiver (0xc539) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 27/86] HID: Ignore battery for Elan touchscreen on ASUS UX550
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 26/86] HID: logitech-dj: add the G602 receiver Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 28/86] clk: tegra30: Add hda clock default rates to clock driver Greg Kroah-Hartman
` (61 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Seth Miller, Jiri Kosina, Sasha Levin
From: Seth Miller <miller.seth@gmail.com>
[ Upstream commit 7c38e769d5c508939ce5dc26df72602f3c902342 ]
Battery status is being reported for the Elan touchscreen on ASUS
UX550 laptops despite not having a batter. It always shows either 0 or
1%.
Signed-off-by: Seth Miller <miller.seth@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2aa810665a78c..33183933337af 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -393,6 +393,7 @@
#define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401
#define USB_DEVICE_ID_HP_X2 0x074d
#define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
+#define USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN 0x2706
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index b2da8476d0d30..ec08895e7b1dc 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -322,6 +322,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_DINOVO_EDGE_KBD),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 28/86] clk: tegra30: Add hda clock default rates to clock driver
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 27/86] HID: Ignore battery for Elan touchscreen on ASUS UX550 Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 29/86] arm64: make atomic helpers __always_inline Greg Kroah-Hartman
` (60 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jon Hunter, Ion Agorria,
Sameer Pujar, Thierry Reding, Peter Geis, Takashi Iwai,
Sasha Levin
From: Peter Geis <pgwipeout@gmail.com>
[ Upstream commit f4eccc7fea203cfb35205891eced1ab51836f362 ]
Current implementation defaults the hda clocks to clk_m. This causes hda
to run too slow to operate correctly. Fix this by defaulting to pll_p and
setting the frequency to the correct rate.
This matches upstream t124 and downstream t30.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Ion Agorria <ion@agorria.com>
Acked-by: Sameer Pujar <spujar@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Link: https://lore.kernel.org/r/20210108135913.2421585-2-pgwipeout@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/clk/tegra/clk-tegra30.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 7b4c6a488527d..501929d9f70ed 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1263,6 +1263,8 @@ static struct tegra_clk_init_table init_table[] __initdata = {
{ TEGRA30_CLK_I2S3_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
{ TEGRA30_CLK_I2S4_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
{ TEGRA30_CLK_VIMCLK_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
+ { TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 102000000, 0 },
+ { TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 48000000, 0 },
/* must be the last entry */
{ TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
};
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 29/86] arm64: make atomic helpers __always_inline
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 28/86] clk: tegra30: Add hda clock default rates to clock driver Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 30/86] xen: Fix event channel callback via INTX/GSI Greg Kroah-Hartman
` (59 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Will Deacon,
Catalin Marinas, Sasha Levin
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit c35a824c31834d947fb99b0c608c1b9f922b4ba0 ]
With UBSAN enabled and building with clang, there are occasionally
warnings like
WARNING: modpost: vmlinux.o(.text+0xc533ec): Section mismatch in reference from the function arch_atomic64_or() to the variable .init.data:numa_nodes_parsed
The function arch_atomic64_or() references
the variable __initdata numa_nodes_parsed.
This is often because arch_atomic64_or lacks a __initdata
annotation or the annotation of numa_nodes_parsed is wrong.
for functions that end up not being inlined as intended but operating
on __initdata variables. Mark these as __always_inline, along with
the corresponding asm-generic wrappers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210108092024.4034860-1-arnd@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/include/asm/atomic.h | 10 +++++-----
include/asm-generic/bitops/atomic.h | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/atomic.h b/arch/arm64/include/asm/atomic.h
index 9543b5e0534d2..6e0f48ddfc656 100644
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@ -17,7 +17,7 @@
#include <asm/lse.h>
#define ATOMIC_OP(op) \
-static inline void arch_##op(int i, atomic_t *v) \
+static __always_inline void arch_##op(int i, atomic_t *v) \
{ \
__lse_ll_sc_body(op, i, v); \
}
@@ -32,7 +32,7 @@ ATOMIC_OP(atomic_sub)
#undef ATOMIC_OP
#define ATOMIC_FETCH_OP(name, op) \
-static inline int arch_##op##name(int i, atomic_t *v) \
+static __always_inline int arch_##op##name(int i, atomic_t *v) \
{ \
return __lse_ll_sc_body(op##name, i, v); \
}
@@ -56,7 +56,7 @@ ATOMIC_FETCH_OPS(atomic_sub_return)
#undef ATOMIC_FETCH_OPS
#define ATOMIC64_OP(op) \
-static inline void arch_##op(long i, atomic64_t *v) \
+static __always_inline void arch_##op(long i, atomic64_t *v) \
{ \
__lse_ll_sc_body(op, i, v); \
}
@@ -71,7 +71,7 @@ ATOMIC64_OP(atomic64_sub)
#undef ATOMIC64_OP
#define ATOMIC64_FETCH_OP(name, op) \
-static inline long arch_##op##name(long i, atomic64_t *v) \
+static __always_inline long arch_##op##name(long i, atomic64_t *v) \
{ \
return __lse_ll_sc_body(op##name, i, v); \
}
@@ -94,7 +94,7 @@ ATOMIC64_FETCH_OPS(atomic64_sub_return)
#undef ATOMIC64_FETCH_OP
#undef ATOMIC64_FETCH_OPS
-static inline long arch_atomic64_dec_if_positive(atomic64_t *v)
+static __always_inline long arch_atomic64_dec_if_positive(atomic64_t *v)
{
return __lse_ll_sc_body(atomic64_dec_if_positive, v);
}
diff --git a/include/asm-generic/bitops/atomic.h b/include/asm-generic/bitops/atomic.h
index dd90c9792909d..0e7316a86240b 100644
--- a/include/asm-generic/bitops/atomic.h
+++ b/include/asm-generic/bitops/atomic.h
@@ -11,19 +11,19 @@
* See Documentation/atomic_bitops.txt for details.
*/
-static inline void set_bit(unsigned int nr, volatile unsigned long *p)
+static __always_inline void set_bit(unsigned int nr, volatile unsigned long *p)
{
p += BIT_WORD(nr);
atomic_long_or(BIT_MASK(nr), (atomic_long_t *)p);
}
-static inline void clear_bit(unsigned int nr, volatile unsigned long *p)
+static __always_inline void clear_bit(unsigned int nr, volatile unsigned long *p)
{
p += BIT_WORD(nr);
atomic_long_andnot(BIT_MASK(nr), (atomic_long_t *)p);
}
-static inline void change_bit(unsigned int nr, volatile unsigned long *p)
+static __always_inline void change_bit(unsigned int nr, volatile unsigned long *p)
{
p += BIT_WORD(nr);
atomic_long_xor(BIT_MASK(nr), (atomic_long_t *)p);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 30/86] xen: Fix event channel callback via INTX/GSI
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 29/86] arm64: make atomic helpers __always_inline Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 31/86] x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery Greg Kroah-Hartman
` (58 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Woodhouse, Boris Ostrovsky,
Juergen Gross, Sasha Levin
From: David Woodhouse <dwmw@amazon.co.uk>
[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ]
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions below 4.0 because we avoid
calling xs_reset_watches() anyway, because xenstore might not cope with
reading a non-existent key. And newer Xen *does* have the vector
callback support, so we rarely fall back to INTX/GSI delivery.
To fix it, clean up a bit of the mess of xs_init() and xenbus_probe()
startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM
case, deferring it to be called from xenbus_probe() in the XS_HVM case
instead.
Then fix up the invocation of xenbus_probe() to happen either from its
device_initcall if the callback is available early enough, or when the
callback is finally set up. This means that the hack of calling
xenbus_probe() from a workqueue after the first interrupt, or directly
from the PCI platform device setup, is no longer needed.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210113132606.422794-2-dwmw2@infradead.org
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/xen/enlighten.c | 2 +-
drivers/xen/events/events_base.c | 10 ----
drivers/xen/platform-pci.c | 1 -
drivers/xen/xenbus/xenbus.h | 1 +
drivers/xen/xenbus/xenbus_comms.c | 8 ---
drivers/xen/xenbus/xenbus_probe.c | 81 +++++++++++++++++++++++++------
include/xen/xenbus.h | 2 +-
7 files changed, 70 insertions(+), 35 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index dd6804a64f1a0..f45bff158fc20 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -371,7 +371,7 @@ static int __init xen_guest_init(void)
}
gnttab_init();
if (!xen_initial_domain())
- xenbus_probe(NULL);
+ xenbus_probe();
/*
* Making sure board specific code will not set up ops for
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 26df84c45db4e..7b94a6c316643 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1988,16 +1988,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
.irq_ack = ack_dynirq,
};
-int xen_set_callback_via(uint64_t via)
-{
- struct xen_hvm_param a;
- a.domid = DOMID_SELF;
- a.index = HVM_PARAM_CALLBACK_IRQ;
- a.value = via;
- return HYPERVISOR_hvm_op(HVMOP_set_param, &a);
-}
-EXPORT_SYMBOL_GPL(xen_set_callback_via);
-
#ifdef CONFIG_XEN_PVHVM
/* Vector callbacks are better than PCI interrupts to receive event
* channel notifications because we can receive vector callbacks on any
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 5e30602fdbad8..c45646450135f 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -149,7 +149,6 @@ static int platform_pci_probe(struct pci_dev *pdev,
ret = gnttab_init();
if (ret)
goto grant_out;
- xenbus_probe(NULL);
return 0;
grant_out:
gnttab_free_auto_xlat_frames();
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 88516a8a9f932..a9bb5f91082d3 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -115,6 +115,7 @@ int xenbus_probe_node(struct xen_bus_type *bus,
const char *type,
const char *nodename);
int xenbus_probe_devices(struct xen_bus_type *bus);
+void xenbus_probe(void);
void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index eb5151fc8efab..e5fda0256feb3 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -57,16 +57,8 @@ DEFINE_MUTEX(xs_response_mutex);
static int xenbus_irq;
static struct task_struct *xenbus_task;
-static DECLARE_WORK(probe_work, xenbus_probe);
-
-
static irqreturn_t wake_waiting(int irq, void *unused)
{
- if (unlikely(xenstored_ready == 0)) {
- xenstored_ready = 1;
- schedule_work(&probe_work);
- }
-
wake_up(&xb_waitq);
return IRQ_HANDLED;
}
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index e6d0903459e11..14ccf13ab8fa1 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -683,29 +683,76 @@ void unregister_xenstore_notifier(struct notifier_block *nb)
}
EXPORT_SYMBOL_GPL(unregister_xenstore_notifier);
-void xenbus_probe(struct work_struct *unused)
+void xenbus_probe(void)
{
xenstored_ready = 1;
+ /*
+ * In the HVM case, xenbus_init() deferred its call to
+ * xs_init() in case callbacks were not operational yet.
+ * So do it now.
+ */
+ if (xen_store_domain_type == XS_HVM)
+ xs_init();
+
/* Notify others that xenstore is up */
blocking_notifier_call_chain(&xenstore_chain, 0, NULL);
}
-EXPORT_SYMBOL_GPL(xenbus_probe);
-static int __init xenbus_probe_initcall(void)
+/*
+ * Returns true when XenStore init must be deferred in order to
+ * allow the PCI platform device to be initialised, before we
+ * can actually have event channel interrupts working.
+ */
+static bool xs_hvm_defer_init_for_callback(void)
{
- if (!xen_domain())
- return -ENODEV;
+#ifdef CONFIG_XEN_PVHVM
+ return xen_store_domain_type == XS_HVM &&
+ !xen_have_vector_callback;
+#else
+ return false;
+#endif
+}
- if (xen_initial_domain() || xen_hvm_domain())
- return 0;
+static int __init xenbus_probe_initcall(void)
+{
+ /*
+ * Probe XenBus here in the XS_PV case, and also XS_HVM unless we
+ * need to wait for the platform PCI device to come up.
+ */
+ if (xen_store_domain_type == XS_PV ||
+ (xen_store_domain_type == XS_HVM &&
+ !xs_hvm_defer_init_for_callback()))
+ xenbus_probe();
- xenbus_probe(NULL);
return 0;
}
-
device_initcall(xenbus_probe_initcall);
+int xen_set_callback_via(uint64_t via)
+{
+ struct xen_hvm_param a;
+ int ret;
+
+ a.domid = DOMID_SELF;
+ a.index = HVM_PARAM_CALLBACK_IRQ;
+ a.value = via;
+
+ ret = HYPERVISOR_hvm_op(HVMOP_set_param, &a);
+ if (ret)
+ return ret;
+
+ /*
+ * If xenbus_probe_initcall() deferred the xenbus_probe()
+ * due to the callback not functioning yet, we can do it now.
+ */
+ if (!xenstored_ready && xs_hvm_defer_init_for_callback())
+ xenbus_probe();
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(xen_set_callback_via);
+
/* Set up event channel for xenstored which is run as a local process
* (this is normally used only in dom0)
*/
@@ -818,11 +865,17 @@ static int __init xenbus_init(void)
break;
}
- /* Initialize the interface to xenstore. */
- err = xs_init();
- if (err) {
- pr_warn("Error initializing xenstore comms: %i\n", err);
- goto out_error;
+ /*
+ * HVM domains may not have a functional callback yet. In that
+ * case let xs_init() be called from xenbus_probe(), which will
+ * get invoked at an appropriate time.
+ */
+ if (xen_store_domain_type != XS_HVM) {
+ err = xs_init();
+ if (err) {
+ pr_warn("Error initializing xenstore comms: %i\n", err);
+ goto out_error;
+ }
}
if ((xen_store_domain_type != XS_LOCAL) &&
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index eba01ab5a55e0..fe9a9fa2ebc45 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -187,7 +187,7 @@ void xs_suspend_cancel(void);
struct work_struct;
-void xenbus_probe(struct work_struct *);
+void xenbus_probe(void);
#define XENBUS_IS_ERR_READ(str) ({ \
if (!IS_ERR(str) && strlen(str) == 0) { \
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 31/86] x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 30/86] xen: Fix event channel callback via INTX/GSI Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 32/86] dts: phy: fix missing mdio device and probe failure of vsc8541-01 device Greg Kroah-Hartman
` (57 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Woodhouse, Boris Ostrovsky,
Juergen Gross, Sasha Levin
From: David Woodhouse <dwmw@amazon.co.uk>
[ Upstream commit b36b0fe96af13460278bf9b173beced1bd15f85d ]
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in active use which use PCI INTX
even when vector delivery is available.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210106153958.584169-4-dwmw2@infradead.org
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
arch/x86/xen/enlighten_hvm.c | 11 ++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 74ba077e99e56..a19ae163c0589 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5452,6 +5452,10 @@
This option is obsoleted by the "nopv" option, which
has equivalent effect for XEN platform.
+ xen_no_vector_callback
+ [KNL,X86,XEN] Disable the vector callback for Xen
+ event channel interrupts.
+
xen_scrub_pages= [XEN]
Boolean option to control scrubbing pages before giving them back
to Xen, for use by other domains. Can be also changed at runtime
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index e138f7de52d20..6024fafed1642 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -175,6 +175,8 @@ static int xen_cpu_dead_hvm(unsigned int cpu)
return 0;
}
+static bool no_vector_callback __initdata;
+
static void __init xen_hvm_guest_init(void)
{
if (xen_pv_domain())
@@ -194,7 +196,7 @@ static void __init xen_hvm_guest_init(void)
xen_panic_handler_init();
- if (xen_feature(XENFEAT_hvm_callback_vector))
+ if (!no_vector_callback && xen_feature(XENFEAT_hvm_callback_vector))
xen_have_vector_callback = 1;
xen_hvm_smp_init();
@@ -220,6 +222,13 @@ static __init int xen_parse_nopv(char *arg)
}
early_param("xen_nopv", xen_parse_nopv);
+static __init int xen_parse_no_vector_callback(char *arg)
+{
+ no_vector_callback = true;
+ return 0;
+}
+early_param("xen_no_vector_callback", xen_parse_no_vector_callback);
+
bool __init xen_hvm_need_lapic(void)
{
if (xen_pv_domain())
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 32/86] dts: phy: fix missing mdio device and probe failure of vsc8541-01 device
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 31/86] x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 33/86] dts: phy: add GPIO number and active state used for phy reset Greg Kroah-Hartman
` (56 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sagar Shrikant Kadam, Palmer Dabbelt,
Sasha Levin
From: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
[ Upstream commit be969b7cfbcfa8a835a528f1dc467f0975c6d883 ]
HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is
identified as a Revision B device as described in device identification
registers. In order to use this phy in the unmanaged mode, it requires
a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin
as documented here [1].
Currently, the bootloader (fsbl or u-boot-spl) takes care of the phy reset.
If due to some reason the phy device hasn't received the reset by the prior
stages before the linux macb driver comes into the picture, the MACB mii
bus gets probed but the mdio scan fails and is not even able to read the
phy ID registers. It gives an error message:
"libphy: MACB_mii_bus: probed
mdio_bus 10090000.ethernet-ffffffff: MDIO device at address 0 is missing."
Thus adding the device OUI (Organizationally Unique Identifier) to the phy
device node helps to probe the phy device.
[1]: VSC8541-01 datasheet:
https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf
Signed-off-by: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index 88cfcb96bf233..cc04e66752aac 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -83,6 +83,7 @@
phy-mode = "gmii";
phy-handle = <&phy0>;
phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id0007.0771";
reg = <0>;
};
};
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 33/86] dts: phy: add GPIO number and active state used for phy reset
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 32/86] dts: phy: fix missing mdio device and probe failure of vsc8541-01 device Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 34/86] riscv: defconfig: enable gpio support for HiFive Unleashed Greg Kroah-Hartman
` (55 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sagar Shrikant Kadam, Palmer Dabbelt,
Sasha Levin
From: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
[ Upstream commit a0fa9d727043da2238432471e85de0bdb8a8df65 ]
The GEMGXL_RST line on HiFive Unleashed is pulled low and is
using GPIO number 12. Add these reset-gpio details to dt-node
using which the linux phylib can reset the phy.
Signed-off-by: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index cc04e66752aac..1ad3dc2fb6343 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -85,6 +85,7 @@
phy0: ethernet-phy@0 {
compatible = "ethernet-phy-id0007.0771";
reg = <0>;
+ reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
};
};
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 34/86] riscv: defconfig: enable gpio support for HiFive Unleashed
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 33/86] dts: phy: add GPIO number and active state used for phy reset Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 35/86] drm/amdgpu/psp: fix psp gfx ctrl cmds Greg Kroah-Hartman
` (54 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sagar Shrikant Kadam, Palmer Dabbelt,
Sasha Levin
From: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
[ Upstream commit 0983834a83931606a647c275e5d4165ce4e7b49f ]
Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line
connected to a gpio, so enable GPIO driver's required to reset
the phy.
Signed-off-by: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/riscv/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 420a0dbef3866..3c656fe97e583 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -62,6 +62,8 @@ CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_SPI=y
CONFIG_SPI_SIFIVE=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SIFIVE=y
# CONFIG_PTP_1588_CLOCK is not set
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 35/86] drm/amdgpu/psp: fix psp gfx ctrl cmds
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 34/86] riscv: defconfig: enable gpio support for HiFive Unleashed Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 36/86] drm/amd/display: Fix to be able to stop crc calculation Greg Kroah-Hartman
` (53 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Victor Zhao, Emily.Deng,
Alex Deucher, Sasha Levin
From: Victor Zhao <Victor.Zhao@amd.com>
[ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ]
psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux,
according to psp, linux cmds are not correct.
v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD.
Signed-off-by: Victor Zhao <Victor.Zhao@amd.com>
Reviewed-by: Emily.Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h
index 74a9fe8e0cfb9..8c54f0be51bab 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h
+++ b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h
@@ -44,7 +44,7 @@ enum psp_gfx_crtl_cmd_id
GFX_CTRL_CMD_ID_DISABLE_INT = 0x00060000, /* disable PSP-to-Gfx interrupt */
GFX_CTRL_CMD_ID_MODE1_RST = 0x00070000, /* trigger the Mode 1 reset */
GFX_CTRL_CMD_ID_GBR_IH_SET = 0x00080000, /* set Gbr IH_RB_CNTL registers */
- GFX_CTRL_CMD_ID_CONSUME_CMD = 0x000A0000, /* send interrupt to psp for updating write pointer of vf */
+ GFX_CTRL_CMD_ID_CONSUME_CMD = 0x00090000, /* send interrupt to psp for updating write pointer of vf */
GFX_CTRL_CMD_ID_DESTROY_GPCOM_RING = 0x000C0000, /* destroy GPCOM ring */
GFX_CTRL_CMD_ID_MAX = 0x000F0000, /* max command ID */
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 36/86] drm/amd/display: Fix to be able to stop crc calculation
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 35/86] drm/amdgpu/psp: fix psp gfx ctrl cmds Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 37/86] drm/nouveau/bios: fix issue shadowing expansion ROMs Greg Kroah-Hartman
` (52 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wayne Lin, Nicholas Kazlauskas,
Qingqing Zhuo, Alex Deucher, Sasha Levin
From: Wayne Lin <Wayne.Lin@amd.com>
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]
[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Also, clean up crc window when disable crc calculation.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index a549c7c717ddc..f0b001b3af578 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -113,7 +113,7 @@ int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc *crtc,
mutex_lock(&adev->dm.dc_lock);
/* Enable CRTC CRC generation if necessary. */
- if (dm_is_crc_source_crtc(source)) {
+ if (dm_is_crc_source_crtc(source) || source == AMDGPU_DM_PIPE_CRC_SOURCE_NONE) {
if (!dc_stream_configure_crc(stream_state->ctx->dc,
stream_state, enable, enable)) {
ret = -EINVAL;
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 37/86] drm/nouveau/bios: fix issue shadowing expansion ROMs
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 36/86] drm/amd/display: Fix to be able to stop crc calculation Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 38/86] drm/nouveau/privring: ack interrupts the same way as RM Greg Kroah-Hartman
` (51 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs, Sasha Levin
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes
[ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes
[ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes
[ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes
[ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset, struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 38/86] drm/nouveau/privring: ack interrupts the same way as RM
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 37/86] drm/nouveau/bios: fix issue shadowing expansion ROMs Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 39/86] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields Greg Kroah-Hartman
` (50 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs, Sasha Levin
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++++++---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++++++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c
index d80dbc8f09b20..55a4ea4393c62 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "priv.h"
+#include <subdev/timer.h>
static void
gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i)
@@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400));
u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400));
nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x122128 + (i * 0x0400), 0x00000200, 0x00000000);
}
static void
@@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400));
u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400));
nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x124128 + (i * 0x0400), 0x00000200, 0x00000000);
}
static void
@@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400));
u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400));
nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x128128 + (i * 0x0400), 0x00000200, 0x00000000);
}
void
@@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus)
intr1 &= ~stat;
}
}
+
+ nvkm_mask(device, 0x121c4c, 0x0000003f, 0x00000002);
+ nvkm_msec(device, 2000,
+ if (!(nvkm_rd32(device, 0x121c4c) & 0x0000003f))
+ break;
+ );
}
static int
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c
index 9025ed1bd2a99..4caf3ef087e1d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "priv.h"
+#include <subdev/timer.h>
static void
gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i)
@@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800));
u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800));
nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x122128 + (i * 0x0800), 0x00000200, 0x00000000);
}
static void
@@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800));
u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800));
nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x124128 + (i * 0x0800), 0x00000200, 0x00000000);
}
static void
@@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i)
u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800));
u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800));
nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat);
- nvkm_mask(device, 0x128128 + (i * 0x0800), 0x00000200, 0x00000000);
}
void
@@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus)
intr1 &= ~stat;
}
}
+
+ nvkm_mask(device, 0x12004c, 0x0000003f, 0x00000002);
+ nvkm_msec(device, 2000,
+ if (!(nvkm_rd32(device, 0x12004c) & 0x0000003f))
+ break;
+ );
}
static int
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 39/86] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 38/86] drm/nouveau/privring: ack interrupts the same way as RM Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 40/86] drm/nouveau/mmu: fix vram heap sizing Greg Kroah-Hartman
` (49 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs, Sasha Levin
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x00310000, 0x00000000);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x00710000, 0x00000000);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x03010000);
+ } while (ctrl & 0x07010000);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x00300000, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x00700000, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x03000000) != urep);
+ } while ((ctrl & 0x07000000) != urep);
return 0;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 40/86] drm/nouveau/mmu: fix vram heap sizing
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 39/86] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 41/86] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 Greg Kroah-Hartman
` (48 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs, Sasha Levin
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index ee11ccaf0563c..cb51e248cb41b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 41/86] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 40/86] drm/nouveau/mmu: fix vram heap sizing Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 42/86] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S Greg Kroah-Hartman
` (47 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs, Sasha Levin
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ee2b1e1199e09..daa79d39201f9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -132,7 +132,7 @@ nv50_dmac_destroy(struct nv50_dmac *dmac)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
- const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+ const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -167,7 +167,7 @@ nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_init(&dmac->base.user, 0xf0000000, NV_DMA_IN_MEMORY,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 7c41b0599d1ac..284068fa6d007 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -70,7 +70,7 @@ struct nv50_dmac {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
- u64 syncbuf, struct nv50_dmac *dmac);
+ s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
u32 *evo_wait(struct nv50_dmac *, int nr);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index f7dbd965e4e72..b49a212af4d8d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -68,7 +68,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 42/86] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 41/86] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 43/86] pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting Greg Kroah-Hartman
` (46 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Youling Tang, Michael Ellerman, Sasha Levin
From: Youling Tang <tangyouling@loongson.cn>
[ Upstream commit fdcfeaba38e5b183045f5b079af94f97658eabe6 ]
Use the common INIT_DATA_SECTION rule for the linker script in an effort
to regularize the linker script.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1604487550-20040-1-git-send-email-tangyouling@loongson.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 4def51c12e1bf..f9081724d6910 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -223,21 +223,7 @@ SECTIONS
EXIT_TEXT
}
- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
- INIT_DATA
- }
-
- .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
- INIT_SETUP(16)
- }
-
- .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- INIT_CALLS
- }
-
- .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
- CON_INITCALL
- }
+ INIT_DATA_SECTION(16)
. = ALIGN(8);
__ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
@@ -265,9 +251,6 @@ SECTIONS
__stop___fw_ftr_fixup = .;
}
#endif
- .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
- INIT_RAM_FS
- }
PERCPU_SECTION(L1_CACHE_BYTES)
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 43/86] pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 42/86] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 44/86] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression Greg Kroah-Hartman
` (45 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Billy Tsai, Joel Stanley,
Andrew Jeffery, Linus Walleij, Sasha Levin
From: Billy Tsai <billy_tsai@aspeedtech.com>
[ Upstream commit 92ff62a7bcc17d47c0ce8dddfb7a6e1a2e55ebf4 ]
The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from
SCU414 to SCU4B4.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index bb07024d22edc..0a745769e7127 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -334,7 +334,7 @@ FUNC_GROUP_DECL(RMII4, F24, E23, E24, E25, C25, C24, B26, B25, B24);
#define D22 40
SIG_EXPR_LIST_DECL_SESG(D22, SD1CLK, SD1, SIG_DESC_SET(SCU414, 8));
-SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU414, 8));
+SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU4B4, 8));
PIN_DECL_2(D22, GPIOF0, SD1CLK, PWM8);
GROUP_DECL(PWM8G0, D22);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 44/86] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 43/86] pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 45/86] powerpc: Fix alignment bug within the init sections Greg Kroah-Hartman
` (44 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Phil Oester, Arnd Bergmann,
Martin K. Petersen, Sasha Levin
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit b112036535eda34460677ea883eaecc3a45a435d ]
Phil Oester reported that a fix for a possible buffer overrun that I sent
caused a regression that manifests in this output:
Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0.
Severity: Critical
Message ID: PCI1308
The original code tried to handle the sense data pointer differently when
using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t
value of 0x11223344 to get stored
32-bit kernel: 44 33 22 11 ?? ?? ?? ??
64-bit LE kernel: 44 33 22 11 00 00 00 00
64-bit BE kernel: 00 00 00 00 44 33 22 11
or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as
32-bit kernel: 88 77 66 55 ?? ?? ?? ??
64-bit kernel: 88 77 66 55 44 33 22 11
In my patch, I tried to ensure that the same value is used on both 32-bit
and 64-bit kernels, and picked what seemed to be the most sensible
combination, storing 32-bit addresses in the first four bytes (as 32-bit
kernels already did), and 64-bit addresses in eight consecutive bytes (as
64-bit kernels already did), but evidently this was incorrect.
Always storing the dma_addr_t pointer as 64-bit little-endian,
i.e. initializing the second four bytes to zero in case of 32-bit
addressing, apparently solved the problem for Phil, and is consistent with
what all 64-bit little-endian machines did before.
I also checked in the history that in previous versions of the code, the
pointer was always in the first four bytes without padding, and that
previous attempts to fix 64-bit user space, big-endian architectures and
64-bit DMA were clearly flawed and seem to have introduced made this worse.
Link: https://lore.kernel.org/r/20210104234137.438275-1-arnd@kernel.org
Fixes: 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets")
Fixes: 107a60dd71b5 ("scsi: megaraid_sas: Add support for 64bit consistent DMA")
Fixes: 94cd65ddf4d7 ("[SCSI] megaraid_sas: addded support for big endian architecture")
Fixes: 7b2519afa1ab ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation")
Reported-by: Phil Oester <kernel@linuxace.com>
Tested-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 4a23dd8b7f9aa..b9c1f722f1ded 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -8174,11 +8174,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
goto out;
}
+ /* always store 64 bits regardless of addressing */
sense_ptr = (void *)cmd->frame + ioc->sense_off;
- if (instance->consistent_mask_64bit)
- put_unaligned_le64(sense_handle, sense_ptr);
- else
- put_unaligned_le32(sense_handle, sense_ptr);
+ put_unaligned_le64(sense_handle, sense_ptr);
}
/*
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 45/86] powerpc: Fix alignment bug within the init sections
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 44/86] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 46/86] i2c: octeon: check correct size of maximum RECV_LEN packet Greg Kroah-Hartman
` (43 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ariel Marcovitch, Christophe Leroy,
Michael Ellerman, Sasha Levin
From: Ariel Marcovitch <arielmarcovitch@gmail.com>
[ Upstream commit 2225a8dda263edc35a0e8b858fe2945cf6240fde ]
This is a bug that causes early crashes in builds with an .exit.text
section smaller than a page and an .init.text section that ends in the
beginning of a physical page (this is kinda random, which might
explain why this wasn't really encountered before).
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code might become read-only at runtime and because
the .init.text section can potentially reside on the same physical
page as .init.data, the beginning of .init.data might be mapped
read-only along with .init.text.
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, make _einittext page aligned and also align .exit.text
to make sure .init.data is always seperated from the text segments.
Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
Signed-off-by: Ariel Marcovitch <ariel.marcovitch@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210102201156.10805-1-ariel.marcovitch@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index f9081724d6910..a4e576019d79c 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -210,6 +210,12 @@ SECTIONS
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
+
+ /*
+ *.init.text might be RO so we must ensure this section ends on
+ * a page boundary.
+ */
+ . = ALIGN(PAGE_SIZE);
_einittext = .;
#ifdef CONFIG_PPC64
*(.tramp.ftrace.init);
@@ -223,6 +229,8 @@ SECTIONS
EXIT_TEXT
}
+ . = ALIGN(PAGE_SIZE);
+
INIT_DATA_SECTION(16)
. = ALIGN(8);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 46/86] i2c: octeon: check correct size of maximum RECV_LEN packet
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 45/86] powerpc: Fix alignment bug within the init sections Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 47/86] platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list Greg Kroah-Hartman
` (42 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wolfram Sang, Robert Richter,
Wolfram Sang, Sasha Levin
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
[ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ]
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. No reason to add one to it.
Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Robert Richter <rric@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-octeon-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-octeon-core.c b/drivers/i2c/busses/i2c-octeon-core.c
index d9607905dc2f1..845eda70b8cab 100644
--- a/drivers/i2c/busses/i2c-octeon-core.c
+++ b/drivers/i2c/busses/i2c-octeon-core.c
@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int target,
if (result)
return result;
if (recv_len && i == 0) {
- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1)
+ if (data[i] > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
length += data[i];
}
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 47/86] platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 46/86] i2c: octeon: check correct size of maximum RECV_LEN packet Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 48/86] selftests: net: fib_tests: remove duplicate log test Greg Kroah-Hartman
` (41 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Sasha Levin
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 070222731be52d741e55d8967b1764482b81e54c ]
THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function:
Method (VGBS, 0, Serialized)
{
If ((^^PCI0.LPCB.EC0.ROLS == Zero))
{
VBDS = Zero
}
Else
{
VBDS = Zero
}
Return (VBDS) /* \_SB_.VGBI.VBDS */
}
Which is obviously wrong, because it always returns 0 independent of the
2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver
to initially report SW_TABLET_MODE = 1 to userspace, which is known to
cause problems when the 2-in-1 is actually in laptop mode.
During earlier testing this turned out to not be a problem because the
2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after
the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state.
Further testing however has shown that this Notify() soon after the
intel-vbtn driver loads, does not always happen. When the Notify
does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in
a non-working touchpad.
IOW the tablet-mode reporting is not reliable on this device, so it
should be dropped from the allow-list, fixing the touchpad sometimes
not working.
Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/intel-vbtn.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c
index bc8b0098d4f32..37035dca469cf 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -191,12 +191,6 @@ static const struct dmi_system_id dmi_switches_allow_list[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
},
},
- {
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Stream x360 Convertible PC 11"),
- },
- },
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 48/86] selftests: net: fib_tests: remove duplicate log test
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 47/86] platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 49/86] can: dev: can_restart: fix use after free bug Greg Kroah-Hartman
` (40 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Antoine Tenart, Hangbin Liu,
David Ahern, Jakub Kicinski, Sasha Levin
From: Hangbin Liu <liuhangbin@gmail.com>
[ Upstream commit fd23d2dc180fccfad4b27a8e52ba1bc415d18509 ]
The previous test added an address with a specified metric and check if
correspond route was created. I somehow added two logs for the same
test. Remove the duplicated one.
Reported-by: Antoine Tenart <atenart@redhat.com>
Fixes: 0d29169a708b ("selftests/net/fib_tests: update addr_metric_test for peer route testing")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210119025930.2810532-1-liuhangbin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/fib_tests.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh
index 4811067d9b053..4e19a1c00ddd8 100755
--- a/tools/testing/selftests/net/fib_tests.sh
+++ b/tools/testing/selftests/net/fib_tests.sh
@@ -1055,7 +1055,6 @@ ipv6_addr_metric_test()
check_route6 "2001:db8:104::1 dev dummy2 proto kernel metric 260"
log_test $? 0 "Set metric with peer route on local side"
- log_test $? 0 "User specified metric on local address"
check_route6 "2001:db8:104::2 dev dummy2 proto kernel metric 260"
log_test $? 0 "Set metric with peer route on peer side"
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 49/86] can: dev: can_restart: fix use after free bug
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 48/86] selftests: net: fib_tests: remove duplicate log test Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 50/86] can: vxcan: vxcan_xmit: " Greg Kroah-Hartman
` (39 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vincent Mailhol, Marc Kleine-Budde,
Sasha Levin
From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the netif_rx_ni() in:
stats->rx_bytes += cf->len;
Reordering the lines solves the issue.
Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 5b8791135de13..247aeacb3a440 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -567,11 +567,11 @@ static void can_restart(struct net_device *dev)
}
cf->can_id |= CAN_ERR_RESTARTED;
- netif_rx_ni(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx_ni(skb);
+
restart:
netdev_dbg(dev, "restarted\n");
priv->can_stats.restarts++;
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 50/86] can: vxcan: vxcan_xmit: fix use after free bug
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 49/86] can: dev: can_restart: fix use after free bug Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 51/86] can: peak_usb: fix use after free bugs Greg Kroah-Hartman
` (38 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vincent Mailhol, Marc Kleine-Budde,
Sasha Levin
From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
[ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the canfd_frame cfd which aliases skb memory is accessed
after the netif_rx_ni().
Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)")
Link: https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/vxcan.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index d6ba9426be4de..b1baa4ac1d537 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -39,6 +39,7 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev)
struct net_device *peer;
struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
struct net_device_stats *peerstats, *srcstats = &dev->stats;
+ u8 len;
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
@@ -61,12 +62,13 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev)
skb->dev = peer;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ len = cfd->len;
if (netif_rx_ni(skb) == NET_RX_SUCCESS) {
srcstats->tx_packets++;
- srcstats->tx_bytes += cfd->len;
+ srcstats->tx_bytes += len;
peerstats = &peer->stats;
peerstats->rx_packets++;
- peerstats->rx_bytes += cfd->len;
+ peerstats->rx_bytes += len;
}
out_unlock:
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 51/86] can: peak_usb: fix use after free bugs
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 50/86] can: vxcan: vxcan_xmit: " Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 52/86] iio: ad5504: Fix setting power-down state Greg Kroah-Hartman
` (37 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vincent Mailhol, Marc Kleine-Budde,
Sasha Levin
From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
[ Upstream commit 50aca891d7a554db0901b245167cd653d73aaa71 ]
After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the peak_usb_netif_rx_ni().
Reordering the lines solves the issue.
Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters")
Link: https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
index dee3e689b54da..96bbdef672bc9 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
@@ -512,11 +512,11 @@ static int pcan_usb_fd_decode_canmsg(struct pcan_usb_fd_if *usb_if,
else
memcpy(cfd->data, rm->d, cfd->len);
- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
-
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += cfd->len;
+ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
+
return 0;
}
@@ -578,11 +578,11 @@ static int pcan_usb_fd_decode_status(struct pcan_usb_fd_if *usb_if,
if (!skb)
return -ENOMEM;
- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
-
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += cf->can_dlc;
+ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
+
return 0;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread* [PATCH 5.4 52/86] iio: ad5504: Fix setting power-down state
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 51/86] can: peak_usb: fix use after free bugs Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 53/86] cifs: do not fail __smb_send_rqst if non-fatal signals are pending Greg Kroah-Hartman
` (36 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen,
Alexandru Ardelean, Stable, Jonathan Cameron
From: Lars-Peter Clausen <lars@metafoo.de>
commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream.
The power-down mask of the ad5504 is actually a power-up mask. Meaning if
a bit is set the corresponding channel is powered up and if it is not set
the channel is powered down.
The driver currently has this the wrong way around, resulting in the
channel being powered up when requested to be powered down and vice versa.
Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201209104649.5794-1-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/dac/ad5504.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iio/dac/ad5504.c
+++ b/drivers/iio/dac/ad5504.c
@@ -188,9 +188,9 @@ static ssize_t ad5504_write_dac_powerdow
return ret;
if (pwr_down)
- st->pwr_down_mask |= (1 << chan->channel);
- else
st->pwr_down_mask &= ~(1 << chan->channel);
+ else
+ st->pwr_down_mask |= (1 << chan->channel);
ret = ad5504_spi_write(st, AD5504_ADDR_CTRL,
AD5504_DAC_PWRDWN_MODE(st->pwr_down_mode) |
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 53/86] cifs: do not fail __smb_send_rqst if non-fatal signals are pending
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 52/86] iio: ad5504: Fix setting power-down state Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 54/86] irqchip/mips-cpu: Set IPI domain parent chip Greg Kroah-Hartman
` (35 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ronnie Sahlberg, Pavel Shilovsky,
Steve French
From: Ronnie Sahlberg <lsahlber@redhat.com>
commit 214a5ea081e77346e4963dd6d20c5539ff8b6ae6 upstream.
RHBZ 1848178
The original intent of returning an error in this function
in the patch:
"CIFS: Mask off signals when sending SMB packets"
was to avoid interrupting packet send in the middle of
sending the data (and thus breaking an SMB connection),
but we also don't want to fail the request for non-fatal
signals even before we have had a chance to try to
send it (the reported problem could be reproduced e.g.
by exiting a child process when the parent process was in
the midst of calling futimens to update a file's timestamps).
In addition, since the signal may remain pending when we enter the
sending loop, we may end up not sending the whole packet before
TCP buffers become full. In this case the code returns -EINTR
but what we need here is to return -ERESTARTSYS instead to
allow system calls to be restarted.
Fixes: b30c74c73c78 ("CIFS: Mask off signals when sending SMB packets")
Cc: stable@vger.kernel.org # v5.1+
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -339,7 +339,7 @@ __smb_send_rqst(struct TCP_Server_Info *
if (ssocket == NULL)
return -EAGAIN;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
cifs_dbg(FYI, "signal pending before send request\n");
return -ERESTARTSYS;
}
@@ -431,7 +431,7 @@ unmask:
if (signal_pending(current) && (total_len != send_length)) {
cifs_dbg(FYI, "signal is pending after attempt to send\n");
- rc = -EINTR;
+ rc = -ERESTARTSYS;
}
/* uncork it */
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 54/86] irqchip/mips-cpu: Set IPI domain parent chip
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 53/86] cifs: do not fail __smb_send_rqst if non-fatal signals are pending Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 55/86] x86/mmx: Use KFPU_387 for MMX string operations Greg Kroah-Hartman
` (34 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mathias Kresin, Marc Zyngier
From: Mathias Kresin <dev@kresin.me>
commit 599b3063adf4bf041a87a69244ee36aded0d878f upstream.
Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
irq_data hierarchy") the irq_data chain is valided.
The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
domain hierarchy as valid, since the ipi domain has the irq domain set
as parent, but the parent domain has no chip set. Hence the boot ends in
a kernel panic.
Set the chip for the parent domain as it is done in the mips gic irq
driver, to have a valid irq_data chain.
Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support")
Cc: <stable@vger.kernel.org> # v5.10+
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210107213603.1637781-1-dev@kresin.me
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-mips-cpu.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/irqchip/irq-mips-cpu.c
+++ b/drivers/irqchip/irq-mips-cpu.c
@@ -197,6 +197,13 @@ static int mips_cpu_ipi_alloc(struct irq
if (ret)
return ret;
+ ret = irq_domain_set_hwirq_and_chip(domain->parent, virq + i, hwirq,
+ &mips_mt_cpu_irq_controller,
+ NULL);
+
+ if (ret)
+ return ret;
+
ret = irq_set_irq_type(virq + i, IRQ_TYPE_LEVEL_HIGH);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 55/86] x86/mmx: Use KFPU_387 for MMX string operations
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 54/86] irqchip/mips-cpu: Set IPI domain parent chip Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-26 7:03 ` Krzysztof Olędzki
2021-01-25 18:39 ` [PATCH 5.4 56/86] intel_th: pci: Add Alder Lake-P support Greg Kroah-Hartman
` (33 subsequent siblings)
88 siblings, 1 reply; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Krzysztof Mazur, Andy Lutomirski,
Borislav Petkov, Krzysztof Piotr Olędzki
From: Andy Lutomirski <luto@kernel.org>
commit 67de8dca50c027ca0fa3b62a488ee5035036a0da upstream.
The default kernel_fpu_begin() doesn't work on systems that support XMM but
haven't yet enabled CR4.OSFXSR. This causes crashes when _mmx_memcpy() is
called too early because LDMXCSR generates #UD when the aforementioned bit
is clear.
Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly.
Fixes: 7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()")
Reported-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Krzysztof Piotr Olędzki <ole@ans.pl>
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/e7bf21855fe99e5f3baa27446e32623358f69e8d.1611205691.git.luto@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/lib/mmx_32.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/arch/x86/lib/mmx_32.c
+++ b/arch/x86/lib/mmx_32.c
@@ -26,6 +26,16 @@
#include <asm/fpu/api.h>
#include <asm/asm.h>
+/*
+ * Use KFPU_387. MMX instructions are not affected by MXCSR,
+ * but both AMD and Intel documentation states that even integer MMX
+ * operations will result in #MF if an exception is pending in FCW.
+ *
+ * EMMS is not needed afterwards because, after calling kernel_fpu_end(),
+ * any subsequent user of the 387 stack will reinitialize it using
+ * KFPU_387.
+ */
+
void *_mmx_memcpy(void *to, const void *from, size_t len)
{
void *p;
@@ -37,7 +47,7 @@ void *_mmx_memcpy(void *to, const void *
p = to;
i = len >> 6; /* len/64 */
- kernel_fpu_begin();
+ kernel_fpu_begin_mask(KFPU_387);
__asm__ __volatile__ (
"1: prefetch (%0)\n" /* This set is 28 bytes */
@@ -127,7 +137,7 @@ static void fast_clear_page(void *page)
{
int i;
- kernel_fpu_begin();
+ kernel_fpu_begin_mask(KFPU_387);
__asm__ __volatile__ (
" pxor %%mm0, %%mm0\n" : :
@@ -160,7 +170,7 @@ static void fast_copy_page(void *to, voi
{
int i;
- kernel_fpu_begin();
+ kernel_fpu_begin_mask(KFPU_387);
/*
* maybe the prefetch stuff can go before the expensive fnsave...
@@ -247,7 +257,7 @@ static void fast_clear_page(void *page)
{
int i;
- kernel_fpu_begin();
+ kernel_fpu_begin_mask(KFPU_387);
__asm__ __volatile__ (
" pxor %%mm0, %%mm0\n" : :
@@ -282,7 +292,7 @@ static void fast_copy_page(void *to, voi
{
int i;
- kernel_fpu_begin();
+ kernel_fpu_begin_mask(KFPU_387);
__asm__ __volatile__ (
"1: prefetch (%0)\n"
^ permalink raw reply [flat|nested] 91+ messages in thread* Re: [PATCH 5.4 55/86] x86/mmx: Use KFPU_387 for MMX string operations
2021-01-25 18:39 ` [PATCH 5.4 55/86] x86/mmx: Use KFPU_387 for MMX string operations Greg Kroah-Hartman
@ 2021-01-26 7:03 ` Krzysztof Olędzki
0 siblings, 0 replies; 91+ messages in thread
From: Krzysztof Olędzki @ 2021-01-26 7:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel, Andy Lutomirski
Cc: stable, Krzysztof Mazur, Borislav Petkov
On 2021-01-25 at 10:39, Greg Kroah-Hartman wrote:
> From: Andy Lutomirski <luto@kernel.org>
>
> commit 67de8dca50c027ca0fa3b62a488ee5035036a0da upstream.
>
> The default kernel_fpu_begin() doesn't work on systems that support XMM but
> haven't yet enabled CR4.OSFXSR. This causes crashes when _mmx_memcpy() is
> called too early because LDMXCSR generates #UD when the aforementioned bit
> is clear.
>
> Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly.
>
> Fixes: 7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()")
> Reported-by: Krzysztof Mazur <krzysiek@podlesie.net>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Tested-by: Krzysztof Piotr Olędzki <ole@ans.pl>
> Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
> Cc: <stable@vger.kernel.org>
> Link: https://lkml.kernel.org/r/e7bf21855fe99e5f3baa27446e32623358f69e8d.1611205691.git.luto@kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Similar to 5.10.11, we also need
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e45122893a9870813f9bd7b4add4f613e6f29008
in 5.4.93:
Otherwise, the kernel will fail to compile if CONFIG_X86_USE_3DNOW=y
arch/x86/lib/mmx_32.c: In function '_mmx_memcpy':
arch/x86/lib/mmx_32.c:50:2: error: implicit declaration of function
'kernel_fpu_begin_mask'; did you mean 'kernel_fpu_begin'?
[-Werror=implicit-function-declaration]
50 | kernel_fpu_begin_mask(KFPU_387);
| ^~~~~~~~~~~~~~~~~~~~~
| kernel_fpu_begin
arch/x86/lib/mmx_32.c:50:24: error: 'KFPU_387' undeclared (first use in
this function)
50 | kernel_fpu_begin_mask(KFPU_387);
| ^~~~~~~~
arch/x86/lib/mmx_32.c:50:24: note: each undeclared identifier is
reported only once for each function it appears in
arch/x86/lib/mmx_32.c: In function 'fast_clear_page':
arch/x86/lib/mmx_32.c:140:24: error: 'KFPU_387' undeclared (first use in
this function)
140 | kernel_fpu_begin_mask(KFPU_387);
| ^~~~~~~~
arch/x86/lib/mmx_32.c: In function 'fast_copy_page':
arch/x86/lib/mmx_32.c:173:24: error: 'KFPU_387' undeclared (first use in
this function)
173 | kernel_fpu_begin_mask(KFPU_387);
| ^~~~~~~~
Thanks,
Krzysztof
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 5.4 56/86] intel_th: pci: Add Alder Lake-P support
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 55/86] x86/mmx: Use KFPU_387 for MMX string operations Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 57/86] stm class: Fix module init return on allocation failure Greg Kroah-Hartman
` (32 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alexander Shishkin
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
commit cb5c681ab9037e25fcca20689c82cf034566d610 upstream.
This adds support for the Trace Hub in Alder Lake-P.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20210115195917.3184-3-alexander.shishkin@linux.intel.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwtracing/intel_th/pci.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -259,6 +259,11 @@ static const struct pci_device_id intel_
.driver_data = (kernel_ulong_t)&intel_th_2x,
},
{
+ /* Alder Lake-P */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x51a6),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
/* Emmitsburg PCH */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1bcc),
.driver_data = (kernel_ulong_t)&intel_th_2x,
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 57/86] stm class: Fix module init return on allocation failure
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 56/86] intel_th: pci: Add Alder Lake-P support Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 58/86] serial: mvebu-uart: fix tx lost characters at power off Greg Kroah-Hartman
` (31 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hulk Robot, Wang Hui, Alexander Shishkin
From: Wang Hui <john.wanghui@huawei.com>
commit 927633a6d20af319d986f3e42c3ef9f6d7835008 upstream.
In stm_heartbeat_init(): return value gets reset after the first
iteration by stm_source_register_device(), so allocation failures
after that will, after a clean up, return success. Fix that.
Fixes: 119291853038 ("stm class: Add heartbeat stm source device")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hui <john.wanghui@huawei.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20210115195917.3184-2-alexander.shishkin@linux.intel.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwtracing/stm/heartbeat.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/hwtracing/stm/heartbeat.c
+++ b/drivers/hwtracing/stm/heartbeat.c
@@ -64,7 +64,7 @@ static void stm_heartbeat_unlink(struct
static int stm_heartbeat_init(void)
{
- int i, ret = -ENOMEM;
+ int i, ret;
if (nr_devs < 0 || nr_devs > STM_HEARTBEAT_MAX)
return -EINVAL;
@@ -72,8 +72,10 @@ static int stm_heartbeat_init(void)
for (i = 0; i < nr_devs; i++) {
stm_heartbeat[i].data.name =
kasprintf(GFP_KERNEL, "heartbeat.%d", i);
- if (!stm_heartbeat[i].data.name)
+ if (!stm_heartbeat[i].data.name) {
+ ret = -ENOMEM;
goto fail_unregister;
+ }
stm_heartbeat[i].data.nr_chans = 1;
stm_heartbeat[i].data.link = stm_heartbeat_link;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 58/86] serial: mvebu-uart: fix tx lost characters at power off
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 57/86] stm class: Fix module init return on allocation failure Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 59/86] ehci: fix EHCI host controller initialization sequence Greg Kroah-Hartman
` (30 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pali Rohár
From: Pali Rohár <pali@kernel.org>
commit 54ca955b5a4024e2ce0f206b03adb7109bc4da26 upstream.
Commit c685af1108d7 ("serial: mvebu-uart: fix tx lost characters") fixed tx
lost characters at low baud rates but started causing tx lost characters
when kernel is going to power off or reboot.
TX_EMP tells us when transmit queue is empty therefore all characters were
transmitted. TX_RDY tells us when CPU can send a new character.
Therefore we need to use different check prior transmitting new character
and different check after all characters were sent.
This patch splits polling code into two functions: wait_for_xmitr() which
waits for TX_RDY and wait_for_xmite() which waits for TX_EMP.
When rebooting A3720 platform without this patch on UART is print only:
[ 42.699�
And with this patch on UART is full output:
[ 39.530216] reboot: Restarting system
Fixes: c685af1108d7 ("serial: mvebu-uart: fix tx lost characters")
Signed-off-by: Pali Rohár <pali@kernel.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201223191931.18343-1-pali@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/mvebu-uart.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -648,6 +648,14 @@ static void wait_for_xmitr(struct uart_p
(val & STAT_TX_RDY(port)), 1, 10000);
}
+static void wait_for_xmite(struct uart_port *port)
+{
+ u32 val;
+
+ readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+ (val & STAT_TX_EMP), 1, 10000);
+}
+
static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
{
wait_for_xmitr(port);
@@ -675,7 +683,7 @@ static void mvebu_uart_console_write(str
uart_console_write(port, s, count, mvebu_uart_console_putchar);
- wait_for_xmitr(port);
+ wait_for_xmite(port);
if (ier)
writel(ier, port->membase + UART_CTRL(port));
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 59/86] ehci: fix EHCI host controller initialization sequence
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 58/86] serial: mvebu-uart: fix tx lost characters at power off Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 60/86] USB: ehci: fix an interrupt calltrace error Greg Kroah-Hartman
` (29 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alan Stern, Eugene Korenevsky
From: Eugene Korenevsky <ekorenevsky@astralinux.ru>
commit 280a9045bb18833db921b316a5527d2b565e9f2e upstream.
According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever
USBCMD.RS=1.
However, it is a good practice to wait some time after setting USBCMD.RS
(approximately 100ms) until USBSTS.HCHalted become zero.
Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs
(see BugLink).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Eugene Korenevsky <ekorenevsky@astralinux.ru>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210110173609.GA17313@himera.home
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/ehci-hcd.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -574,6 +574,7 @@ static int ehci_run (struct usb_hcd *hcd
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
u32 hcc_params;
+ int rc;
hcd->uses_new_polling = 1;
@@ -629,9 +630,20 @@ static int ehci_run (struct usb_hcd *hcd
down_write(&ehci_cf_port_reset_rwsem);
ehci->rh_state = EHCI_RH_RUNNING;
ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
+
+ /* Wait until HC become operational */
ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
msleep(5);
+ rc = ehci_handshake(ehci, &ehci->regs->status, STS_HALT, 0, 100 * 1000);
+
up_write(&ehci_cf_port_reset_rwsem);
+
+ if (rc) {
+ ehci_err(ehci, "USB %x.%x, controller refused to start: %d\n",
+ ((ehci->sbrn & 0xf0)>>4), (ehci->sbrn & 0x0f), rc);
+ return rc;
+ }
+
ehci->last_periodic_enable = ktime_get_real();
temp = HC_VERSION(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 60/86] USB: ehci: fix an interrupt calltrace error
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 59/86] ehci: fix EHCI host controller initialization sequence Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 61/86] usb: gadget: aspeed: fix stop dma register setting Greg Kroah-Hartman
` (28 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Longfang Liu, Alan Stern
From: Longfang Liu <liulongfang@huawei.com>
commit 643a4df7fe3f6831d14536fd692be85f92670a52 upstream.
The system that use Synopsys USB host controllers goes to suspend
when using USB audio player. This causes the USB host controller
continuous send interrupt signal to system, When the number of
interrupts exceeds 100000, the system will forcibly close the
interrupts and output a calltrace error.
When the system goes to suspend, the last interrupt is reported to
the driver. At this time, the system has set the state to suspend.
This causes the last interrupt to not be processed by the system and
not clear the interrupt flag. This uncleared interrupt flag constantly
triggers new interrupt event. This causing the driver to receive more
than 100,000 interrupts, which causes the system to forcibly close the
interrupt report and report the calltrace error.
so, when the driver goes to sleep and changes the system state to
suspend, the interrupt flag needs to be cleared.
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongfang@huawei.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/ehci-hub.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -345,6 +345,9 @@ static int ehci_bus_suspend (struct usb_
unlink_empty_async_suspended(ehci);
+ /* Some Synopsys controllers mistakenly leave IAA turned on */
+ ehci_writel(ehci, STS_IAA, &ehci->regs->status);
+
/* Any IAA cycle that started before the suspend is now invalid */
end_iaa_cycle(ehci);
ehci_handle_start_intr_unlinks(ehci);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 61/86] usb: gadget: aspeed: fix stop dma register setting.
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 60/86] USB: ehci: fix an interrupt calltrace error Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 62/86] usb: udc: core: Use lock when write to soft_connect Greg Kroah-Hartman
` (27 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Felipe Balbi, Joel Stanley, Ryan Chen
From: Ryan Chen <ryan_chen@aspeedtech.com>
commit 4e0dcf62ab4cf917d0cbe751b8bf229a065248d4 upstream.
The vhub engine has two dma mode, one is descriptor list, another
is single stage DMA. Each mode has different stop register setting.
Descriptor list operation (bit2) : 0 disable reset, 1: enable reset
Single mode operation (bit0) : 0 : disable, 1: enable
Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub")
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_chen@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/udc/aspeed-vhub/epn.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/aspeed-vhub/epn.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
@@ -420,7 +420,10 @@ static void ast_vhub_stop_active_req(str
u32 state, reg, loops;
/* Stop DMA activity */
- writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
+ if (ep->epn.desc_mode)
+ writel(VHUB_EP_DMA_CTRL_RESET, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
+ else
+ writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
/* Wait for it to complete */
for (loops = 0; loops < 1000; loops++) {
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 62/86] usb: udc: core: Use lock when write to soft_connect
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 61/86] usb: gadget: aspeed: fix stop dma register setting Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 63/86] usb: bdc: Make bdc pci driver depend on BROKEN Greg Kroah-Hartman
` (26 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Felipe Balbi, Thinh Nguyen
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
commit c28095bc99073ddda65e4f31f6ae0d908d4d5cd8 upstream.
Use lock to guard against concurrent access for soft-connect/disconnect
operations when writing to soft_connect sysfs.
Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class")
Cc: stable@vger.kernel.org
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/udc/core.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1477,10 +1477,13 @@ static ssize_t soft_connect_store(struct
struct device_attribute *attr, const char *buf, size_t n)
{
struct usb_udc *udc = container_of(dev, struct usb_udc, dev);
+ ssize_t ret;
+ mutex_lock(&udc_lock);
if (!udc->driver) {
dev_err(dev, "soft-connect without a gadget driver\n");
- return -EOPNOTSUPP;
+ ret = -EOPNOTSUPP;
+ goto out;
}
if (sysfs_streq(buf, "connect")) {
@@ -1491,10 +1494,14 @@ static ssize_t soft_connect_store(struct
usb_gadget_udc_stop(udc);
} else {
dev_err(dev, "unsupported command '%s'\n", buf);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
- return n;
+ ret = n;
+out:
+ mutex_unlock(&udc_lock);
+ return ret;
}
static DEVICE_ATTR_WO(soft_connect);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 63/86] usb: bdc: Make bdc pci driver depend on BROKEN
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 62/86] usb: udc: core: Use lock when write to soft_connect Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 64/86] xhci: make sure TRB is fully written before giving it to the controller Greg Kroah-Hartman
` (25 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Al Cooper, Felipe Balbi, Patrik Jakobsson
From: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream.
The bdc pci driver is going to be removed due to it not existing in the
wild. This patch turns off compilation of the driver so that stable
kernels can also pick up the change. This helps the out-of-tree
facetimehd webcam driver as the pci id conflicts with bdc.
Cc: Al Cooper <alcooperx@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/bdc/Kconfig
+++ b/drivers/usb/gadget/udc/bdc/Kconfig
@@ -17,7 +17,7 @@ if USB_BDC_UDC
comment "Platform Support"
config USB_BDC_PCI
tristate "BDC support for PCIe based platforms"
- depends on USB_PCI
+ depends on USB_PCI && BROKEN
default USB_BDC_UDC
help
Enable support for platforms which have BDC connected through PCIe, such as Lego3 FPGA platform.
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 64/86] xhci: make sure TRB is fully written before giving it to the controller
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 63/86] usb: bdc: Make bdc pci driver depend on BROKEN Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 65/86] xhci: tegra: Delay for disabling LFPS detector Greg Kroah-Hartman
` (24 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ross Zwisler, Mathias Nyman
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit 576667bad341516edc4e18eb85acb0a2b4c9c9d9 upstream.
Once the command ring doorbell is rung the xHC controller will parse all
command TRBs on the command ring that have the cycle bit set properly.
If the driver just started writing the next command TRB to the ring when
hardware finished the previous TRB, then HW might fetch an incomplete TRB
as long as its cycle bit set correctly.
A command TRB is 16 bytes (128 bits) long.
Driver writes the command TRB in four 32 bit chunks, with the chunk
containing the cycle bit last. This does however not guarantee that
chunks actually get written in that order.
This was detected in stress testing when canceling URBs with several
connected USB devices.
Two consecutive "Set TR Dequeue pointer" commands got queued right
after each other, and the second one was only partially written when
the controller parsed it, causing the dequeue pointer to be set
to bogus values. This was seen as error messages:
"Mismatch between completed Set TR Deq Ptr command & xHCI internal state"
Solution is to add a write memory barrier before writing the cycle bit.
Cc: <stable@vger.kernel.org>
Tested-by: Ross Zwisler <zwisler@google.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210115161907.2875631-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2918,6 +2918,8 @@ static void queue_trb(struct xhci_hcd *x
trb->field[0] = cpu_to_le32(field1);
trb->field[1] = cpu_to_le32(field2);
trb->field[2] = cpu_to_le32(field3);
+ /* make sure TRB is fully written before giving it to the controller */
+ wmb();
trb->field[3] = cpu_to_le32(field4);
trace_xhci_queue_trb(ring, trb);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 65/86] xhci: tegra: Delay for disabling LFPS detector
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 64/86] xhci: make sure TRB is fully written before giving it to the controller Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 66/86] driver core: Extend device_is_dependent() Greg Kroah-Hartman
` (23 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, JC Kuo, Mathias Nyman
From: JC Kuo <jckuo@nvidia.com>
commit da7e0c3c2909a3d9bf8acfe1db3cb213bd7febfb upstream.
Occasionally, we are seeing some SuperSpeed devices resumes right after
being directed to U3. This commits add 500us delay to ensure LFPS
detector is disabled before sending ACK to firmware.
[ 16.099363] tegra-xusb 70090000.usb: entering ELPG
[ 16.104343] tegra-xusb 70090000.usb: 2-1 isn't suspended: 0x0c001203
[ 16.114576] tegra-xusb 70090000.usb: not all ports suspended: -16
[ 16.120789] tegra-xusb 70090000.usb: entering ELPG failed
The register write passes through a few flop stages of 32KHz clock domain.
NVIDIA ASIC designer reviewed RTL and suggests 500us delay.
Cc: stable@vger.kernel.org
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210115161907.2875631-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-tegra.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -562,6 +562,13 @@ static void tegra_xusb_mbox_handle(struc
enable);
if (err < 0)
break;
+
+ /*
+ * wait 500us for LFPS detector to be disabled before
+ * sending ACK
+ */
+ if (!enable)
+ usleep_range(500, 1000);
}
if (err < 0) {
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 66/86] driver core: Extend device_is_dependent()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 65/86] xhci: tegra: Delay for disabling LFPS detector Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 67/86] pinctrl: ingenic: Fix JZ4760 support Greg Kroah-Hartman
` (22 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephan Gerhold, Saravana Kannan,
Rafael J. Wysocki
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream.
If the device passed as the target (second argument) to
device_is_dependent() is not completely registered (that is, it has
been initialized, but not added yet), but the parent pointer of it
is set, it may be missing from the list of the parent's children
and device_for_each_child() called by device_is_dependent() cannot
be relied on to catch that dependency.
For this reason, modify device_is_dependent() to check the ancestors
of the target device by following its parent pointer in addition to
the device_for_each_child() walk.
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Reported-by: Stephan Gerhold <stephan@gerhold.net>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/core.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -106,6 +106,16 @@ int device_links_read_lock_held(void)
#endif
#endif /* !CONFIG_SRCU */
+static bool device_is_ancestor(struct device *dev, struct device *target)
+{
+ while (target->parent) {
+ target = target->parent;
+ if (dev == target)
+ return true;
+ }
+ return false;
+}
+
/**
* device_is_dependent - Check if one device depends on another one
* @dev: Device to check dependencies for.
@@ -119,7 +129,12 @@ static int device_is_dependent(struct de
struct device_link *link;
int ret;
- if (dev == target)
+ /*
+ * The "ancestors" check is needed to catch the case when the target
+ * device has not been completely initialized yet and it is still
+ * missing from the list of children of its parent device.
+ */
+ if (dev == target || device_is_ancestor(dev, target))
return 1;
ret = device_for_each_child(dev, target, device_is_dependent);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 67/86] pinctrl: ingenic: Fix JZ4760 support
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 66/86] driver core: Extend device_is_dependent() Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 68/86] x86/cpu/amd: Set __max_die_per_package on AMD Greg Kroah-Hartman
` (21 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Paul Cercueil, Linus Walleij
From: Paul Cercueil <paul@crapouillou.net>
commit 9a85c09a3f507b925d75cb0c7c8f364467038052 upstream.
- JZ4760 and JZ4760B have a similar register layout as the JZ4740, and
don't use the new register layout, which was introduced with the
JZ4770 SoC and not the JZ4760 or JZ4760B SoCs.
- The JZ4740 code path only expected two function modes to be
configurable for each pin, and wouldn't work with more than two. Fix
it for the JZ4760, which has four configurable function modes.
Fixes: 0257595a5cf4 ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.")
Cc: <stable@vger.kernel.org> # 5.3
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/pinctrl-ingenic.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -1378,7 +1378,7 @@ static inline bool ingenic_gpio_get_valu
static void ingenic_gpio_set_value(struct ingenic_gpio_chip *jzgc,
u8 offset, int value)
{
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_PAT0, offset, !!value);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_DATA, offset, !!value);
@@ -1389,7 +1389,7 @@ static void irq_set_type(struct ingenic_
{
u8 reg1, reg2;
- if (jzgc->jzpc->version >= ID_JZ4760) {
+ if (jzgc->jzpc->version >= ID_JZ4770) {
reg1 = JZ4760_GPIO_PAT1;
reg2 = JZ4760_GPIO_PAT0;
} else {
@@ -1464,7 +1464,7 @@ static void ingenic_gpio_irq_enable(stru
struct ingenic_gpio_chip *jzgc = gpiochip_get_data(gc);
int irq = irqd->hwirq;
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_INT, irq, true);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_SELECT, irq, true);
@@ -1480,7 +1480,7 @@ static void ingenic_gpio_irq_disable(str
ingenic_gpio_irq_mask(irqd);
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_INT, irq, false);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_SELECT, irq, false);
@@ -1505,7 +1505,7 @@ static void ingenic_gpio_irq_ack(struct
irq_set_type(jzgc, irq, IRQ_TYPE_LEVEL_HIGH);
}
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_FLAG, irq, false);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_DATA, irq, true);
@@ -1562,7 +1562,7 @@ static void ingenic_gpio_irq_handler(str
chained_irq_enter(irq_chip, desc);
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
flag = ingenic_gpio_read_reg(jzgc, JZ4760_GPIO_FLAG);
else
flag = ingenic_gpio_read_reg(jzgc, JZ4740_GPIO_FLAG);
@@ -1643,7 +1643,7 @@ static int ingenic_gpio_get_direction(st
struct ingenic_pinctrl *jzpc = jzgc->jzpc;
unsigned int pin = gc->base + offset;
- if (jzpc->version >= ID_JZ4760)
+ if (jzpc->version >= ID_JZ4770)
return ingenic_get_pin_config(jzpc, pin, JZ4760_GPIO_INT) ||
ingenic_get_pin_config(jzpc, pin, JZ4760_GPIO_PAT1);
@@ -1676,7 +1676,7 @@ static int ingenic_pinmux_set_pin_fn(str
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, func & 0x2);
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT0, func & 0x1);
ingenic_shadow_config_pin_load(jzpc, pin);
- } else if (jzpc->version >= ID_JZ4760) {
+ } else if (jzpc->version >= ID_JZ4770) {
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_INT, false);
ingenic_config_pin(jzpc, pin, GPIO_MSK, false);
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, func & 0x2);
@@ -1684,7 +1684,7 @@ static int ingenic_pinmux_set_pin_fn(str
} else {
ingenic_config_pin(jzpc, pin, JZ4740_GPIO_FUNC, true);
ingenic_config_pin(jzpc, pin, JZ4740_GPIO_TRIG, func & 0x2);
- ingenic_config_pin(jzpc, pin, JZ4740_GPIO_SELECT, func > 0);
+ ingenic_config_pin(jzpc, pin, JZ4740_GPIO_SELECT, func & 0x1);
}
return 0;
@@ -1734,7 +1734,7 @@ static int ingenic_pinmux_gpio_set_direc
ingenic_shadow_config_pin(jzpc, pin, GPIO_MSK, true);
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, input);
ingenic_shadow_config_pin_load(jzpc, pin);
- } else if (jzpc->version >= ID_JZ4760) {
+ } else if (jzpc->version >= ID_JZ4770) {
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_INT, false);
ingenic_config_pin(jzpc, pin, GPIO_MSK, true);
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, input);
@@ -1764,7 +1764,7 @@ static int ingenic_pinconf_get(struct pi
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
bool pull;
- if (jzpc->version >= ID_JZ4760)
+ if (jzpc->version >= ID_JZ4770)
pull = !ingenic_get_pin_config(jzpc, pin, JZ4760_GPIO_PEN);
else
pull = !ingenic_get_pin_config(jzpc, pin, JZ4740_GPIO_PULL_DIS);
@@ -1796,7 +1796,7 @@ static int ingenic_pinconf_get(struct pi
static void ingenic_set_bias(struct ingenic_pinctrl *jzpc,
unsigned int pin, bool enabled)
{
- if (jzpc->version >= ID_JZ4760)
+ if (jzpc->version >= ID_JZ4770)
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_PEN, !enabled);
else
ingenic_config_pin(jzpc, pin, JZ4740_GPIO_PULL_DIS, !enabled);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 68/86] x86/cpu/amd: Set __max_die_per_package on AMD
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 67/86] pinctrl: ingenic: Fix JZ4760 support Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 69/86] netfilter: rpfilter: mask ecn bits before fib lookup Greg Kroah-Hartman
` (20 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johnathan Smithinovic,
Rafael Kitover, Yazen Ghannam, Borislav Petkov
From: Yazen Ghannam <Yazen.Ghannam@amd.com>
commit 76e2fc63ca40977af893b724b00cc2f8e9ce47a4 upstream.
Set the maximum DIE per package variable on AMD using the
NodesPerProcessor topology value. This will be used by RAPL, among
others, to determine the maximum number of DIEs on the system in order
to do per-DIE manipulations.
[ bp: Productize into a proper patch. ]
Fixes: 028c221ed190 ("x86/CPU/AMD: Save AMD NodeId as cpu_die_id")
Reported-by: Johnathan Smithinovic <johnathan.smithinovic@gmx.at>
Reported-by: Rafael Kitover <rkitover@gmail.com>
Signed-off-by: Yazen Ghannam <Yazen.Ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Johnathan Smithinovic <johnathan.smithinovic@gmx.at>
Tested-by: Rafael Kitover <rkitover@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=210939
Link: https://lkml.kernel.org/r/20210106112106.GE5729@zn.tnic
Link: https://lkml.kernel.org/r/20210111101455.1194-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -545,12 +545,12 @@ static void bsp_init_amd(struct cpuinfo_
u32 ecx;
ecx = cpuid_ecx(0x8000001e);
- nodes_per_socket = ((ecx >> 8) & 7) + 1;
+ __max_die_per_package = nodes_per_socket = ((ecx >> 8) & 7) + 1;
} else if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
u64 value;
rdmsrl(MSR_FAM10H_NODE_ID, value);
- nodes_per_socket = ((value >> 3) & 7) + 1;
+ __max_die_per_package = nodes_per_socket = ((value >> 3) & 7) + 1;
}
if (!boot_cpu_has(X86_FEATURE_AMD_SSBD) &&
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 69/86] netfilter: rpfilter: mask ecn bits before fib lookup
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 68/86] x86/cpu/amd: Set __max_die_per_package on AMD Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 70/86] sh: dma: fix kconfig dependency for G2_DMA Greg Kroah-Hartman
` (19 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Guillaume Nault, Jakub Kicinski
From: Guillaume Nault <gnault@redhat.com>
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip netns add ns0
$ ip netns add ns1
$ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
$ ip -netns ns0 link set dev veth01 up
$ ip -netns ns1 link set dev veth10 up
$ ip -netns ns0 address add 192.0.2.10/32 dev veth01
$ ip -netns ns1 address add 192.0.2.11/32 dev veth10
Add a route to ns1 in ns0:
$ ip -netns ns0 route add 192.0.2.11/32 dev veth01
In ns1, only packets with TOS 4 can be routed to ns0:
$ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10
Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS
is 4:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 0% packet loss ...
Now use iptable's rpfilter module in ns1:
$ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert -j DROP
Not-ECT and ECT(1) packets still pass:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
But ECT(0) and ECN packets are dropped:
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 100% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 100% packet loss ...
After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore.
Fixes: 8f97339d3feb ("netfilter: add ipv4 reverse path filter match")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/netfilter/ipt_rpfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -76,7 +76,7 @@ static bool rpfilter_mt(const struct sk_
flow.daddr = iph->saddr;
flow.saddr = rpfilter_get_saddr(iph->daddr);
flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
- flow.flowi4_tos = RT_TOS(iph->tos);
+ flow.flowi4_tos = iph->tos & IPTOS_RT_MASK;
flow.flowi4_scope = RT_SCOPE_UNIVERSE;
flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 70/86] sh: dma: fix kconfig dependency for G2_DMA
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 69/86] netfilter: rpfilter: mask ecn bits before fib lookup Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 71/86] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext Greg Kroah-Hartman
` (18 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Necip Fazil Yildiran, Rich Felker
From: Necip Fazil Yildiran <fazilyildiran@gmail.com>
commit f477a538c14d07f8c45e554c8c5208d588514e98 upstream.
When G2_DMA is enabled and SH_DMA is disabled, it results in the following
Kbuild warning:
WARNING: unmet direct dependencies detected for SH_DMA_API
Depends on [n]: SH_DMA [=n]
Selected by [y]:
- G2_DMA [=y] && SH_DREAMCAST [=y]
The reason is that G2_DMA selects SH_DMA_API without depending on or
selecting SH_DMA while SH_DMA_API depends on SH_DMA.
When G2_DMA was first introduced with commit 40f49e7ed77f
("sh: dma: Make G2 DMA configurable."), this wasn't an issue since
SH_DMA_API didn't have such dependency, and this way was the only way to
enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was
made visible and dependent on SH_DMA with commit d8902adcc1a9
("dmaengine: sh: Add Support SuperH DMA Engine driver").
Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues.
Fixes: d8902adcc1a9 ("dmaengine: sh: Add Support SuperH DMA Engine driver")
Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Signed-off-by: Rich Felker <dalias@libc.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sh/drivers/dma/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/sh/drivers/dma/Kconfig
+++ b/arch/sh/drivers/dma/Kconfig
@@ -63,8 +63,7 @@ config PVR2_DMA
config G2_DMA
tristate "G2 Bus DMA support"
- depends on SH_DREAMCAST
- select SH_DMA_API
+ depends on SH_DREAMCAST && SH_DMA_API
help
This enables support for the DMA controller for the Dreamcast's
G2 bus. Drivers that want this will generally enable this on
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 71/86] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 70/86] sh: dma: fix kconfig dependency for G2_DMA Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 72/86] sh_eth: Fix power down vs. is_opened flag ordering Greg Kroah-Hartman
` (17 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rasmus Villemoes, Florian Fainelli,
Tobias Waldekranz, Jakub Kicinski
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
commit 87fe04367d842c4d97a77303242d4dd4ac351e46 upstream.
mv88e6xxx_port_vlan_join checks whether the VTU already contains an
entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely
changes the relevant .member[] element and loads the updated entry
into the VTU.
However, at least for the mv88e6250, the on-stack struct
mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly
initialized, neither in mv88e6xxx_port_vlan_join() nor inside the
getnext implementation. So the new entry has random garbage for the
STU bits, breaking VLAN filtering.
When the VTU entry is initially created, those bits are all zero, and
we should make sure to keep them that way when the entry is updated.
Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097)
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>
Tested-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/mv88e6xxx/global1_vtu.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/dsa/mv88e6xxx/global1_vtu.c
+++ b/drivers/net/dsa/mv88e6xxx/global1_vtu.c
@@ -351,6 +351,10 @@ int mv88e6250_g1_vtu_getnext(struct mv88
if (err)
return err;
+ err = mv88e6185_g1_stu_data_read(chip, entry);
+ if (err)
+ return err;
+
/* VTU DBNum[3:0] are located in VTU Operation 3:0
* VTU DBNum[5:4] are located in VTU Operation 9:8
*/
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 72/86] sh_eth: Fix power down vs. is_opened flag ordering
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 71/86] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 73/86] lightnvm: fix memory leak when submit fails Greg Kroah-Hartman
` (16 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Geert Uytterhoeven, Sergei Shtylyov,
Niklas Söderlund, Jakub Kicinski
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit f6a2e94b3f9d89cb40771ff746b16b5687650cbb upstream.
sh_eth_close() does a synchronous power down of the device before
marking it closed. Revert the order, to make sure the device is never
marked opened while suspended.
While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as
there is no reason to do a synchronous power down.
Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2640,10 +2640,10 @@ static int sh_eth_close(struct net_devic
/* Free all the skbuffs in the Rx queue and the DMA buffer. */
sh_eth_ring_free(ndev);
- pm_runtime_put_sync(&mdp->pdev->dev);
-
mdp->is_opened = 0;
+ pm_runtime_put(&mdp->pdev->dev);
+
return 0;
}
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 73/86] lightnvm: fix memory leak when submit fails
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 72/86] sh_eth: Fix power down vs. is_opened flag ordering Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 74/86] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too Greg Kroah-Hartman
` (15 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pan Bian, Jens Axboe
From: Pan Bian <bianpan2016@163.com>
commit 97784481757fba7570121a70dd37ca74a29f50a8 upstream.
The allocated page is not released if error occurs in
nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid
possible memory leak issue.
Fixes: aff3fb18f957 ("lightnvm: move bad block and chunk state logic to core")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/lightnvm/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -849,11 +849,10 @@ static int nvm_bb_chunk_sense(struct nvm
rqd.ppa_addr = generic_to_dev_addr(dev, ppa);
ret = nvm_submit_io_sync_raw(dev, &rqd);
+ __free_page(page);
if (ret)
return ret;
- __free_page(page);
-
return rqd.error;
}
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 74/86] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 73/86] lightnvm: fix memory leak when submit fails Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 75/86] kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow Greg Kroah-Hartman
` (14 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Lobakin, Jakub Kicinski
From: Alexander Lobakin <alobakin@pm.me>
commit 66c556025d687dbdd0f748c5e1df89c977b6c02a upstream.
Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for
tiny skbs") ensured that skbs with data size lower than 1025 bytes
will be kmalloc'ed to avoid excessive page cache fragmentation and
memory consumption.
However, the fix adressed only __napi_alloc_skb() (primarily for
virtio_net and napi_get_frags()), but the issue can still be achieved
through __netdev_alloc_skb(), which is still used by several drivers.
Drivers often allocate a tiny skb for headers and place the rest of
the frame to frags (so-called copybreak).
Mirror the condition to __netdev_alloc_skb() to handle this case too.
Since v1 [0]:
- fix "Fixes:" tag;
- refine commit message (mention copybreak usecase).
[0] https://lore.kernel.org/netdev/20210114235423.232737-1-alobakin@pm.me
Fixes: a1c7fff7e18f ("net: netdev_alloc_skb() use build_skb()")
Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Link: https://lore.kernel.org/r/20210115150354.85967-1-alobakin@pm.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/skbuff.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -431,7 +431,11 @@ struct sk_buff *__netdev_alloc_skb(struc
len += NET_SKB_PAD;
- if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
+ /* If requested length is either too small or too big,
+ * we use kmalloc() for skb->head allocation.
+ */
+ if (len <= SKB_WITH_OVERHEAD(1024) ||
+ len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
(gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
if (!skb)
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 75/86] kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 74/86] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 76/86] kasan: fix incorrect arguments passing in kasan_add_zero_shadow Greg Kroah-Hartman
` (13 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lecopzer Chen, Andrey Ryabinin,
Dan Williams, Dmitry Vyukov, Alexander Potapenko, YJ Chiang,
Andrey Konovalov, Andrew Morton, Linus Torvalds
From: Lecopzer Chen <lecopzer@gmail.com>
commit a11a496ee6e2ab6ed850233c96b94caf042af0b9 upstream.
During testing kasan_populate_early_shadow and kasan_remove_zero_shadow,
if the shadow start and end address in kasan_remove_zero_shadow() is not
aligned to PMD_SIZE, the remain unaligned PTE won't be removed.
In the test case for kasan_remove_zero_shadow():
shadow_start: 0xffffffb802000000, shadow end: 0xffffffbfbe000000
3-level page table:
PUD_SIZE: 0x40000000 PMD_SIZE: 0x200000 PAGE_SIZE: 4K
0xffffffbf80000000 ~ 0xffffffbfbdf80000 will not be removed because in
kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next
address is 0xffffffbfbdf80000 which is not aligned to PUD_SIZE.
In the correct condition, this should fallback to the next level
kasan_remove_pmd_table() but the condition flow always continue to skip
the unaligned part.
Fix by correcting the condition when next and addr are neither aligned.
Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecopzer@gmail.com
Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN")
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/kasan/init.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -388,9 +388,10 @@ static void kasan_remove_pmd_table(pmd_t
if (kasan_pte_table(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
- IS_ALIGNED(next, PMD_SIZE))
+ IS_ALIGNED(next, PMD_SIZE)) {
pmd_clear(pmd);
- continue;
+ continue;
+ }
}
pte = pte_offset_kernel(pmd, addr);
kasan_remove_pte_table(pte, addr, next);
@@ -413,9 +414,10 @@ static void kasan_remove_pud_table(pud_t
if (kasan_pmd_table(*pud)) {
if (IS_ALIGNED(addr, PUD_SIZE) &&
- IS_ALIGNED(next, PUD_SIZE))
+ IS_ALIGNED(next, PUD_SIZE)) {
pud_clear(pud);
- continue;
+ continue;
+ }
}
pmd = pmd_offset(pud, addr);
pmd_base = pmd_offset(pud, 0);
@@ -439,9 +441,10 @@ static void kasan_remove_p4d_table(p4d_t
if (kasan_pud_table(*p4d)) {
if (IS_ALIGNED(addr, P4D_SIZE) &&
- IS_ALIGNED(next, P4D_SIZE))
+ IS_ALIGNED(next, P4D_SIZE)) {
p4d_clear(p4d);
- continue;
+ continue;
+ }
}
pud = pud_offset(p4d, addr);
kasan_remove_pud_table(pud, addr, next);
@@ -473,9 +476,10 @@ void kasan_remove_zero_shadow(void *star
if (kasan_p4d_table(*pgd)) {
if (IS_ALIGNED(addr, PGDIR_SIZE) &&
- IS_ALIGNED(next, PGDIR_SIZE))
+ IS_ALIGNED(next, PGDIR_SIZE)) {
pgd_clear(pgd);
- continue;
+ continue;
+ }
}
p4d = p4d_offset(pgd, addr);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 76/86] kasan: fix incorrect arguments passing in kasan_add_zero_shadow
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 75/86] kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:39 ` [PATCH 5.4 77/86] udp: mask TOS bits in udp_v4_early_demux() Greg Kroah-Hartman
` (12 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lecopzer Chen, Andrey Konovalov,
Andrey Ryabinin, Dan Williams, Dmitry Vyukov,
Alexander Potapenko, Andrew Morton, Linus Torvalds
From: Lecopzer Chen <lecopzer@gmail.com>
commit 5dabd1712cd056814f9ab15f1d68157ceb04e741 upstream.
kasan_remove_zero_shadow() shall use original virtual address, start and
size, instead of shadow address.
Link: https://lkml.kernel.org/r/20210103063847.5963-1-lecopzer@gmail.com
Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN")
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/kasan/init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -503,7 +503,6 @@ int kasan_add_zero_shadow(void *start, u
ret = kasan_populate_early_shadow(shadow_start, shadow_end);
if (ret)
- kasan_remove_zero_shadow(shadow_start,
- size >> KASAN_SHADOW_SCALE_SHIFT);
+ kasan_remove_zero_shadow(start, size);
return ret;
}
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 77/86] udp: mask TOS bits in udp_v4_early_demux()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 76/86] kasan: fix incorrect arguments passing in kasan_add_zero_shadow Greg Kroah-Hartman
@ 2021-01-25 18:39 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 78/86] ipv6: create multicast route with RTPROT_KERNEL Greg Kroah-Hartman
` (11 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Guillaume Nault, Jakub Kicinski
From: Guillaume Nault <gnault@redhat.com>
commit 8d2b51b008c25240914984208b2ced57d1dd25a5 upstream.
udp_v4_early_demux() is the only function that calls
ip_mc_validate_source() with a TOS that hasn't been masked with
IPTOS_RT_MASK.
This results in different behaviours for incoming multicast UDPv4
packets, depending on if ip_mc_validate_source() is called from the
early-demux path (udp_v4_early_demux) or from the regular input path
(ip_route_input_noref).
ECN would normally not be used with UDP multicast packets, so the
practical consequences should be limited on that side. However,
IPTOS_RT_MASK is used to also masks the TOS' high order bits, to align
with the non-early-demux path behaviour.
Reproducer:
Setup two netns, connected with veth:
$ ip netns add ns0
$ ip netns add ns1
$ ip -netns ns0 link set dev lo up
$ ip -netns ns1 link set dev lo up
$ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
$ ip -netns ns0 link set dev veth01 up
$ ip -netns ns1 link set dev veth10 up
$ ip -netns ns0 address add 192.0.2.10 peer 192.0.2.11/32 dev veth01
$ ip -netns ns1 address add 192.0.2.11 peer 192.0.2.10/32 dev veth10
In ns0, add route to multicast address 224.0.2.0/24 using source
address 198.51.100.10:
$ ip -netns ns0 address add 198.51.100.10/32 dev lo
$ ip -netns ns0 route add 224.0.2.0/24 dev veth01 src 198.51.100.10
In ns1, define route to 198.51.100.10, only for packets with TOS 4:
$ ip -netns ns1 route add 198.51.100.10/32 tos 4 dev veth10
Also activate rp_filter in ns1, so that incoming packets not matching
the above route get dropped:
$ ip netns exec ns1 sysctl -wq net.ipv4.conf.veth10.rp_filter=1
Now try to receive packets on 224.0.2.11:
$ ip netns exec ns1 socat UDP-RECVFROM:1111,ip-add-membership=224.0.2.11:veth10,ignoreeof -
In ns0, send packet to 224.0.2.11 with TOS 4 and ECT(0) (that is,
tos 6 for socat):
$ echo test0 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6
The "test0" message is properly received by socat in ns1, because
early-demux has no cached dst to use, so source address validation
is done by ip_route_input_mc(), which receives a TOS that has the
ECN bits masked.
Now send another packet to 224.0.2.11, still with TOS 4 and ECT(0):
$ echo test1 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6
The "test1" message isn't received by socat in ns1, because, now,
early-demux has a cached dst to use and calls ip_mc_validate_source()
immediately, without masking the ECN bits.
Fixes: bc044e8db796 ("udp: perform source validation for mcast early demux")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/udp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2495,7 +2495,8 @@ int udp_v4_early_demux(struct sk_buff *s
*/
if (!inet_sk(sk)->inet_daddr && in_dev)
return ip_mc_validate_source(skb, iph->daddr,
- iph->saddr, iph->tos,
+ iph->saddr,
+ iph->tos & IPTOS_RT_MASK,
skb->dev, in_dev, &itag);
}
return 0;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 78/86] ipv6: create multicast route with RTPROT_KERNEL
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2021-01-25 18:39 ` [PATCH 5.4 77/86] udp: mask TOS bits in udp_v4_early_demux() Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 79/86] net_sched: avoid shift-out-of-bounds in tcindex_set_parms() Greg Kroah-Hartman
` (10 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Matteo Croce, Jakub Kicinski
From: Matteo Croce <mcroce@microsoft.com>
commit a826b04303a40d52439aa141035fca5654ccaccd upstream.
The ff00::/8 multicast route is created without specifying the fc_protocol
field, so the default RTPROT_BOOT value is used:
$ ip -6 -d route
unicast ::1 dev lo proto kernel scope global metric 256 pref medium
unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium
As the documentation says, this value identifies routes installed during
boot, but the route is created when interface is set up.
Change the value to RTPROT_KERNEL which is a better value.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/addrconf.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2454,6 +2454,7 @@ static void addrconf_add_mroute(struct n
.fc_flags = RTF_UP,
.fc_type = RTN_UNICAST,
.fc_nlinfo.nl_net = dev_net(dev),
+ .fc_protocol = RTPROT_KERNEL,
};
ipv6_addr_set(&cfg.fc_dst, htonl(0xFF000000), 0, 0, 0);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 79/86] net_sched: avoid shift-out-of-bounds in tcindex_set_parms()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 78/86] ipv6: create multicast route with RTPROT_KERNEL Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 80/86] net_sched: reject silly cell_log in qdisc_get_rtab() Greg Kroah-Hartman
` (9 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, syzbot, Jakub Kicinski
From: Eric Dumazet <edumazet@google.com>
commit bcd0cf19ef8258ac31b9a20248b05c15a1f4b4b0 upstream.
tc_index being 16bit wide, we need to check that TCA_TCINDEX_SHIFT
attribute is not silly.
UBSAN: shift-out-of-bounds in net/sched/cls_tcindex.c:260:29
shift exponent 255 is too large for 32-bit type 'int'
CPU: 0 PID: 8516 Comm: syz-executor228 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
valid_perfect_hash net/sched/cls_tcindex.c:260 [inline]
tcindex_set_parms.cold+0x1b/0x215 net/sched/cls_tcindex.c:425
tcindex_change+0x232/0x340 net/sched/cls_tcindex.c:546
tc_new_tfilter+0x13fb/0x21b0 net/sched/cls_api.c:2127
rtnetlink_rcv_msg+0x8b6/0xb80 net/core/rtnetlink.c:5555
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:672
____sys_sendmsg+0x6e8/0x810 net/socket.c:2336
___sys_sendmsg+0xf3/0x170 net/socket.c:2390
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2423
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Link: https://lore.kernel.org/r/20210114185229.1742255-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/cls_tcindex.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -366,9 +366,13 @@ tcindex_set_parms(struct net *net, struc
if (tb[TCA_TCINDEX_MASK])
cp->mask = nla_get_u16(tb[TCA_TCINDEX_MASK]);
- if (tb[TCA_TCINDEX_SHIFT])
+ if (tb[TCA_TCINDEX_SHIFT]) {
cp->shift = nla_get_u32(tb[TCA_TCINDEX_SHIFT]);
-
+ if (cp->shift > 16) {
+ err = -EINVAL;
+ goto errout;
+ }
+ }
if (!cp->hash) {
/* Hash not specified, use perfect hash if the upper limit
* of the hashing index is below the threshold.
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 80/86] net_sched: reject silly cell_log in qdisc_get_rtab()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 79/86] net_sched: avoid shift-out-of-bounds in tcindex_set_parms() Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 81/86] ipv6: set multicast flag on the multicast route Greg Kroah-Hartman
` (8 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, syzbot, Cong Wang,
Jakub Kicinski
From: Eric Dumazet <edumazet@google.com>
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream.
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too large for 32-bit type 'int'
CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x183/0x22e lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:148 [inline]
__ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395
__detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389
qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435
cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180
qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246
tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662
rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg net/socket.c:672 [inline]
____sys_sendmsg+0x5a2/0x900 net/socket.c:2345
___sys_sendmsg net/socket.c:2399 [inline]
__sys_sendmsg+0x319/0x400 net/socket.c:2432
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Cong Wang <cong.wang@bytedance.com>
Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/sch_api.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -409,7 +409,8 @@ struct qdisc_rate_table *qdisc_get_rtab(
{
struct qdisc_rate_table *rtab;
- if (tab == NULL || r->rate == 0 || r->cell_log == 0 ||
+ if (tab == NULL || r->rate == 0 ||
+ r->cell_log == 0 || r->cell_log >= 32 ||
nla_len(tab) != TC_RTAB_SIZE) {
NL_SET_ERR_MSG(extack, "Invalid rate table parameters for searching");
return NULL;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 81/86] ipv6: set multicast flag on the multicast route
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 80/86] net_sched: reject silly cell_log in qdisc_get_rtab() Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 82/86] net: mscc: ocelot: allow offloading of bridge on top of LAG Greg Kroah-Hartman
` (7 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Matteo Croce, Jakub Kicinski
From: Matteo Croce <mcroce@microsoft.com>
commit ceed9038b2783d14e0422bdc6fd04f70580efb4c upstream.
The multicast route ff00::/8 is created with type RTN_UNICAST:
$ ip -6 -d route
unicast ::1 dev lo proto kernel scope global metric 256 pref medium
unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
unicast ff00::/8 dev eth0 proto kernel scope global metric 256 pref medium
Set the type to RTN_MULTICAST which is more appropriate.
Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info")
Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/addrconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2452,7 +2452,7 @@ static void addrconf_add_mroute(struct n
.fc_ifindex = dev->ifindex,
.fc_dst_len = 8,
.fc_flags = RTF_UP,
- .fc_type = RTN_UNICAST,
+ .fc_type = RTN_MULTICAST,
.fc_nlinfo.nl_net = dev_net(dev),
.fc_protocol = RTPROT_KERNEL,
};
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 82/86] net: mscc: ocelot: allow offloading of bridge on top of LAG
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (80 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 81/86] ipv6: set multicast flag on the multicast route Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 83/86] net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled Greg Kroah-Hartman
` (6 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Alexandre Belloni,
Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit 79267ae22615496655feee2db0848f6786bcf67a upstream.
The blamed commit was too aggressive, and it made ocelot_netdevice_event
react only to network interface events emitted for the ocelot switch
ports.
In fact, only the PRECHANGEUPPER should have had that check.
When we ignore all events that are not for us, we miss the fact that the
upper of the LAG changes, and the bonding interface gets enslaved to a
bridge. This is an operation we could offload under certain conditions.
Fixes: 7afb3e575e5a ("net: mscc: ocelot: don't handle netdev events for other netdevs")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210118135210.2666246-1-olteanv@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mscc/ocelot.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1716,10 +1716,8 @@ static int ocelot_netdevice_event(struct
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
int ret = 0;
- if (!ocelot_netdevice_dev_check(dev))
- return 0;
-
if (event == NETDEV_PRECHANGEUPPER &&
+ ocelot_netdevice_dev_check(dev) &&
netif_is_lag_master(info->upper_dev)) {
struct netdev_lag_upper_info *lag_upper_info = info->upper_info;
struct netlink_ext_ack *extack;
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 83/86] net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (81 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 82/86] net: mscc: ocelot: allow offloading of bridge on top of LAG Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 84/86] net: dsa: b53: fix an off by one in checking "vlan->vid" Greg Kroah-Hartman
` (5 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tariq Toukan, Boris Pismenny, Jakub Kicinski
From: Tariq Toukan <tariqt@nvidia.com>
commit a3eb4e9d4c9218476d05c52dfd2be3d6fdce6b91 upstream.
With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be
logically done when RXCSUM offload is off.
Fixes: 14136564c8ee ("net: Add TLS RX offload feature")
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Boris Pismenny <borisp@nvidia.com>
Link: https://lore.kernel.org/r/20210117151538.9411-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8692,6 +8692,11 @@ static netdev_features_t netdev_fix_feat
}
}
+ if ((features & NETIF_F_HW_TLS_RX) && !(features & NETIF_F_RXCSUM)) {
+ netdev_dbg(dev, "Dropping TLS RX HW offload feature since no RXCSUM feature.\n");
+ features &= ~NETIF_F_HW_TLS_RX;
+ }
+
return features;
}
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 84/86] net: dsa: b53: fix an off by one in checking "vlan->vid"
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (82 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 83/86] net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 85/86] tcp: do not mess with cloned skbs in tcp_add_backlog() Greg Kroah-Hartman
` (4 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Florian Fainelli,
Jakub Kicinski
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 8e4052c32d6b4b39c1e13c652c7e33748d447409 upstream.
The > comparison should be >= to prevent accessing one element beyond
the end of the dev->vlans[] array in the caller function, b53_vlan_add().
The "dev->vlans" array is allocated in the b53_switch_init() function
and it has "dev->num_vlans" elements.
Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1330,7 +1330,7 @@ int b53_vlan_prepare(struct dsa_switch *
if ((is5325(dev) || is5365(dev)) && vlan->vid_begin == 0)
return -EOPNOTSUPP;
- if (vlan->vid_end > dev->num_vlans)
+ if (vlan->vid_end >= dev->num_vlans)
return -ERANGE;
b53_enable_vlan(dev, true, ds->vlan_filtering);
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 85/86] tcp: do not mess with cloned skbs in tcp_add_backlog()
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (83 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 84/86] net: dsa: b53: fix an off by one in checking "vlan->vid" Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 18:40 ` [PATCH 5.4 86/86] tcp: fix TCP_USER_TIMEOUT with zero window Greg Kroah-Hartman
` (3 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Juerg Haefliger,
Heiner Kallweit, Jakub Kicinski
From: Eric Dumazet <edumazet@google.com>
commit b160c28548bc0a87cbd16d5af6d3edcfd70b8c9a upstream.
Heiner Kallweit reported that some skbs were sent with
the following invalid GSO properties :
- gso_size > 0
- gso_type == 0
This was triggerring a WARN_ON_ONCE() in rtl8169_tso_csum_v2.
Juerg Haefliger was able to reproduce a similar issue using
a lan78xx NIC and a workload mixing TCP incoming traffic
and forwarded packets.
The problem is that tcp_add_backlog() is writing
over gso_segs and gso_size even if the incoming packet will not
be coalesced to the backlog tail packet.
While skb_try_coalesce() would bail out if tail packet is cloned,
this overwriting would lead to corruptions of other packets
cooked by lan78xx, sharing a common super-packet.
The strategy used by lan78xx is to use a big skb, and split
it into all received packets using skb_clone() to avoid copies.
The drawback of this strategy is that all the small skb share a common
struct skb_shared_info.
This patch rewrites TCP gso_size/gso_segs handling to only
happen on the tail skb, since skb_try_coalesce() made sure
it was not cloned.
Fixes: 4f693b55c3d2 ("tcp: implement coalescing on backlog queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Bisected-by: Juerg Haefliger <juergh@canonical.com>
Tested-by: Juerg Haefliger <juergh@canonical.com>
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209423
Link: https://lore.kernel.org/r/20210119164900.766957-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/tcp_ipv4.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1657,6 +1657,7 @@ int tcp_v4_early_demux(struct sk_buff *s
bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb)
{
u32 limit = READ_ONCE(sk->sk_rcvbuf) + READ_ONCE(sk->sk_sndbuf);
+ u32 tail_gso_size, tail_gso_segs;
struct skb_shared_info *shinfo;
const struct tcphdr *th;
struct tcphdr *thtail;
@@ -1664,6 +1665,7 @@ bool tcp_add_backlog(struct sock *sk, st
unsigned int hdrlen;
bool fragstolen;
u32 gso_segs;
+ u32 gso_size;
int delta;
/* In case all data was pulled from skb frags (in __pskb_pull_tail()),
@@ -1689,13 +1691,6 @@ bool tcp_add_backlog(struct sock *sk, st
*/
th = (const struct tcphdr *)skb->data;
hdrlen = th->doff * 4;
- shinfo = skb_shinfo(skb);
-
- if (!shinfo->gso_size)
- shinfo->gso_size = skb->len - hdrlen;
-
- if (!shinfo->gso_segs)
- shinfo->gso_segs = 1;
tail = sk->sk_backlog.tail;
if (!tail)
@@ -1718,6 +1713,15 @@ bool tcp_add_backlog(struct sock *sk, st
goto no_coalesce;
__skb_pull(skb, hdrlen);
+
+ shinfo = skb_shinfo(skb);
+ gso_size = shinfo->gso_size ?: skb->len;
+ gso_segs = shinfo->gso_segs ?: 1;
+
+ shinfo = skb_shinfo(tail);
+ tail_gso_size = shinfo->gso_size ?: (tail->len - hdrlen);
+ tail_gso_segs = shinfo->gso_segs ?: 1;
+
if (skb_try_coalesce(tail, skb, &fragstolen, &delta)) {
TCP_SKB_CB(tail)->end_seq = TCP_SKB_CB(skb)->end_seq;
@@ -1744,11 +1748,8 @@ bool tcp_add_backlog(struct sock *sk, st
}
/* Not as strict as GRO. We only need to carry mss max value */
- skb_shinfo(tail)->gso_size = max(shinfo->gso_size,
- skb_shinfo(tail)->gso_size);
-
- gso_segs = skb_shinfo(tail)->gso_segs + shinfo->gso_segs;
- skb_shinfo(tail)->gso_segs = min_t(u32, gso_segs, 0xFFFF);
+ shinfo->gso_size = max(gso_size, tail_gso_size);
+ shinfo->gso_segs = min_t(u32, gso_segs + tail_gso_segs, 0xFFFF);
sk->sk_backlog.len += delta;
__NET_INC_STATS(sock_net(sk),
^ permalink raw reply [flat|nested] 91+ messages in thread* [PATCH 5.4 86/86] tcp: fix TCP_USER_TIMEOUT with zero window
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (84 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 85/86] tcp: do not mess with cloned skbs in tcp_add_backlog() Greg Kroah-Hartman
@ 2021-01-25 18:40 ` Greg Kroah-Hartman
2021-01-25 19:44 ` [PATCH 5.4 00/86] 5.4.93-rc1 review Daniel Díaz
` (2 subsequent siblings)
88 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2021-01-25 18:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, William McCall, Neal Cardwell,
Enke Chen, Yuchung Cheng, Eric Dumazet, Jakub Kicinski
From: Enke Chen <enchen@paloaltonetworks.com>
commit 9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac upstream.
The TCP session does not terminate with TCP_USER_TIMEOUT when data
remain untransmitted due to zero window.
The number of unanswered zero-window probes (tcp_probes_out) is
reset to zero with incoming acks irrespective of the window size,
as described in tcp_probe_timer():
RFC 1122 4.2.2.17 requires the sender to stay open indefinitely
as long as the receiver continues to respond probes. We support
this by default and reset icsk_probes_out with incoming ACKs.
This counter, however, is the wrong one to be used in calculating the
duration that the window remains closed and data remain untransmitted.
Thanks to Jonathan Maxwell <jmaxwell37@gmail.com> for diagnosing the
actual issue.
In this patch a new timestamp is introduced for the socket in order to
track the elapsed time for the zero-window probes that have not been
answered with any non-zero window ack.
Fixes: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT")
Reported-by: William McCall <william.mccall@gmail.com>
Co-developed-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Reviewed-by: Yuchung Cheng <ycheng@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20210115223058.GA39267@localhost.localdomain
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/inet_connection_sock.h | 3 +++
net/ipv4/inet_connection_sock.c | 1 +
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_input.c | 1 +
net/ipv4/tcp_output.c | 1 +
net/ipv4/tcp_timer.c | 14 +++++++-------
6 files changed, 14 insertions(+), 7 deletions(-)
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -83,6 +83,8 @@ struct inet_connection_sock_af_ops {
* @icsk_ext_hdr_len: Network protocol overhead (IP/IPv6 options)
* @icsk_ack: Delayed ACK control data
* @icsk_mtup; MTU probing control data
+ * @icsk_probes_tstamp: Probe timestamp (cleared by non-zero window ack)
+ * @icsk_user_timeout: TCP_USER_TIMEOUT value
*/
struct inet_connection_sock {
/* inet_sock has to be the first member! */
@@ -133,6 +135,7 @@ struct inet_connection_sock {
u32 probe_timestamp;
} icsk_mtup;
+ u32 icsk_probes_tstamp;
u32 icsk_user_timeout;
u64 icsk_ca_priv[104 / sizeof(u64)];
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -840,6 +840,7 @@ struct sock *inet_csk_clone_lock(const s
newicsk->icsk_retransmits = 0;
newicsk->icsk_backoff = 0;
newicsk->icsk_probes_out = 0;
+ newicsk->icsk_probes_tstamp = 0;
/* Deinitialize accept_queue to trap illegal accesses. */
memset(&newicsk->icsk_accept_queue, 0, sizeof(newicsk->icsk_accept_queue));
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2627,6 +2627,7 @@ int tcp_disconnect(struct sock *sk, int
icsk->icsk_backoff = 0;
tp->snd_cwnd = 2;
icsk->icsk_probes_out = 0;
+ icsk->icsk_probes_tstamp = 0;
icsk->icsk_rto = TCP_TIMEOUT_INIT;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd = TCP_INIT_CWND;
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3286,6 +3286,7 @@ static void tcp_ack_probe(struct sock *s
return;
if (!after(TCP_SKB_CB(head)->end_seq, tcp_wnd_end(tp))) {
icsk->icsk_backoff = 0;
+ icsk->icsk_probes_tstamp = 0;
inet_csk_clear_xmit_timer(sk, ICSK_TIME_PROBE0);
/* Socket must be waked up by subsequent tcp_data_snd_check().
* This function is not for random using!
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3835,6 +3835,7 @@ void tcp_send_probe0(struct sock *sk)
/* Cancel probe timer, if it is not required. */
icsk->icsk_probes_out = 0;
icsk->icsk_backoff = 0;
+ icsk->icsk_probes_tstamp = 0;
return;
}
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -344,6 +344,7 @@ static void tcp_probe_timer(struct sock
if (tp->packets_out || !skb) {
icsk->icsk_probes_out = 0;
+ icsk->icsk_probes_tstamp = 0;
return;
}
@@ -355,13 +356,12 @@ static void tcp_probe_timer(struct sock
* corresponding system limit. We also implement similar policy when
* we use RTO to probe window in tcp_retransmit_timer().
*/
- if (icsk->icsk_user_timeout) {
- u32 elapsed = tcp_model_timeout(sk, icsk->icsk_probes_out,
- tcp_probe0_base(sk));
-
- if (elapsed >= icsk->icsk_user_timeout)
- goto abort;
- }
+ if (!icsk->icsk_probes_tstamp)
+ icsk->icsk_probes_tstamp = tcp_jiffies32;
+ else if (icsk->icsk_user_timeout &&
+ (s32)(tcp_jiffies32 - icsk->icsk_probes_tstamp) >=
+ msecs_to_jiffies(icsk->icsk_user_timeout))
+ goto abort;
max_probes = sock_net(sk)->ipv4.sysctl_tcp_retries2;
if (sock_flag(sk, SOCK_DEAD)) {
^ permalink raw reply [flat|nested] 91+ messages in thread* Re: [PATCH 5.4 00/86] 5.4.93-rc1 review
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (85 preceding siblings ...)
2021-01-25 18:40 ` [PATCH 5.4 86/86] tcp: fix TCP_USER_TIMEOUT with zero window Greg Kroah-Hartman
@ 2021-01-25 19:44 ` Daniel Díaz
2021-01-26 10:47 ` Jon Hunter
2021-01-26 10:48 ` Jon Hunter
88 siblings, 0 replies; 91+ messages in thread
From: Daniel Díaz @ 2021-01-25 19:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: shuah, patches, lkft-triage, stable, pavel, akpm, torvalds, linux
Hello!
On 1/25/21 12:38 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.93 release.
> There are 86 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 27 Jan 2021 18:31:44 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.93-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Sanity results from Linaro’s test farm.
Regressions detected.
Summary
------------------------------------------------------------------------
kernel: 5.4.93-rc1
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git branch: linux-5.4.y
git commit: 3deaa28e41d9780b3b462686a676fa1d21f55ad3
git describe: v5.4.92-87-g3deaa28e41d9
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y-sanity/build/v5.4.92-87-g3deaa28e41d9
Regressions (compared to build v5.4.92)
------------------------------------------------------------------------
x86_64:
build:
* clang-10-allnoconfig
* clang-10-tinyconfig
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig
riscv:
build:
* clang-10-defconfig
* clang-11-defconfig
* gcc-8-defconfig
* gcc-9-defconfig
* gcc-10-defconfig
i386:
build:
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig
No fixes (compared to build v5.4.92)
Ran 665 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- i386
- juno-r2
- mips
- parisc
- powerpc
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86_64
Test Suites
-----------
* build
* linux-log-parser
* ltp-smoketest-tests
i386 and x86_64 errors as reported on 5.10. Additionally, RISC-V errors look like this:
make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- 'CC=sccache riscv64-linux-gnu-gcc' 'HOSTCC=sccache gcc'
Error: /builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts:88.27-28 syntax error
FATAL ERROR: Unable to parse input tree
make[3]: *** [scripts/Makefile.lib:285: arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [/builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/scripts/Makefile.build:496: arch/riscv/boot/dts/sifive] Error 2
make[2]: Target '__build' not remade because of errors.
make[1]: *** [/builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/Makefile:1272: dtbs] Error 2
We'll try to get more info.
Greetings!
Daniel Díaz
daniel.diaz@linaro.org
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 91+ messages in thread* Re: [PATCH 5.4 00/86] 5.4.93-rc1 review
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (86 preceding siblings ...)
2021-01-25 19:44 ` [PATCH 5.4 00/86] 5.4.93-rc1 review Daniel Díaz
@ 2021-01-26 10:47 ` Jon Hunter
2021-01-26 10:48 ` Jon Hunter
88 siblings, 0 replies; 91+ messages in thread
From: Jon Hunter @ 2021-01-26 10:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, stable, linux-tegra
On Mon, 25 Jan 2021 19:38:42 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.93 release.
> There are 86 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 27 Jan 2021 18:31:44 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.93-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
12 builds: 12 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 fail
Linux version: 5.4.93-rc1-g3deaa28e41d9
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 91+ messages in thread* Re: [PATCH 5.4 00/86] 5.4.93-rc1 review
2021-01-25 18:38 [PATCH 5.4 00/86] 5.4.93-rc1 review Greg Kroah-Hartman
` (87 preceding siblings ...)
2021-01-26 10:47 ` Jon Hunter
@ 2021-01-26 10:48 ` Jon Hunter
88 siblings, 0 replies; 91+ messages in thread
From: Jon Hunter @ 2021-01-26 10:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, stable, linux-tegra
On Mon, 25 Jan 2021 19:38:42 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.93 release.
> There are 86 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 27 Jan 2021 18:31:44 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.93-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
12 builds: 12 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 fail
Linux version: 5.4.93-rc1-g3deaa28e41d9
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 91+ messages in thread