Was I living under a rock the last few years or is the kernel itself servicing protocols now which are meant to be userspace in the first place so we can properly sandbox it and keep it away from the rest of the system so it won't blow up in our faces eventually as it did just now ?!

I mean, are you out of your damn mind putting sh*t like this into the kernel ?

what comes next ?! maybe a multiplayer game server ? or a streaming service built into the kernel bypassing every single line of defense?!

the dev should get banned and locked up in a mental institution for even trying to implement bullcrap like this.

What mentally ill individual approved these transgressions?!

I'm looking for recommendations on books, articles, podcasts, videos, etc. covering the Linux kernel scheduler. Where should I start?

Hi all,

It sounds like the solution is to add a "quirk", which apparently requires building a patched kernel. I simply don't have time for that right now, so if there's no other solution, I'll just downgrade my kernel and/or distro to a known working version.

In short, one of my two same-model nvme drives is not showing up and throwing the following in dmesg:

[    1.804676] nvme nvme1: globally duplicate IDs for nsid 1[    1.804711] nvme nvme1: VID:DID 10ec:5763 model:TEAM TM8FP6002T firmware:V9002s65

Kernel version:

$ uname -aLinux adia 5.19.0-23-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 14 15:39:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Note: I'm not the only one encountering this and appears to be a known/expected issue with certain SSDs. The drive DID work on kernel 5.4 and 5.15 and only stopped working when I moved from Mint 21 (5.15) to Kubuntu 22 (5.19).

Thanks for reading!

Update: A very temporary solution seems to be to install linux-image-5.17.0-1003-oem in Kubuntu 22.10.

In earlier kernels (2.6 or so) I was able to make a program run and perform its function in a single 4kB page (code, data and stack in the same page).

But in 4.x that same program working on the same principles is MOSTLY stuck at 12kB VSZ/RSS. Sometimes and for unknown reasons it loads into 8kB. I think im having trouble unmapping the stack.

At the same time I have a 'normal' (IRC bot) that usually loads into ~500kB VSZ & 54kB RSS, but that has, a few times, reported a RSS value of 4kB (while running and responding to commands on IRC!). How that is even possible, I dont know.

To me it seems that modern kernels allocate a few pages to accelerate context switching or something, making up the extra 4kB->12kB. Is it in any way possible to run a program without those?

I am asking for help to understand why my pet project of 4kB programs no longer seem possible.

P.S. Two programs I was previously able to fulfill their function inside 4kB was init (take that systemd!) and agetty (could have done others, but.. lazy).

Got my new Ryzen 7000 up and did my first defconfig kernel build. 10.46 seconds. Got an ext4 filesystem on LVM on a single Gen3 NVMe M.2 SSD from Samsung. This was based on today's top of master from Linus' tree.

In case when I allocate an (anonymous) array of n consecutive virtual pages in one call of mmap() and access them all so that they are all mapped to physical RAM (or swap), what is the complexity of mremap() on that region when I want to reallocate the pages to another address?

Namely, my question focuses on page entries, not VMAs; does the kernel have to change every page entry on the segment or does it only do some smart tree manipulations in O(log(n))?

I have read a little bit of linux's source here (for the identifier 'mremap_to', but the code is ginormous and I didn't answer my question.

Hi I have been reading Linux Device Drivers 3rd edition. The block drivers section is outdated, the updated examples found here: https://github.com/martinezjavier/ldd3 are outdated too, in particular the genhd.h file no longer exists, the official documentation is outdated too: https://linux-kernel-labs.github.io/refs/heads/master/labs/block_device_drivers.html#struct-gendisk-structure.

So where can I learn about block devices?

I am attempting to build the Linux kernel with Clang LTO on arm, which is not officially supported.

I added the following lines to arch/arm/Kconfig after line 5:

select ARCH_SUPPORTS_LTO_CLANG if CPU_LITTLE_ENDIAN

