Re: noatime on ufs2

[Xin LI]

On Tue, Jan 9, 2024 at 2:47 AM void  wrote:

> I was concerned that email might not work right without atime.
> So far, it seems to be working OK.
>

Depending on how you define "correct".  Deliveries won't be affected by
atime setting in any way; telling if you have new mail _may_ be affected,
but it would be at worst annoying (shell / MUA claims you have new mail
while you don't, and even that it's only for their startup, once the shell
is running it won't rely on atime).

Cheers,

Re: noatime on ufs2

[Xin LI]

On Sun, Jan 7, 2024 at 5:27 AM void  wrote:

> Hi,
>
> Does /var/mail still need atime?
>
> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
> rpi4/8BG which installs into one / . If it's mounted with noatime,
> will it have consequences for /var/mail ?


It doesn't matter if you don't normally receive emails locally (nowadays,
it's rare).

If you do receive emails locally, it depends on what application(s) that
you are using.  Most applications nowadays check both mtime and atime plus
sizes of the mailbox file and do not rely on atime (because they saved the
previous mtime).  Without atime updates, some application may claim that
you have new mail when the mailbox is not empty when they first start.

That's said, if I were you and I'm using some flash based storage (with rpi
it's highly likely) regardless if I'm using mail locally; most of the time
the data is not really useful for anything, and it does increase the wear
of your storage.

This reminds me that -- we probably should have implemented the Linux
"relative atime" (update atime iff (atime <= mtime || atime <= ctime) ||
atime is older than a day) and "no diratime" (don't update directory atime)
for UFS and make the "relatime" option the default; I had an
incomplete implementation about a decade ago somewhere but with the recent
VFS changes it's probably easier to start over.  IMHO, updating atime every
time when a file is accessed is not really providing useful data (like who
accessed the file, etc.) for audit purposes and does come with performance
(more write I/O) and reliability (wear of SSD and other flash devices)
cost, therefore not generally useful in modern days.  The Linux relative
atime is a pretty clever idea that has covered the most useful use case for
atime (Did I accessed the file after it was last modified) and also
provided a coarse-grained update (capped to daily, which is a reasonable
compromise) to the atime.

Cheers,

Re: Move u2f-devd into base?

[Xin LI]

On Mon, Jan 8, 2024 at 10:37 AM Warner Losh  wrote:

>
>
> On Mon, Jan 8, 2024 at 9:35 AM Kyle Evans  wrote:
>
>> On 1/8/24 10:30, Tomoaki AOKI wrote:
>> > On Mon, 8 Jan 2024 08:18:38 -0700
>> > Warner Losh  wrote:
>> >
>> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber 
>> >> wrote:
>> >>
>> >>> We have FIDO/U2F support for SSH in base.
>> >>>
>> >>> We also have a group "u2f", 116, in the default /etc/group file.
>> >>>
>> >>> Why do we keep the devd configuration (to chgrp the device nodes)
>> >>> in a port, security/u2f-devd?  Can't we just add this to base, too?
>> >>> It's just another devd configuration file.
>> >>>
>> >>
>> >> This properly belongs to devfs.conf no? Otherwise it's a race..
>> >>
>> >> Warner
>> >>
>> >> --
>> >>> Christian "naddy" Weisgerber
>> na...@mips.inka.de
>> >
>> > It's devd.conf materials. It actually is security/usf-devd/files
>> > u2f.conf and its contents is sets of notify 100 { match "vendor" ...
>> > match "product" ... action "chgrpy u2f ..." };.
>> > Some hase more items in it, though.
>> >
>> > So it should be in ports to adapt for latest products more quickly than
>> > in base, I think.
>> >
>>
>> I don't see any obvious reason that we can't compromise and have a
>> baseline of products in base and just use the port for new products not
>> yet known to base.  These vendors presumably aren't going to quickly
>> repurpose some PID for a non-u2f thing, much less in a way that we care
>> about.
>>
>
> Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What are
> we missing from that to make this doable generically? If we want it safe,
> we
> may need some additional work around the whole ugen thing it uses.
>

I think it's probably because of the lack of device ID matching capability
in devfs.conf (or in other words, there may be _some_ reason that I am not
aware of, to not expose all USB HID devices to desktop users; devd.conf
gives us the ability to selectively expose them based on what they claim
themselves to be, while with devfs.conf we can only say "expose HID
devices" vs "expose these allowlisted devices").

Cheers,

Re: Move u2f-devd into base?

[Xin LI]

On Mon, Jan 8, 2024 at 7:19 AM Warner Losh  wrote:

>
>
> On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber 
> wrote:
>
>> We have FIDO/U2F support for SSH in base.
>>
>> We also have a group "u2f", 116, in the default /etc/group file.
>>
>> Why do we keep the devd configuration (to chgrp the device nodes)
>> in a port, security/u2f-devd?  Can't we just add this to base, too?
>> It's just another devd configuration file.
>>
>
> This properly belongs to devfs.conf no? Otherwise it's a race...
>

That's a good point.  But I think in practice the race (if I'm
understanding correctly, there would be a window where the device node
showed up, but with the standard permissions until devd kicks in and runs
"action" steps to change it) would probably not matter because the
consumers (Chromium?) would be polling for the device and when opening
failed, they would retry, as the security key is not guaranteed to be
present when a website asks for it, and it's perfectly natural for the
browser to see the security key getting attached and detached while it is
running.

I would say it's a good idea to have something there in place to support
these security keys (possibly also cameras, etc.), especially considering
the base OpenSSH now supports U2F devices.  It's probably a good idea to
have adduser / installer to have a defined "interactive local user" groups
(u2f, video, etc. come to mind) that users are added into by default to
provide a reasonable out-of-box default too.

Cheers,

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 14:17, Mike Karels wrote:

On 23 Dec 2023, at 15:23, Craig Leres wrote:


On 12/23/23 06:52, Konstantin Belousov wrote:

This is strange change at best.  I have no opinion about the disabling
of compression of the rotated logs by default, but we already have knobs
to do that.  Adding a knob that disables (or enables) other knobs to work
is weird.


I totally agree. This moves the compression knob from the config file to the 
command line. And what if the user wants some but not all files to be 
compressed? Or wants to use different compression with different log files?


Another possibility would be to introduce some simple form of variables in
newsyslog.conf, replacing J by a variable reference, with the variable
being set near the beginning.  E.g.

V=zstd (or just V= for none?)
... $V
... $V

Then there would be one global change, and much easier changing of the
default.

It would also be possible to add  /etc/newsyslog.local.conf at the
beginning, and set variables there, making changes to the default file less
painful in the future.


I've implemented support of  in 
https://reviews.freebsd.org/D43174 .  Let's don't add macro or variables 
to newsyslog.conf as it would be a nightmare for compatibility with 
other newsyslog variants of other BSDs.


Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-24 10:03, Rodney W. Grimes wrote:

On 2023-12-23 06:52, Konstantin Belousov wrote:

On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:

Hi,

Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169

Historically, newsyslog has compressed rotated log files to save disk space.
This approach was valuable in the early days where storage space was
limited.  However, the landscape has changed significantly.  Modern file
systems, such as ZFS, now offer native compression capabilities.
Additionally, the widespread availability of larger hard drives has
diminished the necessity for additional compression.  Notably, the need to
decompress log files for pattern searches poses a significant inconvenience,
further questioning the utility of this legacy feature.

In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is
eligible for compression rather than directly enforcing it. It allows for a
more flexible approach, wherein the actual compression method can be set to
"none" or specified as one among bzip2, gzip, xz, or zstd.

Therefore I would propose that we change the default compression setting to
"none" in FreeBSD 15.0.  This change reflects our adaptation to the evolving
technological environment and user needs.  It also aligns with the broader
initiative to modernize our systems while maintaining flexibility and
efficiency.

I look forward to your thoughts and feedback on this proposal.


This is strange change at best.  I have no opinion about the disabling
of compression of the rotated logs by default, but we already have knobs
to do that.  Adding a knob that disables (or enables) other knobs to work
is weird.


And counter intuitive!


If you want to change the compression, update the default configuration file.


The primary issue with simply updating the default configuration file is
the increased workload it imposes during system upgrades. Since the
compression method flag is a part of newsyslog.conf, standard conflict
resolution tools like diff3 struggle to automatically resolve changes
involving these flags without manual intervention. This situation
necessitates that users manually reconcile their configuration with
every update to newsyslog.conf, even for minor alterations like
switching the default compression method.

Therefore, the proposal isn't about adding another knob within
newsyslog.conf. Rather, it's about introducing a command-line option for
newsyslog (to be used in /etc/crontab) that specifies the preferred
compression method, or the choice not to compress at all. This approach
is more self-contained compared to modifying each line in
newsyslog.conf. It offers a simpler, more straightforward solution for
administrators to manage their compression settings, reducing the
administrative burden during upgrades.


So now I edit /etc/crontab to change the behavior of newsyslog?
Thats VERY counter to how things "should be."  I am sorry, but
this change is just yet another "Oh my god, the defaults dont
work for me so I am gona force my idea of what the defaults should
be on everone else."

And you just pushed the merge conflict to another file, one that
is not even related to newsyslog, you do get your arguement doesnt
hold water?  A change in /etc/newsyslog.conf or /etc/crontab BOTH
lead to the fact people are going to have to merge things.

Now we are goning go crazy trying to figure out why my logs are
not compressed and finally gona end up finding this flag in
/etc/crontab that is causing newsyslog to ignore what I put
in its proper config file???  Again, very counter intuitive.


Thank you for your feedback.

In response to the concerns you've raised, I've initiated a new change, 
which you can review at https://reviews.freebsd.org/D43174 . This 
introduces a new configuration file option, "", in the 
newsyslog.conf filem, intended for use at the beginning of the file, and 
updated https://reviews.freebsd.org/D43169 with the default change done 
in the configuration file.


This change aims to provide a more intuitive way to manage compression 
settings directly within the newsyslog configuration, hopefully 
addressing the issues you highlighted.


Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 07:09, Enji Cooper wrote:

This impacts embedded systems or jails which use UFS as the default
/var/log backed device. There are quite a few larger consumers of
FreeBSD out there that still use UFS instead of ZFS.


I appreciate your feedback!

Thank you for pointing out the implications of this change for embedded 
systems and jails using UFS. I understand your concerns, especially 
regarding larger FreeBSD consumers who might still rely on UFS instead 
of ZFS.


Note that the committed change was designed to simplify code 
maintenance, particularly for downstream software vendors.  By reducing 
the number of configuration lines in newsyslog.conf to a single line in 
/etc/crontab, it makes it easier for downstream maintainers to follow 
the latest FreeBSD codebase, because they don't have to manually solve 
merge conflicts when someone changes newsyslog.conf anymore.  This 
should ease the integration and maintenance processes for these vendors.



Adding this instead into bsdinstall and the documentation as a suggested
  knob seems like a good way to go.

Just something to keep in mind when making this change.


Now back to the proposed behavior change, regarding your suggestion to 
change the default in the installer, I have reservations about this 
approach. One of my primary motivations for this change is to move away 
from using flags to specify which compression method should be used.  In 
my view, the software package distributed configuration should not 
dictate the compression method to be used by the user. Rather, its role 
should be to inform newsyslog about the suitability of a file for 
compression. This shift in approach aims to provide users with greater 
flexibility and autonomy in managing their compression settings.


Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 10:17, Ceri Davies wrote:

I really don’t like the idea of adding flags that make the program ignore a 
config file.  I also think this is premature until ZFS installs are default on 
all architectures.

However, if you must (and I see you have) change this, please don’t call the 
option “legacy” as we wish to deprecate other behaviour in the future or add 
additional compression algorithms.
Perhaps it could be called “useconfig” or something that describes what it 
actually does.

Also, could you please update the manage commit to note the change in 15.0 
because not everyone reads commit logs and we may end up violating the PoLA 
twice otherwise.


Thank you for sharing your thoughts on the commit. I want to clarify 
that my recent change does not alter the existing behavior of the code. 
In fact, the current legacy test cases still pass successfully. The 
modification I introduced primarily adds the option to override the 
default compression setting.


Regarding your suggestion to rename the “legacy” option, the term was 
chosen to reflect its purpose – to preserve historical behavior while 
acknowledging that it may be phased out in the future. Adding new 
letters to the configuration format isn't scalable and lacks 
flexibility. Especially, consider an application that install their own 
newsyslog.conf.d configuration, in which case the configuration is 
overwritten during upgrades, or has to have some way to solve merge 
conflicts, should they decide to add new log files, etc.  There's no 
practical reason for users to adhere to a specific compression method 
that the application writer told them, because the administrator have 
better idea about what compressor is more suitable for their situation.


I'll add a note to the release notes later, but rest assured that there 
is no PoLA violation yet.


Cheers,




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 13:08, Steve Kargl wrote:

On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote:


I appreciate your perspective on this issue. However, I believe there are
additional benefits to modifying the newsyslog code (which is already done
in commit 906748d208d3, by the way) beyond what can be achieved by simply
adjusting the defaults in newsyslog.conf.


Why ask for others opinions if you're simply going to commit
the change?  It seems the commit (23 Dec 2023 06:53:06 UTC)
occurred before the initial post in the discussion here
(23 Dec 2023 07:18:23 UTC).


This commit only added the option and does not change the existing code 
behavior.


Cheers,



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 06:52, Konstantin Belousov wrote:

On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:

Hi,

Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169

Historically, newsyslog has compressed rotated log files to save disk space.
This approach was valuable in the early days where storage space was
limited.  However, the landscape has changed significantly.  Modern file
systems, such as ZFS, now offer native compression capabilities.
Additionally, the widespread availability of larger hard drives has
diminished the necessity for additional compression.  Notably, the need to
decompress log files for pattern searches poses a significant inconvenience,
further questioning the utility of this legacy feature.

In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is
eligible for compression rather than directly enforcing it. It allows for a
more flexible approach, wherein the actual compression method can be set to
"none" or specified as one among bzip2, gzip, xz, or zstd.

Therefore I would propose that we change the default compression setting to
"none" in FreeBSD 15.0.  This change reflects our adaptation to the evolving
technological environment and user needs.  It also aligns with the broader
initiative to modernize our systems while maintaining flexibility and
efficiency.

I look forward to your thoughts and feedback on this proposal.


This is strange change at best.  I have no opinion about the disabling
of compression of the rotated logs by default, but we already have knobs
to do that.  Adding a knob that disables (or enables) other knobs to work
is weird.

If you want to change the compression, update the default configuration file.


The primary issue with simply updating the default configuration file is 
the increased workload it imposes during system upgrades. Since the 
compression method flag is a part of newsyslog.conf, standard conflict 
resolution tools like diff3 struggle to automatically resolve changes 
involving these flags without manual intervention. This situation 
necessitates that users manually reconcile their configuration with 
every update to newsyslog.conf, even for minor alterations like 
switching the default compression method.


Therefore, the proposal isn't about adding another knob within 
newsyslog.conf. Rather, it's about introducing a command-line option for 
newsyslog (to be used in /etc/crontab) that specifies the preferred 
compression method, or the choice not to compress at all. This approach 
is more self-contained compared to modifying each line in 
newsyslog.conf. It offers a simpler, more straightforward solution for 
administrators to manage their compression settings, reducing the 
administrative burden during upgrades.


I hope this clarifies the rationale behind the proposed changes and 
their potential benefits.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: Disable compression of newsyslog by default

[Xin Li]

On 2023-12-23 00:51, Miroslav Lachman wrote:

On 23/12/2023 08:18, Xin Li wrote:

Hi,

Inspired by D42961, I propose that we move forward with disabling the 
compression by default in newsyslog, as implemented in 
https://reviews.freebsd.org/D43169


Historically, newsyslog has compressed rotated log files to save disk 
space. This approach was valuable in the early days where storage 
space was limited.  However, the landscape has changed significantly.  
Modern file systems, such as ZFS, now offer native compression 
capabilities. Additionally, the widespread availability of larger hard 
drives has diminished the necessity for additional compression.  
Notably, the need to decompress log files for pattern searches poses a 
significant inconvenience, further questioning the utility of this 
legacy feature.


In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log 
file is eligible for compression rather than directly enforcing it. It 
allows for a more flexible approach, wherein the actual compression 
method can be set to "none" or specified as one among bzip2, gzip, xz, 
or zstd.


Therefore I would propose that we change the default compression 
setting to "none" in FreeBSD 15.0.  This change reflects our 
adaptation to the evolving technological environment and user needs.  
It also aligns with the broader initiative to modernize our systems 
while maintaining flexibility and efficiency.


I look forward to your thoughts and feedback on this proposal.


I don't think anything needs to be changed on newsyslog. Those who want 
to disable compression can do so in the "default" newsyslog.conf file. 
Why force this change in the newsyslog code?
I also don't think that the log file should not be compressed even on a 
compressed filesystem. Compressed log files can be handled by tools like 
zcat, zless, zgrep, etc. without first decompressing the log file. Text 
log files can still grow to large sizes, and if you have a daily backup 
job over a long distance network, if you use a protocol without own 
compression, it is still better to have compressed log files than 
uncompressed on a compressed filesystem. To me, it's the same as 
compressing large database dumps and not relying on filesystem compression.
YMMV, but I really don't see any benefit of changing the newsyslog code, 
just change defaults in newsyslog.conf.


I appreciate your perspective on this issue. However, I believe there 
are additional benefits to modifying the newsyslog code (which is 
already done in commit 906748d208d3, by the way) beyond what can be 
achieved by simply adjusting the defaults in newsyslog.conf.


Firstly, updating the newsyslog code provides us with greater 
flexibility when introducing new compression modes, such as 'xz -9e', or 
in supporting other compressors. This approach is more efficient than 
continually adding new letters to represent each compression method in 
the configuration file. It simplifies the process and avoids unnecessary 
complexity.


Furthermore, the previous method of representing compression methods in 
the configuration file can be cumbersome for users who have disabled or 
altered their compression configuration.  Each time there is a change in 
newsyslog.conf, these users face potential conflicts that require manual 
resolution.  Updating the code would make the configuration in one 
central place (/etc/crontab) therefore simplifying maintenance for users 
and administrators alike.


While I acknowledge your points regarding the utility of compressed log 
files, especially in scenarios involving daily backups over 
long-distance networks, I believe the flexibility and ease of 
maintenance offered by updating the code would be a significant 
improvement for many users.


Looking forward to further discussion on this.

Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Proposal: Disable compression of newsyslog by default

[Xin Li]

Hi,

Inspired by D42961, I propose that we move forward with disabling the 
compression by default in newsyslog, as implemented in 
https://reviews.freebsd.org/D43169


Historically, newsyslog has compressed rotated log files to save disk 
space. This approach was valuable in the early days where storage space 
was limited.  However, the landscape has changed significantly.  Modern 
file systems, such as ZFS, now offer native compression capabilities. 
Additionally, the widespread availability of larger hard drives has 
diminished the necessity for additional compression.  Notably, the need 
to decompress log files for pattern searches poses a significant 
inconvenience, further questioning the utility of this legacy feature.


In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log 
file is eligible for compression rather than directly enforcing it. It 
allows for a more flexible approach, wherein the actual compression 
method can be set to "none" or specified as one among bzip2, gzip, xz, 
or zstd.


Therefore I would propose that we change the default compression setting 
to "none" in FreeBSD 15.0.  This change reflects our adaptation to the 
evolving technological environment and user needs.  It also aligns with 
the broader initiative to modernize our systems while maintaining 
flexibility and efficiency.


I look forward to your thoughts and feedback on this proposal.

Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

[Xin Li]

On 2023-11-20 19:33, Warner Losh wrote:



On Mon, Nov 20, 2023 at 6:21 PM Xin Li <mailto:delp...@delphij.net>> wrote:


Hi,

It seems that the recent improvements of ACPI detection (e0f3dc82727f
and 0b01d45783c3) would leave the system in an unbootable state if the
UEFI files are not being updated at the same time of "make
installworld".  At early boot the kernel would panic with:

panic: running without device atpic requires a local APIC on UEFI
systems

To recover a system in this state, at loader prompt, use:

unset hint.acpi.0.disabled
boot

(I think core.lua should be modified to be compatible with an older
UEFI
payload, possibly issuing a warning that gets logged; and this
should be
mentioned in UPDATING)


I just pushed 
https://cgit.freebsd.org/src/commit/?id=f213da893ca8c7c76e1656b36d3a10f93f9a1760 <https://cgit.freebsd.org/src/commit/?id=f213da893ca8c7c76e1656b36d3a10f93f9a1760> which should fix the issue for x86, with an UPDATING entry for aarch64.


This is at best a stop-gap kludge. The real solution would be for 
loader.efi to publish a list of interfaces it implements and then the 
lua code can cope with old/new better.


Yeah I think it (I assume you mean 
https://cgit.freebsd.org/src/commit/?id=0abe05aeac29d99786401b9078e97dcead35f7f3 
) should be sufficient for x86 systems to boot.  Thanks!


Cheers,



OpenPGP_signature.asc
Description: OpenPGP digital signature

HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

[Xin Li]

Hi,

It seems that the recent improvements of ACPI detection (e0f3dc82727f 
and 0b01d45783c3) would leave the system in an unbootable state if the 
UEFI files are not being updated at the same time of "make 
installworld".  At early boot the kernel would panic with:


panic: running without device atpic requires a local APIC on UEFI systems

To recover a system in this state, at loader prompt, use:

unset hint.acpi.0.disabled
boot

(I think core.lua should be modified to be compatible with an older UEFI 
payload, possibly issuing a warning that gets logged; and this should be 
mentioned in UPDATING)


Cheers,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: MOTD is not created correctly (since 2022/02/18)

[Xin Li]

On 2023-05-22 8:18 PM, Jamie Landeg-Jones wrote:

I've just finally updated to 13-stable, and can't be the first to notice this?!

/etc/rc.d/motd contains the line:

uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 
(\3) #\2,'

Note the space before the "$" - needed because the uname -v output used
to have a trailing space. This was fixed and comitted on 2022/02/18:

https://cgit.freebsd.org/src/commit/usr.bin/uname/uname.c?id=7e05fa3b449007adaa6e588ebb3b8d76f30b355c

Since then, the sed doesn't match, so the uname(1) output is unchanged.

There's no point altering the sed to work with both posibilities, so can
someone commit the fix of removing the ' ' before the '$' in /etc/rc.d/motd ?


Maybe https://reviews.freebsd.org/D40225 ?

(Nice find by the way!  I always feel that something was not right but 
haven't looked close enough.)


Cheers,


OpenPGP_signature
Description: OpenPGP digital signature

Re: find(1): I18N gone wild ?

[Xin LI]

This is expected behavior (in en_US.UTF-8 the ordering is AaBb, not ABab).
You might want to set LC_COLLATE to C if C behavior is desirable.

On Mon, Apr 17, 2023 at 2:06 PM Poul-Henning Kamp 
wrote:

> This surprised me:
>
> # mkdir /tmp/P
> # cd /tmp/P
> # touch FOO
> # touch bar
> # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
> ./FOO
> # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
> ./FOO
> ./bar
>
> Really ?!
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>

Re: cant login after make installworld: pam_opie.so.6 not found

[Xin Li]

On 2023-01-04 6:59 PM, grarpamp wrote:

looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6
and now I cannot pass the login prompt
says the error "pam_opie.so: not found



how can I get it back? I tried everything and nothing brought it back



commit 0aa2700123e22c2b0a977375e087dc2759b8e980
Differential Revision: https://reviews.freebsd.org/D36592


This appeared as perhaps an arbitrary deletion change for some
unknown non-discussed reason. Someone else posted the problems,
user features, and alternatives that would preserve and update use of
OPIE options for FreeBSD users, but again, no one discussed.


Security team has discussed this a decade ago.  See 
https://www.miknet.net/security/skey-dungeon-attack/ for technical details.


And this could have been avoided if user have followed source upgrade 
instructions by performing mergemaster or etcupdate *before* make 
delete-old{-libs}, which is well documented in /usr/src/UPDATING and I 
quote it here:


To upgrade in-place from stable to current
--

make buildworld [9]
make buildkernel KERNCONF=YOUR_KERNEL_HERE  [8]
make installkernel KERNCONF=YOUR_KERNEL_HERE
[1]
 [3]
etcupdate -p[5]
make installworld
etcupdate -B[4]
make delete-old [6]


The order here is very important.

Cheers,

Re: Proposal: remove /usr/bin/minigzip

[Xin Li]

On 7/28/22 23:24, Eugene Grosbein wrote:

29.07.2022 13:12, Xin Li пишет:

Hi,

I'd like to remove /usr/bin/minigzip , a patch is available at:

 https://reviews.freebsd.org/D35979

The minigzip is originally an example application shipped with zlib to 
demonstrate how to use it to implement basic functionality of gzip.  It was 
connected to the base system in 1997, mainly because there wasn't a GPL-free 
implementation of gzip(1):

 
https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b

Now we already have a GPL-free gzip(1) implementation in base system for quite 
a while, so it seems that there isn't much value of keeping minigzip around.  A 
quick grep suggests that it's not being used by the base system anywhere, nor 
in the ports tree.

Any objections?


Have you considered embedded applications (crunchgen etc.)?


Yes, but I don't think it's being used in real life anywhere, base 
system crunchgen examples, including rescue and tools/bsdbox, are all 
using the real gzip.



In 13.1/amd64, /usr/bin/minigzip binary is about 11KB and links with libc and 
libz only.

OTOH, /usr/bin/gzip is about six times larger (64KB) and additionally needs 
libbz2, liblzma, libmd and libthr.


It's a little bit unfair to compare the sizes of the executables 
directly :-)  After all, the C library accounted for 94.4% and 75.4% of 
space for minigzip and gzip respectively:


$ F=/usr/bin/minigzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep 
^/ | sort))

12  /usr/bin/minigzip
1939/lib/libc.so.7
104 /lib/libz.so.6
2054total

$ F=/usr/bin/gzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | 
sort))

63  /usr/bin/gzip
1939/lib/libc.so.7
107 /lib/libmd.so.6
122 /lib/libthr.so.3
104 /lib/libz.so.6
77  /usr/lib/libbz2.so.4
163 /usr/lib/liblzma.so.5
2573total

So yes, gzip is bigger, but arguably it's just about 0.5MiB, or 25% 
larger, and among that 2573KB, 2510KB or 97.6% was shared library.


But for applications that really want to have smaller footprint, bzip2 
might be a better alternative -- the binary is bigger than minigzip, but 
library was smaller than zlib so the total size is actually a little bit 
smaller:


$ F=/usr/bin/bzip2; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | 
sort))

34  /usr/bin/bzip2
1939/lib/libc.so.7
77  /usr/lib/libbz2.so.4
2050total

