Re: Too many PMC implementations

2018-08-25 Thread Kamil Rytarowski
On 26.08.2018 02:40, Kamil Rytarowski wrote: > On 25.08.2018 21:32, David Holland wrote: >> > 2. There is no bpf_validate for Lua bytecode. In fact, Lua team abandoned >> >an idea of bytecode validation few years ago. From Lua 5.3 manual: >> > >> >

Re: Too many PMC implementations

2018-08-25 Thread Kamil Rytarowski
On 25.08.2018 21:32, David Holland wrote: > > 2. There is no bpf_validate for Lua bytecode. In fact, Lua team abandoned > >an idea of bytecode validation few years ago. From Lua 5.3 manual: > > > >Lua does not check the consistency of binary chunks. Maliciously > >crafted binary

Re: Too many PMC implementations

2018-08-24 Thread Kamil Rytarowski
On 25.08.2018 00:28, Rhialto wrote: > On Thu 23 Aug 2018 at 18:48:32 +0200, Kamil Rytarowski wrote: >> Probably DTrace is not the final word in BSD and not something I intend >> to defend - but it's a good solution for now - (FreeBSD already >> ports/develops a potential repl

Re: Too many PMC implementations

2018-08-23 Thread Kamil Rytarowski
On 23.08.2018 18:35, Thor Lancelot Simon wrote: > On Thu, Aug 23, 2018 at 06:25:56PM +0200, Kamil Rytarowski wrote: >> >> As useful I mean the number of commits to the src/ tree. If nothing >> landed, probably nothing was useful. When were the most recent patches >

Re: Too many PMC implementations

2018-08-23 Thread Kamil Rytarowski
On 23.08.2018 17:57, Thor Lancelot Simon wrote: > On Thu, Aug 23, 2018 at 05:09:35PM +0200, Kamil Rytarowski wrote: >> >> Observing that all the useful profiling is already done with DTrace, we >> can remove complexity from the kernel with negligible cost. > >

Re: Too many PMC implementations

2018-08-23 Thread Kamil Rytarowski
On 23.08.2018 16:59, Anders Magnusson wrote: > Den 2018-08-23 kl. 16:48, skrev Kamil Rytarowski: >> On 23.08.2018 16:28, Anders Magnusson wrote: >>> Den 2018-08-23 kl. 15:53, skrev Maxime Villard: >>>> Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit : >>>

Re: Too many PMC implementations

2018-08-23 Thread Kamil Rytarowski
On 23.08.2018 16:28, Anders Magnusson wrote: > Den 2018-08-23 kl. 15:53, skrev Maxime Villard: >> Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit : >>> On 17.08.2018 17:13, Maxime Villard wrote: >>>> Note that I'm talking about the kernel gprof, and not the user

Re: Too many PMC implementations

2018-08-17 Thread Kamil Rytarowski
On 17.08.2018 17:13, Maxime Villard wrote: > Note that I'm talking about the kernel gprof, and not the userland gprof. > In terms of kernel profiling, it's not nonsensical to say that since we > support ARM and x86 in tprof, we can cover 99% of the MI parts of > whatever architecture. From then

Re: Removing dbregs

2018-07-26 Thread Kamil Rytarowski
On 26.07.2018 10:45, Maxime Villard wrote: > Le 26/07/2018 à 10:41, Kamil Rytarowski a écrit : >> On 26.07.2018 09:24, Maxime Villard wrote: >>> For the record, I ended up with a functional patch [1]. This removes the >>> reload of DR6/DR7 on each kernel->us

Re: Removing dbregs

2018-07-26 Thread Kamil Rytarowski
On 26.07.2018 09:24, Maxime Villard wrote: > For the record, I ended up with a functional patch [1]. This removes the > reload of DR6/DR7 on each kernel->user transition, and rather does it > during context switches, only when dbregs are being used. Tested ATF on > i386 and amd64, it works. > >

Re: Possible error in dtrace

2018-07-25 Thread Kamil Rytarowski
On 25.07.2018 16:01, Maxime Villard wrote: > Le 25/07/2018 à 15:54, Siddharth Muralee a écrit : >> Hello, >>    While going through sys/arch/amd64/pmap.h, I came across >> KERN_BASE[1] and confused it for KERNBASE[2]. Looking deeper into the >> same I think someone made the same mistake in

Re: hashtables

2018-07-24 Thread Kamil Rytarowski
On 24.07.2018 21:01, co...@sdf.org wrote: > hi netbsd, > > if I were to state I totally need hashtables, what already existing API > would you tell me to use instead? > > I am porting code: >