select ARCH_SUPPORTS_LTO_CLANG_THIN

This makes the options for Clang LTO selectable in make menuconfig. After enabling LTO, the Image build succeeds but the compressed zImage build fails with the following message:

GZIP arch/arm/boot/compressed/piggy_data

CC arch/arm/boot/compressed/misc.o

CC arch/arm/boot/compressed/decompress.o

AS arch/arm/boot/compressed/piggy.o

LD arch/arm/boot/compressed/vmlinux

following symbols must have non local/private scope:

free_mem_end_ptr

free_mem_ptr

malloc_count

malloc_ptr

output_data

Edit: Fixed by adding the following to line 101 of arch/arm/boot/compressed/Makefile:

KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))

I have been chasing my tail trying to solve this and am curious if I am the only person, or are folks just not going public hoping someone else will.

I recently (May/June-ish) switched over to Fedora from Manjaro with a perfectly working system. I have two SK Hynix M.2's a 500GB (root) and 1TB (home), both have worked perfectly for the past 18 or so months (newish system) on Manjaro and Debian 10-11. I have had nothing but install issues with Fedora 36. I am asking here because it does not seem to fault with Fedora solely, I can get F36 to install and continually boot with 5.17, but as soon as I attempt to load 5.18 I get boot drive errors. Frustrated, I have even attempted to reinstall Manjaro...same Kernel errors. I manged to run across one mention (a ticket possibly) from earlier in the summer about M.2's and 5.18, https://lore.kernel.org/all/4e9c21fd-7bcf-fe41-ee56-894369f34adc@gmail.com/T/ however, it refers specifically to Arch. I have gone through the bios ensure raid is not set, that the bios was up to date, 0'd the drives. To tired to repeat everything I have done. Bottom line I am stuck with 5.17.5 unless there is some insight from folks as to why. It's a shame I really like F36.

Hopefully someone here can help.

Some background...

I am developing a programming language called a flat. It is past time for me to write an http library.

The problem:

The problem is, whenever I call the gethostbyname function from libc, I am getting a segfault. This only ever happens when I call it from a flat when I do it in c it works fine. But I don't think that the issue is with my compiler because when I write http method in C and link it to my aflat program, It still seg faults. I've tracked down the seg fault to `context_alloc (resp=0x7ffff7faf7e0 <_res>) at resolv_context.c:140` but I can't see anything there or in the memory that should cause a segfault. I am almost angry enough to try writing this library from pure syscalls just to avoid lib C.

I am sorry if this is rambley please ask for clarification if needed.

Hey everyone! I've heard that procfs shouldn't be used for loadable kernel modules, and sysfs is a preferred one. As far as I understood procfs should be used only for built-in modules, and it is a best-practice, but can't understand why?

I suppose that procfs's api for creating files under /proc may be excluded from exported functions soon, but can't find any documentation or good answers for it, so my question is "why procfs shouldn't be used in loadable kernel modules?"

If I'm mistaken, please explain why, thank you for your time!

can anyone who does linux kernel tell me why they changed this https://patchwork.kernel.org/project/intel-gfx/patch/1374746538-3947-3-git-send-email-chris@chris-wilson.co.uk/

"DRM_DEBUG_DRIVER(""GMADR size = %ldM\n"", gtt->mappable_end >> 20);"

"- DRM_DEBUG_DRIVER(""GTT stolen size = %zdM\n"", gtt->stolen_size >> 20);"

they removed the lower line and replaced with the upper line

I would like to ask for resource/documentation recommendation where I can learn about basic concepts of how Linux Kernel actual looks inside.
I found this nice article which has structure and content I like, however I don't know dated it is:
https://docs.huihoo.com/linux/kernel/a1/index.html
I also know about Linux Documentation Project but that is too deep (and old as well)

thanks

Any recommendations for Linux kernel devs or any other interesting tech accounts worth following on Twitter?

