- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Re: PCI: hotplug_event: PCIe PLDA Device BAR Reset
by Bjorn Helgaas Feb. 19, 2025

Feb. 19, 2025

[+cc linux-acpi] On Wed, Feb 19, 2025 at 05:52:47PM +0530, Naveen Kumar P wrote: > Hi all, > > I am writing to seek assistance with an issue we are experiencing with > a PCIe device (PLDA Device 5555) connected through PCI Express Root > Port 1 to the host bridge. > > We have observed that after booting the system, the Base Address > Register (BAR0) memory of this device gets reset to 0x0 after > approximately one hour or more (the timing is inconsistent). This was > verified using the lspci output and the setpci -s 01:00.0 > BASE_ADDRESS_0 command. > > To diagnose the issue, we checked the dmesg log, but it did not > provide any relevant information. I then enabled dynamic debugging for > the PCI subsystem (drivers/pci/*) and noticed the following messages > related ACPI hotplug in the dmesg log: > > [ 0.465144] pci 0000:01:00.0: reg 0x10: [mem 0xb0400000-0xb07fffff] > ... > [ 6710.000355] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() > [ 7916.250868] perf: interrupt took too long (4072 > 3601), lowering > kernel.perf_event_max_sample_rate to 49000 > [ 7984.719647] perf: interrupt took too long (5378 > 5090), lowering > kernel.perf_event_max_sample_rate to 37000 > [11051.409115] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() > [11755.388727] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() > [12223.885715] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() > [14303.465636] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() > After these messages appear, reading the device BAR memory results in > 0x0 instead of the expected value. > > I would like to understand the following: > > 1. What could be causing these hotplug_event debug messages? This is an ACPI Notify event. Basically the platform is telling us to re-enumerate the hierarchy below RP01 because a device might have been added or removed. Unfortunately the only real information we get is the ACPI device (RP01) and the notification value (ACPI_NOTIFY_BUS_CHECK). You could instrument acpiphp_check_bridge() to see what path we take. The main paths look like enable_slot() or disable_slot(), but those both include a pr_debug() than you apparently don't see. A remove followed by add would definitely reset the device, including its BARs. But you would normally see some messages related to enumerating a new device. If this doesn't help, try to reproduce the problem with a recent kernel, e.g., v6.13, and post the complete dmesg log. > 2. Why does this result in the BAR memory being reset? > 3. How can we resolve this issue? > > I have verified that the issue occurs even without loading the driver > for the PLDA Device 5555, so it does not appear to be related to the > device driver. > > Any help or guidance on debugging this issue would be greatly appreciated. > > Thank you for your assistance. > > Best regards, > Naveen

1 0

Re: crypto: fscrypt: crypto_create_tfm_node memory leak
by Lucas Tanure Feb. 17, 2025

Feb. 17, 2025

On Mon, Feb 17, 2025 at 6:50 PM Eric Biggers <ebiggers(a)kernel.org> wrote: > > On Mon, Feb 17, 2025 at 06:43:15PM +0000, Lucas Tanure wrote: > > Hi, > > > > I am working with Android 13 and V5.15 kernel. During our development, > > I found a memory leak using kmemleak. > > > > Steps I did to find the memleak: > > mount -t debugfs debugfs /sys/kernel/debug > > echo scan=5 > /sys/kernel/debug/kmemleak > > cat /sys/kernel/debug/kmemleak > > > > Stack I got (hundreds of them): > > unreferenced object 0xffffff8101d31000 (size 1024): > > comm "binder:1357_2", pid 1357, jiffies 4294899464 (age 394.468s) > > hex dump (first 32 bytes): > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > backtrace: > > [<ffffffd327cac060>] crypto_create_tfm_node+0x64/0x228 > > [<ffffffd3279f8c4c>] fscrypt_prepare_key+0xbc/0x230 > > [<ffffffd3279f9758>] fscrypt_setup_v1_file_key+0x48c/0x510 > > [<ffffffd3279f8394>] fscrypt_setup_encryption_info+0x210/0x43c > > [<ffffffd3279f8108>] fscrypt_prepare_new_inode+0x128/0x1a4 > > [<ffffffd327bcc878>] f2fs_new_inode+0x27c/0x89c > > [<ffffffd327bce7c4>] f2fs_mkdir+0x78/0x278 > > [<ffffffd32796a3bc>] vfs_mkdir+0x138/0x204 > > [<ffffffd32796a108>] do_mkdirat+0x88/0x204 > > [<ffffffd32796a068>] __arm64_sys_mkdirat+0x40/0x58 > > [<ffffffd3274be5d4>] invoke_syscall+0x60/0x150 > > [<ffffffd3274be528>] el0_svc_common+0xc8/0x114 > > [<ffffffd3274be3f0>] do_el0_svc+0x28/0x98 > > [<ffffffd328abcf88>] el0_svc+0x28/0x90 > > [<ffffffd328abcefc>] el0t_64_sync_handler+0x88/0xec > > [<ffffffd32741164c>] el0t_64_sync+0x1b8/0x1bc > > > > After checking upstream, I came up with the following: > > cff805b1518f fscrypt: fix keyring memory leak on mount failure > > > > But my kernel has this patch. So I continued to dig around this and > > saw the function fscrypt_prepare_key in fs/crypto/keysetup.c for > > V5.15. > > I can't see the pointer tfm being used anywhere or saved, and > > smp_store_release doesn't kfree it. > > Is smp_store_release doing something with that pointer that makes this > > memory leak a false positive? > > > > Any help with this issue would be much appreciated. > > Thanks > > The pointer to the crypto_skcipher 'tfm' is stored in the fscrypt_inode_info > (previously fscrypt_info) which is stored in inode::i_crypt_info. It gets freed > when the inode is evicted. I don't know why you're getting a kmemleak warning. > Perhaps f2fs in that version of the kernel has a bug that is leaking inodes. > Thanks. How do you check for leaking inodes? Do you have any start point (function) to look at? > smp_store_release is just a fancy way of doing a store that includes a memory > barrier. > > - Eric Lucas

1 0

crypto: fscrypt: crypto_create_tfm_node memory leak
by Lucas Tanure Feb. 17, 2025

Feb. 17, 2025

Hi, I am working with Android 13 and V5.15 kernel. During our development, I found a memory leak using kmemleak. Steps I did to find the memleak: mount -t debugfs debugfs /sys/kernel/debug echo scan=5 > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak Stack I got (hundreds of them): unreferenced object 0xffffff8101d31000 (size 1024): comm "binder:1357_2", pid 1357, jiffies 4294899464 (age 394.468s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffd327cac060>] crypto_create_tfm_node+0x64/0x228 [<ffffffd3279f8c4c>] fscrypt_prepare_key+0xbc/0x230 [<ffffffd3279f9758>] fscrypt_setup_v1_file_key+0x48c/0x510 [<ffffffd3279f8394>] fscrypt_setup_encryption_info+0x210/0x43c [<ffffffd3279f8108>] fscrypt_prepare_new_inode+0x128/0x1a4 [<ffffffd327bcc878>] f2fs_new_inode+0x27c/0x89c [<ffffffd327bce7c4>] f2fs_mkdir+0x78/0x278 [<ffffffd32796a3bc>] vfs_mkdir+0x138/0x204 [<ffffffd32796a108>] do_mkdirat+0x88/0x204 [<ffffffd32796a068>] __arm64_sys_mkdirat+0x40/0x58 [<ffffffd3274be5d4>] invoke_syscall+0x60/0x150 [<ffffffd3274be528>] el0_svc_common+0xc8/0x114 [<ffffffd3274be3f0>] do_el0_svc+0x28/0x98 [<ffffffd328abcf88>] el0_svc+0x28/0x90 [<ffffffd328abcefc>] el0t_64_sync_handler+0x88/0xec [<ffffffd32741164c>] el0t_64_sync+0x1b8/0x1bc After checking upstream, I came up with the following: cff805b1518f fscrypt: fix keyring memory leak on mount failure But my kernel has this patch. So I continued to dig around this and saw the function fscrypt_prepare_key in fs/crypto/keysetup.c for V5.15. I can't see the pointer tfm being used anywhere or saved, and smp_store_release doesn't kfree it. Is smp_store_release doing something with that pointer that makes this memory leak a false positive? Any help with this issue would be much appreciated. Thanks Lucas Tanure

1 0

SCSI Generic with NUMA setup
by Dan Oelke Feb. 13, 2025

Feb. 13, 2025

I am attempting to modify kernel to get it to work for my somewhat weird system. I have a flash device and that device is attached to a separate bank of RAM that the data for a SCSI Read/Write data will be directed to. This is a UFS flash device and I have the UFS device driver working at a basic level at least. Now I am attempting to do a read or write SCSI command. I am doing this using ioctl(fd, SG_IO, sg_io_hdr) I am familiar with SCSI so I have the CDB all set no problem. In that io_hdr I want to set the dxferp to an address in that separate bank of memory. This would be an address That is from the point of view of the UFS/HCI controller and not an address that is relevant to the CPU. I’ve been reading through the scsi_lib.c and sg_ioctl code as well as the ufshcd_queuecommand. The problem is that this all centers on going through the block interface and setting up sglist there. However, I don’t want those sglists. The application is managing that bank of memory and has all the knowledge of what is in there. And it isn't virtual addresses from the kernel's point of view Any pointers on where I should look for help or maybe where would be a better place to ask for help?? This is for an embedded application so I can make things work a bit different from a general purpose system if needed. As for me: I am relatively a newbie to Linux kernel code but quite experienced in C & embedded. Thank you, Dan ________________________________ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message. When we process personal data relating to physical persons, such processing will meet the requirements of applicable data protection legislation and will be in accordance with our Privacy Policy.<https://www.teradyne.com/privacy-statement>

2 1

soundwire : LnK SoundWire Protocol Analyzer on Linux
by Muni Sekhar Feb. 6, 2025

Feb. 6, 2025

Hi all, I hope this message finds you well. I am planning to use the LnK SoundWire Protocol Analyzer on a Linux platform. However, I am uncertain whether the current Linux kernel includes the necessary SoundWire drivers to support this . I would appreciate any guidance on how to use the LnK SoundWire Protocol Analyzer with the Linux kernel, as well as information on the specific device drivers required. Could you please provide details on: The compatibility of the LnK SoundWire Protocol Analyzer with the Linux kernel. The steps to set up and use the analyzer on a Linux platform. The necessary device drivers and any additional configurations needed. Thank you for your assistance. -- Thanks, Sekhar

1 0

Dead sites?
by Leam Hall Jan. 31, 2025

Jan. 31, 2025

Anyone know if these have been replicated anywhere? I am removing them from: https://kernelnewbies.org/RelatedSites https://www.linuxfoundation.org/collaborate/workgroups crashcourse.ca/introduction-linux-kernel-programming-2nd-edition/introduction-linux-kernel-programming-2nd-edition https://www.scientificlinux.org [EOL] http://hub.opensolaris.org Thanks! Leam -- Linux Software Engineer (reuel.net/career) Scribe: The Domici War (domiciwar.net) Coding Ne'er-do-well (github.com/LeamHall) Between "can" and "can't" is a gap of "I don't know", a place of discovery. For the passionate, much of "can't" falls into "yet". -- lh Practice allows options and foresight. -- lh

1 0

Typecasting a void pointer to unsigned long in zsmalloc.c
by Sotir Danailov Jan. 28, 2025

Jan. 28, 2025

While looking through the zsmalloc.c file I stumbled upon something. On the following line, in the zs_malloc() function: handle = cache_alloc_handle(pool, gfp); https://elixir.bootlin.com/linux/v6.13-rc3/source/mm/zsmalloc.c#L1356 the handle is a result of a typecast from a void pointer to an unsigned long. return (unsigned long)kmem_cache_alloc(...); https://elixir.bootlin.com/linux/v6.13-rc3/source/mm/zsmalloc.c#L333 What's the guarantee that an unsigned long can hold the data from the void pointer? Is this safe to do? Shouldn't there be a special type for doing this type of conversion? I understand the reason for not using the void pointer directly and why they need a "handle" instead, but I'm just a bit confused by the method that has been chosen here.

5 20

Re: Typecasting a void pointer to unsigned long in zsmalloc.c
by Alex Hogen Jan. 23, 2025

Jan. 23, 2025

>> Shouldn't there be a special type for doing this type of conversion? > That type is "unsigned long" :) Wouldn't "uintptr_t" be a more explicit type for storing pointer addresses as integers? It seems to me it has the advantage of expressing intent better for us human readers. See <linux/types.h>. Yes, it is currently defined as an "unsigned long."

2 1

Generic sk_buff contract documentation ?
by Alexandre Ferrieux Jan. 13, 2025

Jan. 13, 2025

Hi, Recently digging into a driver-specific issue with sk_buff->protocol, I discovered (with surprise) that the computation of this field (which is *always* necessary for protocol handlers to kick in) was somehow "delegated" to individual network interface drivers. This can be seen by looking for callers of eth_type_trans(), e.g: - tg3: called from tg3_poll_work - ixgbe: called from ixgbe_clean_rx_irq - veth: called from veth_xmit (though indirectly via __dev_forward_skb) This is a surprise as one would naively expect this ubiquitous behavior to be triggered from generic code, depending only on the L2 header structure (but not on the specific NIC hardware at hand). Another surprise was *not* to find any mention of this "contract" in Documentation/*. So, is it an unspoken tradition for NIC driver developers, to "just know" that prior to emitting an skb from the rx path, they must fill skb->protocol (along with who knows how many other metadata items) ? Or, is there *somewhere* some reference documentation listing (exhaustively) the required metadata computations that fall within a NIC driver's responsibility ? Thanks in advance, -Alex

1 0

Linux kernel cgroup v2 CFS - CPU throttled_usec accounting?
by Alexandru Lazarev Jan. 12, 2025

Jan. 12, 2025

Hi community, My question: In Linux kernel cgroup v2’s CFS scheduler, how is cpu.max throttled_usec accounted when a cgroup with multiple threads gets throttled during a single quota period? Specifically, is throttled_usec tracked as the total wall-clock time that the cgroup was throttled as a whole, or is it a sum of the throttled times of all individual threads? Kernel Version: "5.14.0-284.11.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Tue May 9 11:41:53 PDT 2023 x86_64 x86_64 x86_64 GNU/Linux" Distro: Oracle Linux 9.x Regards, AlexL

2 2