Re: Adding a boot flag for No ASLR

2018-07-24 Thread Kamil Rytarowski
On 24.07.2018 14:53, Joerg Sonnenberger wrote: > On Tue, Jul 24, 2018 at 06:44:52AM +0200, Martin Husemann wrote: >> On Mon, Jul 23, 2018 at 11:02:04PM +0200, Kamil Rytarowski wrote: >>> We need to maintain a function to translate certain ranges to >>> shadow/met

Re: Adding a boot flag for No ASLR

2018-07-24 Thread Kamil Rytarowski
On 24.07.2018 06:44, Martin Husemann wrote: > On Mon, Jul 23, 2018 at 11:02:04PM +0200, Kamil Rytarowski wrote: >> We need to maintain a function to translate certain ranges to >> shadow/meta/origin/etc. We cannot map arbitrarily wide ranges to them. > > Can we extend th

Re: Adding a boot flag for No ASLR

2018-07-23 Thread Kamil Rytarowski
On 23.07.2018 21:32, Joerg Sonnenberger wrote: > On Mon, Jul 23, 2018 at 07:13:49PM +0200, Kamil Rytarowski wrote: >> We need to have stack, heap and code of a program in predictable (and >> quite narrow) ranges and thus ASLR disabled or less aggressive. > > What for? Not

Re: Adding a boot flag for No ASLR

2018-07-23 Thread Kamil Rytarowski
On 23.07.2018 15:09, Joerg Sonnenberger wrote: > On Mon, Jul 23, 2018 at 06:24:09PM +0530, Siddharth Muralee wrote: >>> >>> >>> (1) An implementation detail of userland shouldn't be leaked into the >>> kernel boot (!) process. >>> >> >> Okay. I think this makes sense(I am still pretty new to

Re: Adding a boot flag for No ASLR

2018-07-23 Thread Kamil Rytarowski
On 23.07.2018 14:54, Siddharth Muralee wrote: > > (1) An implementation detail of userland shouldn't be leaked into the > kernel boot (!) process. > > > Okay. I think this makes sense(I am still pretty new to NetBSD) - Can > you suggest some other location/config that can be used. >

Re: Adding a boot flag for No ASLR