(It's true that zlib is a much more popular library and is used in more 
scenarios, like ppp, etc., so in reality this might actually added 99kb 
(=34+77-12), I just wanted to say that there are other options, and if 
minigzip is not really being used, building it on every FreeBSD machines 
doesn't seem to be a good use of resources).


Cheers,

Proposal: remove /usr/bin/minigzip

[Xin Li]

Hi,

I'd like to remove /usr/bin/minigzip , a patch is available at:

https://reviews.freebsd.org/D35979

The minigzip is originally an example application shipped with zlib to 
demonstrate how to use it to implement basic functionality of gzip.  It 
was connected to the base system in 1997, mainly because there wasn't a 
GPL-free implementation of gzip(1):



https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b

Now we already have a GPL-free gzip(1) implementation in base system for 
quite a while, so it seems that there isn't much value of keeping 
minigzip around.  A quick grep suggests that it's not being used by the 
base system anywhere, nor in the ports tree.


Any objections?

Cheers,

[RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?

[Xin Li via freebsd-current]

Hi,

Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2. 
The manual page says:


 nfsv2   Use the NFS Version 2 protocol (the default is to try
 version 3 first then version 2).  Note that NFS version 2
 has a file size limit of 2 gigabytes.

And the code agrees, too:


if (trymntmode == V4) {
nfsvers = 4;
mntvers = 3; /* Workaround for GCC. */
} else if (trymntmode == V2) {
nfsvers = 2;
mntvers = 1;
} else {
nfsvers = 3;
mntvers = 3;
}


When trymntmode == ANY, which is the default, mount_nfs would attempt 
NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try 
again with trymntmode = V2.


Nowadays, it seems that NFSv4 is becoming more and more popular.  If a 
server is providing only NFSv4 service, when mounting without -o nfsv4, 
the user would receive message like:


RPCPROG_MNT: RPC:Timed out

A friend of mine who is using TrueNAS core hit this yesterday and his 
Linux client worked just fine.  It took me some time to figure out that 
the root cause.  It seems that modern Linux distributions have been 
using NFSv4 by default for some time.


So I think it makes sense to teach mount_nfs to attempt NFSv4, then 
NFSv3 and NFSv2.  However, this might be a POLA violation and we would 
like to know if there is any objections.


(I've attached a patch but I haven't actually tested it yet).

Cheers,From eb6e60233d840d072d0280325ca2cb37455dc2f1 Mon Sep 17 00:00:00 2001
From: Xin LI 
Date: Mon, 3 Jan 2022 10:48:17 -0800
Subject: [PATCH] mount_nfs: Attempt NFSv4 before NFSv3 and NFSv2.

---
 sbin/mount_nfs/mount_nfs.8 |  6 +++---
 sbin/mount_nfs/mount_nfs.c | 29 -
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/sbin/mount_nfs/mount_nfs.8 b/sbin/mount_nfs/mount_nfs.8
index 648cb2128e90..741b5c24a080 100644
--- a/sbin/mount_nfs/mount_nfs.8
+++ b/sbin/mount_nfs/mount_nfs.8
@@ -28,7 +28,7 @@
 .\"	@(#)mount_nfs.8	8.3 (Berkeley) 3/29/95
 .\" $FreeBSD$
 .\"
-.Dd July 10, 2021
+.Dd January 10, 2022
 .Dt MOUNT_NFS 8
 .Os
 .Sh NAME
@@ -216,8 +216,8 @@ This option requires the
 .Cm nfsv4
 option.
 .It Cm nfsv2
-Use the NFS Version 2 protocol (the default is to try version 3 first
-then version 2).
+Use the NFS Version 2 protocol (the default is to try version 4 first,
+then version 3, then version 2).
 Note that NFS version 2 has a file size limit of 2 gigabytes.
 .It Cm nfsv3
 Use the NFS Version 3 protocol.
diff --git a/sbin/mount_nfs/mount_nfs.c b/sbin/mount_nfs/mount_nfs.c
index e1eaf206e982..e6d7e0afbfb7 100644
--- a/sbin/mount_nfs/mount_nfs.c
+++ b/sbin/mount_nfs/mount_nfs.c
@@ -125,6 +125,7 @@ static enum mountmode {
 	ANY,
 	V2,
 	V3,
+	V3orV2,
 	V4
 } mountmode = ANY;
 
@@ -777,15 +778,21 @@ nfs_tryproto(struct addrinfo *ai, char *hostp, char *spec, char **errstr,
 	}
 
 tryagain:
-	if (trymntmode == V4) {
+	switch (trymntmode) {
+	case V4:
+	case ANY:
 		nfsvers = 4;
 		mntvers = 3; /* Workaround for GCC. */
-	} else if (trymntmode == V2) {
-		nfsvers = 2;
-		mntvers = 1;
-	} else {
+		break;
+	case V3orV2:
+	case V3:
 		nfsvers = 3;
 		mntvers = 3;
+		break;
+	case V2:
+		nfsvers = 2;
+		mntvers = 1;
+		break;
 	}
 
 	if (portspec != NULL) {
@@ -799,10 +806,14 @@ nfs_tryproto(struct addrinfo *ai, char *hostp, char *spec, char **errstr,
 
 		if (!rpcb_getaddr(NFS_PROGRAM, nfsvers, nconf, _nb,
 		hostp)) {
-			if (rpc_createerr.cf_stat == RPC_PROGVERSMISMATCH &&
-			trymntmode == ANY) {
-trymntmode = V2;
-goto tryagain;
+			if (rpc_createerr.cf_stat == RPC_PROGVERSMISMATCH) {
+if (trymntmode == ANY) {
+	trymntmode = V3orV2;
+	goto tryagain;
+} else if (trymntmode == V3orV2) {
+	trymntmode = V2;
+	goto tryagain;
+}
 			}
 			snprintf(errbuf, sizeof errbuf, "[%s] %s:%s: %s",
 			netid, hostp, spec,
-- 
2.34.1

Re: ThinkPad: reboots after successful shutdown -p

[Xin Li via freebsd-current]

On 3/16/21 9:45 PM, Warner Losh wrote:
> 
> 
> On Tue, Mar 16, 2021 at 10:18 PM Xin Li  <mailto:delp...@freebsd.org>> wrote:
> 
>     On 11/17/19 23:14, Xin Li wrote:
> > Hi,
> >
> > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
> > system would shut down and seemingly powered off, then it would
> restart
> > after about 5-10 seconds.
> >
> > Is this a known issue?  Arguably this is not necessarily a FreeBSD
> > issue, but it seems that the Windows 10 installation doesn't have the
> > problem, so I guess there might be some difference between our and
> > Windows's shutdown sequence.
> 
> I've found a workaround for this, for the record, setting
> hw.efi.poweroff=0 would make the laptop to correctly shutdown.
> 
> However I don't see anything wrong with sys/dev/efidev/efirt.c's
> implementation of EFI shutdown; it appears to be essentially the same as
> implemented in command_poweroff() in stand/efi/loader/main.c, but
> 'poweroff' would work just fine in loader.efi.
> 
> Can someone familiar with the code shed me some light here? :-)
> 
> It looks like what Linux did was to prefer ACPI S5, unless it's not
> available or the system have HW_REDUCED flag in FADT, so if we do
> something similar it would fix the issue for me, but according to
> bugs.freebsd.org/233998 <http://bugs.freebsd.org/233998> that's not
> the case for at least Conor's system
> (_S5 appears to be in the ACPI dump), so I think it's something else...
> 
> 
> For me, interrupt storm on shutdown has been the causes of issues like
> this...
> 
> Any chance you can eliminate that as a possibility?

Hmm, that's a good question -- is there a way to tell after the screen
was turned off?

Before the screen was turned off, there doesn't appear to be interrupt
storm.  The system was performing a typical FreeBSD shutdown procedure:
All buffers synced, showed uptime, destroyed GELI devices, spin down the
SATA devices, shutdown the cardreader (rtsx0), detached all USB devices
(hidraw1, hidbus, usbhid1, ubt0, uhub0), screen turned slightly red for
a very brief period (maybe side effect of turning off the backlight),
then goes off.

I think most of FreeBSD drivers would turn off interrupt from the device
before detaching, but I haven't looked into all of my devices; but from
what I have seen on screen (captured a 60fps video and can share if that
helps), there doesn't appear to be an interrupt storm before that.

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

Re: ThinkPad: reboots after successful shutdown -p

[Xin Li]

On 11/17/19 23:14, Xin Li wrote:
> Hi,
> 
> I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
> system would shut down and seemingly powered off, then it would restart
> after about 5-10 seconds.
> 
> Is this a known issue?  Arguably this is not necessarily a FreeBSD
> issue, but it seems that the Windows 10 installation doesn't have the
> problem, so I guess there might be some difference between our and
> Windows's shutdown sequence.

I've found a workaround for this, for the record, setting
hw.efi.poweroff=0 would make the laptop to correctly shutdown.

However I don't see anything wrong with sys/dev/efidev/efirt.c's
implementation of EFI shutdown; it appears to be essentially the same as
implemented in command_poweroff() in stand/efi/loader/main.c, but
'poweroff' would work just fine in loader.efi.

Can someone familiar with the code shed me some light here? :-)

It looks like what Linux did was to prefer ACPI S5, unless it's not
available or the system have HW_REDUCED flag in FADT, so if we do
something similar it would fix the issue for me, but according to
bugs.freebsd.org/233998 that's not the case for at least Conor's system
(_S5 appears to be in the ACPI dump), so I think it's something else...

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

Re: UEFI boot hangs after loading kernel with efi_max_resolution="4k"

[Xin Li via freebsd-current]

With Toomas's help (thanks!), I was able to partially resolve the hang
and blank screen at boot issue, for the record, for now this can be
solved by adding:

screen.font="16x32"

in /boot/loader.conf; no more efi_max_resolution setting is needed.

Setting allscreen_flags to load font still panics the system, but at
least the screen is now in a readable state, and kernel loads fine.
I'll update this thread if I found something new.

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

UEFI boot hangs after loading kernel with efi_max_resolution="4k"

[Xin Li via freebsd-current]

Hi,

It seems that some recent change after 282381aa53a would prevent my
laptop (Lenovo P51, with 4k LCD) from booting.

I have made some attempt to find out why, so far, it seems that setting
efi_max_resolution="480p" or efi_max_resolution="720p" would allow it to
boot to single user mode.

Unfortunately, with KMS modules loaded, the screen would enter high
resolution mode, and the screen output would be garbled.  To make the
situation worse, because I have the following configuration set in
/etc/rc.conf:

allscreens_flags="-f /usr/share/vt/fonts/terminus-b32.fnt"

the kernel would panic shortly after loading the font:

===
Unread portion of the kernel message buffer:
<118>Configuring vt: blanktime allscreens
panic: free: address 0x81c6ee00(0x81c6e000) has not been
allocated.

cpuid = 3
time = 1611996927
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0141dbc490
vpanic() at vpanic+0x181/frame 0xfe0141dbc4e0
panic() at panic+0x43/frame 0xfe0141dbc540
free() at free+0xf8/frame 0xfe0141dbc570
vt_change_font() at vt_change_font+0x16f/frame 0xfe0141dbc5c0
vtterm_ioctl() at vtterm_ioctl+0xef6/frame 0xfe0141dbc610
termtty_ioctl() at termtty_ioctl+0xc3/frame 0xfe0141dbc660
tty_ioctl() at tty_ioctl+0x8e/frame 0xfe0141dbc6b0
ttydev_ioctl() at ttydev_ioctl+0x247/frame 0xfe0141dbc700
devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe0141dbc750
vn_ioctl() at vn_ioctl+0x131/frame 0xfe0141dbc860
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe0141dbc880
kern_ioctl() at kern_ioctl+0x289/frame 0xfe0141dbc8f0
sys_ioctl() at sys_ioctl+0x12a/frame 0xfe0141dbc9c0
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0141dbcaf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0141dbcaf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80038bc9a, rsp =
0x7fffe938, rbp = 0x7fffebf0 ---
Uptime: 28s
Dumping 1421 out of 32433
MB:..2%..11%..21%..31%..41%..51%..61%..71%..82%..91%


I thought the panic was fixed (bug 252833), but it's probably a
different corner case, which can happen when loader/EFI provided
resolution is different from the current KMS-enabled resolution (haven't
took a closer look yet).

But it's still unclear to me why the screen would go blank when
efi_max_resolution is set to "4k" or unset.  I thought it's probably
panicked somewhere, but it's hard to confirm as I don't have a serial
console with this laptop.

If I replace the loader taken from the 20201231 snapshot (from
282381aa53a), then the laptop would boot just fine.

In summary, what I know so far was:

Old loader: everything would work just fine.

New loader:

efi_max_resolution="4k" in /boot/loader.conf:
Screen goes blank after "boot" in loader prompt

No efi_max_resolution in /boot/loader.conf:
'show' gives me efi_max_resolution="1x1" and screen goes blank after
"boot" in loader prompt

efi_max_resolution="720p" or 480p in /boot/loader.conf:
Kernel boots fine up to single user mode.
Panic immediately when loading font.

Any suggestion on what this could be?  It's hard to debug boot loader
issues on this laptop as I don't have an usable serial console and blank
screen would make me blind :)

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

Re: zpool upgrade to draid feature: does it require updated zfs boot code ?

[Xin Li via freebsd-current]

On 1/28/21 11:00, Kurt Jaeger wrote:
> Hi!
> 
> Short question:
> 
> Does a zpool upgrade on 14.0 (current) for the draid feature
> require a boot code update ?
> 
> Long version of the same question:
[...]
> With the draid update, no message was displayed.
> 
> Does it require the bootcode update anyway or, if not, why not ?

This sounded like a bug.  Is it your boot pool, or just a regular data pool?

>  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0
>  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd1

To answer your short question: do I need to update bootcode?  No if
draid is the only feature that you have enabled on an existing pool, but
personally I don't recommend upgrading boot pool right now.

The reason for that "No" answer is 1) the boot code do not currently
support draid, and 2) enabling the feature won't activate it until draid
vdev is added to the pool, which is quite unlikely in your case; note
that if you do add draid vdev, your bootcode won't be able to boot from
it anymore.

On my personal laptop, old bootcode would boot pool with draid enabled
but not activated just fine (note that the loader.efi on -CURRENT won't
boot my P51, which I will start a separate discussion; I used
FreeBSD-13.0-CURRENT-amd64-20201231-282381aa53a-255460-memstick.img and
fixed my EFI loader and it worked fine with the draid-enabled boot ZFS
pool).

Hope this helps.

Cheers,




OpenPGP_signature
Description: OpenPGP digital signature

Re: GPF on boot with devmatch

[Xin Li]

On 10/12/20 11:13, Warner Losh wrote:
> 
> 
> On Mon, Oct 5, 2020 at 3:39 PM Alexander Motin  > wrote:
> 
> On 05.10.2020 17:20, Warner Losh wrote:
> > On Mon, Oct 5, 2020 at 12:36 PM Alexander Motin  
> > >> wrote:
> >
> >     I can add that we've received report about identical panic on
> FreeBSD
> >     releng/12.2 of r365436, AKA TrueNAS 12.0-RC1:
> >     https://jira.ixsystems.com/browse/NAS-107578
>  .  So it looks a) pretty
> >     rate (one report from thousands of early adopters and none in
> our lab),
> >     and b) it is in stable/12 too, not only head.
> >
> > Thanks! I'll see if I can recreate here  But we're accessing the
> > sysctl tree from devmatch to get some information, which should always
> > be OK (the fact that it isn't suggests either a bug in some driver
> > leaving bad pointers, or some race or both)...  It would be nice
> to know
> > which nodes they were, or to have a kernel panic I can look at...
> 
> All we have now in this case is a screenshot you may see in the ticket.
>  Also previously the same user on some earlier version of stable/12
> reported other very weird panics on process lock being dropped where it
> can't be in some other sysctls inside kern.proc, so if we guess those
> are related, I suspect there may be some kind of memory corruption
> happening, but have no clue where.  Unfortunately we have only textdumps
> for those.  So if Xin is able to reproduce it locally, it may be our
> best chance to debug it, at least this specific issue.
> 
> 
> That's totally weird. 
> 
> Xin Li's traceback lead to code I just rewrote in current, while this
> code leads to code that's been there for a long time and hasn't been
> MFC'd. This suggests that Xin Li's backtrace isn't to be trusted, or
> there's two issues at play. Both are plausible. I've fixed a minor
> signedness bug and a possible one byte overflow that might have happened
> in the code I just rewrote. But I suspect this is due to something else
> related to how children are handled after we've raced. Maybe there's
> something special about how USB does things, because other buses will
> create the child early and the child list is stable. If USB's discovery
> code is adding something and is racing with devd's walking of the tree,
> that might explain it...  It would be nice if there were some way to
> provoke the race on a system I could get a core from for deeper analysis

There might be some other players; I just don't have a lot of time
recently to shoot it down; the system is somewhat critical for my
internal network so I can't afford to have long downtimes (it's fine if
I have controllable downtimes, e.g. if you want me to deliberately panic
the system and get some debugging data, please feel free to ask as long
as I can continue to boot at the end of experiment :))

From what I was observing, it seems to be some kind of race condition
between the USB stack and sysctl tree; however, the race might be
delicate as I never successfully provoked the panic on my laptop, which
also runs -CURRENT).  If you want to add some instruments to the code,
please let me know and I'll get the tree patched to try to catch it.

Cheers,

> Warner
>  
> 
> -- 
> Alexander Motin
> 



OpenPGP_signature
Description: OpenPGP digital signature

Re: GPF on boot with devmatch

[Xin Li]

On 10/4/20 10:13 PM, Warner Losh wrote:
> 
> 
> On Sun, Oct 4, 2020, 11:07 PM Xin Li  <mailto:delp...@delphij.net>> wrote:
> 
> Hi,
> 
> I'm seeing this panic at boot after upgrading from r366217 to r366364,
> and continues to exist for r366421 (but I haven't find out the exact
> change that caused it).  Preloading the relevant kernel modules
> (uhid.ko, ums.ko and wmt.ko) seems to make the kernel boot correctly.
> 
> 
> What happens if you disable devmatch and load these modules by hand?

Loading these modules from loader or kld_list will prevent this panic
regardless if devmatch is enabled.

> What happens if you load them from rc.d scripts with devmatch disabled?

It seems that the devmatch was started by devd and not rc.  Disabling
devmatch (setting devmatch_enable="NO" without loading any of these klds
would not provoke the panic).

