Re: rand() is racy in multi-threaded programs?

[Conrad Meyer]

Hi Andriy,

On Wed, Dec 2, 2020 at 11:34 PM Andriy Gapon  wrote:
>
> On 03/12/2020 01:20, Conrad Meyer wrote:
> > Rand(3) is explicitly unsafe to use from concurrent threads without some
> > external serialization, even after initialization. I’d suggest using a 
> > different
> > API.
>
> thank you!
> Just want to check, unsafe in terms of bogus results (with respect to
> randomness) or unsafe as in may crash?

Well, unsafe in that it's a data race, which is formally undefined
behavior in C (if I understand correctly).  So anything could happen,
including a crash.  In practice, you would probably see something more
like the former (bogus results, e.g., multiple calls returning the
same number because the state wasn't updated atomically, or something
like that) rather than a crash.

Best,
Conrad
___
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: rand() is racy in multi-threaded programs?

[Andriy Gapon]

On 03/12/2020 01:20, Conrad Meyer wrote:
> Hi Andriy,
> 
> Rand(3) is explicitly unsafe to use from concurrent threads without some
> external serialization, even after initialization. I’d suggest using a 
> different
> API.

Conrad,

thank you!
Just want to check, unsafe in terms of bogus results (with respect to
randomness) or unsafe as in may crash?


> On Wed, Dec 2, 2020 at 13:53 Andriy Gapon  > wrote:
> 
> 
> Specifically, concurrent "first" calls to rand().
> There can be a moment when rand3_state is allocated but not completely 
> set up
> with initstate_r().
> Is this a known / documented issue?
> Should we try to do better?
> 
> P.S.
> I am seeing this issue from time to time when running ztest program (from 
> ZFS).
> I guess that it uses rand() just because that's what OpenZFS did / does on
> illumos and Linux.
> 
> P.P.S.
> Just realized that the problem can be relatively recent.
> https://svnweb.freebsd.org/base?view=revision&revision=357382
> 
> -- 
> Andriy Gapon
> 


-- 
Andriy Gapon
___
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: rand() is racy in multi-threaded programs?

[Conrad Meyer]

Hi Andriy,

Rand(3) is explicitly unsafe to use from concurrent threads without some
external serialization, even after initialization. I’d suggest using a
different API.

Best,
Conrad

On Wed, Dec 2, 2020 at 13:53 Andriy Gapon  wrote:

>
> Specifically, concurrent "first" calls to rand().
> There can be a moment when rand3_state is allocated but not completely set
> up
> with initstate_r().
> Is this a known / documented issue?
> Should we try to do better?
>
> P.S.
> I am seeing this issue from time to time when running ztest program (from
> ZFS).
> I guess that it uses rand() just because that's what OpenZFS did / does on
> illumos and Linux.
>
> P.P.S.
> Just realized that the problem can be relatively recent.
> https://svnweb.freebsd.org/base?view=revision&revision=357382
>
> --
> Andriy Gapon
>
___
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"

rand() is racy in multi-threaded programs?

[Andriy Gapon]

Specifically, concurrent "first" calls to rand().
There can be a moment when rand3_state is allocated but not completely set up
with initstate_r().
Is this a known / documented issue?
Should we try to do better?

P.S.
I am seeing this issue from time to time when running ztest program (from ZFS).
I guess that it uses rand() just because that's what OpenZFS did / does on
illumos and Linux.

P.P.S.
Just realized that the problem can be relatively recent.
https://svnweb.freebsd.org/base?view=revision&revision=357382

-- 
Andriy Gapon
___
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: dtrace: give %'d a chance?

[Andriy Gapon]

On 02/12/2020 18:52, Mark Johnston wrote:
> On Mon, Nov 30, 2020 at 03:50:53PM +0200, Andriy Gapon wrote:
>> On 19/11/2020 16:57, Mark Johnston wrote:
>>> On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:

 what do people think about adding
 setlocale(LC_NUMERIC, "");
 to dtrace's main function?
>>>
>>> That seems reasonable to me.
>>>
 My primary interest is to (pretty-)print some numbers with a thousands 
 separator.

 Not sure if any other LC_ types are worth bothering.
>>>
>>> Maybe LC_TIME?  libdtrace a couple of date formatters, %T and %Y.  A
>>> locale-aware formatter might be worth having.
>>
>> FWIW, I've just discovered that despite what
>> http://dtrace.org/guide/chp-fmt.html says about %Y its output is not 
>> dependent
>> on locale settings.
>> A quick look at the code confirms that -- pfprint_time uses ctime_r.
>> But %T (undocumented at the above link) indeed depends on LC_TIME as
>> pfprint_time822 uses strftime("%a, %d %b %G %T %Z").
>>
>> Sample output in C locale:
>> 1000
>> Mon, 30 Nov 2020 13:47:24 UTC
>> 2020 Nov 30 13:47:24
>>
>> The same formats (%'d, %T, %Y) in uk_UA locale:
>> 10 000 000
>> Пн, 30 лист. 2020 13:43:11 UTC
>> 2020 Nov 30 13:43:11
> 
> So to be clear, there is nothing that needs to be done for time locales?

Sorry, it was I who was not clear.  The above output is after adding setlocale()
calls.  Stock dtrace always operates in C locale.

> In any case, I'm fine with adding the %'d formatter.

It's already there and it delegates the work to the C printf.
Hence the need for setlocale.

-- 
Andriy Gapon
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

On Wed, 2 Dec 2020 at 12:52, Warner Losh  wrote:
>
> even if lldb isn't a complete drop in replacement (I've not used it at all, 
> so I can't say one way or another).

Quick comment on this point - the FreeBSD Foundation has been
sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still install the gdb
port or package for the familiar command line interface.

There's no FreeBSD kernel support in LLDB yet, but it's being investigated.
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Warner Losh]

On Wed, Dec 2, 2020 at 10:44 AM Ed Maste  wrote:

> We currently have an obsolete version of GDB 6.1 installed as
> /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
> some basic information from a kernel core dump after a crash. If the
> gdb port is installed crashinfo will use that in preference to
> /usr/libexec/gdb. If neither exists it will not perform any analysis,
> reporting "Unable to find a kernel debugger."
>
> GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
> support all of the architectures that FreeBSD does, and imposes
> limitations on the FreeBSD kernel build - the continued use of DWARF2.
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.
>
> In the fullness of time we may use LLDB to extract the same
> information, or provide other tooling to do so, but I do not want to
> block GDB 6.1.1's removal on this.
>
> Please let me know of any objections or comments.
>

I fully support this action. We kept gdb on board for 12 (and 11?) for
crashinfo as a transition to the new gdb port and to help smooth over bumps
from moving kgdb support into that port. jhb@ has done a great job in
getting kgdb moved into the port. I use the port exclusively these days for
all the kernel debugging I have to do from panics in our fleet (although I
have some minorly special needs so I use a special script to fit into our
buildenv vs deployed env). The current gdb in the base can't cope with
anything more complicated than 'hello world'. It's broken for threads. It's
broken for much of the code clang generates. It's useless for kernel dumps
(even tracebacks are unreliable in my experience). There's little to no
value that having gdb in the tree at this point.

I also agree that none of this should be gated on lldb. gdb in tree is so
out of date that we are much better off removing it, even if lldb isn't a
complete drop in replacement (I've not used it at all, so I can't say one
way or another).

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

Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

We currently have an obsolete version of GDB 6.1 installed as
/usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
some basic information from a kernel core dump after a crash. If the
gdb port is installed crashinfo will use that in preference to
/usr/libexec/gdb. If neither exists it will not perform any analysis,
reporting "Unable to find a kernel debugger."

GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
support all of the architectures that FreeBSD does, and imposes
limitations on the FreeBSD kernel build - the continued use of DWARF2.

I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
switch the GDB knob to default to NO in the near future. If the
crashinfo utility and related man pages do not already include
references to installing the gdb port/package I will add those before
making the change.

In the fullness of time we may use LLDB to extract the same
information, or provide other tooling to do so, but I do not want to
block GDB 6.1.1's removal on this.

Please let me know of any objections or comments.
___
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: dtrace: give %'d a chance?

[Mark Johnston]