2018-07-23 Thread Kamil Rytarowski
On 23.07.2018 14:48, Martin Husemann wrote: > On Mon, Jul 23, 2018 at 06:11:49PM +0530, Siddharth Muralee wrote: >> Hello, >>I have recently been working on adding a new boot flag for disabling >> ASLR during boot. I feel that this is useful since MKSANITZER userland >> (specifically Address

Re: aarch64 gcc kernel compilation

2018-07-17 Thread Kamil Rytarowski
On 17.07.2018 07:23, Ryo Shimizu wrote: > > Can we drop it? The __uint128_t type is not used anywhere else in > aarch64 subdirs. > > fortunately, we don't use member of fpreg, use just only as container. > Is this patch enough? > I was thinking about this one:

Re: aarch64 gcc kernel compilation

2018-07-16 Thread Kamil Rytarowski
On 16.07.2018 11:07, Kamil Rytarowski wrote: > On 16.07.2018 10:50, Kamil Rytarowski wrote: >> On 16.07.2018 00:00, Kamil Rytarowski wrote: >>> On 15.07.2018 20:08, Christos Zoulas wrote: >>>> Hi, >>>> >>>> Gcc is now working on aarch6

Re: aarch64 gcc kernel compilation

2018-07-16 Thread Kamil Rytarowski
On 16.07.2018 10:50, Kamil Rytarowski wrote: > On 16.07.2018 00:00, Kamil Rytarowski wrote: >> On 15.07.2018 20:08, Christos Zoulas wrote: >>> Hi, >>> >>> Gcc is now working on aarch64 but the kernel does not compile because of >>> some idiomatic clan

Re: aarch64 gcc kernel compilation

2018-07-16 Thread Kamil Rytarowski
On 16.07.2018 00:00, Kamil Rytarowski wrote: > On 15.07.2018 20:08, Christos Zoulas wrote: >> Hi, >> >> Gcc is now working on aarch64 but the kernel does not compile because of >> some idiomatic clang code that is not supported by gcc (at least gcc-6) >>

Re: aarch64 gcc kernel compilation

2018-07-15 Thread Kamil Rytarowski
On 15.07.2018 20:08, Christos Zoulas wrote: > Hi, > > Gcc is now working on aarch64 but the kernel does not compile because of > some idiomatic clang code that is not supported by gcc (at least gcc-6) > > To define constants, it uses: > > static const uintmax_t > FOO = __BIT(9), > BAR = FOO; >

Re: Removing dbregs

2018-07-14 Thread Kamil Rytarowski
On 14.07.2018 17:55, Maxime Villard wrote: > Le 14/07/2018 à 17:40, Kamil Rytarowski a écrit : >> On 14.07.2018 12:52, Maxime Villard wrote: >>> Le 14/07/2018 à 10:29, Martin Husemann a écrit : >>>> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: &

Re: Removing dbregs

2018-07-14 Thread Kamil Rytarowski
On 14.07.2018 12:52, Maxime Villard wrote: > Le 14/07/2018 à 10:29, Martin Husemann a écrit : >> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: >>> #ifdefing it out in a non-benchmarking application (I was checking ones >>> that do something with s

Re: Removing dbregs

2018-07-14 Thread Kamil Rytarowski
On 14.07.2018 12:52, Maxime Villard wrote: > Le 14/07/2018 à 10:29, Martin Husemann a écrit : >> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: >>> #ifdefing it out in a non-benchmarking application (I was checking ones >>> that do something with s

Re: Removing dbregs

2018-07-13 Thread Kamil Rytarowski
On 13.07.2018 23:32, Jason Thorpe wrote: > > >> On Jul 13, 2018, at 2:22 PM, Kamil Rytarowski wrote: >> >> On 13.07.2018 23:10, Jaromír Doleček wrote: >>> 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >>>> I disagree with disabling it. The code is

Re: Removing dbregs

2018-07-13 Thread Kamil Rytarowski
On 13.07.2018 23:10, Jaromír Doleček wrote: > 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >> I disagree with disabling it. The code is not broken, it's covered by >> tests, it's in use. > > This looks like perfect candidate for optional (default off) feature. > It

Re: Removing dbregs

2018-07-13 Thread Kamil Rytarowski
On 13.07.2018 22:44, Maxime Villard wrote: > Le 13/07/2018 à 21:54, Kamil Rytarowski a écrit : >> On 13.07.2018 21:31, Maxime Villard wrote: >>> I don't like the dbregs code. We unconditionally write into %dr6 and >>> %dr7 in >>> userret, that is, during each i

Re: Removing dbregs

2018-07-13 Thread Kamil Rytarowski
On 13.07.2018 21:31, Maxime Villard wrote: > I don't like the dbregs code. We unconditionally write into %dr6 and > %dr7 in > userret, that is, during each interruptible kernel->user transition. > > Some measurements with PMCs show that the loads of dr6/dr7 are one of the > first sources of

Re: Too many PMC implementations

2018-07-12 Thread Kamil Rytarowski
On 12.07.2018 08:48, Maxime Villard wrote: > Le 11/07/2018 à 19:49, Kamil Rytarowski a écrit : >> I'm not familiar with the internals myself, but from API point of view, >> something usable for porting rr (https://github.com/mozilla/rr) or even >> Linux perf-top is high

Re: Too many PMC implementations

2018-07-11 Thread Kamil Rytarowski
On 11.07.2018 18:22, Maxime Villard wrote: > Right now we have three (or more?) different implementations for > Performance > Monitoring Counters: > >  * PMC: this one is MI. It is used only on one ARM model (xscale I think). >    There used to be an x86 code for it, but it was broken, and I

Re: 8.0 performance issue when running build.sh?

2018-07-11 Thread Kamil Rytarowski
On 11.07.2018 11:47, Takeshi Nakayama wrote: Martin Husemann wrote > >>> Another observation is that grep(1) on one NetBSD server is >>> significantly slower between the switch from -7 to 8RC1. >> >> Please file separate PRs for each (and maybe provide some input files >> to reproduce the

Re: 8.0 performance issue when running build.sh?

2018-07-11 Thread Kamil Rytarowski
On 11.07.2018 09:09, Simon Burge wrote: > Hi folks, > > Martin Husemann wrote: > >> On Tue, Jul 10, 2018 at 12:11:41PM +0200, Kamil Rytarowski wrote: >>> After the switch from NetBSD-HEAD (version from 1 year ago) to 8.0RC2, >>> the ld(1) linker has serious i

Re: 8.0 performance issue when running build.sh?

2018-07-10 Thread Kamil Rytarowski
On 10.07.2018 11:01, Martin Husemann wrote: > On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote: >> I have no scientific data yet, but just noticed that build times on the >> auto build cluster did rise very dramatically since it has been updated >> to run NetBSD 8.0 RC2. >> >> Since

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

2018-07-10 Thread Kamil Rytarowski
On 08.07.2018 17:44, Kamil Rytarowski wrote: > I will try to scratch a new header unaligned.h with the set of macros > and submit it to evaluation. I've prepared a scratch of unaligned.h with get_unaligned(): http://netbsd.org/~kamil/kubsan/unaligned.h There are at least two problems to p

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

2018-07-09 Thread Kamil Rytarowski
On 09.07.2018 16:58, Thor Lancelot Simon wrote: > On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >>

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

2018-07-09 Thread Kamil Rytarowski
On 09.07.2018 11:32, Martin Husemann wrote: > On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote: >> According to my understanding, alignment requirement for a type/object >> is implementation defined (6.2.8); however during the process of >> converting types, if

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

2018-07-09 Thread Kamil Rytarowski
On 09.07.2018 10:09, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote: >> Misaligned pointer is explicitly documented as undefined behavior in the >> C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.) > > Yes, but the st

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

2018-07-08 Thread Kamil Rytarowski
On 08.07.2018 17:30, Mouse wrote: > Caveat: this is all opinion. I'm not the one doing the work here. > > src/sys/arch/x86/x86: mpbios.c > > Remove unaligned access to mpbios_page[] > > sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address > 0x800031c7a413

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

2018-07-08 Thread Kamil Rytarowski
On 08.07.2018 17:16, Jason Thorpe wrote: > > >> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: >> >> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least >> for the use of acpica (which still contains a fallback for Itanium >> without

Re: CVS commit: src/sys/arch

2018-07-08 Thread Kamil Rytarowski
On 08.07.2018 12:01, Martin Husemann wrote: > On Sat, Jul 07, 2018 at 09:35:16PM +0000, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Sat Jul 7 21:35:16 UTC 2018 >> >> Modified Files: >> src/sys/ar

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

2018-07-08 Thread Kamil Rytarowski
On 08.07.2018 15:53, Jaromír Doleček wrote: > Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit : >> I've introduced the change to mpbios.c as it was small, selfcontained >> and without the need to decorate the whole function. > > Am I reading the code wrong or you ac

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

2018-07-08 Thread Kamil Rytarowski
On 08.07.2018 11:24, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >>> Module Name:src >>> Committed By: kamil >>> Date: Sat Jul 7 23:05:50 UTC 2018 >>> >>> Modified Files: >>> src/sys/arch/x86/x86: mpbios.c >>> >>> Log Message:

Re: Apply for 'userland PCIe driver'

2018-06-14 Thread Kamil Rytarowski
On 13.06.2018 20:20, Timbo Tim wrote: > Hi. I'd like to  work on userland PCIe driver for my thesis starting > around the beginning of next year if my proposal get accepted (not > related to GSoC). Can I apply on this one? What's your familiarity with PCI specification? Are you familiar with

Re: New getsockopt2() syscall

2018-06-09 Thread Kamil Rytarowski
On 09.06.2018 16:05, Martin Husemann wrote: > On Sat, Jun 09, 2018 at 10:22:06AM +0200, Kamil Rytarowski wrote: >> Can we reuse unused old syscall numbers? > > Reuse in general not (that would break any possible compat for that). > But there are some unused numbers li

Re: New getsockopt2() syscall

2018-06-09 Thread Kamil Rytarowski
On 08.06.2018 23:18, Robert Swindells wrote: > > Are there any objections to the code for a getsockopt2() syscall > in: > > > Can we reuse unused old syscall numbers? signature.asc Description: OpenPGP digital signature

Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled

2018-05-30 Thread Kamil Rytarowski
On 30.05.2018 12:51, Harry Pantazis wrote: > Greetings, > > I'm working on the task of utilizing Undefined Behavior checks for the > NetBSD/amd64 kernel (KUBSan). I have built the GENERIC kernel with the > -fsanitize=undefined option enabled and I've caught a first series of > errors caused

Re: QEMU/NetBSD status wiki page

2018-05-27 Thread Kamil Rytarowski
On 27.05.2018 20:04, Warner Losh wrote: > > > On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > On 27.05.2018 16:53, Warner Losh wrote: > > > > > > On Sun, May 27, 2018 at 4:05

Re: QEMU/NetBSD status wiki page

2018-05-27 Thread Kamil Rytarowski
On 27.05.2018 16:53, Warner Losh wrote: > > > On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > As requested, I've prepared a QEMU/NetBSD status page: > > http://wiki.netbsd.org/users/kamil/qemu/

QEMU/NetBSD status wiki page

2018-05-27 Thread Kamil Rytarowski
As requested, I've prepared a QEMU/NetBSD status page: http://wiki.netbsd.org/users/kamil/qemu/ I've attempted to be rather conservative with claims that something works, without detailed verification. signature.asc Description: OpenPGP digital signature

Re: e_trapsignal removal

2018-04-27 Thread Kamil Rytarowski
On 27.04.2018 21:11, Christos Zoulas wrote: > In article <b80b33fb-de4f-01dd-1705-716a2c0ec...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> I propose to remove e_trapsignal from the compat framework >> >&

e_trapsignal removal

2018-04-27 Thread Kamil Rytarowski
I propose to remove e_trapsignal from the compat framework Rationale: - It's currently unused. It was used for Darwin compat. - It's certainly broken and not used in part of the code where it could be used, generating a trap signal. - Maintaining debugging features in the compat framework is

Re: Potential new syscall

2018-04-03 Thread Kamil Rytarowski
On 03.04.2018 16:57, Mouse wrote: >> =46rom the GDB protocol point of view, > ...what does gdb have to do with it? Did I miss something? > We need to track forks and its variations. Just a note that from the existing protocol point of view, we can handle this new syscall. signature.asc

Re: Potential new syscall

2018-04-03 Thread Kamil Rytarowski
On 03.04.2018 04:08, Robert Elz wrote: > Kamil - "just use fork" is a very common response, but no matter how > fork gets implemented, vfork() when used correctly always performs > better by huge margins. You are of course correct that there is a very > limited set of functions possible in a

Re: Potential new syscall

2018-04-02 Thread Kamil Rytarowski
On 03.04.2018 01:29, Mouse wrote: > > Thoughts? (Not restricted to just the above details; thoughts on the > general idea would also be interesting to me.) > It might not be a satisfying answer... but go for fork(). I recommend this option - no kernel changes involved... unless someone wants

Debug Register (x86) trap - race

2018-03-25 Thread Kamil Rytarowski
I've been investigating the race in ptrace(2) ATF tests: dbregs_* for x86 (i386 and amd64). Examples: NetBSD/amd64 http://releng.netbsd.org/b5reports/amd64/2018/2018.03.06.11.21.31/test.html#lib_libc_sys_t_ptrace_wait6_dbregs_dr3_trap_variable_readwrite_write_2bytes NetBSD/i386

Re: Port FreeBSD's updated Atheros WiFi Driver

2018-03-19 Thread Kamil Rytarowski
On 19.03.2018 15:20, Aditya Upadhyay wrote: > On Sun, Mar 18, 2018 at 8:36 PM, Kamil Rytarowski <n...@gmx.com> wrote: >> On 18.03.2018 15:11, Aditya Upadhyay wrote: >>> Hi Kamil Rytarowski, >>> >>> Thanks for pointing out the easier one for

Re: Port FreeBSD's updated Atheros WiFi driver

2018-03-19 Thread Kamil Rytarowski
On 19.03.2018 06:26, Harsh Khatore wrote: > Hi team,  > Welcome! > I know it is late to start with, but can you guide me on the above > mentioned project. I want to apply for GSoC with this project.  > > Also, do you have anyone else working on it, if so, please do let me > know, else it will

Re: Port FreeBSD's updated Atheros WiFi Driver

2018-03-18 Thread Kamil Rytarowski
On 18.03.2018 15:11, Aditya Upadhyay wrote: > Hi Kamil Rytarowski, > > Thanks for pointing out the easier one for me. I really appreciate > your response. > > > On Sun, Mar 18, 2018 at 7:06 PM, Kamil Rytarowski <n...@gmx.com> wrote: >> On 18.03.2018 08:55, A

Re: Port FreeBSD's updated Atheros WiFi Driver

2018-03-18 Thread Kamil Rytarowski
On 18.03.2018 08:55, Aditya Upadhyay wrote: > Hi tech-kern, > > > This is Aditya Upadhyay. I was a GSoC student last year at RTEMS > Organization. My Project was POSIX Compliance. This year, I am mentoring > for RTEMS itself. > > I am interested in this project and want to work, not as GSoC

Re: Regarding GSoC

2018-03-15 Thread Kamil Rytarowski
On 15.03.2018 17:53, Siddharth Muralee wrote: > Hey, Welcome! >    I am a second-year undergraduate student at Amrita University, > Amritapuri, India. I would like to take up one of the ideas suggested in > your wiki namely, "Kernel Address SANitizer". I am a security enthusiast > and I am

Re: sysctl_doeproc() race

2018-03-14 Thread Kamil Rytarowski
On 13.03.2018 13:26, Robert Elz wrote: > Sure - I was not suggesting that anything shouild be done to this code to > make it run faster - I had seen that "could just use ..." comment ages ago, > and (as I assume its original author did, even more ages previously) that > it just wasn't worth the

Re: sysctl_doeproc() race

2018-03-13 Thread Kamil Rytarowski
On 13.03.2018 09:17, Robert Elz wrote: > Not a surprise there either - where it might make a difference is when > the number of processes is more in the thousands. I'm not sure how > 20-30 processes counts as a "regular running system" though, my > laptop has > 130 processes at the minute, and

Re: sysctl_doeproc() race

2018-03-12 Thread Kamil Rytarowski
On 11.03.2018 19:20, Kamil Rytarowski wrote: > On 11.03.2018 18:23, Robert Elz wrote: >> Date:Sun, 11 Mar 2018 16:02:57 +0100 >> From:Kamil Rytarowski <n...@gmx.com> >> Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> >

Re: sysctl_doeproc() race

2018-03-11 Thread Kamil Rytarowski
On 11.03.2018 18:23, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | We already use markers so I prefer to stick to this

Re: sysctl_doeproc() race

2018-03-11 Thread Kamil Rytarowski
On 11.03.2018 17:25, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | POSIX people told me that polling of a proc

Re: sysctl_doeproc() race

2018-03-11 Thread Kamil Rytarowski
On 11.03.2018 13:00, Robert Elz wrote: > Date:Sun, 11 Mar 2018 11:06:33 +0100 > From:Martin Husemann > Message-ID: <20180311100633.ge23...@mail.duskware.de> > > | I don't get this part - how would we end up with the new process using > | the

Re: sysctl_doeproc() race

2018-03-11 Thread Kamil Rytarowski
On 11.03.2018 13:12, Martin Husemann wrote: > On Sun, Mar 11, 2018 at 07:00:46PM +0700, Robert Elz wrote: >> That process can exit, its zombie be cleaned up, and then a new process >> created which happens to have the same pid as the previous one had > > Theoretically, but for all practical cases

Re: sysctl_doeproc() race

2018-03-10 Thread Kamil Rytarowski
On 10.03.2018 23:49, Robert Elz wrote: > Date:Sat, 10 Mar 2018 21:47:31 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <6cbea372-5520-8d76-72ac-68409f5a3...@gmx.com> > > | This does not fix the race, > > Some r

Re: sysctl_doeproc() race

2018-03-10 Thread Kamil Rytarowski
On 10.03.2018 21:47, Kamil Rytarowski wrote: > On 10.03.2018 20:45, Christos Zoulas wrote: >> In article <ef31ecad-c6ba-bc06-aace-2b7a2ff33...@gmail.com>, >> Kamil Rytarowski <krytarow...@gmail.com> wrote: >>> I've been observing a race with the ptrace(2) AT

Re: sysctl_doeproc() race

2018-03-10 Thread Kamil Rytarowski
On 10.03.2018 20:45, Christos Zoulas wrote: > In article <ef31ecad-c6ba-bc06-aace-2b7a2ff33...@gmail.com>, > Kamil Rytarowski <krytarow...@gmail.com> wrote: >> I've been observing a race with the ptrace(2) ATF tests. >> >> There is a function await_zombie() t

sysctl_doeproc() race

2018-03-09 Thread Kamil Rytarowski
I've been observing a race with the ptrace(2) ATF tests. There is a function await_zombie() that checks whether a process (traced by a debugger) died and is now a zombie. The current code might return a single process twice, from the allproc list and later from zombproc. I detect that in both

Re: will-it-scale

2018-03-02 Thread Kamil Rytarowski
On 03.03.2018 03:54, Kamil Rytarowski wrote: > With an inspiration from M.J. Guzik, I've ported will-it-scale to > NetBSD. It's available through pkgsrc-wip as wip/will-it-scale-git. > > I'm pasting here results that might be a starting point and inspiration. > A testing machin

will-it-scale

2018-03-02 Thread Kamil Rytarowski
With an inspiration from M.J. Guzik, I've ported will-it-scale to NetBSD. It's available through pkgsrc-wip as wip/will-it-scale-git. I'm pasting here results that might be a starting point and inspiration. A testing machine with a larger number of cores (16+) would be useful for serious scaling

Re: Bunch of bugs reported by Ilja van Sprundel

2018-01-30 Thread Kamil Rytarowski
On 30.01.2018 13:24, Kamil Rytarowski wrote: > On 30.01.2018 13:20, Martin Husemann wrote: >> On Tue, Jan 30, 2018 at 11:17:01AM +, m...@netbsd.org wrote: >>> So, >>> >>> - Didn't communicate that there's a breaking change in 7.1.1 to people >>>

Re: Bunch of bugs reported by Ilja van Sprundel

2018-01-30 Thread Kamil Rytarowski
On 30.01.2018 13:20, Martin Husemann wrote: > On Tue, Jan 30, 2018 at 11:17:01AM +, m...@netbsd.org wrote: >> So, >> >> - Didn't communicate that there's a breaking change in 7.1.1 to people >> building packages > > This is tech-kern and for those pkgsrc agnostic: what "breaking > change in

Re: Bunch of bugs reported by Ilja van Sprundel

2018-01-29 Thread Kamil Rytarowski
On 29.01.2018 22:27, Joerg Sonnenberger wrote: > On Mon, Jan 29, 2018 at 10:16:05PM +0100, Kamil Rytarowski wrote: >> On 29.01.2018 22:01, Joerg Sonnenberger wrote: >>> On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: >>>> Another point is to set a r

Re: Bunch of bugs reported by Ilja van Sprundel

2018-01-29 Thread Kamil Rytarowski
On 29.01.2018 22:01, Joerg Sonnenberger wrote: > On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: >> Another point is to set a rule that ABI is stable between patch versions >> and binary packages (prebuilt software) still works as-is. I'm observing >>

Re: Bunch of bugs reported by Ilja van Sprundel

2018-01-29 Thread Kamil Rytarowski
On 29.01.2018 20:01, m...@netbsd.org wrote: > I think we should have a discussion to change the way netbsd releases > and security advisories are done. they seem to be suitable for a large > company, and netbsd is doesn't keep up with it. > Personally, I would find it reasonable to abandon minor

Re: amd64: svs

2018-01-07 Thread Kamil Rytarowski
On 07.01.2018 18:13, m...@netbsd.org wrote: > It will be good to document somewhere why SVS exists. it's obvious now, > but it might not be in a decade. > > Thanks for working on this! > I expect that we are now required to pullup it to stable branches. Thanks for the fixes! signature.asc

Re: meltdown

2018-01-04 Thread Kamil Rytarowski
On 04.01.2018 21:49, m...@netbsd.org wrote: > Also, I understand that to exploit this, one has to attempt to access > kernel memory a lot, and SEGV at least once per bit. > > I wonder if we can count the number of SEGVs and if we get a few, turn > on the workaround? that would at least spare us

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 25.12.2017 17:18, Valery Ushakov wrote: > On Mon, Dec 25, 2017 at 16:37:43 +0100, Kamil Rytarowski wrote: > >> On 24.12.2017 22:25, Kamil Rytarowski wrote: >> >>> http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt >> >> I've extrac

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 25.12.2017 17:43, Christos Zoulas wrote: > On Dec 25, 4:42pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: Re: Proposal to obsolete SYS_pipe > > | I've extracted two changes from the original mail: > | > | https://mail-index.netbsd.org/tech-kern/2017/12/25/msg02

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 25.12.2017 16:37, Kamil Rytarowski wrote: > On 24.12.2017 22:25, Kamil Rytarowski wrote: >> I propose to deprecate SYS_pipe. >> >> It is a special syscall that returns two integers from one function >> call. Fanciness is not compatible with regular C syntax and it

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 25.12.2017 16:25, Christos Zoulas wrote: > In article <e9f31472-83c5-d3d1-66c1-110a635a4...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> On 25.12.2017 03:42, John Nemeth wrote: >>> On Dec 24, 9:37pm,

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 24.12.2017 22:25, Kamil Rytarowski wrote: > I propose to deprecate SYS_pipe. > > It is a special syscall that returns two integers from one function > call. Fanciness is not compatible with regular C syntax and it demands > per-cpu assembly wrappers and rump-kernel workarounds.

Re: Proposal to obsolete SYS_pipe

2017-12-25 Thread Kamil Rytarowski
On 25.12.2017 03:42, John Nemeth wrote: > On Dec 24, 9:37pm, Mouse wrote: > } > } > http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt > } > } I see no pipe2(2), nor change from pipe(2) to pipe(3) (with an xref to > } pipe2(2)), both of which, it seems to me, should be part of this. > >

