If this requires a specific src rev is there an OSVERSION that rev corresponds to so the port can test for it before it builds?

In D15307#402094, @jrmoede_gmail.com wrote:

Have a HighPoint 2840a that uses that uses this driver. How could I test this out?

In D18536#400013, @markj wrote:

In D18536#395272, @jpaetzel wrote:

In D18536#395145, @delphij wrote:

LGTM (the unlocked use of sc->ioctl_data_mem looks worrisome to me, but the proposed change won't worsen the situation). Do you have a chance to test this on real hardware? (@jpaetzel do you know someone who may be able to help with that?).

My last 9750 died a while ago. I'll ping Austin @ ix to see if he can rig up a system for us to test with.

Ping?

In D18536#395145, @delphij wrote:

LGTM (the unlocked use of sc->ioctl_data_mem looks worrisome to me, but the proposed change won't worsen the situation). Do you have a chance to test this on real hardware? (@jpaetzel do you know someone who may be able to help with that?).

What's the plan for ZFS then? This looks to me like using fstab for ZFS, which is suboptimal, or bespoke FreeBSD ZFS code.

In D15936#337243, @brooks wrote:

In D15936#337219, @jpaetzel wrote:

I'm not sure what the consequences of returning an error here are versus silently truncating. Before this change you'd have hostname "longerthan16chars.local" and it would get passed through as "longerthan16cha" but now mount_smbfs would fail with an error? If that assertion is true maybe it would be better just to copy and truncate at 16 than to return an error.

For the local host name, it seems that truncating to 15-bytes is the right thing. For the server name, it's probably a bug if we are given a server name larger than 16 bytes and we should fail.

I'm not sure what the consequences of returning an error here are versus silently truncating. Before this change you'd have hostname "longerthan16chars.local" and it would get passed through as "longerthan16cha" but now mount_smbfs would fail with an error? If that assertion is true maybe it would be better just to copy and truncate at 16 than to return an error.

Fix typo

Remove invalid UTF-8 from README

Confirmed the new patch works.

avg@ went so far as to verify the stock CentOS kernel included that commit you are referencing, and it does.

For what it's worth the system where I saw this is running the latest version of CentOS 7.4, which has an old kernel, but not that old. But just to be sure I updated it's kernel to 4.15.12 and the problem persisted. I'll test the patch though.

For that to happen the original author will need a commit bit, which I'll be more than happy to mentor.

I reverted this commit. We need more consensus before continuing.

LGTM

The path for the file to be patched is wrong, the original is correct in this case. The code change does fix the kernel panic when the module is loaded.

Oh, I missed the link to the bug which has the full diff and poudriere logs.

As long as this passes poudriere testport and portlint it looks good to me.