nice!

In D47879#1091962, @markj wrote:

In D47879#1091930, @olce wrote:

In D47879#1091920, @kib wrote:

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

They have to, else the packed attribute would just be useless. Bugs should be filed against those that don't.

Yes, that would be a major compiler bug, I hope..

It might be that the better fix is to re-order members without introducing __packed. There is no ABI involved.

That doesn't seem possible as len and pad must stay first.

As far as I can see, this isn't true - the layout is up to the filesystem. The filesystem just needs to guarantee that fh1 == fh2 implies that the two FIDs refer to the same file.

I can't see any NFS code which peeks into the fid structure. Perhaps @rmacklem can confirm?

As far as I know, the NFS server code does not look inside the fid structure.

Yeah it seems #if 1 serves no useful documentary purpose

Updating, point to possible solution for what I need @mav to review (remove ->pic_enable_intr() call from clock.c/875b8844bec hack).

I managed to convert the driver to newbus but noticed slower performance of NVME when flushing cache using bus_write_8().

• direct access to pointer: 97.5MB/s
• using bus_write_8(): 93.3MB/s

So I provided another mapping for a faster access. WDYT?
another idea is to extract the mapping from sc->res and access it directly?

Thank you!

Do you have any idea on the inp->inp_socket->so_type != SOCK_STREAM check?

In D47879#1091930, @olce wrote:

In D47879#1091920, @kib wrote:

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

They have to, else the packed attribute would just be useless. Bugs should be filed against those that don't.

So if sys/_types.h won't suffice, I'd call out why in the commit message (this file makes no pretense of being namespace clean I think would be the reason.)

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

maybe tag as release notes since it's a removal?

In D47879#1091920, @kib wrote:

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

Sorry for bad comments... ignore them, and replace them with this:

I thought we'd already went this far

In D47879#1091770, @olce wrote:

I've checked that nobody takes the address of the unaligned members.

I thought we'd already went this far

But nested structures are a royal pain to emulate...

New system calls often retain the old name,

Oops, it looks like our last comments raced.

In D46301#1091722, @ae wrote:

I just tested these commands from PR:

ifconfig tun0 create
ifconfig tun0 10.10.10.10 20.20.20.20
route -n delete -host 20.20.20.20 -interface tun0

with this patch:

--- a/sys/netlink/route/rt.c
+++ b/sys/netlink/route/rt.c
@@ -1010,8 +1010,9 @@ rtnl_handle_delroute(struct nlmsghdr *hdr, struct nlpcb *nlp,
                return (EINVAL);
        }

+       int op_flags = (attrs.rta_rtflags & RTF_PINNED) ? RTM_F_FORCE : 0;
        error = rib_del_route_px(attrs.rta_table, attrs.rta_dst,
-           attrs.rtm_dst_len, path_match_func, &attrs, 0, &rc);
+           attrs.rtm_dst_len, path_match_func, &attrs, op_flags, &rc);
        if (error == 0)
                report_operation(attrs.rta_table, &rc, nlp, hdr);
        return (error);

It seems works as expected.

In D47883#1091835, @mhorne wrote:

I have never written or studied an sdhci driver in depth. Maybe @manu would like to look.

TODO: MMCCAM (?)

Same notes here: this looks fine as a glue driver, but I am not in the best position to evaluate PCIe. I hope you will monitor the upstreaming of linux/u-boot to eventually improve the magic initialization code.

Seems pretty straightforward.

Of course. Sorry. Got you. We have nested if()s now and not && like in the original code for the checks.

I have never written or studied an sdhci driver in depth. Maybe @manu would like to look.

In D47618#1086045, @brooks wrote:

I like the overall idea.

Add missing 32-bit compatibility code.

This corresponds to the ZPEN field in the VHE case and for me at least would have been clearer when trying to understand the VHE changes while merging them into CheriBSD.