Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Alexey Dokuchaev
On Wed, Jul 01, 2020 at 05:01:00PM -0700, Rodney W. Grimes wrote:
> Thats good, but realize the page already contains history that
> reads like:
> 
> HISTORY
>  Part of the functionality of whatis was already provided by the former
>  manwhere utility in 1BSD. The apropos and whatis utilities first ap-
>  peared in 2BSD.  They were rewritten from scratch for OpenBSD 5.6.
> 
>  The -M option and the MANPATH variable first appeared in 4.3BSD; -m in
>  4.3BSD-Reno; -C in 4.4BSD Lite1; and -S and -s in OpenBSD 4.5 for apropos
>  and in OpenBSD 5.6 for whatis.  The options -acfhIKklOTWw appeared in
>  OpenBSD 5.7.
> 
> And further contains:
> 
> AUTHORS
>  Bill Joy wrote manwhere in 1977 and the original BSD apropos and whatis
>  in February 1979. The current version was written by Kristaps Dzonsons
>   and Ingo Schwarze .
> 
> So the history is rich and complete, do we really need to say when we
> incorporated this into FreeBSD from OpenBSD's mandoc in the manual page?

Ah, in this case, the only thing lacking from the current version is mention
of FreeBSD 11.1.  Sorry for not checking with that before writing my reply.
My main point, however, was that reverse chronological order looks strange.

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


Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Rodney W. Grimes
> On Wed, Jul 01, 2020 at 11:28:47PM +0200, Gordon Bergling wrote:
> > On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> > > On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes wrote:
> > > > ...
> > > > We often have "An ls command appeared in Version 1 AT UNIX."  Our 
> > > > source
> > > > code and man page is not from that, but that is the history of ls.
> > > >
> > > > This *could* be amended and *should* be amended to reflect that apropos,
> > > > and makewhatis got *updated* by a switch to the mandoc versions, but it
> > > > is misleading to say it was intergrated with the switch to mandoc as 
> > > > that
> > > > implies it did not exist before this action.
> > > 
> > > I tend to agree with Rod here. These appeared in X the first time, but
> > > noting they were replaced in version X with Y is the best way to address
> > > the current provenance of the code...
> > 
> > OK, I see your arguments. How about the following addition for HISTORY 
> > section,
> > 
> > The apropos utility was integrated into FreeBSD 11.1 as part of the
> > switch to mandoc. Before the switch to mandoc apropos was available since
> > FreeBSD 1.0.
> 
> It should be the other way around:
> 
>   "The apropos utility appeared in FreeBSD 1.0.  Since FreeBSD 11.1
>it is based on mandoc implementation."

Thats good, but realize the page already contains history that
reads like:

HISTORY
 Part of the functionality of whatis was already provided by the former
 manwhere utility in 1BSD. The apropos and whatis utilities first ap-
 peared in 2BSD.  They were rewritten from scratch for OpenBSD 5.6.

 The -M option and the MANPATH variable first appeared in 4.3BSD; -m in
 4.3BSD-Reno; -C in 4.4BSD Lite1; and -S and -s in OpenBSD 4.5 for apropos
 and in OpenBSD 5.6 for whatis.  The options -acfhIKklOTWw appeared in
 OpenBSD 5.7.

And further contains:

UTHORS
 Bill Joy wrote manwhere in 1977 and the original BSD apropos and whatis
 in February 1979. The current version was written by Kristaps Dzonsons
  and Ingo Schwarze .

So the history is rich and complete, do we really need to say when we
incorporated this into FreeBSD from OpenBSD's mandoc in the manual page?

> ./danfe
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Alexey Dokuchaev
On Wed, Jul 01, 2020 at 11:28:47PM +0200, Gordon Bergling wrote:
> On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> > On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes wrote:
> > > ...
> > > We often have "An ls command appeared in Version 1 AT UNIX."  Our source
> > > code and man page is not from that, but that is the history of ls.
> > >
> > > This *could* be amended and *should* be amended to reflect that apropos,
> > > and makewhatis got *updated* by a switch to the mandoc versions, but it
> > > is misleading to say it was intergrated with the switch to mandoc as that
> > > implies it did not exist before this action.
> > 
> > I tend to agree with Rod here. These appeared in X the first time, but
> > noting they were replaced in version X with Y is the best way to address
> > the current provenance of the code...
> 
> OK, I see your arguments. How about the following addition for HISTORY 
> section,
> 
> The apropos utility was integrated into FreeBSD 11.1 as part of the
> switch to mandoc. Before the switch to mandoc apropos was available since
> FreeBSD 1.0.

It should be the other way around:

  "The apropos utility appeared in FreeBSD 1.0.  Since FreeBSD 11.1
   it is based on mandoc implementation."

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


Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Rodney W. Grimes
> On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> > On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes 
> > wrote:
> > 
> > > > On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > > Author: gbe (doc committer)
> > > > > > Date: Tue Jun 30 18:08:59 2020
> > > > > > New Revision: 362809
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > > > >
> > > > > > Log:
> > > > > >   Mention FreeBSD in the HISTORY sections of apropos(1) and
> > > makewhatis(8).
> > > > > >
> > > > > >   PR: 223520, 223521
> > > > > >   Reviewed by:bcr (mentor)
> > > > > >   Approved by:bcr (mentor)
> > > > > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > > > >
> > > > > > Modified:
> > > > > >   head/contrib/mandoc/apropos.1
> > > > > >   head/contrib/mandoc/makewhatis.8
> > > > > >
> > > > > > Modified: head/contrib/mandoc/apropos.1
> > > > > >
> > > ==
> > > > > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > > > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > > > > @@ -15,7 +15,7 @@
> > > > > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> > > ARISING OUT OF
> > > > > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > > > >  .\"
> > > > > > -.Dd $Mdocdate: November 22 2018 $
> > > > > > +.Dd $Mdocdate: June 30 2020 $
> > > > > >  .Dt APROPOS 1
> > > > > >  .Os
> > > > > >  .Sh NAME
> > > > > > @@ -493,6 +493,12 @@ The options
> > > > > >  .Fl acfhIKklOTWw
> > > > > >  appeared in
> > > > > >  .Ox 5.7 .
> > > > > > +.Pp
> > > > > > +The
> > > > > > +.Nm
> > > > > > +utility was integrated into
> > > > > > +.Fx 11.1
> > > > > > +as part of the switch to mandoc.
> > > > >
> > > > > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has
> > > it:
> > > > > freebsd {110}% uname -a
> > > > > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8
> > > #1: Mon Jul  1 17:58:50 PDT 2019 
> > > r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE
> > > i386
> > > > > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > > > > /usr/bin/apropos
> > > > >
> > > > > And a man page for it too:
> > > > > APROPOS(1)  FreeBSD General Commands Manual
> > >  APROPOS(1)
> > > > >
> > > > > NAME
> > > > >  apropos, whatis -- search the whatis database
> > > > >
> > > > > SYNOPSIS
> > > > >  apropos keyword ...
> > > > >  whatis keyword ...
> > > > >
> > > > > DESCRIPTION
> > > > >  apropos searches a set of database files containing short
> > > descriptions of
> > > > >  system commands for keywords and displays the result on the
> > > standard out-
> > > > >  put.  whatis displays only complete word matches.
> > > > >
> > > > >  keyword really is an extended regular expression, please read
> > > grep(1)
> > > > >  manual page for more information about its format.
> > > > >
> > > > > DIAGNOSTICS
> > > > >  The apropos utility exits 0 on success, and 1 if no keyword
> > > matched.
> > > > >
> > > > > SEE ALSO
> > > > >  grep(1), makewhatis(1), man(1)
> > > > >
> > > > > FreeBSD 5.4January 15, 1991
> > > FreeBSD 5.4
> > > > >
> > > > > >  .Sh AUTHORS
> > > > > >  .An -nosplit
> > > > > >  .An Bill Joy
> > > > > >
> > > >
> > > > That is true, but the version of 'apropos' we have currently in base is
> > > based on mandoc,
> > > > which was imported around September 2018. Due to the nature of
> > > contributed code I
> > > > thought it would be best to document only the history when it was
> > > integrated into
> > > > FreeSBD. The same applies for 'makewhatis'.
> > >
> > > That is not what has been done in other places when code is
> > > changed/replaced,
> > > the HISTORY section is not specific to "FreeBSD's version" of this
> > > function.
> > >
> > > We often have "An ls command appeared in Version 1 AT UNIX."  Our source
> > > code and man page is not from that, but that is the history of ls.
> > >
> > > This *could* be amended and *should* be amended to reflect that apropos,
> > > and makewhatis got *updated* by a switch to the mandoc versions, but it
> > > is misleading to say it was intergrated with the switch to mandoc as that
> > > implies it did not exist before this action.
> > >
> > 
> > I tend to agree with Rod here. These appeared in X the first time, but
> > noting they were replaced in version X with Y is the best way to address
> > the current provenance of the code...
> > 
> > Warner
> 
> OK, I see your arguments. How about the following addition for HISTORY 
> section,
> 
> The apropos utility was integrated into FreeBSD 11.1 as part of the
> switch to mandoc. Before the switch to mandoc apropos was available since
> FreeBSD 1.0.

