August 2024 - Linux-stable-mirror

Re: Bluetooth kernel BUG with Intel AX211 (regression in 6.1.83)

by Linux regression tracking (Thorsten Leemhuis)

Hi stable team (and Bluetooth maintainers), I noticed a regression report about a BT problem in 6.1.y: On 21.04.24 15:54, Jeremy Lainé wrote: > > After upgrading my kernel to Debian's latest version (6.1.85), I > started encountering systematic kernel BUGs at boot, making the > bluetooth stack unusable. I initially reported this to Debian's bug > tracker: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069301 > > .. but have since confirmed that this is reproducible with vanilla > kernels, including the latest 6.1.y version (6.1.87). > > I tried various kernel versions (straight from kernel.org) to pinpoint > when the problem started occurring and the resultats are: Jeremy later wrote: > # first bad commit: [6083089ab00631617f9eac678df3ab050a9d837a] > Bluetooth: hci_conn: Consolidate code for aborting connections https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… That's a13f316e90fdb1 ("Bluetooth: hci_conn: Consolidate code for aborting connections") [v6.6-rc1, v6.1.83 (6083089ab00631)] FWIW, there is a fix for the mainline commit under review: https://lore.kernel.org/all/20240411151929.403263-1-kovalev@altlinux.org/ But it is likely unrelated, as Jeremy later also wrote: > I'm now running 6.9-rc5 and have not been able to reproduce the issue, https://lore.kernel.org/all/CADRbXaA2yFjMo=_8_ZTubPbrrmWH9yx+aG5pUadnk395ko… Makes me wonder if 6.1.y is missing some other change a13f316e90fdb1 depends on. Ciao, Thorsten > I have included a trace below, and full system details are available > in the Debian bug listed above. Can you suggest any other tests I can > perform to help diagnose the origin of the problem? > > [ 22.660847] list_del corruption, ffff94d9f6302000->prev is > LIST_POISON2 (dead000000000122) > [ 22.660887] ------------[ cut here ]------------ > [ 22.660890] kernel BUG at lib/list_debug.c:56! > [ 22.660907] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI > [ 22.660917] CPU: 10 PID: 139 Comm: kworker/u25:0 Not tainted > 6.1.0-20-amd64 #1 Debian 6.1.85-1 > [ 22.660929] Hardware name: Dell Inc. XPS 9315/00KRKP, BIOS 1.19.1 03/14/2024 > [ 22.660936] Workqueue: hci0 hci_cmd_sync_work [bluetooth] > [ 22.661128] RIP: 0010:__list_del_entry_valid.cold+0x4b/0x6f > [ 22.661147] Code: fe ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 48 18 7a > 9f e8 14 a1 fe ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 10 18 7a 9f e8 00 > a1 fe ff <0f> 0b 48 89 fe 48 c7 c7 d8 17 7a 9f e8 ef a0 fe ff 0f 0b 48 > 89 fe > [ 22.661156] RSP: 0000:ffffae0e406efde0 EFLAGS: 00010246 > [ 22.661164] RAX: 000000000000004e RBX: ffff94d9f6302000 RCX: 0000000000000027 > [ 22.661172] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff94dfaf8a03a0 > [ 22.661177] RBP: ffff94d859392000 R08: 0000000000000000 R09: ffffae0e406efc78 > [ 22.661182] R10: 0000000000000003 R11: ffffffff9fed4448 R12: ffff94d859392000 > [ 22.661187] R13: ffff94d859392770 R14: ffff94d858cb9800 R15: dead000000000100 > [ 22.661194] FS: 0000000000000000(0000) GS:ffff94dfaf880000(0000) > knlGS:0000000000000000 > [ 22.661202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 22.661208] CR2: 00007f423c024038 CR3: 0000000799c04000 CR4: 0000000000750ee0 > [ 22.661214] PKRU: 55555554 > [ 22.661218] Call Trace: > [ 22.661225] <TASK> > [ 22.661232] ? __die_body.cold+0x1a/0x1f > [ 22.661246] ? die+0x2a/0x50 > [ 22.661257] ? do_trap+0xc5/0x110 > [ 22.661268] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661279] ? do_error_trap+0x6a/0x90 > [ 22.661289] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661298] ? exc_invalid_op+0x4c/0x60 > [ 22.661307] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661316] ? asm_exc_invalid_op+0x16/0x20 > [ 22.661328] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661337] hci_conn_del+0x136/0x3e0 [bluetooth] > [ 22.661466] hci_abort_conn_sync+0xaa/0x230 [bluetooth] > [ 22.661632] ? abort_conn_sync+0x3d/0x70 [bluetooth] > [ 22.661751] hci_cmd_sync_work+0x9f/0x150 [bluetooth] > [ 22.661915] process_one_work+0x1c4/0x380 > [ 22.661929] worker_thread+0x4d/0x380 > [ 22.661940] ? rescuer_thread+0x3a0/0x3a0 > [ 22.661950] kthread+0xd7/0x100 > [ 22.661959] ? kthread_complete_and_exit+0x20/0x20 > [ 22.661969] ret_from_fork+0x1f/0x30 > [ 22.661984] </TASK> > [ 22.661987] Modules linked in: ctr ccm nft_chain_nat xt_MASQUERADE > nf_nat nf_conntrack_netlink br_netfilter bridge stp llc xfrm_user > xfrm_algo nvme_fabrics rfcomm snd_seq_dummy snd_hrtimer snd_seq > snd_seq_device cmac algif_hash algif_skcipher af_alg snd_ctl_led > snd_soc_sof_sdw snd_soc_intel_hda_dsp_common snd_sof_probes > snd_soc_intel_sof_maxim_common snd_soc_rt715_sdca snd_soc_rt1316_sdw > regmap_sdw_mbq snd_hda_codec_hdmi regmap_sdw overlay ip6t_REJECT > nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 > xt_LOG qrtr nf_log_syslog nft_limit bnep ipmi_devintf ipmi_msghandler > xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables libcrc32c nfnetlink > binfmt_misc nls_ascii nls_cp437 vfat fat x86_pkg_temp_thermal > intel_powerclamp coretemp snd_soc_dmic snd_sof_pci_intel_tgl > snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation > soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp > snd_sof snd_sof_utils > [ 22.662122] snd_soc_hdac_hda snd_hda_ext_core > snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core kvm_intel > snd_compress btusb soundwire_bus btrtl kvm btbcm snd_hda_intel btintel > snd_intel_dspcfg btmtk dell_laptop snd_intel_sdw_acpi irqbypass > ledtrig_audio bluetooth snd_hda_codec i915 snd_hda_core rapl mei_hdcp > intel_rapl_msr snd_hwdep processor_thermal_device_pci dell_wmi joydev > hid_sensor_als intel_cstate jitterentropy_rng processor_thermal_device > snd_pcm hid_sensor_trigger processor_thermal_rfim dell_smbios > ucsi_acpi dcdbas hid_sensor_iio_common processor_thermal_mbox > drm_buddy intel_uncore iwlmvm pcspkr drbg iTCO_wdt typec_ucsi > dell_wmi_sysman snd_timer industrialio_triggered_buffer > drm_display_helper processor_thermal_rapl mei_me dell_wmi_descriptor > firmware_attributes_class kfifo_buf wmi_bmof ansi_cprng intel_pmc_bxt > cec snd roles intel_rapl_common ecdh_generic iTCO_vendor_support > int3403_thermal watchdog ecc industrialio mei soundcore typec > int3400_thermal rc_core mac80211 > [ 22.662253] int340x_thermal_zone intel_pmc_core button intel_hid > acpi_thermal_rel sparse_keymap ttm acpi_pad acpi_tad drm_kms_helper > libarc4 igen6_edac i2c_algo_bit ac evdev hid_multitouch serio_raw > iwlwifi cfg80211 rfkill msr parport_pc ppdev lp drm parport fuse loop > efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 > mbcache jbd2 crc32c_generic usbhid hid_sensor_custom hid_sensor_hub > dm_crypt dm_mod intel_ishtp_hid nvme nvme_core t10_pi > crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic > crc64 ahci libahci crct10dif_pclmul crct10dif_common libata > crc32_pclmul crc32c_intel scsi_mod spi_pxa2xx_platform > ghash_clmulni_intel dw_dmac hid_generic sha512_ssse3 scsi_common > dw_dmac_core xhci_pci sha512_generic sha256_ssse3 xhci_hcd sha1_ssse3 > usbcore i2c_hid_acpi intel_lpss_pci aesni_intel video intel_ish_ipc > i2c_i801 i2c_hid intel_lpss psmouse thunderbolt crypto_simd cryptd > i2c_smbus vmd intel_ishtp usb_common idma64 hid battery wmi > [ 22.662422] ---[ end trace 0000000000000000 ]--- > > Cheers, > > Jeremy #regzbot ^introduced 6083089ab0063 #regzbot title Bluetooth kernel BUG with Intel AX211 #regzbot duplicate: https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… #regzbot ignore-activit