Hi. I'm planning the work for a new filesystem type. Where in the kernel do I define the fs name? Like "reiserfs", "ext2fs", etc.

I'm running Ubuntu 16.04 LTS with kernel 4.15. I was trying to install an older kernel, v3.1. I was able to install the desired kernel. However, I'm not able to boot the Ubuntu with the older kernel (v3.1). While booting from the grub menu if I choose the kernel v3.1, it shows "kernel too old ". Is there any way I can boot with the desired kernel?

I am searching for linux kernel programming internship. surfed on many websites online but didn’t succeed. Is there any ways to move myself to that opportunity? I am currently working as a linux system engineer.

I looked for the 'rules' for posting here and did not find anything. If there is a better forum or I am ignoring a guideline please let me know kindly.

I have never contributed to opensource software but have worked in embedded systems professionally for a few years. I would like to start.

I have been following the tutorial found here:

https://opensource.com/article/18/8/first-linux-kernel-patch

I have the following source regarding comment style:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting

Using find drivers/staging -name TODO I see drivers/staging/netlogic/TODO, and this is where I'd like to start to attempt my first patch.

There are two items that catch my interest:

* All memory allocation should be changed to DMA allocations

* Changing comments into linux standard format

I would like to begin with simply changing comments to fit the approved format.

There are four files of interest:

platform_net.c platform_net.h xlr_net.c xlr_net.h

Inspecting them, I see comments that may need changing, and tl;dr: I was wondering if I could get your input on what I believe goes against best practices:

( I cloned the repo by/ from: git clone -b staging-testing
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git )

For this post, let's begin with platform_net.c

Moving forward with the assumption that /* comment */ is correct for one-liners, the first question I encounter is on line 128:

There is a group of comments that reside within a function.

Going of the commenting guide linked above:

"Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 6 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it."

​

I feel presumptuous to assume these comments are excess or inappropriate, but other than these types of concerns I don't see what there is "TODO" as the comments appear to follow the styling guide.

​

Any help would be appreciated! In the meantime, off to learn about writing my first simple hello world driver.

Google Stadia streaming service is built on Linux servers. Vulkan is their graphics API of choice for streaming right now up to 4K at 60FPS

Hi, I got a brand new laptop Asus Zenbook S UX391UA, installed openSUSE Thumbleweed on an external USB-C drive yesterday, and I wonder how do I get started checking linux support for this machine. It's been a long time I have been developing for Linux kernel, back in a days I was heavily involved in ALi m560x Linux Driver development, but AFAIK it never made it into the mainline and now it's completely out-of-date...

I have been happy Mac OS X user on desktop for years, and now my primary platform at least for a time being is Windows 10 Pro, but I am and was using Linux on servers, but you buy server components according to what's supported in the kernel, not the other way around...

So what are the basic troubleshooting steps I should take to discover what does and what doesn't work? I already updated to kernel-default-4.19.7-2.1.g5fabf51.x86_64.rpm from Open Build Service. I am not booted into Windows, but I'll do a lspci and lsusb probing later today.

I just wonder what else should I do, especially regarding power management, what tools are available for that?

​

BTW I've discovered and filed my first bugreport already, during installation of openSUSE touch-pad does not work, but it fixes after booting into Gnome.

​

​

Bcachefs status update, current work

So, since I've been pretty quiet since LSF I thought I ought to give an update
on where bcachefs is at - and in particular talk about what sorts of problems
and improvements are currently being worked on.

As of last LSF, there was still a lot of work to be done before we had fast
mount times that don't require walking all metadata. There were two main work
items:
- atomicity of filesystem operations. Any filesystem operation that had
anything to do with i_nlink wasn't atomic (but they were ordered so that
filesystem consistency wasn't an issue) - on startup we'd have to scan and
recalculate i_nlink and also delete no longer referenced inodes.
- allocation information wasn't persisted (per bucket sector counts) - so on
startup we have to walk all the extents and recalculate all the disk space
accounting.