This still implies that it originated with the switch to 

Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Gordon Bergling
On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes 
> wrote:
> 
> > > On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > Author: gbe (doc committer)
> > > > > Date: Tue Jun 30 18:08:59 2020
> > > > > New Revision: 362809
> > > > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > > >
> > > > > Log:
> > > > >   Mention FreeBSD in the HISTORY sections of apropos(1) and
> > makewhatis(8).
> > > > >
> > > > >   PR: 223520, 223521
> > > > >   Reviewed by:bcr (mentor)
> > > > >   Approved by:bcr (mentor)
> > > > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > > >
> > > > > Modified:
> > > > >   head/contrib/mandoc/apropos.1
> > > > >   head/contrib/mandoc/makewhatis.8
> > > > >
> > > > > Modified: head/contrib/mandoc/apropos.1
> > > > >
> > ==
> > > > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> > (r362808)
> > > > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> > (r362809)
> > > > > @@ -15,7 +15,7 @@
> > > > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> > ARISING OUT OF
> > > > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > > >  .\"
> > > > > -.Dd $Mdocdate: November 22 2018 $
> > > > > +.Dd $Mdocdate: June 30 2020 $
> > > > >  .Dt APROPOS 1
> > > > >  .Os
> > > > >  .Sh NAME
> > > > > @@ -493,6 +493,12 @@ The options
> > > > >  .Fl acfhIKklOTWw
> > > > >  appeared in
> > > > >  .Ox 5.7 .
> > > > > +.Pp
> > > > > +The
> > > > > +.Nm
> > > > > +utility was integrated into
> > > > > +.Fx 11.1
> > > > > +as part of the switch to mandoc.
> > > >
> > > > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has
> > it:
> > > > freebsd {110}% uname -a
> > > > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8
> > #1: Mon Jul  1 17:58:50 PDT 2019 
> > r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE
> > i386
> > > > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > > > /usr/bin/apropos
> > > >
> > > > And a man page for it too:
> > > > APROPOS(1)  FreeBSD General Commands Manual
> >  APROPOS(1)
> > > >
> > > > NAME
> > > >  apropos, whatis -- search the whatis database
> > > >
> > > > SYNOPSIS
> > > >  apropos keyword ...
> > > >  whatis keyword ...
> > > >
> > > > DESCRIPTION
> > > >  apropos searches a set of database files containing short
> > descriptions of
> > > >  system commands for keywords and displays the result on the
> > standard out-
> > > >  put.  whatis displays only complete word matches.
> > > >
> > > >  keyword really is an extended regular expression, please read
> > grep(1)
> > > >  manual page for more information about its format.
> > > >
> > > > DIAGNOSTICS
> > > >  The apropos utility exits 0 on success, and 1 if no keyword
> > matched.
> > > >
> > > > SEE ALSO
> > > >  grep(1), makewhatis(1), man(1)
> > > >
> > > > FreeBSD 5.4January 15, 1991
> > FreeBSD 5.4
> > > >
> > > > >  .Sh AUTHORS
> > > > >  .An -nosplit
> > > > >  .An Bill Joy
> > > > >
> > >
> > > That is true, but the version of 'apropos' we have currently in base is
> > based on mandoc,
> > > which was imported around September 2018. Due to the nature of
> > contributed code I
> > > thought it would be best to document only the history when it was
> > integrated into
> > > FreeSBD. The same applies for 'makewhatis'.
> >
> > That is not what has been done in other places when code is
> > changed/replaced,
> > the HISTORY section is not specific to "FreeBSD's version" of this
> > function.
> >
> > We often have "An ls command appeared in Version 1 AT UNIX."  Our source
> > code and man page is not from that, but that is the history of ls.
> >
> > This *could* be amended and *should* be amended to reflect that apropos,
> > and makewhatis got *updated* by a switch to the mandoc versions, but it
> > is misleading to say it was intergrated with the switch to mandoc as that
> > implies it did not exist before this action.
> >
> 
> I tend to agree with Rod here. These appeared in X the first time, but
> noting they were replaced in version X with Y is the best way to address
> the current provenance of the code...
> 
> Warner

OK, I see your arguments. How about the following addition for HISTORY section,

The apropos utility was integrated into FreeBSD 11.1 as part of the
switch to mandoc. Before the switch to mandoc apropos was available since
FreeBSD 1.0.

Any suggestions on how to describe the history more precise are very welcome.

--Gordon

> > > > > Modified: head/contrib/mandoc/makewhatis.8
> > > > >
> > ==
> > > > > --- head/contrib/mandoc/makewhatis.8  Tue Jun 30 17:21:28 2020
> >   

svn commit: r362853 - in head/sys/riscv: include riscv

2020-07-01 Thread Kristof Provost
Author: kp
Date: Wed Jul  1 19:15:43 2020
New Revision: 362853
URL: https://svnweb.freebsd.org/changeset/base/362853

Log:
  riscv pmap: zero reserved pte bits in ppn
  
  The top 10 bits of a pte are reserved by specification[1] and are not part of
  the PPN.
  
  [1] 'Volume II: RISC-V Privileged Architectures V20190608-Priv-MSU-Ratified',
  '4.4.1 Addressing and Memory Protection', page 72: "The PTE format for Sv39 is
  shown in Figure 4.18. ... Bits 63–54 are reserved for future use and must be
  zeroed by software for forward compatibility."
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  kp, mhorne
  Differential Revision:https://reviews.freebsd.org/D25523

Modified:
  head/sys/riscv/include/pte.h
  head/sys/riscv/riscv/pmap.c

Modified: head/sys/riscv/include/pte.h
==
--- head/sys/riscv/include/pte.hWed Jul  1 19:12:47 2020
(r362852)
+++ head/sys/riscv/include/pte.hWed Jul  1 19:15:43 2020
(r362853)
@@ -83,6 +83,9 @@ typedef   uint64_tpn_t;   /* page 
number */
 #definePTE_PROMOTE (PTE_V | PTE_RWX | PTE_D | PTE_A | PTE_G | 
PTE_U | \
 PTE_SW_MANAGED | PTE_SW_WIRED)
 
+/* Bits 63 - 54 are reserved for future use. */
+#define PTE_HI_MASK0xFFC0ULL
+
 #definePTE_PPN0_S  10
 #definePTE_PPN1_S  19
 #definePTE_PPN2_S  28

Modified: head/sys/riscv/riscv/pmap.c
==
--- head/sys/riscv/riscv/pmap.c Wed Jul  1 19:12:47 2020(r362852)
+++ head/sys/riscv/riscv/pmap.c Wed Jul  1 19:15:43 2020(r362853)
@@ -339,7 +339,8 @@ pagezero(void *p)
 #definepmap_l2_index(va)   (((va) >> L2_SHIFT) & Ln_ADDR_MASK)
 #definepmap_l3_index(va)   (((va) >> L3_SHIFT) & Ln_ADDR_MASK)
 
-#definePTE_TO_PHYS(pte)((pte >> PTE_PPN0_S) * PAGE_SIZE)
+#definePTE_TO_PHYS(pte) \
+pte) & ~PTE_HI_MASK) >> PTE_PPN0_S) * PAGE_SIZE)
 
 static __inline pd_entry_t *
 pmap_l1(pmap_t pmap, vm_offset_t va)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362852 - head/sys/riscv/riscv

2020-07-01 Thread Kristof Provost
Author: kp
Date: Wed Jul  1 19:12:47 2020
New Revision: 362852
URL: https://svnweb.freebsd.org/changeset/base/362852

Log:
  riscv locore.S: load constant prior to loop
  
  A very minor micro-optimization; t0 is not clobbered between the loop top and
  bottom and there appear to be no other branches to this label.
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  mhorne
  Differential Revision:https://reviews.freebsd.org/D25524

Modified:
  head/sys/riscv/riscv/locore.S

Modified: head/sys/riscv/riscv/locore.S
==
--- head/sys/riscv/riscv/locore.S   Wed Jul  1 19:11:02 2020
(r362851)
+++ head/sys/riscv/riscv/locore.S   Wed Jul  1 19:12:47 2020
(r362852)
@@ -139,8 +139,8 @@ pagetables:
li  t2, 512 /* Build 512 entries */
add t3, t4, t2
li  t5, 0
-1:
li  t0, (PTE_KERN | PTE_X)
+1:
sllit2, t4, PTE_PPN1_S  /* << PTE_PPN1_S */
or  t5, t0, t2
sd  t5, (s1)/* Store PTE entry to position */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362851 - head/sys/riscv/riscv