1 month

7
22
0 0

[REGRESSION][BISECTED] Commit 60e3318e3e900 in stable/linux-6.1.y breaks cifs client failover to another server in DFS namespace

by Andrew Paniakin

Commit 60e3318e3e900 ("cifs: use fs_context for automounts") was released in v6.1.54 and broke the failover when one of the servers inside DFS becomes unavailable. We reproduced the problem on the EC2 instances of different types. Reverting aforementioned commint on top of the latest stable verison v6.1.94 helps to resolve the problem. Earliest working version is v6.2-rc1. There were two big merges of CIFS fixes: [1] and [2]. We would like to ask for the help to investigate this problem and if some of those patches need to be backported. Also, is it safe to just revert problematic commit until proper fixes/backports will be available? We will help to do testing and confirm if fix works, but let me also list the steps we used to reproduce the problem if it will help to identify the problem: 1. Create Active Directory domain eg. 'corp.fsxtest.local' in AWS Directory Service with: - three AWS FSX file systems filesystem1..filesystem3 - three Windows servers; They have DFS installed as per https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs…: - dfs-srv1: EC2AMAZ-2EGTM59 - dfs-srv2: EC2AMAZ-1N36PRD - dfs-srv3: EC2AMAZ-0PAUH2U 2. Create DFS namespace eg. 'dfs-namespace' in Windows server 2008 mode and three folders targets in it: - referral-a mapped to filesystem1.corp.local - referral-b mapped to filesystem2.corp.local - referral-c mapped to filesystem3.corp.local - local folders dfs-srv1..dfs-srv3 in C:\DFSRoots\dfs-namespace of every Windows server. This helps to quickly define underlying server when DFS is mounted. 3. Enabled cifs debug logs: ``` echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control echo 7 > /proc/fs/cifs/cifsFYI ``` 4. Mount DFS namespace on Amazon Linux 2023 instance running any vanilla kernel v6.1.54+: ``` dmesg -c &>/dev/null cd /mnt mount -t cifs -o cred=/mnt/creds,echo_interval=5 \ //corp.fsxtest.local/dfs-namespace \ ./dfs-namespace ``` 5. List DFS root, it's also required to avoid recursive mounts that happen during regular 'ls' run: ``` sh -c 'ls dfs-namespace' dfs-srv2 referral-a referral-b ``` The DFS server is EC2AMAZ-1N36PRD, it's also listed in mount: ``` [root@ip-172-31-2-82 mnt]# mount | grep dfs //corp.fsxtest.local/dfs-namespace on /mnt/dfs-namespace type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.11.26,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) //EC2AMAZ-1N36PRD.corp.fsxtest.local/dfs-namespace/referral-a on /mnt/dfs-namespace/referral-a type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.12.80,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) ``` List files in first folder: ``` sh -c 'ls dfs-namespace/referral-a' filea.txt.txt ``` 6. Shutdown DFS server-2. List DFS root again, server changed from dfs-srv2 to dfs-srv1 EC2AMAZ-2EGTM59: ``` sh -c 'ls dfs-namespace' dfs-srv1 referral-a referral-b ``` 7. Try to list files in another folder, this causes ls to fail with error: ``` sh -c 'ls dfs-namespace/referral-b' ls: cannot access 'dfs-namespace/referral-b': No route to host``` Sometimes it's also 'Operation now in progress' error. mount shows the same output: ``` //corp.fsxtest.local/dfs-namespace on /mnt/dfs-namespace type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.11.26,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) //EC2AMAZ-1N36PRD.corp.fsxtest.local/dfs-namespace/referral-a on /mnt/dfs-namespace/referral-a type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.12.80,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) ``` I also attached kernel debug logs from this test. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Reported-by: Andrei Paniakin <apanyaki(a)amazon.com> Bisected-by: Simba Bonga <simbarb(a)amazon.com> --- #regzbot introduced: v6.1.54..v6.2-rc1

1 month, 1 week

3
10
0 0

[PATCH v7 bpf-next 01/10] lib/buildid: harden build ID parsing logic

by Andrii Nakryiko

Harden build ID parsing logic, adding explicit READ_ONCE() where it's important to have a consistent value read and validated just once. Also, as pointed out by Andi Kleen, we need to make sure that entire ELF note is within a page bounds, so move the overflow check up and add an extra note_size boundaries validation. Fixes tag below points to the code that moved this code into lib/buildid.c, and then subsequently was used in perf subsystem, making this code exposed to perf_event_open() users in v5.12+. Cc: stable(a)vger.kernel.org Reviewed-by: Eduard Zingerman <eddyz87(a)gmail.com> Reviewed-by: Jann Horn <jannh(a)google.com> Suggested-by: Andi Kleen <ak(a)linux.intel.com> Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib") Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> --- lib/buildid.c | 76 +++++++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 32 deletions(-) diff --git a/lib/buildid.c b/lib/buildid.c index e02b5507418b..26007cc99a38 100644 --- a/lib/buildid.c +++ b/lib/buildid.c @@ -18,31 +18,37 @@ static int parse_build_id_buf(unsigned char *build_id, const void *note_start, Elf32_Word note_size) { - Elf32_Word note_offs = 0, new_offs; - - while (note_offs + sizeof(Elf32_Nhdr) < note_size) { - Elf32_Nhdr *nhdr = (Elf32_Nhdr *)(note_start + note_offs); + const char note_name[] = "GNU"; + const size_t note_name_sz = sizeof(note_name); + u64 note_off = 0, new_off, name_sz, desc_sz; + const char *data; + + while (note_off + sizeof(Elf32_Nhdr) < note_size && + note_off + sizeof(Elf32_Nhdr) > note_off /* overflow */) { + Elf32_Nhdr *nhdr = (Elf32_Nhdr *)(note_start + note_off); + + name_sz = READ_ONCE(nhdr->n_namesz); + desc_sz = READ_ONCE(nhdr->n_descsz); + + new_off = note_off + sizeof(Elf32_Nhdr); + if (check_add_overflow(new_off, ALIGN(name_sz, 4), &new_off) || + check_add_overflow(new_off, ALIGN(desc_sz, 4), &new_off) || + new_off > note_size) + break; if (nhdr->n_type == BUILD_ID && - nhdr->n_namesz == sizeof("GNU") && - !strcmp((char *)(nhdr + 1), "GNU") && - nhdr->n_descsz > 0 && - nhdr->n_descsz <= BUILD_ID_SIZE_MAX) { - memcpy(build_id, - note_start + note_offs + - ALIGN(sizeof("GNU"), 4) + sizeof(Elf32_Nhdr), - nhdr->n_descsz); - memset(build_id + nhdr->n_descsz, 0, - BUILD_ID_SIZE_MAX - nhdr->n_descsz); + name_sz == note_name_sz && + memcmp(nhdr + 1, note_name, note_name_sz) == 0 && + desc_sz > 0 && desc_sz <= BUILD_ID_SIZE_MAX) { + data = note_start + note_off + ALIGN(note_name_sz, 4); + memcpy(build_id, data, desc_sz); + memset(build_id + desc_sz, 0, BUILD_ID_SIZE_MAX - desc_sz); if (size) - *size = nhdr->n_descsz; + *size = desc_sz; return 0; } - new_offs = note_offs + sizeof(Elf32_Nhdr) + - ALIGN(nhdr->n_namesz, 4) + ALIGN(nhdr->n_descsz, 4); - if (new_offs <= note_offs) /* overflow */ - break; - note_offs = new_offs; + + note_off = new_off; } return -EINVAL; @@ -71,7 +77,7 @@ static int get_build_id_32(const void *page_addr, unsigned char *build_id, { Elf32_Ehdr *ehdr = (Elf32_Ehdr *)page_addr; Elf32_Phdr *phdr; - int i; + __u32 i, phnum; /* * FIXME @@ -80,18 +86,19 @@ static int get_build_id_32(const void *page_addr, unsigned char *build_id, */ if (ehdr->e_phoff != sizeof(Elf32_Ehdr)) return -EINVAL; + + phnum = READ_ONCE(ehdr->e_phnum); /* only supports phdr that fits in one page */ - if (ehdr->e_phnum > - (PAGE_SIZE - sizeof(Elf32_Ehdr)) / sizeof(Elf32_Phdr)) + if (phnum > (PAGE_SIZE - sizeof(Elf32_Ehdr)) / sizeof(Elf32_Phdr)) return -EINVAL; phdr = (Elf32_Phdr *)(page_addr + sizeof(Elf32_Ehdr)); - for (i = 0; i < ehdr->e_phnum; ++i) { + for (i = 0; i < phnum; ++i) { if (phdr[i].p_type == PT_NOTE && !parse_build_id(page_addr, build_id, size, - page_addr + phdr[i].p_offset, - phdr[i].p_filesz)) + page_addr + READ_ONCE(phdr[i].p_offset), + READ_ONCE(phdr[i].p_filesz))) return 0; } return -EINVAL; @@ -103,7 +110,7 @@ static int get_build_id_64(const void *page_addr, unsigned char *build_id, { Elf64_Ehdr *ehdr = (Elf64_Ehdr *)page_addr; Elf64_Phdr *phdr; - int i; + __u32 i, phnum; /* * FIXME @@ -112,18 +119,19 @@ static int get_build_id_64(const void *page_addr, unsigned char *build_id, */ if (ehdr->e_phoff != sizeof(Elf64_Ehdr)) return -EINVAL; + + phnum = READ_ONCE(ehdr->e_phnum); /* only supports phdr that fits in one page */ - if (ehdr->e_phnum > - (PAGE_SIZE - sizeof(Elf64_Ehdr)) / sizeof(Elf64_Phdr)) + if (phnum > (PAGE_SIZE - sizeof(Elf64_Ehdr)) / sizeof(Elf64_Phdr)) return -EINVAL; phdr = (Elf64_Phdr *)(page_addr + sizeof(Elf64_Ehdr)); - for (i = 0; i < ehdr->e_phnum; ++i) { + for (i = 0; i < phnum; ++i) { if (phdr[i].p_type == PT_NOTE && !parse_build_id(page_addr, build_id, size, - page_addr + phdr[i].p_offset, - phdr[i].p_filesz)) + page_addr + READ_ONCE(phdr[i].p_offset), + READ_ONCE(phdr[i].p_filesz))) return 0; } return -EINVAL; @@ -152,6 +160,10 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id, page = find_get_page(vma->vm_file->f_mapping, 0); if (!page) return -EFAULT; /* page not mapped */ + if (!PageUptodate(page)) { + put_page(page); + return -EFAULT; + } ret = -EINVAL; page_addr = kmap_local_page(page); -- 2.43.5

