This is the start of the stable review cycle for the 5.16.2 release.
There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.16.2-rc1
Takashi Iwai <[email protected]>
ALSA: hda/realtek: Re-order quirk entries for Lenovo
Baole Fang <[email protected]>
ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
Sameer Pujar <[email protected]>
ALSA: hda/tegra: Fix Tegra194 HDA reset failure
Bart Kroon <[email protected]>
ALSA: hda: ALC287: Add Lenovo IdeaPad Slim 9i 14ITL5 speaker quirk
Christian Lachner <[email protected]>
ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master after reboot from Windows
Kai-Heng Feng <[email protected]>
ALSA: hda/realtek: Use ALC285_FIXUP_HP_GPIO_LED on another HP laptop
Arie Geiger <[email protected]>
ALSA: hda/realtek: Add speaker fixup for some Yoga 15ITL5 devices
Dario Petrillo <[email protected]>
perf annotate: Avoid TUI crash when navigating in the annotation of recursive functions
Johan Hovold <[email protected]>
firmware: qemu_fw_cfg: fix kobject leak in probe error path
Johan Hovold <[email protected]>
firmware: qemu_fw_cfg: fix NULL-pointer deref on duplicate entries
Johan Hovold <[email protected]>
firmware: qemu_fw_cfg: fix sysfs information leak
Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled
Johan Hovold <[email protected]>
media: uvcvideo: fix division by zero at stream start
Javier Martinez Canillas <[email protected]>
video: vga16fb: Only probe for EGA and VGA 16 color graphic cards
Dominique Martinet <[email protected]>
9p: fix enodata when reading growing file
Christian Brauner <[email protected]>
9p: only copy valid iattrs in 9P2000.L setattr implementation
Chuck Lever <[email protected]>
NFSD: Fix zero-length NFSv3 WRITEs
Sibi Sankar <[email protected]>
remoteproc: qcom: pas: Add missing power-domain "mxc" for CDSP
Eric Farman <[email protected]>
KVM: s390: Clarify SIGP orders versus STOP/RESTART
Li RongQing <[email protected]>
KVM: x86: don't print when fail to read/write pv eoi memory
Sean Christopherson <[email protected]>
KVM: x86: Register Processor Trace interrupt hook iff PT enabled in guest
Sean Christopherson <[email protected]>
KVM: x86: Register perf callbacks after calling vendor's hardware_setup()
Sean Christopherson <[email protected]>
perf: Protect perf_guest_cbs with RCU
Jamie Hill-Daniel <[email protected]>
vfs: fs_context: fix up param length parsing in legacy_parse_param
Stephen Boyd <[email protected]>
remoteproc: qcom: pil_info: Don't memcpy_toio more than is provided
Christophe JAILLET <[email protected]>
orangefs: Fix the size of a memory allocation in orangefs_bufmap_alloc()
Mario Limonciello <[email protected]>
drm/amd/display: explicitly set is_dsc_supported to false before use
NeilBrown <[email protected]>
devtmpfs regression fix: reconfigure on each mount
-------------
Diffstat:
Makefile | 4 +-
arch/arm/kernel/perf_callchain.c | 17 ++++---
arch/arm64/kernel/perf_callchain.c | 18 +++++---
arch/csky/kernel/perf_callchain.c | 6 ++-
arch/nds32/kernel/perf_event_cpu.c | 17 ++++---
arch/riscv/kernel/perf_callchain.c | 7 ++-
arch/s390/kvm/interrupt.c | 7 +++
arch/s390/kvm/kvm-s390.c | 9 +++-
arch/s390/kvm/kvm-s390.h | 1 +
arch/s390/kvm/sigp.c | 28 ++++++++++++
arch/x86/events/core.c | 17 ++++---
arch/x86/events/intel/core.c | 9 ++--
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/lapic.c | 18 +++-----
arch/x86/kvm/vmx/vmx.c | 1 +
arch/x86/kvm/x86.c | 12 +++--
drivers/base/devtmpfs.c | 7 +++
drivers/firmware/qemu_fw_cfg.c | 20 ++++-----
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/media/usb/uvc/uvc_video.c | 4 ++
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 1 +
drivers/remoteproc/qcom_pil_info.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 1 +
drivers/video/fbdev/vga16fb.c | 24 ++++++++++
fs/9p/vfs_addr.c | 5 +++
fs/9p/vfs_inode_dotl.c | 29 ++++++++----
fs/fs_context.c | 2 +-
fs/nfsd/nfs3proc.c | 6 +--
fs/nfsd/nfsproc.c | 5 ---
fs/orangefs/orangefs-bufmap.c | 7 ++-
fs/super.c | 4 +-
include/linux/fs_context.h | 2 +
include/linux/perf_event.h | 13 +++++-
kernel/events/core.c | 13 ++++--
sound/pci/hda/hda_tegra.c | 43 ++++++++++++++----
sound/pci/hda/patch_realtek.c | 52 ++++++++++++++++++++--
tools/perf/ui/browsers/annotate.c | 23 ++++++----
37 files changed, 321 insertions(+), 115 deletions(-)
From: Bart Kroon <[email protected]>
commit b81e9e5c723de936652653241d3dc4f33ae05e8c upstream.
The speaker fixup that is used for the Yoga 7 14ITL5 also applies to
the IdeaPad Slim 9i 14ITL5. The attached patch applies the quirk to
initialise the amplifier on the IdeaPad Slim 9i as well.
This is validated to work on my laptop.
[ corrected the quirk entry position by tiwai ]
Signed-off-by: Bart Kroon <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8952,6 +8952,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x17aa, 0x31af, "ThinkCentre Station", ALC623_FIXUP_LENOVO_THINKSTATION_P340),
SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940", ALC298_FIXUP_LENOVO_SPK_VOLUME),
SND_PCI_QUIRK(0x17aa, 0x3827, "Ideapad S740", ALC285_FIXUP_IDEAPAD_S740_COEF),
+ SND_PCI_QUIRK(0x17aa, 0x3834, "Lenovo IdeaPad Slim 9i 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3843, "Yoga 9i", ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP),
SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
From: Arie Geiger <[email protected]>
commit 6dc86976220cc904e87ee58e4be19dd90d6a36d5 upstream.
This patch adds another possible subsystem ID for the ALC287 used by
the Lenovo Yoga 15ITL5.
It uses the same initalization as the others.
This patch has been tested and works for my device.
Signed-off-by: Arie Geiger <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8927,6 +8927,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3853, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
+ SND_PCI_QUIRK(0x17aa, 0x384a, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3819, "Lenovo 13s Gen2 ITL", ALC287_FIXUP_13S_GEN2_SPEAKERS),
SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
From: Sameer Pujar <[email protected]>
commit d278dc9151a034674b31ffeda24cdfb0073570f3 upstream.
HDA regression is recently reported on Tegra194 based platforms.
This happens because "hda2codec_2x" reset does not really exist
in Tegra194 and it causes probe failure. All the HDA based audio
tests fail at the moment. This underlying issue is exposed by
commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
response") which now checks return code of BPMP command response.
Fix this issue by skipping unavailable reset on Tegra194.
Cc: [email protected]
Signed-off-by: Sameer Pujar <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/hda_tegra.c | 43 ++++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)
--- a/sound/pci/hda/hda_tegra.c
+++ b/sound/pci/hda/hda_tegra.c
@@ -68,14 +68,20 @@
*/
#define TEGRA194_NUM_SDO_LINES 4
+struct hda_tegra_soc {
+ bool has_hda2codec_2x_reset;
+};
+
struct hda_tegra {
struct azx chip;
struct device *dev;
- struct reset_control *reset;
+ struct reset_control_bulk_data resets[3];
struct clk_bulk_data clocks[3];
+ unsigned int nresets;
unsigned int nclocks;
void __iomem *regs;
struct work_struct probe_work;
+ const struct hda_tegra_soc *soc;
};
#ifdef CONFIG_PM
@@ -170,7 +176,7 @@ static int __maybe_unused hda_tegra_runt
int rc;
if (!chip->running) {
- rc = reset_control_assert(hda->reset);
+ rc = reset_control_bulk_assert(hda->nresets, hda->resets);
if (rc)
return rc;
}
@@ -187,7 +193,7 @@ static int __maybe_unused hda_tegra_runt
} else {
usleep_range(10, 100);
- rc = reset_control_deassert(hda->reset);
+ rc = reset_control_bulk_deassert(hda->nresets, hda->resets);
if (rc)
return rc;
}
@@ -427,9 +433,17 @@ static int hda_tegra_create(struct snd_c
return 0;
}
+static const struct hda_tegra_soc tegra30_data = {
+ .has_hda2codec_2x_reset = true,
+};
+
+static const struct hda_tegra_soc tegra194_data = {
+ .has_hda2codec_2x_reset = false,
+};
+
static const struct of_device_id hda_tegra_match[] = {
- { .compatible = "nvidia,tegra30-hda" },
- { .compatible = "nvidia,tegra194-hda" },
+ { .compatible = "nvidia,tegra30-hda", .data = &tegra30_data },
+ { .compatible = "nvidia,tegra194-hda", .data = &tegra194_data },
{},
};
MODULE_DEVICE_TABLE(of, hda_tegra_match);
@@ -449,6 +463,8 @@ static int hda_tegra_probe(struct platfo
hda->dev = &pdev->dev;
chip = &hda->chip;
+ hda->soc = of_device_get_match_data(&pdev->dev);
+
err = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,
THIS_MODULE, 0, &card);
if (err < 0) {
@@ -456,11 +472,20 @@ static int hda_tegra_probe(struct platfo
return err;
}
- hda->reset = devm_reset_control_array_get_exclusive(&pdev->dev);
- if (IS_ERR(hda->reset)) {
- err = PTR_ERR(hda->reset);
+ hda->resets[hda->nresets++].id = "hda";
+ hda->resets[hda->nresets++].id = "hda2hdmi";
+ /*
+ * "hda2codec_2x" reset is not present on Tegra194. Though DT would
+ * be updated to reflect this, but to have backward compatibility
+ * below is necessary.
+ */
+ if (hda->soc->has_hda2codec_2x_reset)
+ hda->resets[hda->nresets++].id = "hda2codec_2x";
+
+ err = devm_reset_control_bulk_get_exclusive(&pdev->dev, hda->nresets,
+ hda->resets);
+ if (err)
goto out_free;
- }
hda->clocks[hda->nclocks++].id = "hda";
hda->clocks[hda->nclocks++].id = "hda2hdmi";
From: Christian Lachner <[email protected]>
commit c1933008679586b20437280463110c967d66f865 upstream.
This patch addresses an issue where after rebooting from Windows into Linux
there would be no audio output.
It turns out that the Realtek Audio driver on Windows changes some coeffs
which are not being reset/reinitialized when rebooting the machine. As a
result, there is no audio output until these coeffs are being reset to
their initial state. This patch takes care of that by setting known-good
(initial) values to the coeffs.
We initially relied upon alc1220_fixup_clevo_p950() to fix some pins in the
connection list. However, it also sets coef 0x7 which does not need to be
touched. Furthermore, to prevent mixing device-specific quirks I introduced
a new alc1220_fixup_gb_x570() which is heavily based on
alc1220_fixup_clevo_p950() but does not set coeff 0x7 and fixes the coeffs
that are actually needed instead.
This new alc1220_fixup_gb_x570() is believed to also work for other boards,
like the Gigabyte X570 Aorus Extreme and the newer Gigabyte Aorus X570S
Master. However, as there is no way for me to test these I initially only
enable this new behaviour for the mainboard I have which is the Gigabyte
X570(non-S) Aorus Master.
I tested this patch on the 5.15 branch as well as on master and it is
working well for me.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
Signed-off-by: Christian Lachner <[email protected]>
Fixes: 0d45e86d2267d ("ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master")
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1924,6 +1924,7 @@ enum {
ALC887_FIXUP_ASUS_BASS,
ALC887_FIXUP_BASS_CHMAP,
ALC1220_FIXUP_GB_DUAL_CODECS,
+ ALC1220_FIXUP_GB_X570,
ALC1220_FIXUP_CLEVO_P950,
ALC1220_FIXUP_CLEVO_PB51ED,
ALC1220_FIXUP_CLEVO_PB51ED_PINS,
@@ -2113,6 +2114,29 @@ static void alc1220_fixup_gb_dual_codecs
}
}
+static void alc1220_fixup_gb_x570(struct hda_codec *codec,
+ const struct hda_fixup *fix,
+ int action)
+{
+ static const hda_nid_t conn1[] = { 0x0c };
+ static const struct coef_fw gb_x570_coefs[] = {
+ WRITE_COEF(0x1a, 0x01c1),
+ WRITE_COEF(0x1b, 0x0202),
+ WRITE_COEF(0x43, 0x3005),
+ {}
+ };
+
+ switch (action) {
+ case HDA_FIXUP_ACT_PRE_PROBE:
+ snd_hda_override_conn_list(codec, 0x14, ARRAY_SIZE(conn1), conn1);
+ snd_hda_override_conn_list(codec, 0x1b, ARRAY_SIZE(conn1), conn1);
+ break;
+ case HDA_FIXUP_ACT_INIT:
+ alc_process_coef_fw(codec, gb_x570_coefs);
+ break;
+ }
+}
+
static void alc1220_fixup_clevo_p950(struct hda_codec *codec,
const struct hda_fixup *fix,
int action)
@@ -2415,6 +2439,10 @@ static const struct hda_fixup alc882_fix
.type = HDA_FIXUP_FUNC,
.v.func = alc1220_fixup_gb_dual_codecs,
},
+ [ALC1220_FIXUP_GB_X570] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc1220_fixup_gb_x570,
+ },
[ALC1220_FIXUP_CLEVO_P950] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc1220_fixup_clevo_p950,
@@ -2517,7 +2545,7 @@ static const struct snd_pci_quirk alc882
SND_PCI_QUIRK(0x13fe, 0x1009, "Advantech MIT-W101", ALC886_FIXUP_EAPD),
SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte EP45-DS3/Z87X-UD3H", ALC889_FIXUP_FRONT_HP_NO_PRESENCE),
SND_PCI_QUIRK(0x1458, 0xa0b8, "Gigabyte AZ370-Gaming", ALC1220_FIXUP_GB_DUAL_CODECS),
- SND_PCI_QUIRK(0x1458, 0xa0cd, "Gigabyte X570 Aorus Master", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1458, 0xa0cd, "Gigabyte X570 Aorus Master", ALC1220_FIXUP_GB_X570),
SND_PCI_QUIRK(0x1458, 0xa0ce, "Gigabyte X570 Aorus Xtreme", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x11f7, "MSI-GE63", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1228, "MSI-GP63", ALC1220_FIXUP_CLEVO_P950),
On Tue, 2022-01-18 at 17:05 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
hello ,
Compiled and booted 5.16.2-rc1+ on VivoBook 15_ASUS Laptop X507UAR
.No Regression from dmesg, except an old warning
Tested-by: Jeffrin Jose T <[email protected]>
--
software engineer
rajagiri school of engineering and technology - autonomous
On 1/18/22 8:05 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On 1/18/22 9:05 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Tue, Jan 18, 2022 at 9:17 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Hi Greg,
Compiled and booted on my test system Lenovo P50s: Intel Core i7
No emergency and critical messages in the dmesg
I am going to be running perf bench sched from now on and I will
report any regressions
./perf bench sched all
# Running sched/messaging benchmark...
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 0.437 [sec]
# Running sched/pipe benchmark...
# Executed 1000000 pipe operations between two processes
Total time: 6.919 [sec]
6.919489 usecs/op
144519 ops/sec
Tested-by: Zan Aziz <[email protected]>
Thanks
-Zan
On Tue, 18 Jan 2022 at 21:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Following patch caused build regression for powerpc allnoconfig only on 5.16
with gcc-9.
5.16-powerpc-gcc-9-allnoconfig - FAIL
5.16-powerpc-gcc-10-allnoconfig - PASS
5.16-powerpc-gcc-11-allnoconfig - PASS
make --silent --keep-going --jobs=8 \
O=/home/tuxbuild/.cache/tuxmake/builds/current \
ARCH=powerpc \
CROSS_COMPILE=powerpc64le-linux-gnu- \
'CC=sccache powerpc64le-linux-gnu-gcc' \
'HOSTCC=sccache gcc'
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround
make[1]: *** [/builds/linux/Makefile:1161: vmlinux] Error 1
make[1]: *** Deleting file 'vmlinux'
> NeilBrown <[email protected]>
> devtmpfs regression fix: reconfigure on each mount
Bisect log:
# bad: [979dd812ffb543a3f6218868a26a701054ba3b8c] Linux 5.16.2-rc1
# good: [80820ae87cc8c09b828faa951f44b2396a5b48c4] drm/i915: Avoid
bitwise vs logical OR warning in snb_wm_latency_quirk()
git bisect start '979dd812ffb543a3f6218868a26a701054ba3b8c'
'80820ae87cc8c09b828faa951f44b2396a5b48c4'
# bad: [6cb89b83384df47b2def88870be10db707a77649] 9p: only copy valid
iattrs in 9P2000.L setattr implementation
git bisect bad 6cb89b83384df47b2def88870be10db707a77649
# bad: [041b83007bd86ba0e7275e348eb13df13df669ef] vfs: fs_context: fix
up param length parsing in legacy_parse_param
git bisect bad 041b83007bd86ba0e7275e348eb13df13df669ef
# bad: [a7458144427accc2b602a672b1f9435e00ba578e] devtmpfs regression
fix: reconfigure on each mount
git bisect bad a7458144427accc2b602a672b1f9435e00ba578e
# good: [5c245afa643712977fd0a9c70ffbb9df5dbf204b] parisc: Fix
pdc_toc_pim_11 and pdc_toc_pim_20 definitions
git bisect good 5c245afa643712977fd0a9c70ffbb9df5dbf204b
# good: [677615cd2689a0898dd58e51d12abe6663567b24] Linux 5.16.1
git bisect good 677615cd2689a0898dd58e51d12abe6663567b24
# first bad commit: [a7458144427accc2b602a672b1f9435e00ba578e]
devtmpfs regression fix: reconfigure on each mount
The first bad commit:
commit a7458144427accc2b602a672b1f9435e00ba578e
Author: NeilBrown <[email protected]>
Date: Mon Jan 17 09:07:26 2022 +1100
devtmpfs regression fix: reconfigure on each mount
commit a6097180d884ddab769fb25588ea8598589c218c upstream.
Prior to Linux v5.4 devtmpfs used mount_single() which treats the given
mount options as "remount" options, so it updates the configuration of
the single super_block on each mount.
Since that was changed, the mount options used for devtmpfs are ignored.
This is a regression which affect systemd - which mounts devtmpfs with
"-o mode=755,size=4m,nr_inodes=1m".
This patch restores the "remount" effect by calling reconfigure_single()
Fixes: d401727ea0d7 ("devtmpfs: don't mix
{ramfs,shmem}_fill_super() with mount_single()")
Acked-by: Christian Brauner <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
drivers/base/devtmpfs.c | 7 +++++++
fs/super.c | 4 ++--
include/linux/fs_context.h | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
you may compare build results here.
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.16.y/build/v5.16-67-g979dd812ffb5/testrun/7410428/suite/build/test/gcc-9-allnoconfig/history/
Reported-by: Linux Kernel Functional Testing <[email protected]>
--
Linaro LKFT
https://lkft.linaro.org
On Wed, Jan 19, 2022 at 9:30 AM Naresh Kamboju
<[email protected]> wrote:
>
> Inconsistent kallsyms data
This tends to be a "odd build environment" problem, and very very
random. Triggered by very particular compiler versions and just some
odd code modement details.
I'd suggest doing a completely clean build and disabling ccache, and
seeing if that makes it go away.
Linus
On 1/18/22 8:05 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <[email protected]>
On Tue, Jan 18, 2022 at 05:05:55PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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.
Hi Greg,
Looking good.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition: build tested on:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
Tested-by: Rudi Heitbaum <[email protected]>
--
Rudi
On Tue, 18 Jan 2022 at 21:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +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.16.2-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.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## Build
* kernel: 5.16.2-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.16.y
* git commit: 979dd812ffb543a3f6218868a26a701054ba3b8c
* git describe: v5.16-67-g979dd812ffb5
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.16.y/build/v5.16-67-g979dd812ffb5
## Test Regressions (compared to v5.16.1)
No test regressions found.
## Metric Regressions (compared to v5.16.1)
No metric regressions found.
## Test Fixes (compared to v5.16.1)
No test fixes found.
## Metric Fixes (compared to v5.16.1)
No metric fixes found.
## Test result summary
total: 95183, pass: 81363, fail: 867, skip: 12040, xfail: 913
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 263 total, 242 passed, 21 failed
* arm64: 42 total, 42 passed, 0 failed
* i386: 39 total, 36 passed, 3 failed
* mips: 37 total, 31 passed, 6 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 56 total, 48 passed, 8 failed
* riscv: 28 total, 24 passed, 4 failed
* s390: 22 total, 20 passed, 2 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x86_64: 42 total, 42 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-net
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
hallo Greg
5.16.2-rc1
compiles, boots, suspends on my x86_64
(Intel i5-11400, Fedora 35)
Thanks
Tested-by: Ronald Warsow <[email protected]>
regards
Ronald
On 1/18/22 11:53 PM, Linus Torvalds wrote:
> On Wed, Jan 19, 2022 at 9:30 AM Naresh Kamboju
> <[email protected]> wrote:
>>
>> Inconsistent kallsyms data
>
> This tends to be a "odd build environment" problem, and very very
> random. Triggered by very particular compiler versions and just some
> odd code modement details.
>
It happens once in a while depending on the compiler version and
on how symbols are arranged, and new compiler specific symbols showing up.
I had submitted a patch a while ago that kept retrying a few more times
before giving up (that was rejected). We carry a patch in ChromeOS kernels
which tells us what the offending symbols are in case we see the problem
in our builds.
> I'd suggest doing a completely clean build and disabling ccache, and
> seeing if that makes it go away.
>
My experience is that once it starts, it will show up randomly and become
more and more prevalent over time until almost all builds fail. powerpc
seems to be affected a lot by this problem, but we have also seen it
on x86. When that happens, someone has to go in and figure out the
offending symbol(s) and add it or them to some exception list.
Guenter
On Wed, 19 Jan 2022 at 09:00, Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Jan 19, 2022 at 9:30 AM Naresh Kamboju
> <[email protected]> wrote:
> >
> > Inconsistent kallsyms data
>
> This tends to be a "odd build environment" problem, and very very
> random. Triggered by very particular compiler versions and just some
> odd code modement details.
>
> I'd suggest doing a completely clean build and disabling ccache, and
> seeing if that makes it go away.
Clean build without ccache didn't help.
It seams that it fails randomly based on the size of the rodata section.
This could probably happen with another toolchain too, trying enough
configurations.
Diff of tmp_vmlinux.kallsyms2.symbols and
tmp_vmlinux.kallsyms3.symbols [1] show why it fails to converge, while
said that the __stop_notes address is on the page boundary, so
__end_rodata has the same value as __stop_notes.
All 3 tmp_vmlinux.kallsyms(1|2|3).symbols files can be found [2].
Inserting padding before __end_rodata [3], or blacklisting __stop_notes [4]
in kallsyms.c works around the problem, but neither of those seems like a
good fix.
The linker version I'm using are 'GNU ld (GNU Binutils for Debian) 2.35.2'.
Cheers,
Anders
[1] http://ix.io/3ML7
[2] https://people.linaro.org/~anders.roxell/kallsyms/
[3] http://ix.io/3MN2
[4] http://ix.io/3MN4
On Tue, Jan 18, 2022 at 05:05:55PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.16.2 release.
> There are 28 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 Thu, 20 Jan 2022 16:04:42 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 153 pass: 153 fail: 0
Qemu test results:
total: 485 pass: 485 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter