Seems ok to me.

Sorry for not having done this when I added the -fno-sanitize* pattern.

Thanks!

Please add Fixes: 8d5c7813061d ("libradius: Fix input validation bugs") to the commit log message.

In D45331#1037497, @alc wrote:

Please coordinate this with @markj given his lazy init change.

I guess vm_page_insert() could be improved similarly, but that's more work. IMO a better long-term direction there is to remove the memq (insertion into which is the purpose of looking up mpred in the first place) and use the radix tree for iteration instead, but that's a separate topic.

In D45476#1037353, @emaste wrote:

A wrinkle: PR196820 has a report of a system where using mrsas instead of mfi corrupted the volumes.

In D45161#1037296, @kib wrote:

In D45161#1037294, @markj wrote:

How does a debugger (gdb, lldb, ...) know about the special symbols? It needs custom code, instead of looking for the NT_GNU_BUILD_ID note. It seems preferable to avoid that.

Doesn't debugger need a special knowledge anyway, because .ko object files are not finally linked objects (.exe or dso), they do not have program headers and lot of other related stuff. In particular, they do not have PT_GNU_NOTE program header. On the other hand, correct debugger must not assume that sections are present at all in the finally linked objects. So .ko modules are quite special already.

I don't think we can do this for .o kernel modules. When loading .o files, the loader does not copy SHT_NOTE sections into memory. With a linker script we can push the contents of the .note.gnu.build-id section into .rodata, but then the input section is removed, so debuggers cannot find it. I cannot find a way to avoid this.

Isn't it same as the modinit sections? We find them with the special linker-generated start/stop symbols, which should be done for build-id sections as well.

We can add start/stop symbols but the section itself will not be loaded by the boot loader, since it has type SHT_NOTE. So far I do not see how it can work unless the loader is modified to load SHT_NOTE sections.

You said above, that the section can be moved into .rodata with the script, so I did not copied that part. I do not see why would the combination of these two (.note->.rodata + start/stop) would be not enough.

Because then the .note.gnu.build-id section is not present in the .ko file, so debuggers do not know how to find it (without some custom FreeBSD-specific code). The intent behind this patch is to make it possible for debuggers to verify the build-id of the target (I guess a vmcore or a live system) against on-disk files.

This is going in cicrles. The content of the section is moved into .rodata with the liner script. The start and end of the section are available by the values of the special start and end symbols. What else is needed for debuggers?

In D45476#1037286, @emaste wrote:

How about this text:

The hw.mfi.mrsas_enable tunable is now set to 1

It would be nice to include Diagnosed by: khng or similar, and a Fixes: tag.

Please be sure to document this in RELNOTES and UPDATING.

In D45161#1037249, @kib wrote:

In D45161#1037230, @markj wrote:

In D45161#1037216, @kib wrote:

In D45161#1037204, @markj wrote:

In D45161#1030122, @kib wrote:

In D45161#1030118, @aokblast wrote:

For preloaded relocatable kernel module, I think the modification of loader is necessary as I discover SHT_NOTE section was not loaded by boot1 originally when the kernel module is preloaded.

This is most likely can/should be fixed by linker script.

For shared object, actually we can get the address of uuid when kernel is loaded. I modify the loader because I discover that CTORS pass the information from loader and I think I should follow it?

Let me reformulate my point: this functionality (uuid module identification) should not depend on updated loader. I do not see why do we need to establish such requirement.

I don't think we can do this for .o kernel modules. When loading .o files, the loader does not copy SHT_NOTE sections into memory. With a linker script we can push the contents of the .note.gnu.build-id section into .rodata, but then the input section is removed, so debuggers cannot find it. I cannot find a way to avoid this.

Isn't it same as the modinit sections? We find them with the special linker-generated start/stop symbols, which should be done for build-id sections as well.

We can add start/stop symbols but the section itself will not be loaded by the boot loader, since it has type SHT_NOTE. So far I do not see how it can work unless the loader is modified to load SHT_NOTE sections.

You said above, that the section can be moved into .rodata with the script, so I did not copied that part. I do not see why would the combination of these two (.note->.rodata + start/stop) would be not enough.

In D45161#1037216, @kib wrote:

In D45161#1037204, @markj wrote:

In D45161#1030122, @kib wrote:

In D45161#1030118, @aokblast wrote:

For preloaded relocatable kernel module, I think the modification of loader is necessary as I discover SHT_NOTE section was not loaded by boot1 originally when the kernel module is preloaded.

This is most likely can/should be fixed by linker script.

For shared object, actually we can get the address of uuid when kernel is loaded. I modify the loader because I discover that CTORS pass the information from loader and I think I should follow it?

Let me reformulate my point: this functionality (uuid module identification) should not depend on updated loader. I do not see why do we need to establish such requirement.

I don't think we can do this for .o kernel modules. When loading .o files, the loader does not copy SHT_NOTE sections into memory. With a linker script we can push the contents of the .note.gnu.build-id section into .rodata, but then the input section is removed, so debuggers cannot find it. I cannot find a way to avoid this.

Isn't it same as the modinit sections? We find them with the special linker-generated start/stop symbols, which should be done for build-id sections as well.

In D45161#1030122, @kib wrote:

In D45161#1030118, @aokblast wrote:

For preloaded relocatable kernel module, I think the modification of loader is necessary as I discover SHT_NOTE section was not loaded by boot1 originally when the kernel module is preloaded.

This is most likely can/should be fixed by linker script.

For shared object, actually we can get the address of uuid when kernel is loaded. I modify the loader because I discover that CTORS pass the information from loader and I think I should follow it?

Let me reformulate my point: this functionality (uuid module identification) should not depend on updated loader. I do not see why do we need to establish such requirement.

@alc @dougm Do you have any more comments on this patch?

I committed a simpler version in a04ce833f9ba0.

I will go ahead and commit this if there aren't any objections. This bug just bit me again.

There are some special registers that an irq may not update, e.g. esr_el1 is not touched so it will be an unknown value based on the most recent synchronous exception.

Suppose there are two E820 entries with a hole in the middle, and then a new entry fills that hole. Then we could potentially merge the new entry with both the predecessor and successor. Do we need to handle that case?

We know that the generation is not properly reported by the new sysctl.