Proposal to obsolete SYS_pipe

2017-12-24 Thread Kamil Rytarowski
I propose to deprecate SYS_pipe. It is a special syscall that returns two integers from one function call. Fanciness is not compatible with regular C syntax and it demands per-cpu assembly wrappers and rump-kernel workarounds. It's not easily usable with syscall(2). OpenBSD and FreeBSD already

Re: Removing an entry from struct emul

2017-12-21 Thread Kamil Rytarowski
On 21.12.2017 10:43, Martin Husemann wrote: > On Thu, Dec 21, 2017 at 07:16:09AM +, co...@sdf.org wrote: >> Hi, >> >> COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. >> But it's been removed. can I remove e_fault from the struct, or would >> this break compat too hard?

sstk(2) removal proposal

2017-12-15 Thread Kamil Rytarowski
I propose to remove the sstk syscall. It has been added in day0 by with the initial NetBSD commit and never implemented. It has been purged from OpenBSD and is still around in FreeBSD as never implemented and commented for removal (in capabilities). It used to mean "change stack section size",

Re: [Call for Testing] Syzkaller (kernel fuzzing)

2017-10-27 Thread Kamil Rytarowski
Please don't burden upstream for every single issue (for now assume literal meaning: "for any issue"). This worked for a while, as Dmitry had spare time for syzkaller for !Linux, but this time is over. You have asked others for tests, so take the responsibility now to answer feedback reports. I'm