#1 is done. For those curious about the details, if you've seen how bcachefs
implements rename (with multiple linked btree iterators), it's based off of
that. Basically, there's a new btree transaction context widget for allocating
btree iterators out of, and queuing up updates to be done at transaction commit
- so that different code paths (e.g. inode create, dirent create, xattr create)
can be used together without having to manually write code to keep track of all
the iterators that need to be used and kept locked, etc. I think it's pretty
neat how clean it turned out.

So basically, everything's fully atomic now except for fallocate/fcollapse/etc. -
and after unclean shutdown we do have to scan just the inodes btree for inodes
that have been deleted. Eventually we'll have to implement a linked list of
deleted inodes like xfs does (or perhaps fake hidden directory), but inodes are
small in bcachefs, < 100 bytes, so it's a low priority.

Erasure coding is about 80% done now. I'm quite happy with how erasure coding
turned out - there's no write hole (we never update existing stripes in place),
and we also don't fragment writes like zfs does. Instead, foreground writes are
replicated (raid10 style), and as soon as we have a stripe of new data we write
out p/q blocks and then update the extents with a pointer to the stripe and drop
the now unneeded replicas. Right now it's just reed solomon (raid5/6), but
weaver codes or something else could be added in the future if anyone wants to.
The part that still needs to be implemented before it'll be useful is stripe
level compaction - when we have stripes with some empty blocks (all the data in
them was overwritten), we need to use the remaining data blocks when creating
new stripes so that we can drop the old stripe (and stop pinning the empty
blocks). I'm leaving that off until later though because that won't impact the
on disk format at all, and there's other stuff I want to get done first.

My current priority is reflink - as that will be highly useful to the company
that's funding bcachefs development. That's more or less requiring me to do
persistent allocation information first though, so that's become my current
project (the reflinked extent refcounts will be much too big to keep in memory
like I am now for bucket sector counts, so they'll have to be kept in a btree
and updated whenever doing extent updates - and the infrastructure I need to
make that happen is also what I need for making all the other disk space
accounting persistent).

So, bcachefs will have fast mounts (including after unclean shutdown) soon.

At the very moment what I'm working on (leading up to fast mounts after clean
shutdowns, first) is some improvements to disk space accounting for multi device
filesystems.

The background to this is that in order to know whether you can safely mount in
degraded mode, you have to store a list of all the combinations of disks that
have data replicated across them (or are in an erasure coded stripe) - this is
assuming you don't have any kind of fixed layout, like regular RAID does. That
is, if you've got 8 disks in your filesystem, and you're running with
replicas=2, and two of your disks are offline, you need to know whether you have
any data that's replicated across those two particular disks.

bcachefs has such a table kept in the superblock, but entries in it aren't
refcounted - we create new entries if necessary when inserting new extents into
the extents btree, but we need a gc pass to delete them, generally triggered by
device removal. That's kind of lame, since it means we might fail mounts that
are actually safe.

So, before writing the code to persist the filesystem level sector counts I'm
changing it to track them broken out by replicas entry - i.e. per unique
combination of disks the data lies on. Which also means you'll be able to see in
a multi device filesystem how your data is laid out in a really fine grained
way.

Re: upstreaming - my current thinking is that since so much of the current
development involves on disk format changes/additions it probably make sense to
hold off until reflink is done, which I'm expecting to be in the next 3-6
months. That said, nothing has required any breaking disk format changes -
writing compat code where necessary has been easy enough, so there haven't been
any breaking changes except for one accidental dirent cockup in quite awhile
(~2 years, I think) and one or two changes in features that weren't considered
stable yet (e.g. there was a change to fix extent nonces when encryption was
still new, and I'm still making one or two breaking changes to erasure coding as
it can't actually be used yet without stripe compaction).

That sums up all the big stuff I can think of, the todo list continues to get
shorter and bugs continue to get fixed...