On Mon, Nov 30, 2020 at 03:50:53PM +0200, Andriy Gapon wrote:
> On 19/11/2020 16:57, Mark Johnston wrote:
> > On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:
> >>
> >> what do people think about adding
> >> setlocale(LC_NUMERIC, "");
> >> to dtrace's main function?
> > 
> > That seems reasonable to me.
> > 
> >> My primary interest is to (pretty-)print some numbers with a thousands 
> >> separator.
> >>
> >> Not sure if any other LC_ types are worth bothering.
> > 
> > Maybe LC_TIME?  libdtrace a couple of date formatters, %T and %Y.  A
> > locale-aware formatter might be worth having.
> 
> FWIW, I've just discovered that despite what
> http://dtrace.org/guide/chp-fmt.html says about %Y its output is not dependent
> on locale settings.
> A quick look at the code confirms that -- pfprint_time uses ctime_r.
> But %T (undocumented at the above link) indeed depends on LC_TIME as
> pfprint_time822 uses strftime("%a, %d %b %G %T %Z").
> 
> Sample output in C locale:
> 1000
> Mon, 30 Nov 2020 13:47:24 UTC
> 2020 Nov 30 13:47:24
> 
> The same formats (%'d, %T, %Y) in uk_UA locale:
> 10 000 000
> Пн, 30 лист. 2020 13:43:11 UTC
> 2020 Nov 30 13:43:11

So to be clear, there is nothing that needs to be done for time locales?

In any case, I'm fine with adding the %'d formatter.
___
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: Issues with USB-C external monitors

[Ali Abdallah]

On 01.12.2020 17:10, myfreeweb wrote:
> devd (really drm in the kernel) provides hotplug events (system DRM, type 
> HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
> How xorg does this I have no idea, as I don't use xorg.
> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I 
> don't recall anyone adding support for that there.
> With UDEV it might work?

Actually Xorg on FreeBSD with UDEV is compiled with
--disable-config-udev-kms, thus the server never calls:

udev_monitor_filter_add_match_subsystem_devtype

for GPU devices, and thus libudev-devd doesn't forward kms events to the
server. Actually Xorg doesn't even process them, even if the filter check
is bypassed in libudev-devd (udev-monitor.c:261).

Basically Xorg is missing bsd platform code for drm devices, on Linux
the code that implements that can be found in:
hw/xfree86/os-support/linux/lnx_platform.c

Compiling the server with --enable-config-udev-kms, the server expects
to have the following functions implemented

xf86PlatformReprobeDevice, xf86PlatformDeviceProbe, DeleteGPUDeviceRequest and
xf86PlatformDeviceCheckBusID.

Those are fairly easy to implement to enable Xorg to listen to
libudev-devd drm events and to re-configure the drm connectors. I have
already some scratch code, will test more and probably send upstream.

I will probably also add devd code for that, as I use xorg server
with devd on my FreeBSD 12.x machines.

Thanks,
Ali
___
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: Issues with USB-C external monitors

[Ali Abdallah]

On 01.12.2020 20:33, Poul-Henning Kamp wrote:
> 
> 
> When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but
> xrandr shows it with ever increasing names "DP-3", "DP-4" etc.
> 
> For now I've given up and use the T480's HDMI output instead.

I've noticed that as well, the sys.class.drm.card0-DP-3 disappears and
sys.class.drm.card0-DP-4 is created instead.

I need to drive two external monitors, that's why I need the external dock.

___
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: Issues with USB-C external monitors

[Ali Abdallah]

On 01.12.2020 11:08, Scott Long wrote:
> I have a work-in-progress to support Thunderbolt, but that’s not always the 
> same as just DisplayPort-over-USBC.  If your connector has the Thunderbolt 
> logo, then it’s Thunderbolt, if it has the DP logo then it’s not.  Even then, 
> the Thunderbolt component only controls enable/disable permissions and 
> bandwidth partitioning.  The graphics chip and DRM code does the rest of the 
> work, and it sounds like the problems here are with those components.

T495 has AMD Ryzen silicon, and AMD never associated Thunderbolt with
its Ryzen platforms. The dock connector is just a USB-C.

On dock removal, the devd events (system DRM, type HOTPLUG) are
correctly generated and received by libudev-devd, but then for some
reason UD_ACTION_HOTPLUG is not causing the X server to re-scan drm
connectors and to re-configure them.

Will dig further into the issue as I feel it should be easy to solve.

> 
> Scott
> 

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