Re: NFSv4 crash of CURRENT

[Peter Blok]

Rick,

I can confirm Kostik’s fix works on 13-stable.

Peter

> On 15 Jan 2024, at 16:13, Peter Blok  wrote:
> 
> I can give it a shot on one of my clients.
> 
>> On 15 Jan 2024, at 16:04, Rick Macklem > <mailto:rick.mack...@gmail.com>> wrote:
>> 
>> On Mon, Jan 15, 2024 at 2:53 AM Peter Blok > <mailto:pb...@bsd4all.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
>>> automounted NFS is:
>>> 
>>> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
>>> Author: Konstantin Belousov mailto:k...@freebsd.org>>
>>> Date:   Tue Jan 2 00:22:44 2024 +0200
>>> 
>>>nfsclient: limit situations when we do unlocked read-ahead by nfsiod
>>> 
>>>(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
>>> 
>>> When I remove the fix, the problem is gone. Add it back and the crash 
>>> happens.
>> Kostik has already come up with a probable fix. If you want it right
>> away, here it is,
>> but he'll probably commit it soon anyhow:
>> diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
>> index c027d7d7c3fd..1cf45bb0c924 100644
>> --- a/sys/fs/nfsclient/nfs_clbio.c
>> +++ b/sys/fs/nfsclient/nfs_clbio.c
>> @@ -414,6 +414,18 @@ nfs_bioread_check_cons(struct vnode *vp, struct
>> thread *td, struct ucred *cred)
>>return (error);
>> }
>> 
>> +static bool
>> +ncl_bioread_dora(struct vnode *vp)
>> +{
>> +   vm_object_t obj;
>> +
>> +   obj = vp->v_object;
>> +   if (obj == NULL)
>> +   return (true);
>> +   return (!vm_object_mightbedirty(vp->v_object) &&
>> +   vp->v_object->un_pager.vnp.writemappings == 0);
>> +}
>> +
>> /*
>>  * Vnode op for read using bio
>>  */
>> @@ -486,9 +498,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
>> ioflag, struct ucred *cred)
>> * unlocked read by nfsiod could obliterate changes
>> * done by userspace.
>> */
>> -   if (nmp->nm_readahead > 0 &&
>> -   !vm_object_mightbedirty(vp->v_object) &&
>> -   vp->v_object->un_pager.vnp.writemappings == 0) {
>> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp)) {
>>for (nra = 0; nra < nmp->nm_readahead && nra < seqcount &&
>>(off_t)(lbn + 1 + nra) * biosize < nsize; nra++) {
>>rabn = lbn + 1 + nra;
>> @@ -675,9 +685,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
>> ioflag, struct ucred *cred)
>> *  directory offset cookie of the next block.)
>> */
>>NFSLOCKNODE(np);
>> -   if (nmp->nm_readahead > 0 &&
>> -   !vm_object_mightbedirty(vp->v_object) &&
>> -   vp->v_object->un_pager.vnp.writemappings == 0 &&
>> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
>>(bp->b_flags & B_INVAL) == 0 &&
>>(np->n_direofoffset == 0 ||
>>(lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
>> 
>> rick
>> ps: It appears that autofs causes the directory to be read before it
>> is open'd for
>>  some reason. I've never looked at autofs.
>> 
>>> 
>>> Peter
>>> 
>>> On 15 Jan 2024, at 09:31, Peter Blok >> <mailto:pb...@bsd4all.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I do have a crash on a NFS client with stable of today 
>>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. 
>>> Maybe it is the same problem.
>>> 
>>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
>>> tab to autocomplete it crashes with the below stack trace. If I plainly 
>>> mount ports on /usr/ports and do the same everything works. I am using NFSv3
>>> 
>>> Peter
>>> 
>>> 
>>> 
>>> 
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2; apic id = 04
>>> fault virtual address = 0x89
>>> fault code = supervisor read data, page not present
>>> instruction pointer = 0x20:0x809645d4
>>&

Re: NFSv4 crash of CURRENT

[Peter Blok]

I can give it a shot on one of my clients.

> On 15 Jan 2024, at 16:04, Rick Macklem  wrote:
> 
> On Mon, Jan 15, 2024 at 2:53 AM Peter Blok  <mailto:pb...@bsd4all.org>> wrote:
>> 
>> Hi,
>> 
>> Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
>> automounted NFS is:
>> 
>> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
>> Author: Konstantin Belousov 
>> Date:   Tue Jan 2 00:22:44 2024 +0200
>> 
>>nfsclient: limit situations when we do unlocked read-ahead by nfsiod
>> 
>>(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
>> 
>> When I remove the fix, the problem is gone. Add it back and the crash 
>> happens.
> Kostik has already come up with a probable fix. If you want it right
> away, here it is,
> but he'll probably commit it soon anyhow:
> diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
> index c027d7d7c3fd..1cf45bb0c924 100644
> --- a/sys/fs/nfsclient/nfs_clbio.c
> +++ b/sys/fs/nfsclient/nfs_clbio.c
> @@ -414,6 +414,18 @@ nfs_bioread_check_cons(struct vnode *vp, struct
> thread *td, struct ucred *cred)
>return (error);
> }
> 
> +static bool
> +ncl_bioread_dora(struct vnode *vp)
> +{
> +   vm_object_t obj;
> +
> +   obj = vp->v_object;
> +   if (obj == NULL)
> +   return (true);
> +   return (!vm_object_mightbedirty(vp->v_object) &&
> +   vp->v_object->un_pager.vnp.writemappings == 0);
> +}
> +
> /*
>  * Vnode op for read using bio
>  */
> @@ -486,9 +498,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> * unlocked read by nfsiod could obliterate changes
> * done by userspace.
> */
> -   if (nmp->nm_readahead > 0 &&
> -   !vm_object_mightbedirty(vp->v_object) &&
> -   vp->v_object->un_pager.vnp.writemappings == 0) {
> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp)) {
>for (nra = 0; nra < nmp->nm_readahead && nra < seqcount &&
>(off_t)(lbn + 1 + nra) * biosize < nsize; nra++) {
>rabn = lbn + 1 + nra;
> @@ -675,9 +685,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> *  directory offset cookie of the next block.)
> */
>NFSLOCKNODE(np);
> -   if (nmp->nm_readahead > 0 &&
> -   !vm_object_mightbedirty(vp->v_object) &&
> -   vp->v_object->un_pager.vnp.writemappings == 0 &&
> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
>(bp->b_flags & B_INVAL) == 0 &&
>(np->n_direofoffset == 0 ||
>(lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
> 
> rick
> ps: It appears that autofs causes the directory to be read before it
> is open'd for
>  some reason. I've never looked at autofs.
> 
>> 
>> Peter
>> 
>> On 15 Jan 2024, at 09:31, Peter Blok  wrote:
>> 
>> Hi,
>> 
>> I do have a crash on a NFS client with stable of today 
>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe 
>> it is the same problem.
>> 
>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
>> tab to autocomplete it crashes with the below stack trace. If I plainly 
>> mount ports on /usr/ports and do the same everything works. I am using NFSv3
>> 
>> Peter
>> 
>> 
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 04
>> fault virtual address = 0x89
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0x809645d4
>> stack pointer= 0x28:0xfe00acadb830
>> frame pointer= 0x28:0xfe00acadb830
>> code segment = base 0x0, limit 0xf, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process = 6869 (csh)
>> trap number = 12
>> panic: page fault
>> cpuid = 2
>> time = 1705306940
>> KDB: stack backtrace:
>> #0 0x806232f5 at kdb_backtrace+0x65
>> #1 0x805d7a02 at vpanic+0x152
>> #2 0x805d78a3 at panic+0x43
>> #3 0x809d58ad at trap_fatal+0x38d
>> #4 0x

Re: NFSv4 crash of CURRENT

[Peter Blok]

Hi,

Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
automounted NFS is:

commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
Author: Konstantin Belousov 
Date:   Tue Jan 2 00:22:44 2024 +0200

nfsclient: limit situations when we do unlocked read-ahead by nfsiod

(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)

When I remove the fix, the problem is gone. Add it back and the crash happens.

Peter

> On 15 Jan 2024, at 09:31, Peter Blok  wrote:
> 
> Hi,
> 
> I do have a crash on a NFS client with stable of today 
> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe 
> it is the same problem.
> 
> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
> tab to autocomplete it crashes with the below stack trace. If I plainly mount 
> ports on /usr/ports and do the same everything works. I am using NFSv3
> 
> Peter
> 
> 
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 04
> fault virtual address = 0x89
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x809645d4
> stack pointer = 0x28:0xfe00acadb830
> frame pointer = 0x28:0xfe00acadb830
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 6869 (csh)
> trap number   = 12
> panic: page fault
> cpuid = 2
> time = 1705306940
> KDB: stack backtrace:
> #0 0x806232f5 at kdb_backtrace+0x65
> #1 0x805d7a02 at vpanic+0x152
> #2 0x805d78a3 at panic+0x43
> #3 0x809d58ad at trap_fatal+0x38d
> #4 0x809d58ff at trap_pfault+0x4f
> #5 0x809af048 at calltrap+0x8
> #6 0x804c7a7e at ncl_bioread+0xb7e
> #7 0x804b9d90 at nfs_readdir+0x1f0
> #8 0x8069c61a at vop_sigdefer+0x2a
> #9 0x809f8ae0 at VOP_READDIR_APV+0x20
> #10 0x81ce75de at autofs_readdir+0x2ce
> #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> #12 0x806c3002 at kern_getdirentries+0x222
> #13 0x806c33a9 at sys_getdirentries+0x29
> #14 0x809d6180 at amd64_syscall+0x110
> #15 0x809af95b at fast_syscall_common+0xf8
> 
> 
> 
>> On 15 Jan 2024, at 06:46, FreeBSD User > <mailto:free...@walstatt-de.de>> wrote:
>> 
>> Am Sun, 14 Jan 2024 20:34:12 -0800
>> Cy Schubert mailto:cy.schub...@cschubert.com>> 
>> schrieb:
>> 
>>> In message 
>>> >> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c>
>>> om>  
>>> , Rick Macklem writes:
>>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop >>> <mailto:ronald-li...@klop.ws>>=
>>>> wrote:  
>>>>> 
>>>>> 
>>>>> Van: FreeBSD User mailto:free...@walstatt-de.de>>
>>>>> Datum: 13 januari 2024 19:34
>>>>> Aan: FreeBSD CURRENT >>>> <mailto:freebsd-current@freebsd.org>>
>>>>> Onderwerp: NFSv4 crash of CURRENT
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> running CURRENT client (FreeBSD 15.0-CURRENT #4 
>>>>> main-n267556-69748e62e82a=  
>>>> : Sat Jan 13 18:08:32  
>>>>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned 
>>>>> cl=  
>>>> ient, other is FreeBSD  
>>>>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
>>>>> 
>>>>> I can crash the client reproducable by accessing the one or other NFSv4 
>>>>> F=  
>>>> S (a simple ls -la).  
>>>>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla 
>>>>> a=  
>>>> ccess to the client  
>>>>> host, luckily the box recovers.  
>>>> Did you rebuild both the nfscommon and nfscl modules from the same sources?
>>>> I did a commit to main that changes the interface between these two
>>>> modules and did bump the
>>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
>>>> (If you have "options NFSCL" in your kernel config, both should have
>>>> been rebuilt as a part of
>>>> the kernel build.)
>>>> 
>>> 
>>> Is anyone by chance seeing autofs in the backtrace too?
>>> 
>>> 
>> 
>> Hello Cy Shubert,
>> 
>> I forgot to mention that those crashes occur with autofs mounted 
>> filesystems. Good question,
>> by the way, I will check whether crashes also happen when mounting the 
>> tradidional way.
>> 
>> Kind regards,
>> 
>> oh
>> 
>> -- 
>> O. Hartmann
> 

Re: NFSv4 crash of CURRENT

[Peter Blok]

Hi,

I do have a crash on a NFS client with stable of today 
(4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe it 
is the same problem.

I have ports automounted on /am/ports. When I do cd /am/ports/sys and type tab 
to autocomplete it crashes with the below stack trace. If I plainly mount ports 
on /usr/ports and do the same everything works. I am using NFSv3

Peter




Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x89
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x809645d4
stack pointer   = 0x28:0xfe00acadb830
frame pointer   = 0x28:0xfe00acadb830
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 6869 (csh)
trap number = 12
panic: page fault
cpuid = 2
time = 1705306940
KDB: stack backtrace:
#0 0x806232f5 at kdb_backtrace+0x65
#1 0x805d7a02 at vpanic+0x152
#2 0x805d78a3 at panic+0x43
#3 0x809d58ad at trap_fatal+0x38d
#4 0x809d58ff at trap_pfault+0x4f
#5 0x809af048 at calltrap+0x8
#6 0x804c7a7e at ncl_bioread+0xb7e
#7 0x804b9d90 at nfs_readdir+0x1f0
#8 0x8069c61a at vop_sigdefer+0x2a
#9 0x809f8ae0 at VOP_READDIR_APV+0x20
#10 0x81ce75de at autofs_readdir+0x2ce
#11 0x809f8ae0 at VOP_READDIR_APV+0x20
#12 0x806c3002 at kern_getdirentries+0x222
#13 0x806c33a9 at sys_getdirentries+0x29
#14 0x809d6180 at amd64_syscall+0x110
#15 0x809af95b at fast_syscall_common+0xf8



> On 15 Jan 2024, at 06:46, FreeBSD User  wrote:
> 
> Am Sun, 14 Jan 2024 20:34:12 -0800
> Cy Schubert mailto:cy.schub...@cschubert.com>> 
> schrieb:
> 
>> In message > om>  
>> , Rick Macklem writes:
>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
>>> wrote:  
 
 
 Van: FreeBSD User 
 Datum: 13 januari 2024 19:34
 Aan: FreeBSD CURRENT 
 Onderwerp: NFSv4 crash of CURRENT
 
 Hello,
 
 running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a= 
  
>>> : Sat Jan 13 18:08:32  
 CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl= 
  
>>> ient, other is FreeBSD  
 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
 
 I can crash the client reproducable by accessing the one or other NFSv4 F= 
  
>>> S (a simple ls -la).  
 The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a= 
  
>>> ccess to the client  
 host, luckily the box recovers.  
>>> Did you rebuild both the nfscommon and nfscl modules from the same sources?
>>> I did a commit to main that changes the interface between these two
>>> modules and did bump the
>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
>>> (If you have "options NFSCL" in your kernel config, both should have
>>> been rebuilt as a part of
>>> the kernel build.)
>>> 
>> 
>> Is anyone by chance seeing autofs in the backtrace too?
>> 
>> 
> 
> Hello Cy Shubert,
> 
> I forgot to mention that those crashes occur with autofs mounted filesystems. 
> Good question,
> by the way, I will check whether crashes also happen when mounting the 
> tradidional way.
> 
> Kind regards,
> 
> oh
> 
> -- 
> O. Hartmann

Re: CFT: if_bridge performance improvements

[peter . blok]

Just using pf is enough to provoke this panic. I had the same back trace. This 
patch from Kristof fixed it for me.

diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 373fa096d70..83c453090bb 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2529,7 +2529,6 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
 OR_PFIL_HOOKED_INET6)) {   \
if (bridge_pfil(, NULL, ifp,  \
PFIL_IN) != 0 || m == NULL) {   \
-   BRIDGE_UNLOCK(sc);  \
return (NULL);  \
}   \
eh = mtod(m, struct ether_header *);\


> On 22 Apr 2020, at 18:15, Xin Li  wrote:
> 
> On 4/22/20 01:45, Kristof Provost wrote:
>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>> Hi,
>>> 
>>> On 4/14/20 02:51, Kristof Provost wrote:
 Hi,
 
 Thanks to support from The FreeBSD Foundation I’ve been able to work on
 improving the throughput of if_bridge.
 It changes the (data path) locking to use the NET_EPOCH infrastructure.
 Benchmarking shows substantial improvements (x5 in test setups).
 
 This work is ready for wider testing now.
 
 It’s under review here: https://reviews.freebsd.org/D24250
 
 Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
 Patches for stable/12:
 https://people.freebsd.org/~kp/if_bridge/stable_12/
 
 I’m not currently aware of any panics or issues resulting from these
 patches.
>>> 
>>> I have observed the following panic with latest stable/12 after applying
>>> the stable_12 patchset, it appears like a race condition related NULL
>>> pointer deference, but I haven't took a deeper look yet.
>>> 
>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>> acting as a router.  Please let me know if you need additional
>>> information; I can try -CURRENT as well, but it would take some time as
>>> the box is relatively slow (it's a ZFS based system so I can create a
>>> separate boot environment for -CURRENT if needed, but that would take
>>> some time as I might have to upgrade the packages, should there be any
>>> ABI breakages).
>>> 
>> Thanks for the report. I don’t immediately see how this could happen.
>> 
>> Are you running an L2 firewall on that bridge by any chance? An earlier
>> version of the patch had issues with a stray unlock in that code path.
> 
> I don't think I have a L2 firewall (I assume means filtering based on
> MAC address like what can be done with e.g. ipfw?  The bridges were
> created on vlan interfaces though, do they count as L2 firewall?), the
> system is using pf with a few NAT rules:
> 
> $ sudo pfctl -s rules
> anchor "miniupnpd" all
> pass in quick inet6 proto tcp from  to any flags S/SA keep state
> block drop in quick inet6 proto tcp from !  to  flags S/SA
> block drop in quick proto tcp from any os "Linux" to any port = ssh
> pass out on igb6 inet proto tcp from (igb6) to any port = domain flags
> S/SA keep state queue dns
> pass out on igb6 inet proto udp from (igb6) to any port = domain keep
> state queue dns
> pass in on igb6 proto tcp from any to (igb6) port = http flags S/SA
> modulate state queue(web, ack)
> pass in on igb6 proto tcp from any to (igb6) port = https flags S/SA
> modulate state queue(web, ack)
> pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
> state queue bulk
> block drop in quick on igb6 proto tcp from  to any port = ssh
> label "ssh bruteforce"
> block drop in on igb6 from  to any
> 
> Cheers,

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: INTRNG

[peter . blok]

While on the subject INTRNG - does anybody know the status of handling GPIO 
interrupts with queue/kevent?

There were some patches before INTRNG, but they require some work.

Peter

> On 23 Feb 2018, at 07:25, Jon Brawn  wrote:
> 
> Wotcha Gang!
> 
> In my travels through the arm64 GENERIC config file I came across the option 
> ‘INTRNG’, and wondered what it was:
> 
> INTeRrupt Next Generation?
> INTeger Random Number Generator?
> IN TRaiNinG?
> INTerrupt Random Number Generator?
> INdependent TRaiNinG?
> 
> So, please put me out of my misery, what does INTRNG stand for, and what are 
> its implications when selected vs not selected?
> 
> Cheers!
> 
> Jon.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Time to increase MAXPHYS?

[peter . blok]

One area that breaks after changing MAXPHYS from 128K to 1MB is the iscsi 
target. I don’t have details, because that server is semi-production and I 
reverted it back ASAP
> On 5 Jun 2017, at 19:49, Edward Tomasz Napierała  wrote:
> 
> On 0604T0952, Hans Petter Selasky wrote:
>> On 06/04/17 09:39, Tomoaki AOKI wrote:
>>> Hi
>>> 
>>> One possibility would be to make it MD build-time OTIONS,
>>> defaulting 1M on regular systems and 128k on smaller systems.
>>> 
>>> Of course I guess making it a tunable (or sysctl) would be best,
>>> though.
>>> 
>> 
>> Hi,
>> 
>> A tunable sysctl would be fine, but beware that commonly used firmware 
>> out there produced in the millions might hang in a non-recoverable way 
>> if you exceed their "internal limits". Conditionally lowering this 
>> definition is fine, but increasing it needs to be carefully verified.
>> 
>> For example many USB devices are only tested with OS'es like Windows and 
>> MacOS and if these have any kind of limitation on the SCSI transfer 
>> sizes, it is very likely many devices out there do not support any 
>> larger transfer sizes either.
> 
> FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed
> that both issue 1MB requests.  I wouldn't be surprised if they avoided
> doing that for older devices, depending on eg the SCSI version reported
> by device.
> 
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> 
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> "

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic with jail bug_id 213673 was: VNET branch destiny

[peter . blok]

The problem happens when stopping a jail. It doesn’t seem to be related to vnet 
at all.

When stopping a jail, pfr_cleanup calls uma_zdestroy(V_pfr_kentry_z). The dtor 
calls zone_release, which calls slab_free_item. The issue seems to be that the 
keg found in zone_release does not belong to the zone that is to be destroyed, 
but belongs to the zone that is created for the same purpose at the host. The 
zone belongs to the jail (verified). The added if (marked with XXX) fixes the 
problem.

I don’t understand how a keg ends up in a different zone.

zone_release(uma_zone_t zone, void **bucket, int cnt)
{
void *item;
uma_slab_t slab;
uma_keg_t keg;
uint8_t *mem;
int clearfull;
int i;

clearfull = 0;
keg = zone_first_keg(zone);
KEG_LOCK(keg);
for (i = 0; i < cnt; i++) {
item = bucket[i];
if (!(zone->uz_flags & UMA_ZONE_VTOSLAB)) {
mem = (uint8_t *)((uintptr_t)item & (~UMA_SLAB_MASK));
if (zone->uz_flags & UMA_ZONE_HASH) {
slab = hash_sfind(>uk_hash, mem);
} else {
mem += keg->uk_pgoff;
slab = (uma_slab_t)mem;
}
} else {
slab = vtoslab((vm_offset_t)item);
if (slab->us_keg != keg) {
KEG_UNLOCK(keg);
keg = slab->us_keg;
KEG_LOCK(keg);
}
}
if (keg == slab->us_keg)// XXX 
seems to fix the problem
slab_free_item(keg, slab, item);

> On 11 Apr 2017, at 13:43, peter.b...@bsd4all.org wrote:
> 
> Hi Kristof,
> 
> I’m prety sure it is the same as 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 
> . It is unrelated 
> to epair or ng_eiface (my case).
> 
> I’ll dig some more.
> 
> Peter
> 
> 
>> On 11 Apr 2017, at 08:47, Kristof Provost  wrote:
>> 
>> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>>> There have been issues with pf if I recall correctly. I currently have 
>>> issues with stable, pf and vnet. There is an issue with pf table entries 
>>> when an interface is moved to a different vnet.
>>> 
>>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>>> to stable? I haven’t had the time to test this on current.
>>> 
>> I’m currently aware of at least some issues with pf and vnet, even in 
>> CURRENT.
>> Not that one though, so can you make sure there’s a bug report with as much 
>> detail as possible?
>> Please also cc me (k...@freebsd.org) on the report.
>> 
>> Thanks,
>> Kristof
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[peter . blok]

Hi Kristof,

I’m prety sure it is the same as 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 
. It is unrelated to 
epair or ng_eiface (my case).

I’ll dig some more.

Peter


> On 11 Apr 2017, at 08:47, Kristof Provost  wrote:
> 
> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> 
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> 
> I’m currently aware of at least some issues with pf and vnet, even in CURRENT.
> Not that one though, so can you make sure there’s a bug report with as much 
> detail as possible?
> Please also cc me (k...@freebsd.org) on the report.
> 
> Thanks,
> Kristof

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[peter . blok]

No problem. Although pf is not used the vnet_destroy seems to be the issue. 
Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown 
happens on the host vnet so to speak.


> On 10 Apr 2017, at 22:11, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, 
>> not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It 
>> is my intention to use the netgrpah bridge with bhyve as well.
> 
> 
> I also tested using Devin Teske’s jng to create a netgraph bridge on
> RELEASE 10.0 and it worked. But when I tried the same configuration on
> RELEASE 11.0 it no longer worked.
> 
> Sorry for the noise. I missed this sentence. "I’m only using pf on the
> host, not in the jail.". Thats what happens when I answer email after a long 
> day at work.
> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[peter . blok]

Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not 
in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my 
intention to use the netgrpah bridge with bhyve as well.

The panic (one-time) happened in pfioctl when I refreshed the rules. I suspect 
the problem is related to the following message when I stop the jail.

kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost -57 
pages of memory.

Current does not display the UMA message. I’m still narrowing down what happens 
with the pf table entries. My suspicion is that the netgraph bridge which 
creates a ng_ether device which is handed over to the jail vnet, is causing 
this.


The panic happened on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;

mtx_assert(>uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;

for (;;) {
/*
 * Find a slab with some space.  Prefer slabs that are partially
 * used over those that are totally full.  This helps to reduce
 * fragmentation.
 */
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(>uk_part_slab)) {
slab = LIST_FIRST(>uk_part_slab);
} else {
slab = LIST_FIRST(>uk_free_slab);
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(>uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}

KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb

The panic is so far not reproducible.


> On 10 Apr 2017, at 15:50, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> Peter
> 
> PF was fixed in 11.0 to not panic when run on a host that has vimage compiled 
> into the kernel. On 11.0 you can configure pf to run in a vnet jail but it 
> really does not enforce any firewall rules because pf needs access to the 
> kernel which jail(8) is blocking by design. As far as I know this is a show 
> shopper that can not be fixed without a pf rewrite changing the way it works 
> internally.
> 
> This PR gives all the details
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[peter . blok]

There have been issues with pf if I recall correctly. I currently have issues 
with stable, pf and vnet. There is an issue with pf table entries when an 
interface is moved to a different vnet.

Does anyone no if there is a specific fix for this that hasn’t been ported to 
stable? I haven’t had the time to test this on current.

Peter
> On 10 Apr 2017, at 08:50, Pavel Timofeev  wrote:
> 
> 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
> bzeeb-li...@lists.zabbadoz.net> написал:
> 
> On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:
> 
> Hello, dear freebsd-current@!
>> 
>> There was FreeBSD Foundation report back in 2016Q2 where it told us
>> about VNET (VIMAGE) update project sponsored by foundation.
>> What is the current situation? Is it committed into base? If not
>> what's the plan?
>> 
> 
> Changes are in 12 and 11.   12 has seen more slight fixes due to other
> changes that other committers are tracking and I hope they merge to 11.
> 
> /bz
> 
> 
> Sorry, do you know if there is any plan to include VNET into GENERIC?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC/RFT] projects/ipsec

[peter . blok]

Andrey,

Is this going to MFC'ed to stable-11 in the future? I have tested with current 
and found no issues, but I would like to add it to a semi-production 
environment running stable-11

Peter


> On 6 Feb 2017, at 10:07, Andrey V. Elsukov  wrote:
> 
> On 11.12.2016 02:07, Andrey V. Elsukov wrote:
>> I am pleased to announce that projects/ipsec, that I started several
>> months ago is ready for testing and review.
>> The main goals were:
>>  * rework locking to make IPsec code more friendly for concurrent
>>processing;
>>  * make lookup in SADB/SPDB faster;
>>  * revise PFKEY implementation, remove stale code, make it closer
>>to RFC;
>>  * implement IPsec VTI (virtual tunneling interface);
>>  * make IPsec code loadable as kernel module.
> 
> JFYI, the project was merged into head/ in r313330.
> 
> -- 
> WBR, Andrey V. Elsukov
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: crash in iflib_fast_intr

[peter . blok]

This is with an igb interface.

Peter
> On 18 Jan 2017, at 15:31, Sean Bruno  wrote:
> 
> 
> 
> On 01/18/17 03:37, peter.b...@bsd4all.org  
> wrote:
>> Hi,
>> 
>> A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
>> GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
>> reproducible.
>> 
>> KDB: stack backtrace:
>> #0 0x805cec97 at kdb_backtrace+0x67
>> #1 0x80584816 at vpanic+0x186
>> #2 0x80584683 at panic+0x43
>> #3 0x8090f222 at trap_fatal+0x322
>> #4 0x8090f3ec at trap_pfault+0x1bc
>> #5 0x8090eaa0 at trap+0x280
>> #6 0x808f35e1 at calltrap+0x8
>> #7 0x806a202d at iflib_fast_intr+0x3d
>> #8 0x8054963b at intr_event_handle+0x9b
>> #9 0x80965f38 at intr_execute_handlers+0x48
>> #10 0x8096b1cf at lapic_handle_intr+0x3f
>> #11 0x808f3cc7 at Xapic_isr1+0xb7
>> #12 0x805b994a at sched_idletd+0x37a
>> #13 0x805460f5 at fork_exit+0x85
>> #14 0x808f3b1e at fork_trampoline+0xe
>> 
>> Peter
> 
> Thanks for the report.  We're looking at this.
> 
> This is with an igb(4) interface or em(4)?
> 
> sean

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

crash in iflib_fast_intr

[peter . blok]

Hi,

A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
reproducible.

KDB: stack backtrace:
#0 0x805cec97 at kdb_backtrace+0x67
#1 0x80584816 at vpanic+0x186
#2 0x80584683 at panic+0x43
#3 0x8090f222 at trap_fatal+0x322
#4 0x8090f3ec at trap_pfault+0x1bc
#5 0x8090eaa0 at trap+0x280
#6 0x808f35e1 at calltrap+0x8
#7 0x806a202d at iflib_fast_intr+0x3d
#8 0x8054963b at intr_event_handle+0x9b
#9 0x80965f38 at intr_execute_handlers+0x48
#10 0x8096b1cf at lapic_handle_intr+0x3f
#11 0x808f3cc7 at Xapic_isr1+0xb7
#12 0x805b994a at sched_idletd+0x37a
#13 0x805460f5 at fork_exit+0x85
#14 0x808f3b1e at fork_trampoline+0xe

Peter
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"