Posts
284Following
88Followers
3018
They might have a specific PCI driver bound to them, at the function level, and if so, the parent of the device node for that class device (i.e. input, tty, drm, etc.) will then point to that PCI function. But PCI slots don't always match up to PCI bus and device numbers either, as that's a physical thing and many PCI systems don't expose or even know that information (i.e. the BIOS doesn't know.)
Also, PCI bus numbers can change at boot, so you can't know what is happening.
Driver probing can be deferred at any time by userspace for USB devices, and I think that was recently added for PCI devices too, look for the "trusted" device information in the documentation somewhere.
Good luck!
1
0
0
You have full control over device node creation in userspace, that's what udev gives you if you want (or any udev-like program). set up a whole different /dev/ with just your naming/numbering scheme. The kernel gives you the interface and the information to do this, why not take advantage of it if you need it?
1
0
0
But yes, the race condition of "parse the topology, determine the device node, and go to open it" when the device is removed and a different one added right between those last two steps is real. Luckily in real-hardware situations, almost extremely rare if not physically impossible due to hardware debounce times, and one that we explicitly did not care about when we created sysfs and udev (i.e. physical access trumps anything).
1
0
0
Greg K-H
gregkh
6
2
10
Greg K-H
gregkhThat machine that randomly reassigned PCI ids at boot time is no longer with me, but it was great for testing. I'm sure you can do the same with virtual machines these days, passing in different virtual pci devices to them.
Persistent naming is for userspace to handle, the kernel just uses "grab the next free number" as it's naming "policy" as that's all it can really do.
2
0
3
repeated
repeated
Mike [SEC=OFFICIAL]
mike@chinwag.org"Free Copilot in your GitHub account" is the 2020s version of "Free U2 album on your iPod".
5
25
2
Greg K-H
gregkhBut better yet, backport the fix to stable and it all happens automatically for you :)
1
0
1
Greg K-H
gregkh
0
2
5
repeated
Natalie Silvanovich
natashenka@infosec.exchangeCan you find an ITW 0-day from crash logs? Project Zero finds out
1
7
0
repeated
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.orgThe #LinuxKernel's stable team extended the support timeframe for #Linux 6.11 from four to five years:
https://www.kernel.org/releases.html
To quote @gregkh from https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=e6083565a79c3d711c1a76d9312b8c00e06b826b:
'" Bump 6.1.y support up to 5 years.
Giving people a chance to phase in the shorter lifespans, if at all possible. Hopefully this should help a bit.'"
2
6
1
repeated
✧✦Catherine✦✧
whitequark@mastodon.socialare you a programmer? do you like heavy metal? would you like to be *really upset* by a music video?
do i have something for you.
16
34
1
Greg K-H
gregkhIt's a fun thread, recommended for anyone who deals with compilers and trying to get them to do what you would think would be a "easy" thing to do and the hacks around them to get them to do that (hint adding "+ 0" to an expression tricks the compiler into doing what you meant it to do is usually a sign that something is wrong somewhere...)
1
8
25
repeated
Mike Dolan
mdolan@fosstodon.org"Census III of Free and #OpenSource Software: Application Libraries leans on more than 12M data points from security tools such as Black Duck, FOSSA, Snyk, and Sonatype, which have been deployed at more than 10k companies"
https://techcrunch.com/2024/12/04/linux-foundation-report-highlights-the-true-state-of-open-source-libraries-in-production-apps/ #cybersecurity
0
1
0
repeated
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.org2/ Regarding the #Linux 4.19.y EOL, see also this nice and interesting farewell note from @gregkh:
https://lore.kernel.org/all/2024120520-mashing-facing-6776@gregkh/
'"[#LinuxKernel 4.19] had a good life, despite being born out of internal strife. […]
As a "fun" proof that this one is finished […] , I looked at the "unfixed" CVEs from this #kernel release. Currently it is a list 983 CVEs long, too long to list here. […]"'
2
2
0
Greg K-H
gregkhhttps://lore.kernel.org/lkml/2024120520-preorder-untracked-6e5b@gregkh/T/
Please move to a more modern kernel if you are somehow still running this one, which I strongly would not recommend doing.
1
12
27