> Warner
> 
> This is not reproducible on my laptop, which will load many more kernel
> modules.
> 
> ===
> Autoloading module: uhid.ko
> Autoloading module: wmt.ko
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 2; apic id = 04
> instruction pointer     = 0x20:0x806ad6eb
> stack pointer           = 0x28:0xfe01850cd960
> frame pointer           = 0x28:0xfe01850cd9e0
> code segment            = base 0x0, limit 0xf, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 740 (devmatch)
> trap number             = 9
> panic: general protection fault
> cpuid = 3
> time = 1601866799
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01850cd670
> vpanic() at vpanic+0x182/frame 0xfe01850cd6c0
> panic() at panic+0x43/frame 0xfe01850cd720
> trap_fatal() at trap_fatal+0x387/frame 0xfe01850cd780
> trap() at trap+0xa4/frame 0xfe01850cd890
> calltrap() at calltrap+0x8/frame 0xfe01850cd890
> --- trap 0x9, rip = 0x806ad6eb, rsp = 0xfe01850cd960, rbp =
> 0xfe01850cd9e0 ---
> sysctl_devices() at sysctl_devices+0x24b/frame 0xfe01850cd9e0
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame
> 0xfe01850cda30
> sysctl_root() at sysctl_root+0x20a/frame 0xfe01850cdab0
> userland_sysctl() at userland_sysctl+0x17d/frame 0xfe01850cdb60
> sys___sysctl() at sys___sysctl+0x5f/frame 0xfe01850cdc10
> amd64_syscall() at amd64_syscall+0x135/frame 0xfe01850cdd30
> fast_syscall_common() at fast_syscall_common+0xf8/frame
> 0xfe01850cdd30
> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80038968a, rsp =
> 0x7fffd988, rbp = 0x7fffd9c0 ---
> ===
> 
> sysctl_devices+0x24b (0x6dab) was:
> 
>         sb->s_len += strlen(p);
>     6d50:       4c 89 e7                mov    %r12,%rdi
>     6d53:       e8 00 00 00 00          callq  6d58
> 
>     6d58:       48 01 45 b0             add    %rax,-0x50(%rbp)
>     6d5c:       48 8d 7d 88             lea    -0x78(%rbp),%rdi
>         sbuf_putc(, '\0');
>     6d60:       31 f6                   xor    %esi,%esi
>     6d62:       e8 00 00 00 00          callq  6d67
> 
>         MPASS((sb->s_flags & SBUF_INCLUDENUL) == 0);
>     6d67:       f6 45 b8 02             testb  $0x2,-0x48(%rbp)
>     6d6b:       0f 85 10 01 00 00       jne    6e81
> 
>         if (sb->s_error != 0)
>     6d71:       83 7d a0 00             cmpl   $0x0,-0x60(%rbp)
>     6d75:       0f 85 8c 00 00 00       jne    6e07
> 
>         p = EOB(sb);
>     6d7b:       4c 8b 65 88             mov    -0x78(%rbp),%r12
>     6d7f:       48 8b 45 b0             mov    -0x50(%rbp),%rax
>         *p = '\0';      /* sbuf buffer isn't NUL terminated until
> sbuf_finish() */
>     6d83:       41 c6 04 04 00          movb   $0x0,(%r12,%rax,1)
>         space = SPACE(sb);
>     6d88:       4c 8b 6d a8             mov    -0x58(%rbp),%r13
>     6d8c:       4c 2b 6d b0             sub    -0x50(%rbp),%r13
>         if (space <= 1) {
>     6d90:       49 83 fd 01             cmp    $0x1,%r13
>     6d94:       77 09                   ja     6d9f
> 
>                 sb->s_error = ENOMEM;
>     6d96:       c7 45 a0 0c 00 00 00    movl   $0xc,-0x60(%rbp)
>     6d9d:       eb 68                   jmp    6e07
> 
>     6d9f:       49 01 c4                

GPF on boot with devmatch

[Xin Li]

Hi,

I'm seeing this panic at boot after upgrading from r366217 to r366364,
and continues to exist for r366421 (but I haven't find out the exact
change that caused it).  Preloading the relevant kernel modules
(uhid.ko, ums.ko and wmt.ko) seems to make the kernel boot correctly.

This is not reproducible on my laptop, which will load many more kernel
modules.

===
Autoloading module: uhid.ko
Autoloading module: wmt.ko


Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 04
instruction pointer = 0x20:0x806ad6eb
stack pointer   = 0x28:0xfe01850cd960
frame pointer   = 0x28:0xfe01850cd9e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 740 (devmatch)
trap number = 9
panic: general protection fault
cpuid = 3
time = 1601866799
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01850cd670
vpanic() at vpanic+0x182/frame 0xfe01850cd6c0
panic() at panic+0x43/frame 0xfe01850cd720
trap_fatal() at trap_fatal+0x387/frame 0xfe01850cd780
trap() at trap+0xa4/frame 0xfe01850cd890
calltrap() at calltrap+0x8/frame 0xfe01850cd890
--- trap 0x9, rip = 0x806ad6eb, rsp = 0xfe01850cd960, rbp =
0xfe01850cd9e0 ---
sysctl_devices() at sysctl_devices+0x24b/frame 0xfe01850cd9e0
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame
0xfe01850cda30
sysctl_root() at sysctl_root+0x20a/frame 0xfe01850cdab0
userland_sysctl() at userland_sysctl+0x17d/frame 0xfe01850cdb60
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe01850cdc10
amd64_syscall() at amd64_syscall+0x135/frame 0xfe01850cdd30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01850cdd30
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80038968a, rsp =
0x7fffd988, rbp = 0x7fffd9c0 ---
===

sysctl_devices+0x24b (0x6dab) was:

sb->s_len += strlen(p);
6d50:   4c 89 e7mov%r12,%rdi
6d53:   e8 00 00 00 00  callq  6d58 
6d58:   48 01 45 b0 add%rax,-0x50(%rbp)
6d5c:   48 8d 7d 88 lea-0x78(%rbp),%rdi
sbuf_putc(, '\0');
6d60:   31 f6   xor%esi,%esi
6d62:   e8 00 00 00 00  callq  6d67 
MPASS((sb->s_flags & SBUF_INCLUDENUL) == 0);
6d67:   f6 45 b8 02 testb  $0x2,-0x48(%rbp)
6d6b:   0f 85 10 01 00 00   jne6e81 
if (sb->s_error != 0)
6d71:   83 7d a0 00 cmpl   $0x0,-0x60(%rbp)
6d75:   0f 85 8c 00 00 00   jne6e07 
p = EOB(sb);
6d7b:   4c 8b 65 88 mov-0x78(%rbp),%r12
6d7f:   48 8b 45 b0 mov-0x50(%rbp),%rax
*p = '\0';  /* sbuf buffer isn't NUL terminated until
sbuf_finish() */
6d83:   41 c6 04 04 00  movb   $0x0,(%r12,%rax,1)
space = SPACE(sb);
6d88:   4c 8b 6d a8 mov-0x58(%rbp),%r13
6d8c:   4c 2b 6d b0 sub-0x50(%rbp),%r13
if (space <= 1) {
6d90:   49 83 fd 01 cmp$0x1,%r13
6d94:   77 09   ja 6d9f 
sb->s_error = ENOMEM;
6d96:   c7 45 a0 0c 00 00 00movl   $0xc,-0x60(%rbp)
6d9d:   eb 68   jmp6e07 
6d9f:   49 01 c4add%rax,%r12
return (dev->parent);
6da2:   48 8b 7b 28 mov0x28(%rbx),%rdi
if (parent == NULL) {
6da6:   48 85 fftest   %rdi,%rdi
6da9:   74 4b   je 6df6 
KOBJOPLOOKUP(((kobj_t)_dev)->ops,bus_child_location_str);
6dab:   48 8b 07mov(%rdi),%rax
6dae:   48 c7 c2 00 00 00 00mov$0x0,%rdx
6db5:   0f b6 0d 00 00 00 00movzbl 0x0(%rip),%ecx#
6dbc 
6dbc:   4c 8b 04 c8 mov(%rax,%rcx,8),%r8
6dc0:   49 39 10cmp%rdx,(%r8)
6dc3:   74 22   je 6de7 
6dc5:   48 8d 34 c8 lea(%rax,%rcx,8),%rsi
6dc9:   48 89 7d d0 mov%rdi,-0x30(%rbp)
6dcd:   48 8b b8 00 08 00 00mov0x800(%rax),%rdi
6dd4:   48 c7 c2 00 00 00 00mov$0x0,%rdx
6ddb:   e8 00 00 00 00  callq  6de0 
6de0:   48 8b 7d d0 mov-0x30(%rbp),%rdi
6de4:   49 89 c0mov%rax,%r8
rc = ((bus_child_location_str_t *) _m)(_dev, _child, _buf, _buflen);
6de7:   48 89 demov%rbx,%rsi
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

ioctl argument type [Was Re: svn commit: r359968 - head/sys/kern]

[Xin LI]

Hi,

I have seen Chromium trigger the warning (I run -CURRENT with INVARIANTS)
and looked into the code history a little bit.

It seems that the command was changed to u_long in r36846
 with a
follow up commit of r38517
 , possibly
because ioctl was defined to take an unsigned long command before FreeBSD.

Internally, we have truncated it to 32-bit since 2005 (r140406
), and this
recent change made it a silent behavior.  POSIX, on the other hand, defined

ioctl as taking an int as its second parameter, but neither Linux (glibc in
particular, despite its documentation says

differently) nor macOS appear to define it that way, but Solaris seems
 to be
defining it as an int.

What was the motivation to keep the prototype definition as

 int
 ioctl(int fd, unsigned long request, ...);

instead of:

 int
 ioctl(int fd, int request, ...);

Other than to make existing code happy?  Alternatively, will it be a good
idea to give compiler some hints (e.g. by using __attribute__(enable_if))
to emit errors, if we insist keeping the existing signature?


On Wed, Apr 15, 2020 at 6:21 AM Hans Petter Selasky 
wrote:

> Author: hselasky
> Date: Wed Apr 15 13:20:51 2020
> New Revision: 359968
> URL: https://svnweb.freebsd.org/changeset/base/359968
>
> Log:
>   Cast all ioctl command arguments through uint32_t internally.
>
>   Hide debug print showing use of sign extended ioctl command argument
>   under INVARIANTS. The print is available to all and can easily fill
>   up the logs.
>
>   No functional change intended.
>
>   MFC after:1 week
>   Sponsored by: Mellanox Technologies
>
> Modified:
>   head/sys/kern/sys_generic.c
>
> Modified: head/sys/kern/sys_generic.c
>
> ==
> --- head/sys/kern/sys_generic.c Wed Apr 15 13:13:46 2020(r359967)
> +++ head/sys/kern/sys_generic.c Wed Apr 15 13:20:51 2020(r359968)
> @@ -652,18 +652,19 @@ int
>  sys_ioctl(struct thread *td, struct ioctl_args *uap)
>  {
> u_char smalldata[SYS_IOCTL_SMALL_SIZE]
> __aligned(SYS_IOCTL_SMALL_ALIGN);
> -   u_long com;
> +   uint32_t com;
> int arg, error;
> u_int size;
> caddr_t data;
>
> +#ifdef INVARIANTS
> if (uap->com > 0x) {
> printf(
> "WARNING pid %d (%s): ioctl sign-extension ioctl
> %lx\n",
> td->td_proc->p_pid, td->td_name, uap->com);
> -   uap->com &= 0x;
> }
> -   com = uap->com;
> +#endif
> +   com = (uint32_t)uap->com;
>
> /*
>  * Interpret high order word to find amount of data to be
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Is there any error checking on swap?

[Xin Li]

On 7/12/20 12:29 AM, John-Mark Gurney wrote:
> bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700:
>> Is there any error checking on swap traffic, along the lines of
>> a checksum or parity test? 
>>
>> Just curious what happens if a page written out is corrupted  when
>> it comes back.
> 
> Looks like it doesn't:
> https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389

Technically one can enable checks with e.g. geli(8), but note that the
geli(8) provider will not "prime" the HMAC data so attaching the device
will immediately spam the system log with some authentication errors due
to GEOM tasting (because the kernel would try to read locations that
potentially contain metadata for other GEOM providers).

For the case of swap, since the write is always page sized, it's
probably optimal to implement something in the swap layer itself and
store the expected checksums in memory.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: magic file update?

[Xin Li]

On 6/17/20 8:08 AM, Antoine Brodin wrote:
> On Wed, Jun 17, 2020 at 4:00 PM Michael Butler
>  wrote:
>>
>> I'm seeing this message repeatedly during port builds. Should I be
>> concerned?
>>
>> file: File 5.39 supports only version 16 magic files.
>> `/usr/share/misc/magic.mgc' is version 14
> 
> Hi,
> 
> FILES and FILESDIR are overwritten in lib/libmagic/Makefile :-/

Thanks, this should have been fixed by r362279.  I should have used a
fresh installation for testing, sorry about that.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

[Xin Li]

On 6/11/20 10:19, Mark Johnston wrote:
> On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote:
>> On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote:
>>> ...
>>> This should fix noexec for modules.
>>>
>>> diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
>>> index 81db4d7ca85..cb84fc95691 100644
>>> --- a/sys/x86/x86/mp_x86.c
>>> +++ b/sys/x86/x86/mp_x86.c
>>> 
>>
>> Thanks!  Patch applied with no problems; I will plan on rebooting to
>> head & rebuilding & smoke-testing once I get some more work-stuff done.
> 
> I was able to verify that the patch fixes my instance of the panic.

I can confirm that the patch also fixed my panic too.  Thanks!

Cheers,




signature.asc
Description: OpenPGP digital signature

Re: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

[Xin Li]

Hi, Conrad,

On 6/6/20 9:28 AM, Conrad Meyer wrote:
> # geli attach /dev/gpt/testingeli
> Enter passphrase:
> GEOM_ELI: Device md0s1.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI: Crypto: software
> GEOM_LABEL[2]: Tasting md0s1.eli.
> # ls -l /dev/gpt/testingeli*
> lrwxr-xr-x 1 root wheel  8 Jun  6 09:22 /dev/gpt/testingeli -> ../md0s1
> lrwxr-xr-x 1 root wheel 12 Jun  6 09:24 /dev/gpt/testingeli.eli -> 
> ../md0s1.eli
> 
> https://reviews.freebsd.org/D25168

Thanks for the quick fix!

I have applied D24968 and D25168 over r361880 (with some minor unrelated
local changes) and can confirm that the gptid label + geli worked fine now.

However, it seems that the GPT partitions are not showing up under
/dev/diskid (in your test 1 you are specifying the diskid label itself
so it's not clear to me if they would; on my laptop, the diskid label is
now showing up, but not the partitions associated with it (in your case,
that would be /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4p2 and
/dev/diskid/DISK-BHYVE-2613-8EFD-BAF4p3).  Could you please take a look
at these too?

(BTW. On boot I'm now seeing:

g_dev_taste: make_dev_p() failed (gp->name=ada1, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1p2, error=17)

which may be a result of ZFS's GEOM integration (ada1p2 is the root
zpool); I can't really test the ZFS situation yet as I don't have a USB
drive at hand and still waiting for my order to arrive).

Cheers,

> On Sat, Jun 6, 2020 at 8:52 AM Conrad Meyer  wrote:
>>
>> Hi Xin Li,
>>
>> Thank you for the report and diagnosis.  Sorry for the breakage.
>>
>> I have reverted the change and hope to address the issues you have 
>> identified.
>>
>> There seem to be two issues identified:
>> 1. When ZFS attaches to a partition of a disk, the /dev/diskid label 
>> disappears.
>> 2. geli(8) attach of symlink labels doesn't work
>>
>> (1) is interesting, as it does not seem to happen to UFS or swap consumers:
>>
>> # mount
>> /dev/gpt/rootfs on / (ufs, local, noatime, soft-updates)
>> # swapctl -l
>> Device:   1024-blocks Used:
>> /dev/vtbd0p21048576 0
>> # ls -l /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 /dev/gpt/{rootfs,swapfs}
>> lrwxr-xr-x 1 root wheel  8 May 22 20:18
>> /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 -> ../vtbd0
>> lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/rootfs -> ../vtbd0p3
>> lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/swapfs -> ../vtbd0p2
>>
>> I wonder what is different in the ZFS case here.
>>
>> (2)
>>
>> # ls -l /dev/gpt/testingeli
>> lrwxr-xr-x 1 root wheel 8 Jun  6 08:33 /dev/gpt/testingeli -> ../md0s1
>> # geli init /dev/gpt/testingeli
>> Enter new passphrase:
>> Reenter new passphrase:
>> ...
>> # geli attach /dev/gpt/testingeli
>> Enter passphrase:
>> geli: Provider gpt/testingeli is invalid.
>> geli: There was an error with at least one provider.
>>
>> So at least the latter problem is straightforward to resolve.  I have
>> a patch I'm testing locally now, and will upload to phabricator
>> shortly.
>>
>> Best regards,
>> Conrad
>>
>>
>> On Sat, Jun 6, 2020 at 1:17 AM Xin Li  wrote:
>>>
>>> I just spent quite some time to revive my laptop.  TL;DR: if you are
>>> using /dev/diskid or /dev/gptid labels and GELI, please wait until
>>> things settled.
>>>
>>> ===
>>>
>>> On 6/5/20 9:12 AM, Conrad Meyer wrote:
>>>> Author: cem
>>>> Date: Fri Jun  5 16:12:21 2020
>>>> New Revision: 361838
>>>> URL: https://svnweb.freebsd.org/changeset/base/361838
>>>>
>>>> Log:
>>>>   geom_label: Use provider aliasing to alias upstream geoms
>>>>
>>>>   For synthetic aliases (just pseudonyms inferred from metadata like GPT or
>>>>   UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to 
>>>> create
>>>>   a symlink to the real device instead of creating an independent device.
>>>>   This makes it more clear which labels and devices correspond, and we can
>>>>   safely have multiple labels to a single device accessed at once.
>>>>
>>>>   The confusingly named geom_label on-disk construct continues to behave
>>>>   identically to how it did before.
>>>>
>>>>   This requires teaching GEOM's provider aliasing about the possibility
>>>>   that aliases might be added later in time, and GEOM's devfs interaction
>>>>   layer not to worry about existing aliases during retaste.
>>>>

HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

[Xin Li]

I just spent quite some time to revive my laptop.  TL;DR: if you are
using /dev/diskid or /dev/gptid labels and GELI, please wait until
things settled.

===

On 6/5/20 9:12 AM, Conrad Meyer wrote:
> Author: cem
> Date: Fri Jun  5 16:12:21 2020
> New Revision: 361838
> URL: https://svnweb.freebsd.org/changeset/base/361838
> 
> Log:
>   geom_label: Use provider aliasing to alias upstream geoms
>   
>   For synthetic aliases (just pseudonyms inferred from metadata like GPT or
>   UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to create
>   a symlink to the real device instead of creating an independent device.
>   This makes it more clear which labels and devices correspond, and we can
>   safely have multiple labels to a single device accessed at once.
>   
>   The confusingly named geom_label on-disk construct continues to behave
>   identically to how it did before.
>   
>   This requires teaching GEOM's provider aliasing about the possibility
>   that aliases might be added later in time, and GEOM's devfs interaction
>   layer not to worry about existing aliases during retaste.
>   
>   Discussed with: imp
>   Relnotes:   sure, if we don't end up reverting it

This would break (and the effect can be quite persistent and hard to
repair, see explanation below) existing configuration as some GEOM
classes are not converted to support the new way of device
representation, so I'd like to request this change be reverted for now
until these are fixed.

Consider the following configuration, where one have a hard drive
partitioned with GPT, like:

=>40  1953525088  ada1  GPT  (932G)
  40  262144 1  efi  (128M)
  262184 8388608 2  freebsd-zfs  (4.0G)
 865079267108864 3  freebsd-swap  (32G)
75759656  1877765472 4  freebsd-zfs  (895G)

Now, the first ZFS pool is created as root pool.  ZFS gets an exclusive
hold of 'ada1p2' despite the pool is carefully created to use
/dev/diskid/p2 instead of ada1p2.

ZFS writes the new device path to vdev label.  For ZFS, this doesn't
matter much as it always checks the label.

However, this will prevent GEOM from properly creating
/dev/diskid/.

In order to prevent accidentally writing data to wrong disk, for "raw"
disk partitions it's usually a good idea to reference them with labels,
either by /dev/diskid or /dev/gptid.  With /dev/ada1p2 exclusively
accessed by ZFS, the /dev/diskid/ representing the disk is
now gone.

And to make the situation even worse, simply changing the partition
reference to the corresponding /dev/gptid/ doesn't really work
either, when one is encrypting partitions individually.  In the example
above, adap4 is an encrypted partition and with the alias change, one
can no longer "geli attach" them via /dev/gptid/.  They can still
be attached by the "canonical" path (/dev/ada1p4), but for the swap
partition that would completely defeat the purpose of using label (to
prevent accidentally writing to the wrong disk).

For my case, reverting to an older kernel is not sufficient to fix the
configuration, because ZFS is recording the "canonical" device path
(/dev/ada1p2) and /dev/diskid label for this disk disappeared somewhat
permanently (I would have to find a USB drive somewhere to fix the root
pool to use the "right" device path).

>   Differential Revision:  https://reviews.freebsd.org/D24968
[...]
> Modified: head/sys/geom/label/g_label.c
> ==
> --- head/sys/geom/label/g_label.c Fri Jun  5 16:05:09 2020
> (r361837)
> +++ head/sys/geom/label/g_label.c Fri Jun  5 16:12:21 2020
> (r361838)
> @@ -344,18 +345,16 @@ g_label_taste(struct g_class *mp, struct g_provider *p
>  {
>   struct g_label_metadata md;
>   struct g_consumer *cp;
> + struct g_class *clsp;
>   struct g_geom *gp;
>   int i;
> + bool changed;
>  
>   g_trace(G_T_TOPOLOGY, "%s(%s, %s)", __func__, mp->name, pp->name);
>   g_topology_assert();
>  
>   G_LABEL_DEBUG(2, "Tasting %s.", pp->name);
>  
> - /* Skip providers that are already open for writing. */
> - if (pp->acw > 0)
> - return (NULL);
> -
>   if (strcmp(pp->geom->class->name, mp->name) == 0)
>   return (NULL);
>  
> @@ -391,9 +390,16 @@ g_label_taste(struct g_class *mp, struct g_provider *p
>   if (md.md_provsize != pp->mediasize)
>   break;
>  
> + /* Skip providers that are already open for writing. */
> + if (pp->acw > 0) {
> + g_access(cp, -1, 0, 0);
> + goto end;
> + }
> +

(Is this still necessary when the eventual provider would be the real one?)

I think symlink aliasing is a the right direction but we need to be
really careful to not break existing and legitimate usage.  Since this
also breaks GELI when using with labels, I'd like to request that this
change be backed out for 

Re: CFT: if_bridge performance improvements

[Xin Li]

On 4/24/20 06:42, Kristof Provost wrote:
> On 22 Apr 2020, at 18:15, Xin Li wrote:
>> On 4/22/20 01:45, Kristof Provost wrote:
>>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>>> Hi,
>>>>
>>>> On 4/14/20 02:51, Kristof Provost wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks to support from The FreeBSD Foundation I’ve been able to
>>>>> work on
>>>>> improving the throughput of if_bridge.
>>>>> It changes the (data path) locking to use the NET_EPOCH
>>>>> infrastructure.
>>>>> Benchmarking shows substantial improvements (x5 in test setups).
>>>>>
>>>>> This work is ready for wider testing now.
>>>>>
>>>>> It’s under review here: https://reviews.freebsd.org/D24250
>>>>>
>>>>> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
>>>>> Patches for stable/12:
>>>>> https://people.freebsd.org/~kp/if_bridge/stable_12/
>>>>>
>>>>> I’m not currently aware of any panics or issues resulting from these
>>>>> patches.
>>>>
>>>> I have observed the following panic with latest stable/12 after
>>>> applying
>>>> the stable_12 patchset, it appears like a race condition related NULL
>>>> pointer deference, but I haven't took a deeper look yet.
>>>>
>>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>>> acting as a router.  Please let me know if you need additional
>>>> information; I can try -CURRENT as well, but it would take some time as
>>>> the box is relatively slow (it's a ZFS based system so I can create a
>>>> separate boot environment for -CURRENT if needed, but that would take
>>>> some time as I might have to upgrade the packages, should there be any
>>>> ABI breakages).
>>>>
>>> Thanks for the report. I don’t immediately see how this could happen.
>>>
>>> Are you running an L2 firewall on that bridge by any chance? An earlier
>>> version of the patch had issues with a stray unlock in that code path.
>>
>> I don't think I have a L2 firewall (I assume means filtering based on
>> MAC address like what can be done with e.g. ipfw?  The bridges were
>> created on vlan interfaces though, do they count as L2 firewall?), the
>> system is using pf with a few NAT rules:
>>
> 
> That backtrace looks identical to the one Peter reported, up to and
> including the offset in the bridge_input() function.
> Given that there’s no likely way to end up with a NULL mutex either I
> have to assume that it’s a case of trying to unlock a locked mutex, and
> the most likely reason is that you ran into the same problem Peter ran
> into.
> 
> The current version of the patch should resolve it.

Thanks, I'd like to report that after applying the patch from Peter the
system seems to survive without problem.

Cheers,




signature.asc
Description: OpenPGP digital signature

Ordering of files in zoneinfo [Was Re: sort.core error doing installworld on Current.]

[Xin LI]

Hi,

Thanks for raising this.

I have took a look at the change history, it seems that the find operation
was introduced in r245265
 (brooks@,
to support packaged base) and sort was initially implemented as find -s in
r289451 
(ngie@, to make METALOG reproducible) then as sort in r328958
 (imp@, for
portability).

I wonder if we could drop the sort and replace ${TZS} in line 100 with
${TZS:O} instead?

By the way, looking at
https://github.com/freebsd/pkg/blob/master/libpkg/metalog.c , I wonder if
the sort should really happen in pkg(8) instead?

On Fri, Apr 17, 2020 at 7:28 AM Johan Hendriks 
wrote:

> Op 17-04-2020 om 13:30 schreef Johan Hendriks:
> >
> > Op 17-04-2020 om 12:47 schreef Rodney W. Grimes:
>  Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
> >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman
> >>  wrote:
> >>
> >>> So you some how had a sort core dump sitting in
> >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The
> >>> questions, how
> >>> did get there? I'd take a look at the date on the file and, it
> >>> it is older
> >>> than the buildworld, just assume that it was left-over garbage.
> >>> In either
> >>> case, you can delete it and do another installworld.
> >>>
> >>> That should most likely fix things, but, if the buildworld or
> >>> installworld
> >>> had a crash of sort(1) that left the file, further investigation
> >>> might be
> >>> needed. Re-making the zoneinfo would help track it down should
> >>> this be a re
> >>> al bug, but it's my uneducated guess that it's not.
> >>> --
> >>> Kevin Oberman, Part time kid herder and retired Network Engineer
> >>> E-mail: rkober...@gmail.com
> >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>>
> >> Please forgive that awful post! I missed a part of your message
> >> by laziness.
> >>
> >> It's odd that the error of sort(1) crashing was not caught by the
> >> script.
> > Yes, that is a Makefile flaw someplace.
> > Further there must be a wildcard being used to decide which files to
> > install, that is a further Makefile flaw.  Wildcards should NOT be
> > used
> > in the source of an install list, exactly because of this type of
> > cruft
> > that can be dropped in an obj dir.
> >>  From src/share/zoneinfo/Makefile at about line 93:
> >> 92  if make(*install*)
> >> 93  TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
> >>    this is a very bad thing to do
> >> in a Makefile.
> >>
> >> 94  .endif
> >>
> >> Now I still don't know why sort cored, but I am sure this is the line
> >> that did it.
> >>
> >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo
> >> might catch
> >> something. Looking at the core might tell you which "sort" was
> >> involved...
> >> the one you just built or the one in the base system. This could
> >> be just a
> >> FOTU, but I would not bet on it.
> > I suspect a recent zoneinfo commit as the root cause.
> >
>  I have no idea how to bypass this issue.
>  I have used sort from the latest snapshot and placed that file on the
>  system and in the build dir, but i keep getting the core
> 
>  How can i test an build and install part for zoneinfo
> 
>  If i go into the dir /usr/src/share/zoneinfo and do make install it
>  does
>  not work, do i need to add something?
> >>> Can you show us the output from
> >>> cd /usr/src/share/zoneinfo
> >>> make clean && make depend && make all && make install
> >>> Someplace in that we should get to see sort crashing...
> >>>
> > On both machines my src.conf file is the same.
> >
> > I will start over from a clean world by doing a make cleanworld and
> > see if it then still gives the errors
> > Maybe some old artifacts are hanging around.
> >
> >
> >
> >>>
>  Thank you both for your time
> 
> >> --
> >> Kevin Oberman, Part time kid herder and retired Network Engineer
> >> E-mail: rkober...@gmail.com
> >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>
> >>
> >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
> >>> 
> >>> wrote:
> >>>
>  I have a machine running FreeBSD head.
>  rev 13.0-CURRENT #11 r360008
> 
>  This is a quite powerful machine, so i thought it was a good
>  idea to let
>  that server do the build and for my virtualbox machine i can
>  use the
>  powerful machine to do a installword over NFS.
> 
>  But when i did the make installworld step the client so to say
>  gives an
>  error.
> 
>  install   -o root -g wheel -m 444
>  

Re: CFT: if_bridge performance improvements

[Xin Li]

On 4/22/20 01:45, Kristof Provost wrote:
> On 22 Apr 2020, at 10:20, Xin Li wrote:
>> Hi,
>>
>> On 4/14/20 02:51, Kristof Provost wrote:
>>> Hi,
>>>
>>> Thanks to support from The FreeBSD Foundation I’ve been able to work on
>>> improving the throughput of if_bridge.
>>> It changes the (data path) locking to use the NET_EPOCH infrastructure.
>>> Benchmarking shows substantial improvements (x5 in test setups).
>>>
>>> This work is ready for wider testing now.
>>>
>>> It’s under review here: https://reviews.freebsd.org/D24250
>>>
>>> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
>>> Patches for stable/12:
>>> https://people.freebsd.org/~kp/if_bridge/stable_12/
>>>
>>> I’m not currently aware of any panics or issues resulting from these
>>> patches.
>>
>> I have observed the following panic with latest stable/12 after applying
>> the stable_12 patchset, it appears like a race condition related NULL
>> pointer deference, but I haven't took a deeper look yet.
>>
>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>> acting as a router.  Please let me know if you need additional
>> information; I can try -CURRENT as well, but it would take some time as
>> the box is relatively slow (it's a ZFS based system so I can create a
>> separate boot environment for -CURRENT if needed, but that would take
>> some time as I might have to upgrade the packages, should there be any
>> ABI breakages).
>>
> Thanks for the report. I don’t immediately see how this could happen.
> 
> Are you running an L2 firewall on that bridge by any chance? An earlier
> version of the patch had issues with a stray unlock in that code path.

I don't think I have a L2 firewall (I assume means filtering based on
MAC address like what can be done with e.g. ipfw?  The bridges were
created on vlan interfaces though, do they count as L2 firewall?), the
system is using pf with a few NAT rules:

$ sudo pfctl -s rules
anchor "miniupnpd" all
pass in quick inet6 proto tcp from  to any flags S/SA keep state
block drop in quick inet6 proto tcp from !  to  flags S/SA
block drop in quick proto tcp from any os "Linux" to any port = ssh
pass out on igb6 inet proto tcp from (igb6) to any port = domain flags
S/SA keep state queue dns
pass out on igb6 inet proto udp from (igb6) to any port = domain keep
state queue dns
pass in on igb6 proto tcp from any to (igb6) port = http flags S/SA
modulate state queue(web, ack)
pass in on igb6 proto tcp from any to (igb6) port = https flags S/SA
modulate state queue(web, ack)
pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
state queue bulk
block drop in quick on igb6 proto tcp from  to any port = ssh
label "ssh bruteforce"
block drop in on igb6 from  to any

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: CFT: if_bridge performance improvements

[Xin Li]

Hi,

On 4/14/20 02:51, Kristof Provost wrote:
> Hi,
> 
> Thanks to support from The FreeBSD Foundation I’ve been able to work on
> improving the throughput of if_bridge.
> It changes the (data path) locking to use the NET_EPOCH infrastructure.
> Benchmarking shows substantial improvements (x5 in test setups).
> 
> This work is ready for wider testing now.
> 
> It’s under review here: https://reviews.freebsd.org/D24250
> 
> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
> Patches for stable/12: https://people.freebsd.org/~kp/if_bridge/stable_12/
> 
> I’m not currently aware of any panics or issues resulting from these
> patches.

I have observed the following panic with latest stable/12 after applying
the stable_12 patchset, it appears like a race condition related NULL
pointer deference, but I haven't took a deeper look yet.

The box have 7 igb(4) NICs, with several bridge and VLAN configured
acting as a router.  Please let me know if you need additional
information; I can try -CURRENT as well, but it would take some time as
the box is relatively slow (it's a ZFS based system so I can create a
separate boot environment for -CURRENT if needed, but that would take
some time as I might have to upgrade the packages, should there be any
ABI breakages).

===

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x20
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80c286d5
stack pointer   = 0x28:0x824cb840
frame pointer   = 0x28:0x824cb850
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (if_io_tqg_0)
trap number = 12
panic: page fault
cpuid = 0
time = 1587541913
KDB: stack backtrace:
#0 0x80c117a5 at kdb_backtrace+0x65
#1 0x80bc588e at vpanic+0x17e
#2 0x80bc5703 at panic+0x43
#3 0x810d2310 at trap_pfault+0
#4 0x810d235f at trap_pfault+0x4f
#5 0x810d19b8 at trap+0x288
#6 0x810aae1c at calltrap+0x8
#7 0x80ba5c96 at __mtx_unlock_sleep+0xb6
#8 0x8248f4c7 at bridge_input+0x877
#9 0x80cd5c47 at ether_nh_input+0x207
#10 0x80cf1e4a at netisr_dispatch_src+0xca
#11 0x80cd4f0b at ether_input+0x4b
#12 0x80cdf1a3 at vlan_input+0x1f3
#13 0x80cd4ae1 at ether_demux+0x121
#14 0x80cd5d7b at ether_nh_input+0x33b
#15 0x80cf1e4a at netisr_dispatch_src+0xca
#16 0x80cd4f0b at ether_input+0x4b
#17 0x80cee41c at iflib_rxeof+0xadc
Uptime: 6m6s
Dumping 848 out of 16313
MB:..2%..12%..21%..31%..42%..51%..61%..72%..82%..91%


Backtrace:

(kgdb) #0  doadump () at src/sys/amd64/include/pcpu_aux.h:55
#1  0x80bc54a5 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:451
#2  0x80bc58e6 in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:880
#3  0x80bc5703 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:807
#4  0x810d2310 in trap_fatal (frame=,
eva=) at /usr/src/sys/amd64/amd64/trap.c:925
#5  0x810d235f in trap_pfault (frame=0x824cb780,
usermode=, signo=,
ucode=) at src/sys/amd64/include/pcpu_aux.h:55
#6  0x810d19b8 in trap (frame=0x824cb780)
at /usr/src/sys/amd64/amd64/trap.c:407
#7  0x810aae1c in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:289
#8  0x80c286d5 in turnstile_broadcast (ts=0x0, queue=0)
at /usr/src/sys/kern/subr_turnstile.c:880
#9  0x80ba5c96 in __mtx_unlock_sleep (c=0xf80013351430, v=0)
at /usr/src/sys/kern/kern_mutex.c:1041
#10 0x8248f4c7 in bridge_input (ifp=,
m=) at src/sys/amd64/include/atomic.h:221
#11 0x80cd5c47 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:631
#12 0x80cf1e4a in netisr_dispatch_src (proto=5,
source=, m=)
at /usr/src/sys/net/netisr.c:1124
#13 0x80cd4f0b in ether_input (ifp=0xf800060dc000, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:787
#14 0x80cdf1a3 in vlan_input (ifp=0xf800036d6800,
m=0xf8001d65fc00) at /usr/src/sys/net/if_vlan.c:1291
#15 0x80cd4ae1 in ether_demux (ifp=0xf800036d6800,
m=) at /usr/src/sys/net/if_ethersubr.c:832
#16 0x80cd5d7b in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:667
#17 0x80cf1e4a in netisr_dispatch_src (proto=5,
source=, m=)
at /usr/src/sys/net/netisr.c:1124
#18 0x80cd4f0b in ether_input (ifp=0xf800036d6800,
m=0xf80013939c00) at /usr/src/sys/net/if_ethersubr.c:787
#19 0x80cee41c in iflib_rxeof (rxq=,
budget=) at /usr/src/sys/net/iflib.c:2873
#20 0x80ce87b3 in _task_fn_rx (context=0xf800036d6000)
at 

ThinkPad: reboots after successful shutdown -p

[Xin Li]

Hi,

I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
system would shut down and seemingly powered off, then it would restart
after about 5-10 seconds.

Is this a known issue?  Arguably this is not necessarily a FreeBSD
issue, but it seems that the Windows 10 installation doesn't have the
problem, so I guess there might be some difference between our and
Windows's shutdown sequence.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: DRM-current-kmod is still a problem at r353339

[Xin LI]

Have you patched with mjg@'s pmap-fict-invl.diff?  The panic seems to be
similar...

Cheers,

On Fri, Oct 18, 2019 at 2:01 AM Neel Chauhan  wrote:

> This still panicks for me, but with a different error.
>
> https://i.postimg.cc/K8nxF57G/IMG-20191018-045338.jpg
>
> I really should be sleeping but can't because I have to use an older
> kernel to have working graphics. Thanks, Netflix for making my life
> harder.
>
> -Neel
>
> On 2019-10-18 01:01, Xin Li wrote:
> > Another (semi-fixed!) data point -- I can confirm that with if
> > (vm_page_sleep_if_busy(page, "linuxkpi"))
> >  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
> > mjg@'s earlier patch at
> > https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it)
> > ,
> > the latest drm-v5.0 branch of drm-current-kmod worked just fine with
> > Intel HD Graphics P630 on Lenovo P51.
> >
> > On 2019-10-17 18:37, Neel Chauhan wrote:
> >> However, the patch to drm-kmod doesn't work for me. I tried both
> >> drm-devel-kmod and drm-current-kmod.
> >>
> >> https://i.imgur.com/81JvaOO.jpg
> >>
> >> -Neel
> >>
> >> ===
> >>
> >> https://www.neelc.org/
> >>
> >> On 2019-10-17 17:35, Eirik Øverby wrote:
> >>> On 10/17/19 11:29 PM, Eirik Øverby wrote:
> >>>> On 10/17/19 10:31 PM, Niclas Zeising wrote:
> >>>>> On 2019-10-17 21:53, ma...@freebsd.org wrote:
> >>>>>> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
> >>> ..
> >>>>>> I believe it was the recent work on the vm page busy state,
> >>>>>> r353539
> >>>>>> specifically.  This patch should fix it; we don't yet have a
> >>>>>> __FreeBSD_version number bump on which to gate the patch.
> >>> ...>>
> >>>>> Hi!
> >>>>> Hopefully someone can confirm that this patch to drm-current-kmod
> >>>>> or
> >>>>> drm-devel-kmod fixes the issue.  I won't be able to work on this
> >>>>> before the weekend at the earliest, I'm afraid.
> >>>>> Mark, is it possible to get a belated version bump for this fix,
> >>>>> and
> >>>>> what changed to require it?
> >>>>
> >>>> Built, rebooting ... Will hopefully check back in soon.
> >>>
> >>> And tada, I'm back. That seemed to do the trick. Thanks!
> >>>
> >>> /Eirik
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to
> >>> "freebsd-current-unsubscr...@freebsd.org"
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to
> >> "freebsd-current-unsubscr...@freebsd.org"
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited

[Xin Li]