1 month, 2 weeks

3
2
0 0

[PATCH 1/2] drm/i915: Schedule the HPD poll init work on an unbound workqueue

by Imre Deak

Disabling HPD polling from i915_hpd_poll_init_work() involves probing all display connectors explicitly to account for lost hotplug interrupts. On some platforms (mostly pre-ICL) with HDMI connectors the I2C EDID bit-banging using udelay() triggers in turn the workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND warning. Fix the above by scheduling i915_hpd_poll_init_work() on a WQ_UNBOUND workqueue. It's ok to use a system WQ, since i915_hpd_poll_init_work() is properly flushed in intel_hpd_cancel_work(). The connector probing from drm_mode_config::output_poll_work resulting in the same warning is fixed by the next patch. Cc: Tejun Heo <tj(a)kernel.org> Cc: Heiner Kallweit <hkallweit1(a)gmail.com> CC: stable(a)vger.kernel.org # 6.5 Suggested-by: Tejun Heo <tj(a)kernel.org> Suggested-by: Heiner Kallweit <hkallweit1(a)gmail.com> Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245 Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c index e8562f6f8bb44..accc2fec562a0 100644 --- a/drivers/gpu/drm/i915/display/intel_hotplug.c +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -774,7 +774,7 @@ void intel_hpd_poll_enable(struct drm_i915_private *dev_priv) * As well, there's no issue if we race here since we always reschedule * this worker anyway */ - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } @@ -803,7 +803,7 @@ void intel_hpd_poll_disable(struct drm_i915_private *dev_priv) return; WRITE_ONCE(dev_priv->display.hotplug.poll_enabled, false); - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } -- 2.37.2

1 month, 3 weeks

3
4
0 0

[PATCH 0/2] usb: dwc3: Disable susphy during initialization

by Thinh Nguyen

We notice some platforms set "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Just make sure that the GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY are clear during initialization. The host initialization involved xhci. So the dwc3 needs to implement the xhci_plat_priv->plat_start() for xhci to re-enable the suspend bits. Since there's a prerequisite patch to drivers/usb/host/xhci-plat.h that's not a fix patch, this series should go on Greg's usb-testing branch instead of usb-linus. Thinh Nguyen (2): usb: xhci-plat: Don't include xhci.h usb: dwc3: core: Prevent phy suspend during init drivers/usb/dwc3/core.c | 90 +++++++++++++++--------------------- drivers/usb/dwc3/core.h | 1 + drivers/usb/dwc3/gadget.c | 2 + drivers/usb/dwc3/host.c | 27 +++++++++++ drivers/usb/host/xhci-plat.h | 4 +- 5 files changed, 71 insertions(+), 53 deletions(-) base-commit: 3d122e6d27e417a9fa91181922743df26b2cd679 -- 2.28.0

1 month, 3 weeks

5
12
0 0

Re: [REGRESSION] kexec does firmware reboot in kernel v6.7.6

by Steve Wahl

On Tue, Mar 12, 2024 at 07:04:10AM -0400, Eric Hagberg wrote: > On Thu, Mar 7, 2024 at 11:33 AM Steve Wahl <steve.wahl(a)hpe.com> wrote: > > What Linux Distribution are you running on that machine? My guess > > would be that this is not distro related; if you are running something > > quite different from Pavin that would confirm this. > > Distro in use is Rocky 8, so it’s pretty clear not to be distro-specific. > > > I found an AMD based system to try to reproduce this on. > > yeah, it probably requires either a specific cpu or set or devices plus cpu > to trigger… found that it also affects Dell R7625 servers in addition to > the R6615s I agree that it's likely the CPU or particular set of surrounding devices that trigger the problem. I have not succeeded in reproducing the problem yet. I tried an AMD based system lent to me, but it's probably the wrong generation (AMD EPYC 7251) and I didn't see the problem. I have a line on a system that's more in line with the systems the bug was reported on that I should be able to try tomorrow. I would love to have some direction from the community at large on this. The fact that nogbpages on the command line causes the same problem without my patch suggests it's not bad code directly in my patch, but something in the way kexec reacts to the resulting identity map. One quick solution would be a kernel command line parameter to select between the previous identity map creation behavior and the new behavior. E.g. in addition to "nogbpages", we could have "somegbpages" and "allgbpages" -- or gbpages=[all, some, none] with nogbpages a synonym for backwards compatibility. But I don't want to introduce a new command line parameter if the actual problem can be understood and fixed. The question is how much time do I have to persue a direct fix before some other action needs to be taken? Thanks, --> Steve Wahl -- Steve Wahl, Hewlett Packard Enterprise

