Re: svn commit: r343480 - head/lib/libfigpar

[Bruce Evans]

On Sat, 26 Jan 2019, Stefan Esser wrote:


Am 26.01.19 um 22:59 schrieb Colin Percival:

...
The length of the string was already being recalculated, by strcpy.

It seems to me that this could be written as

temp = malloc(slen + 1);
if (temp == NULL) /* could not allocate memory */
return (-1);
memcpy(temp, source, slen + 1);

which avoids both recalculating the string length and using strcpy?


In principle you are right, there is a small run-time cost by not using
the known length for the allocation.

The Clang Scan checks are leading to lots (thousands) of false positives
and a I have looked at quite a number and abstained from silencing them
in the hope that the scan will be improved.

It should learn that at least the trivial case of an allocation of the
value of strlen()+1 followed by a strcpy (and no further strcat or the
like) is safe.


It would be a large bug in coverity for it complain about normal use of
strcpy().

However, the the use was not normal.  It has very broken error checking
for malloc().  This gave undefined behaviour for C99 and usually failure
of the function and a memory leak for POSIX,

The broken error checking was to check errno instead of the return
value of malloc(), without even setting errno to 0 before calling
malloc().  This is especially broken in a library.  It is normal for
errno to contain some garbage value from a previous failure, e.g.,
ENOTTY from isatty().  So the expected behaviour of this library
function is to usually fail and leak the successfully malloc()ed memory
when the broken code is reached.  Coverity should find this bug.
Perhaps it did.

If errno were set before the call to malloc(), then the code would just
be unportable.  Setting errno when malloc() fails is a POSIX extension
of C99.  Coverity should be aware of the standard being used, and should
find this bug for C99 but not for POSIX.

The fix and the above patch don't fix styles bug related to the broken
check.  First there is the lexical style bug of placing the comment
on the check instead of on the result of the check.  The main bug is
that it should go without saying that malloc failures are checked for
by checking whether malloc() returned NULL.  But in the old version,
the check was encrypted as the broken check of errno.  The comment
decrypts this a little.

Bruce
___
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: r343486 - head/contrib/ipfilter/man

[Cy Schubert]

Author: cy
Date: Sun Jan 27 02:31:42 2019
New Revision: 343486
URL: https://svnweb.freebsd.org/changeset/base/343486

Log:
  Fix a typo.
  
  MFC after:3 days

Modified:
  head/contrib/ipfilter/man/ipnat.5

Modified: head/contrib/ipfilter/man/ipnat.5
==
--- head/contrib/ipfilter/man/ipnat.5   Sun Jan 27 00:46:06 2019
(r343485)
+++ head/contrib/ipfilter/man/ipnat.5   Sun Jan 27 02:31:42 2019
(r343486)
@@ -104,7 +104,7 @@ map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp 
 In this instance, the word "auto" tells IPFilter to calculate a private
 range of port numbers for each address on the LHS to use without fear
 of them being trampled by others.  This can lead to problems if there are
-connections being generated mire quickly than IPFilter can expire them.
+connections being generated more quickly than IPFilter can expire them.
 In this instance, and if we want to get away from a private range of
 port numbers, we can say:
 .nf
___
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: r343485 - in head: lib/libprocstat sys/kern sys/sys

[Konstantin Belousov]

Author: kib
Date: Sun Jan 27 00:46:06 2019
New Revision: 343485
URL: https://svnweb.freebsd.org/changeset/base/343485

Log:
  Bump SPECNAMELEN to MAXNAMLEN.
  
  This includes the bump for cdevsw d_version.  Otherwise, the impact on
  the ABI (not KBI) is surprisingly low.  The most important affected
  interface is devname(3) and ttyname(3) which already correctly handle
  long names (and ttyname(3) should not be affected at all).
  
  Still, due to the d_version bump, I argue that the change is not MFC-able.
  
  Requested by: mmacy
  Reviewed by:  jhb
  Sponsored by: The FreeBSD Foundation
  Differential revision:https://reviews.freebsd.org/D18932

Modified:
  head/lib/libprocstat/Symbol.map
  head/lib/libprocstat/libprocstat_compat.c
  head/sys/kern/kern_conf.c
  head/sys/sys/conf.h
  head/sys/sys/param.h

