Bug 242035 - pf/pflog failed to load after 12.1-RELEASE upgrade.
Summary: pf/pflog failed to load after 12.1-RELEASE upgrade.
Status: Closed DUPLICATE of bug 206583
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-pf mailing list
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-11-17 18:12 UTC by sasamotikomi
Modified: 2019-11-19 13:39 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sasamotikomi 2019-11-17 18:12:52 UTC
linker_load_file: /boot/kernel/pf.ko - unsupported file type
KLD pflog.ko: depends on pf - not available or version mismatch
linker_load_file: /boot/kernel/pflog.ko - unsupported file type
kernel: link_elf_load_file: vnet module space is out of space; cannot allocate 0x32d0 for /boot/kernel/pf.ko
linker_load_file: /boot/kernel/pf.ko - unsupported file type

I can reproduce it only with GENERIC kernel(I tried even download kernel binaries directly from CDN with same result) but modules load with custom kernel however can't be unloaded even if was pf stopped (also for some reason with custom kernel raw socked not permitted for not privilege users - ping: ssend socket: Operation not permitted) everything on bare metal not in jails.
Comment 1 Kristof Provost freebsd_committer 2019-11-17 18:16:37 UTC
What other kernel modules do you have loaded?
Comment 2 sasamotikomi 2019-11-17 18:27:52 UTC
(In reply to Kristof Provost from comment #1)
With which kernel GENERIC or custom?
Comment 3 Kristof Provost freebsd_committer 2019-11-17 18:29:10 UTC
With the generic kernel, where the pf.ko module refuses to load.
Comment 4 sasamotikomi 2019-11-17 19:07:31 UTC
(In reply to Kristof Provost from comment #3)

output of kldstat:
Id Refs Address                Size Name
 1   67 0xffffffff80200000  2448ef8 kernel
 2    1 0xffffffff8264a000     2e70 smb.ko
 3    2 0xffffffff8264d000     2f18 smbus.ko
 4    1 0xffffffff82650000     3978 cpuctl.ko
 5    1 0xffffffff82a21000     1aa0 fdescfs.ko
 6    1 0xffffffff82a23000     494c linprocfs.ko
 7    4 0xffffffff82a28000     3178 linux_common.ko
 8    1 0xffffffff82a2c000     1eae linsysfs.ko
 9    1 0xffffffff82a2e000     88d8 tmpfs.ko
10    1 0xffffffff82a37000   12acd0 i915kms.ko
11    1 0xffffffff82b62000    75f30 drm.ko
12    4 0xffffffff82bd8000    10eb0 linuxkpi.ko
13    3 0xffffffff82be9000    12f30 linuxkpi_gplv2.ko
14    2 0xffffffff82bfc000      6c0 debugfs.ko
15    1 0xffffffff82bfd000     3520 ichwd.ko
16    1 0xffffffff82c01000      b98 coretemp.ko
17    1 0xffffffff82c02000     2b88 acpi_video.ko
18    1 0xffffffff82c05000     c2a0 ip_mroute.ko
19    1 0xffffffff82c12000     18a0 uhid.ko
20    1 0xffffffff82c14000     2928 ums.ko
22    1 0xffffffff82c17000    3df60 linux.ko
23    1 0xffffffff82c55000    35b20 linux64.ko
Possible it's due 12.1 bad habit double load same kernel modules, example from dmesg of 12.1-GENERIC:
Starting devd.                                                                                                                                                  
Autoloading module: uhid.ko                                                                                                                                     
Autoloading module: ums.ko                                                                                                                                      
ums0 on uhub3                                                                                                                                                   
ums0: <vendor 0x1bcf USB Optical Mouse, class 0/0, rev 2.00/0.14, addr 2> on usbus0                                                                             
ums0: 3 buttons and [XYZT] coordinates ID=1                                                                                                                     
Autoloading module: uhid.ko                                                                                                                                     
Autoloading module: ums.ko
Comment 5 Bjoern A. Zeeb freebsd_committer 2019-11-17 22:12:02 UTC
I think we never fixed ip_mroute.ko, did we?   Probably my fault if we did not.  I'll go back and see and update here later (or tomorrow) either with a proper reference or a patch.

Ok, if I am not mistaken we have 8 PAGES = 32k of space for modules and the vnet_set for ip_mroute on amd64 (head) seems to be 21984 (~22k) alone.  I don't know how much more the other modules use .. hmm let me check:  pf ~13k (head, ouch)  pflog 144 bytes.

If this setup worked during 12.0 and no longer works in 12.1 then something has increased the vnet_set size in the modules.  Or did the update happen from 11?

I assume loading pf(log) without having loaded ip_mroute will work (could be compiled into the kernel).
I can produce a patch tomorrow for ip{,6}_mroute a least to stop this problem if you are willing to test?
Comment 6 sasamotikomi 2019-11-18 03:15:20 UTC
(In reply to Bjoern A. Zeeb from comment #5)
Yes, you're right pf can't be loaded along with ip_mroute and vice versa but in my custom kernel (minimal kernel without options which can be loaded as kernel modules except FFS and ALTQ) it's work. 
I'll test later old(12.0) kernel and your patches if can provide them for RELENG.
Comment 7 Bjoern A. Zeeb freebsd_committer 2019-11-19 13:39:21 UTC

*** This bug has been marked as a duplicate of bug 206583 ***