1 month, 4 weeks

6
15
0 0

[PATCH] drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too

by Mario Limonciello

Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. Cc: stable(a)vger.kernel.org Cc: Marc Rossi <Marc.Rossi(a)amd.com> Cc: Hamza Mahfooz <Hamza.Mahfooz(a)amd.com> Link: https://gitlab.freedesktop.org/drm/amd/uploads/a832dd515b571ee171b3e3b566e9… [1] Link: https://gitlab.freedesktop.org/drm/amd/uploads/8f13ff3b00963c833e23e68aa811… [2] Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2645 Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- --- drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c index e304e8435fb8..477289846a0a 100644 --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c @@ -841,6 +841,8 @@ bool is_psr_su_specific_panel(struct dc_link *link) isPSRSUSupported = false; else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x03) isPSRSUSupported = false; + else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x01) + isPSRSUSupported = false; else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1) isPSRSUSupported = true; } -- 2.34.1

2 months

5
4
0 0

[PATCH v1 1/1] ufs: core: set SDEV_OFFLINE when ufs shutdown.

by Seunghwan Baek

There is a history of dead lock as reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all lu's scsi_devices by ufs shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio. To solve this, set SDEV_OFFLINE for all lus except wlun, so that any i/o that comes down after a ufs shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun") Cc: stable(a)vger.kernel.org Signed-off-by: Seunghwan Baek <sh8267.baek(a)samsung.com> --- drivers/ufs/core/ufshcd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index a6f818cdef0e..4ac1492787c2 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -10215,7 +10215,9 @@ static void ufshcd_wl_shutdown(struct device *dev) shost_for_each_device(sdev, hba->host) { if (sdev == hba->ufs_device_wlun) continue; - scsi_device_quiesce(sdev); + mutex_lock(&sdev->state_mutex); + scsi_device_set_state(sdev, SDEV_OFFLINE); + mutex_unlock(&sdev->state_mutex); } __ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM); -- 2.17.1

