Re: svn commit: r362261 - head/contrib/file/magic/Magdir

[Xin Li via svn-src-all]

Hi,

On 6/17/20 3:11 AM, Antoine Brodin wrote:
> Author: antoine
> Date: Wed Jun 17 10:11:54 2020
> New Revision: 362261
> URL: https://svnweb.freebsd.org/changeset/base/362261
> 
> Log:
>   Re-apply r333944 to unbreak ports

Could you please file a bug against the upstream (Christos cc'ed), as it
may also affect other users?

> Modified:
>   head/contrib/file/magic/Magdir/elf
> 
> Modified: head/contrib/file/magic/Magdir/elf
> ==
> --- head/contrib/file/magic/Magdir/elfWed Jun 17 08:35:35 2020
> (r362260)
> +++ head/contrib/file/magic/Magdir/elfWed Jun 17 10:11:54 2020
> (r362261)
> @@ -50,9 +50,8 @@
>  !:mime   application/x-object
>  >16  leshort 2   executable,
>  !:mime   application/x-executable
> ->16  leshort 3   ${x?pie executable:shared object},
> -
> -!:mime   application/x-${x?pie-executable:sharedlib}
> +>16  leshort 3   shared object,
> +!:mime   application/x-sharedlib
>  >16  leshort 4   core file,
>  !:mime   application/x-coredump
>  # OS-specific
> 



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r366781 - in head: include lib/libc/stdlib

[Xin Li via svn-src-all]

Hi,

Thanks very much for the feedback.  I have created a new change for
review at https://reviews.freebsd.org/D26845 , could you please take a
look and let me know if it's satisfactory?

On 10/16/20 11:53 PM, Konstantin Belousov wrote:
[...]>> +int ptsname_r(int, char *, size_t);
> This declaration appears in the __XSI_VISIBLE block, but I do not see the
> function description in the IEEE Std 1003.1™-2017 text (base issue 7).
> 
> Review mentioned that the function is scheduled for issue 8, but shouldn't
> it put under BSD_VISIBLE until specification is finalized ?

Good point, fixed in the proposed change.

[...]
>> Modified: head/lib/libc/stdlib/Symbol.map
>> ==
>> --- head/lib/libc/stdlib/Symbol.map  Sat Oct 17 01:06:04 2020
>> (r366780)
>> +++ head/lib/libc/stdlib/Symbol.map  Sat Oct 17 04:14:38 2020
>> (r366781)
>> @@ -125,6 +125,7 @@ FBSD_1.6 {
>>  qsort_s;
>>  rand;
>>  srand;
>> +ptsname_r;
> This is unsorted now.

Fixed in the proposed change.

[...]
>> +{
>> +static char pt_slave[sizeof _PATH_DEV + SPECNAMELEN];
> We usually write sizeof(_PATH_DEV).

This was from previous code so I leave it as-is, but fixed in the
proposed change.

>> +
>> +if (ptsname_r(fildes, pt_slave, sizeof(pt_slave)) == 0)
> Since ptsname_r is non-standard and exported, userspace is allowed to
> interpose the symbol, which would break ptsname().

Thanks for pointing it out -- I should have paid more attention here.
Fixed in the proposed change.

>> +return (pt_slave);
>> +else
> 'else' is redundand.

Removed else and used a straight return instead.

Cheers,
___
svn-src-all@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"

Re: svn commit: r362936 - head/sbin/newfs_msdos

[Xin Li via svn-src-all]

On 7/4/20 12:01 PM, Conrad Meyer wrote:
> Hi Xin Li,
> 
> Maybe we can use C11 static_assert instead of the CTASSERT array mechanism?

Good point, maybe https://reviews.freebsd.org/D25562 ?



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

[Xin Li via svn-src-all]

(chosen a random message)

On 2019-11-03 15:30, Ravi Pokala wrote:
> Uh
> 
> I've had a log device in my boot-pool for months, and have booted without 
> issue:
> 
> [threepio:~] rpokala% zpool status zroot
>   pool: zroot
>  state: ONLINE
>   scan: scrub repaired 0 in 0 days 00:04:36 with 0 errors on Mon Oct 28 
> 03:10:59 2019
> config:
> 
> NAMESTATE READ WRITE CKSUM
> zroot   ONLINE   0 0 0
>   nvd1p4ONLINE   0 0 0
> logs
>   nvd0p1ONLINE   0 0 0
> 
> errors: No known data errors


This is not supported, and it's not trivial to support it, because in
order to support it, the bootloader would have to know how to replay
zilogs, which would add quite a lot of code to it.

It's unlikely that you actually hit a problem, however, because the
critical contents to boot the system is rarely written to, and as a
result it's quite likely that the readable, consistent state of your
/boot/ is good enough to boot the system.  That's said, it's still
because you were lucky, and the code was not designed to work that way...

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

[Xin Li via svn-src-all]

On 2019-11-03 13:32, Toomas Soome wrote:
> 
> 
>> On 3. Nov 2019, at 22:39, Kevin Bowling  wrote:
>>
>> I believe this is/was a common configuration, at least the few
>> spinning disk based systems I have left have a slog.
>>
> 
> On boot pool? um. well, I’ll kick out that return then.

I think it's fine to simply ignore the log in loader, because it's a
read-only consumer.

The full-featured kernel ZFS code would skip replaying the log when
importing read-only, in that case we might see some outdated data, but
it's still guaranteed to be consistent by ZFS.

Cheers,

> 
> rgds,
> toomas
> 
>> On Sun, Nov 3, 2019 at 10:55 AM Andriy Gapon  wrote:
>>>
>>> On 03/11/2019 15:25, Toomas Soome wrote:
 Author: tsoome
 Date: Sun Nov  3 13:25:47 2019
 New Revision: 354283
 URL: https://svnweb.freebsd.org/changeset/base/354283

 Log:
  loader: we do not support booting from pool with log device

  If pool has log device, stop there and tell about it.
>>>
>>> Why?
>>>
 Modified:
  head/stand/libsa/zfs/zfs.c
  head/stand/libsa/zfs/zfsimpl.c
  head/sys/cddl/boot/zfs/zfsimpl.h
>>>
>>>
>>>
>>> --
>>> Andriy Gapon
>>> ___
>>> svn-src-h...@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"
> 



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c

[Xin Li via svn-src-all]

On 3/27/20 11:25 AM, John Baldwin wrote:
[...]>   - Drivers no longer register a list of supported algorithms.  This
> doesn't quite work when you factor in modes (e.g. a driver might
> support both AES-CBC and SHA2-256-HMAC separately but not combined
> for ETA).  Instead, a new 'crypto_probesession' method has been
> added to the kobj interface for symmteric crypto drivers.  This
> method returns a negative value on success (similar to how
> device_probe works) and the crypto framework uses this value to pick
> the "best" driver.  There are three constants for hardware
> (e.g. ccr), accelerated software (e.g. aesni), and plain software
> (cryptosoft) that give preference in that order.  One effect of this
> is that if you request only hardware when creating a new session,
> you will no longer get a session using accelerated software.
> Another effect is that the default setting to disallow software
> crypto via /dev/crypto now disables accelerated software.

For user-visible interface, it seems like we are essentially treating
"accelerated software" like AES-NI the same way of plain software.  For
example, geom_eli would now say:

GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI: Crypto: software

Instead of:

GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI: Crypto: hardware

When AES-NI is used (which is because we only have two bits to represent
hardware and software, and have gave neither bits clear with its own
meaning (use specific driver)).

If we are not going to add a new bit to represent accelerated software,
why are they categorized as software providers?  Technically, all these
still requires hardware that implements the cryptographic primitives to
work, and it's much easier for system administrators if we expose the
fact that they are using some kind of acceleration than asking them to
run DTrace etc. to find out.  Personally, I think it's probably better
to change the notion to either "accelerated" (by either hardware or
software) and "software"...

Cheers,
___
svn-src-all@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"

Re: svn commit: r359945 - in head: lib/geom/eli sys/geom/eli

[Xin Li via svn-src-all]

On 4/14/20 17:22, Alan Somers wrote:
> On Tue, Apr 14, 2020 at 6:15 PM John Baldwin  > wrote:
> 
> Author: jhb
> Date: Wed Apr 15 00:14:50 2020
> New Revision: 359945
> URL: https://svnweb.freebsd.org/changeset/base/359945
> 
> Log:
>   Remove support for geli(4) algorithms deprecated in r348206.
[snip]
> Why remove read-only support?  That will make it much harder to convert
> old volumes.

Because they uses 64-bit block size and is vulnerable to birthday
attacks.  We have officially communicated that these algorithms would be
gone in 13 last year, with gone_in messages in place, so I think it's
fine to remove them as we are not going to keep the code forever.

Cheers,

___
svn-src-all@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"

Re: svn commit: r355759 - in head: include sys/sys

[Xin Li via svn-src-all]

On 2019-12-14 13:52, Conrad Meyer wrote:
> Author: cem
> Date: Sat Dec 14 21:52:49 2019
> New Revision: 355759
> URL: https://svnweb.freebsd.org/changeset/base/355759
> 
> Log:
>   cdefs: Add __deprecated(message) function attribute macro

This conflicts with Linux kernel and breaks DRM.  Please use a different
name.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r358153 - head/usr.sbin/services_mkdb

[Xin Li via svn-src-all]

On 2/19/20 10:01 PM, Yuri Pankov wrote:
> On 20 Feb 2020, at 06:54, Pedro F. Giffuni  wrote:
>>
>> Author: pfg
>> Date: Thu Feb 20 03:54:07 2020
>> New Revision: 358153
>> URL: https://svnweb.freebsd.org/changeset/base/358153
>>
>> Log:
>>  /etc/services: attempt bring the database to this century.
>>
>>  Document better this file, updating the URL to the IANA registry and closely
>>  match the official services.
>>
>>  For system ports (0 to 1023) we now try to follow the registry closely, 
>> noting
>>  some historical differences where applicable.
>>  For the User ports (1024 - 49151) we try to keep some sensible balance only
>>  of services that are likely to be found on FreeBSD/UNIX systems. This 
>> attempts
>>  to strike a balance between complexity and usefulness.
>>
>>  As a side effect: drop references to unofficial Kerberos IV which was EOL'ed
>>  on Oct 2006[1]. While it is conceivable some people may still use it in some
>>  very old FreeBSD machines that can't be replaced easily, the use of it is
>>  considered a security risk. Also drop the unofficial netatalk, which we
>>  supported long ago in the kernel but was dropped long ago.
>>
>>  [1] https://web.mit.edu/kerberos/krb4-end-of-life.html
>>
>>  MFC after:  3 weeks (likely to 12-stable only)
>>  Differential Revision:  https://reviews.freebsd.org/D23621
>>
>> Modified:
>>  head/usr.sbin/services_mkdb/services
> 
> I noticed `mergemaster` failing, and it seems to be not happy with this 
> change:
> 
> # make installconfig
> installing DIRS CONFSDIR
> install  -d -m 0755 -o root  -g wheel  /etc
> install  -C -o root  -g wheel -m 644  
> /usr/src/usr.sbin/services_mkdb/services /etc/services
> services_mkdb -l -q -o /var/db/services.db  /etc/services
> services_mkdb: Ran out of protocols adding `divert'; recompile with larger 
> PROTOMAX
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/usr.sbin/services_mkdb

Fixed in r358154.  Please merge the revision with r358153 when MFC'ing.



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r365619 - in stable/12/sys: conf sys

[Xin Li via svn-src-all]

On 1/14/21 06:17, Kyle Evans wrote:
> On Thu, Sep 10, 2020 at 7:04 PM Glen Barber  wrote:
>>
>> Author: gjb
>> Date: Fri Sep 11 00:04:23 2020
>> New Revision: 365619
>> URL: https://svnweb.freebsd.org/changeset/base/365619
>>
>> Log:
>>   Rename stable/12 to -STABLE, and bump __FreeBSD_version after
>>   releng/12.2 had been created.
>>
> 
> I had wondered this before, and now I wonder again after a recent
> pkgbase discussion about versioning schemes. Why do we rename stable
> to -PRERELEASE at all? It's decidedly a (minor) downgrade to try to go
> from -PRERELEASE to -RELEASE since anyone that manages to get a
> -PRERELEASE build is still along -STABLE.

-PRERELEASE indicates that the stable branch is currently in code freeze
in preparation of a release.  The expectation here is that whatever you
are seeing in the build would end up in an upcoming release (X.Y),
unless they were reverted (for -STABLE, they would go to the next
release, or X.Y+1, or never, if X.Y is the last release).

I believe traditionally we also bump __FreeBSD_version when -STABLE
become -PRERELEASE, which typically happens when we enter a code freeze,
but more recent -STABLE branches seems to have moved to doing
__FreeBSD_version bumps at the time of -BETA, but technically I think we
do want to bump __FreeBSD_version as early as we promoted -STABLE to
-PRERELEASE to match the hardcoded version number...

Cheers,



OpenPGP_signature
Description: OpenPGP digital signature