What are /r/kernel's favorite Products & Services?

From 3.5 billion Reddit comments

You can pass the 'memmap=' parameter to the kernel at boot time. From https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt:

memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be reserved is from ss to ss+nn. Example: Exclude memory from 0x18690000-0x1869ffff memmap=64K$0x18690000 or memmap=0x10000$0x18690000 Some bootloaders may need an escape character before '$', like Grub2, otherwise '$' and the following number will be eaten.

Not sure if you've received a response from little yet. Anyway, thought you (and other Redditors' participating in this challenge) may find the following info helpful -

1. Yes, the challenge is very much on. So far, only 111 individuals have completed all 20 tasks/assignments of this challenge (out of 13.9K participants, of which only nearly 5.3K are active, as of 28th Dec, '15).

2. You can only get to the next assignment once you've successfully completed the current one.

3. All communications are carried out through plain text based emails. This is one very important aspect of this challenge. So, I would suggest to get your email client fixed at the very beginning. Perhaps <em>this</em> will give you some insights on which email client to use for back-and-forth email communication, if you've not done that already.

4. Be patient! Sometimes it takes days before you even get a response from the bot. Expect further delays when you're seeking human assistance. In little's words -

>Remember, this is not a race, there is no rush, if tasks take a while to be graded, enjoy the time to go do something else. There is a lot more in life other than Linux kernel programming.

Good luck!

I'm not sure if this applies in your setup, but most servers use NUMA to do something similar: use memory closer (with lower cost) to the current processor. Linux has code to take advantage of NUMA.

If Linux could recognize the cost, it would probably apply the same logic and prefer the faster memory.

A lot of printed material will focus on an early version of Linux Kernel, particularly because they were relatively “fresh” (ie little bloat).

The amount of time it takes to create such a manual, you’ll be halfway done with 3.x when 6.9 is released!

That said, try this: https://kernelnewbies.org/Linux_Kernel_Newbies?action=LocalSiteMap

Thats the problem with documentation for the Kernel, as well it’s a world-wide project with countless people contributing, so you really need to find a version, dive DEEP into it (the one time I did was to fix a driver issue I had with a USB/wireless mouse... it was a headache).

The source itself is fairly well documented/maintained:

https://www.kernel.org/doc/html/latest/

All I can say, is good luck !! You’ll be a stronger person than I if you grasp the Kernel even minutely.

I think you might want to have a look at this (freely available) book: http://lwn.net/Kernel/LDD3/

The fourth edition will be out soon, a month or two, it still will help you until then. I partially used it to implement a char driver.

http://lwn.net/Articles/589183/

From one of the kpatch devs "Ksplice is apparently no longer GPL. The last source code release was in July 2011 when Oracle acquired them, and I think the code was already out of date at that time."

> So I'm apparently not allowed to just read memory like that.

Correct. The kernel only deals with Virtual Memory. You must construct a mapping between Physical Memory and Virtual Memory if you want to talk to your device. There are actually many different address ranges (I/O, DMA, PAE, etc) so you have to know which API to call.

Example: https://stackoverflow.com/questions/11621911/mapping-physical-addresses-to-virtual-address-linux#11644085

Can you show your Makefile and/or the command you used to build the module?

In general, you need to use the Makefile associated with the kernel that you are building against to have everything set up properly for building with the kernel version. For building against the kernel you are currently running, this can generally be done by running make -C /lib/modules/$(uname -r)/build M=$PWD as documented in <code>Documentation/kbuild/modules.txt</code>.

There is the kernel maintainers file: https://www.kernel.org/doc/linux/MAINTAINERS

There are a bunch of IIO driver entries in there, maybe try the generic iio subsystem entry:

IIO SUBSYSTEM AND DRIVERS [...] L: T: git git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git S: Maintained F: Documentation/devicetree/bindings/iio/ F: drivers/iio/ F: drivers/staging/iio/ F: include/linux/iio/ F: tools/iio/

Here I'd try the [email protected] list. Or if you know of another iio driver (maybe from the same vendor) then you can check if they have another more specific mailing list or maybe email the author directly.

Otherwise there's always the Linux kernel bugzilla https://bugzilla.kernel.org/ or just LKML ([email protected]), although I'm not sure you'd reach the right people using those.

I've been pretty successful learning from books, classes help a bit but mostly for teaching me about "unknown unknown's" that can be hard to find about on my own. Do you think that this text might be better as it just came out recently? https://www.amazon.com/Mastering-Linux-Device-Driver-Development/dp/178934204X

The topics covered seem interesting to me. Thanks for the resources, bootlin seems very useful

Speaking from zero experience with CAN, have you considered alloc_candev instead?

This might also be a good opportunity to use `gdb` to find the line number causing the panic.

You could backup Module.symvers

Then do a make clean and make modules_prepare

And move the Module.symvers back.

That way you will at least not have the binary files there. And it should be enough to compile kernel modules.

Distributions are more careful in what files they include in their kernel-headers packages but that's a lot of effort for not a all that much space saved.

With all due respect I would be very suspicious of someone who thinks an admin is going to be hacking the kernel. There's no such thing as not knowing miniscule detail if you're going to actually hack it - the devil is in the miniscule details. An admin doesnt go into a group of kernel developers and suggest code level changes. Linus does that ;) There are numerous books covering the kernel and umpteen guides online. This is the kind of intro overview that woulld be good for most I would think. https://www.kernel.org/doc/html/v4.16/process/howto.html

Quite simply, since you have kernel sources, you need to build the kernel before you can install it. So run "make".

You'll need openssl-devel headers too in your system, see dependencies:

https://www.kernel.org/doc/html/v5.11/process/changes.html

Like in listed in proc/cpuinfo ? Your kernel should already have mitigations built in.

MDS is a hardware bug. Get CPU from a different vendor maybe?

https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html

One thing I just thought of.. would kprobes be of help to you? The pre- and post-handlers of a kprobe are always executed from interrupt context, with preemption disabled. This consistency might be simpler than having to deal with whatever stack you've got in the task you interrupted.

> I was compiling in a VM on a 2015 macbook air, so that probably slowed things down a bit :) I don't remember, but it's also possible I might have only had a single core allocated to the VM.

I see, that certainly could be the reason.

> Regarding the TODO uid 100, we recently changed it to use module_param to set the uid/gid when loading the module.

Ahh, I was looking at an older commit.

> Whoa, seq_printf hashes the pointer for you if you use %p?

Everything that takes a format string will hash pointers when you use %p, it all comes down to lib/vsprintf.c. <code>printk()</code> is very powerful.

> I was hashing the pointer so as to identify struct files without exposing any info about the kernel memory layout.

A good rule of thumb is that if you thought of something, chances are, others have thought of it as well, and it's already implemented in the kernel... somewhere, somehow.

> I put break in the seq_has_overflowed(sfile) branch so that I can call put_task_struct on any remaining tasks, since any task in that list already had its reference count incremented in the first loop over the process list. I should probably add a comment there!

You're right, I missed the put_task_struct() somehow.

USB 4 is supported already. Not sure what release it was introduced in, but if you run the latest mainline you'll be fine.

https://www.kernel.org/doc/html/latest/admin-guide/thunderbolt.html

Thunderbolt 4 I'm not sure on. I don't see any commits, so I suspect the software side is backwards compatible and that most changes are physical layer.

PCIe 4.0 only contains physical layer changes, and is completely compatible with the existing software.

Okey the actually the reinstall of grub and installing android-udev solve a problem was i had. Now the actually question is>How i added the default kernel example this or other actual :4.10.1.1-ARCH .i actually when i tipe uname -r i have 4.19.58-1-lts

The spec for booting Linux on ARM is here: https://www.kernel.org/doc/Documentation/arm/Booting

Not mentioned is other stuff the bootloader does on most embedded platforms: - Initialize clocks - Initialize SDRAM - Initialize storage to load kernel & dtb from

Then it loads kernel and dtb from storage into RAM and prepares the entry as described in step #6.

Uimage is merely a wrapper around kernel and possibly other sub-images (xLinux, dtb, initramdisk).

I'm not aware of anything tracing a packet through the code.

ftrace is handy, as it can show a stack call trace (amongst other thing). But it does not do it on a per packet basis, and you have to know what functions to instrument (or drink from the fire hose).

Oh another thing. You don't say much about your use case but it sounds like you may be better using completions rather than a loop with msleep.

https://www.kernel.org/doc/Documentation/scheduler/completion.txt

The only operating systems with stable internal apis are dead operating systems.

Also, I documented why you really do not want this type of thing for your operating system many years ago here: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html

The internal apis for Linux are very unstable, which is good. The user/kernel api is very stable, which is also good. The combination of the two has allowed us to create something that has never been done before, so please don't ask for us to regress and make the same mistakes other operating systems did in the past.

Thanks for your answer !
I modified the file like i would have to do, but dont find any article explaining how to patch a kernel file.

Is this what i should do ?

Take a look at the kernel hacking doc.

https://www.kernel.org/doc/html/v4.13/kernel-hacking/locking.html

You should probably explain more clearly what you mean by using "within struct task_struct".

So this is necessarily system-specific. Different architectures and different boot protocols will do different things.

For the real mode x86 boot protocol, see this document. The boot loader loads the kernel and initial ramfs. The address and size of the initial ramfs are written into a data structure at a fixed offset in the loaded kernel image.

For EFI, see this document. The boot loader executes the kernel image with an initrd= command-line argument, and the kernel loads the initial ramfs itself using filesystem APIs provided by the EFI firmware.

It would be a lot of work for little improvement but yeah you could do that.

I don't remember the source, but I've read that if you disable udev (a tool to automatically make most drivers work) you could reduce the kernel size quite a bit. The drawback is that you'd need to recompile the kernel everytime you plug a new device so I think it's not really worth doing it. Would be interesting for learning though.

Since you are new I'm going to recommend you to check the ArchWiki. It's a really nice wiki that explains quite well everything related to linux. It's focused on the Arch distro, but some things are also useful for other distros. I usually search everything I need in that wiki, because it's really well explained.

Also there are some special kernels that focus on giving more performance for your system, you could use those if you don't want to compile a kernel. If you want to improve the performance you can follow this guide to change kernel parameters too

According to this: https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-init.html "similarly modules discard this memory after initialization", I think this is not what you intended to do. The fact you gave module_param this memory area, the kernel will try to free or access the area on module destruction/removal (see destroy_params in the traceback) and it will cause kernel oops because the memory area is not available. I assumed this is the case, Im not familiar with the internals of how the kernel handles module params, for further check see relevant code in the kernel.

hey u/xunilarium, please note that you should provide the complete version number of your kernel, not only "kernel 5". 4.x, 5.x, 6.x, ... the major number doesn't have a particular meaning. To get your kernel version use uname -r. Also, it would be helpful to say what distro (and what version) are you using now.

Regarding the problem, it seems that is a regression on your graphics card driver. To check which driver/module you are using, run this command: lspci -k | grep -EA3 'VGA|3D|Display'. Then, starting by opening a bug report (check this guide) on your distro with all the relevant information you can find. If you can manage to test different versions and find out which one is the first one to show the problem, it would be great.

For now, try using a LTS kernel, check with your distro how you can get one from your package manager.

When I started (quite some time ago), I read Robert Love's Linux Kernel Development book basically cover-to-cover. It's been through a few revisions since, and like all kernel development books it's perpetually out of date. Still, it's a good overview of the core kernel code, and from there you can branch out into other topics:

https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468

I read this one first, but I was already a Windows kernel developer, so... https://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652

Cool, I always wanted a guide like that - this seems like a nice guide to have.