Modified: head/lib/libprocstat/Symbol.map
==
--- head/lib/libprocstat/Symbol.map Sun Jan 27 00:37:52 2019
(r343484)
+++ head/lib/libprocstat/Symbol.map Sun Jan 27 00:46:06 2019
(r343485)
@@ -35,9 +35,12 @@ FBSD_1.3 {
 FBSD_1.5 {
procstat_freeptlwpinfo;
procstat_getptlwpinfo;
-   procstat_get_pts_info;
procstat_get_sem_info;
procstat_get_shm_info;
procstat_get_socket_info;
+};
+
+FBSD_1.6 {
+   procstat_get_pts_info;
procstat_get_vnode_info;
 };

Modified: head/lib/libprocstat/libprocstat_compat.c
==
--- head/lib/libprocstat/libprocstat_compat.c   Sun Jan 27 00:37:52 2019
(r343484)
+++ head/lib/libprocstat/libprocstat_compat.c   Sun Jan 27 00:46:06 2019
(r343485)
@@ -36,9 +36,11 @@ __FBSDID("$FreeBSD$");
 
 #include "libprocstat.h"
 
+#defineSPECNAMELEN_COMPAT1263
+
 struct freebsd11_ptsstat {
uint32_tdev;
-   chardevname[SPECNAMELEN + 1];
+   chardevname[SPECNAMELEN_COMPAT12 + 1];
 };
 
 struct freebsd11_vnstat {
@@ -49,7 +51,7 @@ struct freebsd11_vnstat {
uint32_tvn_fsid;
int vn_type;
uint16_tvn_mode;
-   charvn_devname[SPECNAMELEN + 1];
+   charvn_devname[SPECNAMELEN_COMPAT12 + 1];
 };
 struct freebsd11_semstat {
uint32_tvalue;
@@ -75,8 +77,25 @@ struct freebsd11_sockstat {
chardname[32];
 };
 
+struct freebsd12_vnstat {
+   uint64_tvn_fileid;
+   uint64_tvn_size;
+   uint64_tvn_dev;
+   uint64_tvn_fsid;
+   char*vn_mntdir;
+   int vn_type;
+   uint16_tvn_mode;
+   charvn_devname[SPECNAMELEN_COMPAT12 + 1];
+};
+struct freebsd12_ptsstat {
+   uint64_tdev;
+   chardevname[SPECNAMELEN_COMPAT12 + 1];
+};
+
 intfreebsd11_procstat_get_pts_info(struct procstat *procstat,
 struct filestat *fst, struct freebsd11_ptsstat *pts, char *errbuf);
+intfreebsd12_procstat_get_pts_info(struct procstat *procstat,
+struct filestat *fst, struct freebsd12_ptsstat *pts_compat, char *errbuf);
 intfreebsd11_procstat_get_sem_info(struct procstat *procstat,
 struct filestat *fst, struct freebsd11_semstat *sem, char *errbuf);
 intfreebsd11_procstat_get_shm_info(struct procstat *procstat,
@@ -85,7 +104,11 @@ int freebsd11_procstat_get_socket_info(struct procstat
 struct filestat *fst, struct freebsd11_sockstat *sock, char *errbuf);
 intfreebsd11_procstat_get_vnode_info(struct procstat *procstat,
 struct filestat *fst, struct freebsd11_vnstat *vn, char *errbuf);
+intfreebsd12_procstat_get_vnode_info(struct procstat *procstat,
+struct filestat *fst, struct freebsd12_vnstat *vn_compat, char *errbuf);
 
+static const char trunc_name[] = "";
+
 int
 freebsd11_procstat_get_pts_info(struct procstat *procstat,
 struct filestat *fst, struct freebsd11_ptsstat *pts_compat, char *errbuf)
@@ -97,12 +120,34 @@ freebsd11_procstat_get_pts_info(struct procstat *procs
if (r != 0)
return (r);
pts_compat->dev = pts.dev;
-   memcpy(pts_compat->devname, pts.devname,
-   sizeof(pts_compat->devname));
+   if (strlen(pts.devname) >= sizeof(pts_compat->devname))
+   strcpy(pts_compat->devname, trunc_name);
+   else
+   memcpy(pts_compat->devname, pts.devname,
+   sizeof(pts_compat->devname));
return (0);
 }
 
 int
+freebsd12_procstat_get_pts_info(struct procstat *procstat,
+struct filestat *fst, struct freebsd12_ptsstat *pts_compat, char *errbuf)
+{
+   struct ptsstat pts;
+   int r;
+
+   r = procstat_get_pts_info(procstat, fst, &pts, errbuf);
+   if (r != 0)
+   return (r);
+   pts_compat->dev = pts.dev;
+   if (strlen(pts.devname) >= sizeof(pts_compat->devname))
+   strcpy(pts_compat->devn

svn commit: r343484 - head/libexec/rtld-elf

[Konstantin Belousov]

Author: kib
Date: Sun Jan 27 00:37:52 2019
New Revision: 343484
URL: https://svnweb.freebsd.org/changeset/base/343484

Log:
  Remove now redundand ifunc relocation code which should have been
  removed as part of r341441.
  
  This call to reloc_non_plt() may crash if ifunc resolvers use the
  needed libraries symbols since the pass over the needed libs
  relocation is not yet done.  The change in r341441 ensures the right
  relocation order otherwise.
  
  Submitted by: theraven
  MFC after:1 week
  Discussed in: https://reviews.freebsd.org/D17529

Modified:
  head/libexec/rtld-elf/rtld.c

Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cSat Jan 26 22:27:12 2019
(r343483)
+++ head/libexec/rtld-elf/rtld.cSun Jan 27 00:37:52 2019
(r343484)
@@ -2897,16 +2897,6 @@ relocate_object(Obj_Entry *obj, bool bind_now, Obj_Ent
lockstate) == -1)
return (-1);
 
-   /*
-* Process the non-PLT IFUNC relocations.  The relocations are
-* processed in two phases, because IFUNC resolvers may
-* reference other symbols, which must be readily processed
-* before resolvers are called.
-*/
-   if (obj->non_plt_gnu_ifunc &&
-   reloc_non_plt(obj, rtldobj, flags | SYMLOOK_IFUNC, lockstate))
-   return (-1);
-
if (!obj->mainprog && obj_enforce_relro(obj) == -1)
return (-1);
 
___
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: r343480 - head/lib/libfigpar

[Devin Teske]

> On 26 Jan 2019, at 1:59 PM, Colin Percival  wrote:
> 
> On 1/26/19 1:36 PM, Rodney W. Grimes wrote:
>>> Author: se
>>> Date: Sat Jan 26 21:30:26 2019
>>> New Revision: 343480
>>> URL: https://svnweb.freebsd.org/changeset/base/343480
>>> 
>>> Log:
>>>  Silence Clang Scan warning about potentially unsafe use of strcpy.
>>> 
>>>  While this is a false positive, the use of strdup() simplifies the code.
>> 
>> Though that might be true, it also has to recalculate the
>> length of the string which was already known by slen.
>> 
>> I am not sure how often this code is called,
>> but that is wasted cycles in a library.
> 
> The length of the string was already being recalculated, by strcpy.
> 
> It seems to me that this could be written as
> 
>temp = malloc(slen + 1);
>if (temp == NULL) /* could not allocate memory */
>return (-1);
>memcpy(temp, source, slen + 1);
> 
> which avoids both recalculating the string length and using strcpy?
> 

Thanks for fixing that.
— 
Cheers,
Devin



>>> Modified: head/lib/libfigpar/string_m.c
>>> ==
>>> --- head/lib/libfigpar/string_m.cSat Jan 26 20:43:28 2019(r343479)
>>> +++ head/lib/libfigpar/string_m.cSat Jan 26 21:30:26 2019(r343480)
>>> @@ -119,10 +119,9 @@ replaceall(char *source, const char *find, const char 
>>> 
>>>/* If replace is longer than find, we'll need to create a temp copy */
>>>if (rlen > flen) {
>>> -temp = malloc(slen + 1);
>>> -if (errno != 0) /* could not allocate memory */
>>> +temp = strdup(source);
>>> +if (temp == NULL) /* could not allocate memory */
>>>return (-1);
>>> -strcpy(temp, source);
>>>} else
>>>temp = source;

___
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: r343483 - in head/sbin: newfs tunefs

[Dmitry Morozovsky]

Kirk,

On Sat, 26 Jan 2019, Kirk McKusick wrote:

> Author: mckusick
> Date: Sat Jan 26 22:27:12 2019
> New Revision: 343483
> URL: https://svnweb.freebsd.org/changeset/base/343483
> 
> Log:
>   Update tunefs and newfs error messages for the -L (volume label) option
>   to note that underscores are valid.

while you're here -- most of FSes also allow dash as a valid symbol in FS name.

I stepped on it several times, and even did some local patch, but was too lazy 
to sumbit it.

could you please look into it?

thanks!

>   
>   PR:   235182
>   Reported by:  Rodney W. Grimes (rgrimes@)
>   Sponsored by: Netflix
> 
> Modified:
>   head/sbin/newfs/newfs.c
>   head/sbin/tunefs/tunefs.c
> 
> Modified: head/sbin/newfs/newfs.c
> ==
> --- head/sbin/newfs/newfs.c   Sat Jan 26 22:24:15 2019(r343482)
> +++ head/sbin/newfs/newfs.c   Sat Jan 26 22:27:12 2019(r343483)
> @@ -155,7 +155,8 @@ main(int argc, char *argv[])
>   while (isalnum(volumelabel[++i]) ||
>   volumelabel[i] == '_');
>   if (volumelabel[i] != '\0') {
> - errx(1, "bad volume label. Valid characters are 
> alphanumerics.");
> + errx(1, "bad volume label. Valid characters "
> + "are alphanumerics and underscores.");
>   }
>   if (strlen(volumelabel) >= MAXVOLLEN) {
>   errx(1, "bad volume label. Length is longer 
> than %d.",
> 
> Modified: head/sbin/tunefs/tunefs.c
> ==
> --- head/sbin/tunefs/tunefs.c Sat Jan 26 22:24:15 2019(r343482)
> +++ head/sbin/tunefs/tunefs.c Sat Jan 26 22:27:12 2019(r343483)
> @@ -191,9 +191,8 @@ main(int argc, char *argv[])
>   i = -1;
>   while (isalnum(Lvalue[++i]) || Lvalue[i] == '_');
>   if (Lvalue[i] != '\0') {
> - errx(10,
> - "bad %s. Valid characters are alphanumerics.",
> - name);
> + errx(10, "bad %s. Valid characters are "
> + "alphanumerics and underscores.", name);
>   }
>   if (strlen(Lvalue) >= MAXVOLLEN) {
>   errx(10, "bad %s. Length is longer than %d.",
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
> 

-- 
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***

___
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: r343483 - in head/sbin: newfs tunefs

[Kirk McKusick]

Author: mckusick
Date: Sat Jan 26 22:27:12 2019
New Revision: 343483
URL: https://svnweb.freebsd.org/changeset/base/343483

Log:
  Update tunefs and newfs error messages for the -L (volume label) option
  to note that underscores are valid.
  
  PR:   235182
  Reported by:  Rodney W. Grimes (rgrimes@)
  Sponsored by: Netflix

Modified:
  head/sbin/newfs/newfs.c
  head/sbin/tunefs/tunefs.c

Modified: head/sbin/newfs/newfs.c
==
--- head/sbin/newfs/newfs.c Sat Jan 26 22:24:15 2019(r343482)
+++ head/sbin/newfs/newfs.c Sat Jan 26 22:27:12 2019(r343483)
@@ -155,7 +155,8 @@ main(int argc, char *argv[])
while (isalnum(volumelabel[++i]) ||
volumelabel[i] == '_');
if (volumelabel[i] != '\0') {
-   errx(1, "bad volume label. Valid characters are 
alphanumerics.");
+   errx(1, "bad volume label. Valid characters "
+   "are alphanumerics and underscores.");
}
if (strlen(volumelabel) >= MAXVOLLEN) {
errx(1, "bad volume label. Length is longer 
than %d.",

Modified: head/sbin/tunefs/tunefs.c
==
--- head/sbin/tunefs/tunefs.c   Sat Jan 26 22:24:15 2019(r343482)
+++ head/sbin/tunefs/tunefs.c   Sat Jan 26 22:27:12 2019(r343483)
@@ -191,9 +191,8 @@ main(int argc, char *argv[])
i = -1;
while (isalnum(Lvalue[++i]) || Lvalue[i] == '_');
if (Lvalue[i] != '\0') {
-   errx(10,
-   "bad %s. Valid characters are alphanumerics.",
-   name);
+   errx(10, "bad %s. Valid characters are "
+   "alphanumerics and underscores.", name);
}
if (strlen(Lvalue) >= MAXVOLLEN) {
errx(10, "bad %s. Length is longer than %d.",
___
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: r343480 - head/lib/libfigpar

[Stefan Esser]

Am 26.01.19 um 22:59 schrieb Colin Percival:
> On 1/26/19 1:36 PM, Rodney W. Grimes wrote:
>>> Author: se
>>> Date: Sat Jan 26 21:30:26 2019
>>> New Revision: 343480
>>> URL: https://svnweb.freebsd.org/changeset/base/343480
>>>
>>> Log:
>>>   Silence Clang Scan warning about potentially unsafe use of strcpy.
>>>   
>>>   While this is a false positive, the use of strdup() simplifies the code.
>>
>> Though that might be true, it also has to recalculate the
>> length of the string which was already known by slen.
>>
>> I am not sure how often this code is called,
>> but that is wasted cycles in a library.
> 
> The length of the string was already being recalculated, by strcpy.
> 
> It seems to me that this could be written as
> 
>   temp = malloc(slen + 1);
>   if (temp == NULL) /* could not allocate memory */
>   return (-1);
>   memcpy(temp, source, slen + 1);
> 
> which avoids both recalculating the string length and using strcpy?

In principle you are right, there is a small run-time cost by not using
the known length for the allocation.

The Clang Scan checks are leading to lots (thousands) of false positives
and a I have looked at quite a number and abstained from silencing them
in the hope that the scan will be improved.

It should learn that at least the trivial case of an allocation of the
value of strlen()+1 followed by a strcpy (and no further strcat or the
like) is safe.

But I have seen cases where the assumption is that "i<0" followed by
"i>=0" at the same location and then a warning about potential problem.

I have committed the version you suggest in rev. 343482 ...

Regards, STefan
___
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: r343482 - head/lib/libfigpar

[Stefan Esser]

Author: se
Date: Sat Jan 26 22:24:15 2019
New Revision: 343482
URL: https://svnweb.freebsd.org/changeset/base/343482

Log:
  Slightly improve previous commit that silenced a Clang Scan warning.
  
  The strdup() call does not take advantage of the known length of the
  source string. Replace by malloc() and memcpy() utilizimng the pre-
  calculated string length.
  
  Submitted by: cperciva
  Reported by:  rgrimes
  MFC after:2 weeks

Modified:
  head/lib/libfigpar/string_m.c

Modified: head/lib/libfigpar/string_m.c
==
--- head/lib/libfigpar/string_m.c   Sat Jan 26 21:35:51 2019
(r343481)
+++ head/lib/libfigpar/string_m.c   Sat Jan 26 22:24:15 2019
(r343482)
@@ -119,9 +119,10 @@ replaceall(char *source, const char *find, const char 
 
/* If replace is longer than find, we'll need to create a temp copy */
if (rlen > flen) {
-   temp = strdup(source);
+   temp = malloc(slen + 1);
if (temp == NULL) /* could not allocate memory */
return (-1);
+   memcpy(temp, source, slen + 1);
} else
temp = source;
 
___
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: r343480 - head/lib/libfigpar

[Colin Percival]

On 1/26/19 1:36 PM, Rodney W. Grimes wrote:
>> Author: se
>> Date: Sat Jan 26 21:30:26 2019
>> New Revision: 343480
>> URL: https://svnweb.freebsd.org/changeset/base/343480
>>
>> Log:
>>   Silence Clang Scan warning about potentially unsafe use of strcpy.
>>   
>>   While this is a false positive, the use of strdup() simplifies the code.
> 
> Though that might be true, it also has to recalculate the
> length of the string which was already known by slen.
> 
> I am not sure how often this code is called,
> but that is wasted cycles in a library.

The length of the string was already being recalculated, by strcpy.

It seems to me that this could be written as

temp = malloc(slen + 1);
if (temp == NULL) /* could not allocate memory */
return (-1);
memcpy(temp, source, slen + 1);

which avoids both recalculating the string length and using strcpy?

>> Modified: head/lib/libfigpar/string_m.c
>> ==
>> --- head/lib/libfigpar/string_m.cSat Jan 26 20:43:28 2019
>> (r343479)
>> +++ head/lib/libfigpar/string_m.cSat Jan 26 21:30:26 2019
>> (r343480)
>> @@ -119,10 +119,9 @@ replaceall(char *source, const char *find, const char 
>>  
>>  /* If replace is longer than find, we'll need to create a temp copy */
>>  if (rlen > flen) {
>> -temp = malloc(slen + 1);
>> -if (errno != 0) /* could not allocate memory */
>> +temp = strdup(source);
>> +if (temp == NULL) /* could not allocate memory */
>>  return (-1);
>> -strcpy(temp, source);
>>  } else
>>  temp = source;

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
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: r343481 - head/sys/net

[Marius Strobl]

Author: marius
Date: Sat Jan 26 21:35:51 2019
New Revision: 343481
URL: https://svnweb.freebsd.org/changeset/base/343481

Log:
  - In _iflib_fl_refill(), don't mark an RX buffer as available in the
corresponding bitmap before adding an mbuf has actually succeeded.
Previously, m_gethdr(M_NOWAIT, ...) failing caused a "hole" in the
RX ring but not in its bitmap. One implication of such a hole was
that in a subsequent call to _iflib_fl_refill() with the RX buffer
accounting still indicating another reclaimable buffer, bit_ffc(3)
nevertheless returned -1 in frag_idx which in turn caused havoc
when used as an index. Thus, additionally assert that frag_idx is
0 or greater.
Another possible consequence of a hole in the RX ring was a NULL-
dereference when trying to use the unallocated mbuf, for example
in iflib_rxd_pkt_get().
  
While at it, make the variable declarations in _iflib_fl_refill()
conform to style(9) and remove redundant checks already performed
by bit_ffc{,_at}(3).
  
  - In iflib_queues_alloc(), don't pass redundant M_ZERO to bit_alloc(3).
  
  Reported and tested by: pho

Modified:
  head/sys/net/iflib.c

Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cSat Jan 26 21:30:26 2019(r343480)
+++ head/sys/net/iflib.cSat Jan 26 21:35:51 2019(r343481)
@@ -1921,27 +1921,27 @@ _rxq_refill_cb(void *arg, bus_dma_segment_t *segs, int
 static void
 _iflib_fl_refill(if_ctx_t ctx, iflib_fl_t fl, int count)
 {
+   struct if_rxd_update iru;
+   struct rxq_refill_cb_arg cb_arg;
struct mbuf *m;
-   int idx, frag_idx = fl->ifl_fragidx;
-int pidx = fl->ifl_pidx;
caddr_t cl, *sd_cl;
struct mbuf **sd_m;
-   struct if_rxd_update iru;
-   struct rxq_refill_cb_arg cb_arg;
bus_dmamap_t *sd_map;
-   int n, i = 0;
bus_addr_t bus_addr, *sd_ba;
-   int err;
+   int err, frag_idx, i, idx, n, pidx;
qidx_t credits;
 
sd_m = fl->ifl_sds.ifsd_m;
sd_map = fl->ifl_sds.ifsd_map;
sd_cl = fl->ifl_sds.ifsd_cl;
sd_ba = fl->ifl_sds.ifsd_ba;
+   pidx = fl->ifl_pidx;
idx = pidx;
+   frag_idx = fl->ifl_fragidx;
credits = fl->ifl_credits;
 
-   n  = count;
+   i = 0;
+   n = count;
MPASS(n > 0);
MPASS(credits + n <= fl->ifl_size);
 
@@ -1963,9 +1963,11 @@ _iflib_fl_refill(if_ctx_t ctx, iflib_fl_t fl, int coun
 *
 * If the cluster is still set then we know a minimum sized 
packet was received
 */
-   bit_ffc_at(fl->ifl_rx_bitmap, frag_idx, fl->ifl_size,  
&frag_idx);
-   if ((frag_idx < 0) || (frag_idx >= fl->ifl_size))
-   bit_ffc(fl->ifl_rx_bitmap, fl->ifl_size, &frag_idx);
+   bit_ffc_at(fl->ifl_rx_bitmap, frag_idx, fl->ifl_size,
+   &frag_idx);
+   if (frag_idx < 0)
+   bit_ffc(fl->ifl_rx_bitmap, fl->ifl_size, &frag_idx);
+   MPASS(frag_idx >= 0);
if ((cl = sd_cl[frag_idx]) == NULL) {
if ((cl = m_cljget(NULL, M_NOWAIT, fl->ifl_buf_size)) 
== NULL)
break;
@@ -1995,12 +1997,12 @@ _iflib_fl_refill(if_ctx_t ctx, iflib_fl_t fl, int coun
bus_addr = sd_ba[frag_idx];
}
 
-   bit_set(fl->ifl_rx_bitmap, frag_idx);
MPASS(sd_m[frag_idx] == NULL);
if ((m = m_gethdr(M_NOWAIT, MT_NOINIT)) == NULL) {
break;
}
sd_m[frag_idx] = m;
+   bit_set(fl->ifl_rx_bitmap, frag_idx);
 #if MEMORY_LOGGING
fl->ifl_m_enqueued++;
 #endif
@@ -2025,7 +2027,6 @@ _iflib_fl_refill(if_ctx_t ctx, iflib_fl_t fl, int coun
fl->ifl_pidx = idx;
fl->ifl_credits = credits;
}
-
}
 
if (i) {
@@ -4896,7 +4897,6 @@ iflib_device_deregister(if_ctx_t ctx)
 
for (j = 0, fl = rxq->ifr_fl; j < rxq->ifr_nfl; j++, fl++)
free(fl->ifl_rx_bitmap, M_IFLIB);
-   
}
tqg = qgroup_if_config_tqg;
if (ctx->ifc_admin_task.gt_uniq != NULL)
@@ -5304,7 +5304,8 @@ iflib_queues_alloc(if_ctx_t ctx)
}
 
for (j = 0, fl = rxq->ifr_fl; j < rxq->ifr_nfl; j++, fl++) 
-   fl->ifl_rx_bitmap = bit_alloc(fl->ifl_size, M_IFLIB, 
M_WAITOK|M_ZERO);
+   fl->ifl_rx_bitmap = bit_alloc(fl->ifl_size, M_IFLIB,
+   M_WAITOK);
}
 
/* TXQs */
___
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-unsubsc

Re: svn commit: r343480 - head/lib/libfigpar

[Rodney W. Grimes]

> Author: se
> Date: Sat Jan 26 21:30:26 2019
> New Revision: 343480
> URL: https://svnweb.freebsd.org/changeset/base/343480
> 
> Log:
>   Silence Clang Scan warning about potentially unsafe use of strcpy.
>   
>   While this is a false positive, the use of strdup() simplifies the code.

Though that might be true, it also has to recalculate the
length of the string which was already known by slen.

I am not sure how often this code is called,
but that is wasted cycles in a library.

>   
>   MFC after:  2 weeks
> 
> Modified:
>   head/lib/libfigpar/string_m.c
> 
> Modified: head/lib/libfigpar/string_m.c
> ==
> --- head/lib/libfigpar/string_m.c Sat Jan 26 20:43:28 2019
> (r343479)
> +++ head/lib/libfigpar/string_m.c Sat Jan 26 21:30:26 2019
> (r343480)
> @@ -119,10 +119,9 @@ replaceall(char *source, const char *find, const char 
>  
>   /* If replace is longer than find, we'll need to create a temp copy */
>   if (rlen > flen) {
> - temp = malloc(slen + 1);
> - if (errno != 0) /* could not allocate memory */
> + temp = strdup(source);
> + if (temp == NULL) /* could not allocate memory */
>   return (-1);
> - strcpy(temp, source);
>   } else
>   temp = source;
>  
> 
> 

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

svn commit: r343480 - head/lib/libfigpar

[Stefan Esser]

Author: se
Date: Sat Jan 26 21:30:26 2019
New Revision: 343480
URL: https://svnweb.freebsd.org/changeset/base/343480

Log:
  Silence Clang Scan warning about potentially unsafe use of strcpy.
  
  While this is a false positive, the use of strdup() simplifies the code.
  
  MFC after:2 weeks

Modified:
  head/lib/libfigpar/string_m.c

Modified: head/lib/libfigpar/string_m.c
==
--- head/lib/libfigpar/string_m.c   Sat Jan 26 20:43:28 2019
(r343479)
+++ head/lib/libfigpar/string_m.c   Sat Jan 26 21:30:26 2019
(r343480)
@@ -119,10 +119,9 @@ replaceall(char *source, const char *find, const char 
 
/* If replace is longer than find, we'll need to create a temp copy */
if (rlen > flen) {
-   temp = malloc(slen + 1);
-   if (errno != 0) /* could not allocate memory */
+   temp = strdup(source);
+   if (temp == NULL) /* could not allocate memory */
return (-1);
-   strcpy(temp, source);
} else
temp = source;
 
___
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: r343479 - head/libexec/getty

[Stefan Esser]

Author: se
Date: Sat Jan 26 20:43:28 2019
New Revision: 343479
URL: https://svnweb.freebsd.org/changeset/base/343479

Log:
  Fix potential buffer overflow and undefined behavior.
  
  The buffer allocated in read_chat() could be 1 element too short, if the
  chatstr parameter passed in is 1 or 3 charachters long (e.g. "a" or "a b").
  The allocation of the pointer array does not account for the terminating
  NULL pointer in that case.
  
  Overlapping source and destination strings are undefined in strcpy().
  Instead of moving a string to the left by one character just increment the
  char pointer before it is assigned to the results array.
  
  MFC after:2 weeks

Modified:
  head/libexec/getty/chat.c

Modified: head/libexec/getty/chat.c
==
--- head/libexec/getty/chat.c   Sat Jan 26 18:23:19 2019(r343478)
+++ head/libexec/getty/chat.c   Sat Jan 26 20:43:28 2019(r343479)
@@ -141,7 +141,7 @@ read_chat(char **chatstr)
int l;
 
if ((l=strlen(str)) > 0 && (tmp=malloc(l + 1)) != NULL &&
-   (res=malloc((l / 2 + 1) * sizeof(char *))) != NULL) {
+   (res=malloc(((l + 1) / 2 + 1) * sizeof(char *))) != NULL) {
static char ws[] = " \t";
char * p;
 
@@ -216,7 +216,7 @@ read_chat(char **chatstr)
q = strrchr(p+1, *p);
if (q != NULL && *q == *p && q[1] == 
'\0') {
*q = '\0';
-   strcpy(p, p+1);
+   p++;
}
}
 
___
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: r343440 - head/bin/sh

[Ian Lepore]

On Sat, 2019-01-26 at 11:11 -0800, Conrad Meyer wrote:
> I didn't really feel the need to weigh in on this bikeshed thread
> previously, but apparently some folks are calling for a revert.  Why?
> I don't really understand how this meets the high bar for summary
> revert, even if you disagree with the change made (and disagreement
> is
> fine, of course).
> 
> So I'll raise my hand for "leave it in" and encourage talking out
> your
> bikeshed.  It would be persuasive to come up with a specific list of
> complaints, ideally excluding ones that have been shown to be
> baseless.  So far there has been a lot of mudslinging and it's
> difficult to sort out the preference complaints from the security
> complaints from the (well-intentioned, but ultimately inaccurate)
> fiction.  I don't think a "heckler's veto" should be granted.
> 
> If you don't use root/toor, that's fine!  But I think that sort of
> (heavily) discounts how much weight your opinion of root/toor
> defaults
> should be given.
> 
> If you use Expect, great.  You should be setting a specific PS1
> anyway
> (both before and after this change).  After all, this is just the
> default.  Users have been free to set a custom PS1 for root in
> .profile since time began.
> 
> Has anyone verified the claim that freebsd-update will actually
> modify
> a user's home directory contents, or was that just speculation?  I
> don't know one way or the other and I think it's still an open
> question.
> 
> Best regards,
> Conrad
> 

Wait a sec... something has been stable and working fine for 30 years,
then it gets changed to reflect one man's personal preferences, and
it's the people who object to that who have to jump through flaming
hoops to justify themselves?

Screw that. Don't bother to CC me in any replies, I'm out of this
conversation.

It's a pity the freebsd prject has turned into linux.

-- ian

> On Fri, Jan 25, 2019 at 9:09 AM Edward Tomasz Napierala
>  wrote:
> > 
> > Author: trasz
> > Date: Fri Jan 25 17:09:26 2019
> > New Revision: 343440
> > URL: https://svnweb.freebsd.org/changeset/base/343440
> > 
> > Log:
> >   Comment out the default sh(1) aliases for root, introduced in
> > r343416.
> >   The rest of this stuff is still to be discussed, but I think at
> > this
> >   point we have the agreement that the aliases should go.
> > 
> >   MFC after:2 weeks
> >   Sponsored by: DARPA, AFRL
> > 
> > Modified:
> >   head/bin/sh/dot.shrc
> > 
> > Modified: head/bin/sh/dot.shrc
> > ===
> > ===
> > --- head/bin/sh/dot.shrcFri Jan 25 17:08:28
> > 2019(r343439)
> > +++ head/bin/sh/dot.shrcFri Jan 25 17:09:26
> > 2019(r343440)
> > @@ -18,13 +18,13 @@
> >  # set -o vi
> > 
> > 
> > -# some useful aliases
> > -alias h='fc -l'
> > -alias j=jobs
> > -alias m="$PAGER"
> > -alias ll='ls -laFo'
> > -alias l='ls -l'
> > -alias g='egrep -i'
> > +# # some useful aliases
> > +# alias h='fc -l'
> > +# alias j=jobs
> > +# alias m="$PAGER"
> > +# alias ll='ls -laFo'
> > +# alias l='ls -l'
> > +# alias g='egrep -i'
> > 
> >  # # be paranoid
> >  # alias cp='cp -ip'
> > 
> 
> 

___
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: r343440 - head/bin/sh

[Conrad Meyer]

I didn't really feel the need to weigh in on this bikeshed thread
previously, but apparently some folks are calling for a revert.  Why?
I don't really understand how this meets the high bar for summary
revert, even if you disagree with the change made (and disagreement is
fine, of course).

So I'll raise my hand for "leave it in" and encourage talking out your
bikeshed.  It would be persuasive to come up with a specific list of
complaints, ideally excluding ones that have been shown to be
baseless.  So far there has been a lot of mudslinging and it's
difficult to sort out the preference complaints from the security
complaints from the (well-intentioned, but ultimately inaccurate)
fiction.  I don't think a "heckler's veto" should be granted.

If you don't use root/toor, that's fine!  But I think that sort of
(heavily) discounts how much weight your opinion of root/toor defaults
should be given.

If you use Expect, great.  You should be setting a specific PS1 anyway
(both before and after this change).  After all, this is just the
default.  Users have been free to set a custom PS1 for root in
.profile since time began.

Has anyone verified the claim that freebsd-update will actually modify
a user's home directory contents, or was that just speculation?  I
don't know one way or the other and I think it's still an open
question.

Best regards,
Conrad

On Fri, Jan 25, 2019 at 9:09 AM Edward Tomasz Napierala
 wrote:
>
> Author: trasz
> Date: Fri Jan 25 17:09:26 2019
> New Revision: 343440
> URL: https://svnweb.freebsd.org/changeset/base/343440
>
> Log:
>   Comment out the default sh(1) aliases for root, introduced in r343416.
>   The rest of this stuff is still to be discussed, but I think at this
>   point we have the agreement that the aliases should go.
>
>   MFC after:2 weeks
>   Sponsored by: DARPA, AFRL
>
> Modified:
>   head/bin/sh/dot.shrc
>
> Modified: head/bin/sh/dot.shrc
> ==
> --- head/bin/sh/dot.shrcFri Jan 25 17:08:28 2019(r343439)
> +++ head/bin/sh/dot.shrcFri Jan 25 17:09:26 2019(r343440)
> @@ -18,13 +18,13 @@
>  # set -o vi
>
>
> -# some useful aliases
> -alias h='fc -l'
> -alias j=jobs
> -alias m="$PAGER"
> -alias ll='ls -laFo'
> -alias l='ls -l'
> -alias g='egrep -i'
> +# # some useful aliases
> +# alias h='fc -l'
> +# alias j=jobs
> +# alias m="$PAGER"
> +# alias ll='ls -laFo'
> +# alias l='ls -l'
> +# alias g='egrep -i'
>
>  # # be paranoid
>  # alias cp='cp -ip'
>
___
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: r343478 - head/tools/kerneldoc/subsys

[Alexander Leidinger]

Author: netchild
Date: Sat Jan 26 18:23:19 2019
New Revision: 343478
URL: https://svnweb.freebsd.org/changeset/base/343478

Log:
  Catch up with some years of driver development.
  Most impressive in terms of doxygen stuff are the isci and
  ocs_fc drivers.

Added:
  head/tools/kerneldoc/subsys/Doxyfile-dev_aacraid   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_al_eth   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_alpm   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_altera   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_amd_ecc_inject   (contents, props 
changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_amdgpio   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_amdpm   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_amdsmb   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_amdsmn   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_axgbe   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_beri   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_bhnd   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_bnxt   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_bvm   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_cadence   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_chromebook_platform   (contents, 
props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_cyapa   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_dme   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_dpaa   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_drm2   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_dwc   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_efidev   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ena   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_etherswitch   (contents, props 
changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_evdev   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_extres   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ffec   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_filemon   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_gxemul   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_hdmi   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_hptnr   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_hyperv   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ichiic   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_imcsmb   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_intel   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_intpm   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ioat   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_isci   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_iscsi_initiator   (contents, props 
changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_iser   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_isl   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ismt   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_iwm   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ixl   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_jedec_dimm   (contents, props 
changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_liquidio   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mbox   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mdio   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mlx4   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mlx5   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mmcnull   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mpr   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mrsas   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_mthca   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_nand   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_nctgpio   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_neta   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_netfpga10g   (contents, props 
changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_nfsmb   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_ntb   (contents, props changed)
  head/tools/kerneldoc/subsys/Doxyfile-dev_nvd   (contents, props cha

Re: svn commit: r343440 - head/bin/sh

[Devin Teske]

> On Jan 26, 2019, at 9:55 AM, Ian Lepore  wrote:
> 
> On Sat, 2019-01-26 at 09:17 -0800, Rodney W. Grimes wrote:
>>> On Sat, 2019-01-26 at 13:18 +, Edward Napierala wrote:
 On 0125T1647, Devin Teske wrote:
>> On Jan 25, 2019, at 1:13 AM, Edward Napierala <
>> tr...@freebsd.org>
>> wrote:
>> On 0125T1530, Devin Teske wrote:
 On Jan 25, 2019, at 12:28 AM, Edward Napierala <
 tr...@freebsd.org> wrote:
 On 0125T1441, Devin Teske wrote:
>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <
>> tr...@freebsd.org> wrote:
>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes
>> > free...@pdx.rh.cn85.dnsmgr.net>> napisa?(a):
>> 
>> ...
 
>>> 
>>> No, it's not just the aliases. The part that angers me the most is
>>> the
>>> changing of PS1. I still haven't seen anything that justifies any
>>> of
>>> these changes other than your opinion that you like your changes
>>> better
>>> than what was there before.
>> 
>> I have asked once in public, and once in private in not such a
>> polite tone (Uncalled for, sorry Traz) that this be reverted.
>> This discussion has gone on far too long on -committers and
>> this change is clearly controversial.
>> 
>> Ian, Please assert a request to revert as well, as it seems
>> Traz is stuck in the "this is just a bikeshed" and is not
>> going to move on my request alone, though it was also asserted
>> by Devin.
>> 
>> Thanks,
> 
> Since informal discussion doesn't seem to be getting through, I will
> indeed add my name to the list of those calling for a revert.
> 

I'm actually backing away slowly.
-- 
Devin

___
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: r343440 - head/bin/sh

[Ian Lepore]

On Sat, 2019-01-26 at 09:17 -0800, Rodney W. Grimes wrote:
> > On Sat, 2019-01-26 at 13:18 +, Edward Napierala wrote:
> > > On 0125T1647, Devin Teske wrote:
> > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala <
> > > > > tr...@freebsd.org>
> > > > > wrote:
> > > > > On 0125T1530, Devin Teske wrote:
> > > > > > > On Jan 25, 2019, at 12:28 AM, Edward Napierala <
> > > > > > > tr...@freebsd.org> wrote:
> > > > > > > On 0125T1441, Devin Teske wrote:
> > > > > > > > > On Jan 25, 2019, at 1:37 PM, Edward Napierala <
> > > > > > > > > tr...@freebsd.org> wrote:
> > > > > > > > > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > > > > > > > >  > > > > > > > > free...@pdx.rh.cn85.dnsmgr.net>> napisa?(a):
> 
> ...
> > > 
> > 
> > No, it's not just the aliases. The part that angers me the most is
> > the
> > changing of PS1. I still haven't seen anything that justifies any
> > of
> > these changes other than your opinion that you like your changes
> > better
> > than what was there before.
> 
> I have asked once in public, and once in private in not such a
> polite tone (Uncalled for, sorry Traz) that this be reverted.
> This discussion has gone on far too long on -committers and
> this change is clearly controversial.
> 
> Ian, Please assert a request to revert as well, as it seems
> Traz is stuck in the "this is just a bikeshed" and is not
> going to move on my request alone, though it was also asserted
> by Devin.
> 
> Thanks,

Since informal discussion doesn't seem to be getting through, I will
indeed add my name to the list of those calling for a revert.

-- Ian

___
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: r343477 - head/sys/dev/iwm

[Bjoern A. Zeeb]

Author: bz
Date: Sat Jan 26 17:52:12 2019
New Revision: 343477
URL: https://svnweb.freebsd.org/changeset/base/343477

Log:
  Fix logic errors in iwm_pcie_load_firmware_chunk introduced in r314065.
  
   * There's no reason to have a while() loop here, because:
  - if msleep returns 0, that means we were woken up by the interrupt 
handler,
and we are going to exit immediately as sc_fw_chunk_done will now be 1
(there is nothing else that sleeps on sc_fw.)
  - if msleep doesn't return 0 (i.e. it returned ETIMEDOUT) then we will
exit immediately because of the if-test.
 So, just use a single msleep() and then check sc_fw_chunk_done as before.
   * The comment said we were sleeping for 5 seconds, but the msleep was only
 for 1. Before r314065, this was 1 second and so was the comment,
 and in that commit the comment was changed and the function call wasn't.
  
  Possibly fixes failures to initialize uCode on certain devices.
  
  Submitted by: Augustin Cavalier (waddlesplash gmail.com)
  Obtained from:Haiku 132990ecdcb072f2ce597b5d497ff3e5b1f09c20
  MFC after:10 days

Modified:
  head/sys/dev/iwm/if_iwm.c

Modified: head/sys/dev/iwm/if_iwm.c
==
--- head/sys/dev/iwm/if_iwm.c   Sat Jan 26 17:27:12 2019(r343476)
+++ head/sys/dev/iwm/if_iwm.c   Sat Jan 26 17:52:12 2019(r343477)
@@ -2397,8 +2397,6 @@ static int
 iwm_pcie_load_firmware_chunk(struct iwm_softc *sc, uint32_t dst_addr,
 bus_addr_t phy_addr, uint32_t byte_cnt)
 {
-   int ret;
-
sc->sc_fw_chunk_done = 0;
 
if (!iwm_nic_lock(sc))
@@ -2430,14 +2428,9 @@ iwm_pcie_load_firmware_chunk(struct iwm_softc *sc, uin
iwm_nic_unlock(sc);
 
/* wait up to 5s for this segment to load */
-   ret = 0;
-   while (!sc->sc_fw_chunk_done) {
-   ret = msleep(&sc->sc_fw, &sc->sc_mtx, 0, "iwmfw", hz);
-   if (ret)
-   break;
-   }
+   msleep(&sc->sc_fw, &sc->sc_mtx, 0, "iwmfw", hz * 5);
 
-   if (ret != 0) {
+   if (!sc->sc_fw_chunk_done) {
device_printf(sc->sc_dev,
"fw chunk addr 0x%x len %d failed to load\n",
dst_addr, byte_cnt);
___
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: r343476 - head

[Andriy Voskoboinyk]

Author: avos
Date: Sat Jan 26 17:27:12 2019
New Revision: 343476
URL: https://svnweb.freebsd.org/changeset/base/343476

Log:
  ObsoleteFiles.inc: remove adv(4) / adw(4) man pages after r339567

Modified:
  head/ObsoleteFiles.inc

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Sat Jan 26 17:17:25 2019(r343475)
+++ head/ObsoleteFiles.inc  Sat Jan 26 17:27:12 2019(r343476)
@@ -38,6 +38,9 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20190126: adv(4) / adw(4) removal
+OLD_FILES+=usr/share/man/man4/adv.4.gz
+OLD_FILES+=usr/share/man/man4/adw.4.gz
 # 20190114: old pbuf allocator removed
 OLD_FILES+=usr/share/man/man9/pbuf.9.gz
 # 20181219: ibcs removal
___
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: r343440 - head/bin/sh

[Rodney W. Grimes]

> On 0125T1647, Devin Teske wrote:
> > > On Jan 25, 2019, at 1:13 AM, Edward Napierala  wrote:
> > > On 0125T1530, Devin Teske wrote:
> > >>> On Jan 25, 2019, at 12:28 AM, Edward Napierala  
> > >>> wrote:
> > >>> On 0125T1441, Devin Teske wrote:
> > > On Jan 25, 2019, at 1:37 PM, Edward Napierala  
> > > wrote:
> > > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > >  > > > napisa?(a):
> > >>> Author: trasz
> > >>> Date: Fri Jan 25 17:09:26 2019
> > >>> New Revision: 343440
> > >>> URL: https://svnweb.freebsd.org/changeset/base/343440
> > >>> 
> > >>> Log:
> > >>> Comment out the default sh(1) aliases for root, introduced in 
> > >>> r343416.
> > >>> The rest of this stuff is still to be discussed, but I think at this
> > >>> point we have the agreement that the aliases should go.
> > >>> 
> > >>> MFC after:  2 weeks
> > >>> Sponsored by:   DARPA, AFRL
> > >> 
> > >> Please just revert this and the prior commit out, and when
> > >> the path forward is clear commit it.  I would not want any of this
> > >> merged to 12/ or 11/ until the time that it is all settled.
> > > 
> > > Oops, my bad - neither this nor the previous commit is supposed
> > > to be MFC-ed; the "2 weeks" above comes from my default Subversion
> > > config.
> > > 
> > > Regarding the backoff - just a few hours ago you said you don't have
> > > any problem with this, except for aliases and the default ENV.  The
> > > aliases problem has been addressed, and you hadn't yet responded
> > > to my explanations regarding the ENV.  Another committer asked for
> > > backoff, because "sh is not an interactive shell", while in fact sh(1)
> > > is FreeBSD's default interactive shell except for root.  Finally, 
> > > there's
> > > one person who asked for revert, but without giving any reasons
> > > whatsoever.
> > > 
> > > So far nobody had proposed any scenario where this would break
> > > anything, or even affect existing users.  It seems like a typical 
> > > bikeshed
> > > situation.
> >  
> >  It is not clear to me after reading r343416 and D18872 what this 
> >  change is trying to solve.
> > >>> 
> > >>> The idea is to make it easy to replace the default root shell - which
> > >>> many people consider broken, due to not supporting basic shell syntax - 
> > >>> with
> > >>> something that actually works.
> > >> 
> > >> How exactly does changing PS1 or adding 6 aliases fix the "basic shell 
> > >> syntax" which you claim to be unsupported?
> > >> 
> > >> If the number of aliases added to a shell are a measure of its 
> > >> brokenness, then bash must be hella broken (I have 43 aliases in my 
> > >> bash_profile).
> > > 
> > > The aliases are gone.
> > 
> > Fair enough, albeit the topic was r343416 and D18872.
> > 
> > 
> > >  Human-friendly PS1 is considered a standard feature
> > > nowadays.
> > 
> > I fail to see how ''$ " is unfriendly.
> 
> How many people you know use a plain '$' as a shell prompt,
> because they like it that way?

I am prefectly happy with any single character prompt on
any OS I might happen to be working on, knowing that I
can change it at my leasure.

However I am NOT happy with a stringy long ass prompt
that eats up half my command line when I am deep down
a file hierarchy trying to fix some problem at a
single user prompt on a hardwired conssole I had to
jack into the box cause it wont come up.

Yes I can change either at will, and so can anyone
else who wants to, lets stop spoon feeding a new
default and spoon feed up some docs on "you may
want to tweak this" after you have installed.

-- 
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: r343440 - head/bin/sh

[Rodney W. Grimes]

> On Sat, 2019-01-26 at 13:18 +, Edward Napierala wrote:
> > On 0125T1647, Devin Teske wrote:
> > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala 
> > > > wrote:
> > > > On 0125T1530, Devin Teske wrote:
> > > > > > On Jan 25, 2019, at 12:28 AM, Edward Napierala <
> > > > > > tr...@freebsd.org> wrote:
> > > > > > On 0125T1441, Devin Teske wrote:
> > > > > > > > On Jan 25, 2019, at 1:37 PM, Edward Napierala <
> > > > > > > > tr...@freebsd.org> wrote:
> > > > > > > > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > > > > > > >  > > > > > > > free...@pdx.rh.cn85.dnsmgr.net>> napisa?(a):
...
> > 
> 
> No, it's not just the aliases. The part that angers me the most is the
> changing of PS1. I still haven't seen anything that justifies any of
> these changes other than your opinion that you like your changes better
> than what was there before.

I have asked once in public, and once in private in not such a
polite tone (Uncalled for, sorry Traz) that this be reverted.
This discussion has gone on far too long on -committers and
this change is clearly controversial.

Ian, Please assert a request to revert as well, as it seems
Traz is stuck in the "this is just a bikeshed" and is not
going to move on my request alone, though it was also asserted
by Devin.

Thanks,
-- 
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"

svn commit: r343475 - head/sys/geom/uzip

[Andriy Voskoboinyk]

Author: avos
Date: Sat Jan 26 17:17:25 2019
New Revision: 343475
URL: https://svnweb.freebsd.org/changeset/base/343475

Log:
  geom_uzip(4): set 'gp != NULL' assertion on top of the function
  
  There was yet another access to this variable in g_trace() few
  lines upper.
  
  PR:   203499
  Reported by:  cem
  MFC after:5 days
  MFC with: 343473

Modified:
  head/sys/geom/uzip/g_uzip.c

Modified: head/sys/geom/uzip/g_uzip.c
==
--- head/sys/geom/uzip/g_uzip.c Sat Jan 26 17:00:55 2019(r343474)
+++ head/sys/geom/uzip/g_uzip.c Sat Jan 26 17:17:25 2019(r343475)
@@ -886,10 +886,10 @@ g_uzip_destroy_geom(struct gctl_req *req, struct g_cla
 {
struct g_provider *pp;
 
+   KASSERT(gp != NULL, ("NULL geom"));
g_trace(G_T_TOPOLOGY, "%s(%s, %s)", __func__, mp->name, gp->name);
g_topology_assert();
 
-   KASSERT(gp != NULL, ("NULL geom"));
if (gp->softc == NULL) {
DPRINTF(GUZ_DBG_ERR, ("%s(%s): gp->softc == NULL\n", __func__,
gp->name));
___
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: r343474 - in head/sys: dev/bwi dev/iwi dev/ral dev/rtwn dev/usb/wlan net80211

[Andriy Voskoboinyk]

Author: avos
Date: Sat Jan 26 17:00:55 2019
New Revision: 343474
URL: https://svnweb.freebsd.org/changeset/base/343474

Log:
  Remove 2GHz channel list copies from wireless drivers.
  
  Wrap ieee80211_add_channel_list_2ghz into another function
  which supplies default (1-14) channel list to it and drop
  its copies from drivers.
  
  Checked with RTL8188EE, country US / JP / KR / UA.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/bwi/if_bwi.c
  head/sys/dev/iwi/if_iwi.c
  head/sys/dev/ral/rt2560.c
  head/sys/dev/ral/rt2661.c
  head/sys/dev/ral/rt2860.c
  head/sys/dev/rtwn/if_rtwn.c
  head/sys/dev/usb/wlan/if_rsu.c
  head/sys/dev/usb/wlan/if_rum.c
  head/sys/dev/usb/wlan/if_run.c
  head/sys/dev/usb/wlan/if_runreg.h
  head/sys/dev/usb/wlan/if_ural.c
  head/sys/dev/usb/wlan/if_urtw.c
  head/sys/dev/usb/wlan/if_zyd.c
  head/sys/dev/usb/wlan/if_zydreg.h
  head/sys/net80211/ieee80211.c
  head/sys/net80211/ieee80211_var.h

Modified: head/sys/dev/bwi/if_bwi.c
==
--- head/sys/dev/bwi/if_bwi.c   Sat Jan 26 14:54:06 2019(r343473)
+++ head/sys/dev/bwi/if_bwi.c   Sat Jan 26 17:00:55 2019(r343474)
@@ -307,9 +307,6 @@ static const struct {
[108]   = { 7, 3 }
 };
 
-static const uint8_t bwi_chan_2ghz[] =
-   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 };
-
 #ifdef BWI_DEBUG
 #ifdef BWI_DEBUG_VERBOSE
 static uint32_t bwi_debug = BWI_DBG_ATTACH | BWI_DBG_INIT | BWI_DBG_TXPOWER;
@@ -1715,8 +1712,7 @@ bwi_getradiocaps(struct ieee80211com *ic,
panic("unknown phymode %d\n", phy->phy_mode);
}
 
-   ieee80211_add_channel_list_2ghz(chans, maxchans, nchans,
-   bwi_chan_2ghz, nitems(bwi_chan_2ghz), bands, 0);
+   ieee80211_add_channels_default_2ghz(chans, maxchans, nchans, bands, 0);
 }
 
 static void

Modified: head/sys/dev/iwi/if_iwi.c
==
--- head/sys/dev/iwi/if_iwi.c   Sat Jan 26 14:54:06 2019(r343473)
+++ head/sys/dev/iwi/if_iwi.c   Sat Jan 26 17:00:55 2019(r343474)
@@ -132,8 +132,6 @@ static const struct iwi_ident iwi_ident_table[] = {
{ 0, 0, NULL }
 };
 
-static const uint8_t def_chan_2ghz[] =
-   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 };
 static const uint8_t def_chan_5ghz_band1[] =
{ 36, 40, 44, 48, 52, 56, 60, 64 };
 static const uint8_t def_chan_5ghz_band2[] =
@@ -3604,8 +3602,8 @@ iwi_getradiocaps(struct ieee80211com *ic,
iwi_collect_bands(ic, bands, sizeof(bands));
*nchans = 0;
if (isset(bands, IEEE80211_MODE_11B) || isset(bands, 
IEEE80211_MODE_11G))
-   ieee80211_add_channel_list_2ghz(chans, maxchans, nchans,
-   def_chan_2ghz, nitems(def_chan_2ghz), bands, 0);
+   ieee80211_add_channels_default_2ghz(chans, maxchans, nchans,
+   bands, 0);
if (isset(bands, IEEE80211_MODE_11A)) {
ieee80211_add_channel_list_5ghz(chans, maxchans, nchans,
def_chan_5ghz_band1, nitems(def_chan_5ghz_band1),

Modified: head/sys/dev/ral/rt2560.c
==
--- head/sys/dev/ral/rt2560.c   Sat Jan 26 14:54:06 2019(r343473)
+++ head/sys/dev/ral/rt2560.c   Sat Jan 26 17:00:55 2019(r343474)
@@ -189,9 +189,6 @@ static const uint32_t rt2560_rf2525e_r2[]   = RT2560_R
 static const uint32_t rt2560_rf2526_r2[]= RT2560_RF2526_R2;
 static const uint32_t rt2560_rf2526_hi_r2[] = RT2560_RF2526_HI_R2;
 
-static const uint8_t rt2560_chan_2ghz[] =
-   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 };
-
 static const uint8_t rt2560_chan_5ghz[] =
{ 36, 40, 44, 48, 52, 56, 60, 64,
  100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140,
@@ -2137,8 +2134,7 @@ rt2560_getradiocaps(struct ieee80211com *ic,
memset(bands, 0, sizeof(bands));
setbit(bands, IEEE80211_MODE_11B);
setbit(bands, IEEE80211_MODE_11G);
-   ieee80211_add_channel_list_2ghz(chans, maxchans, nchans,
-   rt2560_chan_2ghz, nitems(rt2560_chan_2ghz), bands, 0);
+   ieee80211_add_channels_default_2ghz(chans, maxchans, nchans, bands, 0);
 
if (sc->rf_rev == RT2560_RF_5222) {
setbit(bands, IEEE80211_MODE_11A);

Modified: head/sys/dev/ral/rt2661.c
==
--- head/sys/dev/ral/rt2661.c   Sat Jan 26 14:54:06 2019(r343473)
+++ head/sys/dev/ral/rt2661.c   Sat Jan 26 17:00:55 2019(r343474)
@@ -195,8 +195,6 @@ static const struct rfprog {
RT2661_RF5225_2
 };
 
-static const uint8_t rt2661_chan_2ghz[] =
-   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 };
 static const uint8_t rt2661_chan_5ghz[] =
{ 36, 40, 44, 48, 52, 56, 60, 64,
  100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140,
@@ -2757,8 +2755,7 @@ rt2661_getradiocaps(struct i

Re: svn commit: r343440 - head/bin/sh

[Ian Lepore]

On Sat, 2019-01-26 at 13:18 +, Edward Napierala wrote:
> On 0125T1647, Devin Teske wrote:
> > 
> > 
> > > On Jan 25, 2019, at 1:13 AM, Edward Napierala 
> > > wrote:
> > > 
> > > On 0125T1530, Devin Teske wrote:
> > > > 
> > > > 
> > > > > On Jan 25, 2019, at 12:28 AM, Edward Napierala <
> > > > > tr...@freebsd.org> wrote:
> > > > > 
> > > > > On 0125T1441, Devin Teske wrote:
> > > > > > 
> > > > > > 
> > > > > > > On Jan 25, 2019, at 1:37 PM, Edward Napierala <
> > > > > > > tr...@freebsd.org> wrote:
> > > > > > > 
> > > > > > > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > > > > > >  > > > > > > free...@pdx.rh.cn85.dnsmgr.net>> napisał(a):
> > > > > > > > 
> > > > > > > > > Author: trasz
> > > > > > > > > Date: Fri Jan 25 17:09:26 2019
> > > > > > > > > New Revision: 343440
> > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/343440
> > > > > > > > > 
> > > > > > > > > Log:
> > > > > > > > > Comment out the default sh(1) aliases for root,
> > > > > > > > > introduced in r343416.
> > > > > > > > > The rest of this stuff is still to be discussed, but
> > > > > > > > > I think at this
> > > > > > > > > point we have the agreement that the aliases should
> > > > > > > > > go.
> > > > > > > > > 
> > > > > > > > > MFC after:  2 weeks
> > > > > > > > > Sponsored by:   DARPA, AFRL
> > > > > > > > 
> > > > > > > > Please just revert this and the prior commit out, and
> > > > > > > > when
> > > > > > > > the path forward is clear commit it.  I would not want
> > > > > > > > any of this
> > > > > > > > merged to 12/ or 11/ until the time that it is all
> > > > > > > > settled.
> > > > > > > 
> > > > > > > Oops, my bad - neither this nor the previous commit is
> > > > > > > supposed
> > > > > > > to be MFC-ed; the "2 weeks" above comes from my default
> > > > > > > Subversion
> > > > > > > config.
> > > > > > > 
> > > > > > > Regarding the backoff - just a few hours ago you said you
> > > > > > > don't have
> > > > > > > any problem with this, except for aliases and the default
> > > > > > > ENV.  The
> > > > > > > aliases problem has been addressed, and you hadn't yet
> > > > > > > responded
> > > > > > > to my explanations regarding the ENV.  Another committer
> > > > > > > asked for
> > > > > > > backoff, because "sh is not an interactive shell", while
> > > > > > > in fact sh(1)
> > > > > > > is FreeBSD's default interactive shell except for
> > > > > > > root.  Finally, there's
> > > > > > > one person who asked for revert, but without giving any
> > > > > > > reasons
> > > > > > > whatsoever.
> > > > > > > 
> > > > > > > So far nobody had proposed any scenario where this would
> > > > > > > break
> > > > > > > anything, or even affect existing users.  It seems like a
> > > > > > > typical bikeshed
> > > > > > > situation.
> > > > > > 
> > > > > > It is not clear to me after reading r343416 and D18872 what
> > > > > > this change is trying to solve.
> > > > > 
> > > > > The idea is to make it easy to replace the default root shell
> > > > > - which
> > > > > many people consider broken, due to not supporting basic
> > > > > shell syntax - with
> > > > > something that actually works.
> > > > 
> > > > How exactly does changing PS1 or adding 6 aliases fix the
> > > > "basic shell syntax" which you claim to be unsupported?
> > > > 
> > > > If the number of aliases added to a shell are a measure of its
> > > > brokenness, then bash must be hella broken (I have 43 aliases
> > > > in my bash_profile).
> > > 
> > > The aliases are gone.
> > 
> > Fair enough, albeit the topic was r343416 and D18872.
> > 
> > 
> > >  Human-friendly PS1 is considered a standard feature
> > > nowadays.
> > 
> > I fail to see how ''$ " is unfriendly.
> 
> How many people you know use a plain '$' as a shell prompt,
> because they like it that way?
> 
> > In fact, I am a bit amiss how you don't see "\u@\h:\w \\$ " as
> > being unfriendly to TCL/Expect.
> > 
> > While it's certainly possible to use "expect -re" and formulate
> > around it, the change itself would break existing scripts.
> > 
> > 
> > 
> > >  But the way it fixes things is that it makes it easy to replace
> > > csh with a shell which actually groks shell syntax and is
> > > reasonably useful
> > > out of the box,
> > 
> > This sounds like you are claiming csh is broken.
> > 
> > I see where you may be coming from:
> > 
> > + /bin/sh supports a syntax
> > + bash supports nearly all of /bin/sh
> > + zsh supports nearly all of /bin/sh
> > 
> > So [t]csh must seem broken to you because it doesn't fall inline.
> > 
> > Being different doesn't mean you are broken. As I have stated
> > previously, I know lots of people that would and do set their login
> > shell to tcsh.
> > 
> > I personally have both a .tcshrc and a .bash_profile because I use
> > both. I would never consider csh broken because it doesn't "grok
> > shell syntax" -- it in-fact groks its own shell syntax just fine
> > and dandy.
> 
> I know people who use tcsh, too, but they are a minority of all

svn commit: r343473 - head/sys/geom/uzip

[Andriy Voskoboinyk]

Author: avos
Date: Sat Jan 26 14:54:06 2019
New Revision: 343473
URL: https://svnweb.freebsd.org/changeset/base/343473

Log:
  geom_uzip(4): move NULL pointer KASSERT check before it is dereferenced
  
  PR:   203499
  Submitted by: 
  MFC after:5 days

Modified:
  head/sys/geom/uzip/g_uzip.c

Modified: head/sys/geom/uzip/g_uzip.c
==
--- head/sys/geom/uzip/g_uzip.c Sat Jan 26 14:14:25 2019(r343472)
+++ head/sys/geom/uzip/g_uzip.c Sat Jan 26 14:54:06 2019(r343473)
@@ -889,13 +889,13 @@ g_uzip_destroy_geom(struct gctl_req *req, struct g_cla
g_trace(G_T_TOPOLOGY, "%s(%s, %s)", __func__, mp->name, gp->name);
g_topology_assert();
 
+   KASSERT(gp != NULL, ("NULL geom"));
if (gp->softc == NULL) {
DPRINTF(GUZ_DBG_ERR, ("%s(%s): gp->softc == NULL\n", __func__,
gp->name));
return (ENXIO);
}
 
-   KASSERT(gp != NULL, ("NULL geom"));
pp = LIST_FIRST(&gp->provider);
KASSERT(pp != NULL, ("NULL provider"));
if (pp->acr > 0 || pp->acw > 0 || pp->ace > 0)
___
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: r343440 - head/bin/sh

[Edward Napierala]

sob., 26 sty 2019 o 01:38 Rodney W. Grimes
 napisał(a):
>
> > On 0125T1705, Rodney W. Grimes wrote:
> > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala  
> > > > > wrote:
> > >
> > > Chop with the big axe most of this as I need to clarify a miss statement.
> > > ...
> > > > > The change we're discussing doesn't affect upgrades at all - it's only
> > > > > for new installs.
> > > >
> > > > mergemaster, iirc, will merge in changes to etc files after an upgrade.
> > > > So this would effect anybody that goes through an upgrade and performs 
> > > > mergemaster.
> > >
> > > Correct, and to my knowledge there is no way to stop that effect.
> >
> > Won't happen in this case, this doesn't apply to files in /etc
> > at all; it only applies to the default /root/.shrc and /root/.profile
> > that get installed on fresh systems.
>
> mergemaster is the wrong term here, freebsd-update is
> going to want to merge this change.

Are you sure freebsd-update also updates root's private configuration
files?  I've never used it, but this seems somewhat surprising.

> > > > >  And it doesn't affect root by default, you
> > > > > need to change their shell from csh(1) to sh(1).
> > > >
> > > > By your own commit messages admission, this is for the toor account, so 
> > > > it does affect a user (and as you were keen to point out, users with 
> > > > the default shell).
> > >
> > > Further it effects root any time root types "sh" or "/bin/sh"
> > > and intentially invokes sh interactive for some reason,
> > > something I do more often than I care to admit simply
> > > cause I know what I want to do is much easier in that
> > > shell.
> >
> > It doesn't.  For sh(1) to read ~/.shrc (/root/.shrc in this case)
> > you need to have ENV set; the default /root/.profile only sets
> > it when sh(1) is your login shell.
> I do not see any conditional logic in /root/.profile,
> what your mis stating is that /root/.profile is not
> run for a login shell, so ENV would not be set unless
> something else caused /root/.profile to be read, aka
> source ~/.profile

Correction: /root/.profile is not-run for non-login shell, so ENV
wouldn't be set.  Yeah, that's what I've meant.

> >   Which means, this doesn't
> > change the behaviour when you casually run "sh" or "/bin/sh"
> > as root; sh needs to be set up as login shell for this to take
> > effect.
>
> Again I do not see any conditional logic in /root/.profile
> that would make that true.  A su - toor would be effected.

As opposed to 'su - root' or plain '/bin/sh', right.
___
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: r343472 - head/share/man/man4

[Andriy Voskoboinyk]

Author: avos
Date: Sat Jan 26 14:14:25 2019
New Revision: 343472
URL: https://svnweb.freebsd.org/changeset/base/343472

Log:
  otus(4): fix a typo in man page (802.11 -> 802.11n)
  
  MFC after:3 days

Modified:
  head/share/man/man4/otus.4

Modified: head/share/man/man4/otus.4
==
--- head/share/man/man4/otus.4  Sat Jan 26 14:10:49 2019(r343471)
+++ head/share/man/man4/otus.4  Sat Jan 26 14:14:25 2019(r343472)
@@ -166,4 +166,4 @@ and ported by
 The
 .Nm
 driver only supports 802.11a/b/g operations.
-802.11 operation is not supported at this time.
+802.11n operation is not supported at this time.
___
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: r343471 - head/lib/libcasper/libcasper

[Mariusz Zaborski]

Author: oshogbo
Date: Sat Jan 26 14:10:49 2019
New Revision: 343471
URL: https://svnweb.freebsd.org/changeset/base/343471

Log:
  libcasper: do not run registered exit functions
  
  Casper library should not use exit(3) function because before setting it up
  applications may register it. Casper doesn't depend on any registered exit
  function, so it safe to change this.
  
  Reported by:  jceel
  MFC after:2 weeks

Modified:
  head/lib/libcasper/libcasper/libcasper_service.c
  head/lib/libcasper/libcasper/service.c
  head/lib/libcasper/libcasper/zygote.c

Modified: head/lib/libcasper/libcasper/libcasper_service.c
==
--- head/lib/libcasper/libcasper/libcasper_service.cSat Jan 26 13:53:00 
2019(r343470)
+++ head/lib/libcasper/libcasper/libcasper_service.cSat Jan 26 14:10:49 
2019(r343471)
@@ -148,20 +148,20 @@ service_execute(int chanfd)
 
nvl = nvlist_recv(chanfd, 0);
if (nvl == NULL)
-   exit(1);
+   _exit(1);
if (!nvlist_exists_string(nvl, "service"))
-   exit(1);
+   _exit(1);
servname = nvlist_get_string(nvl, "service");
casserv = service_find(servname);
if (casserv == NULL)
-   exit(1);
+   _exit(1);
service = casserv->cs_service;
procfd = nvlist_take_descriptor(nvl, "procfd");
nvlist_destroy(nvl);
 
service_start(service, chanfd, procfd);
/* Not reached. */
-   exit(1);
+   _exit(1);
 }
 
 static int
@@ -231,7 +231,7 @@ casper_main_loop(int fd)
int sock, maxfd, ret;
 
if (zygote_init() < 0)
-   exit(1);
+   _exit(1);
 
/*
 * Register core services.
@@ -256,7 +256,7 @@ casper_main_loop(int fd)
}
if (maxfd == -1) {
/* Nothing to do. */
-   exit(0);
+   _exit(0);
}
maxfd++;
 
@@ -267,7 +267,7 @@ casper_main_loop(int fd)
if (ret == -1) {
if (errno == EINTR)
continue;
-   exit(1);
+   _exit(1);
}
 
TAILQ_FOREACH(casserv, &casper_services, cs_next) {

Modified: head/lib/libcasper/libcasper/service.c
==
--- head/lib/libcasper/libcasper/service.c  Sat Jan 26 13:53:00 2019
(r343470)
+++ head/lib/libcasper/libcasper/service.c  Sat Jan 26 14:10:49 2019
(r343471)
@@ -427,7 +427,7 @@ service_start(struct service *service, int sock, int p
service_clean(sock, procfd, service->s_flags);
 
if (service_connection_add(service, sock, NULL) == NULL)
-   exit(1);
+   _exit(1);
 
for (;;) {
FD_ZERO(&fds);
@@ -443,7 +443,7 @@ service_start(struct service *service, int sock, int p
nfds = select(maxfd + 1, &fds, NULL, NULL, NULL);
if (nfds < 0) {
if (errno != EINTR)
-   exit(1);
+   _exit(1);
continue;
} else if (nfds == 0) {
/* Timeout. */
@@ -468,5 +468,5 @@ service_start(struct service *service, int sock, int p
}
}
 
-   exit(0);
+   _exit(0);
 }

Modified: head/lib/libcasper/libcasper/zygote.c
==
--- head/lib/libcasper/libcasper/zygote.c   Sat Jan 26 13:53:00 2019
(r343470)
+++ head/lib/libcasper/libcasper/zygote.c   Sat Jan 26 14:10:49 2019
(r343471)
@@ -122,7 +122,7 @@ zygote_main(int sock)
if (nvlin == NULL) {
if (errno == ENOTCONN) {
/* Casper exited. */
-   exit(0);
+   _exit(0);
}
continue;
}
@@ -134,7 +134,7 @@ zygote_main(int sock)
func = service_execute;
break;
default:
-   exit(0);
+   _exit(0);
}
 
/*
@@ -161,7 +161,7 @@ zygote_main(int sock)
close(chanfd[0]);
func(chanfd[1]);
/* NOTREACHED */
-   exit(1);
+   _exit(1);
default:
/* Parent. */
close(chanfd[1]);
___
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

svn commit: r343470 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Mariusz Zaborski]

Author: oshogbo
Date: Sat Jan 26 13:53:00 2019
New Revision: 343470
URL: https://svnweb.freebsd.org/changeset/base/343470

Log:
  zfs: allow to change cache flush sysctl
  
  There is no reason for this variable to be tunable.
  This variable is used as a barrier in few places.
  
  Discussed with:   pjd
  MFC after:2 weeks
  Sponsored by: Fudo Security

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c   Sat Jan 26 
13:36:06 2019(r343469)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c   Sat Jan 26 
13:53:00 2019(r343470)
@@ -103,7 +103,7 @@ SYSCTL_INT(_vfs_zfs, OID_AUTO, zil_replay_disable, CTL
  * out-of-order write cache is enabled.
  */
 boolean_t zfs_nocacheflush = B_FALSE;
-SYSCTL_INT(_vfs_zfs, OID_AUTO, cache_flush_disable, CTLFLAG_RDTUN,
+SYSCTL_INT(_vfs_zfs, OID_AUTO, cache_flush_disable, CTLFLAG_RWTUN,
 &zfs_nocacheflush, 0, "Disable cache flush");
 boolean_t zfs_trim_enabled = B_TRUE;
 SYSCTL_DECL(_vfs_zfs_trim);
___
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: r343440 - head/bin/sh

[Edward Napierala]

On 0125T1647, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 1:13 AM, Edward Napierala  wrote:
> > 
> > On 0125T1530, Devin Teske wrote:
> >> 
> >> 
> >>> On Jan 25, 2019, at 12:28 AM, Edward Napierala  wrote:
> >>> 
> >>> On 0125T1441, Devin Teske wrote:
>  
>  
> > On Jan 25, 2019, at 1:37 PM, Edward Napierala  wrote:
> > 
> > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> >  > > napisał(a):
> >> 
> >>> Author: trasz
> >>> Date: Fri Jan 25 17:09:26 2019
> >>> New Revision: 343440
> >>> URL: https://svnweb.freebsd.org/changeset/base/343440
> >>> 
> >>> Log:
> >>> Comment out the default sh(1) aliases for root, introduced in r343416.
> >>> The rest of this stuff is still to be discussed, but I think at this
> >>> point we have the agreement that the aliases should go.
> >>> 
> >>> MFC after:  2 weeks
> >>> Sponsored by:   DARPA, AFRL
> >> 
> >> Please just revert this and the prior commit out, and when
> >> the path forward is clear commit it.  I would not want any of this
> >> merged to 12/ or 11/ until the time that it is all settled.
> > 
> > Oops, my bad - neither this nor the previous commit is supposed
> > to be MFC-ed; the "2 weeks" above comes from my default Subversion
> > config.
> > 
> > Regarding the backoff - just a few hours ago you said you don't have
> > any problem with this, except for aliases and the default ENV.  The
> > aliases problem has been addressed, and you hadn't yet responded
> > to my explanations regarding the ENV.  Another committer asked for
> > backoff, because "sh is not an interactive shell", while in fact sh(1)
> > is FreeBSD's default interactive shell except for root.  Finally, 
> > there's
> > one person who asked for revert, but without giving any reasons
> > whatsoever.
> > 
> > So far nobody had proposed any scenario where this would break
> > anything, or even affect existing users.  It seems like a typical 
> > bikeshed
> > situation.
>  
>  It is not clear to me after reading r343416 and D18872 what this change 
>  is trying to solve.
> >>> 
> >>> The idea is to make it easy to replace the default root shell - which
> >>> many people consider broken, due to not supporting basic shell syntax - 
> >>> with
> >>> something that actually works.
> >> 
> >> How exactly does changing PS1 or adding 6 aliases fix the "basic shell 
> >> syntax" which you claim to be unsupported?
> >> 
> >> If the number of aliases added to a shell are a measure of its brokenness, 
> >> then bash must be hella broken (I have 43 aliases in my bash_profile).
> > 
> > The aliases are gone.
> 
> Fair enough, albeit the topic was r343416 and D18872.
> 
> 
> >  Human-friendly PS1 is considered a standard feature
> > nowadays.
> 
> I fail to see how ''$ " is unfriendly.

How many people you know use a plain '$' as a shell prompt,
because they like it that way?

> In fact, I am a bit amiss how you don't see "\u@\h:\w \\$ " as being 
> unfriendly to TCL/Expect.
> 
> While it's certainly possible to use "expect -re" and formulate around it, 
> the change itself would break existing scripts.
> 
> 
> 
> >  But the way it fixes things is that it makes it easy to replace
> > csh with a shell which actually groks shell syntax and is reasonably useful
> > out of the box,
> 
> This sounds like you are claiming csh is broken.
> 
> I see where you may be coming from:
> 
> + /bin/sh supports a syntax
> + bash supports nearly all of /bin/sh
> + zsh supports nearly all of /bin/sh
> 
> So [t]csh must seem broken to you because it doesn't fall inline.
> 
> Being different doesn't mean you are broken. As I have stated previously, I 
> know lots of people that would and do set their login shell to tcsh.
> 
> I personally have both a .tcshrc and a .bash_profile because I use both. I 
> would never consider csh broken because it doesn't "grok shell syntax" -- it 
> in-fact groks its own shell syntax just fine and dandy.

I know people who use tcsh, too, but they are a minority of all users.
However, this change doesn't do anything for them.

> > with ~/.shrc you can customize etc.
> 
> As can ~/.profile

But ~/.profile won't work for aliases or the prompt; it's only run
for login shells.  And our sh(1) doesn't source ~/.shrc by itself,
which is confusing to people coming from other systems.

> >  Think of it as a POLA,
> > but horizontally, for folks coming from other systems, instead of the usual
> > one.
> 
> POLA can affect multiple people at the same time.
> 
> Someone may be astonished that something is different when coming from anther 
> community, but what if addressing this difference causes a POLA violation for 
> long-standing users.

That's true, but I don't think this change would violate POLA for the them.
If they don't use sh, they are not affected.  If they do, they already have