2020-07-01 Thread Kristof Provost
Author: kp
Date: Wed Jul  1 19:11:02 2020
New Revision: 362851
URL: https://svnweb.freebsd.org/changeset/base/362851

Log:
  riscv: Log missing registers in dump_regs()
  
  If we panic we dump the registers for debugging. This is very useful, but it
  missed several registers (ra, sp, gp and tp).
  
  Log these as well. Especially the return address value is extremely useful.
  
  Sponsored by: Axiado

Modified:
  head/sys/riscv/riscv/trap.c

Modified: head/sys/riscv/riscv/trap.c
==
--- head/sys/riscv/riscv/trap.c Wed Jul  1 18:10:37 2020(r362850)
+++ head/sys/riscv/riscv/trap.c Wed Jul  1 19:11:02 2020(r362851)
@@ -147,6 +147,11 @@ dump_regs(struct trapframe *frame)
for (i = 0; i < n; i++)
printf("a[%d] == 0x%016lx\n", i, frame->tf_a[i]);
 
+   printf("ra == 0x%016lx\n", frame->tf_ra);
+   printf("sp == 0x%016lx\n", frame->tf_sp);
+   printf("gp == 0x%016lx\n", frame->tf_gp);
+   printf("tp == 0x%016lx\n", frame->tf_tp);
+
printf("sepc == 0x%016lx\n", frame->tf_sepc);
printf("sstatus == 0x%016lx\n", frame->tf_sstatus);
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Warner Losh
On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes 
wrote:

> > On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > Author: gbe (doc committer)
> > > > Date: Tue Jun 30 18:08:59 2020
> > > > New Revision: 362809
> > > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > >
> > > > Log:
> > > >   Mention FreeBSD in the HISTORY sections of apropos(1) and
> makewhatis(8).
> > > >
> > > >   PR: 223520, 223521
> > > >   Reviewed by:bcr (mentor)
> > > >   Approved by:bcr (mentor)
> > > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > >
> > > > Modified:
> > > >   head/contrib/mandoc/apropos.1
> > > >   head/contrib/mandoc/makewhatis.8
> > > >
> > > > Modified: head/contrib/mandoc/apropos.1
> > > >
> ==
> > > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> (r362808)
> > > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> (r362809)
> > > > @@ -15,7 +15,7 @@
> > > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> ARISING OUT OF
> > > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > >  .\"
> > > > -.Dd $Mdocdate: November 22 2018 $
> > > > +.Dd $Mdocdate: June 30 2020 $
> > > >  .Dt APROPOS 1
> > > >  .Os
> > > >  .Sh NAME
> > > > @@ -493,6 +493,12 @@ The options
> > > >  .Fl acfhIKklOTWw
> > > >  appeared in
> > > >  .Ox 5.7 .
> > > > +.Pp
> > > > +The
> > > > +.Nm
> > > > +utility was integrated into
> > > > +.Fx 11.1
> > > > +as part of the switch to mandoc.
> > >
> > > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has
> it:
> > > freebsd {110}% uname -a
> > > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8
> #1: Mon Jul  1 17:58:50 PDT 2019 
> r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE
> i386
> > > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > > /usr/bin/apropos
> > >
> > > And a man page for it too:
> > > APROPOS(1)  FreeBSD General Commands Manual
>  APROPOS(1)
> > >
> > > NAME
> > >  apropos, whatis -- search the whatis database
> > >
> > > SYNOPSIS
> > >  apropos keyword ...
> > >  whatis keyword ...
> > >
> > > DESCRIPTION
> > >  apropos searches a set of database files containing short
> descriptions of
> > >  system commands for keywords and displays the result on the
> standard out-
> > >  put.  whatis displays only complete word matches.
> > >
> > >  keyword really is an extended regular expression, please read
> grep(1)
> > >  manual page for more information about its format.
> > >
> > > DIAGNOSTICS
> > >  The apropos utility exits 0 on success, and 1 if no keyword
> matched.
> > >
> > > SEE ALSO
> > >  grep(1), makewhatis(1), man(1)
> > >
> > > FreeBSD 5.4January 15, 1991
> FreeBSD 5.4
> > >
> > > >  .Sh AUTHORS
> > > >  .An -nosplit
> > > >  .An Bill Joy
> > > >
> >
> > That is true, but the version of 'apropos' we have currently in base is
> based on mandoc,
> > which was imported around September 2018. Due to the nature of
> contributed code I
> > thought it would be best to document only the history when it was
> integrated into
> > FreeSBD. The same applies for 'makewhatis'.
>
> That is not what has been done in other places when code is
> changed/replaced,
> the HISTORY section is not specific to "FreeBSD's version" of this
> function.
>
> We often have "An ls command appeared in Version 1 AT UNIX."  Our source
> code and man page is not from that, but that is the history of ls.
>
> This *could* be amended and *should* be amended to reflect that apropos,
> and makewhatis got *updated* by a switch to the mandoc versions, but it
> is misleading to say it was intergrated with the switch to mandoc as that
> implies it did not exist before this action.
>

I tend to agree with Rod here. These appeared in X the first time, but
noting they were replaced in version X with Y is the best way to address
the current provenance of the code...

Warner


> >
> > > > Modified: head/contrib/mandoc/makewhatis.8
> > > >
> ==
> > > > --- head/contrib/mandoc/makewhatis.8  Tue Jun 30 17:21:28 2020
>   (r362808)
> > > > +++ head/contrib/mandoc/makewhatis.8  Tue Jun 30 18:08:59 2020
>   (r362809)
> > > > @@ -15,7 +15,7 @@
> > > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> ARISING OUT OF
> > > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > >  .\"
> > > > -.Dd $Mdocdate: May 17 2017 $
> > > > +.Dd $Mdocdate: June 30 2020 $
> > > >  .Dt MAKEWHATIS 8
> > > >  .Os
> > > >  .Sh NAME
> > > > @@ -211,6 +211,12 @@ and the options
> > > >  .Fl aCDnQT
> > > >  in
> > > >  .Ox 5.6 .
> > > > +.Pp
> > > > +The
> > > > +.Nm
> > > > +utility was integrated into
> > > > +.Fx 11.1
> > > > +as part of 

svn commit: r362846 - head/sys/netinet/tcp_stacks

2020-07-01 Thread Michael Tuexen
Author: tuexen
Date: Wed Jul  1 17:17:06 2020
New Revision: 362846
URL: https://svnweb.freebsd.org/changeset/base/362846

Log:
  Fix the cleanup handling in a error path for TCP BBR.
  
  Reported by:  syzbot+df7899c55c4cc52f5...@syzkaller.appspotmail.com
  Reviewed by:  rscheff
  Sponsored by: Netflix, Inc.
  Differential Revision:https://reviews.freebsd.org/D25486

Modified:
  head/sys/netinet/tcp_stacks/bbr.c

Modified: head/sys/netinet/tcp_stacks/bbr.c
==
--- head/sys/netinet/tcp_stacks/bbr.c   Wed Jul  1 16:57:57 2020
(r362845)
+++ head/sys/netinet/tcp_stacks/bbr.c   Wed Jul  1 17:17:06 2020
(r362846)
@@ -13381,6 +13381,8 @@ send:
 */
BBR_STAT_INC(bbr_offset_drop);
tcp_set_inp_to_drop(inp, EFAULT);
+   SOCKBUF_UNLOCK(sb);
+   (void)m_free(m);
return (0);
}
len = rsm->r_end - rsm->r_start;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362845 - in head/sys/arm64: arm64 include

2020-07-01 Thread Andrew Turner
Author: andrew
Date: Wed Jul  1 16:57:57 2020
New Revision: 362845
URL: https://svnweb.freebsd.org/changeset/base/362845

Log:
  Read the CPU 0 arm64 ID registers early in initarm
  
  We also update the kernel view early in the boot. This will allow the
  use of the common kernel view in ifunc resolvers.
  
  Sponsored by: Innovate UK

Modified:
  head/sys/arm64/arm64/identcpu.c
  head/sys/arm64/arm64/machdep.c
  head/sys/arm64/arm64/mp_machdep.c
  head/sys/arm64/include/cpu.h

Modified: head/sys/arm64/arm64/identcpu.c
==
--- head/sys/arm64/arm64/identcpu.c Wed Jul  1 16:37:08 2020
(r362844)
+++ head/sys/arm64/arm64/identcpu.c Wed Jul  1 16:57:57 2020
(r362845)
@@ -992,7 +992,7 @@ update_lower_register(uint64_t val, uint64_t new_val, 
return (val);
 }
 