2 months, 1 week

3
9
0 0

[PATCH v2 0/6] sysctl: prepare sysctl core for const struct ctl_table

by Thomas Weißschuh

Adapt the internal and external APIs of the sysctl core to handle read-only instances of "struct ctl_table". Patch 1: Bugfix for the sysctl core, the bug can be reliably triggered with the series applied Patch 2: Trivial preparation commit for the sysctl BPF hook Patch 3: Adapts the internal sysctl APIs Patch 4: Adapts the external sysctl APIs Patch 5: Constifies the sysctl internal tables as proof that it works Patch 6: Updates scripts/const_structs.checkpatch for "struct ctl_table" Motivation ========== Moving structures containing function pointers into unmodifiable .rodata prevents attackers or bugs from corrupting and diverting those pointers. Also the "struct ctl_table" exposed by the sysctl core were never meant to be mutated by users. For this goal changes to both the sysctl core and "const" qualifiers for various sysctl APIs are necessary. Full Process ============ * Drop ctl_table modifications from the sysctl core ([0], in mainline) * Constify arguments to ctl_table_root::{set_ownership,permissions} ([1], in mainline) * Migrate users of "ctl_table_header::ctl_table_arg" to "const". (in mainline) * Afterwards convert "ctl_table_header::ctl_table_arg" itself to const. (in mainline) * Prepare helpers used to implement proc_handlers throughout the tree to use "const struct ctl_table *". ([2], in mainline) * Afterwards switch over all proc_handlers callbacks to use "const struct ctl_table *" in one commit. (in mainline) * Switch over the internals of the sysctl core to "const struct ctl_table *" (this series) * Switch include/linux/sysctl.h to "const struct ctl_table *" (this series) * Transition instances of "struct ctl_table" through the tree to const (to be done) This series is meant to be applied through the sysctl tree. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Avoid spurious permanent empty tables (patch 1) - Link to v1: https://lore.kernel.org/r/20240729-sysctl-const-api-v1-0-ca628c7a942c@weiss… --- Thomas Weißschuh (6): sysctl: avoid spurious permanent empty tables bpf: Constify ctl_table argument of filter function sysctl: move internal interfaces to const struct ctl_table sysctl: allow registration of const struct ctl_table sysctl: make internal ctl_tables const const_structs.checkpatch: add ctl_table fs/proc/internal.h | 2 +- fs/proc/proc_sysctl.c | 100 +++++++++++++++++++++------------------ include/linux/bpf-cgroup.h | 2 +- include/linux/sysctl.h | 12 ++--- kernel/bpf/cgroup.c | 2 +- scripts/const_structs.checkpatch | 1 + 6 files changed, 63 insertions(+), 56 deletions(-) --- base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b change-id: 20240729-sysctl-const-api-73954f3d62c1 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

2 months, 1 week

3
4
0 0

[PATCH] soc: qcom: smem_state: fix missing of_node_put in error path

by Krzysztof Kozlowski

If of_parse_phandle_with_args() succeeds, the OF node reference should be dropped, regardless of number of phandle arguments. Cc: <stable(a)vger.kernel.org> Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- drivers/soc/qcom/smem_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/qcom/smem_state.c b/drivers/soc/qcom/smem_state.c index d9bfac6c54fb..cc5be8019b6a 100644 --- a/drivers/soc/qcom/smem_state.c +++ b/drivers/soc/qcom/smem_state.c @@ -112,7 +112,8 @@ struct qcom_smem_state *qcom_smem_state_get(struct device *dev, if (args.args_count != 1) { dev_err(dev, "invalid #qcom,smem-state-cells\n"); - return ERR_PTR(-EINVAL); + state = ERR_PTR(-EINVAL); + goto put; } state = of_node_to_state(args.np); -- 2.43.0

2 months, 2 weeks

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024