I have seen this on boot of my laptop.

It appears that in6_joingroup() was called in netisr_dispatch_src
codepath, and it tried to acquire IN6_MULTI_LOCK(), which happened to
sleep because we failed to acquire the sx, thus triggered the panic.

===

panic: sleepq_add: td 0xf8000ecd6000 to sleep on wchan
0x81dedfe0 with sleeping prohibited


#1  0x80bbff90 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:479
#2  0x80bc03e6 in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:908
#3  0x80bc0143 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:835
#4  0x80c1a2bf in sleepq_add (wchan=0x81dedfe0, lock=0x0,
wmesg=0x8110f331 "in6_multi_sx", flags=3, queue=0)
at /usr/src/sys/kern/subr_sleepqueue.c:318
#5  0x80bc9ce4 in _sx_xlock_hard (sx=0x81dedfe0,
x=18446735277856440320, opts=,
file=, line=)
at /usr/src/sys/kern/kern_sx.c:841
#6  0x80bc983f in _sx_xlock (sx=0x81dedfe0, opts=0,
file=0x8113a568 "/usr/src/sys/netinet6/in6_mcast.c", line=1185)
at /usr/src/sys/kern/kern_sx.c:325
#7  0x80e17dd1 in in6_joingroup (ifp=0xf80003b99800,
mcaddr=0xfe00e1612e58, imf=,
pinm=0xf80019e17300, delay=2) at
/usr/src/sys/netinet6/in6_mcast.c:1185
#8  0x80e0fa72 in in6_update_ifa (ifp=0xf80003b99800,
ifra=, ia=,
flags=) at /usr/src/sys/netinet6/in6.c:752
#9  0x80e374c5 in nd6_ra_input (m=0xf800191d4a00,
off=, icmp6len=)
at /usr/src/sys/netinet6/nd6_rtr.c:2274
#10 0x80e096d5 in icmp6_input (mp=,
offp=0xfe00e161335c, proto=)
at /usr/src/sys/netinet6/icmp6.c:767
#11 0x80e22dff in ip6_input (m=0xf800191d4a00)
at /usr/src/sys/netinet6/ip6_input.c:963
#12 0x80ceff11 in netisr_dispatch_src (proto=6, source=0,
m=0xf800191d4a00) at /usr/src/sys/net/netisr.c:1127
#13 0x80cd399e in ether_demux (ifp=0xf80003b99800,
m=) at /usr/src/sys/net/if_ethersubr.c:916
#14 0x80cd4f88 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:705
#15 0x80ceff11 in netisr_dispatch_src (proto=5, source=0,
m=0xf800191d4a00) at /usr/src/sys/net/netisr.c:1127
#16 0x80cd3e8d in ether_input (ifp=0xf8000397a800, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:824
#17 0x80d429f0 in sta_input (ni=,
m=0xf800191d4a00, rxs=,
rssi=, nf=)
at /usr/src/sys/net80211/ieee80211_sta.c:891
#18 0x80d1ec2a in ieee80211_input_mimo (ni=0xfe0106c66000,
m=0xf800191d4a00) at /usr/src/sys/net80211/ieee80211_input.c:101
#19 0x848e55a2 in iwm_mvm_rx_rx_mpdu (sc=0xfe00e2c0,
m=0xf800191d4a00, offset=,
stolen=) at /usr/src/sys/dev/iwm/if_iwm.c:3245
#20 0x848e3fee in iwm_intr (arg=)
at /usr/src/sys/dev/iwm/if_iwm.c:5151



signature.asc
Description: OpenPGP digital signature

Re: DRM-current-kmod is still a problem at r353339

[Xin Li]

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
 -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.

On 2019-10-17 18:37, Neel Chauhan wrote:
> However, the patch to drm-kmod doesn't work for me. I tried both
> drm-devel-kmod and drm-current-kmod.
> 
> https://i.imgur.com/81JvaOO.jpg
> 
> -Neel
> 
> ===
> 
> https://www.neelc.org/
> 
> On 2019-10-17 17:35, Eirik Øverby wrote:
>> On 10/17/19 11:29 PM, Eirik Øverby wrote:
>>> On 10/17/19 10:31 PM, Niclas Zeising wrote:
 On 2019-10-17 21:53, ma...@freebsd.org wrote:
> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
>> ..
> I believe it was the recent work on the vm page busy state, r353539
> specifically.  This patch should fix it; we don't yet have a
> __FreeBSD_version number bump on which to gate the patch.
>> ...>>
 Hi!
 Hopefully someone can confirm that this patch to drm-current-kmod or
 drm-devel-kmod fixes the issue.  I won't be able to work on this
 before the weekend at the earliest, I'm afraid.
 Mark, is it possible to get a belated version bump for this fix, and
 what changed to require it?
>>>
>>> Built, rebooting ... Will hopefully check back in soon.
>>
>> And tada, I'm back. That seemed to do the trick. Thanks!
>>
>> /Eirik
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[Xin LI]

On Mon, May 27, 2019 at 7:08 AM  wrote:

> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
>
> The patch attached for the bug is for disabling these options by
> default, following a few reasons which I'm going to list here:
>  - Keeping support for deprecated libraries isn't exactly the best we
> could do to avoid security issues (if there are any) as I'm sure nobody
> wants to spend that much time maintaining such stuff (it's enough to
> think about misc/compat4x in the ports tree: that version of FreeBSD was
> released on March 2000 and keeping 19 years old libraries around isn't
> ideal)
>

To accomplish this goal, a prerequisite would be to remove libc.a (possibly
also libthr.a as well as anything that makes a direct system call).  I'd
rather see that happen first.


>  - Devs should get track of time and realize that developing software
> using unsupported libraries is NOT something that you should do
>  - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
> if the software won't compile without the legacy components (and has a
> replacement of some kind), considering removal wouldn't be a bad idea
>  - This is on by default: most users don't care or don't use binaries
> that old
>

> I don't see any practical reason to keep these options on by default,
> but I do appreciate any sort of input regarding this issue.
>

Because users would find a way (e.g. by not upgrading) which further
undermines their security?  I know quite some Windows users would disable
Windows Update for the exact same reason, if you break backward
compatibility, your credibility is broken and it is much harder to regain
the trust.

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

Re: newfs silently fails if random is not ready (?)

[Xin Li]

On 9/4/18 21:39, Conrad Meyer wrote:
> With current libc, I instead see:
> 
> load: 0.10  cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s
> 0% 2328k (SIGINFO)
> 
> $ procstat -kk 1668
>   PIDTID COMMTDNAME  KSTACK
>  1668 100609 blocked_random_poc  -   mi_switch+0xd3
> sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272
> read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940
> fast_syscall_common+0x101
> 
> and:
> 
> $ truss ./blocked_random_poc
> ...
> getrandom(0x7fffd340,40,0)   ERR#35 'Resource
> temporarily unavailable'
> thr_self(0x7fffd310) = 0 (0x0)
> thr_kill(100609,SIGKILL) = 0 (0x0)
> SIGNAL 9 (SIGKILL) code=SI_NOINFO
> 
> So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN
> after we have already slept until random was seeded.  This bubbles up
> to getentropy(3) -> arc4random(3), which sees a surprising failure
> from getentropy(3) and raises KILL against the program.
> 
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition.  This may be sufficient to fix the problem:
> 
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
> error = tsleep(_alg_context, PCATCH, "randseed", 
> hz/10);
> if (error == ERESTART || error == EINTR)
> break;
> +   /* Squash hz/10 timeout condition */
> +   if (error == EWOULDBLOCK)
> +   error = 0;
> +   KASSERT(error == 0, ("unexpected %d", error));
> }
> if (error == 0) {
> read_rate_increment((uio->uio_resid +
> sizeof(uint32_t))/sizeof(uint32_t));

+markm, re

I think the proposed change is reasonable (note that I think the same
theory applies to the tsleep_sbt() case below as well, which should be
handled similarly).

> Best,
> Conrad
> 
> 
> On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer  wrote:
>> Hi Lev,
>>
>> I took a first attempt at reproducing this problem on a fast
>> desktop-class system.  First steps, give us a way to revert back to
>> unseeded status:
>>
>> --- a/sys/dev/random/fortuna.c
>> +++ b/sys/dev/random/fortuna.c
>> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>>
>>  #ifdef _KERNEL
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>> return;
>> }
>>
>> +   /*
>> +* When set, pretend we do not have enough entropy to reseed yet.
>> +*/
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
>> +   if (RETURN_VALUE != 0) {
>> +   RANDOM_RESEED_UNLOCK();
>> +   return;
>> +   }
>> +   });
>> +
>> +
>>  #ifdef _KERNEL
>> fortuna_state.fs_lasttime = now;
>>  #endif
>> @@ -442,5 +454,11 @@ bool
>>  random_fortuna_seeded(void)
>>  {
>>
>> +   /* When set, act as if we are not seeded. */
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
>> +   if (RETURN_VALUE != 0)
>> +   fortuna_state.fs_counter = UINT128_ZERO;
>> +   });
>> +
>> return (!uint128_is_zero(fortuna_state.fs_counter));
>>  }
>>
>>
>> Second step, enable the failpoints and launch repro program:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
>> debug.fail_point.random_fortuna_pre_read: off -> return(1)
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
>> debug.fail_point.random_fortuna_seeded: off -> return(1)
>>
>> $ cat ./blocked_random_poc.c
>> #include 
>> #include 
>> #include 
>>
>> int
>> main(int argc, char **argv)
>> {
>> printf("%x\n", arc4random());
>> return (0);
>> }
>>
>>
>> $ ./blocked_random_poc
>> ...
>>
>>
>> Third step, I looked at what that process was doing:
>>
>> Curiously, it is not in getrandom() at all, but instead the ARND
>> sysctl fallback.  I probably need to rebuild world (libc) to test this
>> (new libc arc4random based on Chacha).
>>
>> $ procstat -kk 1196
>>   PIDTID COMMTDNAME  KSTACK
>>  1196 100435 blocked_random_poc  -   read_random+0x3d
>> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
>> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
>> amd64_syscall+0x940 fast_syscall_common+0x101
>>
>>
>> When I unblocked the failpoints, it completed successfully:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
>> debug.fail_point.random_fortuna_pre_read: return(1) -> off
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
>> debug.fail_point.random_fortuna_seeded: return(1) -> off
>>
>> ...
>> 9e5eb30f
>>
>>
>> Best,
>> Conrad




signature.asc
Description: OpenPGP digital signature

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Xin LI]

On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
>
> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> > This was caused by r337852, but I didn't investigated further.
> >
> > The problem is that we have a source file called 'moduli.c' in
> > crypto/openssh/ while the build target was moduli, and bmake seen
> > 'moduli' in source tree as older than moduli.c, and decided to rebuild
> > it from source, while the two files are unrelated.
>
> Hi Xin,
>
> I don't see how that could be the case as I didn't move the file around, I 
> just moved how it gets installed.
>
> I have done many many builds with this change in and haven't seen this 
> problem..

