Re: CVS commit: src/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09.08.2015 15:29, Joerg Sonnenberger wrote:
 On Tue, Jul 28, 2015 at 05:13:34PM +, Kamil Rytarowski wrote:
 Module Name: src Committed By:   kamil Date: Tue Jul 28 
 17:13:34
 UTC 2015
 
 Modified Files: src/lib/libc/stdlib: reallocarr.3 reallocarr.c
 
 Log Message: Compatibility fixes in reallocarr(3)
 
 Except it is worse now. There is now an obscure assumption that 
 CHAR_BITS is 8, spelled via 2 == log_2 CHAR_BITS - 1.
 


What do you think about the following patch:

Index: reallocarr.c
===
RCS file: /cvsroot/src/lib/libc/stdlib/reallocarr.c,v
retrieving revision 1.3
diff -u -r1.3 reallocarr.c
- --- reallocarr.c  28 Jul 2015 17:13:34 -  1.3
+++ reallocarr.c16 Aug 2015 20:57:06 -
@@ -50,8 +50,6 @@
 #endif
 #endif

- -#define SQRT_SIZE_MAX (1UL  (sizeof(size_t)  2))
- -
 #if !HAVE_REALLOCARR
 int
 reallocarr(void *ptr, size_t number, size_t size)
@@ -70,8 +68,7 @@
return 0;
}

- - if ((number = SQRT_SIZE_MAX || size = SQRT_SIZE_MAX) 
- - number  SIZE_MAX / size) {
+   if (number  SIZE_MAX / size) {
errno = saved_errno;
return EOVERFLOW;
}



I was benchmarking it on a modern amd64 processor and there is almost
no difference between (number = SQRT_SIZE_MAX || size =
SQRT_SIZE_MAX) vs (number  SIZE_MAX / size) for small 'number' and
small 'size'.

The reason to go for it is already prevented the 0 division with the
check in the free(3) case (number == 0 || size == 0).

In 90. division was an expensive operation, today not any more. I
would prefer to let it to be optimized by a compiler, not by a human
for a special or an old hardware with expensive arithmetic operations.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV0PuKAAoJEEuzCOmwLnZsLmoP/3xbcc2XNXhyGmP/aZvZ9FTo
9ScYE50pV96J+UPmf5hM2kG7jUV7nIfPc3vSdP1UUi7Lg5B5gc6KKx9gCqPOn3PC
4HOcCLRRcO9R2VwNuTYSp5h1xRGgrKXt8fE5FEUA5WrMQ5+LgZ9nWQc1ZnLZFd38
Hir3o1AcjjLcLC2Xttq0CD9Uw7i1F5nUPMKfVgYo4CzYbLrTB+oXhymLOzqEcc2Q
N9aqUsFhCVphz24hH7KQX/sSbAykl6mBvv3JIGrurk6mby4UC2H26lEx+6LZw2eu
6TylkXrAmgC64Y5MhJkYnWDtKuwN09fr+zc0GsGpy4ZIEWD7rz1VCaovhLw2g7iV
u0ccHqe6ldLUzneqEKOIQJFTQU4ROM6KVhzCOrg4tTZw5MPd12ARYJz9hkdT9Nz1
clkH9+YMFZpRW9OnAze3U1APevmhP0qt7mpiWiMn8I49t+2fpMg5gt63dAyGLODw
tHK8IsCwuDp9TcvOI2iza+XhYpbBcjRoevTTciOa6xKougp62h+mCpIWrXGECKIz
Gomx3nzmIVAAVPIOoZAvwzD00n2vlVjjYEtw8fZ4q7QJueSYghhW/WSe4N6ZQDxD
OaTY0eeEOYHm9yGfy/L8sd5+jU7ehRbBHJ5MtAkFzO07HTeNmlMWtV1PV7VfAByB
e4MfvasHmIj5l7QQVyAo
=4eOR
-END PGP SIGNATURE-

Re: libutil shlib_version lossage

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14.08.2015 08:53, Christos Zoulas wrote:
 In article 20150814032236.1da9260...@jupiter.mumble.net, Taylor R
 Campbell  campbell+netbsd-source-change...@mumble.net wrote:
 Whisky tango foxtrot?  Did someone botch a cvs admin?
 
 Looks that way, let's verify first and then we can fix it.
 
 christos
 
 

I will investigate it and prepare a proper patch for review to address i
t.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVz35MAAoJEEuzCOmwLnZsu0YP/3dc2QjTbb4yCVPer8l3Gudg
Hn0a8pyrt0qjBhSBCBquE0bG4QX6tWYvEE3v3+mSrH0Da68R5bCaGw/MUpkYYeZW
z3gKBszDlYKYndIIlFX7++TxDA/smBl7R5kZjqGjc48SLd2BMxrLf41h8YU502+t
5XbQleS6yM9Km42IdTWxEemFp39GMauJEh6lGZda8ld7iWettXCcS960D4Ooigeb
jIz3LXJa86JHt1V+uW8NhtDw8+6DPFBGM85cfZ29JOMF10FkvdhZ3uUInuVA583C
YErBkUfpl8Aa+5ROVnodCCEd7tAbFLz2kPDEwM2TUGX1I03+m0duNdkKbP8zEy8+
g96QeeXBe3Dwrd1iCeJo3vHIeAe0ygGbK0/6LKo/qYyYwYtTmOkb6AiWlb9mV26b
3EpfYv1yYj5bapRDs+cl9pAYGJJ6EyhcEVlFw/n4LHp30QJSBATE1T3BoWwHABOk
bjoU2w02+G1RSvJ89DenP+TPZNrPxRNpu19xGh8818tB4gYxETo4/oICtvDQtzXZ
knCn1yDsFqMvoihWkj/t9NnIErdJNmgywRZBgpIsZ8dIhz6idxs5HnFnFiao/lI0
YL38UrTtnvot+ojEiBOWeJoH17r68pE2Vg1ARKpiR+A0uDbf0arCiD2c85mrdc+1
k7w1XTQxL5DnWMUqVkWN
=SIzK
-END PGP SIGNATURE-

Re: CVS commit: src

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26.07.2015 09:45, matthew green wrote:
 matthew green writes:
 
 Kamil Rytarowski writes:
 Module Name:src Committed By:   kamil Date: Sun Jul 
 26 02:20:30
 UTC 2015
 
 Modified Files: src/distrib/sets/lists/comp: mi src/include:
 util.h src/lib/libutil: Makefile efun.3 efun.c
 
 Log Message: Add ereallocarr(3) to libutil
 
 ereallocarr(3) wraps reallocarr(3) and embeds return status
 validation.
 
 Older version reviewed by riastradh and christos
 
 please bump the libutil minor version due to the added
 functionality.
 
 thanks.
 
 this also has broken the tools build it seems:
 
 http://build.tastylime.net/builders/kernel-amd64/builds/5022
 
 for instance.
 

I'm on it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVtNcdAAoJEEuzCOmwLnZshCQP/ivzsN4ypZmU2bONlIqNmTGa
0/uhbpl7/X9Xgzk6/2RItdS36XWPmIJ03lDSm3QRncfQUMLRPMqpSWaHQ1sDIcPo
AGgO9RUuZ+63PoRX9HdPk5/jW72QUMDKgYK43oWk419MeiDJ/P2dIyncqubgeQ3V
fG8vM/h7y7d+7QDJ90My0Tl3f0wO2824K621tV+A8zhTTvSW0XwcRXD4w8+NFn6g
HBbuT5nz2J0LVlu8Gw5tU4zIj2v5zY9r1bp819E5CnOfLDlApzVp83cx8NKqGmgR
OEJgyY6Mok1CsXzN2y0OrOzG6b5/CWLpqi/EVQ/z+AEU2NaEi3XRti+VkHQHhohM
s6XGmUOjFq4Efz74WKdhpU+AfJDiob23PcbTAj96LSdFRPzf+84w5FAo6ctIrddj
lrgAo0/0wM6pyTw8UUxkFdB4Qabpr7fvMus1wD7SHOxikav384OioTPwCBgMrN36
Ss+Oysv+OrvqgEcnHR3V5j/8L9Tb6o93eUjcGE5SeXXckDy0briAmw4Xs5L8+kZ5
MsRKhoXqldz+2Um6S86oWj8g6zsbfofm+vlHp1oNZgofeuJ+ilUtNFQiE/9GIL2G
4SbTA9hdcGF6as9GrM3ttQ+ZsTbY4gGK1mvQI8Iqo45fJWsvaHlwiNn/0je1h3Xk
03S82ZbZsi/h/N6Cww5B
=NBOp
-END PGP SIGNATURE-

Re: CVS commit: src/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16.07.2015 10:25, Pierre Pronchery wrote:
 Hi,
 
 On 07/16/15 02:04, Kamil Rytarowski wrote:
 Module Name: src Committed By:   kamil Date: Thu Jul 16 
 00:04:00
 UTC 2015
 
 Modified Files: src/lib/libc/stdlib: reallocarr.c
 
 Log Message: Reorder memcpy(3) and save errno
 
 This chang is for safety as memcpy(3) might change it.
 
 I am not against the change, but are you sure memcpy(3) has any
 chance to change errno? I think it would actually be a bug if it
 does, since it is not meant to fail, and it is a pretty essential
 component for error recovery (writing messages...).
 
 This is not a definite answer but: $ find
 NetBSD/src/common/lib/libc -name memcpy.S -exec grep errno {} \+ 
 does not report anything.
 
 Anyway, HTH,
 

I will use this function outside the NetBSD world. My intention is to
push it to libnbcompat. Before that I removed the possible
thin-skinned point.

The C standard permits memcpy(3) to affect errno(2).

I'm not much interested in debate what platforms do it and whether
they are sane or not, this change just cuts this discussion down. Last
year the GCC(1) team debated the support of platforms clobbering
errno(2) in the memcpy(9) function.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

Just better to do it now then wait for timer bomb to explode.

For most of the users this change is non-functional.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVp4OIAAoJEEuzCOmwLnZstk8QALw6r4V+JDdJvi7ru4dqGWwm
5HjnM+YbmEjcbcunctZtPYXNLLl5c2KedBDaSmrZ6AJ192Xk7SCFR2jzZmQ/nO+G
xXp8yAp1bIqh/wM+FXtaeQYq7pc8z7ckvi9E7nreoife+kHC6fDuvhp9i6As5DoK
Vhqp9XaZfdCX7aWdkwlvf1gO7CpuBuvFNBD+9m80ganJ6Bwk/0Lv+hp+r2q6kQCC
9quq5GfAYwMpB0VVb2mtEVOo2wxBeFFk866lyiiZH6jf9PI8C2Igg7S2ljr463kv
p/DDgKWlY26FLkmagOaLyIGyQpni0Gw+XZg8qwAJ/H8UETls6XLLk5XPS5FbaoFc
xEgNVHYU3RxO/1eDyvtQGuKuoDfTFqIXVnsvBqhoGNBNSENwcgwc0AXcnWgbw/IY
CgIh80FUfrWvbnoxajgBGzVzOs4yjKpWcjbVrJl2tfjLCuQ/99EFptBuBBZWaquO
loqlqCO5MTWPeG3GUecUXBDZK6CJVf/Uz9II6YBSOXjTzIkGbVIev0beKMmXePEJ
KcxkStaFvVYIJ9Qbyzhd0/o03KZp2BM1tu1bIseHd1L9JNtleNLMSxb6WFDx69D2
ggmGgA9w4ySM7N/c2BEuKUurRRd4uElj2eJAnifSkaLhLg8184XK/0OFvLMVyFAJ
PUpnHTlLhZ9N7y3hn2/Z
=cZYP
-END PGP SIGNATURE-

Re: CVS commit: src/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 19.07.2015 20:56, Joerg Sonnenberger wrote:
 On Thu, Jul 16, 2015 at 12:12:27PM +0200, Kamil Rytarowski wrote:
 The C standard permits memcpy(3) to affect errno(2).
 
 More like it hasn't explicitly ruled it out. That might or might 
 not be seen as an oversight, but pretty much any compiler uses 
 memcpy(3) under the assumption that it does not. If you really care
 about this case, please raise a DR against ISO C and get a 
 clarification of the intention, before further changes to src.
 

Thanks.
It is also for the consistency with lines 63-64 of the same file.

Regards,
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVrBMIAAoJEEuzCOmwLnZsvUsQAIMgD3/aL6pld6VZ521n0+kY
zsv3axqXVO4JwoEYj0g/B4W6vuuWBzkKrSVLJm6Hf/Xjv0ZfpvWwFbT9cq3p5zuH
3uYPhjxNuPM7HTSJvLaQUCK9X0kyB1DEVlF31UOqYE5Tg6zyH9I8SWWYH9uZx/kJ
2Tc3Fl1Vx/p9veyZTsQ0tddEokC97ABTo8tLkBrr7NTimi9G0WfgEMN9fcuMjzSt
BdsnEoYI/w3JZZOcE8HhmgAIJ3osX3Ys9RVmmKJzoIyQr5Sp61hrTsPBM4bx8n55
twbFygd7Fuo/Uc8muVhBDRRBkTLogwsDUz5htP0ydYy0PpLdGeZe1q+4yVUJwxMC
vQqwFDDk4lUvfhq/Rn3RPr8otE8/W9iltihkMF7BngDyWW+mQM4MjGmgfaesR/Kc
9CoIy1zylwD+Q9FcPQFNh0zMcxxtUQ0I4TFsMTaMZ6C2FzNWkuWp5rn2kvL/Io4c
xhiGZA+czOeEZBj9CNA3fWLAzA3R3UFWk66n8de8iWeWmWgBxv4d7LnHL5J4il/u
B/Pm5thHDHTBeSwsf2nAuCady6MXivxZJLSyAodXHDpWLNgBsOXCg7cTasXnCQOL
Oqeavut0qB6HeeaaOM2YhiO/eprE7kfA1UgxyXgysaBw23LiYAbaetKJ39K4A8L6
9mL4NLMc3uEvanz5goIZ
=Mayj
-END PGP SIGNATURE-

Re: CVS commit: src/lib/libpanel

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27.10.2015 00:09, Valeriy E. Ushakov wrote:
> Module Name:  src Committed By:   uwe Date:   Mon Oct 26 
> 23:09:50 UTC
> 2015
> 
> Added Files: src/lib/libpanel: Makefile _deck.c above.c below.c
> bottom.c del.c getuser.c hidden.c hide.c move.c new.c panel.h
> panel_impl.h replace.c setuser.c shlib_version show.c top.c
> update.c window.c
> 
> Log Message: First cut at ETI libpanel.  Lacks man pages and
> tests. Not hooked into the build yet.
> 

Are we ready to hook it into the build?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWSQ6eAAoJEEuzCOmwLnZsRrAQAIoNwdXoUdeDqRQiKUDhGP8G
Ogr+uLx4HETgHO8K7SgFIqzYLBZsfmBoYEeHqQWcfJTKhi7JMay084GrqiKGXaX7
exsy2pZgcYSqkU549ktl8wQQsj+Zz5vXt6Bm0xy3HOGFwxkL9HMd/SY9HlBSdYKM
6HcoCwv/u3UfAZOLZqSj+J91daRb0Pa7DsDlDsM8mrs+PgvTvRyiLwFlQzP06hXP
ymK4MXr6UwjRD9BZ3cMbxvtiLN5FKcNY8Gfj6p7fbHd73PxgK+eIMR9Wiz712l31
vaqkX475XFOG85+7AogKgEX6Hmh97+mg9yhwG4kWlcbokFBnNH1dnkH0SxColP66
WkaZHRSa/je22au4kodSnqCrBjc0FUqtsDIUss/T7SerMXlt75SZP2cILW3TtUf4
Nx+4LYRrI/VBitpexa6nYnMHz1MppLMQXHpuwST9bHGYIPqxZ3Wh0lj6sKirWvUV
8dcJUwkuGmYZmCHGUP26nCVdAi32hRLGhvjPZz/DzQhn+K0Z+FmBgYg/7Ne2eaZF
S4sxoeP+ayaGz/8sXsMONoz/g5xULHMvkjSb/HyTkvpKxd0FW4HDl1wKf5KrxVAk
Z7U+uaHCPXuCK2RgbRO7TbWAiw4bvEvAWB7yLg5TnH/NM/l7neuZFNI5jDT5o4zs
XBMUjuZPK4E2CyFpkvAw
=0W3m
-END PGP SIGNATURE-

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11.09.2015 03:23, Christos Zoulas wrote:
> Module Name:  src Committed By:   christos Date:  Fri Sep 11 
> 01:23:37
> UTC 2015
> 
> Modified Files: src/sys/kern: kern_exec.c
> 
> Log Message: On non absolute exec pathnames, prepend the working
> directory if possible so that we can provide in most situations the
> absolute pathname in the AUX vector so that $ORIGIN works. The
> following are implementation issues: 1. deep path execs still don't
> work (can't provide path to the AUX vector) 2. the returned path is
> not normalized (cosmetic)
> 
> 

I confirm that this commit fixes my local elf linker issues with the
$ORIGIN magic. I can build and run these kind of applications.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8xUoAAoJEEuzCOmwLnZs01AP/2I9qX4ttWmZYgCO29GnU9jm
jT/FOysRlkNSG6ALj8qM1SfOMUcbRfyDeQ9nnEhsBBZNaXyJPDjhtP03mHocD4Sc
NHJIHNuYyM0eqg29PxWlVPQgSdt77T8vh7oYbxjO1XxonwJDVYwO3attJjsr0FG8
QvLWnFTNufXrmb57RPAK74VXKMknIN1erc7e1A58uDPLkoIYf2+CbliLpH99e8VH
Bhu/5UR0xp6JfMUodeILrz5eXEp3m6wwgyAbsoVnbxiIBVqTKNI9MhnrBp08CZDK
2UbMn5eAlBeYD/7sLiykuAe6HfxcTNfWBKQ9l4b2IWqOY4/Jq5fPGoOcBHv03Q1r
Ya/+fVjTC/dBz0hhKvU8ClKpngbZhcwqodB2qyoI0j0mWvHiE1BS8CI2ZSJ+Ij2h
VLCUyJqrHd6QsQFlhSGA1SLBnPDHnymbOn/Dsaz83cOBW+yyA64S3UmwI6rHAApl
c5h2knwQa5KY1k5jAeVmTeft1lY/wl45r6DnIQ1qBir+9lg8M8c7NBZYOOflUpgB
1nveW4zKTn/2K+wbj35LoZ/KMxk9NiZVf+VXE60X9uclqYXZujp8LUu5XElSaAWc
gc9VHRdDg9EmjgCm+Urwa+cc5ydJ/9ztRKkGMKWS+pwmPzPZ6u+b3xhNjzqQR7bG
4xfTbrFuWD2GlgNmPSZv
=y95E
-END PGP SIGNATURE-

Re: CVS commit: src/lib/libpanel

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16.11.2015 12:25, Valery Ushakov wrote:
> On Mon, Nov 16, 2015 at 00:00:48 +0100, Kamil Rytarowski wrote:
> 
>> On 27.10.2015 00:09, Valeriy E. Ushakov wrote:
>>> Module Name:src Committed By:   uwe Date:   Mon Oct 
>>> 26 23:09:50
>>> UTC 2015
>>> 
>>> Added Files: src/lib/libpanel: Makefile _deck.c above.c
>>> below.c bottom.c del.c getuser.c hidden.c hide.c move.c new.c
>>> panel.h panel_impl.h replace.c setuser.c shlib_version show.c
>>> top.c update.c window.c
>>> 
>>> Log Message: First cut at ETI libpanel.  Lacks man pages and 
>>> tests. Not hooked into the build yet.
>> 
>> Are we ready to hook it into the build?
> 
> Sorry, I don't have time.  Feel free to.
> 
> -uwe
> 

The libpanel(3) library has been landed. Thank you!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWUVSxAAoJEEuzCOmwLnZs5qQP/3IeGhQP6qF21z4B0ycyqoW+
fHWCB/JSHApiciI3tTCmdOQAzvyyBaQ4E6wbXjcGwgJpnKE5ucieDSKcYcBJbpR8
ME6DNY5hSVbUpgKci+ZGFaN89j5JGnYwhzME7RhLXYf6P1HulGdZsEBzpHr2xUMU
mJSnZ7NaY8qCd4q/GpXt8IxDt1CCSEJ5W9ScViaXXoPslB1K7EwlJoT9ZJqEYspZ
T9nneMC/SmnbzzHY8Tm2yXR2auTCmH4DumiAEPDfiFuwTswcMamwOJ8IUBAX0fYW
+2zzv+eytkuhuXDNBeHr7g+8GJcxTHx/Wq1blgaKbhCPEjFVy0ywIP4D5X2fpoFs
eMOaGs/Y7ooQQLO0ZdB/c0qiHtNyCe+MSfWrobEmDNe1yXST2kXuluaT1ySsE12y
cZjcL0HJkip1nhLvO5fMZyHNpSEIGwk+187pRIcZglD4sU2YXxohrGNH8/QTbNI5
IVpZZrFAP11IKWUqvC7ioLHq1p9FiHdWyAoffise30S5cyH1LOoF/ryZXy/bYeZH
l8lwkkkeJ4g4WJTWnYp9a/oXLmvkx5dpyi6zN2sF5kD8+I8LR5E73VjTdHGWrPD7
TaHN3+BWbSzQkqNNlU4H0/gT9p7lUBQ8rgW/wM9Q3D7a6uXPcWNiUZ4cfuiBupdz
5bU62g6Ea9ojy7FlI8b+
=u5z0
-END PGP SIGNATURE-

Re: CVS commit: src/common/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12.01.2016 22:43, David Laight wrote:
> On Sat, Nov 14, 2015 at 06:40:21AM +1100, matthew green wrote:
>> Christos Zoulas writes:
>>> In article <2015111344.ga13...@britannica.bec.de>, Joerg
>>> Sonnenberger   wrote:
 On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas
 wrote:
> Module Name:  src Committed By:   christos Date:  Thu Nov 
> 12
> 17:23:51 UTC 2015
> 
> Modified Files: src/common/lib/libc/stdlib: _strtol.h
> _strtoul.h
> 
> Log Message: Recognize 0[bB] as binary (base 2)
 
 Based on what authority? This is a ISO C function and that
 doesn't allow binary input. I am quite concerned about
 changing a function used that often, especially as it can
 break a lot of existing code.
>>> 
>>> I don't think it will since it will only affect conversions
>>> with 0[bB], and the OS/X code is doing the same, but I will
>>> revert it until others catch up.
>> 
>> the problem is that something that was "0b" always
>> came out as 0 before, but now it doesn't.
>> 
>> that's a fairly major semantic change, i think i agree with joerg
>> that it has a high chance of breaking existing usage.
> 
> Worse that that, some code might be relying on getting a pointer to
> the 'b' and continuing to parse the buffer.
> 
> Not a good idea to change it.
> 
> David
> 

The 0B or 0b syntax is a part of C++14 and part of C compilers
recognize it for at least a decade. It's common in other languages
(Java, D, Ruby, Python)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf

But it's still not officially supported by strtol(3)-like functions in
C/C++.

I would support it as a local extensions, it makes sense to me.

There might be a conflict with strsuftoll(3) (hopefully once replaced
by strsuftoi(3)) for '0b' but it's a narrow-case and not from a
real-life usage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWlqd1AAoJEEuzCOmwLnZss/oQAMLZVikU+NlqrC+j5Qyq8w/J
u7KEvgXP4j/uo6tWkc1q9sbMDyrH9FIF1T+wtpAppmxU1k2B2rFTSs/sqcDq+B1V
8pJBZt97+eyra7fbc9uy6pP8jZu9Wuvay+Uu0zoJxSlvThmF5+uPpLPA8D/lvKcP
Gvnx9aBDk01Hloltyg7D1A7VpH0zcc+EH+f3oIe4Jckkkm06OulhN5YacXszyaF2
14X77cqFVTsB5v1+UWDoi95e10X8My5UAYgn9efJHk+b75BxQAggm4kJ8YG84OyV
CjuqpuakWQ+N/3tQarV7laLjCxwuX7CVe5qDpzmCcCTLO6wIIk6gXOqOwQHn9/Qm
0SFW/aHhocXn7l4eTjMd/rjpuzScgrt21PB+UcrHQAkBjaXZB1w1MvvgYsHcseWm
OXSVeR0W+wPplgegs2dCpUa9VGh/m3fxbHOTW+Ac4rBwRKk9BjalOUhj/IG7Acy5
5pl+YAwmCsIcSsHI1JUsL+aJVgLz0jsC+oqT3VyV7txz7Z5OXpRB+j/LW7tHYg0F
gIXLGwka8mToTtRxuNeVby4vITsjR3qaJmhVlX8j0mqHsbWxwnc83mUcmmT6vnkc
tvDbLt022FS1TvEEFEInDeMhe0QX5j+rqTb3ft5rYww4CmEnOiTvYRAsh2LqLPhJ
3VLpHPeT9ouMUwVzHIrm
=fXts
-END PGP SIGNATURE-

Re: CVS import: othersrc/external/mit/micropython

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14.01.2016 02:38, Alistair G. Crooks wrote:
> Module Name:  othersrc Committed By:  agc Date:   Thu Jan 14 
> 01:38:53
> UTC 2016
> 
> Update of /cvsroot/othersrc/external/mit/micropython In directory
> ivanova.netbsd.org:/tmp/cvs-serv18307
> 
> Log Message: Import micropython version 1.5.2 into othersrc.
> 
> Micropython is a python3 implementation that has been optimised
> for micro-controllers and small embedded systems.  It also has a
> "unix" port. It has an MIT license.
> 

Does it mean that it's prepared to be used as an extra set (located in
othersrc/) of sources in the NetBSD base?

Is it going to be evaluated for inclusion to base (next to Lua)?

Is aimed to be a fork?

Why not in pkgsrc?

Thanks for making it clear.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWmkjbAAoJEEuzCOmwLnZsF3gP/RN9BpGOMNkTk7veDcEEXSxE
D+KJFOtRmg+lyocuK8heDt3KbKO6UaLBc1n30DMKYZ/u1wcm6es2XEe6kmqTcQLf
KZ3WH1QQwfpQpcuq/T9Lvo9ZZQwn0ui4ZGEERARadsJOPYL5IFOczVvJFJGgMlNT
qWfSYxHYbKnxa9Ftn0oGsKHJPmsCUxvgKIpCKC3hUl8gbYw9H5wCyk8w0ZVWaor9
fmqiNxbU6Mq4p3agNS3TLa/ISmetal8RqPFXsLIslUTA1dfDwP/xjxaZYBZEB54V
Is9M1JxVnM7cOUAjmd5e/0fuxPMl3XA69lofBNkESdh/jYFGd+lEn59slfRSmlT/
e8DKyWECS7dyjx2ne1XdUPrZ3tgwIGQmaYfAi7cqaabOQIaxh3e08Blo4LE+s1zU
+3KZuojj5Z/jkYdK27E7XuROMslIuVIIYHWr8xjV08Pc1zoLbQXzm+VITtJltKWi
4c4VjjE2uTEfaP8N3MDG7JlyUBa8snAoJU1XDjdetoXW2cE3OOEpYJREGfjreT6i
J+VlU+7Beu0VbJwnGBd7lkoZzdkC84Ph9nop190iMsuUKmXLvFMHgdkVsWhm9Hu6
aGaTimrxBXGQYNosqxZgy4dOJU0aHFD/T/XCr623UsQY/pQ3TDfDe1V+6kBmm/7o
woGjrYDz+QkVMe1HEvUp
=lik+
-END PGP SIGNATURE-

Re: CVS commit: src

[Kamil Rytarowski]

On 04.08.2016 08:43, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Thu Aug  4 06:43:43 UTC 2016
> 
> Modified Files:
>   src/include: limits.h
>   src/lib/libc/gen: sysconf.c
>   src/sys/kern: kern_sig.c sys_sig.c
>   src/sys/sys: signal.h signalvar.h unistd.h
>   src/tests/lib/libc/sys: t_sigqueue.c
> 
> Log Message:
> Realtime signal support from GSoC 2016, Charles Cui.
> 

Thank you very much for this work!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 17.02.2017 15:03, Robert Elz wrote:
> Date:Fri, 17 Feb 2017 01:42:59 +
> From:    "Kamil Rytarowski" <ka...@netbsd.org>
> Message-ID:  <20170217014259.e68fef...@cvs.netbsd.org>
> 
>   | Modified Files:
>   |   src: UPDATING
>   | 
>   | Log Message:
>   | Note TRAP_HWWPT -> TRAP_DBREG rename manual steps for build.sh -u
> 
> I think you can remove that entry from UPDATING.
> 
> It is bad enough that the build system cannot handle dealing with
> files that used to exist (but are no longer referenced anywhere in
> the Makefiles, or elsewhere) - but understandable - it is not easy
> to arrange to remove something whose name is unknown (though it could
> be done, at a cost) and some other (files changing type, etc) issues --
> but it would be a serious problem if a file that is supposed to exist
> failed to be regenerated when a file it depends upon has changed.
> Dealing with that is exactly what make and makefiles are all about.
> 
> I could see no reason why the relevant files in this case would not
> be correctly regenerated without manual intervention, so I did an
> update build without removing them manually (I had done a full build more
> recently than the 20170211 terminfo update - and while I did not look to
> see why that one required avoiding -u, it might be another that did not
> really require that), and sure enough, the build system worked properly,
> the siginfo.c iles were correctly regenerated as expected.
> 
> There is no need for any unusual manual intervention here.
> 
> kre
> 

Thank you for your feedback. I was required to manually remove old files
in order to regenerate locally new siginfo.c.. as I faced a build error.
I think it's not worth the effort to build the distribution twice to
reproduce it again, I will just remove it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 17.02.2017 22:47, Robert Elz wrote:
> Date:Fri, 17 Feb 2017 22:28:32 +0100
> From:    Kamil Rytarowski <n...@gmx.com>
> Message-ID:  <1f5043f2-b004-f558-bd66-cc96675ab...@gmx.com>
> 
> 
>   | Thank you for your feedback. I was required to manually remove old files
>   | in order to regenerate locally new siginfo.c..
> 
> That means you didn't do "make includes" first before building.   build.sh
> does.
> 

I see, I will use it in future. Thank you!

> For whatever reason, the siginfo.c file depends upon 
> ${DESTDIR}/usr/include/...
> rather than ../../src/sys/...  (perhaps in order to allow the same 
> Makefile.inc
> to be used from multiple places, I am not sure - the usual reason for this is
> to depend upon an arch or machine dependant .h file, which this is not.)
> 
> kre
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/distrib/sets/lists/tests

[Kamil Rytarowski]

On 25.02.2017 06:31, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Wed Feb 22 09:09:49 UTC 2017
>>
>> Modified Files:
>>  src/distrib/sets/lists/tests: md.amd64 md.i386 mi
>>
>> Log Message:
>> Fix build of !x86 ports
>>
>> Mark debug/usr/tests/kernel/arch/x86 as MI directory.
> 
> this should be created by mtree/NetBSD.dist. not not
> pollute other platforms.
> 
> 
> .mrg.
> 

As discussed with martin, I will refactor these tests to remove MD
distfiles.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/sys

[Kamil Rytarowski]

On 08.02.2017 19:01, Maya Rashish wrote:
> Module Name:  src
> Committed By: maya
> Date: Wed Feb  8 18:01:24 UTC 2017
> 
> Modified Files:
>   src/lib/libc/sys: accept.2
> 
> Log Message:
> Document accept4 in accept(2)
> 

In general we don't put POSIX/standard and nonstandard functions into
the same manual pages. I think accept(2) should be split with accept4(2)
and paccept(2).

Currently there is no man-page link accept4 -> accept.

Since we are here - are we planning to introduce ppoll(2)? It's very
similar to homegrown pollts(2). Porting of it is the same scenario to
accept4(2).

codesearch.debian.net gives 233 packages for accept4(2) and 191 for ppoll(2)



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/sys

[Kamil Rytarowski]

On 23.02.2017 12:33, Robert Elz wrote:
> Date:Thu, 23 Feb 2017 13:48:10 +0300
> From:Valery Ushakov <u...@stderr.spb.ru>
> Message-ID:  <20170223104810.gw20...@pony.stderr.spb.ru>
> 
>   | > From: Kamil Rytarowski <n...@gmx.com>
>   | > In general we don't put POSIX/standard and nonstandard functions into
>   | > the same manual pages.
>   | 
>   | Where did you get that impression?
> 
> Good question - Kamil, see:
>   man 2 wait
> for a counter example (there are many.)
> 
> kre
> 

I learnt it from this thraed:

List:   netbsd-tech-userlevel
Subject:Re: reallocarr(3) cleanup
From:   David Holland 
Date:   2015-03-18 0:07:45
Message-ID: 20150318000745.GB15136 () netbsd ! org
[Download message RAW]

On Wed, Mar 18, 2015 at 12:00:51AM +0100, Joerg Sonnenberger wrote:
 > On Tue, Mar 17, 2015 at 11:56:35PM +0100, Kamil Rytarowski wrote:
 > > - merge reallocarr.3 to malloc.3 for consistency,
 >
 > No. Don't put standard and non-standard functions in the same man page.

concur

-- 
David A. Holland
dholl...@netbsd.org


https://marc.info/?l=netbsd-tech-userlevel=142663727209791=2



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 07.11.2016 22:39, J. Hannken-Illjes wrote:
> My patch contains corruption issues only and it passes ATF and
> it passes my stress test which is a bit more than just some fsx.
> 
> As -current currently corrupts file systems we should either fix it very
> soon or revert your changes completely.
> 

Could we please revert it and recommit it once will be fixed. Some
people need to run NetBSD-current that is literally from yesterday and
cannot track wapbl-related patches.

Also the first line of defense should be the automatic testing
framework, not a computer of a user/developer doing the daily job on NetBSD.

Perhaps a rhetorical question, but is it viable to add more ATF tests
for filesystem code, especially before altering anything functional in it?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 03.11.2016 18:08, Kamil Rytarowski wrote:
> 
> For now I'm focusing on functional tests, which are equivalent to
> FreeBSD capabilities. This is why I will reschedule combination of
> wait(2) usage functions for later and move to on other ptrace(2) use-cases.
> 

With recent reported issues I'm convinced to cover the whole
wait(2)-family of interfaces in t_ptrace.

There is a need to sort out all possible issues.

My plan is to split t_ptrace into t_ptrace_wait, t_ptrace_waitpid etc. I
will try to avoid duplication of the code and prepare something like the
t_mutex and t_timedmutex pair.

To keep the t_ptrace file there, I will add a new test not using any of
the wait(2) functions.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 06.11.2016 17:56, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 16:24:16 +
> From:    "Kamil Rytarowski" <ka...@netbsd.org>
> Message-ID:  <20161106162416.95d77f...@cvs.netbsd.org>
> 
>   | assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
>   | /dev/init process. This tests is skipped if run as root.
> 
> There's no need to skip it, just
> 
>   child=fork();   /* err if -1 */
>   if (child == 0) {
>   (void)setuid(10);
>   if (ptrace(.) < 0)
>   _exit(errno);
>   else
>   _exit(0);
>   }
>   waitpid(child, , 0);
>   /* and check status */
> 
> If you're root, the setuid() works, and the child isn't root any more.
> if you happened to be uid(10), the setuid() is a no-op, if you were some
> other user the setuid() fails, but you don't care.
> 
> kre
> 

Good point.

I noted a sequence in other tests like:

struct passwd *pw;
pw = getpwnam("nobody");
if (pid == 0) {
(void)setuid(pw->pw_uid);
}

I will make use of something similar.

I was evaluating whether it's possible to PT_ATTACH to getpid() [I will
check documentation later]. It doesn't make sense but we shouldn't hang.
I will test it and add an entry for it in the t_ptrace code.

Another idea is to test chroot(8) attach failure.

I'm inventing potential tests without the usage of wait(2)-like
functions, and without help of hacks like sleep(3) - such test would be
waste of precious time of execution of the ATF framework and the
behavior would not be practical.

My intention is to move all other tests to ptrace_wait* files.

Thank you for your suggestions!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 06.11.2016 17:38, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 15:03:31 +
> From:    "Kamil Rytarowski" <ka...@netbsd.org>
> Message-ID:  <20161106150331.25fb2f...@cvs.netbsd.org>
> 
>   | The t_wait_noproc_wnohang adds to options (except wait(2), wait3(2))
> 
> Why exclude wait3() ?   (Not that it really matters, wait3() and wait4()
> are the same thing modulo the pid paramater, which isn't being used here)
> 

This was my mistake, I will correct it.

> Could you also add tests (for wait4() and later, not wait() or wait3())
> where the process has a child, but the pid parameter (which is why not
> wait() or wait3() as there isn't one) is not the pid of the child ?
> 
> Also test (for wait3() and later) the WNOHANG case where the child
> exists, but has not exited yet ...
> 
> When you do that you also need to do a wait to clean up the child when
> it exits ... you get to also test wait returning a value, as the child
> should just sleep, then once the first waits (not expected to fetch
> the process are finished) kill() the child to avoid waiting for the
> sleep() to finish (delaying the test needlessly and perhaps getting
> caught up in the qemu timing issues) and what's more you get to check
> that the exit reason and signal number are correct (note that for waitid()
> you need to supply, and use, a siginfo_t to get the values, and should
> for wait6() as well - and verify both it, and wait6's status arg).
> 
> The basic model should be ...
> 
>   child = fork(); /* test for -1 ... */
>   if (child == 0) {
>   sleep(10);  /* plenty long enough */
>   _exit(0);
>   }
>   pid = waitpid(child+10, ...);   /* expect error */
>   pid = waitpid(child, WNOHANG);  /* expect 0 */
>   kill(child, SIGTERM);
>   pid = waitpid(child, , ...); /* expect child */
>   /* expect WIFSIGNALLED(status), and WTERMSIG(status)==SIGTERM)
> 
> you can deal with this in one generic function to do the work,
> and N helper functions that do the waits using their different arg
> sequences - where all the helper funcs have the same arg lists (even
> down to a siginfo_t inall of them) so you can then just call the
> generic routine N times, with each of the N different wait funcs
> as an arg, like
> 
>   int generic_func( int waitfunc(int, int, int *, siginfo_t *),
>int flags, int *status, siginfo_t *si) {
>   {
>   /* then as above, except instead of calling waitpid()
> you would do 
>   pid = (*waitfunc)(child+10, flags, status, si); /* + checks */
>   pid = (*waitfunc)(child, flags|WNOHANG, status, si); /* +...*/
>   pid = (*waitfunc)(child, flags, status, si);  /* check 
> pid==child */
>   return pid; /* then return as rest of checking
>   depends on which wait func was used */
> 
>   }
> 
> or something along those lines, and call that as
> 
> then implement
>   waitpid_func(int child, int flags, int *status, siginfo_t *si)
>   {
>   return waitpid(child, status, flags);   /* si is unused here */
>   }
> (and so on for the others), and then call
> 
>   pid = generic_func(waitpid, WNOHANG, , );
>   /* validate results in status - si ignored of course */
>   pid = generic_func(waitid, WNOHANG, , );
>   /* validate results (from si), expect 0 from final pid,
>ignore unused status */
>   /*etc etc*/
> 
> (details need to be fleshed out!)
> 
> 
> I am not yet certain that the current behaviour of wait6() and waitid()
> is actually wrong, so the expected result, and expect_fail for those ones
> might be premature.
> 
> kre
> 

Thank you for good suggestions. I will add them once t_ptrace_wait*
family of tests will land the sources.

I have also other tests in mind in the t_wait* family and I will add
them too.

I need to go out for few hours and unless there will be issues in the
code I plan to finish everything mentioned above tonight.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 06.11.2016 18:26, Nicolas Joly wrote:
> On Sun, Nov 06, 2016 at 11:56:31PM +0700, Robert Elz wrote:
>> Date:Sun, 6 Nov 2016 16:24:16 +
>> From:"Kamil Rytarowski" <ka...@netbsd.org>
>> Message-ID:  <20161106162416.95d77f...@cvs.netbsd.org>
>>
>>   | assert_pid1 asserts that non-root user cannot attach to PID 1 as it is 
>> the
>>   | /dev/init process. This tests is skipped if run as root.
>>
>> There's no need to skip it, just
>>
>>  child=fork();   /* err if -1 */
>>  if (child == 0) {
>>  (void)setuid(10);
>>  if (ptrace(.) < 0)
>>  _exit(errno);
>>  else
>>  _exit(0);
>>  }
>>  waitpid(child, , 0);
>>  /* and check status */
>>
>> If you're root, the setuid() works, and the child isn't root any more.
>> if you happened to be uid(10), the setuid() is a no-op, if you were some
>> other user the setuid() fails, but you don't care.
> 
> Or use dedicated ATF properties :
> 
>   atf_tc_set_md_var(tc, "require.user", "unprivileged");
> 
> Documented in atf-test-case(4).
> 

It worked, thanks!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 10.11.2016 03:28, Paul Goyette wrote:
> On Thu, 10 Nov 2016, matthew green wrote:
> 
 also, root can't attach to pid1 if securelevel is >= 0.
>>>
>>> To adjust securelevel this test would need to be modified to run under
>>> rump ...  We wouldn't want the test to manipulate securelevel of the
>>> running system.
>>
>> s/wouldn't want/*can't* by design have/.
>>
>> i don't know that running under rump is useful here.  i certainly
>> would not trust ptrace tests in a rump to cover it properly.  this
>> test should just be skipped if securelevel >= 0.  fact is that
>> very few systems run with securelevel these days, so it's a small
>> portion of systems that won't have it.
> 
> Yeah, rump probably doesn't make much sense here.  Skipping the test
> (with atf_tc_skip(...) of course) is likely the best solution.
> 
> 

This test is already enforcing unprivileged user. For now, I leave all
other rump and securelevel use-cases.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 10.11.2016 03:44, matthew green wrote:
> it would actually be useful to have a testcase that ran iff
> root *and* securelevel >= 0 and tests it is unable to attach
> to pid 1.
> 
> thanks.
> 
> 
> .mrg.
> 

OK, I will have a look at it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 11.11.2016 11:52, J. Hannken-Illjes wrote:
> 
>> On 10 Nov 2016, at 21:56, Jaromir Dolecek  wrote:
>>
>> Module Name: src
>> Committed By:jdolecek
>> Date:Thu Nov 10 20:56:32 UTC 2016
>>
>> Modified Files:
>>  src/sys/kern: vfs_wapbl.c
>>  src/sys/sys: wapbl.h
>>  src/sys/ufs/ffs: ffs_inode.c ffs_wapbl.c
>>  src/sys/ufs/ufs: ufs_wapbl.h
>>
>> Log Message:
>> during truncate with wapbl, register deallocation for upper indirect block
>> before recursing into lower blocks, to make sure that it will be removed 
>> after
>> all its referenced blocks are removed
>>
>> fixes 'ffs_blkfree_common: freeing free block' panic triggered by
>> ufs_truncate_retry() when just the upper indirect block registration failed,
>> code tried to free the lower blocks again after wapbl flush
>>
>> problem found by hannken@, thank you
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.85 -r1.86 src/sys/kern/vfs_wapbl.c
> 
> -   SIMPLEQ_HEAD(, wapbl_dealloc) wl_dealloclist;   /* lm:  list head */
> +   TAILQ_HEAD(, wapbl_dealloc) wl_dealloclist; /* lm:  list head */
> 
> This should have been committed on its own.  It makes reading the diff
> quite difficult.
> 
> Why do we need a TAILQ here, the number of deletions after the first
> element is nearly zero and the list is quite short.
> 
> 
> +wapbl_deallocation_free(struct wapbl *wl, struct wapbl_dealloc *wd,
> +   bool locked)
> 
> Better to let the caller always take/release the lock.
> 
> 
> +wapbl_register_deallocation(struct wapbl *wl, daddr_t blk, int len, bool 
> force,
> +void **cookiep)
> 
> +   if (cookiep)
> +   *cookiep = wd;
> 
> +wapbl_unregister_deallocation(struct wapbl *wl, void *cookie)
> 
> Returning a pointer to an arbitrary list element and using it
> later is bad design.  Would be better to define as:
> 
> wapbl_unregister_deallocation(struct wapbl *wl, daddr_t blk, int len)
> {
>   struct wapbl_dealloc *wd;
> 
>   mutex_enter(>wl_mtx);
>   TAILQ_FOREACH(wd, >wl_dealloclist, wd_entries) {
>   if (wd->wd_blkno == blk && wd->wd_len == len)
>   break;
>   }
>   KASSERT(wd != NULL);
>   wapbl_deallocation_free(wl, wd);
>   mutex_exit(>wl_mtx);
> }
> 
>> cvs rdiff -u -r1.19 -r1.20 src/sys/sys/wapbl.h
>> cvs rdiff -u -r1.121 -r1.122 src/sys/ufs/ffs/ffs_inode.c
>> cvs rdiff -u -r1.35 -r1.36 src/sys/ufs/ffs/ffs_wapbl.c
>> cvs rdiff -u -r1.12 -r1.13 src/sys/ufs/ufs/ufs_wapbl.h
> 
> --
> J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> 

I don't know what exact commit was that, but tests panic i386 now.

http://releng.netbsd.org/b5reports/i386/commits-2016.11.html#end

e.g.

http://releng.netbsd.org/b5reports/i386/build/2016.11.10.23.47.23/test.log

Part of the log.

sbin/resize_ffs/t_shrink (457/676): 4 test cases
shrink_24M_16M_v0_32768: uvm_fault(0xc1890e20, 0x1000, 2) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 2 eip c084150b cs 8 eflags 202 cr2 1fa0 ilevel 0 esp 4000
curlwp 0xc19c7540 pid 4299 lid 1 lowest kstack 0xc4e862c0
panic: trap
cpu0: Begin traceback...
vpanic(c0f3e4a6,c4e88b34,c4e88bb0,c01167d3,c0f3e4a6,c4e88bbc,c4e88bbc,1,c4e862c0,202)
at netbsd:vpanic+0x121
snprintf(c0f3e4a6,c4e88bbc,c4e88bbc,1,c4e862c0,202,1fa0,0,4000,0) at
netbsd:snprintf
trap() at netbsd:trap+0xca4
--- trap (number 6) ---
ffs_indirtrunc(21fac0,0,3f3,0,0,c4e88d20,c014826d,0,400,0) at
netbsd:ffs_indirtrunc+0x782
ffs_truncate(c1a644c4,100,0,0,c16f1a80,c01515c0,c186f008,0,c4e88ea4,0)
at netbsd:ffs_truncate+0xa5b
ufs_truncate_retry(c1a644c4,100,0,c16f1a80,0,c1a64568,c1a644c4,c1a644c4,c1a644c4,c4e88e60)
at netbsd:ufs_truncate_retry+0x95
ufs_setattr(c4e88e78,3,c4e88f68,c0ed0be4,c1a644c4,c4e88ea4,c16f1a80,c4e88ea4,c4e88f38,c0974066)
at netbsd:ufs_setattr+0x4bc
VOP_SETATTR(c1a644c4,c4e88ea4,c16f1a80,c1880a80,0,,,,,)
at netbsd:VOP_SETATTR+0x32
sys_ftruncate(c19c7540,c4e88f68,c4e88f60,c1890e20,1ba8000,c4e88f60,c4e88f68,c9,0,0)
at netbsd:sys_ftruncate+0xd4
syscall() at netbsd:syscall+0x13c
--- syscall (number 201) ---
b1eeeb07:
cpu0: End traceback...

dumping to dev 0,1 offset 2240
dump uvm_fault(0xc12c0400, 0xc4de6000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c011125c cs 8 eflags 246 cr2 c4de6dc0 ilevel 8
esp c1282bc0
curlwp 0xc19c7540 pid 4299 lid 1 lowest kstack 0xc4e862c0
Skipping crash dump on recursive panic
panic: trap
cpu0: Begin traceback...
vpanic(c0f3e4a6,c4e889c4,c4e88a40,c01167d3,c0f3e4a6,c4e88a4c,c4e88a4c,1,c4e862c0,246)
at netbsd:vpanic+0x121
snprintf(c0f3e4a6,c4e88a4c,c4e88a4c,1,c4e862c0,246,c4de6dc0,8,c1282bc0,0)
at netbsd:snprintf
trap() at netbsd:trap+0xca4
--- trap (number 6) ---
dodumpsys(c4e88b34,0,104,c011406a,8,c0fcc349,0,104,c0f3e4a6,c4e88b34) at
netbsd:dodumpsys+0x343
dumpsys(104,0,c0f3e4a6,c4e88b34,c19c7540,6,c4e88bbc,c4e88b28,c09207aa,c0f3e4a6)
at netbsd:dumpsys+0x14

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 12.11.2016 15:47, Valery Ushakov wrote:
> On Fri, Nov 11, 2016 at 12:10:04 -0500, Christos Zoulas wrote:
> 
>> Date:Fri Nov 11 17:10:04 UTC 2016
>>
>> Modified Files:
>>  src/sys/kern: sys_ptrace_common.c
>>
>> Log Message:
>> kern/51621: When attaching to a child send it a SIGTRAP not a SIGSTOP like
>> Linux and FreeBSD do.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.2 -r1.3 src/sys/kern/sys_ptrace_common.c
> 
> Hmm, I'm confused.  The PR says:
> 
> - PT_ATTACH seems to work, but waiting for stopped status and signal from the
>   child results in getting SIGTRAP, not SIGSTOP like in Linux and FreeBSD.
> 
> This revision changes PT_ATTACH case to:
> 
> proc_changeparent(t, p);
> -   signo = SIGSTOP;
> +   signo = SIGTRAP;
> goto sendsig;
> 
> which looks like it's the opposite of what's said in the PR.
> 
> FreeBSD from source code inspection (abridged version quoted below)
> does indeed send SIGSTOP:
> 
>   case PT_ATTACH:
>   proc_set_traced(p, true);
>   if (p->p_pptr != td->td_proc) {
>   proc_reparent(p, td->td_proc);
>   }
>   data = SIGSTOP;
>   goto sendsig;
> 
> From a very quick look through the code it looks like the intention
> (before this commit) is to send SIGSTOP to a process that we attach
> to, which is semantically correct, as we want to just stop it as-is
> and let the tracer poke at it.
> 
> The SIGTRAP comes from the fork path as far as I can tell.
> 
> So what's going on here?
> 
> -uwe
> 

I'm going to set SIGSTOP as expected signal in attach3, is it is
preferred in general. Not just because FreeBSD and Linux works this way,
but to make it consistent and regardless of relation between tracee and
tracer always get the same signal.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 25.11.2016 23:41, Christos Zoulas wrote:
> In article <o1aegv$210$1...@blaine.gmane.org>,
> Christos Zoulas <chris...@astron.com> wrote:
>> In article <20161125200105.5dbb4f...@cvs.netbsd.org>,
>> Kamil Rytarowski <source-changes-d@NetBSD.org> wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By:   kamil
>>> Date:   Fri Nov 25 20:01:05 UTC 2016
>>>
>>> Modified Files:
>>> src/tests/kernel: t_ptrace_wait.c
>>>
>>> Log Message:
>>> Fix several printf(3)-like functions usage with printing integers
>>>
>>> Integers as hex shall no be printed with PRIx8, but with plain "x".
>>
>> I would use %#x...
> 
> And I am not sure that passing 'int x; ptrace(.., , ...);' is right when
> reading/writing 1 byte. It works on x86 if you initialize x = 0, but
> it will will not work on sparc64, I think. Perhaps you need to pass
> 'uint8_t x; ptrace(, ..., , ...);' Then the printf format is right :-)
> 
> christos
> 

PT_READ_D and PT_READ_I read single int according to documentation.

In tests io_read_d* io_read_i* data blocks are printed with appropriate
PRIxN.

I cannot spot a mistake in the tests.

I'm going to replace %x with %#x.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sbin/mount_puffs

[Kamil Rytarowski]

On 23.11.2016 15:33, Masatake Daimon wrote:
> Module Name:  src
> Committed By: pho
> Date: Wed Nov 23 14:33:29 UTC 2016
> 
> Modified Files:
>   src/sbin/mount_puffs: mount_puffs.8 mount_puffs.c
> 
> Log Message:
> Major rework on mount_puffs(8) so that it can actually start file servers
> 
> Now you can do
>   # mount_puffs -o rdonly rot13fs#/home/foo /mnt/rot13
> 
> or in fstab
>   rot13fs#/home/foo  /mnt/rot13  puffs  rdonly
> 
> to start rot13fs with arguments identical to
>   # rot13fs -o rdonly /home/foo /mnt/rot13
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1 -r1.2 src/sbin/mount_puffs/mount_puffs.8
> cvs rdiff -u -r1.4 -r1.5 src/sbin/mount_puffs/mount_puffs.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Thanks for improving the man-page, it used to be the most cryptic one I
could find in NetBSD!

What do you think about adding an entry in a section EXAMPLES linking to
src/share/examples/puffs/rot13fs/rot13fs.c as we use rot13fs in example
command snippets.

It's worth to cross-reference all puffs filesystems out there, there is
at least mount_sysctlfs(8).

Thank you for your work!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 13.11.2016 02:44, Kamil Rytarowski wrote:
> 
> 
> On 13.11.2016 02:39, Robert Elz wrote:
>> Date:Sat, 12 Nov 2016 14:42:47 -0500
>> From:"Christos Zoulas" <chris...@netbsd.org>
>> Message-ID:  <20161112194247.37910f...@cvs.netbsd.org>
>>
>>   | PR/51624: Return the original parent for a traced process.
>>
>> Maybe the real bug here was that proc_reparent() is changing the
>> child's p_ppid ?
>>
>> I can see no reason for that, and if it wasn't done, then p_ppid would
>> be what is wanted by getppid() without needing kern_getppid() to
>> do all that unwind logic (and assiated locting and unlocking to make
>> it safe.)
>>
>> Aside from proc_reparent() the only weirdness I can see with p_ppid are
>> in kern_proc.c in fill_eproc() and fill_kproc2().   They both use (and
>> continue to use, so the results will be different for a process being
>> traced, and the same process when not traced) p_pptr->p_pid rather than
>> the simpler p_ppid but I am not sure why (nor what the clients of those
>> functions are or what the info is used for, so I am not sure what is 
>> correct.)
>>
>> kre
>>
> 
> It's also common to use kinfo_proc2 and extract data from there. There
> is one field:
> 
> int32_t p_ppid; /* PID_T: Parent process id */
> 
> getppid(2) and p_ppid shall be the same.
> 
> I can add a test for it, comparing old parent identifier with p_ppid
> from kinfo_proc2.
> 

Another place with ppid is in procfs:
/proc//stat

The 4th field should be PPID.

Another idea for a test.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 13.11.2016 02:39, Robert Elz wrote:
> Date:Sat, 12 Nov 2016 14:42:47 -0500
> From:"Christos Zoulas" 
> Message-ID:  <20161112194247.37910f...@cvs.netbsd.org>
> 
>   | PR/51624: Return the original parent for a traced process.
> 
> Maybe the real bug here was that proc_reparent() is changing the
> child's p_ppid ?
> 
> I can see no reason for that, and if it wasn't done, then p_ppid would
> be what is wanted by getppid() without needing kern_getppid() to
> do all that unwind logic (and assiated locting and unlocking to make
> it safe.)
> 
> Aside from proc_reparent() the only weirdness I can see with p_ppid are
> in kern_proc.c in fill_eproc() and fill_kproc2().   They both use (and
> continue to use, so the results will be different for a process being
> traced, and the same process when not traced) p_pptr->p_pid rather than
> the simpler p_ppid but I am not sure why (nor what the clients of those
> functions are or what the info is used for, so I am not sure what is correct.)
> 
> kre
> 

It's also common to use kinfo_proc2 and extract data from there. There
is one field:

int32_t p_ppid; /* PID_T: Parent process id */

getppid(2) and p_ppid shall be the same.

I can add a test for it, comparing old parent identifier with p_ppid
from kinfo_proc2.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 11.11.2016 18:10, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Fri Nov 11 17:10:04 UTC 2016
> 
> Modified Files:
>   src/sys/kern: sys_ptrace_common.c
> 
> Log Message:
> kern/51621: When attaching to a child send it a SIGTRAP not a SIGSTOP like
> Linux and FreeBSD do.
> 

Thank you for looking at it!

I noted that it doesn't work for me. attach1 still hangs and there is
regression in attach2 and attach3 in the t_ptrace_wait family.

$ atf-run t_ptrace_wait6|atf-report
Tests root: /usr/tests/kernel

t_ptrace_wait6 (1/1): 7 test cases
attach1: sorry, pid 21393 was killed: orphaned traced process
[0.002638s] Failed: /usr/src/tests/kernel/t_ptrace_wait.c:636: rv ==
sizeof(msg) not met
attach2: sorry, pid 17474 was killed: orphaned traced process
[0.001444s] Failed: /usr/src/tests/kernel/t_ptrace_wait.c:776: rv ==
sizeof(msg) not met
attach3: sorry, pid 2725 was killed: orphaned traced process
[301.145040s] Failed: Test case timed out after 300 seconds
traceme1: [0.001639s] Passed.
traceme2: [0.001406s] Passed.
traceme3: [0.001359s] Passed.
traceme4: [0.001391s] Passed.
[301.155536s]

Failed test cases:
t_ptrace_wait6:attach1, t_ptrace_wait6:attach2, t_ptrace_wait6:attach3

Summary for 1 test programs:
4 passed test cases.
3 failed test cases.
0 expected failed test cases.
0 skipped test cases.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 13.11.2016 03:39, Robert Elz wrote:
> Date:Sun, 13 Nov 2016 02:44:03 +0100
> From:    Kamil Rytarowski <n...@gmx.com>
> Message-ID:  <332a57da-1ac6-38ed-4fc3-947e2e6ca...@gmx.com>
> 
>   | I can add a test for it, comparing old parent identifier with p_ppid
>   | from kinfo_proc2.
> 
> That would be useful, I suspect they will be the same except when the
> process is being traced.
> 

Done!

>   | Another place with ppid is in procfs: /proc//stat
>   | The 4th field should be PPID. 
> 
> That one comes from p_ppid .. so will also probably be (currently) incorrect
> for a traced process, so a test would be good to verify.   That could also be
> fixed by using the new kern_getppid() or by just not changing p_ppid in
> proc_reparent() if no-one can find a reason why the change is needed.
> 
> As best I can tell, p_ppid is used excludively for providing info to userland,
> and the info wanted is always the original parent's pid, so changing it
> doesn't make a lot of sense to me.
> 
> kre
> 

I have added two tests: attach6 and attach7, in t_ptrace_wait*. The
former tests sysctl(7) and struct kinfo_proc2 and the latter
/proc/curproc/status.

As of now, both tests fail for me. I will wait for releng test bots to
confirm it.

There is a side topic. how useful is /proc, as it was implemented in
order to address old (4.4BSD as far as I know) defects in ptrace(2). The
deficiencies have been addressed long time ago and the duplicated
interface is still there. For now I will just ignore procfs, I'm just
wondering whether there are still users of it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libpthread

[Kamil Rytarowski]

On 31.10.2016 21:23, Taylor R Campbell wrote:
>Date: Mon, 31 Oct 2016 18:29:56 +0100
>From: Kamil Rytarowski <n...@gmx.com>
> 
>pthread_mutex_timedlock(3) is broken and it does not work at all for me,
>not as a standard mutex (like pthread_mutex_lock(3), sufficiently
>lengthy timeout makes it a good approximation) neither as a timed variant.
> 
> If the test is expected to fail, you should mark it xfail with a
> reference to a PR so that it doesn't draw needless attention to
> itself.
> 
> The autobuild system is designed to detect and flag unexpected
> failures; expected ones should be documented in the PR database
> instead.
> 

You are right, thank you.

The problem is under investigation right now and is "hot".



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libpthread

[Kamil Rytarowski]

On 31.10.2016 17:21, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Mon Oct 31 16:21:23 UTC 2016
> 
> Modified Files:
>   src/tests/lib/libpthread: t_mutex.c t_timedmutex.c
> 
> Log Message:
> Merge and fix the timed mutex tests to use absolute time.
> NB: the new tests are broken?
> 
> 

Tests are good.

pthread_mutex_timedlock(3) is broken and it does not work at all for me,
not as a standard mutex (like pthread_mutex_lock(3), sufficiently
lengthy timeout makes it a good approximation) neither as a timed variant.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 03.11.2016 15:24, Christos Zoulas wrote:
> In article <19801.1478175...@andromeda.noi.kre.to>,
> Robert Elz   wrote:
>>
>> Which is actually correct?   (That is, which makes more sense, if it is
>> not actually specified somewhere.)
>>
>> Please make the tests test correct behaviour, not just what NetBSD happens
>> to do today.   If NetBSD is doing something that is not correct, file a PR
>> and use atf_expect_fail() referencing the PR so it can get fixed, someday.
>>
>> Of course, it is also possible that the linux behaviour is the one that's
>> wrong.
>>
>>  | This code covers (uncovers issues?) WIFCONTINUED() and is the last planned
>>  | test in the ptraceme category.
>>
>> It would be kind of nice to have some (similar) tests that use waitid()
>> (or wait6()) instead of waitpid() given that waitid() is the more modern
>> (and more flexible) interface.
> 
> Well, having both WIFSTOPPED and WIFCONTINUED set does not make a lot of 
> sense.
> It would seem that the right behavior is that WIFCONTINUED should be set
> and WIFSTOPPED not set after PT_CONTINUE (unless the child stopped again).
> 
> Anyway, for FreeBSD WIFSTOPPED is set and WIFCONTINUED is not, so my guess
> is that the child is stopped again and we are wrong somewhere forgetting
> to clear the continued flag.
> 
> christos
> 

I will file a bug for it assuming that Linux (and apparently FreeBSD) is
correct here and adjust it in the test-case.

For now I'm focusing on functional tests, which are equivalent to
FreeBSD capabilities. This is why I will reschedule combination of
wait(2) usage functions for later and move to on other ptrace(2) use-cases.

I will replace sys_errlist(3) with strerror(3).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 08.12.2016 12:31, Nathanial Sloss wrote:
> Module Name:  src
> Committed By: nat
> Date: Thu Dec  8 11:31:15 UTC 2016
> 
> Modified Files:
>   src/etc/etc.aarch64: MAKEDEV.conf
>   src/etc/etc.algor: MAKEDEV.conf
>   src/etc/etc.amiga: MAKEDEV.conf
>   src/etc/etc.amigappc: MAKEDEV.conf
>   src/etc/etc.atari: MAKEDEV.conf
>   src/etc/etc.cats: MAKEDEV.conf
>   src/etc/etc.cobalt: MAKEDEV.conf
>   src/etc/etc.dreamcast: MAKEDEV.conf
>   src/etc/etc.epoc32: MAKEDEV.conf
>   src/etc/etc.evbarm: MAKEDEV.conf
>   src/etc/etc.evbppc: MAKEDEV.conf
>   src/etc/etc.evbsh3: MAKEDEV.conf
>   src/etc/etc.hpcarm: MAKEDEV.conf
>   src/etc/etc.hpcmips: MAKEDEV.conf
>   src/etc/etc.hppa: MAKEDEV.conf
>   src/etc/etc.landisk: MAKEDEV.conf
>   src/etc/etc.macppc: MAKEDEV.conf
>   src/etc/etc.mmeye: MAKEDEV.conf
>   src/etc/etc.or1k: MAKEDEV.conf
>   src/etc/etc.pmax: MAKEDEV.conf
>   src/etc/etc.sgimips: MAKEDEV.conf
>   src/etc/etc.shark: MAKEDEV.conf
>   src/etc/etc.sparc: MAKEDEV.conf
>   src/etc/etc.sparc64: MAKEDEV.conf
>   src/etc/etc.x68k: MAKEDEV.conf
>   src/etc/etc.zaurus: MAKEDEV.conf
>   src/share/man/man4: speaker.4
>   src/sys/arch/acorn32/conf: EB7500ATX GENERIC INSTALL LOWMEM_WSCONS NC
>   src/sys/arch/algor/conf: majors.algor
>   src/sys/arch/alpha/conf: GENERIC majors.alpha
>   src/sys/arch/amd64/conf: ALL GENERIC XEN3_DOM0 majors.amd64
>   src/sys/arch/amiga/conf: AMIGA DRACO GENERIC GENERIC.in MDINSTALL
>   src/sys/arch/amigappc/conf: GENERIC NULL
>   src/sys/arch/atari/conf: GENERIC.in HADES HADES.in MILAN-ISAIDE
>   MILAN-PCIIDE
>   src/sys/arch/bebox/conf: GENERIC INSTALL majors.bebox
>   src/sys/arch/cats/conf: GENERIC INSTALL
>   src/sys/arch/cobalt/conf: GENERIC INSTALL
>   src/sys/arch/dreamcast/conf: GENERIC
>   src/sys/arch/emips/conf: GENERIC
>   src/sys/arch/epoc32/conf: GENERIC
>   src/sys/arch/evbarm/conf: ALLWINNER_A80 ARMADILLO9 BPI CUBIEBOARD
>   GUMSTIX HDL_G HPT5325 HUMMINGBIRD_A31 IMX23_OLINUXINO LUBBOCK
>   MINI2440 MMNET_GENERIC MPCSA_GENERIC MV2120 POGO RPI SHEEVAPLUG
>   SMDK2410 TEGRA TS7200 TWINTAIL
>   src/sys/arch/evbmips/conf: ALCHEMY LOONGSON MALTA majors.evbmips
>   src/sys/arch/evbppc/conf: EV64260 OPENBLOCKS266_OPT PMPPC
>   src/sys/arch/hp300/conf: GENERIC
>   src/sys/arch/hpcarm/conf: NETBOOKPRO WZERO3
>   src/sys/arch/hpcmips/conf: GENERIC TX3922 VR41XX
>   src/sys/arch/hppa/conf: GENERIC
>   src/sys/arch/i386/conf: ALL GENERIC GENERIC_TINY INSTALL_FLOPPY
>   INSTALL_TINY XEN3_DOM0 majors.i386
>   src/sys/arch/ia64/conf: majors.ia64
>   src/sys/arch/ibmnws/conf: GENERIC
>   src/sys/arch/iyonix/conf: GENERIC
>   src/sys/arch/landisk/conf: GENERIC
>   src/sys/arch/macppc/conf: GENERIC GENERIC_601 POWERMAC_G5
>   src/sys/arch/mmeye/conf: MMEYE_WLF
>   src/sys/arch/netwinder/conf: GENERIC
>   src/sys/arch/ofppc/conf: GENERIC
>   src/sys/arch/playstation2/conf: DEBUG
>   src/sys/arch/pmax/conf: GENERIC GENERIC64 INSTALL INSTALL64
>   src/sys/arch/powerpc/conf: majors.powerpc
>   src/sys/arch/prep/conf: GENERIC majors.prep
>   src/sys/arch/riscv/conf: majors.riscv
>   src/sys/arch/sandpoint/conf: ENCPP1
>   src/sys/arch/sgimips/conf: GENERIC32_IP2x GENERIC32_IP3x
>   src/sys/arch/shark/conf: GENERIC INSTALL
>   src/sys/arch/sparc/conf: GENERIC INSTALL KRUPS MRCOFFEE TADPOLE3GX
>   src/sys/arch/sparc64/conf: GENERIC NONPLUS64
>   src/sys/arch/usermode/conf: GENERIC.common
>   src/sys/arch/vax/conf: GENERIC
>   src/sys/arch/x68k/conf: GENERIC INSTALL
>   src/sys/arch/x86/acpi: acpi_cpu_md.c
>   src/sys/arch/zaurus/conf: GENERIC INSTALL
>   src/sys/conf: majors
>   src/sys/dev: audiobell.c audiobellvar.h files.audio
>   src/sys/dev/isa: files.isa spkr.c
>   src/sys/dev/wscons: wskbd.c
> Added Files:
>   src/sys/dev: spkr_synth.c spkrvar.h
> 
> Log Message:
> Add a synthesized pc beeper and keyboard bell for platforms with an audio
> device.

Is it intended that speaker device for aarch64 is called spkr while for
others speaker?




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/kernel

[Kamil Rytarowski]

On 06.12.2016 19:59, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Tue Dec  6 18:59:00 UTC 2016
> 
> Modified Files:
>   src/tests/kernel: t_ptrace_wait.c
> 
> Log Message:
> switch to using fork so we can see the child output.
> 

atf_utils_fork() still works however... it outputs to .txt files, one
file is saved from stdout and the other from stderr.

Maybe we should rework atf_utils_fork() in ATF to just work like
fork(2), with setup for buffering and exit on failure?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 02.01.2017 04:44, David Holland wrote:
> On Sat, Dec 31, 2016 at 08:57:16PM +0000, Kamil Rytarowski wrote:
>  > Update TODO.ptrace
>  > 
>  > Mark exect(3) for removal, there is no use-case for it. exec() is already
>  > monitored and emits SIGTRAP when traced.
> 
> Historically exect() is used by debuggers to start debuggees. While
> it's equivalent to using PT_TRACE_ME followed by execve(), I think the
> result is that the new process first stops immediately after the exec
> finishes so that the debugger doesn't have to worry about stepping
> through the exec call in its own code.
> 
> This doesn't mean it shouldn't go away (or as much away as it can,
> that is, to COMPAT_70) but I'm not convinced there's no case for it.
> 

So, can I change exect(3) to something like:

int
exect(const char *path, char *const argv[], char *const envp[])
{
if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
return -1;
return execve(path, argv, envp);
}

The current implementation of exect(3) (at least philosophically)
predates SIGTRAP on exec().

Personally, I have no opinion neither preference on it either way.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 02.01.2017 18:54, David Holland wrote:
> On Mon, Jan 02, 2017 at 05:18:49AM +0100, Kamil Rytarowski wrote:
>  > > Historically exect() is used by debuggers to start debuggees. While
>  > > it's equivalent to using PT_TRACE_ME followed by execve(), I think the
>  > > result is that the new process first stops immediately after the exec
>  > > finishes so that the debugger doesn't have to worry about stepping
>  > > through the exec call in its own code.
>  > > 
>  > > This doesn't mean it shouldn't go away (or as much away as it can,
>  > > that is, to COMPAT_70) but I'm not convinced there's no case for it.
>  > > 
>  > 
>  > So, can I change exect(3) to something like:
>  > 
>  > int
>  > exect(const char *path, char *const argv[], char *const envp[])
>  > {
>  > if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
>  > return -1;
>  > return execve(path, argv, envp);
>  > }
>  > 
>  > The current implementation of exect(3) (at least philosophically)
>  > predates SIGTRAP on exec().
> 
> Not really; AFAIK, with that the target will first stop at the return
> from the ptrace call, and also stop at the exec, whereas with
> traditional exect it will first stop after the exec completes, in
> __start or in ld.elf_so.
> 
> An unsophisticated debugger expecting the latter will almost certainly
> be confused by the former.
> 
> Anyway, it needs to be kept in both the kernel and libc for compat so
> there's not much to be gained by mucking with it. :-/
> 

A debugger doesn't catch signal on PT_TRACE_ME. It will stop once on exec().

I don't see any need for compat as I doubt that it was ever functional.
In the past it was trying to singlestep libc call for execve(2), with
the new approach it will not turn on PT_STEP, but emit signal on exec().



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 09.01.2017 04:36, Christos Zoulas wrote:
> In article <20170109003130.33807f...@cvs.netbsd.org>,
> Kamil Rytarowski <source-changes-d@NetBSD.org> wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Mon Jan  9 00:31:30 UTC 2017
>>
>> Modified Files:
>>  src/sys/kern: kern_exec.c kern_exit.c kern_fork.c
>>
>> Log Message:
>> Cleanup dead code after revert of racy vfork(2) commit
>>
>> This removes dead code introduced with the following commit:
> 
> That's not dead code; it is commented out code that we would like
> to eventually get working. Rmind committed the change but it caused
> some regressions we did not understand. It did not hurt anything as
> it was commented out, and served as a reminder that something is
> wrong and we should one day track it down and fix it. Now there is
> no such reminder.
> 
> dead code = unreachable code but still compiled.
> 
> christos
> 

It's almost 5 years since commenting out - I assumed that it will rot to
the point that it might need to be rewritten. A reminder could be added
to roadmap and the code is still there in code history.

But if there is a request, I will revert it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 09.01.2017 05:06, Christos Zoulas wrote:
> On Jan 9,  4:40am, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/sys/kern
> 
> | It's almost 5 years since commenting out - I assumed that it will rot to
> | the point that it might need to be rewritten. A reminder could be added
> | to roadmap and the code is still there in code history.
> | 
> | But if there is a request, I will revert it.
> 
> But neither the API or the ABI or something that is related to that
> code to cause it to rot has changed... If there was a change that would
> make it not compile anymore I would understand why it was removed...
> But it was just sitting there hurting nothing :-)
> 
> christos
> 

I'm testing and analyzing proper tracing of vfork events also around the
removed code fragments (even if new code might be in other place) and
testing this ifdef is ouf scope of my work - unless someone will make it
enabled and eventually fixed. Getting rid of it reduces the complexity
(at least for my eyes).

If there is a request to add it to TODO/roadmap or to back it out, I
will do it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

> Sent: Wednesday, March 29, 2017 at 10:09 PM
> From: "Christos Zoulas" <chris...@astron.com>
> To: source-changes-d@NetBSD.org
> Subject: Re: CVS commit: src/sys/kern
>
> In article <20170329195230.d895af...@cvs.netbsd.org>,
> Kamil Rytarowski <source-changes-d@NetBSD.org> wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:kamil
> >Date:Wed Mar 29 19:52:30 UTC 2017
> >
> >Modified Files:
> > src/sys/kern: core_elf32.c sys_ptrace_common.c
> >
> >Log Message:
> >Generate ELF AUXV for core(5) and ptrace(2) limited to the vector TYPE x V
> >
> >Previously PT_DUMPCORE and PIOD_READ_AUXV and regular core dumping retrieved
> >the vector of AuxInfo {a_type, a_v} + MAXPATHLEN + ALIGN(1).
> >
> >The extra data is not actually needed in the returned chunk. It can be
> >retrieved with PT_READ_I operations and it's the preferred way to access
> >them as the AuxInfo fields contain pointers (void* format) to them.
> >
> >This changes the behavior of the kernel, no stable releases are affected
> >with this move. Current software is not affected as other systems already
> >stop generating data on AT_NULL. This streamlines the NetBSD behavior with
> >other ELF format OSes. This move also simplifies determination if we got
> >all the needed data inside the debugger and we no longer need to eliminate
> >the unneeded chunk at the end.
> 
> This is both incomplete and broken:
> 
> 1. The size needed is not just the maximum number of entries * the size of
>an entry. You have to account for the string entry storage that
>AT_SUN_EXECNAME needs (and alignment).

My intention was to remove the content of it. Do we need it? Why?
AT_SUN_EXECNAME has a pointer and we can retrieve it with a debugger.
I'm not sure it's safe to read and data after trailing AT_NULL and make
assumptions what is it.

I checked SunOS (perhaps the best reference for AT_SUN_EXECNAME) and
they don't offer this either.

AUXV is stored in /proc/$pid/auxv

$ uname -rms
SunOS 5.11 i86pc

$ hexdump  /home/kamil/auxv.sol.txt 
  
000 07d8  7fcf 0804 07de  7fd5 0804
010 0019  7fec 0804 0003  0034 0805
020 0004  0020  0005  0006 
030 0009  6480 0805 07e0  b000 feff
040 0007  5000 fefb 0008   
050 0006  1000  07e1  0002 
060 07d9  5c6f 7dd7 07e7   
070        
*
0b0

07d8  - AT_SUN_PLATFORM
07de  - AT_SUN_EXECNAME
0019  - AT_RANDOM
0003  - AT_PHDR
0004  - AT_PHENT
0005  - AT_PHNUM
0009  - AT_ENTRY
07e0  - AT_SUN_LDDATA
0007  - AT_BASE
0008  - AT_FLAGS
0006  - AT_PAGESZ
07e1  - AT_SUN_AUXFLAGS
07d9  - AT_SUN_HWCAP
07e7  - AT_SUN_HWCAP2
  - AT_NULL


> 2. There are other places where es_arglen is used, and needs to be cleaned
>up not to mention all the size info defines in the emulations
>(svr4/osf1/linux).

I will check emulation core dumps.

> 3. You can't assume that ELF_AUX_ENTRIES is the max number of entries needed
>since emulations might need more (they currently don't) and some need
>less.
> 
> In other words, you strictly made the situation worse and you possibly broke
> coredumps. Fortunately you did not break exec code :-)
> 
> christos
> 
> 

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

> Sent: Wednesday, March 29, 2017 at 11:27 PM
> From: "Kamil Rytarowski" <n...@gmx.com>
> To: "Christos Zoulas" <chris...@astron.com>
> Cc: source-changes-d@NetBSD.org
> Subject: Re: CVS commit: src/sys/kern
>
> 
> 
> > Sent: Wednesday, March 29, 2017 at 10:09 PM
> > From: "Christos Zoulas" <chris...@astron.com>
> > To: source-changes-d@NetBSD.org
> > Subject: Re: CVS commit: src/sys/kern
> >
> > In article <20170329195230.d895af...@cvs.netbsd.org>,
> > Kamil Rytarowski <source-changes-d@NetBSD.org> wrote:
> > >-=-=-=-=-=-
> > >
> > >Module Name:   src
> > >Committed By:  kamil
> > >Date:  Wed Mar 29 19:52:30 UTC 2017
> > >
> > >Modified Files:
> > >   src/sys/kern: core_elf32.c sys_ptrace_common.c
> > >
> > >Log Message:
> > >Generate ELF AUXV for core(5) and ptrace(2) limited to the vector TYPE x V
> > >
> > >Previously PT_DUMPCORE and PIOD_READ_AUXV and regular core dumping 
> > >retrieved
> > >the vector of AuxInfo {a_type, a_v} + MAXPATHLEN + ALIGN(1).
> > >
> > >The extra data is not actually needed in the returned chunk. It can be
> > >retrieved with PT_READ_I operations and it's the preferred way to access
> > >them as the AuxInfo fields contain pointers (void* format) to them.
> > >
> > >This changes the behavior of the kernel, no stable releases are affected
> > >with this move. Current software is not affected as other systems already
> > >stop generating data on AT_NULL. This streamlines the NetBSD behavior with
> > >other ELF format OSes. This move also simplifies determination if we got
> > >all the needed data inside the debugger and we no longer need to eliminate
> > >the unneeded chunk at the end.
> > 
> > This is both incomplete and broken:
> > 
> > 1. The size needed is not just the maximum number of entries * the size of
> >an entry. You have to account for the string entry storage that
> >AT_SUN_EXECNAME needs (and alignment).
> 
> My intention was to remove the content of it. Do we need it? Why?
> AT_SUN_EXECNAME has a pointer and we can retrieve it with a debugger.
> I'm not sure it's safe to read and data after trailing AT_NULL and make
> assumptions what is it.
> 
> I checked SunOS (perhaps the best reference for AT_SUN_EXECNAME) and
> they don't offer this either.
> 
> AUXV is stored in /proc/$pid/auxv
> 
> $ uname -rms
> SunOS 5.11 i86pc
> 
> $ hexdump  /home/kamil/auxv.sol.txt   
> 
> 000 07d8  7fcf 0804 07de  7fd5 0804
> 010 0019  7fec 0804 0003  0034 0805
> 020 0004  0020  0005  0006 
> 030 0009  6480 0805 07e0  b000 feff
> 040 0007  5000 fefb 0008   
> 050 0006  1000  07e1  0002 
> 060 07d9  5c6f 7dd7 07e7   
> 070        
> *
> 0b0
> 
> 07d8  - AT_SUN_PLATFORM
> 07de  - AT_SUN_EXECNAME
> 0019  - AT_RANDOM
> 0003  - AT_PHDR
> 0004  - AT_PHENT
> 0005  - AT_PHNUM
> 0009  - AT_ENTRY
> 07e0  - AT_SUN_LDDATA
> 0007  - AT_BASE
> 0008  - AT_FLAGS
> 0006  - AT_PAGESZ
> 07e1  - AT_SUN_AUXFLAGS
> 07d9  - AT_SUN_HWCAP
> 07e7  - AT_SUN_HWCAP2
>   - AT_NULL
> 
> 
> > 2. There are other places where es_arglen is used, and needs to be cleaned
> >up not to mention all the size info defines in the emulations
> >(svr4/osf1/linux).
> 
> I will check emulation core dumps.
> 
> > 3. You can't assume that ELF_AUX_ENTRIES is the max number of entries needed
> >since emulations might need more (they currently don't) and some need
> >less.
> > 
> > In other words, you strictly made the situation worse and you possibly broke
> > coredumps. Fortunately you did not break exec code :-)
> > 
> > christos
> > 
> > 
> 

I've checked the emulation code and indeed, there is a variety of possibilities.
There are longer and shorter AUX vectors.

Two simple solutions:
 - revert and keep some trailing content after AT_NULL,
 - check PK_32, stack grow direction and find AT_NULL before dumping the vector.

The former seems safer and I will go for it.

Thanks for pointing it out.

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 12.02.2017 22:52, Valeriy E. Ushakov wrote:
> Module Name:  src
> Committed By: uwe
> Date: Sun Feb 12 21:52:46 UTC 2017
> 
> Modified Files:
>   src/sys/kern: exec_elf.c
> 
> Log Message:
> netbsd_elf_signature - look at note segments (phdrs) not note
> sections.  They point to the same data in the file, but sections are
> for linkers and are not necessarily present in an executable.
> 
> The original switch from phdrs to shdrs seems to be just a cop-out to
> avoid parsing multiple notes per segment, which doesn't really avoid
> the problem b/c sections also can contain multiple notes.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.87 -r1.88 src/sys/kern/exec_elf.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 
> 


This change broke assembly framework of mine.

(amd64)
$ cat start.S
.globl _start

.section ".note.netbsd.ident", "", @note
.long 2f-1f
.long 4f-3f
.long 1
1:  .asciz "NetBSD"
2:  .p2align 2
3:  .long 70001
4:  .p2align 2

.section .text
_start:
andq $0xfff0, %rsp
subq $0x8, %rsp
call main
movq %rax, %rdi
movq $0x1, %rax
syscall

$ cat minimal.c
int main(void)
{
return 5;
}

$ gcc -nostdlib start.S minimal.c -o minimal

This program reports invalid NetBSD executable now. It was inspired by
https://wiki.netbsd.org/examples/netbsd_assembly/

Reverting this commit locally makes the executable work again.

Is this a regression or is the template wrong?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 21.04.2017 18:09, Martin Husemann wrote:
> On Fri, Apr 21, 2017 at 05:50:41PM +0200, Kamil Rytarowski wrote:
> 
>> .section ".note.netbsd.ident", "", @note
> 
> That is missing an "a" flag:
> 
> .section ".note.netbsd.ident", "a", @note
> 
> Look at readelf -a output, no program header is generated for your variant,
> but if you add the flag, all is fine (and the file becomes executable again).
> 
> 
> Martin
> 

It works now, thank you! I hope that there are no other regressions in
"real" software in regard to this change.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sbin/fsck_ext2fs

[Kamil Rytarowski]

On 21.04.2017 19:47, co...@sdf.org wrote:
> On Fri, Apr 21, 2017 at 01:33:05PM -0400, Christos Zoulas wrote:
>> e2di_block is an array; can't be NULL, (clang)
> 
> I'm guessing this is from
> http://releng.netbsd.org/builds/HEAD-llvm/201704191240Z/amd64.build.failed
> 
> 
> /home/source/ab/HEAD-llvm/src/sbin/fsck_ext2fs/pass1.c:242:39: warning: 
> comparison of array 'dp->e2di_blocks' equal to a null pointer is always false 
> [-Wtautological-pointer-compare]
> (EXT2_MAXSYMLINKLEN == 0 && dp->e2di_blocks == 0)) {
> ^~~~
> 
> 1 warning generated.
> 
> How come that warning wasn't fatal?
> 

It's a valid code.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sbin/fsck_ext2fs

[Kamil Rytarowski]

On 21.04.2017 20:08, co...@sdf.org wrote:
> On Fri, Apr 21, 2017 at 07:46:27PM +0200, Kamil Rytarowski wrote:
>>
>> It's a valid code.
>>
> 
> Other things fail:
> http://releng.netbsd.org/builds/HEAD/201704202350Z/evbarm64-aarch64.build.failed
> 
> /home/source/ab/HEAD/src/bin/ln/ln.c:357:1: error: function 'usage'
> could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
> {
> ^
> 1 error generated.
> 
> I think that one is even more valid :-)
> 

Sometimes we can specify WARNS=6 or similar in Makefiles to turn
warnings into errors.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 18.08.2017 12:02, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Fri Aug 18 10:02:37 UTC 2017
> 
> Modified Files:
>   src/sys/arch/amd64/amd64: amd64_trap.S
>   src/sys/arch/i386/i386: i386_trap.S vector.S
> 
> Log Message:
> Remove unused and broken code. On amd64 we won't want int3 from kernel
> mode to be valid.
> 

Does it affect DTrace? ddb(4) used to have an option to set breakpoints.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/bin/ksh

[Kamil Rytarowski]

On 23.06.2017 02:12, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu Jun 22 13:32:04 UTC 2017
>>
>> Modified Files:
>>  src/bin/ksh: c_ksh.c edit.c path.c sh.h
>>
>> Log Message:
>> Remove ancient cygwin support in ksh(1)
>>
>> OK by 
> 
> i thought ksh was upstream owned code, so changes like this
> seem to be out of place in netbsd tree.
> 
> why are you doing all this?
> 
> 
> .mrg
> 

I haven't found active upstream development since around 1999; I have
local patches and I took maintainership. This is what happened in other
BSDs.

I got some old patches and I will try to upstream them after removing
K code. This will also help to address some local bugs that affect my
shell usage.

The domain for multiplatform legacy Unices is covered by MKSH (developed
against gcc1, gcc2). So no need to compete with them for this niche.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/uvm

[Kamil Rytarowski]

On 19.05.2017 17:30, Chuck Silvers wrote:
> Module Name:  src
> Committed By: chs
> Date: Fri May 19 15:30:19 UTC 2017
> 
> Modified Files:
>   src/sys/uvm: uvm_map.c uvm_mmap.c
> 
> Log Message:
> make MAP_FIXED mapping operations atomic. fixes PR 52239.
> previously, unmapping any entries being replaced was done separately
> from entering the new mapping, which allowed another thread doing
> a non-MAP_FIXED mapping to allocate the range out from under the
> MAP_FIXED thread.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.346 -r1.347 src/sys/uvm/uvm_map.c
> cvs rdiff -u -r1.164 -r1.165 src/sys/uvm/uvm_mmap.c
> 

UVM broke after this commit. I cannot build packages due to random
memory corruptions. Processes die / files (at least executables) contain
trash.

There are also users on IRC reporting the same behavior.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch/x86/x86

[Kamil Rytarowski]

I've found this article:

http://coypu.sdf.org/20170525-qemu-smp

On 31.05.2017 08:51, Jaromír Doleček wrote:
> You rock! Thank you.
> 
> 2017-05-31 2:19 GMT+02:00 Maya Rashish  >:
> 
> Module Name:src
> Committed By:   maya
> Date:   Wed May 31 00:19:17 UTC 2017
> 
> Modified Files:
> src/sys/arch/x86/x86: cpu.c
> 
> Log Message:
> Do not pause many times between testing if the CPU can go.
> 
> This only impacts QEMU as QEMU's implementation of pause is
> significantly slower than its implementation of nop.
> 
> PR kern/51623: running qemu-x86_64 with -smp 4 - the additional
> CPUs don't start.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.125 -r1.126 src/sys/arch/x86/x86/cpu.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/make

[Kamil Rytarowski]

On 18.06.2017 00:16, Christos Zoulas wrote:
> In article <20170617213136.ga21...@britannica.bec.de>,
> Joerg Sonnenberger   wrote:
>> On Sat, Jun 17, 2017 at 05:28:07PM -0400, Christos Zoulas wrote:
>>> On Jun 17,  9:38pm, jo...@bec.de (Joerg Sonnenberger) wrote:
>>> -- Subject: Re: CVS commit: src/usr.bin/make
>>>
>>> | Agreed, please revert. This was discussed at the time and FreeBSD
>>> | behavior you have now implemented is much less useful.
>>>
>>> You can get the original with -V '\VAR'
>>
>> That's no better than the behavior before.
> 
> Now you get:
> 
> $ make -V MACHINE_CPU
> arm
> $ make -V \\MACHINE_CPU
> ${MACHINE_ARCH:C/mipse[bl]/mips/:C/mips64e[bl]/mips/:C/sh3e[bl]/sh3/:S/coldfire/m68k/:S/m68000/m68k/:C/arm.*/arm/:C/earm.*/arm/:S/earm/arm/:S/powerpc64/powerpc/:S/aarch64eb/aarch64/:S/or1knd/or1k/:C/riscv../riscv/}
> 
> The second is the original version.
> 
> christos
> 

How about "make -V" getting the original behavior and "make -VV"
resulting with evaluated one?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/make

[Kamil Rytarowski]

On 18.06.2017 00:31, Christos Zoulas wrote:
> In article <20170617222558.ga24...@britannica.bec.de>,
> Joerg Sonnenberger  <jo...@bec.de> wrote:
>> On Sun, Jun 18, 2017 at 12:22:13AM +0200, Kamil Rytarowski wrote:
>>> On 18.06.2017 00:16, Christos Zoulas wrote:
>>>> In article <20170617213136.ga21...@britannica.bec.de>,
>>>> Joerg Sonnenberger  <jo...@bec.de> wrote:
>>>>> On Sat, Jun 17, 2017 at 05:28:07PM -0400, Christos Zoulas wrote:
>>>>>> On Jun 17,  9:38pm, jo...@bec.de (Joerg Sonnenberger) wrote:
>>>>>> -- Subject: Re: CVS commit: src/usr.bin/make
>>>>>>
>>>>>> | Agreed, please revert. This was discussed at the time and FreeBSD
>>>>>> | behavior you have now implemented is much less useful.
>>>>>>
>>>>>> You can get the original with -V '\VAR'
>>>>>
>>>>> That's no better than the behavior before.
>>>>
>>>> Now you get:
>>>>
>>>> $ make -V MACHINE_CPU
>>>> arm
>>>> $ make -V \\MACHINE_CPU
>>>>
>> ${MACHINE_ARCH:C/mipse[bl]/mips/:C/mips64e[bl]/mips/:C/sh3e[bl]/sh3/:S/coldfire/m68k/:S/m68000/m68k/:C/arm.*/arm/:C/earm.*/arm/:S/earm/arm/:S/powerpc64/powerpc/:S/aarch64eb/aarch64/:S/or1knd/or1k/:C/riscv../riscv/}
>>>>
>>>> The second is the original version.
>>>>
>>>> christos
>>>>
>>>
>>> How about "make -V" getting the original behavior and "make -VV"
>>> resulting with evaluated one?
>>
>> I find -V '${foo}' a perfectly reasonable way to spell it, especially
>> since it works consistently with modifiers. No need for more complexity.
> 
> And it still does. You cannot use -VV because of getopt(3). You can use
> a different letter. The complexity is when I get this long string instead
> of the evaluated variable.
> 
> christos
> 

Can we reuse show-var from pkgsrc?

$ make show-var VARNAME=MACHINE_CPU
x86_64

# show-var:
# show-vars:
# show-subdir-var:
#   Convenience targets, to display make variables from the command
#   line. Examples:
#
#   make show-var VARNAME=PKGNAME
#   make show-vars VARNAMES="PKGNAME PKGVERSION PKGREVISION"
#   make show-subdir-var VARNAME=DISTFILES
#
#   In category directories, show-var and show-vars descend
#   recursively into each subdirectory, printing the variables of


#   the individual packages. To show a variable from the category
#   itself, use show-subdir-var.
.PHONY: show-var
show-var:
@${ECHO} ${${VARNAME}:Q

 -- /usr/pkgsrc/mk/bsd.pkg.mk



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/uvm

[Kamil Rytarowski]

On 20.05.2017 02:02, Kamil Rytarowski wrote:
> On 19.05.2017 17:30, Chuck Silvers wrote:
>> Module Name: src
>> Committed By:chs
>> Date:Fri May 19 15:30:19 UTC 2017
>>
>> Modified Files:
>>  src/sys/uvm: uvm_map.c uvm_mmap.c
>>
>> Log Message:
>> make MAP_FIXED mapping operations atomic. fixes PR 52239.
>> previously, unmapping any entries being replaced was done separately
>> from entering the new mapping, which allowed another thread doing
>> a non-MAP_FIXED mapping to allocate the range out from under the
>> MAP_FIXED thread.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.346 -r1.347 src/sys/uvm/uvm_map.c
>> cvs rdiff -u -r1.164 -r1.165 src/sys/uvm/uvm_mmap.c
>>
> 
> UVM broke after this commit. I cannot build packages due to random
> memory corruptions. Processes die / files (at least executables) contain
> trash.
> 
> There are also users on IRC reporting the same behavior.
> 

After recent changes the issues are gone.
 - src/sys/uvm/uvm_extern.h r.1.206
 - src/sys/uvm/uvm_map.c r.1.349
 - src/sys/uvm/uvm_mmap.c r.1.166

Thanks Chuck Silvers!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 03.10.2017 19:27, Christos Zoulas wrote:
> On Oct 3,  7:03pm, m...@m00nbsd.net (Maxime Villard) wrote:
> -- Subject: Re: CVS commit: src/sys
> 
> | What about you both cut the drama and the bullshit right here. What has been
> | said already repeatedly, again, and again, is that choosing one side over 
> the
> | other just does not work. There is no "most secure", there is no "most 
> usable".
> | There is the *middle* of it; some security with features that are still
> | compiled but not accessible by unpriv user by default, some usability with a
> | way to enable the feature that requires the least effort possible.
> 
> 
> How about the most usable is what we have now, and the most secure we can
> get via a sysctl? Or the other way around? We do need a decision on where
> we are heading though, because we keep disabling features piecemeal in the
> name of security.
> 
> christos
> 

I think that the approach in the middle is to use secmodel_securelevel(9).

Add fine-grained switch at which level compat_* stops to work with
default "1".

Desktop users will use INSECURE, server ones SECURE. I run Opera with
compat_linux and from time to time bootstrap something from Linux
executables. I don't care about extra hardening, my desktop does not
serve any public services.

For a server or a product I wouldn't want to run such executables and I
would use SECURE or HIGHLY-SECURE mode.

MODULAR vs non-MODULAR kernel approach appears to me too complex.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 10.10.2017 13:27, Martin Husemann wrote:
> On Tue, Oct 10, 2017 at 11:03:42AM +, co...@sdf.org wrote:
>> On Tue, Oct 10, 2017 at 05:02:48AM +, Martin Husemann wrote:
>>> I think you are confusing things. We do not support FPU emulation in the
>>> kernel, but booting on FPU-less machines should still work (with a softfloat
>>> userland).
>>
>> I don't think we should support every esoteric case just in case someone
>> wants to complete support it. We haven't run on such machines in over a
>> decade.
> 
> We have not provided a usable userland for it, but we were able to boot
> on them.
> 
> The cost for this is minimal (given the overall mess of FPU save area
> sizes on x86), no point in cleaning this up.
> 
> Martin
> 

Agreed, there are still users asking for no-FPU x86 support. We badly
closed one of their latest PR as wontfix...



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch/x86/x86

[Kamil Rytarowski]

On 04.10.2017 08:35, Alexander Nasonov wrote:
> Maxime Villard wrote:
>> In the first mail, you said that it was better to have a all-or-nothing
>> sysctl, which is *exactly* what I just committed.
> 
> Yes, sysctl is better than giving rdtsc to root only. But "better"
> alone isn't strong enough to count me as a supporter.
> 
>> In the second one, as a reply to me, you were indeed talking about
>> more granular control -- but with vdso, which we don't have, so
>> it's basically not doable.
> 
> IMO, it's more important to have vdso than to control rdtsc.
> 
>> (PS: there is no point in having it done in a note section either, since
>> unpriv user can still create a binary with rdtsc enabled and side channel
>> the kernel.)
> 
> Mount all user-writable partitions with noexec.
> 

An idea borrowed from the OpenBSD approach with wxneeded partition
(mount) property.

Add fine-grained control over aslr, mprotect, segvguard, rdtsc, compat_*
etc as a mount option. With this approach we can grant certain features
to individual users or individual groups of people.

By default everything could be enforced. I would put my Opera binaries
in /home on my desktop.

I would benefit from it, being able to test-build language runtimes on a
dedicated mount point without shutting off global aslr/mprotect/similar
and without debugging why thing break the build and what needs to be
touched with paxctl(8).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 02.10.2017 15:36, Martin Husemann wrote:
> On Mon, Oct 02, 2017 at 03:16:14PM +0200, Maxime Villard wrote:
>> Le 02/10/2017 à 14:47, Manuel Bouyer a écrit :
>>> On Mon, Oct 02, 2017 at 02:39:47PM +0200, Maxime Villard wrote:
> Actually I did suggest to make the default dependant on MODULAR.

 what's the point exactly?
>>>
>>> that if I build a non-modular kernel with an emulation option explicitely
>>> selected, it works at boot. Even in single-user mode.
>>
>> and what do we do with architectures that don't support kernel modules?
> 
> No emulation unless you build a custom kernel with the compat enabled.
> 
> Martin
> 

I would leave this and all other compat code turned on by default.

There could be a sysinst option or note how to harden it (adding an
entry in /etc/sysctl.conf).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 03.10.2017 15:35, Greg Troxel wrote:
> Then, I think the debate
> reduces to "should the checked-in GENERIC enable the emulation sysctl".

I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.

My personal preference is to keep it enabled by default, but I would ask
core@ for the official statement and follow it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/gen (vax mentions moved to CAVEATs)

[Kamil Rytarowski]

On 27.09.2017 11:23, m...@netbsd.org wrote:
> On Wed, Sep 27, 2017 at 09:04:30AM +, Maya Rashish wrote:
>> Module Name: src
>> Committed By:maya
>> Date:Wed Sep 27 09:04:30 UTC 2017
>>
>> Modified Files:
>>  src/lib/libc/gen: isinf.3
>>
>> Log Message:
>> Move VAX notes to CAVEATS, clarify that it just returns zero
>>
>> The VAX isinf implementation is in sys/arch/vax/include/math.h.
> 
> If there is no objection to this I'll do isnan too
> (and whatever else I can find)
> 

On VAX infinites, NaN and signbit(3) are special.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/stdlib

[Kamil Rytarowski]

On 02.11.2017 20:15, Joerg Sonnenberger wrote:
> On Thu, Nov 02, 2017 at 08:15:01PM +0100, Joerg Sonnenberger wrote:
>> On Thu, Nov 02, 2017 at 06:37:15PM +0000, Kamil Rytarowski wrote:
>>> Module Name:src
>>> Committed By:   kamil
>>> Date:   Thu Nov  2 18:37:15 UTC 2017
>>>
>>> Modified Files:
>>> src/lib/libc/stdlib: atexit.c
>>>
>>> Log Message:
>>> Correct handling of __cxa_atexit(a,b,NULL) in libc
>>
>> I don't get it. This seems to be quite wrong.
>>
>>> Correct a bug that __cxa_atexit(x,y,NULL) is handled in the same way as
>>> atexit(x) (which is simplified to __cxa_atexit(x,NULL,NULL).
>>
>> __cxa_atexit(x,y,NULL) is not invalid. Please revert this.
> 
> ...is invalid, of course.
> 
> Joerg
> 

What's the rationale for being wrong?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 02.12.2017 14:03, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Sat Dec  2 13:03:15 UTC 2017
> 
> Modified Files:
>   src/sys/arch/amd64/conf: GENERIC files.amd64
>   src/sys/arch/xen/conf: files.xen
> Removed Files:
>   src/sys/arch/amd64/amd64: compat_13_machdep.c
> 
> Log Message:
> Drop COMPAT_13 on amd64, already not enabled. Reduces the number of
> critical places.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1 -r0 src/sys/arch/amd64/amd64/compat_13_machdep.c
> cvs rdiff -u -r1.470 -r1.471 src/sys/arch/amd64/conf/GENERIC
> cvs rdiff -u -r1.94 -r1.95 src/sys/arch/amd64/conf/files.amd64
> cvs rdiff -u -r1.163 -r1.164 src/sys/arch/xen/conf/files.xen
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 
> 
> 
> Modified files:
> 
> Index: src/sys/arch/amd64/conf/GENERIC
> diff -u src/sys/arch/amd64/conf/GENERIC:1.470 
> src/sys/arch/amd64/conf/GENERIC:1.471
> --- src/sys/arch/amd64/conf/GENERIC:1.470 Sat Dec  2 12:40:03 2017
> +++ src/sys/arch/amd64/conf/GENERIC   Sat Dec  2 13:03:15 2017
> @@ -1,4 +1,4 @@
> -# $NetBSD: GENERIC,v 1.470 2017/12/02 12:40:03 maxv Exp $
> +# $NetBSD: GENERIC,v 1.471 2017/12/02 13:03:15 maxv Exp $
>  #
>  # GENERIC machine description file
>  #
> @@ -22,7 +22,7 @@ include "arch/amd64/conf/std.amd64"
>  
>  options  INCLUDE_CONFIG_FILE # embed config file in kernel binary
>  
> -#ident   "GENERIC-$Revision: 1.470 $"
> +#ident   "GENERIC-$Revision: 1.471 $"
>  
>  maxusers 64  # estimated number of users
>  
> @@ -117,7 +117,7 @@ options   KDTRACE_HOOKS   # kernel DTrace h
>  # Compatibility options
>  #options EXEC_AOUT   # required by binaries from before 1.5
>  
> -# NetBSD backward compatibility. Support goes from COMPAT_11 up until
> +# NetBSD backward compatibility. Support goes from COMPAT_15 up until
>  # the latest release. Note that really old compat (< COMPAT_16) is only
>  # useful for 32-bit binaries.
>  include  "conf/compat_netbsd15.config"
> 
> Index: src/sys/arch/amd64/conf/files.amd64
> diff -u src/sys/arch/amd64/conf/files.amd64:1.94 
> src/sys/arch/amd64/conf/files.amd64:1.95
> --- src/sys/arch/amd64/conf/files.amd64:1.94  Sun Oct  8 09:06:50 2017
> +++ src/sys/arch/amd64/conf/files.amd64   Sat Dec  2 13:03:15 2017
> @@ -1,4 +1,4 @@
> -#$NetBSD: files.amd64,v 1.94 2017/10/08 09:06:50 maxv Exp $
> +#$NetBSD: files.amd64,v 1.95 2017/12/02 13:03:15 maxv Exp $
>  #
>  # new style config file for amd64 architecture
>  #
> @@ -136,7 +136,6 @@ attachfd at fdc
>  # Compatibility modules
>  #
>  # Binary compatibility with previous NetBSD releases (COMPAT_XX)
> -file arch/amd64/amd64/compat_13_machdep.ccompat_13
>  file arch/amd64/amd64/compat_16_machdep.ccompat_16
>  
>  # NetBSD/i386 32-bit binary compatibility (COMPAT_NETBSD32)
> 
> Index: src/sys/arch/xen/conf/files.xen
> diff -u src/sys/arch/xen/conf/files.xen:1.163 
> src/sys/arch/xen/conf/files.xen:1.164
> --- src/sys/arch/xen/conf/files.xen:1.163 Mon Nov  6 15:21:23 2017
> +++ src/sys/arch/xen/conf/files.xen   Sat Dec  2 13:03:15 2017
> @@ -1,4 +1,4 @@
> -#$NetBSD: files.xen,v 1.163 2017/11/06 15:21:23 cherry Exp $
> +#$NetBSD: files.xen,v 1.164 2017/12/02 13:03:15 maxv Exp $
>  #NetBSD: files.x86,v 1.10 2003/10/08 17:30:00 bouyer Exp 
>  #NetBSD: files.i386,v 1.254 2004/03/25 23:32:10 jmc Exp 
>  
> @@ -330,7 +330,6 @@ include   "compat/freebsd/files.freebsd"
>  elifdef amd64
>  
>  # Binary compatibility with previous NetBSD releases (COMPAT_XX)
> -file arch/amd64/amd64/compat_13_machdep.ccompat_13
>  file arch/amd64/amd64/compat_16_machdep.ccompat_16
>  
>  # NetBSD/i386 32-bit binary compatibility (COMPAT_NETBSD32)
> 

There are still users of NetBSD/i386 0.9 executables (like myself - of
Franz Lisp).

It's reasonable to drop compat for pre-ELF (approximately < 2.0) as we
can use emulators, but it should be discussed and decided by core.

pkgsrc for early compat distributions (emulators/compat12, 13, 14) never
worked well for me and I had to build them manually.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 02.12.2017 16:55, Maxime Villard wrote:
> Le 02/12/2017 à 14:22, Kamil Rytarowski a écrit :
>> There are still users of NetBSD/i386 0.9 executables (like myself - of
>> Franz Lisp).
> 
> And? compat_09 is available on i386.
> 

It used to work on the NetBSD/amd64 kernel.

>> It's reasonable to drop compat for pre-ELF (approximately < 2.0) ...
> 
> Yes, amd64 needs to start from compat_20. But compat_20 does not
> compile: if
> you include compat_netbsd20.config in GENERIC, you get "multiple definition
> of _KERNEL_OPT_COMPAT_15 _KERNEL_OPT_COMPAT_16 etc".
> 
> However, the current compat_netbsd15.config inclusion works, even though
> compat_15 enables compat_20.
> 
> So it looks like there is something going wrong in the dependencies. It
> wouldn't be a big surprise, since no one has ever tested that.
> 

< 2.0 compat is rotten on all levels.

>> ... but it should be discussed and decided by core.
> 
> No. I am not going to discuss basic changes like this one all the time.
> (And
> I am not mentioning here that in each of the two times I asked core@ to
> decide on what to do, they were unable to formulate a single answer after
> months, not recognizing the rules they had themselves stated when these
> were
> to be enforced. Fool me again.)
> 
> Maxime

OK, I will prompt about it myself.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 02.12.2017 22:23, David Holland wrote:
> On Sat, Dec 02, 2017 at 10:04:26PM +0100, Maxime Villard wrote:
>  > > Revert this. Compat on amd64 must be available all the way back to
>  > > 0.9, same as i386.
>  > > 
>  > > Also, please stop unilaterally breaking the world.
>  > 
>  > You are kidding, right? Everything below COMPAT_15 has *never* been
>  > enabled.  This change does not break anything, since nothing was
>  > enabled in the first.
> 
> No, I am not kidding. It is there in GENERIC so it can be enabled for
> people who want to run very old i386 binaries.
> 
>  > "Compat on amd64 must be available"
>  > 
>  > What authority do you have to say that? It has never been this way.
> 
> Providing compat has been policy for 25+ years.
> 
> Since you bring up the notion of authority... what authority do you
> think you have to make declarations about what will and won't be
> removed?
> 

For the record, we were fixing 0.9 compat in HEAD at least in May 2017,
after the breakage from vm.user_va0_disable. (I recall commits fixing
syscalls that were introduced later).

http://gnats.netbsd.org/52246

It used to work on a NetBSD-7.99.71/amd64 kernel with NetBSD-0.9/i386
a.out executables.

I still want to use this software as reference, but I will ask core@
what to do.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/games/fortune/datfiles

[Kamil Rytarowski]

On 06.12.2017 17:58, Taylor R Campbell wrote:
>> Date: Wed, 6 Dec 2017 16:41:27 +0800 (+08)
>> From: Paul Goyette 
>>
>>> Oh, and I'd also change "its canine barking" to "its barking," (note the
>>> addition of a comma), which would make that sentence flow better, and
>>> avoid the unnecessary re-use of the word 'canine'.
>>
>> Hmmm, it'd be nice if there were a definitive source for this quote; 
>> without that, I'd rather not "adjust" the language.
> 
> I expect the original quote was probably something in Polish.
> 

I was the coauthor of the original translation. There are many other
good quotes but they could be difficult to explain to foreigners,
explain background context etc... or needlessly controversial (even if
true) for fortunes (no need to discuss German-Polish-Russian relations
via fortunes).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch/x86/x86

[Kamil Rytarowski]

This is really impressive and great work!

On 21.10.2017 21:05, Alistair Crooks wrote:
> Oh, nice! This is great :)
> 
> Thank you for all your work on this, pkboot, kaslr and the pmap.
> 
> Best,
> Alistair
> 
> On 21 October 2017 at 01:27, Maxime Villard  wrote:
>> Module Name:src
>> Committed By:   maxv
>> Date:   Sat Oct 21 08:27:19 UTC 2017
>>
>> Modified Files:
>> src/sys/arch/x86/x86: sys_machdep.c
>>
>> Log Message:
>> Forbid 64bit entries. That's it, now we support USER_LDT on amd64.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.42 -r1.43 src/sys/arch/x86/x86/sys_machdep.c
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>




signature.asc
Description: OpenPGP digital signature

Re: Register new acronym in wtf(6) (Re: CVS commit: src/share/misc)

[Kamil Rytarowski]

On 05.05.2018 11:47, Geoff Wing wrote:
> On Friday 2018-05-04 03:01 +1000, Kamil Rytarowski output:
> :Module Name: src
> :Committed By:kamil
> :Date:Thu May  3 17:01:09 UTC 2018
> :
> :Modified Files:
> : src/share/misc: acronyms
> :
> :Log Message:
> :Register new acronym in wtf(6)
> :
> :VLCvariable length array
> :Noted by 
> :cvs rdiff -u -r1.266 -r1.267 src/share/misc/acronyms
> 
> VLC = Variable Length Code (or the video player I use)
> VLA = Variable Length Array
> 
> Am I missing something?
> 
> Regards,
> Geoff
> 

It has been fixed... Should I move this term to acronyms.comp?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 06.06.2018 13:43, Christos Zoulas wrote:
> On Jun 6,  9:47am, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src
> 
> | CC: + Yang Zheng who investigated the root cause.
> 
> http://mail-index.netbsd.org/source-changes/2018/06/02/msg095659.html
> 
> Conditionally elide it.
> 
> christos
> 

I see, I will commit it to src/ now!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 12.06.2018 14:24, Joerg Sonnenberger wrote:
> On Tue, Jun 12, 2018 at 12:00:01PM +0200, Kamil Rytarowski wrote:
>> On 12.06.2018 11:51, matthew green wrote:
>>>> On 12.06.2018 10:28, Kamil Rytarowski wrote:
>>>>> On 12.06.2018 09:04, Martin Husemann wrote:
>>>>>> On Tue, Jun 12, 2018 at 05:47:35AM +0300, Valery Ushakov wrote:
>>>>>>> To sum it up, out of 30+ lines of the commit message, the relevant
>>>>>>> information is contained only in (part of) one line.
>>>>>>
>>>>>> FWIW, I fully agree with uwe here.
>>>>>>
>>>>>> Martin
>>>>>
>>>>> I find keeping reproducers for issues very useful. Keeping track of them
>>>>> helps to check whether fixes are functional.
>>>>>
>>>>> Also introduction of refactoring without a note in the message is not
>>>>> acceptable in my opinion.
>>>>>
>>>>> Thanks to the verbose message people have the whole context.
>>>>
>>>> To be clear, I will keep introducing fixes in the same form. I'm
>>>> catching e.g. bugs in programs only in specific usage and input. If I
>>>> will refactor something I will keep including it in messages too.
>>>
>>> that's a pity.
>>>
>>> i don't mind having a little more detail that uwe is talking
>>> about, but i don't think we need nearly as much.  it's worth
>>> mentioning the sanitizer used as the finding-tool, but there
>>> is no need to repeat the basic fix 3 times, or to reproduce
>>> the code change itself.
>>>
>>> please reconsider and use a shorter form.
>>>
>>
>> I will keep messages within 20 lines.
> 
> That's missing the point. A short description of why the specific
> undefined behavior is seen is useful. Pasting random program output is
> not.
> 
> Joerg
> 

Random program output might not be useful, but the one containing
runtime message is.. and it was 1-liner + 1 line how to invoke it and 1
line of runtime error. I have more to come an I will keep documenting
the runtime error messages.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 12.06.2018 11:51, matthew green wrote:
>> On 12.06.2018 10:28, Kamil Rytarowski wrote:
>>> On 12.06.2018 09:04, Martin Husemann wrote:
>>>> On Tue, Jun 12, 2018 at 05:47:35AM +0300, Valery Ushakov wrote:
>>>>> To sum it up, out of 30+ lines of the commit message, the relevant
>>>>> information is contained only in (part of) one line.
>>>>
>>>> FWIW, I fully agree with uwe here.
>>>>
>>>> Martin
>>>
>>> I find keeping reproducers for issues very useful. Keeping track of them
>>> helps to check whether fixes are functional.
>>>
>>> Also introduction of refactoring without a note in the message is not
>>> acceptable in my opinion.
>>>
>>> Thanks to the verbose message people have the whole context.
>>
>> To be clear, I will keep introducing fixes in the same form. I'm
>> catching e.g. bugs in programs only in specific usage and input. If I
>> will refactor something I will keep including it in messages too.
> 
> that's a pity.
> 
> i don't mind having a little more detail that uwe is talking
> about, but i don't think we need nearly as much.  it's worth
> mentioning the sanitizer used as the finding-tool, but there
> is no need to repeat the basic fix 3 times, or to reproduce
> the code change itself.
> 
> please reconsider and use a shorter form.
> 

I will keep messages within 20 lines.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 12.06.2018 10:28, Kamil Rytarowski wrote:
> On 12.06.2018 09:04, Martin Husemann wrote:
>> On Tue, Jun 12, 2018 at 05:47:35AM +0300, Valery Ushakov wrote:
>>> To sum it up, out of 30+ lines of the commit message, the relevant
>>> information is contained only in (part of) one line.
>>
>> FWIW, I fully agree with uwe here.
>>
>> Martin
>>
> 
> I find keeping reproducers for issues very useful. Keeping track of them
> helps to check whether fixes are functional.
> 
> Also introduction of refactoring without a note in the message is not
> acceptable in my opinion.
> 
> Thanks to the verbose message people have the whole context.
> 

To be clear, I will keep introducing fixes in the same form. I'm
catching e.g. bugs in programs only in specific usage and input. If I
will refactor something I will keep including it in messages too.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 12.06.2018 09:04, Martin Husemann wrote:
> On Tue, Jun 12, 2018 at 05:47:35AM +0300, Valery Ushakov wrote:
>> To sum it up, out of 30+ lines of the commit message, the relevant
>> information is contained only in (part of) one line.
> 
> FWIW, I fully agree with uwe here.
> 
> Martin
> 

I find keeping reproducers for issues very useful. Keeping track of them
helps to check whether fixes are functional.

Also introduction of refactoring without a note in the message is not
acceptable in my opinion.

Thanks to the verbose message people have the whole context.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/cddl/osnet/lib/libdtrace

[Kamil Rytarowski]

On 07.06.2018 15:08, Joerg Sonnenberger wrote:
> On Thu, Jun 07, 2018 at 10:07:27AM +0200, Kamil Rytarowski wrote:
>> On 07.06.2018 00:03, Joerg Sonnenberger wrote:
>>> On Wed, Jun 06, 2018 at 02:18:39PM +, Kamil Rytarowski wrote:
>>>> Module Name:   src
>>>> Committed By:  kamil
>>>> Date:  Wed Jun  6 14:18:39 UTC 2018
>>>>
>>>> Modified Files:
>>>>src/external/cddl/osnet/lib/libdtrace: Makefile
>>>>
>>>> Log Message:
>>>> Make cddl/osnet/lib/libdtrace buildable with MKLLVM=yes
>>>
>>> This is not the correct way to fix this. First of all, the flags are
>>> conditional even for GCC, but more importantly, HAVE_GCC does not mean
>>> that the compiler is GCC. See i.e. ah_regdomain.c handling in sys/conf.
>>>
>>> Joerg
>>>
>>
>> Do you mean to change the switch to: ${ACTIVE_CC} == "clang"?
> 
> == "gcc", but otherwise yes.
> 
> Joerg
> 

I'm test building a patch with ${ACTIVE_CC} for GCC and LLVM
distribution and I will commit it once it will build.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/bsd/nvi/dist/common

[Kamil Rytarowski]

On 16.06.2018 22:39, Christos Zoulas wrote:
> In article <20180616185452.afd29f...@cvs.netbsd.org>,
> Kamil Rytarowski  wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Jun 16 18:54:52 UTC 2018
>>
>> Modified Files:
>>  src/external/bsd/nvi/dist/common: log.c
>>
>> Log Message:
>> Do not cause Undefined Behavior in vi(1)
>>
>> Replace unportable manual calculation of alignof() that causes UB, with
>> a GCC extension __alignof__.
> 
> Isn't that offsetof() instead?
> 
> christos
> 

Fixed!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 13.06.2018 00:54, Robert Elz wrote:
> Date:Tue, 12 Jun 2018 19:52:43 +0200
> From:    Kamil Rytarowski 
> Message-ID:  <90519caf-289c-b4d3-7ebc-d14d4efc9...@gmx.com>
> 
>   | I will try to meet the expectations in commit messages for *San fixes.
> 
> That would be good (and not just those,  unless the board required it, which
> I doubt is likely, there's no need for the "Sponsored by" stuff almost 
> anywhere, maybe just in those monthly reports you send).
> 

OK!

I've got few more reports and I will keep iterating over them and fixing
appropriately.

The next one on my list is grep(1) as it affects every user:

http://www.netbsd.org/~kamil/mksanitizer-reports/0003-grep-_obstack_begin.txt

For the context, UBSan is still able to catch defined unsigned overflow
issues (with an additional command line argument) as these operations
are rather rarely used deliberately in C. It can catch violation of
compiler specific features like passing NULL to a function with
specified nonnull arguments.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.bin/gzip

[Kamil Rytarowski]

On 12.06.2018 15:52, Joerg Sonnenberger wrote:
> On Tue, Jun 12, 2018 at 02:35:40PM +0200, Kamil Rytarowski wrote:
>> On 12.06.2018 14:24, Joerg Sonnenberger wrote:
>>> That's missing the point. A short description of why the specific
>>> undefined behavior is seen is useful. Pasting random program output is
>>> not.
>>>
>>> Joerg
>>>
>>
>> Random program output might not be useful, but the one containing
>> runtime message is.. and it was 1-liner + 1 line how to invoke it and 1
>> line of runtime error. I have more to come an I will keep documenting
>> the runtime error messages.
> 
> Are you trying hard to be obnoxious? The only useful part that you
> quoted is the runtime error itself. The rest is either noise or doesn't
> help with reproduction since it depends on external input. Nothing in
> the commit message contains a real analysis of why this "reproducer"
> triggers the problem. As such, it is pointless noise and shouldn't be
> preserved for eternity.
> 
> Joerg
> 

I will try to meet the expectations in commit messages for *San fixes.

I will try to also dig down why some programs needs in bit mask the sign
bit in unsigned integer instead of quickly swapping the type to unsigned.

There are just many reports so I expected to land patches quickly, just
please be aware that presenting more deep investigation in a commit
message will take longer.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/gpl2/gmake/dist

[Kamil Rytarowski]

On 01.06.2018 10:33, Frédéric Fauberteau wrote:
> Le 2018-05-01 03:23, Kamil Rytarowski a écrit :
>> On 01.05.2018 02:55, Christos Zoulas wrote:
>>> In article
>>> ,
>>> Kimihiro Nonaka   wrote:
>>>> 2018-05-01 8:53 GMT+09:00 Kamil Rytarowski :
>>>>
>>>>> This is polling GPLv3 code into GPLv2 gmake - these licenses are
>>>>> incompatible.
>>>
>>> You mean pulling here? There is no pulling GPLv3 code unless the code
>>> is copied from GPLv3.
>>>
>>
>> It was cherry-picked from GPLv3+.
> 
> Thanks to the following patch, I can cross-build a toolset on my Arch
> box. When I look at the make.git tree:
> http://git.savannah.gnu.org/cgit/make.git/tree/
> I don't see any 'configure' file. In which way this patch breaks the
> license?
> 
> Index: configure
> ===
> RCS file: /cvsroot/src/external/gpl2/gmake/dist/configure,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 configure
> --- configure    18 Aug 2014 06:46:54 -    1.1.1.1
> +++ configure    1 Jun 2018 08:05:31 -
> @@ -13619,10 +13619,9 @@
>  #include 
>  #include 
> 
> -#define GLOB_INTERFACE_VERSION 1
>  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
>  # include 
> -# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
> +# if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
>     gnu glob
>  # endif
>  #endif

http://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n6

# GNU Make is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free
Software
# Foundation; either version 3 of the License, or (at your option) any later
# version.

GPL2 and GPL3 are incompatible for some reasons.. we could just upgrade
gmake to GPLv3. It's used for building GCC only.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 05.01.2016 14:07, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Tue Jan  5 13:07:47 UTC 2016
> 
> Modified Files:
>   src/external/bsd/blacklist/lib: Makefile
>   src/external/bsd/elftoolchain/lib/libdwarf: Makefile
>   src/external/bsd/fetch/lib: Makefile
>   src/external/bsd/libc++/lib: Makefile
>   src/external/gpl2/lvm2/lib/liblvm: Makefile
>   src/external/gpl3/gcc.old/lib/libtsan: Makefile
>   src/external/gpl3/gcc/lib/libtsan: Makefile
>   src/external/mit/xorg/lib/libfontenc: Makefile
>   src/external/mit/xorg/lib/libglut: Makefile
>   src/external/mit/xorg/lib/libpciaccess: Makefile
>   src/external/public-domain/xz/lib: Makefile
>   src/lib/libnpf: Makefile
>   src/sys/rump/kern/lib/libsljit: Makefile
> 
> Log Message:
> - Change LDADD/DPADD in library dependencies to LIBDPLIBS
> - Fix some LDADD abuse and remove useless dependencies
> - include  in the right place where appropriate
> From Rin Okuyama
> 

In this commit:

> Index: src/external/bsd/libc++/lib/Makefile
> diff -u src/external/bsd/libc++/lib/Makefile:1.7 
> src/external/bsd/libc++/lib/Makefile:1.8
> --- src/external/bsd/libc++/lib/Makefile:1.7  Wed Aug 20 11:19:39 2014
> +++ src/external/bsd/libc++/lib/Makefile  Tue Jan  5 08:07:46 2016
> @@ -1,4 +1,4 @@
> -#$NetBSD: Makefile,v 1.7 2014/08/20 15:19:39 joerg Exp $
> +#$NetBSD: Makefile,v 1.8 2016/01/05 13:07:46 christos Exp $
>  
>  LIB= c++
>  WARNS=   4
> @@ -44,6 +44,6 @@ CWARNFLAGS.clang+=  -Wno-error=missing-pr
>  CWARNFLAGS.clang+=   -Wno-error=missing-field-initializers -Wno-error=switch
>  CWARNFLAGS.clang+=   -Wno-error=implicit-exception-spec-mismatch
>  
> -LDADD+=  -Wl,-z,defs
> +LDFLAGS+=-Wl,-z,defs
>  
>  .include 
> 

I know that this -z defs was added by Joerg earlier, but what's the
purpose of it? Do we really need it? Can we drop it?

It breaks building libc++ with sanitizers. This flag is explicitly
adviced against being used at least for ASan and MSan (and certainly
others):

When linking shared libraries, the AddressSanitizer run-time is not
linked, so -Wl,-z,defs may cause link errors (don’t use it with
AddressSanitizer).

https://clang.llvm.org/docs/AddressSanitizer.html

When linking shared libraries, the MemorySanitizer run-time is not
linked, so -Wl,-z,defs may cause link errors (don’t use it with
MemorySanitizer).

https://clang.llvm.org/docs/MemorySanitizer.html


Removal of this -Wl,-z,defs, allows us to build libcxx under MSan.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

CC: + Yang Zheng who investigated the root cause.

On 06.06.2018 09:47, Kamil Rytarowski wrote:
> On 05.01.2016 14:07, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jan  5 13:07:47 UTC 2016
>>
>> Modified Files:
>>  src/external/bsd/blacklist/lib: Makefile
>>  src/external/bsd/elftoolchain/lib/libdwarf: Makefile
>>  src/external/bsd/fetch/lib: Makefile
>>  src/external/bsd/libc++/lib: Makefile
>>  src/external/gpl2/lvm2/lib/liblvm: Makefile
>>  src/external/gpl3/gcc.old/lib/libtsan: Makefile
>>  src/external/gpl3/gcc/lib/libtsan: Makefile
>>  src/external/mit/xorg/lib/libfontenc: Makefile
>>  src/external/mit/xorg/lib/libglut: Makefile
>>  src/external/mit/xorg/lib/libpciaccess: Makefile
>>  src/external/public-domain/xz/lib: Makefile
>>  src/lib/libnpf: Makefile
>>  src/sys/rump/kern/lib/libsljit: Makefile
>>
>> Log Message:
>> - Change LDADD/DPADD in library dependencies to LIBDPLIBS
>> - Fix some LDADD abuse and remove useless dependencies
>> - include  in the right place where appropriate
>> From Rin Okuyama
>>
> 
> In this commit:
> 
>> Index: src/external/bsd/libc++/lib/Makefile
>> diff -u src/external/bsd/libc++/lib/Makefile:1.7 
>> src/external/bsd/libc++/lib/Makefile:1.8
>> --- src/external/bsd/libc++/lib/Makefile:1.7 Wed Aug 20 11:19:39 2014
>> +++ src/external/bsd/libc++/lib/Makefile Tue Jan  5 08:07:46 2016
>> @@ -1,4 +1,4 @@
>> -#   $NetBSD: Makefile,v 1.7 2014/08/20 15:19:39 joerg Exp $
>> +#   $NetBSD: Makefile,v 1.8 2016/01/05 13:07:46 christos Exp $
>>  
>>  LIB=c++
>>  WARNS=  4
>> @@ -44,6 +44,6 @@ CWARNFLAGS.clang+= -Wno-error=missing-pr
>>  CWARNFLAGS.clang+=  -Wno-error=missing-field-initializers -Wno-error=switch
>>  CWARNFLAGS.clang+=  -Wno-error=implicit-exception-spec-mismatch
>>  
>> -LDADD+= -Wl,-z,defs
>> +LDFLAGS+=   -Wl,-z,defs
>>  
>>  .include 
>>
> 
> I know that this -z defs was added by Joerg earlier, but what's the
> purpose of it? Do we really need it? Can we drop it?
> 
> It breaks building libc++ with sanitizers. This flag is explicitly
> adviced against being used at least for ASan and MSan (and certainly
> others):
> 
> When linking shared libraries, the AddressSanitizer run-time is not
> linked, so -Wl,-z,defs may cause link errors (don’t use it with
> AddressSanitizer).
> 
> https://clang.llvm.org/docs/AddressSanitizer.html
> 
> When linking shared libraries, the MemorySanitizer run-time is not
> linked, so -Wl,-z,defs may cause link errors (don’t use it with
> MemorySanitizer).
> 
> https://clang.llvm.org/docs/MemorySanitizer.html
> 
> 
> Removal of this -Wl,-z,defs, allows us to build libcxx under MSan.
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/cddl/osnet/lib/libdtrace

[Kamil Rytarowski]

On 07.06.2018 00:03, Joerg Sonnenberger wrote:
> On Wed, Jun 06, 2018 at 02:18:39PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Wed Jun  6 14:18:39 UTC 2018
>>
>> Modified Files:
>>  src/external/cddl/osnet/lib/libdtrace: Makefile
>>
>> Log Message:
>> Make cddl/osnet/lib/libdtrace buildable with MKLLVM=yes
> 
> This is not the correct way to fix this. First of all, the flags are
> conditional even for GCC, but more importantly, HAVE_GCC does not mean
> that the compiler is GCC. See i.e. ah_regdomain.c handling in sys/conf.
> 
> Joerg
> 

Do you mean to change the switch to: ${ACTIVE_CC} == "clang"?

I've followed the approach in share/mk/bsd.sys.mk:

.if (defined(HAVE_GCC) \
 && (${MACHINE_ARCH} == "coldfire" || \
 ${MACHINE_CPU} == "sh3" || \
 ${MACHINE_CPU} == "m68k"))
# XXX GCC 4.5 for sh3 and m68k (which we compile with -Os) is extra
noisy for
# cases it should be better with
CFLAGS+=-Wno-uninitialized
CFLAGS+=-Wno-maybe-uninitialized
.endif

And this works.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/mpl/dhcp

[Kamil Rytarowski]

On 22.06.2018 17:05, Jason Thorpe wrote:
> 
> 
>> On Jun 22, 2018, at 7:44 AM, matthew green  wrote:
>>
>> meaning -- it uses libraries normally installed in /usr/lib but
>> links them statically?
>>
>> those libraries should move to /lib.  they're already part of
>> the root fs (mostly).  then all this stupid makefile and linking
>> crap can go away, and your problem solved.
> 
> Modulo the silliness of continuing to support /usr on a separate file system, 
> "what Matt said."
> 
> -- thorpej
> 

From a MKSANITIZER point of view we want to remove conflicts with libc
and libpthread symbols.

http://netbsd.org/~kamil/programs-baselibs-symbol-clash-2018-06-03-2.txt



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.sbin/sysinst

[Kamil Rytarowski]

On 24.06.2018 21:52, Christos Zoulas wrote:
> In article <0a88399a-0897-160e-6a56-ae328bd4c...@gmx.com>,
> Kamil Rytarowski   wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>>> This is not the correct fix. No change to set_status should happen at any
>>> index >= SET_LAST, you are papering over the real bug.
>>>
>>> Please provide more information where this access happens if easily 
>>> available
>>> (or let me debug it properly).
> 
> Fixed.
> 
> christos
> 

Thanks!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/usr.sbin/sysinst

[Kamil Rytarowski]

On 24.06.2018 08:31, Martin Husemann wrote:
> On Sat, Jun 23, 2018 at 10:35:29PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Jun 23 22:35:29 UTC 2018
>>
>> Modified Files:
>>  src/usr.sbin/sysinst: util.c
>>
>> Log Message:
>> Enlarge the set_status[] array by a single element
>>
>> In the get_and_unpack_sets() function there is accessed the
>> set_status[SET_GROUP_END] element in the array. The array is allocated on
>> the stack with SET_GROUP_END elements. This means that it is 1 element too
>> short.
> 
> This is not the correct fix. No change to set_status should happen at any
> index >= SET_LAST, you are papering over the real bug.
> 
> Please provide more information where this access happens if easily available
> (or let me debug it properly).
> 
> Martin
> 

Address Sanitizer report:

http://netbsd.org/~kamil/mksanitizer-reports/0021-sysinst-sets.txt

It happens just before unpacking the sets.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/mpl/dhcp

[Kamil Rytarowski]

On 22.06.2018 16:18, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu Jun 21 11:02:48 UTC 2018
>>
>> Modified Files:
>>  src/external/mpl/dhcp: Makefile.inc
>>
>> Log Message:
>> Make building of dhcp compatible with MKSANITIZER
>>
>> Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER.
>> These options are incompatible with the current design of sanitizers,
>> because they cause duplication of symbols into programs and thus symbols
>> from the interceptors from sanitizers cannot be linked.
>>
>> This change makes effectively mounting /usr required for dhcp programs like
>> dhclient(8).
> 
> why does dhclient link this way?  at the very least, adding
> a comment to the Makefile.inc would help, but i wonder if this
> is not some artifact of old times we should remove, at least
> for MKDYNAMICROOT=yes.
> 
> 
> .mrg.
> 

Well, there is an ongoing discussion to phase out dhcp (dhclient) out of
the base system.

It duplicates symbols from libraries in order to be usable without /usr
mounted. dhcpcd doesn't need it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/gpl2/gmake/dist

[Kamil Rytarowski]

On 01.05.2018 02:55, Christos Zoulas wrote:
> In article 
> <cam+xf6ceazak+1mwf7mukce6zk--a2htirhnmt7wodz6-i0...@mail.gmail.com>,
> Kimihiro Nonaka  <nona...@gmail.com> wrote:
>> 2018-05-01 8:53 GMT+09:00 Kamil Rytarowski <n...@gmx.com>:
>>
>>> This is polling GPLv3 code into GPLv2 gmake - these licenses are
>>> incompatible.
> 
> You mean pulling here? There is no pulling GPLv3 code unless the code
> is copied from GPLv3.
> 

It was cherry-picked from GPLv3+.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/gpl2/gmake/dist

[Kamil Rytarowski]

On 28.04.2018 14:20, NONAKA Kimihiro wrote:
> Module Name:  src
> Committed By: nonaka
> Date: Sat Apr 28 12:20:41 UTC 2018
> 
> Modified Files:
>   src/external/gpl2/gmake/dist: configure configure.in
> 
> Log Message:
> gmake: Apply patch to support GLIBC glob interface v2
> 
> http://git.savannah.gnu.org/cgit/make.git/commit/?id=48c8a116
> 
> Fix a build failure on Ubuntu 18.04.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl2/gmake/dist/configure \
> src/external/gpl2/gmake/dist/configure.in
> 

This is polling GPLv3 code into GPLv2 gmake - these licenses are
incompatible.

I think we should either upgrade it to GPLv3 now or remove it.



signature.asc
Description: OpenPGP digital signature

Re: src/sys/kern/subr_prf.c r1.161

[Kamil Rytarowski]

On 27.10.2017 14:13, Frédéric Fauberteau wrote:
> Hi,
> 
> Since revision 1.161 of src/sys/kern/subr_prf.c, I encounter the
> following error:
> /home/triaxx/netbsd8/usr/src/sys/kern/subr_lockdebug.c: In function
> 'lockdebug_barrier':
> /home/triaxx/netbsd8/usr/src/sys/kern/subr_lockdebug.c:683:24: error:
> passing argument 2 of 'lockdebug_dump' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>  lockdebug_dump(ld, printf);
> ^
> /home/triaxx/netbsd8/usr/src/sys/kern/subr_lockdebug.c:106:13: note:
> expected 'void (*)(const char *)' but argument is of type 'int (*)(const
> char *)'
>  static void lockdebug_dump(lockdebug_t *, void (*)(const char *, ...)
> 
> I fixed it by casting printf:
> +
> + lockdebug_dump(ld, (void (*)(const char *, ...))printf);
> +
> but it does not appear as an elegant solution...
> 

Fixed in HEAD. printf(9) change has been reverted.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 27.10.2017 13:44, Christos Zoulas wrote:
> In article <20171027113720.gb5...@britannica.bec.de>,
> Joerg Sonnenberger   wrote:
>> On Fri, Oct 27, 2017 at 09:59:17AM +, Utkarsh Anand wrote:
>>> Module Name:src
>>> Committed By:   utkarsh009
>>> Date:   Fri Oct 27 09:59:17 UTC 2017
>>>
>>> Modified Files:
>>> src/sys/arch/x86/x86: intr.c
>>> src/sys/ddb: db_interface.h db_panic.c
>>> src/sys/kern: init_main.c subr_autoconf.c subr_disk.c subr_prf.c
>>> vfs_subr.c vfs_wapbl.c
>>> src/sys/sys: systm.h
>>> src/sys/ufs/ufs: ufs_lookup.c
>>>
>>> Log Message:
>>> [syzkaller] Attempted fix for https://github.com/google/syzkaller/issues/399
>>>
>>> syzkaller was failing to extract constants because of the above
>> mentioned issue so I had to redeclare printf in sys/sys/systm.h
>>> For more information on syzkaller, visit: 
>>> https://github.com/google/syzkaller
>>
>> Please revert this commit immediately.
>>
>> (1) The commit message is useless. It doesn't provide any understandable
>> justification for this change.
>>
>> (2) The commit itself changes a central part of the kernel without any
>> review or consensus. If you want to get it recommitted, please bring it
>> up FIRST on tech-kern.
>>
>> (3) Having to add > 10 casts in random places in a way that is at best
>> implementation-defined behavior should be a huge warning sign that this
>> change is a bad idea.
> 
> Yes, this needs to be undone and we need to think about this carefully
> first. There are other ways to make syzcaller happy.
> 
> christos
> 

Just a remainder that casting function pointers to data pointers is a
bold hack and not portable from the C language point of view... but I
know that it's there for as the last resort. 3rd party software isn't a
legitimate reason to go for it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 27.10.2017 14:05, Joerg Sonnenberger wrote:
> On Fri, Oct 27, 2017 at 01:44:18PM +0200, Kamil Rytarowski wrote:
>> Just a remainder that casting function pointers to data pointers is a
>> bold hack and not portable from the C language point of view... but I
>> know that it's there for as the last resort. 3rd party software isn't a
>> legitimate reason to go for it.
> 
> This is not the concern I am talking about. The problem I have is
> expecting casts between different signatures to work.
> 
> Joerg
> 

Yes, agreed on this. Just adding another reason why this looks fishy.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/uvm

[Kamil Rytarowski]

On 28.10.2017 00:14, Taylor R Campbell wrote:
>> Date: Fri, 27 Oct 2017 21:46:48 + (UTC)
>> This needs to be pulled up to -8.
> 
> Yes.
> 

I've verified that the reported bug is gone.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

[Kamil Rytarowski]

On 05.01.2018 22:24, m...@netbsd.org wrote:
>> Register new weak symbol in libc for internal usage: atoi
> 
> Why are we protecting libc from users who override standard C functions?
> I don't think you should be able to provide a wrong implementation of
> them, link to libc, and expect it to work.
> 

I'm incercepting atoi(3) & other functions in sanitizers. I cannot
reliably intercept them within libc internals (e.g. I'm marking certain
data under pointer as initialized, but not inside libc), this change
allows to keep libc as a black-box for those who overwrite atoi() in 3rd
party software and expect libc to still work as is.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 25.12.2017 02:21, m...@netbsd.org wrote:
> On Tue, Dec 19, 2017 at 07:40:04PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Dec 19 19:40:04 UTC 2017
>>
>> Modified Files:
>>  src/sys/compat/netbsd32: netbsd32_netbsd.c netbsd32_syscall.h
>>  netbsd32_syscallargs.h netbsd32_syscalls.c
>>  netbsd32_syscalls_autoload.c netbsd32_sysent.c
>>  netbsd32_systrace_args.c syscalls.master
>>  src/sys/kern: init_sysent.c syscalls.c syscalls.master
>>  syscalls_autoload.c systrace_args.c
>>  src/sys/rump/include/rump: rump_syscalls.h
>>  src/sys/rump/librump/rumpkern: rump_syscalls.c
>>  src/sys/sys: syscall.h syscallargs.h
>>  src/sys/uvm: uvm_unix.c
>>
>> Log Message:
>> Drop SYS_vadvise
>>
>> The (o)vadvise syscall is dummy since the beginning of NetBSD.
>>
>> It is an obsolete remnant from the old UNIX.
> 
> I think this removes a symbol from libc too
> 

This is correct.

$ nm /usr/lib/libc.so|grep vadvise


0003b980 T vadvise

I will fix it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc

[Kamil Rytarowski]

On 07.01.2018 00:42, Joerg Sonnenberger wrote:
> On Fri, Jan 05, 2018 at 08:01:32PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Jan  5 20:01:32 UTC 2018
>>
>> Modified Files:
>>  src/lib/libc/include: namespace.h
>>  src/lib/libc/time: asctime.c
>>
>> Log Message:
>> Register new weak symbol in libc for internal usage: asctime
> 
> Please revert this. It is plainly wrong.
> 
> Joerg
> 

I will check this case (whether my understanding and rationale is
correct) with the sanitizer developers and be back to this, on a public
mailing list (tech-userlevel).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/include

[Kamil Rytarowski]

On 07.01.2018 00:41, Joerg Sonnenberger wrote:
> On Fri, Jan 05, 2018 at 06:57:06PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Jan  5 18:57:06 UTC 2018
>>
>> Modified Files:
>>  src/lib/libc/include: namespace.h
>>
>> Log Message:
>> Register more syscalls in namespace.h (of libc)
>>
>> Add weak symbols for:
>>  - fcntl
>>  - close
>>  - execve
>>  - setcontext
>>  - wait6
>>  - write
>>  - writev
> 
> Most of those are standard library calls. They should not be weak unless
> they are also a cancellation point.
> 
> Joerg
> 

I had a different goal of marking them weak.

But looking at the specs about the cancellation point functions I can
read the following:

"Cancellation points shall occur when a thread is executing the
following functions:"

fcntl, close, related to wait6 (wait, waitpid, waitid), write, writev



From the another commit about asctime:

"A cancellation point may also occur when a thread is executing the
following functions:"

asctime()



http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer

[Kamil Rytarowski]

On 05.02.2018 23:04, matthew green wrote:
> Module Name:  src
> Committed By: mrg
> Date: Mon Feb  5 22:04:54 UTC 2018
> 
> Modified Files:
>   src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
>   sanitizer_linux.cc sanitizer_platform_limits_posix.cc
>   src/external/gpl3/gcc/dist/libsanitizer/ubsan: ubsan_platform.h
> 
> Log Message:
> - enable powerpc and arm support.
> - port GetPcSpBp() to netbsd/powerpc* and netbsd/arm.
> 
> 

Upstream for the sanitizers is located in LLVM compiler-rt/lib (it's
equivalent to libsanitier in GCC with added wrappers for GCC).

https://github.com/llvm-mirror/compiler-rt

8snapshot contains a decent part of the upstreamed NetBSD work (at least
ASan, UBSan, partial TSan).

I think that we should upgrade libsanitizer to 8snapshot as-is, instead
of repeating the porting effort for 6.x. Or even better upgrade to HEAD
from LLVM directly (TSan, MSan + other fixes).

I will pickup the !amd64 patches added here and upstream to LLVM directly.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/arch

[Kamil Rytarowski]

On 17.02.2018 21:56, Joerg Sonnenberger wrote:
> On Sat, Feb 17, 2018 at 06:51:53PM +, Maxime Villard wrote:
>> Module Name: src
>> Committed By:maxv
>> Date:Sat Feb 17 18:51:53 UTC 2018
>>
>> Modified Files:
>>  src/sys/arch/amd64/amd64: vector.S
>>  src/sys/arch/i386/i386: vector.S
>>  src/sys/arch/x86/include: intr.h
>>  src/sys/arch/x86/x86: i8259.c intr.c
>>  src/sys/arch/xen/x86: pintr.c
>>
>> Log Message:
>> Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
>> same name, eg:
>>
>>  legacy_stubs
>>  -> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
>>  -> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
>>  ...
> 
> I find this change confusing. i8259 is pretty explicit on what it means.
> legacy is not clear at all. Is non-MSI(X) legacy?
> 
> Joerg
> 

Personally, I'm familiar with the 'legacy' wording. i8259 might be
explicit but at least from my perspective it's unused.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/lib/libc/regex

[Kamil Rytarowski]

On 14.01.2016 21:41, Christos Zoulas wrote:
> +The
> +.Fa rm
> +array must be at least 10 elements long, and should contain the result
> +of the matches from a previous
> +.Fn regexec
> +call.

Could we have an argument to regasub(3)/regnsub(3) "size_t nmatch" like
in regexec(3), instead of assuming >= 10 elements long?

It might not be too late to alter this function. There is only 1 user in
GCC and no stable releases with this API.

My rationale is to sanitize these interfaces without caching the number
of elements for a regexec(3) call in a sanitizer. Additionally we could
have an internal sanity check to prevent out of bound operations on the
"regmatch_t *" type.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 22.12.2017 17:58, Robert Elz wrote:
> Date:Fri, 22 Dec 2017 23:35:12 +0700
> From:Robert Elz 
> Message-ID:  <19521.1513960...@andromeda.noi.kre.to>
> 
>   | The EFAULT that is returned there is probably the one Kamil mentioned.
> 
> And of course it is, as in the test ...
> 
>   if ((p != curproc && (p->p_sflag & PS_WEXIT) != 0) ||
> 
> (the || alternative is irrelevant, even though it is XXX'd) as
> we know p != curproc (this is ptrace I/O - the process whose addr
> space is being written is not the process doing the sys call
> "What never?   Well, hardly ever...")  and nor is that process usually
> exiting (too late to modify it then) - so for ptrace() that test
> is more or less guaranteed true - which leads to the EFAULT.
> 
> kre
> 

Thank you for the investigation!

I'm cleaning up now the status of the existing tests and be back to to
proper fix for PT_READ/WRITE_I/D.



signature.asc
Description: OpenPGP digital signature

Re: ubsan.c (was: CVS commit: src/common/lib/libc/misc)

[Kamil Rytarowski]

On 03.08.2018 04:48, Paul Goyette wrote:
> If there are no licensing issues or concerns, then please describe the
> real reason(s) for avoiding KNF.
> 
> 

As discussed, we have removed the comment and drop the unnecessary part
from CVS log.




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/kern

[Kamil Rytarowski]

On 02.08.2018 12:23, Kamil Rytarowski wrote:
> I will defer the research on a proper solution in the networking code as
> I'm swamped by the development and improving of tool catching
> misalignment access. I will be done with it soon.
> 

For the record, I've landed the kUBSan implementation. Please uncomment
the "kubsan" kernel config option and rebuild from scratch the kernel.

It will detect misalignment issues.

I've observed that GCC is more sensible to these checks than Clang/LLVM.




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/external/bsd/dhcpcd/dist/src

[Kamil Rytarowski]

On 03.08.2018 12:26, Robert Elz wrote:
> Date:Fri, 3 Aug 2018 02:17:33 +
> From:    "Kamil Rytarowski" 
> Message-ID:  <20180803021733.b2002f...@cvs.netbsd.org>
> 
>   | GCC with -fsanitize=undefiend detects a potential overflow in the code.
>   | Cast the return value of ntohs(3) to size_t.
> 
> I don't understand the point of this change, and I believe it to
> be wrong and misguided.
> 
> Further if there ever was a potential problem from this line ...
> 
>   *len = ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
> then
>   *len = (size_t)ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
> 
> will not fix it.   The possible problem being if ip_len < 28 (the sum of the
> two sizeof's).While I didn't check this code, that possibility is usually
> verified elsewhere, and even if not, adding the cast changes nothing, the
> result is still bogus (that is, at best, the change could be masking a real
> bug, though that's unlikely.)
> 
> This looks to be (somehow) determining that the result of ntohs(ip_len)
> might somehow be negative (or something, I'm not really sure what is
> being believed is happening) but the ntohs() result is (in all cases here)
> a uint16_t (either because the result is literally the arg, which is that 
> type,
> or because it is the result of bswap16() which is declared that way.)
> 
> The sizeof() ops make the expression at least a size_t - so unless size_t
> and uint16_t are the same (which might happen on a pdp-11 or similar,
> though even there it is unlikely I suspect) the narrower one needs to be
> promoted - whether the ntohs() result is implicitly promoted to size_t, or
> explicitly cast cannot make any difference, can it?
> 
> So what exactly is being fixed here?  Which behaviour is supposedly undefined?
> 

It was a build time error generated by GCC. The compiler detected that
both sizeof() could be large enough to overflow the result returned from
 ntohs(3). And overflowing a signed integer is Undefined Behavior.

This change points to the compiler that the code is safe.

> kre
> 




signature.asc
Description: OpenPGP digital signature