Re: stable/13, vm page counts do not add up

[Rozhuk Ivan]

On Tue, 13 Apr 2021 17:18:42 -0400
Mark Johnston  wrote:

> > P.S.
> > I have not been running any virtual machines.
> > I do use nvidia graphics driver.  
> 

In past I had report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238698

Now I switch to AMD and got only ~1Gb memory allocated by xorg.

___
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: sys/sys/param.h: 'main' instead of 'Master'?

[Chargen]

Master of origin;-)
-- 
Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail
verzoeken wij u dit direct door te geven aan de verzender door middel van
een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als
u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de
inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch
anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. If you are not the
intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Please notify us immediately if you have received it in error by
reply e-mail and then delete this message from your system.

Thanks,
   _  _
  (_)(_)
   (,,)
   =()=
  ((__)\
   _|L\___/
Save The Lab Rats


On Fri, Apr 16, 2021 at 10:23 PM Warner Losh  wrote:

> On Fri, Apr 16, 2021 at 12:20 PM Michael Gmelin  wrote:
>
> >
> >
> > > On 16. Apr 2021, at 19:29, Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> > >
> > > 
> > >>
> > >> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling 
> wrote:
> > >>>
> > >>> While viewing sys/sys/param.h I noticed that the comment of the
> > >>> definition of __FreeBSD_version is probably out of date.
> > >>>
> > >>> Since the switch to Git, doesn't it have to be 'main' instead of
> > 'master'?
> > >>>
> > >>
> > >> This isn't based on a branch name, though I guess if one were going to
> > >> touch it anyways then "Authoritative" would be a better descriptor.
> > >
> > > As well as "Origin".
> >
> > (Single) Source of Truth, maybe?
> >
>
> s/Master, p/P/ also makes sense.
>
> Warner
>
>
> > -m
> >
> > >
> > >>
> > >>> #cd /usr/src
> > >>> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
> > >>> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200
> > >>> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200
> > >>> @@ -60,7 +60,7 @@
> > >>>  * in the range 5 to 9.
> > >>>  */
> > >>> #undef __FreeBSD_version
> > >>> -#define __FreeBSD_version 147  /* Master, propagated to
> > newvers */
> > >>> +#define __FreeBSD_version 147  /* main, propagated to
> newvers
> > */
> > >>>
> > >>> /*
> > >>>  * __FreeBSD_kernel__ indicates that this system uses the kernel of
> > >>> FreeBSD,
> > >>>
> > >>> ___
> > >>> 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"
> > >>
> > >
> > > --
> > > Rod Grimes
> > rgri...@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"
> >
> > ___
> > 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"
>
___
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: sys/sys/param.h: 'main' instead of 'Master'?

[Warner Losh]

On Mon, Apr 19, 2021 at 7:12 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> > On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> > > On Fri, 16 Apr 2021 at 16:22, Warner Losh  wrote:
> > > >
> > > > > > As well as "Origin".
> > > > >
> > > > > (Single) Source of Truth, maybe?
> > > >
> > > > s/Master, p/P/ also makes sense.
> > >
> > > IMO instead of lightly rewording the existing comment we could just
> > > remove it, it doesn't really add any clarity.
> > >
> > > Instead we ought to add an introductory sentence or two to the block
> > > comment above, explaining what __FreeBSD_version actually is.
> >
> > fully agreed here! I had to explained many time what __FreeBSD_version
> actually
> > was. A clear comment would be great ;)
>
> Yes please!


Well, we explain the scheme w/o explaining when / why you'd want to bump it.

https://reviews.freebsd.org/D29850

has my attempt to do the latter. Please comment there...

Warner
___
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: NFS issues since upgrading to 13-RELEASE

[Juraj Lutter]

> On 19 Apr 2021, at 17:03, Rick Macklem  wrote:
> 
> Olav Gjerde wrote:
>> I have tried D29690 patch and reverting back to r367492 this weekend. 
>> Neither made any difference for my system.

For me, reverting the patch in r367492, solved all the problems.
In addition, I also turned off LRO and TSO on NICs comprising the lagg 
interface over which NFS service is provided.

otis

___
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: NFS issues since upgrading to 13-RELEASE

[Rick Macklem]

Olav Gjerde wrote:
>I have tried D29690 patch and reverting back to r367492 this weekend. Neither 
>made any difference for my system.
Just to clarify it, I meant "revert the patch in r367492" and not
"revert to revision r367492". I've attached the patch that
backs out the changes made by the patch in r367492, which
should apply to a fairly recent main/13 kernel.

This should be done instead of applying D29690, not combined with it.
My testing of D29690 has suggested it is not yet mature, so
I would not recommend choosing that alternative yet.

If you have tried a kernel with the attached patch applied to it, but not
D29690 applied to it, then please:
Let us know if you still have Linux clients "hanging" with this kernel.
If still "hanging", try the following to see if they help:
- Use the "minorversion=1" mount option on the Linux clients,
   to ensure that they are not using NFSv4.2, to see if it is a
   NFSv4.2 specific issue.
- Try disabling tso and lro and avoid jumbo frames for drivers
  that use jumbo mbufs when handling jumbo frames.
Collect the following info when it happens:
- "netstat -a", to see what the TCP connection is up to.
- "tcpdump -s 0 -w hang.pcap host "
   run for several minutes on the server, to see what is going on the
   wire. I use wireshark to look at hang.pcap, since it
   knows NFS as well as TCP.
   You can also do the above with "host " instead
   of "host " run on the client.
- "ps axHl" on the server, to see what the nfsd threads
   are up to.
If none of the above contains confidential info, please
send it to me, if not the list.

Good luck with it, rick
ps: Yea, I started this post and then realized I had hit
 reply instead of reply all.



There is also a reddit thread about this 
https://www.reddit.com/r/freebsd/comments/mqol4o/nfs_issues_since_upgrading_to_13release/

On Sat, Apr 17, 2021 at 1:10 AM Rick Macklem 
mailto:rmack...@uoguelph.ca>> wrote:
Just fyi, I just got a "recursed on non-recursed mutex" panic in
socantrcvmore() with the D29690 patch, so you might not
want to test with that one yet.

rick


From: 
owner-freebsd-curr...@freebsd.org 
mailto:owner-freebsd-curr...@freebsd.org>> 
on behalf of Olav Gjerde mailto:o...@backupbay.com>>
Sent: Thursday, April 15, 2021 3:21 PM
To: Allan Jude
Cc: freebsd-current@freebsd.org
Subject: Re: NFS issues since upgrading to 13-RELEASE

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca


Well something do happen if I restart NFS Service on FreeBSD , it works for
like 10 seconds then it gets unresponsive again.

This is my output from `nfsstat -d 1`

0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
8.00  10258.00  8.02 17170  134.54  2.01 72716  142.54  0.07  51  34
8.00  2273   17.76  7.99 31273  244.07  2.01 133267  261.83  0.14  20  82
8.03  4889   38.33  7.99 25885  202.07  2.06 119340  240.40  0.13  21  81
[= Read =]  [= Write ]  [=== Total ]
KB/t   tpsMB/s  KB/t   tpsMB/s  KB/t   tpsMB/sms  ql  %b
7.98  8811   68.64  8.00 12997  101.54  2.22 78396  170.18  0.15   1  80
7.99   9227.20  8.00  3798   29.68  2.10 17965   36.87  0.09   0  11
8.07  2959   23.31  0.00 00.00  2.67  8938   23.31  0.86  32  72
7.97  7088   55.18  0.00 00.00  2.66 21233   55.18  1.05  16  98
7.98  4666   36.38  0.00 00.00  2.66 13986   36.38  0.36   9  29
8.00  4513   35.24  8.00  7662   59.86  2.20 44188   95.10  0.27  10  49
7.98  4799   37.40  8.00 11422   89.23  2.16 60076  126.63  0.19   0  51
8.00  4322   33.76  0.00 00.00  2.67 12967   33.76  0.89   0  42
8.02  4839   37.91  0.00 00.0

Re: NFS issues since upgrading to 13-RELEASE

[Olav Gjerde]

I have tried D29690 patch and reverting back to r367492 this weekend.
Neither made any difference for my system.
There is also a reddit thread about this
https://www.reddit.com/r/freebsd/comments/mqol4o/nfs_issues_since_upgrading_to_13release/

On Sat, Apr 17, 2021 at 1:10 AM Rick Macklem  wrote:

> Just fyi, I just got a "recursed on non-recursed mutex" panic in
> socantrcvmore() with the D29690 patch, so you might not
> want to test with that one yet.
>
> rick
>
> 
> From: owner-freebsd-curr...@freebsd.org 
> on behalf of Olav Gjerde 
> Sent: Thursday, April 15, 2021 3:21 PM
> To: Allan Jude
> Cc: freebsd-current@freebsd.org
> Subject: Re: NFS issues since upgrading to 13-RELEASE
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> ith...@uoguelph.ca
>
>
> Well something do happen if I restart NFS Service on FreeBSD , it works for
> like 10 seconds then it gets unresponsive again.
>
> This is my output from `nfsstat -d 1`
>
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 8.00  10258.00  8.02 17170  134.54  2.01 72716  142.54  0.07  51  34
> 8.00  2273   17.76  7.99 31273  244.07  2.01 133267  261.83  0.14  20  82
> 8.03  4889   38.33  7.99 25885  202.07  2.06 119340  240.40  0.13  21  81
> [= Read =]  [= Write ]  [=== Total ]
> KB/t   tpsMB/s  KB/t   tpsMB/s  KB/t   tpsMB/sms  ql  %b
> 7.98  8811   68.64  8.00 12997  101.54  2.22 78396  170.18  0.15   1  80
> 7.99   9227.20  8.00  3798   29.68  2.10 17965   36.87  0.09   0  11
> 8.07  2959   23.31  0.00 00.00  2.67  8938   23.31  0.86  32  72
> 7.97  7088   55.18  0.00 00.00  2.66 21233   55.18  1.05  16  98
> 7.98  4666   36.38  0.00 00.00  2.66 13986   36.38  0.36   9  29
> 8.00  4513   35.24  8.00  7662   59.86  2.20 44188   95.10  0.27  10  49
> 7.98  4799   37.40  8.00 11422   89.23  2.16 60076  126.63  0.19   0  51
> 8.00  4322   33.76  0.00 00.00  2.67 12967   33.76  0.89   0  42
> 8.02  4839   37.91  0.00 00.00  2.67 14550   37.91  0.54  17  41
> 8.01  4516   35.32  0.00 00.00  2.67 13569   35.32  0.57  27  38
> 7.95  4459   34.62  8.00  11959.34  2.49 18109   43.96  0.55   0  45
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
> 0.00 00.00  0.00 00.00  0.00 00.00  0.00   0   0
>
>
>
> On Thu, Apr 15, 2021 at 9:07 PM Olav Gjerde  wrote:
>
> > I have the same issue, using Ubuntu 20.10 with Linux 5.8 kernel. The
> Linux
> > NFS client will get unresponsive and it does not recover in my case, even
> > if I restart NFS on FreeBSD. I upgraded from FreeBSD 12.1-RELEASE though.
> >
> > On Thu, Apr 15, 2021 at 8:36 PM Allan Jude 
> wrote:
> >
> >> On 4/15/2021 9:22 AM, Chris Roose wrote:
> >> > I posted this in -questions and someone suggested I post here as well.
> >> >
> >> > I'm having NFS availability issues between my Proxmox client and
> >> FreeBSD server (10G link) since upgrading to 13-RELEASE. And
> unfortunately
> >> I upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm
> kind of
> >> stuck.
> >> >
> >> > Periodically, the NFS server (I've tried both v3 and v4.2 clients)
> will
> >> go unre

Re: sys/sys/param.h: 'main' instead of 'Master'?

[Rodney W. Grimes]

> On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> > On Fri, 16 Apr 2021 at 16:22, Warner Losh  wrote:
> > >
> > > > > As well as "Origin".
> > > >
> > > > (Single) Source of Truth, maybe?
> > >
> > > s/Master, p/P/ also makes sense.
> > 
> > IMO instead of lightly rewording the existing comment we could just
> > remove it, it doesn't really add any clarity.
> > 
> > Instead we ought to add an introductory sentence or two to the block
> > comment above, explaining what __FreeBSD_version actually is.
> 
> fully agreed here! I had to explained many time what __FreeBSD_version 
> actually
> was. A clear comment would be great ;)

Yes please!


-- 
Rod Grimes rgri...@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: ZFS: out of temporary buffer space

[Kurt Jaeger]

Hi!

> ZFS: out of temporary buffer space
> 
> Any ideas on how to fix this ?

Ok, fix was this:

Using the same memstick, I wrote a new efi partition as a copy
from the efi partition on the memstick.

gpart (simplified) showed this:

=>40  2000409184  nvd0  GPT  (954G)
  40  409600 1  efi  (200M)
  4096401024 2  freebsd-boot  (512K)
  410664 984- free -  (492K)
  41164816777216 3  freebsd-swap  (8.0G)
17188864  1983219712 4  freebsd-zfs  (946G)
  2000408576 648- free -  (324K)

=>  1  767  da0  MBR  (3.7G)
1665841  efi  (33M)
66585  21749922  freebsd  [active]  (1.0G)
  2241577  5438423   - free -  (2.6G)

So:

  dd if=/dev/da0s1 of=/dev/nvd0p1

and reboot and there we go!

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"

ZFS: out of temporary buffer space

[Kurt Jaeger]

Hi!

Upgrading a c256294-g2cf84258922f kernel (14.0 from 27th of January)
to a more recent version displays this error on reboot:

ZFS: out of temporary buffer space

Any ideas on how to fix this ?

I've tried the fix as described in

https://old.reddit.com/r/freebsd/comments/mtx5cf/freebsd_130_upgrade_zfs_out_of_temporary_buffer/

with the memstick from SNAPSHOTS:

FreeBSD-14.0-CURRENT-amd64-20210415-14d0cd7225e-246078-memstick.img

and it did not work on 14.0.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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: NSS issues after locking fixes

[Konstantin Belousov]

On Mon, Apr 19, 2021 at 10:06:28AM +0100, Alexander Richardson wrote:
> On Sun, 18 Apr 2021 at 20:58, Александр Недоцуков  wrote:
> >
> > Hi All,
> >
> > After supposed locking fixes done in this commit: 
> > 5245bf7b92b74e556527b4916a8deba386fe5772
> > we have a broken nsdispatch(3) when system has a threaded nss module 
> > plugged in.
> >
> > To illustrate the problem:
> >
> > $id bland
> > id: bland: no such user
> > t$LD_PRELOAD=/usr/lib/libthr.so id bland
> > uid=1001(bland) gid=500(domainusers) groups=500(domainusers),...
> >
> > $cat /etc/nsswitch.conf
> > group: files ldap
> > hosts: files mdns dns
> > netgroup: comapt
> > networks: files
> > passwd: files ldap
> > shells: files
> > services: files
> > protocols: files
> > rpc: files
> >
> > It seems that the commit in question was done under asumption that 
> > threading model can never be changed during run-time, while previous code 
> > was taking care of it by taking a copy of __isthreaded.
> >
> > I can not reach out Alex Rechardson who authored this change. Perhaps 
> > someone else can step in and take care of it?
> >
> > Thanks,
> > Alexander.
> 
> Hi Alexander,
> 
> I was away over the weekend so I wasn't able to revert it then. I've
> committed the revert as
> https://cgit.freebsd.org/src/commit/?id=738314e445ceac4d3dd6c77c636044141623b8dc
> and
> 
> I am not convinced that __isthreaded changing is the real problem.
> This can only happen with fork() (which calls _thr_setthreaded(0))
> since if it's currently false, the main thread is executing and we
> can't be spawning a new thread.
> I think the problem could be that fork() is called while the lock is
> held in one thread and therefore the new process ends up with a locked
> rwlock. I think the solution could be to add a pthread_atfork()
> callback that unlocks the rwlock.

Just to be pedantic.  Proper way to handle process-private locks and fork
is to lock in pthread_atfork prepare(), and unlock both in parent and
child.
___
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: NSS issues after locking fixes

[Alexander Richardson]

On Sun, 18 Apr 2021 at 20:58, Александр Недоцуков  wrote:
>
> Hi All,
>
> After supposed locking fixes done in this commit: 
> 5245bf7b92b74e556527b4916a8deba386fe5772
> we have a broken nsdispatch(3) when system has a threaded nss module plugged 
> in.
>
> To illustrate the problem:
>
> $id bland
> id: bland: no such user
> t$LD_PRELOAD=/usr/lib/libthr.so id bland
> uid=1001(bland) gid=500(domainusers) groups=500(domainusers),...
>
> $cat /etc/nsswitch.conf
> group: files ldap
> hosts: files mdns dns
> netgroup: comapt
> networks: files
> passwd: files ldap
> shells: files
> services: files
> protocols: files
> rpc: files
>
> It seems that the commit in question was done under asumption that threading 
> model can never be changed during run-time, while previous code was taking 
> care of it by taking a copy of __isthreaded.
>
> I can not reach out Alex Rechardson who authored this change. Perhaps someone 
> else can step in and take care of it?
>
> Thanks,
> Alexander.

Hi Alexander,

I was away over the weekend so I wasn't able to revert it then. I've
committed the revert as
https://cgit.freebsd.org/src/commit/?id=738314e445ceac4d3dd6c77c636044141623b8dc
and

I am not convinced that __isthreaded changing is the real problem.
This can only happen with fork() (which calls _thr_setthreaded(0))
since if it's currently false, the main thread is executing and we
can't be spawning a new thread.
I think the problem could be that fork() is called while the lock is
held in one thread and therefore the new process ends up with a locked
rwlock. I think the solution could be to add a pthread_atfork()
callback that unlocks the rwlock.

Sorry for the breakage!

Alex
___
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: sys/sys/param.h: 'main' instead of 'Master'?

[Baptiste Daroussin]

On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> On Fri, 16 Apr 2021 at 16:22, Warner Losh  wrote:
> >
> > > > As well as "Origin".
> > >
> > > (Single) Source of Truth, maybe?
> >
> > s/Master, p/P/ also makes sense.
> 
> IMO instead of lightly rewording the existing comment we could just
> remove it, it doesn't really add any clarity.
> 
> Instead we ought to add an introductory sentence or two to the block
> comment above, explaining what __FreeBSD_version actually is.

fully agreed here! I had to explained many time what __FreeBSD_version actually
was. A clear comment would be great ;)

Bapt
___
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"