Re: Removal of 'wd* at umass?' driver?

2017-10-09 Thread Kamil Rytarowski
On 08.10.2017 21:12, Jaromír Doleček wrote: > Opinions? Can we just disable the driver now and reevaluate after 9.0? signature.asc Description: OpenPGP digital signature

Re: amd64: kernel aslr support

2017-10-05 Thread Kamil Rytarowski
On 05.10.2017 12:56, Maxime Villard wrote: > > The advantage of having a separate prekern is that you can update the > kernel > without touching the prekern, or the other way around. Is live-kernel update more viable with this approach? signature.asc Description: OpenPGP digital signature

Re: amd64: kernel aslr support

2017-10-05 Thread Kamil Rytarowski
On 04.10.2017 21:00, Maxime Villard wrote: > Here is a Kernel ASLR implementation for NetBSD-amd64. It is light, > functional, > user-friendly, and does not break any feature of the system. > Instructions on > how to install and use it can be found here [1]. I'm looking forward to see it aboard

Re: how to tell if a process is 64-bit

2017-09-10 Thread Kamil Rytarowski
On 10.09.2017 16:31, Thor Lancelot Simon wrote: > On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: >>> In a cross-platform process utility tool the question came up how to >>> decide if a process is 64-bit. >> >> First, I have to ask: what does it mean to say that a particular >> process is