Yeah, let me rephrase: this might have been exposed by r337852; I
don't think your change itself really caused or should have caused
problem, but my theory based on what we have observed was that it
might have exposed a bug where either bmake itself, or some .mk files
might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
(haven't traced that part down yet).

The most scaring part is that the build system seems to trying
building crypto/openssh/moduli because moduli.c was newer, and the
file was deleted as part of the rebuild; should moduli.c compile by
its own, we would end up with a binary moduli file.

I'll take another look tonight if I had some time.

>
>
> Regards,
> Brad Davis
>
> > On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  
> > wrote:
> > >
> > > Running:
> > >
> > > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> > > r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> > > amd64
> > >
> > > after updating working copy to r337903, I'm seeing:
> > >
> > > ...
> > > >>> stage 4.3: building everything
> > > ...
> > > --- ifconfig_make ---
> > > Building 
> > > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> > > --- all_subdir_secure ---
> > > --- moduli ---
> > > /usr/bin/ld: error: undefined symbol: main
> > > >>> referenced by crt1.c
> > > >>>   
> > > >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> > > /usr/bin/ld: error: undefined symbol: Fssh_error
> > > 
> > > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > > .ERROR_TARGET='moduli'
> > > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> > > .MAKE.LEVEL='5'
> > > MAKEFILE=''
> > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> > > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> > > --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> > > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> > > -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> > > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> > > -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> > > -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> > > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> > > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> > > -Wno-enum-conversion -Wno-unused-local-typedef 
> > > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
> > > -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments   
> > > -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> > > /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> > > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > > .MAKE='make'
> > > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> > > .TARGETS='all'
> > > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > > 
> > >
> > > (on both the laptop and the build machine).
> > >
> > > I have copied the .ERROR_META_FILE to
> > > <http://www.catwhisker.org/~david/FreeBSD/head/r337903/moduli.meta and
> > > a typescript of the attempted build to
> > > <http://www.catwhisker.org/~david/FreeBSD/head/r337903/typescript>.
> > >
> > > Additional information (previous day's verbose dmesg.bot, etc.) may
> > > be found at <http://www.catwhisker.org/~david/FreeBSD/history/>.
> > >
> > > Peace,
> > > david
> > > --
> > > David H. Wolfskill  da...@catwhisker.org
> > > Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
> > >
> > > See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Xin LI]

This was caused by r337852, but I didn't investigated further.

The problem is that we have a source file called 'moduli.c' in
crypto/openssh/ while the build target was moduli, and bmake seen
'moduli' in source tree as older than moduli.c, and decided to rebuild
it from source, while the two files are unrelated.

Cheers,
On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  wrote:
>
> Running:
>
> FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> after updating working copy to r337903, I'm seeing:
>
> ...
> >>> stage 4.3: building everything
> ...
> --- ifconfig_make ---
> Building 
> /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> --- all_subdir_secure ---
> --- moduli ---
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c
> >>>   
> >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> /usr/bin/ld: error: undefined symbol: Fssh_error
> 
> make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> .ERROR_TARGET='moduli'
> .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
> -Qunused-arguments   -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> .CURDIR='/usr/src/secure/usr.sbin/sshd'
> .MAKE='make'
> .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> .TARGETS='all'
> DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> 
>
> (on both the laptop and the build machine).
>
> I have copied the .ERROR_META_FILE to
>  a typescript of the attempted build to
> .
>
> Additional information (previous day's verbose dmesg.bot, etc.) may
> be found at .
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: post ino64: lockd no runs?

[Xin LI]

On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin  wrote:
> On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
>> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
>> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
>> > of my systems after a full rebuild of src and ports. No log entries
>> > offer any insight as to why :-(
>> >
>> > imb
>>
>> I don't tend to use NFS on my systems that are running head, so I
>> haven't had occasion to test this as stated.
>>
>> However, I just completed my weekly update of the "prooduction" systems
>> here at home, running stable/11.  And I find that lockd seems to be ...
>> claiming that all is well, but declining to run (for long).
>>
>> To the best of my knowledge, that was not the case until this last
>> update, which was from:
>>
>> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316  
>> r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> to
>>
>> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  
>> r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> The "glaringly obvious" symptom in my case is that I am now unable
>> to (directly) save an email message from within mutt(1) by appending
>> it to an NFS-resident file.  (Saving it to a local file, then using
>> cat(1) to append that to the NFS- resident file & removing the local
>> copy works)
>>
>> After a few variations on a theme of:
>>
>> albert(11.1)[5] sudo service lockd restart
>> lockd not running?
>> Starting lockd.
>> albert(11.1)[6] echo $?
>> 0
>> albert(11.1)[7] service lockd status
>> lockd is not running.
>>
>> I finally(!) thought to ask ktrace what's going on (as tailing
>> /var/log/messages was completely unproductive, even after enabling
>> rc_debug).
>>
>> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
>> the output of kdump(1), I see that the trace ends with:
>>
>>   ...
>>   2811 rpc.lockd NAMI  "/var/run/logpriv"
>>   2786 sh   CALL  read(0xa,0x627fc0,0x400)
>>   2786 sh   GIO   fd 10 read 0 bytes
>>""
>>   2811 rpc.lockd RET   connect 0
>>   2786 sh   RET   read 0
>>   2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
>>   2786 sh   CALL  exit(0)
>>   2811 rpc.lockd GIO   fd 3 wrote 39 bytes
>>"<30>Jun 11 15:43:10 rpc.lockd: Starting"
>>   2811 rpc.lockd RET   sendto 39/0x27
>>   2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
>>   2811 rpc.lockd RET   sigaction 0
>>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
>>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
>
> This is a really good clue.  nlm_syscall is dying with EFAULT.  The last
> argument is a pointer to an array of char * pointers, and the only way
> I can see it dying is if it fails to copyin() one of the strings pointed
> to by those pointers.  You could try running rpc.lockd under gdb from
> ports and setting a breakpoint on 'nlm_syscall' and then printing out
> 'addr_count' and 'p addrs@(addr_count * 2)'.

Yes, I found that the kernel was trying to copyin() from NULL, and
then found that corresponds to 'uaddr'.  After some tracing I found
that the tightened condition for taddr2uaddr have enforced (correctly)
buffer length passed from caller, which was not set correctly since ~9
years ago (r177633, which sets the size to sizeof(pointer)) but never
gets noticed because there is no check on that, so the solution seems
to be to correctly set the length values to (allocated size), and that
have fixed the issue for me.

The code could use some cleanups and I plan to do it at some later time.

> Unfortunately I'm not able to reproduce the failure on a test machine
> I have running head post-ino64.

This should have been fixed by r319852 in -HEAD (
https://svnweb.freebsd.org/base?view=revision=319852 ), and
I'll MFC the change after 3 days' settle  assuming there is no
objections, as this is a regression.

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

Re: Build fails in libpcap with WITHOUT_INET6

[Xin LI]

Thanks for reporting.  I have applied a fix as r316125.

On Tue, Mar 28, 2017 at 9:31 AM, Randy Westlund  wrote:
> Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 set fails
> in libpcap:
>
>> --- klm_prot_xdr.pico ---
>> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs
>> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free
>> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O
>> -pipe   -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg
>> ra/freebsd/tmp/usr/include/rpcsvc -MD  -MF.depend.klm_prot_xdr.pico -MTklm_pr
>> ot_xdr.pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-
>> body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compar
>> e -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-
>> conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switc
>> h -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arg
>> uments  -c klm_prot_xdr.c -o klm_prot_xdr.pico
>> --- all_subdir_lib/libpcap ---
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:695:9: error: no memb
>> er named 'ai' in 'struct _compiler_state'
>> cstate.ai = NULL;
>> ~~ ^
>> --- all_subdir_lib/librpcsvc ---
>> --- mount_xdr.pico ---
>> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs
>> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free
>> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O
>> -pipe   -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg
>> ra/freebsd/tmp/usr/include/rpcsvc -MD  -MF.depend.mount_xdr.pico -MTmount_xdr
>> .pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -
>> Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno
>> -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conver
>> sion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno
>> -switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments
>>   -c mount_xdr.c -o mount_xdr.pico
>> --- all_subdir_lib/libpcap ---
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4916:13: error: use o
>> f undeclared identifier 'cstate'
>> bpf_error(cstate, "direction applied to 'gateway'");
>>   ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4923:11: error: use o
>> f undeclared identifier 'cstate'
>> switch (cstate->linktype) {
>> ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4961:17: error: use o
>> f undeclared identifier 'cstate'
>> b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR, Q_H
>> OST);
>>   ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4963:19: error: use o
>> f undeclared identifier 'cstate'
>> tmp = gen_host(cstate, **alist++, 0x, proto,
>> Q_OR,
>>^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4972:12: error: use o
>> f undeclared identifier 'cstate'
>> bpf_error(cstate, "illegal modifier of 'gateway'");
>>   ^
>> 6 errors generated.
>> *** [gencode.o] Error code 1
>>
>> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap
>> 1 error
>>
>> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap
>> *** [all_subdir_lib/libpcap] Error code 2
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

[Xin LI]

On Thu, Feb 2, 2017 at 1:28 PM, Bruno Lauzé <brunola...@msn.com> wrote:
>
>
> But a simple user with no rights can mlock (64kb by default) why a jail would 
> not be able?
>

No, I'm not, by any means, arguing against having jailed processes
being able to mlock(), I'm just saying that we should have more fine
grained control over it (a knob to allow system administrators to
tweak it would be a good start).

Cheers,

>
> From: Xin LI<mailto:delp...@gmail.com>
> Sent: Thursday, February 2, 2017 1:13 PM
> To: Pavel Timofeev<mailto:tim...@gmail.com>
> Cc: Bruno Lauzé<mailto:brunola...@msn.com>; 
> freebsd-current<mailto:freebsd-current@freebsd.org>
> Subject: Re: mlock and jail
>
>
>
> On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote:
>> 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>:
>>> I like this idea.
>>>
>>> Note that potentially your patch would make it possible for a jailed
>>> root to DoS the whole system by locking too much of pages in memory.
>>> I think it would be sensible to provide a per-jail flag to enable
>>> doing it, or better, have some finer grained control (e.g. per jail
>>> quota of permitted locked pages).
>>>
>>> Why did the application want to lock pages in main memory, though?
>>
>> For example, this secret management tool
>> https://www.vaultproject.io/docs/config/ wants to lock memory for
>> security (surprise) reason.
>> It's available as security/vault in our ports tree.
>
> No it's not surprise but overkill IMHO.  Here is why:
>
> Locking memory does prevent swapping, but in a typical multi-user
> system, if an attacker is already able to read swap (keep in mind that
> disks are by default owned by root and can not be read in a typical
> setup), then the administrator already have much bigger problem to
> worry about, and the attacker would have much more powerful tools to
> steal the secrets.
>
> Additionally, if one really cares about safety of swap, they should
> have used encrypted swap in the first place.  On FreeBSD, appending
> '.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
> /dev/ada0p3.eli) would automatically do one-time keyed swapping.
>
> Moreover, I don't think it's a good idea to use an application that
> advocates locking all memory that it owns for "security" reasons: if
> the application writer does not know which memory pages would contain
> sensitive information, good chances that the application writer have
> no idea what is privilege separation and the design they have created
> could be fundamentally flawed.
>
> Cheers,
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

[Xin LI]

On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote:
> 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>:
>> I like this idea.
>>
>> Note that potentially your patch would make it possible for a jailed
>> root to DoS the whole system by locking too much of pages in memory.
>> I think it would be sensible to provide a per-jail flag to enable
>> doing it, or better, have some finer grained control (e.g. per jail
>> quota of permitted locked pages).
>>
>> Why did the application want to lock pages in main memory, though?
>
> For example, this secret management tool
> https://www.vaultproject.io/docs/config/ wants to lock memory for
> security (surprise) reason.
> It's available as security/vault in our ports tree.

No it's not surprise but overkill IMHO.  Here is why:

Locking memory does prevent swapping, but in a typical multi-user
system, if an attacker is already able to read swap (keep in mind that
disks are by default owned by root and can not be read in a typical
setup), then the administrator already have much bigger problem to
worry about, and the attacker would have much more powerful tools to
steal the secrets.

Additionally, if one really cares about safety of swap, they should
have used encrypted swap in the first place.  On FreeBSD, appending
'.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
/dev/ada0p3.eli) would automatically do one-time keyed swapping.

Moreover, I don't think it's a good idea to use an application that
advocates locking all memory that it owns for "security" reasons: if
the application writer does not know which memory pages would contain
sensitive information, good chances that the application writer have
no idea what is privilege separation and the design they have created
could be fundamentally flawed.

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

Re: mlock and jail

[Xin LI]

I like this idea.

Note that potentially your patch would make it possible for a jailed
root to DoS the whole system by locking too much of pages in memory.
I think it would be sensible to provide a per-jail flag to enable
doing it, or better, have some finer grained control (e.g. per jail
quota of permitted locked pages).

Why did the application want to lock pages in main memory, though?

On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé  wrote:
>
> I would like to ask if there is a reason I would have to applythe  patch 
> below to make an application work in a jail.
> And who's bad? the app too intrusive or the bsd not flexible enough 
> (allow.mlock?)
>
>
> Index: sys/kern/kern_jail.c
> ===
> --- sys/kern/kern_jail.c(revision 313033)
> +++ sys/kern/kern_jail.c(working copy)
> @@ -3340,6 +3340,11 @@
> case PRIV_PROC_SETLOGINCLASS:
> return (0);
>
>
> +case PRIV_VM_MADV_PROTECT:
> +case PRIV_VM_MLOCK:
> +case PRIV_VM_MUNLOCK:
> +return (0);
> +
> default:
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic with some recent changes (between r309016 and r309184)

[Xin Li]

Is this known?

The traceback:

panic: vm_page_assert_xbusied: page 0xf807fae225b0 not exclusive
busy @ /usr/src/sys/vm/vm_pager.c:263
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0a528ea620
vpanic() at vpanic+0x186/frame 0xfe0a528ea6a0
kassert_panic() at kassert_panic+0x126/frame 0xfe0a528ea710
vm_pager_assert_in() at vm_pager_assert_in+0x6f/frame 0xfe0a528ea740
vm_pager_get_pages_async() at vm_pager_get_pages_async+0x26/frame
0xfe0a528ea780
vn_sendfile() at vn_sendfile+0xc85/frame 0xfe0a528ea9e0
sys_sendfile() at sys_sendfile+0x11a/frame 0xfe0a528eaa70
amd64_syscall() at amd64_syscall+0x2f9/frame 0xfe0a528eabf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0a528eabf0
--- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x8040eb47a, rsp =
0x7fffea58, rbp = 0x7fffeb00 ---
KDB: enter: panic


Cheers,



signature.asc
Description: OpenPGP digital signature

EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

[Xin Li]

Hi,

I finally got some time to explore the UEFI boot process (kudos to
everyone who made this work!) and getting myself familiarize with the
basics.

One quick question -- Is there some technical restriction that prevents
us from merging boot1.efi and loader.efi into one binary?

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD_HEAD_i386 - Build #3460 - Failure

[Xin Li]

My bad.  Proposed fix would be:

Index: lib/libmagic/Makefile
===
--- lib/libmagic/Makefile   (revision 302221)
+++ lib/libmagic/Makefile   (working copy)
@@ -19,7 +19,7 @@ INCS= magic.h
 MAGICPATH?=/usr/share/misc

 CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DHAVE_CONFIG_H
-CFLAGS+= -I${.CURDIR} -I${CONTRDIR}/src
+CFLAGS+= -I${.CURDIR} -I${.OBJDIR} -I${CONTRDIR}/src

 WARNS?=3

@@ -40,8 +40,8 @@ magic.mgc: mkmagic magic

 CLEANFILES+=   mkmagic
 build-tools: mkmagic
-mkmagic: apprentice.c cdf_time.c encoding.c funcs.c magic.c print.c
${BUILD_TOOLS_META}
-   ${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC} \
+mkmagic: apprentice.c cdf_time.c encoding.c funcs.c magic.c print.c
${INCS} ${BUILD_TOOLS_META}
+   ${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC:N*.h} 
\
${LDADD}

 FILEVER!= awk '$$1 == "\#define" && $$2 == "VERSION" { print $$3; exit }' \

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Xin Li]

On 6/8/16 23:10, Craig Rodrigues wrote:
> Hi,
> 
> I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> current.
> 
> In latest current, it should be possible to put in /etc/rc.conf:
> 
> nis_ypldap_enable="YES"
> to activate the ypldap daemon.
> 
> When set up properly, it should be possible to log into FreeBSD, and have
> the backend password database come from an LDAP database such
> as OpenLDAP
> 
> There is some documentation for setting this up, but it is OpenBSD specific:
> 
> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> http://puffysecurity.com/wiki/ypldap.html#2
> 
> I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> information
> does not apply.  I figure that openldap from ports should work fine.
> 
> I was wondering if there is someone out there familiar enough with LDAP
> and has a setup they can test this stuff out with, provide feedback, and
> help
> improve the documentation for FreeBSD?

Looks like it would be a fun weekend project.  I've cc'ed a potential
person who may be interested in this as well.

But will this worth the effort? (I think the current implementation
would do everything with plaintext protocol over wire, so while it
extends life for legacy applications that are still using NIS/YP, it
doesn't seem to be something that we should recommend end user to use?)

> I would also be interested in hearing from someone who can see if
> ypldap can work against a Microsoft Active Directory setup?

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: [zfs] Cache on SD stops working after updating to 11-CURRENT r291458 amd64

[Xin Li]

Please subscribe:

https://bugs.freebsd.org/205882

You can locally apply -r292066 or modify the code to skip the check when
pguid is 0 as a stopgap.

Cheers,



signature.asc
Description: OpenPGP digital signature

HEADSUP: Memory corruption issue with ZFS users using L2ARC [Fwd: svn commit: r287283 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]

[Xin Li]

Hi,

Please note that -CURRENT in revision range of [r286951, 287283),
approximately 9 days ago until now, are affected by a buffer overrun
issue that may cause data corruption (!) which may manifest itself as
random panics that relates to NULL pointer deference (e.g. Kernel Trap
12 with 4K fault address), or strange UMA related panics.

Systems that do not have L2ARC devices are not affected by this problem.
 The affected code is L2ARC specific.

For those who are using L2ARC devices -- it's not clear to me how bad
the corruption could affect the on disk data for ZFS.  If you are
running -CURRENT and have L2ARC, please be sure to examine if you have
any data loss.

Cheers,


 Forwarded Message 
Subject: svn commit: r287283 -
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Date: Sat, 29 Aug 2015 09:22:33 + (UTC)
From: Xin LI delp...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org

Author: delphij
Date: Sat Aug 29 09:22:32 2015
New Revision: 287283
URL: https://svnweb.freebsd.org/changeset/base/287283

Log:
  Fix a buffer overrun which may lead to data corruption, introduced in
  r286951 by reinstating changes in r274628.

  In l2arc_compress_buf(), we allocate a buffer to stash away the compressed
  data in 'cdata', allocated of l2hdr-b_asize bytes.

  We then ask zio_compress_data() to compress the buffer,
b_l1hdr.b_tmp_cdata,
  which is of l2hdr-b_asize bytes, and have the compressed size (or
original
  size, if compress didn't gain enough) stored in csize.

  To pad the buffer to fit the optimal write size, we round up the
compressed
  size to L2 device's vdev_ashift.

  Illumos code rounds up the size by at most SPA_MINBLOCKSIZE.  Because we
  know csize = b_asize, and b_asize is integer multiple of
SPA_MINBLOCKSIZE,
  we are guaranteed that the rounded up csize would be = b_asize. However,
  this is not necessarily true when we round up to 1  vdev_ashift, because
  it could be larger than SPA_MINBLOCKSIZE.

  So, in the worst case scenario, we are overwriting at most

(1  vdev_ashift - SPA_MINBLOCKSIZE)

  bytes of memory next to the compressed data buffer.

  Andriy's original change in r274628 reorganized the code a little bit,
  by moving the padding to after we determined that the compression was
  beneficial.  At which point, we would check rounded size against the
  allocated buffer size, and the buffer overrun would not be possible.

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


Cheers,



signature.asc
Description: OpenPGP digital signature

Re: Read-only /usr/obj/ no longer kosher?

[Xin Li]

On 08/25/15 14:55, Pawel Jakub Dawidek wrote:
 Now that I think of it, it might have been that I did
 buildworld/buildkernel before -p1. Then freebsd-update updated
 newvers.sh and then I was trying to do installworld.
 
 Yes, I can now reproduce it with source updated to -p2.

Yes, that's because freebsd-version.sh is generated from the files (but
it's not clear to me whether if it's a bug or a feature that 'make
install' checks if it's up-to-date and decides to regenerate it...).

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die



signature.asc
Description: OpenPGP digital signature

Re: Read-only /usr/obj/ no longer kosher?

[Xin Li]

On 8/23/15 14:55, Pawel Jakub Dawidek wrote:
 I used to build world and kernel on one machine and export both /usr/src/ and
 /usr/obj read-only to other machines. It doesn't work anymore (this is from
 'make installworld'):
 
 === bin/freebsd-version (install)
 eval $(egrep '^(TYPE|REVISION|BRANCH)=' 
 /usr/src/bin/freebsd-version/../../sys/conf/newvers.sh) ;  if ! sed -e  
 s/@@TYPE@@/${TYPE}/g;  s/@@REVISION@@/${REVISION}/g;  
 s/@@BRANCH@@/${BRANCH}/g;   
 /usr/src/bin/freebsd-version/freebsd-version.sh.in freebsd-version.sh ; then 
  rm -f freebsd-version.sh ;  exit 1 ;  fi
 cannot create freebsd-version.sh: Permission denied
 rm: freebsd-version.sh: Read-only file system
 *** Error code 1

What's the modification times of
/usr/obj/usr/bin/freebsd-version/freebsd-version.sh,
/usr/src/bin/freebsd-version/freebsd-version.sh and
/usr/src/sys/conf/newvers.sh?

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/07/15 08:50, Jamie Landeg-Jones wrote:
 Xin Li delp...@delphij.net wrote:
 
 On 8/6/15 22:24, Kevin Oberman wrote:
 Or the code in portsnap could be modified to get the current 
 running version.
 
 I thought about this today but it won't work as advertised:
 someone (currently me) still have to tweak the portsnap builder
 configuration to announce new major version (9, 10, 11 now, and
 we would need 12 when 11.0-STABLE appears).  However,
 freebsd-update or mergemaster would take care for this.
 
 I was going to suggest this too. Isn't this information available 
 using /bin/freebsd-version -u ?

Client side: yes.

Server side: someone has to tell the server to start building for new
- -CURRENT or stop building for old -STABLE.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVxNcgAAoJEJW2GBstM+ns2HQP/iQfmSjJ853Aj4Bs+0qed7Ya
UoE4LDaX1PJSIpqswyWir34mSgqZ5jHC8wuEkNrT3dlXaSnuxBmjvZfm23T/AUFH
9b/ytjJGlZWT0Db88AOnIeiMKKKX786m9mkDxiY2C747Q0L+KqLzQx6Ltrgl7DEm
9arRlB3nQcix9u7badVgP+B3CRfspUwtqmL9m+4LFIlJQA3OPsMxySdKoJlCQD8H
E1rJNV/6NOxIIX2Y+/6EBhtNnhQwbXyKT74B/4UKFaGNaKfw7XIjB5T4yGBaWhPL
4VXqzDRU2g0YGY8VM3/uXA3AfSVuVYi9kmm2R3W/91TFwOVqGH31OQQczeK78Gpn
dx8+kOfC7OLGWaQ9Xb9H3bNcPUknRuUVusb4+Wbe8qXk5cWfeyIJLTK7GC4Vvq4i
dGf+rYpEMls/0t+W+6e1re+XTlZtgepLfWQMuuhCbOQf8egKktClbJ++Th6krc1B
Aob62BmfgNgq4mS8t21Ee2heBTTrjNwp+openjPv9+ffvhmDngshNrdp+z4umQ3G
uryURepM9YYmrRWVmD9ZOei81R2QIpzdFh/Xv4w8bwTAoiV3oJfNIavbJWuhsEsk
sAKU2Kk0oBiTDwOqe4ZEVfF1HWbOZe6X6gBWjwO0f/RG7Rtn9pexU9TRzBL1SmeE
qUix6Wbx6VfCB+7QiQgg
=LDxP
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 8/6/15 22:24, Kevin Oberman wrote:
 Or the code in portsnap could be modified to get the current
 running version.

I thought about this today but it won't work as advertised: someone
(currently me) still have to tweak the portsnap builder configuration
to announce new major version (9, 10, 11 now, and we would need 12
when 11.0-STABLE appears).  However, freebsd-update or mergemaster
would take care for this.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVxEYEAAoJEJW2GBstM+ns6wkP/AoQS/GX6RfJ0r5KBzHJzo1Z
1sFGkqULBYbiS4DNV8Svt1+mMdg0IwK7t5vYhkiQI/RrkeddvU1btDiVPjNGbC3K
Wm5wKAD2uMRLczz9EhKCZehDRq88ckvUMefPdT5R3b+DTo4VKdCXoPC4AqZnu7bb
60wnOL6cyKw8fwKTHhVyui6zcbg9uj7VtGj9MGK+03jHDmekJ6sXZO/0fp/TGju6
ruPVf9yImi9o/T5IUaKlj2D3xfDtwEhjI7Q96K4C5y88Tl5+PXQBh/07SQOKIu59
nalLbAH8eoxITWEAOBFjM/e1KOLH5Hyk+TfR0GXDZVLyL4mi8eIpch0eLFHp3e94
PEbsE1lUN3R3/4IFTmPDj1WYF9dE/AUgV4gzQKBboieVYNLfuL/esI0VOCFa/3r3
3rSW9RAj8MOH3GA3un14eUrWg5prvDcjMq9cJUO5Pebc3cD0CxlKCJ+yNAMlTo4Q
07u8dxBXsZcO//xknW5Gx9rKl+fJxvwy2klLmsiR3+bM2PCd1bt4bvSkOTgv1ZOt
qJZ4g/sDpF2jx3UYj2PF5vnBLkI6RrWer379q8ZqAwVRGE4Z9glnzo9BNUpQoQDy
PXzf3Nsj/qWkvnXXIWxI71rLTsKNejiXpBiYYjZV2eYz9dCveNJEMRFmHQ+xthHz
VrdB3J9EBHa17p5Xlt2y
=nN8J
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Proposal: make portsnap generate INDEX-${OSREL:R} only by default

[Xin Li]

Hi,

Currently the default portsnap.conf would generate INDEX-11, INDEX-10
and INDEX-9.  The INDEX file is only used for searching ports, and only
one (INDEX-${OSREL:R}) file is actually used.

Traditionally, we create all supported INDEX-* files by default, but the
only users who would benefit from this default are the ones who shares
ports tree across many systems that runs different FreeBSD releases.
 And even in these scenario, it's likely that they would still want to
tweak the configuration, as we may be creating more than needed INDEX-*
files.

So for simplicity and to reduce cycles wasted on everyone's system, I'd
propose the attached change to head/'s portsnap.conf and similar changes
to stable/9 and stable/10's portsnap.conf so that only INDEX-${OSREL:R}
is created by default.  Users who want additional INDEX files can
uncomment the corresponding lines.

Any objections/concerns?  I'll commit the change if no objection is
raised in a week.

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
Index: etc/portsnap.conf
===
--- etc/portsnap.conf	(revision 286392)
+++ etc/portsnap.conf	(working copy)
@@ -30,6 +30,6 @@
 # REFUSE korean polish portuguese russian ukrainian vietnamese
 
 # List of INDEX files to build and the DESCRIBE file to use for each
-INDEX INDEX-9 DESCRIBE.9
-INDEX INDEX-10 DESCRIBE.10
+#INDEX INDEX-9 DESCRIBE.9
+#INDEX INDEX-10 DESCRIBE.10
 INDEX INDEX-11 DESCRIBE.11


signature.asc
Description: OpenPGP digital signature

HEADSUP: password database format change [Was: svn commit: r283981 - head/usr.sbin/pwd_mkdb]

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please be advised that the password database format have been changed
and no longer have legacy, endianness sensitive formatted entries, as
of r283981.

This change should not have any visible impact to current users other
than slightly smaller password databases, as the base system have been
changed to use the new, machine independent formatted entries more
than 12 years ago, and all modern FreeBSD releases have supported them
since 5.x time.

Old behavior can be restored by specifying '-l' from command line, if
desirable.  Please report any breakage as we currently plan to remove
the -l, -B and -L options from pwd_mkdb(8) in 12.0-RELEASE.

Cheers,


-  Forwarded Message 
Subject: svn commit: r283981 - head/usr.sbin/pwd_mkdb
Date: Thu, 4 Jun 2015 07:24:56 + (UTC)
From: Xin LI delp...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org

Author: delphij
Date: Thu Jun  4 07:24:56 2015
New Revision: 283981
URL: https://svnweb.freebsd.org/changeset/base/283981

Log:
  In r113596, version 4 of entries have been added but pwd_mkdb have
  been generating both new (machine independent) and legacy version
  entries (endianness sensitive).

  The base system have been using the new format for quite some time,
  so disable the generation by default.

  An interim option, -l, have been added to re-enable old behavior.
  The -l, -B and -L options are considered deprecated and will be
  removed in FreeBSD 12.0 release.

Modified:
  head/usr.sbin/pwd_mkdb/pwd_mkdb.8
  head/usr.sbin/pwd_mkdb/pwd_mkdb.c

Modified: head/usr.sbin/pwd_mkdb/pwd_mkdb.8

==
- --- head/usr.sbin/pwd_mkdb/pwd_mkdb.8 Thu Jun  4 06:30:39 2015
(r283980)
+++ head/usr.sbin/pwd_mkdb/pwd_mkdb.8   Thu Jun  4 07:24:56 2015
(r283981)
@@ -36,7 +36,7 @@
 .Nd generate the password databases
 .Sh SYNOPSIS
 .Nm
- -.Op Fl BCiLNp
+.Op Fl BCilLNp
 .Op Fl d Ar directory
 .Op Fl s Ar cachesize
 .Op Fl u Ar username
@@ -61,14 +61,10 @@ different from the historic Version 7 st
 .Pp
 The options are as follows:
 .Bl -tag -width flag
- -.It Fl B
- -Store data in big-endian format.
 .It Fl C
 Check if the password file is in the correct format.
 Do not
 change, add, or remove any files.
- -.It Fl L
- -Store data in little-endian format.
 .It Fl N
 Tell
 .Nm
@@ -116,6 +112,34 @@ encrypted password and the insecure vers
 The databases are used by the C library password routines (see
 .Xr getpwent 3 ) .
 .Pp
+By default,
+the
+.Nm
+utility generates new,
+machine independent format
+.Pq v4
+entries only.
+For compatibility with
+.Fx 5.0
+and earlier releases,
+the
+.Fl l
+option may be specified,
+which enables generation of legacy format
+.Pq v3
+entries.
+The legacy format entries are endianness dependent.
+.Pp
+The following options may be specified and will affect the
+generation of legacy entries.
+.Pp
+.Bl -tag -width flag
+.It Fl B
+Store data in big-endian format.
+.It Fl L
+Store data in little-endian format.
+.El
+.Pp
 The
 .Nm
 utility exits zero on success, non-zero on failure.

Modified: head/usr.sbin/pwd_mkdb/pwd_mkdb.c

==
- --- head/usr.sbin/pwd_mkdb/pwd_mkdb.c Thu Jun  4 06:30:39 2015
(r283980)
+++ head/usr.sbin/pwd_mkdb/pwd_mkdb.c   Thu Jun  4 07:24:56 2015
(r283981)
@@ -112,15 +112,15 @@ main(int argc, char *argv[])
char sbuf2[MAXPATHLEN];
char *username;
u_int method, methoduid;
- - int Cflag, dflag, iflag;
+   int Cflag, dflag, iflag, lflag;
int nblock = 0;

- - iflag = dflag = Cflag = 0;
+   iflag = dflag = Cflag = lflag = 0;
strcpy(prefix, _PATH_PWD);
makeold = 0;
username = NULL;
oldfp = NULL;
- - while ((ch = getopt(argc, argv, BCLNd:ips:u:v)) != -1)
+   while ((ch = getopt(argc, argv, BCLlNd:ips:u:v)) != -1)
switch(ch) {
case 'B':   /* big-endian output */
openinfo.lorder = BIG_ENDIAN;
@@ -128,6 +128,9 @@ main(int argc, char *argv[])
case 'C':   /* verify only */
Cflag = 1;
break;
+   case 'l':   /* generate legacy entries */
+   lflag = 1;
+   break;
case 'L':   /* little-endian output */
openinfo.lorder = LITTLE_ENDIAN;
break;
@@ -465,6 +468,7 @@ main(int argc, char *argv[])
error(put);
}

+   if (lflag) {
/* Create insecure data. (legacy version) */
p = buf;
COMPACT(pwd.pw_name);
@@ -555,6 +559,7

Re: What to do about RCS/OpenRCS

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/07/15 12:09, Pedro Giffuni wrote:
 Hello;
 
 Some of you might recall that right before 10.0-Release there was a
 painful attempt to remove GNU RCS from the base system.
 
 From my point of view, the lessons learned from that were:
 
 -A lot more people than you might think find it useful to have a
 small version control system for thing like the files in /etc. 
 -Just removing features without a discussion is not wise. -IMHO,
 people wondering about the bloat in the OS should focus on other
 bigger VCS we carry, namely svn.
 
 For all I know, it looks like OpenRCS is the most viable option and
 can completely replace the old RCS we have in base.

I have objected this in 2013 because OpenRCS did not pass GNU RCS's
test suite:

https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185.
html

More specifically:

+ : -Dhas_conf_h
+ : cc
+ : diff
+ CL='cc -Dhas_conf_h  -o a.out'
+ L=''
+ RCSINIT=-x
+ export RCSINIT
+ SLASH=/
+ RCSfile=RCS/a.c
+ RCS_alt=RCS/a.d
+ lockfile=RCS/a._
+ q=-q
+ test -d RCS
+ rmdir=rmdir
+ mkdir RCS
+ rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._
+ echo 1.1
+ echo 1.1.1.1
+ echo 1.2
+ diff -c a.11 a.3x1
+ diff='diff -c'
+ rcs -i -L -ta.11 -q a.c
+ test -r RCS/a.c
+ rlog a.c
+ rm -f RCS/a.c
+ cp a.11 a.c
+ ci -ta.11 -mm -q a.c
+ test -r RCS/a.c
+ rcs -L -q a.c
+ test ! -f a.c
+ co -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ co -l -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ cp a.12 a.c
+ ci -mm -q a.c
+ co -q a.c
+ diff -c a.12 a.c
+ rm -f a.c
+ co -r1.1 -q a.c
+ diff -c a.11 a.c
+ rm -f a.c
+ cp a.3x1 a.c
+ ci -r1.1.1 -mm -q a.c
ci: RCS/a.c: no lock set by delphij
+ echo '#branches failed'
#branches failed
+ exit 1

The checkout as of today ported to FreeBSD still does not pass the
test cases, so I still object the replacement unless the issues have
been taken care of.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP
3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p
77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM
t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy
0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW
5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z
zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c
b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw
+cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu
2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu
QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj
VgaTuJMDK6pjCpTKfA/B
=di1X
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: backward dependencies on libzfs

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/27/15 17:57, Craig Rodrigues wrote:
 On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon a...@freebsd.org
 wrote:
 
 
 I am not sure what's the best list to discuss this issue, so let
 me raise it here.
 
 It seems that libzfs_core can not be used without also linking /
 loading libzfs: /lib/libzfs_core.so.2: Undefined symbol
 zcmd_ioctl_compat
 
 The same is true for libnvpair but for a different reason (and it
 looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol
 aok
 
 Both dependencies seem to be backward, because: $ ldd
 /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 = /lib/libmd.so.6
 (0x801647000) libthr.so.3 = /lib/libthr.so.3 (0x801857000) 
 libumem.so.2 = /lib/libumem.so.2 (0x801a7c000) libutil.so.9 =
 /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 =
 /lib/libuutil.so.2 (0x801e8f000) libm.so.5 = /lib/libm.so.5
 (0x802098000) *libnvpair.so.2 = /lib/libnvpair.so.2
 (0x8022c1000)* libavl.so.2 = /lib/libavl.so.2 (0x8024d6000) 
 libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5
 = /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 =
 /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 = /lib/libc.so.7
 (0x80081f000) libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000)
 
 So, there are circular dependencies between libzfs and the other
 library in both cases. It seems that those dependencies do not
 cause much, if any trouble, in practice, but they are not nice,
 because they are unexpected and they are not present on other
 OpenZFS platforms.
 
 
 Fixes similar to this: 
 https://svnweb.freebsd.org/changeset/base/272484
 
 need to be done to plug these symbol dependency problems in the
 libraries.

Well I think it's different issue.  The backward dependency was
because of our libzfs_core depends on some compatibility shims (I
think it was introduced in r248445).  I don't have much time to work
on it right now though.

Andriy -- maybe file a bug and assign it to me?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVPt+QAAoJEJW2GBstM+ns5g8P/jchSVar1TjU2HoJymmthwPM
W5mwFSp0f0XWbtd2tkOSUHL6DGvV5pVpzhg3Oj20lrSGJv3s7tymffUSwBtKEA5q
fptapAeg/2hXT2U27ns0d5BgaoNz87y0BZgwcWrM4lsDOLpOLt++NPvqf5Jjoq18
y9cRvO06JCZV087Ou/mqU981b7f1T6T+eEUdGXGltP6uynF10HMAlwe53d4hJLgl
mhXvZcK78rjf8swtUCBzvkeTkB1OH/O1kL/w8p1oSTUbTERJneNFHEb1+o18XHsA
3aWrnDtweEDgK6mItK3HI26Rq1HvxdqbaYVnfmQikkufyamehzQofXb0AewJuRNf
EG4DYp1Y48USD2feQRF0an+lGcro6IQPv1GdKox2VdgR6lF0mOUPJr2TMvKNsumQ
4pxPNsM0b637YzL0mp/bt6t2C6YNaStn+PQ8gWCeOzBM2AJIUqliAP8eghEuAR2a
4kFGOOzLlzITdsg8Y7UNvTmiAMJVGm2XIwkOQA7pUR8LfkFeqyFqb846kR0HOK9w
Ce01BAsgM1OFgbo/WELd8ZTTrh+B2eV8dPJhPVEO1tmcniJoeUg3Qj76IPAK34U0
q5FTs5iaEWk2/N+jkd8kAGnZrHhVTLl88aEcdak+eyLj/VtUuvHakZckteDTlYak
k5ZJG2p/nxiY5NJPbDJJ
=tf6a
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: default pager (csh)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/20/15 18:05, Warren Block wrote:
 It doesn't do that on csh.  Or maybe I figured out how to prevent
 it long ago and forgot, but all I use is this:
 
 setenv  PAGER   less -RS
 
 
 You probably did what I used to do. Modify the termcaps/terminfo
 to eliminate this behavior. See Exorcising the Evil Alternate
 Screen.
 
 In the past, FreeBSD disabled this by default. It was changed
 several years ago, but you can change it back as per the aboved
 referenced article.
 
 I'm pretty sure I have not done that, it would show up in
 mergemaster. As far as I can remember, less(1) has never done that
 clear-the-screen thing on FreeBSD, which is why it is so jarring on
 Linux.

Not all terminals will clear screen...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIbBAEBCgAGBQJU5+32AAoJEJW2GBstM+nsZFQP+IoALzoaMRYF+jB9L1kwY+QN
h3mnx6BCjv24nMfnv/wLDvWXQ5N1DY0Di9/RP0YSFxgWetpxQGIf0fDOE2jYAbSW
+xPBMnYfkKWmzenF5W9NxMPi4o6ul/+LIkp1PxGpxHqjktkSFu3lnoeZaI0JB+6U
3XgpyLMsCfKPP1s5jOyn7TcIKQkby69ANUHWN+7Vfcrg7wy7h0cLmEuCfqOjMg0O
CczASshTkCH3JjdwENmT5hwxIKRRqLeqKLvGSyphcZ8FiOl8TKfY+Rnd7wxc9/Cf
/PU4cJFVIYw4v60hknD+Dj3hdgwJYA5pfJY2+8faC5V0qKpsDCnl43xDzKXojJjE
QX74k7fS47bwcAzTZMLD55X95mos6k7pkDdSE+FoEyWld+yCKxxnSGEXE+728xX2
zdpj1OlJLhyijcZXPNYbDmUVbGzjBnWSTcRF73+upeGDtG3Q1cKaCD7ZBx+Eyqq8
r0ILRrINPzW58XzK0i33obT4SqyBKnadCRuSADpKEaEZgjQeDEGhlQ83SBIt2xBr
rqofewSf3jPoN/o03vNaVMRfOT36NT65DOoCjIf0TuEpKbRhfYXb5LVAmt13Bhpv
Uc29/3uOi0r2A1h+2URZ0M5LBJo2NiaNgGRE+TTw4y/+mUwhbMvdOVuRwvYwGatb
2lI/u9fCHmNkyPWf5J8=
=+90O
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: default pager (csh)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/18/15 15:18, Davide Italiano wrote:
 Hi, one of the first things I do when I install FreeBSD is to
 switch the default PAGER from more(1) to less(1). This is
 particularly convenient, e.g. while using git diff, to show
 something more readable. Just out of curiosity, is there a reason
 why more(1) is still the default, and/or is this just historical?

The _only_ reason that I can think of is that more(1) does not clear
screen for certain terminals (done with 'ti' and 'te' sequences),
while less(1) when running as less does.

The less(1) behavior can be annoying to some people (sometimes even
myself when using less to show contents of a file and ^Z to paste
them), and unfortunately quite a few of them also happen to be the
more vocal ones when it comes to a change.

Other behavioral difference are trivial (or people care less to speak up).

I use less(1) instead of more(1) on all systems I have, so if some
brave soul wants to make the change I'd say just go for it! but
that's my $0.02 only.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJU5SMrAAoJEJW2GBstM+nsd7AQAJNJnZtu3YabP0wzbwZuhQHu
7BvG/RLEqUe6ZmR10pcxe/vr6W+d7HpRuBcF09MSclpijTie+w/5AmaP7NNCCrHc
+lAtUhGxGhloTmpkm3GhL94ai1AMoKSIwKgT2Onx76CWYXKfh2ycN4EDfAHUlenZ
4N+3NYua/20deTy0rji0HYMexN4/ZUApsiX9hLwj+mlVl/KVNLMh2OIoUpdbnfJi
MU9h+/WPZGBJeU4VQU3YO77sPm23EIzirFajM4Fqk6AZJp8ueHp5U0Bz1l98fBFZ
EUx2Bh4DLhn/+7AUlCiW3ByAwyaEzdjpeGwIT97hqHE+7r0Yuf69Sf1mdUcIbMNd
TOMo3oKTsVWtYkzB8DZAvGw6y73sLxm6KRwGYWoU3SIhIacU7zer5FC755pPGw3V
RqjBPu6nD8BCCXaBumiFtwrr88+vdDV6HfWRXfwSukT4sAYDAzjDEAhuY8kzDyWB
vW9KG5IqPrTXPabdAKEj8qpfZBbspYUT0jOPrnto9/S5pnxkXmtmTn/gfVELjblj
mLkJYPX9W25ziz3hI9t/wOp2Rl5GzBQdudIXpwD/06/L9h9X4CD38NdEQtJOOLyp
M4twYFkiFJZp64XhuwMJ4BGIunj4OsbDfmvZEbJJfV8Z2mgA0QbRvfZG7UqVThd0
MTHLk0J7hIunFwIdICpI
=whDB
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: tzsetup chroot

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/03/15 17:05, Nick Frampton wrote:
 We have our own FreeBSD 10.1 installation script in which we call
 tzsetup.
 
 I'm seeing different behaviour in tzsetup between these two
 invocations:
 
 tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup
 
 With the -C option, no matter which time zone I select, it asks:
 
 Does the abbreviation 'UTC' look reasonable?
 
 Using chroot, I get the expected behaviour, e.g. selecting 
 America/New_York:
 
 Does the abbreviation 'EST' look reasonable?
 
 /mnt contains the contents of base.txz, so it looks like all the 
 zoneinfo files are there.

Could you please submit a bug ticket for this?

It looks like what happens is that tzsetup does not really do a
chroot(2) system call.  Instead, it simulated the effect by prefixing
all paths with the chroot environment.

The problem is that when tzsetup is going to verify your
configuration, it would use tzset(3), which does not respect the
simulated chroot effect.  When no zoneinfo data is present, everything
would be considered as UTC.

Attached is an dirty hack (ugly enough that I don't wish to commit)
that changes tzsetup to use chroot instead, which should fix the
problem.  I'm not very satisfied with it as it does chroot() before
doing init_dialog, which may well fail as the devfs is not necessarily
mounted in the chroot, and on the other hand all termcap related data
would be sourced from the chroot, which is probably an undesirable
side effect.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJU0X+zAAoJEJW2GBstM+nsfpwQAIwPBj11lzJS662RPBPQR6dB
vb3gCGJjqRANCD+Sr8EqxzPlKOcC4UiBB5Khy39lidC+d4qgGQ3Mz3qIwjCdl3Aw
KUzkFfhvspGzE25tIwsPJ3A00NjXNJGqGqcDMitfls4SdYZWzCgs+gwa3zGq+yO3
/pPMQVVhhBz2pgkqxCtznFqY9paN5lzwaOqp9HepNz1g99Q4u+KpIUI93BMcMdMD
9HtY7YQYzDCnhi4OskdIB2BrLm1NSFPMkALASTMuCplFwtyI+emYD/GzOwUF5zay
Vk4QQ33Z9G1pw6jU730kFl/FU5tps35leUYUMcgiz2CG9DTz/wFRJ4SjwD4b1NYx
35nwbrhnp5TV4g94zFfY1NejSwmCpdzq5fvSYwu73yQ+pzwqA2xjXGMwICEo95Tj
Zop/T9gU3g2Hglmz6zTe7m4EXdruFZrADlI6K6cPg/52HosSi7iLnkebwX0nClbQ
HQeCdved38nzRBDZGaJmrDebHD3Uy+qrP5dxTaDe49JZZ+lnkceqy5s+OLQb78S3
Wt9q6GgdKLwa157K74ci/T3rSnty+dJlOXlaq2Bhbru8O7GGmIcmMtsAYzI7+C0z
0cuqsI2sXvT6i/XSjt2VK0D/aQfJ0NfpWDJ6rtlAnFc0g5UBncd8MrAfWo/KOPdH
nIdamgVfmtHcglu07fBq
=0pwZ
-END PGP SIGNATURE-
Index: tzsetup.c
===
--- tzsetup.c   (revision 278173)
+++ tzsetup.c   (working copy)
@@ -40,6 +40,7 @@ __FBSDID($FreeBSD$);
 #include stdio.h
 #include stdlib.h
 #include string.h
+#include sysexits.h
 #include time.h
 #include unistd.h
 
@@ -944,24 +945,19 @@ main(int argc, char **argv)
if (argc - optind  1)
usage();
 
-   if (chrootenv == NULL) {
-   strcpy(path_zonetab, _PATH_ZONETAB);
-   strcpy(path_iso3166, _PATH_ISO3166);
-   strcpy(path_zoneinfo, _PATH_ZONEINFO);
-   strcpy(path_localtime, _PATH_LOCALTIME);
-   strcpy(path_db, _PATH_DB);
-   strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
-   } else {
-   sprintf(path_zonetab, %s/%s, chrootenv, _PATH_ZONETAB);
-   sprintf(path_iso3166, %s/%s, chrootenv, _PATH_ISO3166);
-   sprintf(path_zoneinfo, %s/%s, chrootenv, _PATH_ZONEINFO);
-   sprintf(path_localtime, %s/%s, chrootenv, _PATH_LOCALTIME);
-   sprintf(path_db, %s/%s, chrootenv, _PATH_DB);
-   sprintf(path_wall_cmos_clock, %s/%s, chrootenv,
-   _PATH_WALL_CMOS_CLOCK);
+   strcpy(path_zonetab, _PATH_ZONETAB);
+   strcpy(path_iso3166, _PATH_ISO3166);
+   strcpy(path_zoneinfo, _PATH_ZONEINFO);
+   strcpy(path_localtime, _PATH_LOCALTIME);
+   strcpy(path_db, _PATH_DB);
+   strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
+
+   if (chrootenv != NULL) {
+   rv = chroot(chrootenv);
+   if (rv != 0)
+   err(EX_OSERR, chroot to %s, chrootenv);
}
 
-
/* Override the user-supplied umask. */
(void)umask(S_IWGRP | S_IWOTH);
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: old bug: mount_nfs path/name is limited to 88 chars

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/19/15 13:20, Garrett Cooper wrote:
 On Jan 19, 2015, at 8:46, Brandon Allbery allber...@gmail.com
 wrote:
 
 On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht
 me...@bris.ac.uk wrote:
 
 So perhaps changing MNAMELEN will break statfs(2) on -stable
 too?
 
 
 I believe the context there is not so much -current is special,
 as changing it for everyone is bad news (and this would
 necessarily need to originate in -current).
 
 A compat layer needs to be created for all of the affected
 syscalls, and the change needs to be made. That’s it in a
 nutshell.
 
 Doing it in 11 makes sense since there is a compat layer for 10
 now… if I knew all of the steps I would happily do them as annoys
 me from time to time as well with the path length issue.

Compat layer may break applications in other funny ways and we
probably have to return e.g. ENAMETOOLONG for legacy applications if
the names are too long to fit into the buffer, but I don't see any
easy solution either: I wish we have bumped it in 2003 when the struct
receives its first big revamp by bumping all statistic fields to 64-bit.

I personally think we probably better create a new API and keep the
existing one for (limited) compatibility.  For instance, it may be
sensible to make f_mntfromname and f_mntonname fields variable length
and have the caller pass a pointer and their length.  If we set an
arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some
time.

BTW. If someone wants to change statfs(2), please make sure to create
reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c
for an example).  The statfs(2) API is used in a lot of places,
especially fts(3), and breaking it either way (running new world with
old kernel, or running old world with new kernel) would be a big pain
to recover from.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O
a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f
vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU
4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg
wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c
NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J
55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ
sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj
b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro
IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v
+2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM
PiOk31dmRfQB+3mqZ+Oj
=a3fA
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Delayed atime updates (lazytime)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/26/14 10:06, Marcus Reid wrote:
 Hi,
 
 Looks like Linux is about to grow another solution to handling
 atime updates differently:
 
 http://lwn.net/SubscriberLink/621046/e59938475fd3e874/
 
 In short, it will only write out atime changes periodically
 (daily), or if there is another reason to write out the inode, or
 if the inode is about to be pushed out of cache.  This seems like a
 pretty good compromise.
 
 Currently, the ZFS configuration that results from using
 bsdinstall disables atime on all but /var/mail, which is the only
 example of disabling atime by default that I'm aware of outside of
 Gentoo Linux. I can't seem to find any information that talks about
 the rationale behind that, though a couple things come to mind:
 
 - some additional IO generated (but that's always been the case) -
 additional wear on SSD devices (enough to compel the change?) - zfs
 snapshot growth (but the snapshot stops growing after one full set
 of inode updates) - wake up otherwise idle spinning media on a
 laptop (the actual reason that was cited as motivation for the
 change)
 
 Something like lazytime would address most of those concerns, and
 people who are even more OCD than that could disable atime
 completely on their machine.

I think bsdinstall disables atime because it's an useful default.
The lazytime idea seems to be a better compromise.

PS.  A while back I have implemented a 'relatime' feature on FreeBSD
in a private branch on my github repository, but never have pushed it
further due to a difference in semantics (which needs to be fixed:
atime should still be updated after some time, while my version only
update it once, the Linux semantics is more useful for cleanup
applications to identify unused files) and partially lack of interest
from the community.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQIcBAEBCgAGBQJUdjhZAAoJEJW2GBstM+nsJvsQAJAYNhKU3+3OTIEX7+1w1WlQ
SPO55FrZ86nRfYIDbioafXqXki5QrjDrZLwaP2wwLMOmclZBVxliKiFUnRSXNdl+
q0j2jSYiue3GKNvN6nLRTCWqe4lYg46btmVhqBsJnATLxDq4fH/5+FwsORgSgTOq
LENUyYDJ8beuYCCD52Rs7RklNhQqfEPPbNWclLuWqjq6YYcqfRjgXD0PHJpmhMcR
NOMRnkv8BtcvsOwD09uYqfsWZX5cO2yb1JdlvGRVft6xHLLOhCaAxOhhz7yeTSzq
OrvUSRw2rCRJdNqfUpLcN1oK7Fu2f13HrqPXGeOKc96VE6pX2ADaoCtKXgtDFf0W
qCmR1jhu5v/NAHxTZjRR+Lpf3zO/NA0lS3+uCFjxFjBy5NwFdh2MsNRBWV6EBdYF
kJ5DqsIqLfW89F7jtKnp3qaxhyySwKlgqDooVMrClCkz6Doy84dBzA44b8yQnHri
YcUlXgfBz33qfMP+pywRKOC25mQe05u1yk33dp1QTTxPVW+BvDMxgwaTqSpqTvyB
yHTm//Dz+UdNDkxL82aVw4pfNhhOPb52jWz7MNTVYTP15w3+rY45sChgux02ltNE
gEm1MnJIBYmFNQq5orcjLSGIKTL6VlrDmC6rd7zXEagQ1D34LknziE61m6/yeZTI
4lcmm6CWRz/L2cfOLR/p
=I8Cg
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: current panic: Lock (sx) random_adaptors not locked @

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/04/14 06:01, Julian H. Stacey wrote:
 Hi current@
 
 Maybe this is a transient no one else will see ?: with no
 /boot/loader.conf, my old custom kernel booted  my new one
 paniced:
 
 panic: Lock (sx) random_adaptors not locked @
 dev/random/random_adaptors.c:278

This was fixed in r274006 FYI.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQIcBAEBCgAGBQJUWRmsAAoJEJW2GBstM+nsvZEP/1JKJsptJGPrkOfhE9MznH03
dD9TeDN1fZUvi+54ZZue78SS/hE4/Nbga62nWc5ml8mZkHwrEF/N1+xgHR5Scfw9
EPFFY/bvmzAB9AKDyFLPC7IYLCQ+G9lZKbkNbeSc8q4tze0nmc4Sgpum1FVstS46
njU9cnhIJZ9yScVkofhBuaAeGgbD5w4zK6Ezr1aLdfhTil2cs9nZlN2fuRBTDIot
v8PS52ZZw2pQJZ9SSZaYlB9fbT5vsH3cCUzxFpr5EH7oJdlNs6fPknYoy+2q4SkT
9yjIg+P96jdB42c0HaSO7DvJOzDIrtG8Dy1hMDpxJUkHodwa0HqQWNRYDZ8t3d2f
gEgwwO3/t8H6jyzPqPIwFj5nQuI6ErKfwDOUm/kORWy18zFiApDHhiAltMPsryCo
nz3swJEgmW//viYEW25Yi/WHEBvzrTa3736Q/r5/I6Ssz2nJX/wehuRQ4+pPHKGx
OponYjXeXlHj/1dVjdnieYgC+aCVSQTBiF5i+QBV6gD+NvLosjH2u73aQ73lQisD
AUiGw7AvwfuDaxvqhjT+hu69hCrpRcDhL9QEJZ6TmoPOnL0kaz70iVfO9khEoObr
MbODB+eqDn7j2tZ+klVWagRgFyjRX7uCGi9A3wLD43nvcd7wquNJVRFnSxN3NJD2
hhlH+sXhtcxZcyhwjWo3
=nu2x
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The problem should have been corrected by r273919.  Please update your
system and update /etc/ with mergemaster.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQIcBAEBCgAGBQJUVBaIAAoJEJW2GBstM+nsDHIP/jEgsdtn8ZWbwSHCh8RBXhM7
rr7wdRXcti0h8G0htXTaWWrEaJ1Y7LKGVBjqrUqTJU/g7mRha/p2BrEsYMGBwFbT
uqPDYIiHvfVIDH6wAO5qi1CvPG8UhsGG3IV+RXEazeBFlNUA50ZRhyhYtvuywoWw
9izOCtc1y3pEuR3i7Ybpors6oulyYWIpd/tuafkVWmhrLblvCLNv6wrmwxAcXtNN
UC92bvH320nqA49AC1jAD0zrZ5uc6fPBgcSXi1SZvmnuxnODRrV/O0yD67fUHKtm
59x7woa4tMaVNtP+eQ2QSZv75oko5HmZqfAV4urTQjfb44wDj42uFOKN8WHmMNbe
RxZ/b7dhbU9BMKhnf117IIg2P96o2Hj9jwBN6+PaPoPw2UGSgiJf7/bf3RnEZCoM
TISlyv3fAvbNg7yuGAZsm8onjUPIfjlriOUhUeiKzNDhQDRW8eKWDPEio8IapyJW
wYLtNPjARYUfIswAVMRn5NuNzjqloPKLjXf2YOtREb/c3K1UZMRLTc98zPhJ7za+
6EzIe/CuY7X55ajwK8Fqmqh/G3TiaSomwiVzZrtl2ggdeXsMsWfeaV0E9gtspVwb
Qaprmo1Qx/vZUhHPy8L/OHqvCF39z4RC4N/4ryc7gt5gpW9jkeWzyYvGD/wCdV7b
bHxbVZR+Ukuz2B4aUFH5
=J3ap
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: zfs recv hangs in kmem arena

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/16/14 4:25 AM, James R. Van Artsdalen wrote:
 The zfs recv / kmem arena hang happens with -CURRENT as well as 
 10-STABLE, on two different systems, with 16GB or 32GB of RAM,
 from memstick or normal multi-user environments,
 
 Hangs usually seem to hapeen 1TB to 3TB in, but last night one run
 hung after only 4.35MB.
 
 On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
 FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2
 r272070M: Wed Sep 24 17:36:56 CDT 2014 
 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64
 
 With current STABLE10 I am unable to replicate a ZFS pool using
 zfs send/recv without zfs hanging in state kmem arena, within
 the first 4TB or so (of a 23TB Pool).
 
 The most recent attempt used this command line
 
 SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs
 recv -duvF BIGTOX
 
 though local replications fail in kmem arena too.
 
 The two machines I've been attempting this on have 16BG and 32GB
 of RAM each and are otherwise idle.
 
 Any suggestions on how to get around, or investigate, kmem
 arena?
 
 # top last pid:  3272;  load averages:  0.22,  0.22,  0.23
 up 0+08:25:02  01:32:07 34 processes:  1 running, 33 sleeping 
 CPU:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9%
 idle Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free 
 ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M
 Other Swap: 16G Total, 16G Free
 
 PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIME
 WCPU COMMAND 1173 root  1  520 86476K  7780K select
 0 124:33   0.00% sshd 1176 root  1  460 87276K 47732K
 kmem a  3  48:36   0.00% zfs 968 root 32  200 12344K
 1888K rpcsvc  0   0:13   0.00% nfsd 1009 root  1  200
 25452K  2864K select  3   0:01   0.00% ntpd ...

What does procstat -kk 1176 (or the PID of your 'zfs' process that
stuck in that state) say?

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUP+5vAAoJEJW2GBstM+ns0v4P/31s7geR2j22etrRnfReUxbb
lbex0VkmLGm23TbTj2vpVce+ogBeA4zo6h4WzF/yYt2372MpWOfnEoVX2yOuuGku
AFapewXS3UMXLzaRWrdTWng1KQlOyQykAHI2rvQLlYlQNTLA5AbUm6uzNXaKpD8s
PbckREQ6wHnpZOiRcMN695QstjBNCal+XJHgvrwTfyp9vdFrPVD4UHnsN7MU6QSO
XobxOqbuw4Tq95mgYJqrjk+xEYMgzUy2zkVp2QTCBXZn3T3yroI2RcgUZQWaw5SO
xRegPa5jfJqcQJAdSxl8oVs9Sz8+5YDeksAnjCOxIQzLZBbNho+SOAzi+kjnT6W7
ijTc20z5eioQVPekdJ4MBweBsAeS1aGi8VWppuP+ZDLoirmxB0LaZyRv/W/HRQDD
j4CoZswkndh+J+9Crsa9SUkfNGNvVVNjhJUGyIfTGFUsMbWTAWwa4SMj7Ad04aqW
yhg+Ab4H3Yc14TahtX0jrhD3sTBer6ZoMFKE3tl8aStGXHVMyPkj0PHg5xjZEWL2
XGF86eoIgx03A9sIdbdHEZpyTMksfNatDXZk5XpPGF/sVd6txUoYP4Ch2wD8YRFM
O5Ny2r6ash2rZYmlyjf19n4gvKebdGo8d8NbzOJ3oYue6OI/88cu0rv6xLV9hHSF
fwgIbPo5uK4hIpEm0Dk4
=qY45
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: zfs recv hangs in kmem arena

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/16/14 8:43 PM, James R. Van Artsdalen wrote:
 On 10/16/2014 11:12 AM, Xin Li wrote:
 On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
 FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2
 #2 r272070M: Wed Sep 24 17:36:56 CDT 2014 
 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC
 amd64
 
 With current STABLE10 I am unable to replicate a ZFS pool
 using zfs send/recv without zfs hanging in state kmem
 arena, within the first 4TB or so (of a 23TB Pool).
 
 What does procstat -kk 1176 (or the PID of your 'zfs' process
 that stuck in that state) say?
 
 Cheers,
 
 SUPERTEX:/root# ps -lp 866 UID PID PPID CPU PRI NI   VSZ   RSS
 MWCHAN   STAT TT  TIME COMMAND 0 866  863   0  52  0 66800
 29716 kmem are D+1  57:40.82 zfs recv -duvF BIGTOX 
 SUPERTEX:/root# procstat -kk 866 PIDTID COMM TDNAME
 KSTACK 866 101573 zfs  -mi_switch+0xe1 
 sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d 
 kmem_malloc+0x33 keg_alloc_slab+0xcd keg_fetch_slab+0x151 
 zone_fetch_slab+0x7e zone_import+0x40 uma_zalloc_arg+0x34e 
 arc_get_data_buf+0x31a arc_buf_alloc+0xaa dmu_buf_will_fill+0x169 
 dmu_write+0xfc dmu_recv_stream+0xd40 zfs_ioc_recv+0x94e 
 zfsdev_ioctl+0x5ca

Do you have any special tuning in your /boot/loader.conf?

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUQJazAAoJEJW2GBstM+ns6dQQAK4NM6X40d7tS7pqoTQvZbrD
U0u5kid703tWgAlSFzvORxeOEB94BxcHu/z1a68nGhUlL2kip8SirWV9A1rqBpes
i4T6asHYTcFj4OvaPfSoA7lSVsZIaLK+RscraN1b7hehSG9UExeYF8D7cRIguhoa
1Gnlv5iZZkjJZGjR0R6DmxC8C1CyNxAZBXnj1L+ofpgUzqH0Rw2TCW1XVKqMcxvI
5lpt+V0uu7MPNgjzgVy/1z5ZD2SUBPco0eHuN/Npj0c6HkmHkoWqd53vxrBhlyCP
eDbzLw7QTO7PaV5hAuC9y9/X1JGlmTVa0GP2irKuE5t1bAbVwUPQqpn+iiFs1Le8
34fL/jkCeSBY6voYYj100CBU1/1mZOh93wuY6FdMVWPJp/bsjbDUtKZUmosGU86j
ZMikfVNl5Jc5dmH30JGFCDOWzfaFq+V34toSfYIihaBQPyFov0Mr7De5MvQ7VJ7D
qiXDcfAXE99CXzAboYpruwrbxyxTqhUmXlWp2uCPqvmo0WhVUsROmhhXhWXkG3tS
S7L0n4X8kgklveirZWq/oDsg4JXNTP2ernNdAYyhD7TbG/N4INdFaVuqZkDVDgny
ibwY0HEzg2zskJOJBqr9a21fZx6c2dvJ1n+j5BaAq6ve2Hw2NyvUVWfMTknp4I8j
t/JJtsDNs9xokH/veS3J
=aBKI
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS-related panic: possible spa-spa_errlog_lock deadlock

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 9/7/14 9:02 PM, Fabian Keil wrote:
 Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the
 following panic yesterday:
 
 [...] Unread portion of the kernel message buffer: [6880] panic:
 deadlkres: possible deadlock detected for 0xf80015289490,
 blocked for 1800503 ticks

Any chance to get all backtraces (e.g. thread apply all bt full 16)?
I think a different thread that held the lock have been blocked,
probably related to your disconnected vdev.

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUDGarAAoJEJW2GBstM+nsU+AP/0CjAmk3p/j/HD3lOCRYRiyV
JkajIcSI8FFgAfLuiULclnEziBT+XEgYDisoABd7FVaP890mL/Mp52RSLMYlr8VJ
RP9Qv+KePNGVn52djSOPxnNdUNqgNGHiDEllUIZbBu28k/flV4EcSfm799iA9HES
o84LPUUc1pm+NJTtgoT6QKWZ+kfuztfY3/vlwJEluJqSuoZkN8DII1jT3pE55R6h
f++bqSD/eKOd/3EJ5qZ38glXhmeSPEJ+VJlVumuRMwQoe3II7nIrZZBYVMY1sRZ8
qqmi4mUU1EOGvQWYjZ+J+1TYDTQgO9PP/aEPhz39tyJxP4d/VNDbJqPvAw+ez9ZU
jT7n9xuaFXr3WdJSexSFsDOJts9op6kytqnZScPTgVUi2AbUQwBu3wV9v9XKjqBa
YlcHoGFlpUmlc8I9NXdTks0oyORct0K5E/5x00S9QUGw3EtokDVCBQ63n9L1usmd
mRG7F5xgDoTtl6UQSdW+DLhYF0cS08zG6TBDBx630Bdbtye2j5rRVn/bmonZJpOd
Mx0lUyYGKnJFnMaeJe2BsFkrMyUej1JuI0plLVe/QyZ/GBPKsXCIV1R/EC2+2rUF
xgrJl18H5hnwyNpBxjjrBodz1zgbpntijcH301lxRYlJYDBBwUTk3WBxLs/HISTe
itcqBb/VIO33cjBHn3qJ
=QPRD
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS-related panic: possible spa-spa_errlog_lock deadlock

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 9/7/14 11:23 PM, Fabian Keil wrote:
 Xin Li delp...@delphij.net wrote:
 
 On 9/7/14 9:02 PM, Fabian Keil wrote:
 Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got
 the following panic yesterday:
 
 [...] Unread portion of the kernel message buffer: [6880]
 panic: deadlkres: possible deadlock detected for
 0xf80015289490, blocked for 1800503 ticks
 
 Any chance to get all backtraces (e.g. thread apply all bt full
 16)? I think a different thread that held the lock have been
 blocked, probably related to your disconnected vdev.
 
 Output of thread apply all bt full 16 is available at: 
 http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt

  A lot of the backtraces prematurely end with Cannot access memory
 at address, therefore I also added thread apply all bt output.
 
 Apparently there are at least two additional threads blocking below
 spa_get_stats():
 
 Thread 1182 (Thread 101989): #0  sched_switch
 (td=0xf800628cc490, newtd=value optimized out, flags=value
 optimized out) at /usr/src/sys/kern/sched_ule.c:1932 #1
 0x805a23c1 in mi_switch (flags=260, newtd=0x0) at
 /usr/src/sys/kern/kern_synch.c:493 #2  0x805e4bca in
 sleepq_wait (wchan=0x0, pri=0) at
 /usr/src/sys/kern/subr_sleepqueue.c:631 #3  0x80539f10 in
 _cv_wait (cvp=0xf80025534a50, lock=0xf80025534a30) at
 /usr/src/sys/kern/kern_condvar.c:139 #4  0x811721db in
 zio_wait (zio=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 
 #5  0x81102111 in dbuf_read (db=value optimized out,
 zio=value optimized out, flags=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:649 
 #6  0x81108e6d in dmu_buf_hold (os=value optimized out,
 object=value optimized out, offset=value optimized out,
 tag=0x0, dbp=0xfe00955c6648, flags=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 
 #7  0x81163986 in zap_lockdir (os=0xf8002b7ab000,
 obj=92, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=value
 optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:467

 
#8  0x811644ad in zap_count (os=0x0, zapobj=0,
count=0xfe00955c66d8) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:712
 #9  0x8114a6dc in spa_get_errlog_size
 (spa=0xf800062ed000) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149

 
- ---Type return to continue, or q return to quit---
 #10 0x8113f549 in spa_get_stats (name=0xfe0044cac000
 spaceloop, config=0xfe00955c68e8, altroot=0xfe0044cac430
 , buflen=2048) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 
 #11 0x81189a45 in zfs_ioc_pool_stats
 (zc=0xfe0044cac000) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656

 
#12 0x81187290 in zfsdev_ioctl (dev=value optimized out,
zcmd=value optimized out, arg=value optimized out, flag=value
optimized out, td=value optimized out)
 at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6136

 
#13 0x80464a55 in devfs_ioctl_f (fp=0xf80038bd00a0,
com=3222821381, data=0xf800067b80a0, cred=value optimized out,
td=0xf800628cc490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757
 #14 0x805f3c3d in kern_ioctl (td=0xf800628cc490,
 fd=value optimized out, com=0) at file.h:311 #15
 0x805f381c in sys_ioctl (td=0xf800628cc490,
 uap=0xfe00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 #16
 0x8085c2db in amd64_syscall (td=0xf800628cc490,
 traced=0) at subr_syscall.c:133 #17 0x8083f90b in
 Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #18
 0x0008019fc3da in ?? () Previous frame inner to this frame
 (corrupt stack?)

Yes, thread 1182 owned the lock and is waiting for the zio be done.
Other threads that wanted the lock would have to wait.

I don't have much clue why the system entered this state, however, as
the operations should have errored out (the GELI device is gone on
21:44:56 based on your log, which suggests all references were closed)
instead of waiting.

Adding mav@ as he may have some idea.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUDIA5AAoJEJW2GBstM+nsdsgP/RT4nBT4mvOtpF2IEL7VFexJ
OjipGsWIDmG9kc8CEEN+qh3Q4+prJO3IwHGTUPa0Vu13jRZ3T/uoZj/ncVAqnCyW
s+SeEBjVVhZs/B08LqT2A8fZI9jVdqvFVWEL02z3ibWggoCnP60oag1OyvkNGqQU
apWtXkjTnrFmOEcbB95viD8QEhfUzlQgBbeRuK8ADtK/jQNEl6A8xdE5HCT2DIN4
icIwoj9eXqyLB0/aGVIFycRID4hWAZaqPehXVtGhCdnlGut7itdufuXtfmTCEDWs
z3vkGjTCJ3qsyKSxl/2ABGRgAH/lpR6J/N2yZOSNMRTt9PbjN1iLppu2IfD33OdY
QlQrI2HhbwvoZmYe4f4B/1/8qzKag77hzYG2J2aN0OGn45zkThOwoQt854zm7OHq
f3O3pysxUInTnIJrdBa53cT0arhQRtYn1xL5CYyvK4Nto74ht6g/AuBJbBWzWM/B
t2fKuZmpGt32lf+vHjWS0O2VWdkc6I6s5rVZJsSLzAMfc1rWePIcokPdUk9RucyX
qRrNDpMW53APWhPKGpkK+Utyx/OLKhO62d7iiYrGhVX0FU

Recent vt(4) broke moused when hw.vga.textmode=1

[Xin Li]

Hi,

I have seen this panic via serial console, but the console is completely
unusable at the time.  VGA console is full of '?'.

Booting single user mode, I can provoke the panic with '/etc/rc.d/moused
start ums0'.

===

Fatal trap 12: page fault while in kernel mode

cpuid = 7;
apic id = 0e
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2c
cpuid = 6; fault code   = supervisor read data, page not present
apic id = 0c
instruction pointer = 0x20:0x803abcf7
fault virtual address   = 0x2c
stack pointer   = 0x28:0xfe085f1b3880
fault code  = supervisor read data, page not present
frame pointer   = 0x28:0xfe085f1b38e0
instruction pointer = 0x20:0x803ae562
code segment= base 0x0, limit 0xf, type 0x1b
stack pointer   = 0x28:0xfe083c9b9950
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, frame pointer
= 0x28:0xfe083c9b9a10
IOPL = 0
current process = code segment  = base 0x0, limit
0xf, type 0x1b

The instruction pointer is Line 831 of /usr/src/sys/dev/vt/vt_core.c.

Reverting /sys/dev/vt to r270269 would solve the panic, but I haven't
investigated further.

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

Re: Recent vt(4) broke moused when hw.vga.textmode=1

[Xin Li]

On 8/23/14 12:42 AM, Jean-Sébastien Pédron wrote:
 On 23.08.2014 08:38, Xin Li wrote:
 Fatal trap 12: page fault while in kernel mode
 
 And the crash is fixed in r270390.
 
 Thank you for reporting this!

I have verified and r270390 have fixed the crash, thanks for the prompt fix!

Cheers,

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

Re: [ZFS][PANIC] Solaris Assert/zio.c:2548

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think this is my stupid.  Feeling ashamed.

Please try r268980+ and report back if it's fixed or not, thanks!

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTzihjAAoJEJW2GBstM+ns2esP/3zfORqtE11QeveWI8wBzHav
Pl4A3V8kgi8FHP8m33gim1yAERpqf2+WgYuAjUNloFrFD9JCslnnoGtk9yiaOH2N
Y7SJMYfvYkZ50upGE+fJKAcpH3QxLuEpSIlaFMkvA9oXtAiZEJ+BYBJh8VFWFXIs
+bnqY0Mba7T574oqw8KcEysdYYDqSVd4/M/HBUdDTWT0/ZgeStJZw9MKPiSYFJcK
PvV9dglPZ08L+Ra7cqu/EtC93p9IxVtfqxMlNkhMeVkQt+0jMKzHgDZ0dg9j7AVn
SA9e+YvE9Sg2riE6XT2iF9B8Z4vDFf5/8CGtpBpKrB4861bcctdgJ3LIJBdDsz9N
lOCjWXc4Amv8GVpTKPKaAGxeGPeN52Drqd2pD1ljLLENJsBZ3WOdMjt/R4VhpLVl
9LuXNFZ8oQy/PqVxHhYWYOOuqcFQnexB/5Qdmic3grIC/fwELbQwEK+34md5q4iJ
pvy34RzzZrA1pVRfBM2oQ0TnABrdA7+bsb44DLvkPHmVGxPPZdN7QUfVzIrbCNe9
apBkLk/Qx2kOtpuAe6xBxhaOZEAJ9Q26Souew1HOYDSAusyCETB5+tfp1hl7R0ic
xdL4YjSq9FPKOyYATCBh8/F0f2hVPC3mB2SmDz9PvI1+POWHae1tpeSCGonoc3A+
DCOLXRPNLbyZyrxTUtXG
=NzT+
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: svn commit: r267897 - in head: contrib/file contrib/file/Magdir contrib/file/doc contrib/file/m4 contrib/file/magic contrib/file/python contrib/file/src contrib/file/tests lib/libmagic usr.bin/fil

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 7/2/14, 12:10 AM, Matthias Meyser wrote:
 Am 26.06.2014 08:03, schrieb Xin LI:
 Author: delphij Date: Thu Jun 26 06:03:39 2014 New Revision:
 267897 URL: http://svnweb.freebsd.org/changeset/base/267897
 
 Log: MFV r267843: update file/libmagic to 5.19.
 
 MFC after:2 weeks
 
 This commit breaks installing world from readonly /usr/src

Can't reproduce with today's -CURRENT.  Any further details?  (I tried
mounting /usr/src read-only and both /usr/src and /usr/obj read-only,
neither broke).

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTs71HAAoJEJW2GBstM+nsdhkQAKwiZtKcHwOVijRvwHq6dWOQ
zlY3OhDCygzW93KxMW3kqT223UNP2tRBDyu3xQqn++av4NVprFo/aRrV/vs+tZYN
RMUcLFFlUeQZHIyF9L4alyAX3/ncABwWrOV97kkg990+O7CeURDycTc7Cwn/YwXq
pzrLT9ebzaRecRN1PJ5jP1dB569CFuKWyVDWjiaKxt32U0oi3T/MWTjaot+cGI0e
RrfJu+zmTwQk6gTl9lFewaIzqEIfVFotOQ3DB6IocQ2XL+wVD5NFnKYhl3UL6fJq
TK2oPuphktHi1WfEycmTIwsDfvR0o7I6ZD1Q5zdvp+PUgJPBmPS6ha2QaqfLZLht
vePNRwcD2lqpeyQRkd9W9N2YIswysiKnVXPd3OL29v2UJ3yafLTXnsLjrDdIFD50
+0xG8Y3E/1Vq/VGyachhAXSFEJfrNrGHPNQ3be0KZXnHcTgUFdg6+1bG+GeCjk4r
NwS10FlcbFUwgKc0d1wF1H5VT9xXQjJJTFa2AGbBqaOKQPEcwPKMnXdYCPfOKmzD
vdh03JNsXJyZYrpRtb7jATjQmgTp13VFlGqBJAEVc0Os8CjKmWnK06TeUQw+8q9B
NNebsCHYDlYrylFnyR7RJ6gD24F6uzUXxV/EXg+Bzidvu8jzg240Zd4aR1MU6obF
qSe3alAzDfUKzP+Y20+L
=5kxz
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: userland breakage, zfs ?

[Xin LI]

I'll take a look on this.


On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno sbr...@ignoranthack.me wrote:

 Just updated two machines in the fbsd cluser, buildworld/kernel,
 installkernel, reboot into single user.

 zfs from oldworld (pre installworld) doesn't work and segfaults in new
 and magical ways.

 Trying to mount root from zfs:zroot []...
 Enter full pathname of shell or RETURN for /bin/sh:
 Cannot read termcap database;
 using dumb terminal settings.
 # zfs set readonly=off zroot
 internal error: pInvalid argumentid
  19 (zfs), uid 0: exited on signal 6
 Abort trap


 I guess, I could multiuser the box on old kernel and installworld from
 multiuser, but this could lead to disaster.  I see no indication of ABI
 breakage of this kind in UPDATING, so ... any ideas?

 sean

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




-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

HEADSUP -- ZFS users

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

As some of you may have already noticed, I have accidentally
introduced a regression when implementing backward compatibility to
existing zfs binaries when importing a recent ZFS change as of
r268075, which will cause system to block on 'kmem arena' when running
_old_ zfs(8) binaries, due to an overlooked incompatibility of kernel
data structures.

If this happens, the quickest recovery method would be to roll back to
previous kernel by booting into single user mode, mount -uw /, then
copy /boot/kernel.old/* to /boot/kernel .

The compatibility code was tested against old kernel so if you are
doing 'make installkernel installworld' (NOT RECOMMENDED: new userland
is NOT guaranteed to work with old kernel) rather than booting to a
new kernel, then you would probably be unaffected.

I have a working fix and am testing it right now.  The fix will be
committed after I have done sufficient testing, and I'll send another
headsup once everything is settled.

Sorry for the inconvenience and thanks for your patience.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJTswQiAAoJEJW2GBstM+nsrxkP/iuyV5CYFtdBTaLONTEihGYH
Y5GpkrSy14Dikz+kAhCVBs6BlbEe94tpHvpL7tHKbIfmXQthWXj9WSW5F4PDrJGN
FOLTCGfS0IHfKe2hzAln8jJW+E5uECgL/mLlPVbiVFf1gLsbHgy+YoOS46Zmr4Ro
JmW7zChvIT2ZFvF8NJbP22PThf0R5IRPU9EKSbF1BioUUAePyh3Ml6TlGofCFAFT
kBSuLhRDw6p42SJ+tWHixdPKVFJHj4qrYtAdBCLTa/jeLYUuD1R0wfk3XyZHH6r9
8dfN0L4GVM9vjvh1qD9AC1TZy1IbwE1TsBnmipo2bU8BLxey8/TxdtimLC/JoXol
EcBfsO/GfOcLxvYEdD6ZstOZkAcGRfpxbe8ECfEia3od9bM11eCBo1OTdAHlCnGg
VxhoCzWGtL6Ma3EApZpOELG43wE+8N9tv3ylM30QTEcJ27SS03mewQUTnXPHFvZq
D0kSC6CSF1WfFIm5aS8NkkrZKazhdig7TasBXWq13p9u2p5wvAgPZlh2qWF4uBdb
oP1o/c9kbYyiduUrRDWwL6iGcD4YQG/9vpPntwH17B4r8i6Nf69E1KeU32FUDfbk
Lfn7lY9M2NgsCH5MQrWygR6NfeirEtpq0cGgu6FPnUHq0PAxkl9CtrjEBa3RPLXa
NCYxWySbYXV+I1jKYoZU
=eO6S
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADSUP -- ZFS users

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Should be fixed in r268116.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJTsyDiAAoJEJW2GBstM+nsz+kQAJQQHq6tlIhv3MrCzaEF9BWw
PKKdRPKXfBI4d2DD/WIx16q62bI/8T9iSEMLheyiVPpnMWor6AUmDIvZFAtWYuHD
i1SW5bPXKQUGgQXXhrRGH3goD/2K2YW+96yotBHn5Qq5yF6UHixK6aALE1y75UlH
BcYkkuytCSjdTyU7Ujk6unHjMMhg39I36sYt/dLCR6zh6vuMuuCYVNxn61iKVMEG
oXL/GZTQrzABQ4OBT3+kkbBvFX8UC9qHM9jP4pS/Z2ldf5DHemTPseDVgyAZi7Fq
feapjOGAlpgkE/IhXkYuOUEYgbnLhKuzZ8QuwNtyGNI+kjzDHvRZoo3NQa1AUCDg
sNaCh+IYK0A+gdL8yAboc2rUXebZsVpwP/fq2YtZ6BgZohDoT3p67yXwxBlf6GDw
7+niYeY3mZtddCIteLAkgB6a7jOO/HIW6hrmp6QeAHRUhS5e8OO5an08Wk8fY0n7
+gwFJPt9iidVpyQZwYQY9Gg0563azeII3j7MZy2bIYRFYHDfMWYt/JaBRS39kET/
Yw+lahYRwAO0WQFPy4e4c69BfL+k59B5QAi3c/u/8B9Mm7XEh1ufItcrfOl9KNRg
NpCiqOewtoUJSOwv7T1gr3eEwyKYQR0aFnKd4zPc2tCknZtUz4c1ylv6xX89mU6Z
TWkI7+SiBvF0gplro3Uo
=qMaa
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: svn commit: r267977 - head/bin/mv

[Xin Li]

[moving discussion to freebsd-current@]

On 06/27/14 15:23, Jilles Tjoelker wrote:
 On Fri, Jun 27, 2014 at 07:57:54PM +, Xin LI wrote:
 Author: delphij
 Date: Fri Jun 27 19:57:54 2014
 New Revision: 267977
 URL: http://svnweb.freebsd.org/changeset/base/267977
 
 Log:
   Always set UF_ARCHIVE on target (because they are by definition new files
   and should be archived) and ignore error when we can't set it (e.g. NFS).
 
   Reviewed by:   ken
   MFC after: 2 weeks
 
 Modified:
   head/bin/mv/mv.c
 
 Modified: head/bin/mv/mv.c
 ==
 --- head/bin/mv/mv.c Fri Jun 27 19:50:30 2014(r267976)
 +++ head/bin/mv/mv.c Fri Jun 27 19:57:54 2014(r267977)
 @@ -337,8 +337,8 @@ err: if (unlink(to))
   * on a file that we copied, i.e., that we didn't create.)
   */
  errno = 0;
 -if (fchflags(to_fd, sbp-st_flags))
 -if (errno != EOPNOTSUPP || sbp-st_flags != 0)
 +if (fchflags(to_fd, sbp-st_flags | UF_ARCHIVE))
 +if (errno != EOPNOTSUPP || ((sbp-st_flags  ~UF_ARCHIVE) != 0))
  warn(%s: set flags (was: 0%07o), to, sbp-st_flags);
  
  tval[0].tv_sec = sbp-st_atime;
 
 The part ignoring failures to set UF_ARCHIVE is OK. However, it seems
 inconsistent to set UF_ARCHIVE on a cross-filesystem mv of a single
 file, but not on a cross-filesystem mv of a directory tree or a file
 newly created via shell output redirection.
 
 If UF_ARCHIVE is supposed to be set automatically, I think this should
 be done in the kernel, like msdosfs already does. However, I'm not sure
 this is actually a useful feature: backup programs are smarter than an
 archive attribute these days.

The flag is supposed to be set automatically (as my understanding of the
ZFS portion of implementation).

However in order to implement that way, we will have to stat() the
target file (attached).  Personally, I think this is a little bit
wasteful, but it would probably something that we have to do if we
implement a switch to turn off automatic UF_ARCHIVE behavior.

Cheers
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
Index: bin/mv/mv.c
===
--- bin/mv/mv.c (revision 267984)
+++ bin/mv/mv.c (working copy)
@@ -278,6 +278,7 @@ fastcopy(const char *from, const char *to, struct
static char *bp = NULL;
mode_t oldmode;
int nread, from_fd, to_fd;
+   struct stat to_sb;
 
if ((from_fd = open(from, O_RDONLY, 0))  0) {
warn(fastcopy: open() failed (from): %s, from);
@@ -329,6 +330,7 @@ err:if (unlink(to))
 */
preserve_fd_acls(from_fd, to_fd, from, to);
(void)close(from_fd);
+
/*
 * XXX
 * NFS doesn't support chflags; ignore errors unless there's reason
@@ -336,10 +338,19 @@ err:  if (unlink(to))
 * if the server supports flags and we were trying to *remove* flags
 * on a file that we copied, i.e., that we didn't create.)
 */
-   errno = 0;
-   if (fchflags(to_fd, sbp-st_flags | UF_ARCHIVE))
-   if (errno != EOPNOTSUPP || ((sbp-st_flags  ~UF_ARCHIVE) != 0))
-   warn(%s: set flags (was: 0%07o), to, sbp-st_flags);
+   if (fstat(to_fd, to_sb) == 0) {
+   if ((sbp-st_flags   ~UF_ARCHIVE) !=
+   (to_sb.st_flags  ~UF_ARCHIVE)) {
+   errno = 0;
+   if (fchflags(to_fd,
+   sbp-st_flags | (to_sb.st_flags  UF_ARCHIVE)))
+   if (errno != EOPNOTSUPP ||
+   ((sbp-st_flags  ~UF_ARCHIVE) != 0))
+   warn(%s: set flags (was: 0%07o),
+   to, sbp-st_flags);
+   }
+   } else
+   warn(%s: can not stat, to);
 
tval[0].tv_sec = sbp-st_atime;
tval[1].tv_sec = sbp-st_mtime;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [rfc] /dev/devstat permissions patch

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Adding phk@ to cc since the 400 is from his changeset (r112001).

On 03/18/14 12:29, Maksim Yevmenkin wrote:
 hello,
 
 would anyone object to the following patch?
 
 ==
 
 Index: subr_devstat.c 
 ===

 
- --- subr_devstat.c (revision 263311)
 +++ subr_devstat.c (working copy) @@ -503,7 +503,7 @@ 
 mtx_assert(devstat_mutex, MA_NOTOWNED); if (!once) { 
 make_dev_credf(MAKEDEV_ETERNAL | MAKEDEV_CHECKNAME, -
 devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0400, +
 devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0444, 
 DEVSTAT_DEVICE_NAME); once = 1; }
 
 ==
 
 i'm not sure why /dev/devstat has such restrictive permissions.
 can someone please explain the reason for it? having gstat(8)
 require super-user privilege seems like an overkill me. iostat(8)
 and systat(1) do not require super-user privileges to work.
 
 and, yes, i know i can override permissions with /etc/devfs.conf,
 just curious what are we protecting from in /dev/devstat

I have similar change locally (except it's GID_OPERATOR and 0440) and
I think your proposed change would be a sensible default.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTKMofAAoJEJW2GBstM+nspPYQAKt8UiAqDBQwe0KTeH+ykpis
4EG4+oM43Ze8WCc3DgsbB+Dnq4en63z3SXyK7b78ZDN9xVzSmR4Cb6N0W63cuACI
4pE2Wl72P7v6eVgOrrgMJoRjI7BwX0nlOXKCvmwkHznbZSmpjgYTzx9ADYl1T4pP
SKtvgOtCyFXdpGP2adE8kJMRcFvBpbs61Y4hiSLwKE1lGywgLwYWfwkZMWFxGaNW
SU3H7qew5SRoFSF7ZhurhKENwyNR1EHEHXW+Se77TcTUzBIGCQop+78Od+Pxwi/v
KJYFKHS+Z72BRVbpaxowxQGRNSPzqC4dB2nMhrcQaOU8gXRret9OXCfBc7Fmrv31
ot0ewo3GapmNh/9ypMuYNQ+3XsjEmx96ckSeS0oX6lKLR2qIu8+JIMd9Oq0ogNHk
tMdjrX0dkpwedN9UiakbQq8Ws7u/XRfkQEUD8nsDu5gK+f3KlRldboA+GFAjYgX6
F+E4JHfRGWCFYQuzcl48Nkzg4Glw/r8HCHHE+cGqwXXPIGfjtwSIyGGZzw0Nb2Nr
jYfs4aYuGCwFmwUO/hVn47Wbbzmpr7rVbf7EW3PXwZuxPKTVxrEUpYklvCUmkDMi
jYEwQMcIfV7pI+nD1M9bocOk3TQ4nYWqlts2E6J+/qEC/ayXpo4kk/93swimj7wP
p6xDXw3sAX6Xaj0bZqcB
=ktrj
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: processes stuck in vmo_de state

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It looks like there is a regression (or a regression that gets exposed
by some new feature) that is related to time-keeping or timecounter,
although I'm not yet familiar with the related code to tell if my
conclusion was right or not.

The problem I observed is that when system boots up, it sometimes
hangs and pressing ^T on console tells me that sleep(1) is running
with 0 second out of 1 second, but the 'real' part of the output is
smaller than 1 or sometimes negative.

For some reason the console may stop giving any output, but trapping
into debugger would unblock it sometimes.

When sh(1) stuck in 'vmo_de' state, it would never recover from that
and a hard reset is necessary.

It seems that commenting hint.apic.0.clock=0 from my loader.conf would
mitigate the issue by the way.  I'll let the system sit there and do a
full universe build, etc. for a while and check it tomorrow.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTIXfgAAoJEJW2GBstM+nsc1EP/1VbIXscDeufiuAOj+UmDWV1
LsEb7n2M6qVYuL7sTTqY7R5svUATcVRAxG/jjXTHObvvCdB/8Gjk+51K/cCN5wIV
bKchxm2mv1ENbkFQJI3akntSbPeNk2iEAzORdvdcD/gkb5sIOxNGfeBp8/PtIO4x
3bKD2aRh7KdHzDWl4PdLiZSstLLuG1w6K0tFaoeWV0wu3e3GgMglK7kSq2H/ZWrn
WCtcw9kJOFuRF2kIj1UMygvqL6IDt2UF8As7A4wO/HKCTMm3xj5tHQzn6JZFoRwR
I2rILJtKrWRz8TUutV+ivD+2c0ZFpL6qn0ByQFtAPU3S1LQsgHZhgPNanvNVcmRQ
zz35CTWYRdxIq1JTZTA9zd/At9jRJtRYenJxgK9btJfwF9TqtmWmwPcOIkaMPr5T
uNHO5c+4gMQK96Km08cwkDCPoZTPNHJcAHgTlDMTM+TZ5vjVqyOI4wLcTwLecLca
yFJIaBhYektAlPJZoNwNJJsv3ReBF77yKMNzaNAUAM5Cfu06I1DGsxmrFTpvx+t/
nnIjHF0djACuJq8CpVHe4r8gdEUSSc180gzgyyyCJc8cHGc8JphOdY10gNBc6Cki
4h5cAdGUNov0+NkqF0tmEwKvDoCb7ASph7yJbVymt+2t2gh4ay8T1BBH2k50deG8
rsO6gv8qzRZshwyXlZd0
=DaxI
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

processes stuck in vmo_de state

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I have recently upgraded my home storage box (Avoton based board
running FreeBSD/amd64) from 10.0-RELEASE (patched with some ZFS
changes) to -CURRENT.  It looks like the system would easily hang when
I start 'buildworld', when this happens, I saw sh process stuck in
'vmo_de' state and procstat -kk would give me EBUSY:

$ procstat -kk 1752
  PIDTID COMM TDNAME   KSTACK

procstat: sysctl: kern.proc.kstack: 1752: Device busy

To rule out issue introduced by my local changes, I reverted them all
and used an unpatched 'VT' kernel (with WITNESS, etc. enabled).

In loader.conf I have:

zfs_load=YES
aesni_load=YES
hint.apic.0.clock=0
hint.atrtc.0.clock=0

In rc.conf I have:

powerd_enable=YES

economy_cx_lowest=LOW
performance_cx_lowest=LOW

The zpool I'm using is configured to use SHA256 as checksum.  One
zpool is created over 4 GELI provider and decrypted on boot but I
don't think that matters.

Any hints?  The system have flaky IPMI access so I can't always debug
from remote but would happy to provide more data if helpful.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTHr/cAAoJEJW2GBstM+ns6akP/1nsP8EH1zQ3v04fP4ZrmHp2
/7RgU3LH5/ydRuoiVvMnnJsK0XjZxi/Uu8kad1P/xi4FpqDmMTsQ5/8u/HKoGA9Z
Jik+LS79R7AApU4v64pWpPbUo7a9cs+JWH3gNWPCfqDHpg6FoP6B7sxrGdX4EY+n
UftSstk/UVSeoGaoC1sEgzsR3/ORAN+pQ7YbTlPJ7/RK8OIcrq8GTXTJpXaT0EoP
w0PQZtvPy5lWkB+KwAjrfF3QEr/G6pubLKbeq46eSwY0eDruL79zd7zozHcR5F9e
03tu17VM1QW41Y8zQT16cX8YEWI//5rk1wOQLZXT++jWyty9T9Ekt+d+H0mCPtjm
nIwLlyVQrfXPZnvFi3oZcOxgSdT3x3O9cUDQVebC4yIN4NPUWdyHmn6C57xwjW/h
efPoujEAkjPfD3iykWbLBXHGKyINi3KxU8ht1vndO4LdYKj+Dvtnz/IKs6VxnyT0
ld19nMkXZOjZc8Iftkx9/aLdlA1/BtkwIndod1J18kmMf7fWW9k7Mt8DyaGD8XUA
5QRIz3aeomF/+awTvVWTa07Rib5d4s6qv63ecGPEhNLjR6QA5t19b0W/8Ip2eTQD
B39ROUtBbSE2wzcpYwNdkHQEUiQSOzQithqRPvzXJZrUdEk+I3/4D1870r5BFCIJ
wL8/P0dmN1Y02vYFdJwy
=xBqp
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the strength
 of the hashing algorithm (when combined with my other feature
 request). Updating my bcrypt hashes from $2a$04$ to $2b$12$
 or something. Same applies for the default sha512, maybe I
 want to update to rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
 
 
 This looks like what we wanted. In the feedback you talked about
 some changes to your patch required to make it work, is there any
 progress on those?
 
 Derek's patches worked perfectly for our needs, but we're the sort
 of people who use vipw and our own utilities for user management.
 It wasn't until later that we discovered at least one other file
 would need patching to satisfy everyone.  We didn't want to employ
 the same copy-pasta method, so we asked for feedback about our
 proposed alternative.
 
 secteam@, do you have any comments?  Before we put any more work
 into this, we want to be sure that our proposal is an acceptable
 one.
 

Did you mean adding rounds capability, or transparent upgrade of
crypt() algorithms, or both?

I need some time to digest the whole transparent upgrade idea but in
general I think it's good.

Speaking for adding rounds, the only problem that needs to be fixed is
that the proposed patch makes it possible to create conflicting
configuration (passwd_format and passwd_modular can use different
hashing algorithms) and need to be fixed and polished.  I like the
idea of making it possible to use more rounds though.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGkLzAAoJEJW2GBstM+nsaVoP/017iARGzd++lCsfqyFDozGk
nXJjatlrIcRjrbCmVRT0lsHiK/hoYJ4zZPeOu8EXU1Qs0/wggGHYePX7+zEVob2S
YCxhqUOdG/jqrHnH8bljzWE/OtI7Y4PvFOLpsWkOE/uulssQfGDMSy8WJzFriqzv
GXjAEyFrGXCT29gW6ozTRfDfPSOfd4MhwewbMYAUykSqucMfkG4FaDAgLxv/XdRi
YmLQZuxxTzEqMYanZGq/0e5CvOwOuncd0aVxncJC8ZRcsHs5cqbzcyDkkRwvw/YU
g1OsLXiO08zej0rOz1E4pud8O6q3unG5dNcz9Y96oNo0fJONMrk9IetCUCHBsR8N
eyWJQyHL7wwwNlC5k8U9cOnsL3zxBv54N6bfWuWNNDpJmNrvgMr9LdPso+AX0gLD
y4RhVJeLCQbLrkQawoM1+Ki5N0mQibk9BBGXH/ZPScP1pNqVt9tqXp94N5ZPLV54
Uu4cn/2uKjtTjl76YFlCTvfwwiuWgds1k6CnKZIW8luOp4cG5XOoOSztONqWr6S/
yd7SLDV4f8PC7Fi1iSkSuVW5MYz1I7RRVR1Z27oV3e3UwXwIgqRjHJawNZqIgVe1
4lk84+fm75ULLfiA6bgkMCjylyWHCzrdOQt/Zx+0vyZOer5x2p4gZmnYAyV2EQIP
TM611j1UES6OUGFkfbWa
=4Qur
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote:
 Xin Li wrote:
 Hi,
 
 On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the
 strength of the hashing algorithm (when combined with my
 other feature request). Updating my bcrypt hashes from
 $2a$04$ to $2b$12$ or something. Same applies for the
 default sha512, maybe I want to update to rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
 
 [...]
 
 Speaking for adding rounds, the only problem that needs to be
 fixed is that the proposed patch makes it possible to create
 conflicting configuration (passwd_format and passwd_modular can
 use different hashing algorithms) and need to be fixed and
 polished.  I like the idea of making it possible to use more
 rounds though.
 
 This was deliberate for backward compatibility.  passwd_format will
 be used by default if passwd_modular isn't defined.  If
 passwd_modular is defined as disabled, then passwd_format will be
 used.

Well, my point is that the two shouldn't be allowed to exist together
if they can mean something conflicting.  Allowing passwd_format=sha512
AND passwd_modular=$2a$08$ in the same configuration creates confusion
and it's not good.

My suggestion is that we either have:

a) passwd_format and passwd_round (so that they don't conflict), or

b) extend passwd_format in a compatible manner to allow specifying a
round, or,

c) make passwd_format and passwd_modular conflict so we don't silently
accept it and instead bail out when doing pwd_mkdb.

 What do you think of the idea of putting this into libcrypt instead
 of pam_unix.c, and then patching pam_unix.c and pw_user.c to
 reference libcrypt?

Which part of the idea?  I think it's a bad idea to make libcrypt to
depend on libutil (for login_cap(3)) but we should probably provide
new wrappers in login_cap(3) to do the common things when requested
for various password manipulating tools to reduce duplicated code.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGmYMAAoJEJW2GBstM+nsDJ8QAJ+SM9WuRCXo1KYERj+/NJsC
VoP8psjZDZ7+hGOnG7iSwREYTLpxSEAw+sPnIhMgEy1Tg5jCcPvnIhCN/n+XPvaR
HG0o0TdTXL5ZVU4HyKuhNH6JGF9sWWua7Ki/jFguqE+1rdmivcbhrHMZNqOy8Djc
N/dnoCD/eN8K2/FiwP+KjTsYeSyisKFMyiGimQNcuPA7boF4ZBgJmmJqPASHzO9M
DVccoVPrDUip/6BdM+CNx/rNTry1sW3lMFSAuJkx+LENgulbhFz5R0aRGglzwGnJ
LocXVCZlTv0QB37qp9VIHCtTO5n8GxOx43dEtgjWF1cjDs+s+iKjEylX8NguUi0x
SjYu5WOw8xXNdE48QtqpT0N5aHSw9+CCwbrocGaOVYy11voGzo+r3C7jXprhQl8a
pgeiXH5pyBpo9Eh7+/aZdN3WcBjpaOVDnX8We7A9my1lVjxyuLXFyhC3q2OqUjvl
dX4ywKIjiFHSOz0ivzi+uQPx6PD05UuyrWUDING2PvMD/oMtg/hHbR5IxOHdmgPq
j7brHNOk7gxu1f/NFft/yfJAKem6JXjlX68z6/9jMrwxZ8jwTWWAtHrVBjo9/u2i
7ShSZlsEi62GewoIKRRVKvKmdX7Xl+Of/p/DZMTNGCJ9K5NnhEnLKWSp+I5VF0LN
fVQkTqpRaXglMVa/iRkG
=xSx1
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/07/14 15:07, John-Mark Gurney wrote:
 Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500:
 On 2014-03-07 17:06, Xin Li wrote:
 Hi,
 
 On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the
 strength of the hashing algorithm (when combined with
 my other feature request). Updating my bcrypt hashes
 from $2a$04$ to $2b$12$ or something. Same applies for
 the default sha512, maybe I want to update to
 rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903



 
This looks like what we wanted. In the feedback you talked about
 some changes to your patch required to make it work, is
 there any progress on those?
 
 Derek's patches worked perfectly for our needs, but we're the
 sort of people who use vipw and our own utilities for user
 management. It wasn't until later that we discovered at least
 one other file would need patching to satisfy everyone.  We
 didn't want to employ the same copy-pasta method, so we asked
 for feedback about our proposed alternative.
 
 secteam@, do you have any comments?  Before we put any more
 work into this, we want to be sure that our proposal is an
 acceptable one.
 
 
 Did you mean adding rounds capability, or transparent upgrade
 of crypt() algorithms, or both?
 
 There are 2 separate but related threads
 
 1) specify rounds for crypt()
 
 2) transparent upgrade of crypt() algo (or more likely just
 number of rounds)
 
 Can't the two be merged...  where 2 becomes a flag in login.conf
 instead of an algo fetch, and then if it's true, it does the algo
 fetch from 1?
 
 I really would like us to get 1 in, and then on boot dynamicly
 adjust the number of rounds depending upon CPU usage... obviously,
 a flag will adjust how long/many rounds the admin wants, but it
 would allow an automatic increase in security as faster CPUs are
 used...

Or by the installer/a tool that gets run when doing
mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster
after installation, and we can probably just write in the
configuration anyway?

Personally I'm not a big fan of making it something that changes over
time: the attacker may do offline attacker than doing it on the victim
system that revealed the salted hashes, so how fast the system CPU
runs doesn't really matter, except for how long a system administrator
is willing to have the user to wait.

 Anyways, how many people are still using passwords instead of ssh
 keys? Setting the time to be something like 100ms may seem long,
 but considering few people should be using passwords these days,
 it's less of an issue...

I'm currently using SSH key plus Google Authenticator for my systems
but all remote login via password is disabled.  I am aware of,
however, many people who refuse to use SSH key authentication because
they don't want to carry their keys, which is a bad idea but they do
it anyways.

 Xin Li, if you need help reviewing, testing, let me know...

Will do and thanks for the offer!

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGme0AAoJEJW2GBstM+nsXnkQAIYplCr5wMtENLYMQCDSrOFJ
7oxKbW2Iy1qPbbrjAb6mG0TY4ugJu2T6Sg6Wp1B+um2sWqWkNMr+8auHokwuB8+1
8NpnbcZarFvmA5tgVEsh+JcAJF1qZRFQDku+DbL9f/ZXFn/4CtmLkw5NS/kIKf/0
TIeXykNie5nFCS8ifT5Ai7vEHImOTwS4OEVzXoTQSdFGuLnHrToCnV7LpOK2ceIo
ssZ/0Go49tSzW8y3u2a0TZYTqMnh+0EzQFusWkulyCIam0NYjYON/3UY0/TpRgZd
ik2QLqKXaMZBPmi4EsmgpQr97MS0PRag4lahZZad2CckZmhiwWrHLyECf0Xk5i1W
+ACqSfJAzq+NeyDBW05y31qALeyUhm7+ALolSMDFkQMj5B7ra8qnQsbXVyG+DLmg
itpCWfXUpKPxclkvirnDQx89BE1MOYGYBbw69IR5NWcvF3f4EF177xplwAMjHhn5
EXUVIeTwjHYoYgMiZKX8aFgyNR2EX/g6JvZS8236HUbskLQl5AAKM0RA4aQkAFGW
206DYokJW3TnXNArm8kKJCZrYAJb17XyzN6HcY89N+GA0oEkehy2qyQiBVqtpjgh
6WsslScxAnQM3LG84un98cdipOWwQerTwfeji1yqfmik5oNuCm4D/Jlt6rvJBFLb
S5fUd1BQv+0woAKndGhb
=rCdB
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

nvi: tab can't be used in the context of substitute

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It looks like the new nvi version don't accept tab in the context of
substitute.  A minimal use case would be to replace all leading 8
spaces with tabs, what one would do on older version of nvi would be:

: 1,$ s/^/tab/g

Now, with nvi in FreeBSD 10.x+, entering tab won't yield the tab
character.  This seems to be a regression from older nvi version.

Is this a known issue, or did I missed something?

Thanks in advance!

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTExA6AAoJEJW2GBstM+nsRzIQAIfSS4isLQF4ex8ZzXQyE/0I
6Wia9FRHsa5gYt8phJxvWWbPCFeyHuqRjAkUEk+btuReZUSgEen27848v350hmBZ
DXMaJknryGIU1/f9x/XIjLYpmBOf58tN+rPId6psgFiH7NmdTcfAVg320fdAKlKC
gaMQHA3yGBC4ZTmopdj/e71gqmmjQuPe7kjyOx4fpdUWNKU+llIb5bUB1YWKYzyu
/hBBp8bewWoHjlH4qa0hSK/k6ef8yA8WmFEFldHZMQeXizQTmNxDKURZ9gZGOlYQ
m3mmeatE8KN+XVwn46p+iB9FcJu1dpzPq2QrepiWRzZJkxqOJhmjvQ0ZbZG1A6rM
jjQCRvKRi3PjzRPrGkBhhSZcRYmpNsYV8Anf4mUg5GxbJNKYzHAhKJ+dySc+nvqm
5xccpeGXpw/ji/A5OefoEzQSAhujVaBW5x64J28E7VwY5zw38K20wm0hv+KfWofM
OWc/gAB/1OYh5i+BaEb/O7RBoFIK+19MkJU3LFklBpDB2d8AE7vhoCbE4j9uujwB
8yFGNcl4up2z0ln+YhBYfTo8oc4iq6V55vNJYOM5iARKlQKYlhpPpyFgL+ssR4nY
+hAPSJ8qV2dMNqwdwW7oGhlzAMR/+i/s/TMeHyLCJijEcTpZZB/V7k/I6muzHnYg
p9f4hmB2r2f6/TaUyFmH
=5n4i
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: UDP Lite support

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/2/14, 10:42 AM, Joe Nosay wrote:
 On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com
 wrote:
 
 
 
 
 On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net
 wrote:
 
 On 02/26/14 18:52, Joe Nosay wrote:
 On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis
 bro...@freebsd.org wrote:
 
 On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay
 wrote:
 The last thread on this was in 2006. Has it ever been 
 reconsidered or is the likelihood of too many damaged
 packets the reason for not supporting? I'm not sure
 where to put this question. Apologies for the noise.
 
 You've provided next to no context.  What is the
 question?  What thread are you referring to?  If this is
 the usual UDP then freebsd-net would be vastly more
 appropriate than -current.
 
 -- Brooks
 
 Thanks. I will ask kevlo and maybe bring it up on
 freebsd-net. It has to do with an implementation of the
 JACK server using UDP Lite for transferring data.
 
 
 http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

  Looks
 
 like nobody proposed a patch?
 
 I think the concern was that this is not very useful in real-world 
 scenarios due to link layer error detection mechanism but that
 doesn't raise a red flag to me assuming this is sufficiently self
 contained feature as it would improve compatibility with other
 operating systems.
 
 Cheers,
 
 
 https://github.com/torelizer/jack_trauma
 
 Not my project;  but, I want to port it to FreeBSD. First is to
 get it to build from source. Use  your raspberry pi with FreeBSD
 to broadcast your tunes and all.
 
 
 
 Thanks for all of the input. The project is being reworked to
 improve the code.

Kevin Lo have a patchset but needs someone to do performance testing
(its impact on non-UDPLite applications), test with vimage, etc:

http://people.freebsd.org/~kevlo/udplite.diff
http://people.freebsd.org/~kevlo/udp-v.diff

Are you interested in working on these and report back?

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTE4+mAAoJEJW2GBstM+nsthoQAIW67l7yDfIPvxDsNIWWJcRd
8brFYCAOPYE4LpuLGjtSgy370aBe9JmwAm41tE4qF0WhGpcu6TLsKjgMGWa/lHCc
JId8+WBfbbQT8XJj/d+3oOETn5/rglvlRhJbnNIwaQpTXxuMC5oz2nGW7rIpIkaA
OHo0D20DzGj4nxrQvijZ7DsMkk3F+KJu/4p7M6lpsIPCakknW1WD7IHRfbZ4Oldz
2xH4HfIk7cAdA7i/YUNjlpSgWFQ5OU03J5HAYfC6W37wiGbjdBYf/PKVhJ8hz7+D
OCl+yCV00u4fCjlY6zXFea9pGr7Cl1P+sapwKDZ4g+NpNHxBUVY+ahbjQUHYON2W
sdzAsLpMMqavCr1o8mcXdm7IPRlLUK9QZUySC9DitPvoF8G2llTAz1mWa4/Oj7/S
JMiUERcaL5gdFN8EgEKkamFgLJguYquAjGtiowa51EMbnZG0Q2yWUcrEBFHWBEZT
RW1u6r4ChIrPE9X5ljfFpQyKG6jFhYFXG+iVlgTB7F2ZWhjPAXi/tLbBnvIcci1m
Md4XFm/bBJj/yNXdPuCi+CtvvdpZ/d4LQn4B7By5bIo1QjCb4Zx5n2Tq5xnYZUOI
CnSVnNSkwLbbrAVtYOVWnrSuwR33JQnqeGHdM+XYBBwKBRhrx+ZgFWD7N6Gm95PU
xXSxkgYVXI4sgi7Lh3Ia
=2Vmc
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: UDP Lite support

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/26/14 18:52, Joe Nosay wrote:
 On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis bro...@freebsd.org
 wrote:
 
 On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay wrote:
 The last thread on this was in 2006. Has it ever been
 reconsidered or is the likelihood of too many damaged packets
 the reason for not supporting? I'm not sure where to put this
 question. Apologies for the noise.
 
 You've provided next to no context.  What is the question?  What
 thread are you referring to?  If this is the usual UDP then
 freebsd-net would be vastly more appropriate than -current.
 
 -- Brooks
 
 Thanks. I will ask kevlo and maybe bring it up on freebsd-net. It
 has to do with an implementation of the JACK server using UDP Lite
 for transferring data.
 
 http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

Looks
 
like nobody proposed a patch?

I think the concern was that this is not very useful in real-world
scenarios due to link layer error detection mechanism but that doesn't
raise a red flag to me assuming this is sufficiently self contained
feature as it would improve compatibility with other operating systems.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTDrzbAAoJEJW2GBstM+nsJVoP/29XRcleHMnAVa1UOG0+CD2y
0e/pAmk5vay599gjmiKSAuTSeKNaawRF3FZP+QsxhKw/lNTYEHlppUw7FDc01NqO
pk1GsIu+mVuLlzZBNSuAkXdMMzJz5OKfY9GeK7Uw4iumiNP5LKpoC1RaYqLVASGf
JH6tqJdSVnD+apWxV/PF4orCXZECFLkQZhbgZe+2nni+te6OfzIbkjhBqn8ZIDNY
m9GbYwkTEATBDcMGgl9F0wBfcLhQLF4p4+TnsCguP0HAbxCtbZmt3SXe6Xt4y2YE
iHlO/qstGKrl61aiehtpasjiljJaN5ucmuv8XDGbix4cghiJCJAGmxXGxCoHs/Uq
vkn88wfV901pjYWPWf9HmTdjSmsck0k2+srWYlJuRymVKvMsL2mwPky+QL9SZ6MY
NJ8kXUl5szFwdN4OtO+1iUvVZNLkVDlV5bmnc5KOkciFRoLuTq1/f/xzGj/YDZpx
2DxjddVyvJ6YhrUSSAGoOcdxIpDejKfVif0ANoocsKLAnTHtNxdB76doJH4wBl+W
LAl9a9IqVOiefFe9qb6tZky3lft3HUe4XvLJPraKTfbvA9VAKPqZbc2Z8eeoqb49
LPC2n8WnlnaXB9KXKSWTLXbdcY2L+HnAt2+DEv4viSyKSXQg00aEbm+R95h1pTz7
oMv/8VGg5akyRQtkTTIx
=ukUF
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [head tinderbox] failure on powerpc64/powerpc

[Xin Li]

/zinject/../../contrib/opensolaris/head
 -I/src/cddl/usr.bin/zinject/../../lib/libumem
 -DNEED_SOLARIS_BOOLEAN -std=gnu89  -fstack-protector
 -Wno-pointer-sign -Wno-unknown-pragmas  -o zinject zinject.o
 translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs
 -lzpool /obj/powerpc.powerpc64/src/tmp/usr/lib/libzpool.so:
 undefined reference to `atomic_swap_64' *** Error code 1

Sorry for the breakage.  I'm testing a fix right now and will commit
once validated.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSxLupAAoJEJW2GBstM+nsYnQQAIlQhsYIff7FuDmD363hHi30
tbCXGPz5gonV6NYQ7tPGD3ododeUdMUXNx10y1e7f/7oG4qKKm787/RPUmaY5aeW
Y3CheoEEWvOIHMSR0HgSX4yc+XoND1LLLRdUn5diUG8AdQ6dCcK0m65E805Z7zpI
B6Yk6TBH8sT6kGIgcLUDTf6+N5DpymKyNcHGSRoyfJi88e6tHtmse4l0XLrfWklk
KWpw91qAQmdPuaUM6xUbOgHDK0G5xwI+Zcx/OyUkQ3NiCYFm8oO/fM/vTKgAerW5
sEFh58CgBWCr8RUVsBwbyeeZ/T7yKFPs53ZEMj2QZxpQzgRhz6emR1O0PxrRfgRC
H//VFSarhbuEtb4j17LLSby/jyBDjoc7vEC/MuoE28ovOF7ZlXF3OdzwsOtB5Q/r
nU+j/QmrGF+vmNh4FCr3sn/+yPdAxHoGkz9xyhBU7Sbomh5SJSjXxzS0D8uPpXIj
orxsl6itEUX2L8BdMJgx8ZpZaj/gB+XnYOxv1XYKovHsBUwHVw8vv0cwI6rfltKA
EvczKl/lkfu4SYeRtSIX080Id9dIihBSXVgOQ0nL813fpFfqGBaBEJd7MU6UDmAx
eNqrWJO6DU4lteFzUvBOqPsvXus9vppsm9GY/4OgC14b3PZYE/dXEsZSuz+JU9u2
0ynVIiFYxaI6RXR/pxjd
=lHMA
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[PATCH RFC] Disable save-entropy in jails

[Xin Li]

Hi,

I think we shouldn't save entropy inside jails, as the data is not going
to be used by rc script (pjd@126744).  If there is no objections, I will
commit this changeset on January 1, 2014.

Index: libexec/save-entropy/save-entropy.sh
===
--- libexec/save-entropy/save-entropy.sh(revision 259828)
+++ libexec/save-entropy/save-entropy.sh(working copy)
@@ -42,6 +42,10 @@ elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf 2/dev/null
 fi

+if [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ]; then
+   exit 0
+fi
+
 case ${entropy_dir} in
 [Nn][Oo])
exit 0

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC] Disable save-entropy in jails

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/24/13 14:36, Paul Hoffman wrote:
 On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote:
 
 I think we shouldn't save entropy inside jails, as the data is
 not going to be used by rc script (pjd@126744).  If there is no 
 objections, I will commit this changeset on January 1, 2014.
 
 Even if it is not used by an rc script, it might be used by some 
 userland program (running as root, of course) that knows about the 
 directory and wants some fresh entropy for its own use.

Why a userland application would want to use these?  Would you mind
elaborating what kind of use that would be?

My understanding is that the saved entropy is used for bootstraping
the system only: any applications that wants good random numbers
should just use /dev/random because relying on something saved on disk
is the worst way for someone who wants more entropy.

 Is there a problem with saving the directory in jails? It
 certainly isn't taking up much space.

No, it's not about space.  What I am concerned is that it may have
wasted entropy: each time (every */11 minute) the system would get
2048 bytes out from /dev/random per jail.  This deterministic behavior
may trigger reseeds earlier than wanted.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSuhBlAAoJEJW2GBstM+nss7YQAIYcMq6GflgY7T304J+bdoll
TBYA740eQy6iNoyGTSh4VEeKh5GDrwX7GAM5EshrDQMKfagwm0smdYbpWYklUc07
V6sy8uuIvhxM6GOxQqP86tyzMCu9EtiVzfDakKJz1IL8pzVuu6Kbq/CxdA3fC3G4
qQraPMHvpYRsXiOn30B8i0kojMgRAxMOTZRZ4HRByiuZrsVdFYlNxMoh76reMO40
dSq1UPmQMjeDqlEKkAxpR1nN67ebVgFOuXl8O/YjOvNJLnCtcEr6xQcUQso8cbeR
j7WCgUmiqCKcoPcE6Bf43Qp1otdeLVP+qoeogWcAPIPrK6XL2wxsVxj6Y44fbkeW
Ttfw5iXwR7yt7MSZHP4eXdycZuSRswQUzp9TEyAxclMTE+aHFd0B/C4lViTKTfU1
dglg5goplXCAVCFPXek+R9UnFCFSc9GvlSL2K2d5TNvjDiVdNGc9SDyO7u0qNxV5
Eo+X8W2oR05jiZNHitJyalZSWd62+rn5+R5Pwf3A0hv9opimNX2xVTpfVU7y7DoK
dJpPo7S8GvVKK0JgnP9yOvAD2wIjNnLz0T+hmmnygPA+xkrbVZIYdxMxrMQ491Dm
/3dej3hDg5panfU7kxjpVmA+mTQbaFwQJeV0gSJDeswBl8JeAwhycchA+rgpPWCN
qEziEr9sgMQKdc6JyVf9
=b7jA
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC] Disable save-entropy in jails

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/24/13 15:26, Paul Hoffman wrote:
 On Dec 24, 2013, at 2:53 PM, Xin Li delp...@delphij.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 12/24/13 14:36, Paul Hoffman wrote:
 On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net
 wrote:
 
 I think we shouldn't save entropy inside jails, as the data
 is not going to be used by rc script (pjd@126744).  If there
 is no objections, I will commit this changeset on January 1,
 2014.
 
 Even if it is not used by an rc script, it might be used by
 some userland program (running as root, of course) that knows
 about the directory and wants some fresh entropy for its own
 use.
 
 Why a userland application would want to use these?  Would you
 mind elaborating what kind of use that would be?
 
 I don't have a specific application in mind, and certainly not one
 for a jail. However, I'm not sure what the value in removing a
 feature for a jail if we don't know if anyone is using that
 feature. Thus, my question.

I see.

 My understanding is that the saved entropy is used for
 bootstraping the system only: any applications that wants good
 random numbers should just use /dev/random because relying on
 something saved on disk is the worst way for someone who wants
 more entropy.
 
 Quite true. Note, however, that we don't delete the saved entropy
 after booting and add it just before shutdown: we leave it there
 for some reason. I'm not sure why a jail is so different of an
 environment that it should be treated differently than a normal
 (non-jail) environment. Maybe there is a reason, but I'm not seeing
 it.

Definitely not for seeding some userland applications :)  If the
application wants secure random numbers, it should rely on /dev/random
because it has more entropy sources and is less predicable.

 Is there a problem with saving the directory in jails? It 
 certainly isn't taking up much space.
 
 No, it's not about space.  What I am concerned is that it may
 have wasted entropy: each time (every */11 minute) the system
 would get 2048 bytes out from /dev/random per jail.  This
 deterministic behavior may trigger reseeds earlier than wanted.
 
 I did not understand this. What changes in the system does removing
 /var/db/entropy cause? (If this is answered in a longer article, a
 pointer to it would be useful to me (and maybe others).)

No, we are not talking about removing /var/db/entropy.  What I am
proposing to do is to disable entropy savings from jails.  Here is why:

The way a PRNG works is that it uses one or many entropy sources to
feed its internal state, and generate a series of pseudo-random
numbers from the internal state via a PRF.

FreeBSD collects entropy from several sources: Ethernet, interrupts,
software interrupts, etc., as well as hardware RNG that is available
to the system, and use all these entropy to derive the internal state
of its PRNG.

When reading from /dev/random, one essentially consumes entropy that
is fed into the random device, and eventually it would cause a reseed.
 In an ideal world, we would want this to be less predicable and
controllable from a potential attacker.

Normal applications tends to read /dev/random in small bites, and do
so in a discrete and nearly random manner, assuming we have a lot of
processes running.  Saving entropy, on the other hand, happen in
larger chunks at a determined time.  With multiple jails running, one
would have a lot of big chunk reads from the /dev/random device,
making its behavior more deterministic, which could have bad consequences.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSuiElAAoJEJW2GBstM+nsW8wP/iJOuLK7gl4xcaZ0WQM9ZbcF
dRo9Wuao4aytIPNcI7BcRvFPkQIVd/N6tIwmi98Uy3vLG1FAkZlSkPT9IXGWKwtX
lil1tfPlGt4+lMPirD7AFkk99DUfMO7nY2TuWw6DG6w6gfbzoBkZfxEZTTBv5XXl
ZtNMsw2CR6xOOY2YTx3HobSnnr4UzwBzT1nif+7W/pYTwQB2LNbnwnVqoDsGn9mv
MMO/9WnYs3/smYDQdChmmybGws4/P53sGjIzds/dv3Gg8ce8fu/ZAPFGCKRzr+uL
CTBCBuaeiRM/BhlG3n6H0o4updgDAOQ0PDH0q6rMXwcg7ODz6tW2x7lJ5hwm/Z2B
nrPCr5p2jk5KE8ULjINypYyIgjbPcgDTZN2ToB+a83RvIf9/DlRMzyOA76b0KsEs
AnygLyG/ZoBqy5s4nrNbLyNERx2T7hrcrGtK4qtMIdpYQK8T/etZZvIebLVPvCGK
kGG9AEgiUYHgG0RASg0LtsiJLi0/LjGzwZl+/Q3lqjrcmV7m6jOLAMT349aWOep9
GXPOcBXxh4emEz2qAQRSn7Y+Xn0T80lIPHb/6Wz04pOIhlMwQPR97X+IfAtybHFf
7HVk4GfhQC/zDiwPKb5Qcx7JRnE3wBZ2vnVaVzPCk9uPImyvMYKDKiNfFl2zlFfS
AdjiKPaOGw2kAZA55dC3
=7Ruf
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-RC2 current wireless link aggregation not working correctly

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/13 09:34, Allan Jude wrote:
 If I am am understanding correctly, Dan and Nikolai say that just 
 running 'ifconfig' brings the lagg back to life. Why would that
 make a difference at all? Running ifconfig with no parameters
 shouldn't be changing anything.

I don't really believe these claim.

I had similar issue in the past and found an 'arp -a -d' would fix
it so I didn't pursued further but I think this would be an
interesting problem to get addressed.

If I would take an guess, I would start from making lagg(4) interface
to initiate one or a few gratuitous ARP broadcast when the active port
changes.  Some switches could use this to kick out their (outdated)
memory of where the port is.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSsPQLAAoJEJW2GBstM+nsyXoP/RCeHdu1PVCooIUxzjhqWMJG
3RyN9i85O1WYpgZwHCSC9mkFKM6GjEIiyaNKCvdYzN/k+d9aCQSXIShgIGutM6ie
hFD4GCGrevjquHCddpULlUE+iwj0qIJWSyRMusUgo+ya+Bc/4H+szoxTndXaaamz
CPkZMuzga8kEApXgMvImGfsqB8FqqFNtEELlRmISEHb04iAGqUv6HwoL1DhqEZ3I
tQQi73JvuCU3Lfbp4CDI0IeTzlAoARBX/mWFjlDm7CA8clu4PzIVhdsRxRUhXIId
ijI8432al9XXt0m4+4LIKmJa6DlyvQ3pIZDFodryQ1za3PAaF7IheILFKPi9BAwi
Tn47X2+2XYXx7ZS2S22R7KRgeORZqj2uYZifs/xsNwkBCsyntYZgH+c5qYU7TWb/
tWRi9c5uVFskoPx4JL4W3ctgPvN7TpvKeCBLZTBdLQjy9WT6sqhxChxS57SFT5AH
kTOWNEA0PqWjrrqRlNO47TL/aTg3Js9S4KxIZ2+hHSkDAlMxGi9rHzyHYPQKxJ1V
lLmLGN0ZRYGGKa4Yn2OBAy16q/I2jkLE0Nkb0u1V3EEMkKQWp6pcro/Kb9Hrirfe
n6zrFVyzLTIgNpr9C1+By1CxAmJfg73cIoobJSjNDZ2+EpY+FRDdhKYip3xtpNfA
QFmabonocmaEohNcC8me
=mSYS
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-RC2 current wireless link aggregation not working correctly

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/13, 11:28 PM, dan_partelly wrote:
 
 What claims you do not believe ? Not important anyway. This is 
 engineering, so you need not believe, you need to know. Go and
 replicate the bug. You will know then.

I don't believe in merely doing 'ifconfig' would workaround the issue,
it does not make sense, plus I have tested and it didn't work for my
case (iwn+em on my laptop).

I'm aware of the issue but thought it was compatibility issue with my
own weirdly setup wireless AP at the time, and looks like it's not
just me, but I'm not interested nor have time to fix the problem so I
replied the thread and offered what I have tested as a workaround in
the hope that it's useful for someone who is interested and have the
ability to fix the problem.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSsVEkAAoJEJW2GBstM+nswTsP/Rs0hdyXNejf2Z98GbSGns0n
lsI+UmjwWUSg0h+8QzCce7/80mwEw0tZH1btoRr6I0tPKXwdUYDO2C3LPM2a/jSV
hvN6aay0ppnldtsqMZcuDv1OznSGfEIt0A04/m/RUTDBYaPKY+F1iqZYNE960zes
u6mbR2elpAUCHjpV3lEchnP5V1v/yLpVziGYabR4WLwohtlOMGVbL92ejLAeKVnr
Ar7SiWA7GVar6lSGBWyyGwoErveb8TaZxRiSKgjHuvciMLgy+KrlyxqZq6gNd7nP
isBDMEe2NsnUawR/gfcxvvzpyHTPYPtSlEJjejdbnGlP4YGy5BT2vm3HqyAgK/iX
N1iRBhx8zuH9UDNN8XiSuvuYuxAw9OfeBoh/2aGifj5dcrEP+IeyYUoAWBoXgny+
IcoitmUwYE4xLduLnIpf2b5KG8Yw1r2bKoZJVOw8+ixJAqCWR0xXONcywB56MXoE
8r9A11D6ASdRmozKjcEQH9+j6/4VuVeydCBfXQSZHIlVL3pTFZAlH0Q0JSZq4NXA
Pb5YGcdYDONi3gPxNIvUn1WeqTfpgJhGveKV5PhI3NY2d+GEB3fBBuBhvlAlrwxg
CPCqH4YC0sntvqMqcOooz44OfiLpB1ARGGTwtKATLNIzpS/iMsS1swW1NZEeaN19
uFZw/dY3w5uhDQ7u2Buc
=4ByJ
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH] Haswell Kernel Mode Setting

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/11/13 14:29, Neel Chauhan wrote:
 Sorry if I sent a similar patch before. It didn't get accepted so I
 am sending one now. Enjoy.

What does didn't get accepted mean? :)  Since this looks like a
PCI-ID only change that do not affect other existing hardware, if it's
not an explicit objection from a reviewer, I think it's Okay to just
go ahead and commit the change after a reasonable timeout instead of
waiting indefinitely.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSgWqaAAoJEJW2GBstM+ns7pgP/iTu4VI4UYgj/nCmSblhVsjH
kO+YPaBoXkO+3e7GQ+E6LKqnH3Byjvc8WZH6/fBA2qY9Kfjjte0gJIG8t7Fu34IQ
SRiQaErRYUyXCHIIfgjrvRVIrk7bvwe70awnMVQOIktmzdJ4i6cxxEzsvsLqd5OY
Argc77bBkSSa0w/QiWR04bG119u/WVyEhNnJ1XdYq3IzJqTb/fkOYAHm/JaWkhSy
F8Vj2bxSr9fiKD36wb/kV5cFC4ZNP/SounurAhMTMaHfWAGJE/KuUy5aRP0bHzOY
FwcpAAqIsuy13tBKXXsDNgETTJrbnSGQp7AM7BMZJXkX7kfX8SIfpmG0rjoJH02G
V3SDdvMmS/x4sIrKmgwQsUT1MGNGdJtD0Xzx27ng0BVSItPKXkB1azxvRkfRE03N
yyWX4C0IQg/U/UgkV3jwe+8LAezPXNRbnKD5QX165g+EnAkRmferAT1/kNnV1zV/
G7eU7x9TTml8fCi0g5Oid3smL+BiwGOkZA36r+Js+lQd5Pmkn3GUJw1qx3vNTWKz
P6UHeRzSppez1aWx6NigvPH9qUz+HpaN4aWf+Zzl9MFbKcEohtzT8LaBCB/F1BdG
pvGOXcCb+BeUy/IBW+Yx7zal5Ri7YIRIAb2hssqACVBOYwbVzMQidEWuSERMyNdo
gMcNWZw+kXLE5wCklwm9
=zbWH
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org