-static void
+void
 update_special_regs(u_int cpu)
 {
struct mrs_field *fields;
@@ -1072,7 +1072,8 @@ identify_cpu_sysinit(void *dummy __unused)
elf_hwcap = hwcap;
else
elf_hwcap &= hwcap;
-   update_special_regs(cpu);
+   if (cpu != 0)
+   update_special_regs(cpu);
 
if (CTR_DIC_VAL(cpu_desc[cpu].ctr) == 0)
dic = false;
@@ -1457,23 +1458,15 @@ identify_cache(uint64_t ctr)
 }
 
 void
-identify_cpu(void)
+identify_cpu(u_int cpu)
 {
u_int midr;
u_int impl_id;
u_int part_id;
-   u_int cpu;
size_t i;
const struct cpu_parts *cpu_partsp = NULL;
 
-   cpu = PCPU_GET(cpuid);
midr = get_midr();
-
-   /*
-* Store midr to pcpu to allow fast reading
-* from EL0, EL1 and assembly code.
-*/
-   PCPU_SET(midr, midr);
 
impl_id = CPU_IMPL(midr);
for (i = 0; i < nitems(cpu_implementers); i++) {

Modified: head/sys/arm64/arm64/machdep.c
==
--- head/sys/arm64/arm64/machdep.c  Wed Jul  1 16:37:08 2020
(r362844)
+++ head/sys/arm64/arm64/machdep.c  Wed Jul  1 16:57:57 2020
(r362845)
@@ -172,7 +172,6 @@ cpu_startup(void *dummy)
 {
 
undef_init();
-   identify_cpu();
install_cpu_errata();
 
vm_ksubmap_init();
@@ -1138,6 +1137,9 @@ initarm(struct arm64_bootparams *abp)
if (kmdp == NULL)
kmdp = preload_search_by_type("elf64 kernel");
 
+   identify_cpu(0);
+   update_special_regs(0);
+
link_elf_ireloc(kmdp);
try_load_dtb(kmdp);
 
@@ -1181,6 +1183,7 @@ initarm(struct arm64_bootparams *abp)
"msr tpidr_el1, %0" :: "r"(pcpup));
 
PCPU_SET(curthread, );
+   PCPU_SET(midr, get_midr());
 
/* Do basic tuning, hz etc */
init_param1();

Modified: head/sys/arm64/arm64/mp_machdep.c
==
--- head/sys/arm64/arm64/mp_machdep.c   Wed Jul  1 16:37:08 2020
(r362844)
+++ head/sys/arm64/arm64/mp_machdep.c   Wed Jul  1 16:57:57 2020
(r362845)
@@ -220,7 +220,7 @@ init_secondary(uint64_t cpu)
 * We need this before signalling the CPU is ready to
 * let the boot CPU use the results.
 */
-   identify_cpu();
+   identify_cpu(cpu);
 
/* Ensure the stores in identify_cpu have completed */
atomic_thread_fence_acq_rel();
@@ -229,6 +229,8 @@ init_secondary(uint64_t cpu)
atomic_add_int(_started, 1);
while (!atomic_load_int(_ready))
__asm __volatile("wfe");
+
+   pcpup->pc_midr = get_midr();
 
/* Initialize curthread */
KASSERT(PCPU_GET(idlethread) != NULL, ("no idle thread"));

Modified: head/sys/arm64/include/cpu.h
==
--- head/sys/arm64/include/cpu.hWed Jul  1 16:37:08 2020
(r362844)
+++ head/sys/arm64/include/cpu.hWed Jul  1 16:57:57 2020
(r362845)
@@ -167,11 +167,12 @@ void  cpu_halt(void) __dead2;
 void   cpu_reset(void) __dead2;
 void   fork_trampoline(void);
 void   identify_cache(uint64_t);
-void   identify_cpu(void);
+void   identify_cpu(u_int);
 void   install_cpu_errata(void);
 void   swi_vm(void *v);
 
 /* Functions to read the sanitised view of the special registers */
+void   update_special_regs(u_int);
 bool   extract_user_id_field(u_int, u_int, uint8_t *);
 bool   get_kernel_reg(u_int, uint64_t *);
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362843 - head/usr.bin/printf

2020-07-01 Thread Fernando Apesteguía
Author: fernape (ports committer)
Date: Wed Jul  1 16:33:32 2020
New Revision: 362843
URL: https://svnweb.freebsd.org/changeset/base/362843

Log:
  printf(1): Add EXAMPLES section
  
   * Small addition with four simple examples
   * While here, remove three obsolete .Tn macros
  
  Approved by:  manpages (gbe)
  Differential Revision:https://reviews.freebsd.org/D25462

Modified:
  head/usr.bin/printf/printf.1

Modified: head/usr.bin/printf/printf.1
==
--- head/usr.bin/printf/printf.1Wed Jul  1 16:18:35 2020
(r362842)
+++ head/usr.bin/printf/printf.1Wed Jul  1 16:33:32 2020
(r362843)
@@ -31,7 +31,7 @@
 .\"@(#)printf.18.1 (Berkeley) 6/6/93
 .\" $FreeBSD$
 .\"
-.Dd July 29, 2019
+.Dd July 1, 2020
 .Dt PRINTF 1
 .Os
 .Sh NAME
@@ -316,12 +316,48 @@ Consult the
 manual page.
 .Sh EXIT STATUS
 .Ex -std
+.Sh EXAMPLES
+Print the string
+.Qq hello :
+.Bd -literal -offset indent
+$ printf "%s\en" hello
+hello
+.Ed
+.Pp
+Same as above, but notice that the format string is not quoted and hence we
+do not get the expected behavior:
+.Bd -literal -offset indent
+$ printf %s\en hello
+hellon$
+.Ed
+.Pp
+Print arguments forcing sign only for the first argument:
+.Bd -literal -offset indent
+$ printf "%+d\en%d\en%d\en" 1 -2 13
++1
+-2
+13
+.Ed
+.Pp
+Same as above, but the single format string will be applied to the three
+arguments:
+.Bd -literal -offset indent
+$ printf "%+d\en" 1 -2 13
++1
+-2
++13
+.Ed
+.Pp
+Print number using only two digits after the decimal point:
+.Bd -literal -offset indent
+$ printf "%.2f\en" 31.7456
+31.75
+.Ed
 .Sh COMPATIBILITY
 The traditional
 .Bx
 behavior of converting arguments of numeric formats not beginning
-with a digit to the
-.Tn ASCII
+with a digit to the ASCII
 code of the first character is not supported.
 .Sh SEE ALSO
 .Xr builtin 1 ,
@@ -343,8 +379,7 @@ It is modeled
 after the standard library function,
 .Xr printf 3 .
 .Sh CAVEATS
-.Tn ANSI
-hexadecimal character constants were deliberately not provided.
+ANSI hexadecimal character constants were deliberately not provided.
 .Pp
 Trying to print a dash ("-") as the first character causes
 .Nm
@@ -364,10 +399,8 @@ and
 formats with a precision
 may not operate as expected.
 .Sh BUGS
-Since the floating point numbers are translated from
-.Tn ASCII
-to floating-point and
-then back again, floating-point precision may be lost.
+Since the floating point numbers are translated from ASCII
+to floating-point and then back again, floating-point precision may be lost.
 (By default, the number is translated to an IEEE-754 double-precision
 value before being printed.
 The
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362841 - head/sys/arm64/include

2020-07-01 Thread Andrew Turner
Author: andrew
Date: Wed Jul  1 16:17:51 2020
New Revision: 362841
URL: https://svnweb.freebsd.org/changeset/base/362841

Log:
  Move ID reading signatures to a better header
  
  The functions to read the common user and kernel ID registers should be
  in cpu.h rather than undefined.h as they are related to CPU details and
  used by undefined instruction handlers.
  
  Sponsored by: Innovate UK

Modified:
  head/sys/arm64/include/cpu.h
  head/sys/arm64/include/undefined.h

Modified: head/sys/arm64/include/cpu.h
==
--- head/sys/arm64/include/cpu.hWed Jul  1 15:42:48 2020
(r362840)
+++ head/sys/arm64/include/cpu.hWed Jul  1 16:17:51 2020
(r362841)
@@ -171,6 +171,10 @@ void   identify_cpu(void);
 void   install_cpu_errata(void);
 void   swi_vm(void *v);
 
+/* Functions to read the sanitised view of the special registers */
+bool   extract_user_id_field(u_int, u_int, uint8_t *);
+bool   get_kernel_reg(u_int, uint64_t *);
+
 #defineCPU_AFFINITY(cpu)   __cpu_affinity[(cpu)]
 #defineCPU_CURRENT_SOCKET  \
 (CPU_AFF2(CPU_AFFINITY(PCPU_GET(cpuid

Modified: head/sys/arm64/include/undefined.h
==
--- head/sys/arm64/include/undefined.h  Wed Jul  1 15:42:48 2020
(r362840)
+++ head/sys/arm64/include/undefined.h  Wed Jul  1 16:17:51 2020
(r362841)
@@ -63,10 +63,6 @@ void *install_undef_handler(bool, undef_handler_t);
 void remove_undef_handler(void *);
 int undef_insn(u_int, struct trapframe *);
 
-/* Functions to read the sanitised view of the special registers */
-bool extract_user_id_field(u_int, u_int, uint8_t *);
-bool get_kernel_reg(u_int, uint64_t *);
-
 #endif /* _KERNEL */
 
 #endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362840 - head/sys/netinet

2020-07-01 Thread Mark Johnston
Author: markj
Date: Wed Jul  1 15:42:48 2020
New Revision: 362840
URL: https://svnweb.freebsd.org/changeset/base/362840

Log:
  Fix a possible next-hop refcount leak when handling IPSec traffic.
  
  It may be possible to fix this by deferring the lookup, but let's
  keep the initial change simple to make MFCs easier.
  
  PR:   246951
  Reviewed by:  melifaro
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D25519

Modified:
  head/sys/netinet/ip_input.c

Modified: head/sys/netinet/ip_input.c
==
--- head/sys/netinet/ip_input.c Wed Jul  1 15:30:27 2020(r362839)
+++ head/sys/netinet/ip_input.c Wed Jul  1 15:42:48 2020(r362840)
@@ -1028,6 +1028,7 @@ ip_forward(struct mbuf *m, int srcrt)
if (IPSEC_ENABLED(ipv4)) {
if ((error = IPSEC_FORWARD(ipv4, m)) != 0) {
/* mbuf consumed by IPsec */
+   RO_NHFREE();
m_freem(mcopy);
if (error != EINPROGRESS)
IPSTAT_INC(ips_cantforward);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362839 - head/share/misc

2020-07-01 Thread Muhammad Moinur Rahman
Author: bofh (ports committer)
Date: Wed Jul  1 15:30:27 2020
New Revision: 362839
URL: https://svnweb.freebsd.org/changeset/base/362839

Log:
  Update with the members of the 11th core team, core.xi
  - Update the core-secretary role.
  - Update the comment to mention that the sorting is done based on FreeBSD
login name
  
  Reported by:  bofh (with core-secretary@ hat on)
  Reviewed by:  bcr
  Approved by:  bcr
  Differential Revision:https://reviews.freebsd.org/D25526

Modified:
  head/share/misc/organization.dot

Modified: head/share/misc/organization.dot
==
--- head/share/misc/organization.dotWed Jul  1 15:27:34 2020
(r362838)
+++ head/share/misc/organization.dotWed Jul  1 15:30:27 2020
(r362839)
@@ -23,10 +23,10 @@ _devel [label="FreeBSD Developers"]
 _admin [label="FreeBSD Infrastructure Administrators"]
 _misc [label="Miscellaneous Hats"]
 
-# Development teams go here alphabetically sorted
+# Development teams go here alphabetically sorted by FreeBSD login name
 
-core [label="Core Team\nc...@freebsd.org\nallanjude, bcr, brooks,\nimp, hrs, 
jeff,\njhb, kmoore, seanc"]
-coresecretary [label="Core Team Secretary\ncore-secret...@freebsd.org\njrm"]
+core [label="Core Team\nc...@freebsd.org\nbapt, emaste, gnn,\nimp, hrs, 
kevans,\nmarkj, scottl, seanc"]
+coresecretary [label="Core Team Secretary\ncore-secret...@freebsd.org\nbofh"]
 doccommitters [label="Doc/www Committers\ndoc-committ...@freebsd.org"]
 doceng [label="Documentation Engineering Team\ndoc...@freebsd.org\nbcr, gabor, 
gjb, hrs,\nblackend, ryusuke, wblock"]
 portscommitters [label="Ports Committers\nports-committ...@freebsd.org"]
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r362837 - head/sys/arm64/arm64

2020-07-01 Thread Andrew Turner
Author: andrew
Date: Wed Jul  1 15:17:45 2020
New Revision: 362837
URL: https://svnweb.freebsd.org/changeset/base/362837

Log:
  Read the arm64 ID registers earlier in the boot process.
  
  Also move parsing the registers to just after the secondary CPUs have
  started. This means the kernel register view from all CPUs is available
  after the CPU SYSINITs have finished, e.g. for use by ifunc resolvers.
  
  Sponsored by: Innovate UK
  Differential Revision:https://reviews.freebsd.org/D25505

Modified:
  head/sys/arm64/arm64/identcpu.c
  head/sys/arm64/arm64/mp_machdep.c

Modified: head/sys/arm64/arm64/identcpu.c
==
--- head/sys/arm64/arm64/identcpu.c Wed Jul  1 15:02:56 2020
(r362836)
+++ head/sys/arm64/arm64/identcpu.c Wed Jul  1 15:17:45 2020
(r362837)
@@ -46,7 +46,6 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-static int ident_lock;
 static void print_cpu_features(u_int cpu);
 static u_long parse_cpu_features_hwcap(u_int cpu);
 
@@ -67,6 +66,8 @@ static int allow_idc = 1;
 SYSCTL_INT(_machdep_cache, OID_AUTO, allow_idc, CTLFLAG_RDTUN, _idc, 0,
 "Allow optimizations based on the IDC cache bit");
 
+static void check_cpu_regs(u_int cpu);
+
 /*
  * The default implementation of I-cache sync assumes we have an
  * aliasing cache until we know otherwise.
@@ -1063,8 +1064,9 @@ identify_cpu_sysinit(void *dummy __unused)
 
dic = (allow_dic != 0);
idc = (allow_idc != 0);
+
CPU_FOREACH(cpu) {
-   print_cpu_features(cpu);
+   check_cpu_regs(cpu);
hwcap = parse_cpu_features_hwcap(cpu);
if (elf_hwcap == 0)
elf_hwcap = hwcap;
@@ -1096,8 +1098,18 @@ identify_cpu_sysinit(void *dummy __unused)
 
install_undef_handler(true, user_mrs_handler);
 }
-SYSINIT(identify_cpu, SI_SUB_SMP, SI_ORDER_ANY, identify_cpu_sysinit, NULL);
+SYSINIT(identify_cpu, SI_SUB_CPU, SI_ORDER_ANY, identify_cpu_sysinit, NULL);
 
+static void
+cpu_features_sysinit(void *dummy __unused)
+{
+   u_int cpu;
+
+   CPU_FOREACH(cpu)
+   print_cpu_features(cpu);
+}
+SYSINIT(cpu_features, SI_SUB_SMP, SI_ORDER_ANY, cpu_features_sysinit, NULL);
+
 static u_long
 parse_cpu_features_hwcap(u_int cpu)
 {
@@ -1468,7 +1480,8 @@ identify_cpu(void)
if (impl_id == cpu_implementers[i].impl_id ||
cpu_implementers[i].impl_id == 0) {
cpu_desc[cpu].cpu_impl = impl_id;
-   cpu_desc[cpu].cpu_impl_name = 
cpu_implementers[i].impl_name;
+   cpu_desc[cpu].cpu_impl_name =
+   cpu_implementers[i].impl_name;
cpu_partsp = cpu_implementers[i].cpu_parts;
break;
}
@@ -1505,77 +1518,68 @@ identify_cpu(void)
cpu_desc[cpu].id_aa64mmfr2 = READ_SPECIALREG(id_aa64mmfr2_el1);
cpu_desc[cpu].id_aa64pfr0 = READ_SPECIALREG(id_aa64pfr0_el1);
cpu_desc[cpu].id_aa64pfr1 = READ_SPECIALREG(id_aa64pfr1_el1);
+}
 
-   if (cpu != 0) {
-   /*
-* This code must run on one cpu at a time, but we are
-* not scheduling on the current core so implement a
-* simple spinlock.
-*/
-   while (atomic_cmpset_acq_int(_lock, 0, 1) == 0)
-   __asm __volatile("wfe" ::: "memory");
+static void
+check_cpu_regs(u_int cpu)
+{
 
-   switch (cpu_aff_levels) {
-   case 0:
-   if (CPU_AFF0(cpu_desc[cpu].mpidr) !=
-   CPU_AFF0(cpu_desc[0].mpidr))
-   cpu_aff_levels = 1;
-   /* FALLTHROUGH */
-   case 1:
-   if (CPU_AFF1(cpu_desc[cpu].mpidr) !=
-   CPU_AFF1(cpu_desc[0].mpidr))
-   cpu_aff_levels = 2;
-   /* FALLTHROUGH */
-   case 2:
-   if (CPU_AFF2(cpu_desc[cpu].mpidr) !=
-   CPU_AFF2(cpu_desc[0].mpidr))
-   cpu_aff_levels = 3;
-   /* FALLTHROUGH */
-   case 3:
-   if (CPU_AFF3(cpu_desc[cpu].mpidr) !=
-   CPU_AFF3(cpu_desc[0].mpidr))
-   cpu_aff_levels = 4;
-   break;
-   }
+   switch (cpu_aff_levels) {
+   case 0:
+   if (CPU_AFF0(cpu_desc[cpu].mpidr) !=
+   CPU_AFF0(cpu_desc[0].mpidr))
+   cpu_aff_levels = 1;
+   /* FALLTHROUGH */
+   case 1:
+   if (CPU_AFF1(cpu_desc[cpu].mpidr) !=
+   CPU_AFF1(cpu_desc[0].mpidr))
+   cpu_aff_levels = 2;
+   /* FALLTHROUGH */
+   case 2:
+   if 

Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Rodney W. Grimes
> On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gbe (doc committer)
> > > Date: Tue Jun 30 18:08:59 2020
> > > New Revision: 362809
> > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > 
> > > Log:
> > >   Mention FreeBSD in the HISTORY sections of apropos(1) and makewhatis(8).
> > >   
> > >   PR: 223520, 223521
> > >   Reviewed by:bcr (mentor)
> > >   Approved by:bcr (mentor)
> > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > 
> > > Modified:
> > >   head/contrib/mandoc/apropos.1
> > >   head/contrib/mandoc/makewhatis.8
> > > 
> > > Modified: head/contrib/mandoc/apropos.1
> > > ==
> > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > @@ -15,7 +15,7 @@
> > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT 
> > > OF
> > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > >  .\"
> > > -.Dd $Mdocdate: November 22 2018 $
> > > +.Dd $Mdocdate: June 30 2020 $
> > >  .Dt APROPOS 1
> > >  .Os
> > >  .Sh NAME
> > > @@ -493,6 +493,12 @@ The options
> > >  .Fl acfhIKklOTWw
> > >  appeared in
> > >  .Ox 5.7 .
> > > +.Pp
> > > +The
> > > +.Nm
> > > +utility was integrated into
> > > +.Fx 11.1
> > > +as part of the switch to mandoc.
> > 
> > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has it:
> > freebsd {110}% uname -a
> > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #1: 
> > Mon Jul  1 17:58:50 PDT 2019 
> > r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE  i386
> > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > /usr/bin/apropos
> > 
> > And a man page for it too:
> > APROPOS(1)  FreeBSD General Commands Manual 
> > APROPOS(1)
> > 
> > NAME
> >  apropos, whatis -- search the whatis database
> > 
> > SYNOPSIS
> >  apropos keyword ...
> >  whatis keyword ...
> > 
> > DESCRIPTION
> >  apropos searches a set of database files containing short descriptions 
> > of
> >  system commands for keywords and displays the result on the standard 
> > out-
> >  put.  whatis displays only complete word matches.
> > 
> >  keyword really is an extended regular expression, please read grep(1)
> >  manual page for more information about its format.
> > 
> > DIAGNOSTICS
> >  The apropos utility exits 0 on success, and 1 if no keyword matched.
> > 
> > SEE ALSO
> >  grep(1), makewhatis(1), man(1)
> > 
> > FreeBSD 5.4January 15, 1991FreeBSD 
> > 5.4
> > 
> > >  .Sh AUTHORS
> > >  .An -nosplit
> > >  .An Bill Joy
> > > 
> 
> That is true, but the version of 'apropos' we have currently in base is based 
> on mandoc,
> which was imported around September 2018. Due to the nature of contributed 
> code I 
> thought it would be best to document only the history when it was integrated 
> into
> FreeSBD. The same applies for 'makewhatis'.

That is not what has been done in other places when code is changed/replaced,
the HISTORY section is not specific to "FreeBSD's version" of this function.

We often have "An ls command appeared in Version 1 AT UNIX."  Our source
code and man page is not from that, but that is the history of ls.

This *could* be amended and *should* be amended to reflect that apropos,
and makewhatis got *updated* by a switch to the mandoc versions, but it
is misleading to say it was intergrated with the switch to mandoc as that
implies it did not exist before this action.

> 
> > > Modified: head/contrib/mandoc/makewhatis.8
> > > ==
> > > --- head/contrib/mandoc/makewhatis.8  Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > +++ head/contrib/mandoc/makewhatis.8  Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > @@ -15,7 +15,7 @@
> > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT 
> > > OF
> > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > >  .\"
> > > -.Dd $Mdocdate: May 17 2017 $
> > > +.Dd $Mdocdate: June 30 2020 $
> > >  .Dt MAKEWHATIS 8
> > >  .Os
> > >  .Sh NAME
> > > @@ -211,6 +211,12 @@ and the options
> > >  .Fl aCDnQT
> > >  in
> > >  .Ox 5.6 .
> > > +.Pp
> > > +The
> > > +.Nm
> > > +utility was integrated into
> > > +.Fx 11.1
> > > +as part of the switch to mandoc.
> > 
> > Ditto
> > 
> > >  .Sh AUTHORS
> > >  .An -nosplit
> > >  .An Bill Joy
> 
> --Gordon
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to 

Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-01 Thread Peter Jeremy
On 2020-Jul-01 18:57:47 +1000, Peter Jeremy  wrote:
>On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko  wrote:
>>Log:
>>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
>>  
>>  For 1000Mb mode to work reliably TX/RX delays need to be configured
>>  between the TX/RX clock and the respective signals on the PHY
>>  to compensate for differing trace lengths on the PCB.
>
>This breaks (at least) diskless booting on my Rock64.

I've studied the RK3328 TRM[1] and the RK3328 code following r362736
matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574
says the delay line is configured via GRF_SOC_CON3 - which doesn't
match the documentation on GRF_SOC_CON3 on p175-177).  That suggests
that the delay values in the FDT are incorrect.  Unfortunately, the
TRM doesn't include any details on how to configure the delay values
so it's difficult to adjust the numbers in the FDT.

One possible explanation I have is that there are (at least) 2
different Rock64 variants.  Later versions have increased the RGMII
bus voltage to improve GigE reliability.  I initially had problems
with GigE reliability and mod'd my Rock64[3] to use the higher RGMII
bus voltage - which made it rock solid at GigE.  It's possible that
different variants need different delay values, due to different track
skew or different driver behaviour at different bus voltages.

[1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
[2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of
RK3328_GRF_MAC_CON0_RX_MASK but the values are the same).
[3] Move 1 resistor to change a pull-up to a pull-down

-- 
Peter Jeremy


signature.asc
Description: PGP signature


svn commit: r362834 - head/sys/kern

2020-07-01 Thread Andrew Turner
Author: andrew
Date: Wed Jul  1 12:07:28 2020
New Revision: 362834
URL: https://svnweb.freebsd.org/changeset/base/362834

Log:
  Simplify the flow when getting/setting an isrc
  
  Rather than unlocking and returning we can just perform the needed action
  only when the interrupt source is valid and reuse the unlock in both the
  valid irq and invalid irq cases.
  
  Sponsored by: Innovate UK

Modified:
  head/sys/kern/subr_intr.c

Modified: head/sys/kern/subr_intr.c
==
--- head/sys/kern/subr_intr.c   Wed Jul  1 10:37:08 2020(r362833)
+++ head/sys/kern/subr_intr.c   Wed Jul  1 12:07:28 2020(r362834)
@@ -1517,13 +1517,12 @@ intr_map_get_isrc(u_int res_id)
 {
struct intr_irqsrc *isrc;
 
+   isrc = NULL;
mtx_lock(_map_lock);
-   if ((res_id >= irq_map_count) || (irq_map[res_id] == NULL)) {
-   mtx_unlock(_map_lock);
-   return (NULL);
-   }
-   isrc = irq_map[res_id]->isrc;
+   if (res_id < irq_map_count && irq_map[res_id] != NULL)
+   isrc = irq_map[res_id]->isrc;
mtx_unlock(_map_lock);
+
return (isrc);
 }
 
@@ -1532,11 +1531,8 @@ intr_map_set_isrc(u_int res_id, struct intr_irqsrc *is
 {
 
mtx_lock(_map_lock);
-   if ((res_id >= irq_map_count) || (irq_map[res_id] == NULL)) {
-   mtx_unlock(_map_lock);
-   return;
-   }
-   irq_map[res_id]->isrc = isrc;
+   if (res_id < irq_map_count && irq_map[res_id] != NULL)
+   irq_map[res_id]->isrc = isrc;
mtx_unlock(_map_lock);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Konstantin Belousov
On Wed, Jul 01, 2020 at 12:56:12PM +0200, Hans Petter Selasky wrote:
> On 2020-07-01 12:30, Konstantin Belousov wrote:
> > I see no point in repeating the same pfind/tdfind calls, better to convert
> > them to pget(), and have this code in one intended place.
> 
> I wonder if we can convert all cases in linux_current.c to use pget(). Could
> you have a look too?

Other uses in linux_current.c are not suitable for pget().  In case
linux_pid_task()/linux_get_pid_task() were passed a tid instead of pid,
current code returns lkpi_task for the specified thread.  In other words,
if using pget(), we would need to find the thread after the call, which
makes no sense.

On the other hand, there are at least two aspects that can be improved.
First, the functions are too similar to require separating body.  Second,
distinction between pid and tid is static and if we are passed pid, it
makes no sense to call tdfind() on it.

https://reviews.freebsd.org/D25534
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Hans Petter Selasky

On 2020-07-01 12:30, Konstantin Belousov wrote:

I see no point in repeating the same pfind/tdfind calls, better to convert
them to pget(), and have this code in one intended place.


I wonder if we can convert all cases in linux_current.c to use pget(). 
Could you have a look too?


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


svn commit: r362833 - head/sys/compat/linux

2020-07-01 Thread Edward Tomasz Napierala
Author: trasz
Date: Wed Jul  1 10:37:08 2020
New Revision: 362833
URL: https://svnweb.freebsd.org/changeset/base/362833

Log:
  Rework linux accept(2).  This makes the code flow easier to follow,
  and fixes a bug where calling accept(2) could result in closing fd 0.
  
  Note that the code still contains a number of problems: it makes
  assumptions about l_sockaddr_in being the same as sockaddr_in,
  the EFAULT-related code looks like it doesn't work at all, and the
  socket type check is racy.  Those will be addressed later on;
  I'm trying to work in small steps to avoid breaking one thing while
  fixing another.
  
  It fixes Redis, among other things.
  
  Reviewed by:  kib
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D25461

Modified:
  head/sys/compat/linux/linux_socket.c

Modified: head/sys/compat/linux/linux_socket.c
==
--- head/sys/compat/linux/linux_socket.cWed Jul  1 09:35:33 2020
(r362832)
+++ head/sys/compat/linux/linux_socket.cWed Jul  1 10:37:08 2020
(r362833)
@@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -611,17 +612,19 @@ linux_accept_common(struct thread *td, int s, l_uintpt
 {
struct l_sockaddr *lsa;
struct sockaddr *sa;
-   struct file *fp;
+   struct file *fp, *fp1;
int bflags, len;
struct socket *so;
int error, error1;
 
bflags = 0;
+   fp = NULL;
+   sa = NULL;
+
error = linux_set_socket_flags(flags, );
if (error != 0)
return (error);
 
-   sa = NULL;
if (PTRIN(addr) == NULL) {
len = 0;
error = kern_accept4(td, s, NULL, NULL, bflags, NULL);
@@ -632,48 +635,54 @@ linux_accept_common(struct thread *td, int s, l_uintpt
if (len < 0)
return (EINVAL);
error = kern_accept4(td, s, , , bflags, );
-   if (error == 0)
-   fdrop(fp, td);
}
 
+   /*
+* Translate errno values into ones used by Linux.
+*/
if (error != 0) {
/*
 * XXX. This is wrong, different sockaddr structures
 * have different sizes.
 */
-   if (error == EFAULT && namelen != sizeof(struct sockaddr_in))
-   {
-   error = EINVAL;
-   goto out;
-   }
-   if (error == EINVAL) {
-   error1 = getsock_cap(td, s, _accept_rights, , 
NULL, NULL);
+   switch (error) {
+   case EFAULT:
+   if (namelen != sizeof(struct sockaddr_in))
+   error = EINVAL;
+   break;
+   case EINVAL:
+   error1 = getsock_cap(td, s, _accept_rights, , 
NULL, NULL);
if (error1 != 0) {
error = error1;
-   goto out;
+   break;
}
-   so = fp->f_data;
+   so = fp1->f_data;
if (so->so_type == SOCK_DGRAM)
error = EOPNOTSUPP;
-   fdrop(fp, td);
+   fdrop(fp1, td);
+   break;
}
-   goto out;
+   return (error);
}
 
-   if (len != 0 && error == 0) {
+   if (len != 0) {
error = bsd_to_linux_sockaddr(sa, , len);
if (error == 0)
error = copyout(lsa, PTRIN(addr), len);
free(lsa, M_SONAME);
-   }
 
-   free(sa, M_SONAME);
+   /*
+* XXX: We should also copyout the len, shouldn't we?
+*/
 
-out:
-   if (error != 0) {
-   (void)kern_close(td, td->td_retval[0]);
-   td->td_retval[0] = 0;
+   if (error != 0) {
+   fdclose(td, fp, td->td_retval[0]);
+   td->td_retval[0] = 0;
+   }
}
+   if (fp != NULL)
+   fdrop(fp, td);
+   free(sa, M_SONAME);
return (error);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Konstantin Belousov
On Wed, Jul 01, 2020 at 11:35:21AM +0200, Hans Petter Selasky wrote:
> On 2020-07-01 11:21, Konstantin Belousov wrote:
> > It should be expressed as pget(pid, 0); instead of duplicating.
> 
> Hi,
> 
> Currently the LinuxKPI style is to use tdfind() and pfind(). If you look at
> linux_current.c you see multiple uses of the exact same syntax.
> 
> Quickly looking at the pget() implementation, I see it doesn't expand to
> exactly tdfind() and pfind(). pget() uses pfind_tid() which looks overkill
> compared to tdfind(). tdfind() uses a hash-table lookup, while pfind_tid()
> doesn't  I'm confused.

It is trivial to change pget() to use tdfind(),
https://reviews.freebsd.org/D25532

I see no point in repeating the same pfind/tdfind calls, better to convert
them to pget(), and have this code in one intended place.




the sam
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Hans Petter Selasky

On 2020-07-01 11:21, Konstantin Belousov wrote:

It should be expressed as pget(pid, 0); instead of duplicating.


Hi,

Currently the LinuxKPI style is to use tdfind() and pfind(). If you look 
at linux_current.c you see multiple uses of the exact same syntax.


Quickly looking at the pget() implementation, I see it doesn't expand to 
exactly tdfind() and pfind(). pget() uses pfind_tid() which looks 
overkill compared to tdfind(). tdfind() uses a hash-table lookup, while 
pfind_tid() doesn't  I'm confused.


--HPS


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


Re: svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Konstantin Belousov
On Wed, Jul 01, 2020 at 08:23:57AM +, Hans Petter Selasky wrote:
> Author: hselasky
> Date: Wed Jul  1 08:23:57 2020
> New Revision: 362829
> URL: https://svnweb.freebsd.org/changeset/base/362829
> 
> Log:
>   The "pid" field in the LinuxKPI task struct is typically set to the thread 
> ID
>   and not the process ID. Make sure the linux_task_exiting() function uses 
> tdfind()
>   to lookup the BSD procedure structure pointer by the "pid" field, and only
>   fallback to pfind() when no match is found! This makes linux_task_exiting()
>   in line with the rest of the code.
>   
>   Differential Revision: https://reviews.freebsd.org/D25509
>   Submitted by:   Greg V 
>   MFC after:  1 week
>   Sponsored by:   Mellanox Technologies
> 
> Modified:
>   head/sys/compat/linuxkpi/common/src/linux_current.c
> 
> Modified: head/sys/compat/linuxkpi/common/src/linux_current.c
> ==
> --- head/sys/compat/linuxkpi/common/src/linux_current.c   Wed Jul  1 
> 05:59:08 2020(r362828)
> +++ head/sys/compat/linuxkpi/common/src/linux_current.c   Wed Jul  1 
> 08:23:57 2020(r362829)
> @@ -219,11 +219,21 @@ linux_get_pid_task(pid_t pid)
>  bool
>  linux_task_exiting(struct task_struct *task)
>  {
> + struct thread *td;
>   struct proc *p;
>   bool ret;
>  
>   ret = false;
> - p = pfind(task->pid);
> +
> + /* try to find corresponding thread */
> + td = tdfind(task->pid, -1);
> + if (td != NULL) {
> + p = td->td_proc;
> + } else {
> + /* try to find corresponding procedure */
> + p = pfind(task->pid);
> + }
> +
>   if (p != NULL) {
>   if ((p->p_flag & P_WEXIT) != 0)
>   ret = true;
It should be expressed as pget(pid, 0); instead of duplicating.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362815 - head/sys/net80211

2020-07-01 Thread Bjoern A. Zeeb

On 1 Jul 2020, at 0:23, Adrian Chadd wrote:


Author: adrian
Date: Wed Jul  1 00:23:49 2020
New Revision: 362815
URL: https://svnweb.freebsd.org/changeset/base/362815

Log:
  [net80211] Migrate HT/legacy protection mode and preamble 
calculation to per-VAP flags


can you please put these changes into Phabricator with adequate time to 
get the reviewed in the future?



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


Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-01 Thread Peter Jeremy
On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko  wrote:
>Log:
>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
>  
>  For 1000Mb mode to work reliably TX/RX delays need to be configured
>  between the TX/RX clock and the respective signals on the PHY
>  to compensate for differing trace lengths on the PCB.

This breaks (at least) diskless booting on my Rock64.

During boot, I normally see:
regulator: shutting down unused regulators
uhub1: 1 port with 1 removable, self powered
uhub0: 2 ports with 2 removable, self powered
uhub2: 1 port with 1 removable, self powered
uhub3: 1 port with 1 removable, self powered
dwc0: link state changed to DOWN
NFS ROOT: 192.168.12.200:/tank/rock64
dwc0: link state changed to UP
Warning: no time-of-day clock registered, system time will not be set accurately
Warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init

With r362736, I see:
setting RK3328 RX/TX delays:  24/36
...
regulator: shutting down unused regulators
uhub0: 1 port with 1 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
dwc0: link state changed to DOWN
NFS ROOT: 192.168.12.200:/tank/rock64
dwc0: link state changed to UP
dwc0: link state changed to DOWN
dwc0: link state changed to UP
[Nothing further until I push the reset button]

The system doesn't respond to pings so I suspect the network is dead.
Normally, it runs 1000baseT .

-- 
Peter Jeremy


signature.asc
Description: PGP signature


svn commit: r362829 - head/sys/compat/linuxkpi/common/src

2020-07-01 Thread Hans Petter Selasky
Author: hselasky
Date: Wed Jul  1 08:23:57 2020
New Revision: 362829
URL: https://svnweb.freebsd.org/changeset/base/362829

Log:
  The "pid" field in the LinuxKPI task struct is typically set to the thread ID
  and not the process ID. Make sure the linux_task_exiting() function uses 
tdfind()
  to lookup the BSD procedure structure pointer by the "pid" field, and only
  fallback to pfind() when no match is found! This makes linux_task_exiting()
  in line with the rest of the code.
  
  Differential Revision: https://reviews.freebsd.org/D25509
  Submitted by: Greg V 
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/src/linux_current.c

Modified: head/sys/compat/linuxkpi/common/src/linux_current.c
==
--- head/sys/compat/linuxkpi/common/src/linux_current.c Wed Jul  1 05:59:08 
2020(r362828)
+++ head/sys/compat/linuxkpi/common/src/linux_current.c Wed Jul  1 08:23:57 
2020(r362829)
@@ -219,11 +219,21 @@ linux_get_pid_task(pid_t pid)
 bool
 linux_task_exiting(struct task_struct *task)
 {
+   struct thread *td;
struct proc *p;
bool ret;
 
ret = false;
-   p = pfind(task->pid);
+
+   /* try to find corresponding thread */
+   td = tdfind(task->pid, -1);
+   if (td != NULL) {
+   p = td->td_proc;
+   } else {
+   /* try to find corresponding procedure */
+   p = pfind(task->pid);
+   }
+
if (p != NULL) {
if ((p->p_flag & P_WEXIT) != 0)
ret = true;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r362809 - head/contrib/mandoc

2020-07-01 Thread Gordon Bergling
On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > Author: gbe (doc committer)
> > Date: Tue Jun 30 18:08:59 2020
> > New Revision: 362809
> > URL: https://svnweb.freebsd.org/changeset/base/362809
> > 
> > Log:
> >   Mention FreeBSD in the HISTORY sections of apropos(1) and makewhatis(8).
> >   
> >   PR:   223520, 223521
> >   Reviewed by:  bcr (mentor)
> >   Approved by:  bcr (mentor)
> >   Differential Revision:https://reviews.freebsd.org/D25521
> > 
> > Modified:
> >   head/contrib/mandoc/apropos.1
> >   head/contrib/mandoc/makewhatis.8
> > 
> > Modified: head/contrib/mandoc/apropos.1
> > ==
> > --- head/contrib/mandoc/apropos.1   Tue Jun 30 17:21:28 2020
> > (r362808)
> > +++ head/contrib/mandoc/apropos.1   Tue Jun 30 18:08:59 2020
> > (r362809)
> > @@ -15,7 +15,7 @@
> >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >  .\"
> > -.Dd $Mdocdate: November 22 2018 $
> > +.Dd $Mdocdate: June 30 2020 $
> >  .Dt APROPOS 1
> >  .Os
> >  .Sh NAME
> > @@ -493,6 +493,12 @@ The options
> >  .Fl acfhIKklOTWw
> >  appeared in
> >  .Ox 5.7 .
> > +.Pp
> > +The
> > +.Nm
> > +utility was integrated into
> > +.Fx 11.1
> > +as part of the switch to mandoc.
> 
> Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has it:
> freebsd {110}% uname -a
> FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #1: Mon 
> Jul  1 17:58:50 PDT 2019 
> r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE  i386
> pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> /usr/bin/apropos
> 
> And a man page for it too:
> APROPOS(1)  FreeBSD General Commands Manual APROPOS(1)
> 
> NAME
>  apropos, whatis -- search the whatis database
> 
> SYNOPSIS
>  apropos keyword ...
>  whatis keyword ...
> 
> DESCRIPTION
>  apropos searches a set of database files containing short descriptions of
>  system commands for keywords and displays the result on the standard out-
>  put.  whatis displays only complete word matches.
> 
>  keyword really is an extended regular expression, please read grep(1)
>  manual page for more information about its format.
> 
> DIAGNOSTICS
>  The apropos utility exits 0 on success, and 1 if no keyword matched.
> 
> SEE ALSO
>  grep(1), makewhatis(1), man(1)
> 
> FreeBSD 5.4January 15, 1991FreeBSD 5.4
> 
> >  .Sh AUTHORS
> >  .An -nosplit
> >  .An Bill Joy
> > 

That is true, but the version of 'apropos' we have currently in base is based 
on mandoc,
which was imported around September 2018. Due to the nature of contributed code 
I 
thought it would be best to document only the history when it was integrated 
into
FreeSBD. The same applies for 'makewhatis'.

> > Modified: head/contrib/mandoc/makewhatis.8
> > ==
> > --- head/contrib/mandoc/makewhatis.8Tue Jun 30 17:21:28 2020
> > (r362808)
> > +++ head/contrib/mandoc/makewhatis.8Tue Jun 30 18:08:59 2020
> > (r362809)
> > @@ -15,7 +15,7 @@
> >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >  .\"
> > -.Dd $Mdocdate: May 17 2017 $
> > +.Dd $Mdocdate: June 30 2020 $
> >  .Dt MAKEWHATIS 8
> >  .Os
> >  .Sh NAME
> > @@ -211,6 +211,12 @@ and the options
> >  .Fl aCDnQT
> >  in
> >  .Ox 5.6 .
> > +.Pp
> > +The
> > +.Nm
> > +utility was integrated into
> > +.Fx 11.1
> > +as part of the switch to mandoc.
> 
> Ditto
> 
> >  .Sh AUTHORS
> >  .An -nosplit
> >  .An Bill Joy

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


Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/

2020-07-01 Thread Dimitry Andric
On 1 Jul 2020, at 00:03, Stefan Eßer  wrote:
> 
> Am 30.06.20 um 23:29 schrieb Dimitry Andric:
...
>> This is because you are supposed to commit stuff to ^/base/vendor/xxx
>> first, then svn cp it to ^/head/contrib/xxx, at least from Subversion
>> 1.8 onwards. The 'cp' action establishes the ancestral relation.
> 
> Yes, I thought so - the problem I want to fix is the premature import
> to /contrib and I had been hoping that it was possible to use the
> --record-only merge to edit the merge history (as suggested by John
> Baldwin and Ed Maste).

I have never been able to find a way to 'force' the ancestral relation
after the fact. Subversion does not seem to expose this as a
user-manipulable property. The --record-only option does what it says,
i.e. not actually merging but only updating the svn:mergeinfo property,
but it will still only work on ancestrally related objects.


> I want to upgrade to the next release and I'm wondering whether it
> would be possible to just svn copy that new version over from the
> vendor directory to the contrib directory. The import to the vendor
> area and the contrib directory have very similar commit messages and
> thus there would be no loss of commit history.

If you don't have many (or no) customizations, then indeed it will be
fairly easy. In one commit, you can svn rm the old version, and svn cp
the new version from the vendor area. Subversion will later show the
directory to have been "Replaced". There are lots of examples of this
in the tree, and I would hope the Git converter can handle it, or there
will be much more trouble. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP