On 03.11.2020 23:20, co...@sdf.org wrote:
> On Tue, Nov 03, 2020 at 10:42:27PM +0100, Martin Husemann wrote:
>> On Tue, Nov 03, 2020 at 10:23:30PM +0100, Reinoud Zandijk wrote:
>>> To be clear, do we want to (keep) supporting legacy devices? Its not
>>> required
>>> in 1.0 and could clean up the c
On 21.10.2020 14:14, co...@sdf.org wrote:
> On Tue, Oct 20, 2020 at 07:11:05PM +, co...@sdf.org wrote:
>> hello,
>>
>> As a background, some Linux binaries don't claim to be targeting the
>> Linux OS, but instead are "SYSV".
>>
>> We have used some heuristics to still identify those binaries as
The same bug was fixed in FreeBSD here:
"amd64: Store full 64bit of FIP/FDP for 64bit processes when using XSAVE."
https://github.com/freebsd/freebsd/commit/62a9018a8878533432500e5cb89f9bd07fd9ef14
Kamil Rytarowski
CTO, Moritz Systems
www.moritz.systems
pt., 16 paź 2020 o 15:26 Mi
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.
.
What's the benefit of keeping it around and having no users and
documented deprecation plus being prone to miscompilation? The removal
does not break libc or kernel ABIs. Most 3rd party users of these
macros deliver a homegrown copy of sys/queue.h anyway.
Kamil Rytarowski
CTO, Moritz Sy
Kamil Rytarowski
CTO, Moritz Systems
www.moritz.systems
pon., 12 paź 2020 o 04:23 matthew green napisał(a):
>
> Kamil Rytarowski writes:
> > Switch the last user (ypserv) from CIRCLEQ to TAILQ.
> > This is inspired by analogous refactoring from OpenBSD:
> > https://
It was marked deprecated in NetBSD 7 and already removed from
FreeBSD in 2000 and OpenBSD in 2015.
---
share/man/man3/queue.3 | 10 +++
sys/sys/queue.h| 196 -
2 files changed, 10 insertions(+), 196 deletions(-)
diff --git a/share/man/man3/queue.3
The CIRCLEQ API from sys/queue.h is deprecated since NetBSD 7 and
it will be removed soon. The CIRCLEQ API implementation is prone
to a miscompilation due to the pointer aliasing and is discouraged.
---
usr.sbin/ypserv/ypserv/ypserv_db.c | 14 +++---
1 file changed, 7 insertions(+), 7 dele
this fact in the QUEUE(3) man-page.
Kamil Rytarowski (2):
Convert the CIRCLEQ (from sys/queue.h) usage to TAILQ
Remove the CIRCLEQ API
share/man/man3/queue.3 | 10 ++
sys/sys/queue.h| 196 -
usr.sbin/ypserv/ypserv/ypserv_db.c | 14
On 19.08.2020 20:02, Roy Marples wrote:
> On 18/08/2020 20:52, Mouse wrote:
Perhaps it would need a new flavour of file descriptor, [...]
>>> Linux has apparently done this: pidfd (file descriptors representing
>>> a process). The idea is that you can pass them to various system
>>> call vari
I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer.
WAPBL - Write Ahead Physical Block Logging file system journaling
More info on WAPBL in wapbl(4).
https://netbsd.gw.com/cgi-bin/man-cgi?wapbl++NetBSD-current
Rationale: the default filesystem (FFS) without WAPBL is mor
On 04.07.2020 15:51, Jaromír Doleček wrote:
> Le sam. 4 juil. 2020 à 15:30, Kamil Rytarowski a écrit :
>>> Kamil - what's the difference in gcc between -Wframe-larger-than= and
>>> -Wstack-size= ?
>>>
>>
>> -Wstack-size doesn't exist?
>
On 10.07.2020 15:41, Robert Elz wrote:
> Unfortunately
> I have no idea what "qualifying pgrp for job control" is supposed to mean.
The Design and implementation of 4.4book phrases it as: number of
processes with parent controlling terminal.
Unfortunately the book does not explain whether pg_jobc
On 04.07.2020 14:00, Jaromír Doleček wrote:
> Can anybody using clang please confirm kernel build with
> -Wframe-larger-than=3584?
>
NetBSD-current from today, amd64 GENERIC builds for me.
> Kamil - what's the difference in gcc between -Wframe-larger-than= and
> -Wstack-size= ?
>
-Wstack-size
On 09.06.2020 20:11, Robert Elz wrote:
> Date:Tue, 9 Jun 2020 17:04:54 +0200
> From: Kamil Rytarowski
> Message-ID:
>
>
> | Yes... syzkaller had like 12 different ways to reproduce it.
>
> OK, thanks.
>
> | There is still a race
On 15.06.2020 15:21, Johnny Billquist wrote:
>
> Anyway. Who here does not modify their path at login anyway.
The path has to be readily available for pkgsrc users with unprepared
environment.
However if we install the utility into /usr/sys (similar to /usr/games),
we can use a full path to the
On 15.06.2020 14:35, Reinoud Zandijk wrote:
> On Mon, Jun 15, 2020 at 02:06:00PM +0200, Kamil Rytarowski wrote:
>> On 15.06.2020 13:44, Reinoud Zandijk wrote:
>>> No need to install it in base. The resulting files can then be committed
>>> as `regen' just li
On 15.06.2020 14:16, Johnny Billquist wrote:
> On 2020-06-15 14:12, Kamil Rytarowski wrote:
>> On 15.06.2020 14:11, Johnny Billquist wrote:
>>>
>>> We should not clutter the directories that are in the normal users path
>>> with things that a normal user would
On 15.06.2020 14:11, Johnny Billquist wrote:
>
> We should not clutter the directories that are in the normal users path
> with things that a normal user would never care about.
I never used 90% of the programs from /usr/bin /usr/sbin /bin /sbin. but
I definitely would use makesyscall(1). If you
On 15.06.2020 13:44, Reinoud Zandijk wrote:
> No need to install it in base. The resulting
> files can then be committed as `regen' just like the pcidevs variants.
I disagree as we don't want to pull ${BSDSRCDIR} dependency for users,
for building an application.
This utility shall receive ATF t
On 15.06.2020 00:57, Johnny Billquist wrote:
> On 2020-06-15 00:52, Kamil Rytarowski wrote:
>> On 15.06.2020 00:26, Johnny Billquist wrote:
>>> But that's just me. I'll leave the deciding to you guys...
>>>
>>
>> This is only me, but /sbin and /usr/
On 15.06.2020 00:26, Johnny Billquist wrote:
> But that's just me. I'll leave the deciding to you guys...
>
This is only me, but /sbin and /usr/sbin are for users with root
privileges, while /bin and /usr/bin for everybody. makesyscalls(1)
intends to be an end-user program that aids building soft
On 14.06.2020 23:59, Johnny Billquist wrote:
> On 2020-06-14 23:21, Paul Goyette wrote:
>> On Sun, 14 Jun 2020, David Holland wrote:
>>
>>
>>
>>> This raises two points that need to be bikeshedded:
>>>
>>> (1) What's the new tool called, and where does it live in the tree?
>>> "usr.bin/makesyscall
I propose to add a new option for building rumpkernel:
RUMP_USE_LIBC_ALLOCATORS.
This option wires the kernel allocators directly to the libc functions.
This is useful for sanitizers with their fine-grained checks of
allocated chunks.
http://netbsd.org/~kamil/patch-00268-RUMP_USE_LIBC_ALLOCATORS.
On 10.06.2020 01:13, David Holland wrote:
> The question is: do we want the Python version in the tree now
For this, I would say "NO", at least as long Python is out of base and
IMO it shall not be there.
But it is fine to put into othersrc/.
On 10.06.2020 01:13, David Holland wrote:
> Rewriting
On 09.06.2020 16:35, Robert Elz wrote:
> Date:Tue, 9 Jun 2020 14:13:56 +0200
> From: Kamil Rytarowski
> Message-ID: <85d5e51f-afd1-1038-fd68-2366ff073...@netbsd.org>
>
> | Here is the simplest reproducer crashing the kernel on negative pg_
On 09.06.2020 08:38, Maxime Villard wrote:
>> Should we allow pg_jobc going negative?
>
> I don't think so, the code is not designed to expect negative values.
Here is the simplest reproducer crashing the kernel on negative pg_jobc:
http://netbsd.org/~kamil/ptrace/pg_jobc-crash.c
On 09.06.2020
On 09.06.2020 10:23, Michael van Elst wrote:
> m...@m00nbsd.net (Maxime Villard) writes:
>
>> You can see they are all different, but all have to do with reading the
>> group pointer, which was either freed, overwritten, not initialized,
>> unmapped, or contained pure garbage. This is typical of r
pg_jobc is a process group struct member counting the number of
processes with a parent capable of doing job control. Once reaching 0,
the process group is orphaned.
With the addition of asserts checking for pg_jobc > 0 (by maxv@), we
caught issues that pg_jobc can go negative. I have landed new A
On 06.06.2020 00:25, Jaromír Doleček wrote:
> Le ven. 5 juin 2020 à 21:49, syzbot
> a écrit :
>> [ 44.1699615] panic: UBSan: Undefined Behavior in
>> /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/vfs_lockf.c:843:16, signed
>> integer overflow: 131072 + 9223372036854771712 cannot be represen
Can we adopt -Wframe-larger-than=1024 and mark it fatal?
This option is supported by GCC and Clang.
On 31.05.2020 15:55, Jaromír Doleček wrote:
> I think it would make sense to add -Wstack-usage=X to kernel builds.
>
> Either 2KB or 1KB seems to be good limit, not too many offenders
> between 1K
On 19.05.2020 15:06, Robert Elz wrote:
> Date:Tue, 19 May 2020 14:12:31 +0200
> From: Kamil Rytarowski
> Message-ID: <6874bb63-5146-797f-98b7-b9c497677...@gmx.com>
>
> | Rationale for pointless?
>
> There is no point. What more can I s
On 19.05.2020 08:38, Robert Elz wrote:
> Date:Mon, 18 May 2020 21:11:36 +0200
> From: Kamil Rytarowski
> Message-ID: <05255347-1c55-2762-aaf6-fec3caf48...@gmx.com>
>
> | Next, I can add my value at the end of list (and before _P_MAXIDTYPE).
On 18.05.2020 22:18, Christos Zoulas wrote:
>
>
>> On May 18, 2020, at 3:40 PM, Kamil Rytarowski wrote:
>>
>> If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
>> we can force the number anyway). If I delete P_CID there is an inelegant
>&
On 18.05.2020 21:31, Taylor R Campbell wrote:
>> Date: Mon, 18 May 2020 21:11:36 +0200
>> From: Kamil Rytarowski
>>
>> On 18.05.2020 20:24, Robert Elz wrote:
>>> Date:Mon, 18 May 2020 19:45:55 +0200
>>> From:Kamil Rytarowski
>
On 18.05.2020 20:24, Robert Elz wrote:
> Date:Mon, 18 May 2020 19:45:55 +0200
> From: Kamil Rytarowski
> Message-ID:
>
> | I have got a local use-case for another P_type (premature to discuss it
> | in this thread) and I would rather recyc
POSIX notes:
"The type idtype_t shall be defined as an enumeration type whose
possible values shall include at least the following: P_ALL P_PGID P_PID"
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html
For some reason we copied as-is solaris types into our public headers
Is it possible to avoid negation in the name?
KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION
On 17.05.2020 00:51, Paul Goyette wrote:
> I'm not sure I like the name!
>
> Can you call it KAUTH_SYSTEM_DISABLE_SWAPENCRYPT ? That more
> closely describes the action which is being controlled.
>
>
> On Sat, 1
On 16.05.2020 18:52, Nick Hudson wrote:
>
> On 16/05/2020 12:45, Kamil Rytarowski wrote:
>> On 16.05.2020 07:48, Nick Hudson wrote:
>>> On 15/05/2020 17:35, Kamil Rytarowski wrote:
>>>> I propose the following patch:
>>>>
>>>> http://
On 16.05.2020 07:48, Nick Hudson wrote:
> On 15/05/2020 17:35, Kamil Rytarowski wrote:
>> I propose the following patch:
>>
>> http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt
>>
>> Does it look good?
>>
>> Nick, does it fix the hppa l
I propose the following patch:
http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt
Does it look good?
Nick, does it fix the hppa locking problem?
signature.asc
Description: OpenPGP digital signature
Is there any good reason that fstat(1) needs kvm(3)? Is it viable to
offer its functionality with sysctl(3), in particular in struct kinfo_file?
I'm have got a use-case (in GDB (*)) where I would make use of more
fields in struct kinfo_file, at least file path and socket information.
Maybe it wou
On 02.04.2020 04:06, Mouse wrote:
>> We should maintain a contract that all new ioctl operations are
>> system wide unique.
>
> That is, unfortunately, unenforceable in the presence of a user base
> that writes and shares code. If I #define IOCNEWTHING _IO('?',7) and
> someone else #defines IOCOTH
On 02.04.2020 03:33, Mouse wrote:
$ ioctlname 2148554498
WSKBDIO_COMPLEXBELL
>>> Where would you get the mapping between the ioctl value and the
>>> name? [...]
>> Everything is already done in kdump and reused in other tools like
>> ktruss.
>
> So, the big switch() method.
>
Yes.
We s
On 02.04.2020 02:14, Christos Zoulas wrote:
> In article <0fd513f7-6f0c-6ed1-2119-6ce5313d4...@gmx.com>,
> Kamil Rytarowski wrote:
>> I propose to add two new tools:
>>
>> - ioctlname
>> - ioctldecode
>
> I would call it ioctlprint and have:
>
> i
On 02.04.2020 02:56, Mouse wrote:
>> $ ioctldecode 2148554498
>> _IOW('W',0x2,0x10)
>
>> $ ioctlname 2148554498
>> WSKBDIO_COMPLEXBELL
>
> Where would you get the mapping between the ioctl value and the name?
> Would this be just a huge switch statement (or compiled-in table), or
> would it search
I propose to add two new tools:
- ioctlname
- ioctldecode
Both of them are a special mode embedded into kdump(1).
>From time to time there is need to decode IOCTL codes and there is no
(as far as I am aware) easy tool to do so.
ioctlname is already invented and it calls the internal function
On 24.03.2020 14:30, Kamil Rytarowski wrote:
> (3) Patch Clang to start optimizing on NULL + in C so we can return to
> points (1) and (2).
>
I have received a feedback that the particular NULL + 0 issue is
intended to be reported to the C committee as a defect.
I appreciate this app
On 24.03.2020 07:43, Taylor R Campbell wrote:
>> Date: Sun, 22 Mar 2020 03:30:56 +0100
>> From: Kamil Rytarowski
>>
>> On 22.03.2020 01:50, Taylor R Campbell wrote:
>>> So far, after several weeks of discussion, nobody has presented a case
>>> tha
On 22.03.2020 01:50, Taylor R Campbell wrote:
>> Date: Sun, 22 Mar 2020 00:03:57 +0100
>> From: Kamil Rytarowski
>>
>> I propose to change the fun(pointer + 0) logic with fun(pointer, 0).
>
> I don't think this is a good approach -- it requires modifying code
I propose to change the fun(pointer + 0) logic with fun(pointer, 0).
We still maintain the sanity checks and we can optimize the code to
generate not worse code than before. We can pass the "0" argument only
with DIAGNOSTIC or DEBUG kernel.
http://netbsd.org/~kamil/patch-00242-pslist-avoid-null-p
On 09.03.2020 07:05, Martin Husemann wrote:
> Also note that the getuid()/geteuid() example here is IMHO unrelated to the
> original issue that caused this discussion, so I am not even convinced this
> is NOT a ubsan bug.
We instruct a C compiler that pointer used in the pserialize macros is
never
On 08.03.2020 19:42, Mouse wrote:
>>> The correct fix is not to disable the null-pointer-check option but
>>> to remove the broken automatic non-null arguments in GCC.
>
>> The C standard and current usage (GNU) disagrees here.
>
> GNU is not some kind of arbiter of "current usage" (whatever _tha
On 08.03.2020 19:30, Taylor R Campbell wrote:
>> Date: Sun, 8 Mar 2020 20:52:29 +0300
>> From: Roman Lebedev
>>
>> so we are allowed to lower that in clang front-end as:
>>
>> int
>> statu(char *a)
>> {
>> __builtin_assume(a != NULL);
>> a += getuid() - geteuid();
>> __builtin_assume(a != NU
On 08.03.2020 18:12, Joerg Sonnenberger wrote:
> On Sun, Mar 08, 2020 at 03:33:57PM +0100, Kamil Rytarowski wrote:
>> There was also a request to make a proof that memcpy(NULL,NULL,0) is UB
>> and can be miscompiled.
>>
>> Here is a reproducer:
>>
>> http://
On 08.03.2020 18:11, Joerg Sonnenberger wrote:
> On Sun, Mar 08, 2020 at 03:30:02PM +0100, Kamil Rytarowski wrote:
>> NULL+x is now miscompiled by Clang/LLVM after this commit:
>>
>> https://reviews.llvm.org/rL369789
>>
>> This broke various programs like:
>&g
On 08.03.2020 18:00, Taylor R Campbell wrote:
> Thanks for doing the research.
>
>> Date: Sun, 8 Mar 2020 15:30:02 +0100
>> From: Kamil Rytarowski
>>
>> NULL+0 was added to UBSan proactively as it is as of today not
>> miscompiled, but it is planned t
On 08.03.2020 15:30, Kamil Rytarowski wrote:
> On 22.02.2020 17:25, Kamil Rytarowski wrote:
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>>
>> http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-n
On 22.02.2020 17:25, Kamil Rytarowski wrote:
> When running the ATF tests under MKLIBCSANITIZER [1], there are many
> NULL pointer arithmetic issues .
>
> http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt
>
> These issues
On 08.03.2020 03:55, メーリングリストNetBSD wrote:
> Hello,
>
> I'm interested in "support jails-like features" [1] among The NetBSD
> projects.
> I investigated several current container systems [2], but couldn't find
> one providing kernel-level virtualization.
> I would like to know the current state o
On 24.02.2020 23:35, Mouse wrote:
>> Unless I remember wrong, older C standards explicitly say that the
>> integer 0 can be converted to a pointer, and that will be the NULL
>> pointer, and a NULL pointer cast as an integer shall give the value
>> 0.
>
> The only one I have anything close to a cop
On 24.02.2020 21:18, Mouse wrote:
>>> If we use 0x0, it can be a valid pointer.
>
>>> If we use NULL, it's not expected to work and will eventually
>>> generate a syntax erro.
>
> Then someone has severely broken compatability with older versions of
> C. 0x0 and (when one of the suitable #includ
On 24.02.2020 15:35, Don Lee wrote:
>
>> On Feb 24, 2020, at 8:05 AM, Mouse wrote:
>>
> RUST is better defined that C and is indeed used in OS development
> these days
...so? I don't see how this is related to the rest of the
discussion.
>>> As C is considered as not suitable f
On 24.02.2020 15:04, Jason Thorpe wrote:
>
>> On Feb 24, 2020, at 4:22 AM, Kamil Rytarowski wrote:
>>
>> A compiler once being smart enough can introduce ILL/SEGV traps into
>> code that performs operations on NULL pointers. This already bitten us
>> when we were
On 24.02.2020 14:03, Mouse wrote:
It is now in C++ mainstream and already in C2x draft.
>>> Then those are not suitable languages for OS implementations.
>> This battle is lost for C
>
> C is not a language. C is a family of closely related languages.
>
If we tread C as gnu89 gnu99 gnu11 k
On 24.02.2020 13:41, Joerg Sonnenberger wrote:
> On Mon, Feb 24, 2020 at 11:42:01AM +0100, Kamil Rytarowski wrote:
>> Forbidding NULL pointer arithmetic is not just for C purists trolls. It
>> is now in C++ mainstream and already in C2x draft.
>
> This is not true. NULL p
On 24.02.2020 12:14, Mouse wrote:
>> Forbidding NULL pointer arithmetic is not just for C purists trolls.
>> It is now in C++ mainstream and already in C2x draft.
>
> Then those are not suitable languages for OS implementations.
>
> I'm with campbell and mrg on this one. It is not appropriate to
On 24.02.2020 05:03, Taylor R Campbell wrote:
>> Date: Sun, 23 Feb 2020 22:51:08 +0100
>> From: Kamil Rytarowski
>>
>> On 23.02.2020 20:08, Taylor R Campbell wrote:
>> Date: Sun, 23 Feb 2020 22:51:08 +0100
>> From: Kamil Rytarowski
>>
>> On 23.0
On 23.02.2020 20:08, Taylor R Campbell wrote:
>> Date: Sat, 22 Feb 2020 17:25:42 +0100
>> From: Kamil Rytarowski
>>
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>>
>> http://netbsd.org/~kamil
On 22.02.2020 19:39, Joerg Sonnenberger wrote:
> On Sat, Feb 22, 2020 at 05:25:42PM +0100, Kamil Rytarowski wrote:
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>
> Which flags are the sanitizers using? Because I
When running the ATF tests under MKLIBCSANITIZER [1], there are many
NULL pointer arithmetic issues .
http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt
These issues are in macros like:
- IN_ADDRHASH_READER_FOREACH()
- IN_ADDRLIST_WRITER_INSERT_TAIL()
- IFADDR_READE
On 08.02.2020 11:47, Maxime Villard wrote:
>
> Running ATF with kASan+LOCKDEBUG+fault with {N=32 scope=GLOBAL} already
> gives
> an instant crash:
>
> kernel diagnostic assertion "radix_tree_empty_tree_p(&pmap->pm_pvtree)"
> failed: file ".../sys/arch/x86/x86/pmap.c"
>
There is a number of
On 06.02.2020 20:51, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Thu Feb 6 19:51:59 UTC 2020
>
> Modified Files:
> src/bin/sh: main.c
>
> Log Message:
> If we are invoked with SIGCHLD ignored, we fail badly, as we assume
> that we can always wait(2) for our ch
I keep observing responsiveness issues on NetBSD-current. This happened
in last 2 months.
Whenever I start building something with -j${CORES}, I have significant
delays of responsiveness in other applications.
load averages: 2.69, 5.56, 6.22; up 0+01:32:42 12:12:34
71 processes:
On 20.01.2020 17:42, Emile `iMil' Heitor wrote:
>
> Hi Kamil, Emmanuel & all,
>
> On Tue, 24 Sep 2019, Kamil Rytarowski wrote:
>
>> On 24.09.2019 14:26, Emmanuel Dreyfus wrote:
>>> On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote:
>>
On 20.01.2020 04:53, Chen,Xizi wrote:
> Hi NetBSD Community,
>
Welcome@
> I am currently a first year Master's Degree student studying Computer
> Science at Northwest Missouri State University. I'm a professional C/C++
> developer with about 4 years of work experience as a storage systems
> engi
On 26.12.2019 15:11, Valery Ushakov wrote:
> On Thu, Dec 26, 2019 at 08:52:39 +0000, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Thu Dec 26 08:52:39 UTC 2019
>>
>> Modified Files:
>> sr
PT_LWPINFO is a legacy ptrace(2) operation that was originally intended
to retrieve the thread (LWP) information inside a traced process.
At the end of the day, this call has been designed to work as an
iterator over threads and retrieve the LWP id + event information. The
event information is rec
On 17.12.2019 15:44, Andrew Doran wrote:
Typically with a character device, the kmod can get unloaded while an ioctl
is being executed on it.
>
> That's solvable. Conceptually I think the main stumbling block is that
> there are two layers at play which need to reconciled: specfs and dev
On 17.12.2019 14:19, Maxime Villard wrote:
> Le 17/12/2019 à 12:34, Kamil Rytarowski a écrit :
>> On 17.12.2019 09:16, Maxime Villard wrote:
>>>> Module Name: htdocs
>>>> Committed By: christos
>>>> Date: Tue Dec 17 01:03:49 UTC 2019
&
On 17.12.2019 09:16, Maxime Villard wrote:
>> Module Name: htdocs
>> Committed By: christos
>> Date: Tue Dec 17 01:03:49 UTC 2019
>>
>> Modified Files:
>> htdocs/support/security: advisory.html index.html
>>
>> Log Message:
>> new advisory
>>
>>
>> To generate a diff of this
On 06.12.2019 06:17, Kamil Rytarowski wrote:
> I have implemented l_private accessor in ptrace(2).
>
> By default this uses l_private from the lwp struct.
>
> PT_SET_LWP_PRIVATE uses lwp_setprivate() directly and this call
> abstracts internally MI and MD code.
>
>
I have implemented l_private accessor in ptrace(2).
By default this uses l_private from the lwp struct.
PT_SET_LWP_PRIVATE uses lwp_setprivate() directly and this call
abstracts internally MI and MD code.
The PT_SET_LWP_PRIVATE operation uses by default l_private from the
struct lwp, however whe
On 04.12.2019 19:11, Jason Thorpe wrote:
>
>
>> On Dec 4, 2019, at 8:47 AM, Kamil Rytarowski wrote:
>>
>> Today it's missing.. do we need it in core files?
>
> Seems like you would absolutely need it in core files, otherwise the debugger
> won't kn
Today it's missing.. do we need it in core files?
On 04.12.2019 16:56, Andrew Cagney wrote:
> Where is it in a core file?
>
> On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote:
>>
>> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
>> o
On 04.12.2019 04:10, Kamil Rytarowski wrote:
> On 03.12.2019 17:55, Joerg Sonnenberger wrote:
>> On Tue, Dec 03, 2019 at 05:11:49PM +0100, Kamil Rytarowski wrote:
>>> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
>>> out of gpregs.
>>
&
On 03.12.2019 17:55, Joerg Sonnenberger wrote:
> On Tue, Dec 03, 2019 at 05:11:49PM +0100, Kamil Rytarowski wrote:
>> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
>> out of gpregs.
>
> That's an implementation detail and IMO something we sh
TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
out of gpregs.
In the amd64 case mcontext looks like this:
typedef struct {
__gregset_t __gregs;
__greg_t_mc_tlsbase;
__fpregset_t__fpregs;
} mcontext_t;
The same situation is for: i3
On 23.11.2019 17:29, Christos Zoulas wrote:
> In article ,
> Christos Zoulas wrote:
>> In article <468095c0-b973-7f23-1cfa-3dc19e3b8...@gmail.com>,
>> Rin Okuyama wrote:
>>> On 2019/11/22 10:56, Christos Zoulas wrote:
In article <679493cf-3e85-f56d-85e4-dfaf7958a...@gmail.com>,
Rin Oku
On 22.11.2019 02:42, Robert Elz wrote:
> Date:Fri, 22 Nov 2019 01:04:56 +0100
> From: Kamil Rytarowski
> Message-ID: <1a9d9b40-42fe-be08-d7b3-e6ecead5b...@gmx.com>
>
>
> | I think that picking C11 terminology is the way forward.
>
>
On 22.11.2019 00:53, Robert Elz wrote:
> Date:Thu, 21 Nov 2019 19:19:51 +0100
> From:Maxime Villard
> Message-ID:
>
> | So in the end which name do we use? Are people really unhappy with
> _racy()?
> | At least it has a general meaning, and does not imply atomic
On 21.11.2019 10:49, Rin Okuyama wrote:
> On 2019/11/20 20:12, Rin Okuyama wrote:
>> On 2019/11/19 22:59, Kamil Rytarowski wrote:
> ...
>>>
>>> We still miss compat32 support for PT_GETXMMREGS and PT_SETXMMREGS, at
>>> some point of time we shall a
On 20.11.2019 18:14, Michael van Elst wrote:
> n...@gmx.com (Kamil Rytarowski) writes:
>
>> =46rom a high level point of view, we want to reject early corrupted FS o=
>> n
>> a mount. Today we panic the kernel needlessly.
>
>
> Rejecting won't help much,
On 20.11.2019 16:11, Mouse wrote:
>> During the fuzzing of FFS filesystem, we had a couple of issues
>> caused by corrupted inode fields. [...]
>
>> To make sure that corrupted mount won't cause harm to the user, I
>> want to add function to validate root inode on mount step (after
>> superblock
On 18.11.2019 13:08, Rin Okuyama wrote:
> On 2019/11/18 20:15, Kamil Rytarowski wrote:
>> I was thinking about something along these lines:
>>
>> http://netbsd.org/~kamil/patch-00196-siginfo_netbsd32_compat_uint64.txt
>>
>> In future some compat of i386 coul
On 18.11.2019 11:40, Rin Okuyama wrote:
> On 2019/11/18 16:52, Kamil Rytarowski wrote:
>> On 18.11.2019 05:38, Rin Okuyama wrote:
>>> Thank you for your comment!
>>>
>>> On 2019/11/17 22:42, Kamil Rytarowski wrote:
>>>> Please check it also with p
On 18.11.2019 05:38, Rin Okuyama wrote:
> Thank you for your comment!
>
> On 2019/11/17 22:42, Kamil Rytarowski wrote:
>> Please check it also with picotrace/truss:
>>
>> http://pkgsrc.se/devel/picotrace
>
> netbsd32_signal.c needed to catch up with kern_sig.c
On 17.11.2019 04:34, Rin Okuyama wrote:
> Hi,
>
> In order to distangle circular dependency between
> v.s. ,
> I propose
>
> (1) Move NETBSD32_INT64_ALIGN from to
>
>
> (2) Move netbsd32_{,u}int64 from to
>
>
> See attached patch for example on amd64.
>
What do you think about duplicatin
On 16.11.2019 15:31, Mindaugas Rasiukevicius wrote:
> Maxime Villard wrote:
>> Alright so let's add the macros with volatile (my initial patch). Which
>> name do we use? I actually like __{read,write}_racy().
>
> I suggest __atomic_load_relaxed()/__atomic_store_relaxed(). If these
> are to be pr
On 08.11.2019 13:40, Mindaugas Rasiukevicius wrote:
>>> There is more code in the NetBSD kernel which needs fixing. I would say
>>> pretty much all lock-free code should be audited.
>> I believe KCSAN can greatly help with that, since it automatically reports
>> concurrent accesses. Up to us then
1 - 100 of 401 matches
Mail list logo
