LinuxKPI: Implement linux/hashtable.h for FreeBSD.

[• hselasky]

Summary

This implementation uses the concurrency kit, CK, API directly which is
suitable for use with EPOCH(9) and RCU under FreeBSD.

No functional change intended.

The initial "linux/hash.h" code was obtained from DragonFlyBSD via FreeBSD's drm-kmod in ports.

MFC after: 1 week
Sponsored by: NVIDIA Networking

Test Plan

cd /usr/ports/graphics/*fbsd13
make extract
rm ./work/drm-kmod-drm_*/linuxkpi/gplv2/include/linux/hashtable.h
rm ./work/drm-kmod-drm_*/linuxkpi/bsd/include/linux/hash.h
make all

[• hselasky]

manu@ : Could you do a quick test with graphics drivers ?

[• hselasky]

sys/compat/linuxkpi/common/include/linux/hashtable.h

163

NOTE: This container_of() could have been skipped, if it wasn't for how Linux defined the hashtable API!

[bz]

I'll give this a try tonight as well and have a closer look.
It's one of two missing pieces I need; in theory kfifo is the other one but I think that is used so little that I might simply change the code?

I'd probably would help to mention where the hash.h with a 2013 copyright was obtained from.

[markj]

sys/compat/linuxkpi/common/include/linux/hash.h

3

Add an SPDX tag?

sys/compat/linuxkpi/common/include/linux/hashtable.h

3

Here too.

93

So hash_del_rcu() clears this pointer after removing the element, but what if the element was never inserted to begin with? In other words, how does a node get initialized?

[emaste]

sys/compat/linuxkpi/common/include/linux/hash.h

39

Presumably fine for our use cases but really we ought to have a hash_64 that returns up to 64 bits?

54

Not just amd64 for FreeBSD

[• hselasky]

sys/compat/linuxkpi/common/include/linux/hash.h

3

Yes, good point.

54

I'll update that tomorrow. Was so in the original I used from the DRM kmod.

sys/compat/linuxkpi/common/include/linux/hashtable.h

93

There is a hidden assumption in Linux that if this feature is used, that memory is allocated with kzalloc or M_ZERO .

[bz]

Makes more code compile for me too. Thank you!

sys/compat/linuxkpi/common/include/linux/hashtable.h

93

Should we then KASSERT that on add it's NULL to better guard against (upstream not detected) broken code?

[• hselasky]

sys/compat/linuxkpi/common/include/linux/hash.h

39

Fixed.

[• hselasky]

Implement suggestions from bz@ and markj@ .

[• hselasky]

@manu: Where was "include/linux/hash.h" obtained from?

[manu]

In D35162#797271, @hselasky wrote:

@manu: Where was "include/linux/hash.h" obtained from?

This predates my involvment with drm-kmod but looking at the header I'd say DragonFlyBSD.

[bz]

I'd probably say "Dragonfly via drm-kmod" as you obtained it from drm-kmod?

[• hselasky]

In D35162#797274, @bz wrote:

I'd probably say "Dragonfly via drm-kmod" as you obtained it from drm-kmod?

Yes, that's correct.

Do we need to bump the FreeBSD version for this - no?

[bz]

Do we need to bump the FreeBSD version for this - no?

I'll leave that to @manu on how to deal with possible conflicts or if it is a problem with drm-kmod ports/packages.

[manu]

In D35162#797277, @hselasky wrote:

In D35162#797274, @bz wrote:

I'd probably say "Dragonfly via drm-kmod" as you obtained it from drm-kmod?

Yes, that's correct.

Do we need to bump the FreeBSD version for this - no?

It's not needed, drm-kmod will still use the version there and we can switch that whenever we want.

[markj]

The loop macros look right to me after staring at them for a while, just some style nits.

sys/compat/linuxkpi/common/include/linux/hashtable.h

89

Style, lines are too long.

93

Looking at Linux, they do explicit zeroing in INIT_HLIST_NODE.

165

Lines are too long here as well.

[• hselasky]

sys/compat/linuxkpi/common/include/linux/hashtable.h

93

Nice to know.

[• hselasky]

Address some long lines and improve some type asserts.