Re: fork1 use-after-free of the child process

2017-09-08 Thread Kamil Rytarowski
On 08.09.2017 04:32, Mateusz Guzik wrote: > The fork1 routine can wait for the child to exit (if vforked) and/or > return the pointer to the child. > > Neither case guarantees the safety of said operation. The key is that > the parent can be ignoring SIGCHLD, which results in autoreaping the >

Re: /proc/#/ctl removal

2017-08-27 Thread Kamil Rytarowski
On 27.08.2017 16:07, Johnny Billquist wrote: > On 2017-08-27 14:09, D'Arcy Cain wrote: >> On 08/27/2017 03:59 AM, Christos Zoulas wrote: >>> LGTM, perhaps leave a comment /* old P_FSTRACE0x0001 */ >>> instead of completely removing the constants for now as a reminder. >> >> Isn't that sort

Re: /proc/#/ctl removal

2017-08-27 Thread Kamil Rytarowski
On 27.08.2017 09:59, Christos Zoulas wrote: > On Aug 26, 4:04pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: Re: /proc/#/ctl removal > > | I will do it. > | > | Draft patch: http://netbsd.org/~kamil/patch-00036-procfs_ctl.txt > | > | I plan to commit it on Mo

Re: /proc/#/ctl removal

2017-08-26 Thread Kamil Rytarowski
On 21.08.2017 12:13, Christos Zoulas wrote: > In article <da98e240-5dfb-4c49-ebb0-55c43d7b5...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> I plan to remove the filesystem process tracing capability through >&

  1   2   >