On 06.11.2019 16:58, David Young wrote:
> I *think* the intention is for __read_once()/__write_once() to
> load/store the entire variable from/to memory precisely once. They
> provide no guarantees about atomicity of the load/store. Should
> something be said about ordering and visibility of
On 06.11.2019 16:44, Kamil Rytarowski wrote:
> On 06.11.2019 15:57, Jason Thorpe wrote:
>>
>>
>>> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>>>
>>> On 06.11.2019 14:37, Jason Thorpe wrote:
>>>>
>>>>
>>>&g
On 06.11.2019 15:57, Jason Thorpe wrote:
>
>
>> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>>
>> On 06.11.2019 14:37, Jason Thorpe wrote:
>>>
>>>
>>>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>>>>
>
On 06.11.2019 14:37, Jason Thorpe wrote:
>
>
>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>>
>> I propose __write_relaxed() / __read_relaxed().
>
> ...except that seems to imply the opposite of what these do.
>
> -- thorpej
>
Ratio
On 06.11.2019 12:51, Maxime Villard wrote:
> Le 06/11/2019 à 12:38, Martin Husemann a écrit :
>> On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
>>> __read_once(x)
>>> __write_once(x, val)
>>
>> The names are really not helpfull for understanding what is supposed
>> to
On 28.09.2019 09:55, Thomas Mueller wrote:
> from Kamil Rytarowski and my previous post:
>
>>>> I have managed to get light cross-toolchain producing Linux binaries.
>
>>>> The only dependency is musl (+gmake to build it).
>
>>> Is it necessary
On 28.09.2019 09:01, Martin Husemann wrote:
> On Fri, Sep 27, 2019 at 08:50:55PM +0200, Rhialto wrote:
>> I have been pondering it for a while and it seems more complicated than
>> I first thought... it seems that the actual value of delta isn't even
>> important, but what rnd_delta_estimate()
On 27.09.2019 20:50, Rhialto wrote:
> On Fri 27 Sep 2019 at 15:53:47 +0200, Kamil Rytarowski wrote:
>> On 27.09.2019 10:19, Rhialto wrote:
>>> On Thu 26 Sep 2019 at 01:15:23 +0200, Kamil Rytarowski wrote:
>>>> Is this patch correct?
>>>>
>>>>
On 27.09.2019 10:19, Rhialto wrote:
> On Thu 26 Sep 2019 at 01:15:23 +0200, Kamil Rytarowski wrote:
>> Is this patch correct?
>>
>> http://netbsd.org/~kamil/patch-00168-kern_rndq.c-avoid-overflow.txt
>>
>> This code will map the corner case into defined seman
On 26.09.2019 19:13, Maxime Villard wrote:
> I think you are confused.
>
> Fuzzing does not act as a perfusion to keep something artificially alive.
>
> Part of the compat_linux bugs and vulns I fixed recently were found with a
> simple fuzzing VM I set up. Yet, does it really change anything?
On 26.09.2019 19:01, Maxime Villard wrote:
> Le 26/09/2019 à 18:56, Kamil Rytarowski a écrit :
>> Statement that Linux-compat is not much used is false at least due to
>> adobe-flash-plugin-11.2.202.644nb1.
>>
>> I find this package as a must have for a web browser.
>
On 26.09.2019 18:45, Maxime Villard wrote:
> Le 26/09/2019 à 18:15, Manuel Bouyer a écrit :
>> On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote:
>>> Le 26/09/2019 à 17:25, Brian Buhrow a écrit :
[...]
One implication of your proposal is that you'll disable the
On 26.09.2019 15:55, Kamil Rytarowski wrote:
> On 26.09.2019 15:06, Mouse wrote:
>>> [...] compat_linux and compat_linux32 [...]
>>
>>> Keeping them enabled for the <1% users interested means keeping
>>> vulnerabilities for the >99% who don't use these fe
On 26.09.2019 15:06, Mouse wrote:
>> [...] compat_linux and compat_linux32 [...]
>
>> Keeping them enabled for the <1% users interested means keeping
>> vulnerabilities for the >99% who don't use these features.
>
> Are the usage numbers really that extreme? Where'd you get them? I
> didn't
Is this patch correct?
http://netbsd.org/~kamil/patch-00168-kern_rndq.c-avoid-overflow.txt
This code will map the corner case into defined semantics, treating
delta INT32_MIN as INT32_MIN+1.
This panic was already triggered 7 times on syzbot.
On 23.09.2019 10:56, 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:
>> My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with
>> multiboot2 patches merged) it still did not work.
>
> I did not commi
On 24.09.2019 13:28, Emmanuel Dreyfus wrote:
> Hello
>
> I recently added features to x86 bootstraps (GPT and RAIDframe support,
> multiboot 2), which caused the files to grow. That causes troubles:
>
> - I had to disable multiboot 2 for dosboot, otherwise the binary gets too
> big and the
Truncating and resending to tech-kern@ as this message was dropped, as
too long.
On 23.09.2019 10:19, Kamil Rytarowski wrote:
> kern_rndq.c has a special corner case triggered by the fuzzer (1 hit in
> 2**32 attempts?).
>
> 393 /*
> 394 * Delta estimator for 32 or bit
On 15.09.2019 20:03, Christos Zoulas wrote:
> I think it is quite reliable because all the file descriptors would be
> recently
> opened and therefore be in the cache. One would need to DoS the cache
> cause eviction. If that turns out to be false, we can make the namecache
> reliable, or
On 14.09.2019 23:34, Christos Zoulas wrote:
> Comments?
>
Question. How does it handle symbolic/hardlinks?
> christos
>
>
> Index: kern/sys_descrip.c
> ===
> RCS file: /cvsroot/src/sys/kern/sys_descrip.c,v
> retrieving revision
On 10.09.2019 18:21, David Holland wrote:
> On Tue, Sep 10, 2019 at 06:11:55PM +0200, Kamil Rytarowski wrote:
> > O_EXEC should be tunable in runtime, with:
> >
> > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);
>
> Why? You can't do that with O_WRITE.
>
On 10.09.2019 17:04, Taylor R Campbell wrote:
>> Date: Tue, 10 Sep 2019 10:52:47 -0400
>> From: chris...@zoulas.com (Christos Zoulas)
>>
>> 1. Looks like FreeBSD (and my initial posting) leaves the file descriptor
>>of the executable open in the process's image. The Linux man page says
>>
On 22.07.2019 13:12, Greg Troxel wrote:
> Taylor R Campbell writes:
>
>>> It would also be reasonable to have a sysctl to allow /dev/random to
>>> return bytes anyway, like urandom would, and to turn this on for our xen
>>> builders, as a different workaround. That's easy, and it doesn't break
On 21.07.2019 16:53, Kamil Rytarowski wrote:
> On 21.07.2019 16:41, co...@sdf.org wrote:
>> hi,
>>
>> since netbsd won't stop using broken setups like xen (which don't
>> provide randomness) to build packages, why don't we give up on
>> /dev/random entirely?
&
On 21.07.2019 16:41, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
>
/dev/random is not defined in POSIX.
On 16.07.2019 15:34, Michał Górny wrote:
> On Tue, 2019-07-16 at 05:23 +1000, matthew green wrote:
>>> Introduce a simple COREDUMP_MACHDEP_LWP_NOTES logic to provide machdep
>>> API for injecting per-LWP notes into coredumps, and use it to append
>>> PT_GETXSTATE note.
>>
>> this macro is pretty
On 01.07.2019 17:06, Andrew Cagney wrote:
> On Mon, 1 Jul 2019 at 10:06, Kamil Rytarowski wrote:
>>
>> On 01.07.2019 16:01, Christos Zoulas wrote:
>>> In article ,
>>> Michael van Elst wrote:
>>>> chris...@astron.com (Christos Zoulas) writes:
>&g
On 01.07.2019 16:01, Christos Zoulas wrote:
> In article ,
> Michael van Elst wrote:
>> chris...@astron.com (Christos Zoulas) writes:
>>
>>> We can fill them completely with 0 as we pad with 0 the 32 bit
>>> part of the 64 bit registers that does not exist in a 32 bit
>>> process.
>>
>> The
On 30.06.2019 19:19, Jason Thorpe wrote:
>
>
>> On Jun 30, 2019, at 10:15 AM, Christos Zoulas wrote:
>>
>> I think that our goal is be able to branch 9 with a gdb that works as well
>> as 7 (since it is more broken in 8 because of the 64->32 breakage).
>
> Yah, that's fair... I just think we
On 30.06.2019 18:34, Jason Thorpe wrote:
>
>> On Jun 30, 2019, at 9:12 AM, Kamil Rytarowski wrote:
>>
>> Rationale? It worked for me in compat32 mode...
>
> Not if you're debugging core files, right? Everything that works for
> live-debugging on native also n
On 30.06.2019 17:38, Jason Thorpe wrote:
>
>
>> On Jun 30, 2019, at 8:19 AM, Kamil Rytarowski wrote:
>>>> There is kinfo_getvmmap(3) + sysctl(3) equivalent.
>>>
>>> But this really should work for cross-debugging as well.
>>>
>>&g
On 30.06.2019 17:15, Jason Thorpe wrote:
>
>> On Jun 30, 2019, at 8:06 AM, Kamil Rytarowski wrote:
>>
>> On 30.06.2019 15:46, Andrew Cagney wrote:
>>> There's /proc/PID/maps, there should be a PTRACE equivalent and it
>>> should also be dumped into the cor
On 30.06.2019 11:30, Maxime Villard wrote:
> Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit :
>> On 05.06.2019 08:08, Maxime Villard wrote:
>>> I intend to change the NVMM API in order to reduce the data
>>> movements. The
>>> patches are available
On 30.06.2019 15:46, Andrew Cagney wrote:
> There's /proc/PID/maps, there should be a PTRACE equivalent and it
> should also be dumped into the core file.
There is kinfo_getvmmap(3) + sysctl(3) equivalent.
We touched a related code recently (r_debug in rtld) as there was
introduced support in
On 28.06.2019 22:44, Christos Zoulas wrote:
> What do you think? SHould we make the code work like before? Or this is
> functionality that we don't want to have because it is "dumb"? (I think
> that Max here means that it adds complexity and it could be dangerous,
> but I am just guessing)
On 18.06.2019 14:30, Jason Thorpe wrote:
>
>
>> On Jun 18, 2019, at 2:25 PM, Jason Thorpe wrote:
>>
>>> On Jun 18, 2019, at 2:01 PM, Greg Troxel wrote:
>>>
>>> I realize mkfifo is preferred in our world, and POSIX says it is
>>> preferred. But I believe we have a failure to follow POSIX.
>>>
On 06.06.2019 17:10, Christos Zoulas wrote:
> It is better style to do avoid the extra checks and duplication so I would
> also fix the original :-).
>
> Having said all of that, I don't see any of those changes are "risky" or
> creating issues for the -9 branch, so I don't see a reason to delay
On 06.06.2019 05:25, Frédéric Fauberteau wrote:
> Le 2019-05-06 05:58, zerous a écrit :
>> Hi All,
>>
>> I have done some tinkering with wine-4.4 on i386 and amd64.
>> I have done a write-up about them on https://nocebo.space/netbsd/
>> Currently, I have been able to compile and run wine-1.9
On 06.06.2019 05:07, Mouse wrote:
>> Unfortunately, if "undefined behavior" (UB) is invoked, you simply
>> cannot claim to understand what is happening, because C11-compliant
>> compilers have a lot of leeway in what code they generate when
>> behavior is undefined.
>
> Compilers that do
On 05.06.2019 23:42, Robert Elz wrote:
> Date:Wed, 5 Jun 2019 22:25:39 +0200
> From: Kamil Rytarowski
> Message-ID: <05d25ffa-588b-464f-56c9-099fea3f3...@gmx.com>
>
> | Does this patch look good?
>
> Personally, I would hesitate to ch
Does this patch look good?
http://netbsd.org/~kamil/patch-00121-kern_ntptime.c.txt
It fixes the following reports:
[ 49.1001191] UBSan: Undefined Behavior in
../../../../kern/kern_ntptime.c:381:14, left shift of negative value
-43172954112
[ 49.1001191] UBSan: Undefined Behavior in
On 05.06.2019 18:59, Paul Goyette wrote:
> On Wed, 5 Jun 2019, Kamil Rytarowski wrote:
>
>> On 05.06.2019 17:59, Paul Goyette wrote:
>>> An easier question:
>>>
>>> Does an old HAXM module still work correctly with a new kernel? AND
>>> Does a
On 05.06.2019 08:08, Maxime Villard wrote:
> I intend to change the NVMM API in order to reduce the data movements. The
> patches are available here [1].
>
This looks good and it will make the interfaces simpler.
Could we merge the demo example into /usr/share/examples/nvmm ?
ber nonetheless as we want to keep kernel and modules (ptrace is a
module) synced.
>
>
> On Wed, 5 Jun 2019, Paul Goyette wrote:
>
>> On Wed, 5 Jun 2019, Kamil Rytarowski wrote:
>>
>>> On 05.06.2019 17:32, Paul Goyette wrote:
>>>> Are there any userland
On 05.06.2019 17:32, Paul Goyette wrote:
> Are there any userland programs that use cpu.h? Or any kernel modules?
We use cpu.h, e.g. when prompting for CPU_MACHDEP values with sysctl(3).
HAXM as a kernel module uses cpu.h.
>
> If so, these changes would create a change in the kernel API and
On 28.05.2019 20:08, Martin Husemann wrote:
> On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote:
>> Well, if we are only to consider new registers, then we're talking about
>> 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state
>> register, multiply by two... 114 PT_*
On 28.05.2019 18:34, Michał Górny wrote:
> There is no difference in internal layout or logic between b. and c.
> In either case, we need to perform XSAVE, process it and copy the data
> into internal structure. The only difference is that in b. we handle it
> all in one request, and in c. we do
On 27.05.2019 21:03, Michał Górny wrote:
> Currently, the compat32 passes PT_* request values to kernel functions
> without translation. This works fine for low PT_* requests that happen
> to have the same values both on i386 and amd64. However, for requests
> higher than PT_SETFPREGS, the value
On 28.05.2019 15:20, Michał Górny wrote:
> Hi,
>
> After implementing most of PT_GETXSTATE/PT_SETXSTATE and getting some
> comments requiring major changes anyway, I'm starting to wonder whether
> the approach I've followed is actually the best one. This is especially
> important now that I'm
On 04.03.2019 16:24, Emmanuel Dreyfus wrote:
> Hello
>
> With latest netbsd-6 kernel, dumping data on a LTFS fileystem, I get
> a few kernel messages like that:
> pmap_unwire: wiring for pmap 0xc3d19000 va 0xb57ff000 did not change!
>
> It does not seem to break anything, Should the message be
On 28.02.2019 08:24, Iain Hibbert wrote:
> On Thu, 28 Feb 2019, Masanobu SAITOH wrote:
>
>> I'd like to get new number for new ioctl. How should I find unused number
>> for it? I'm going to add new SIOCXXX. It may not enough to grep sys/net/*.h,
>> so I made usr.bin/kdump-ioctl.c and did
>>
>>
Please review.
Build errors and proposed patches are in the .txt files.
http://netbsd.org/~kamil/patch-00087-amdgpu_cz_smc.c.txt
http://netbsd.org/~kamil/patch-00088-amdgpu_display.c.txt
http://netbsd.org/~kamil/patch-00089-amdgpu_gfx_v8_0.c.txt
On 19.02.2019 08:17, Michael van Elst wrote:
> n...@gmx.com (Kamil Rytarowski) writes:
>
>> =46rom end-user point of view major and minor numbers don't matter most o=
>> f
>> the time (are there exceptions?) and it might be picked by the kernel
>> dynamically.
>
On 17.02.2019 21:28, Christoph Badura wrote:
> On Sat, Feb 16, 2019 at 09:02:05PM -0800, John Nemeth wrote:
>> On Feb 16, 11:25pm, Kamil Rytarowski wrote:
>> } Where and how to reserve these major numbers?
>>
>> The ideal thing is to not reserve numbers at all
; Le sam. 16 févr. 2019 à 23:55, Kamil Rytarowski a écrit :
>>
>> On 16.02.2019 23:40, Jaromír Doleček wrote:
>>> Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit :
>>>>
>>>> We started to build and ship kernel modules through pkgsrc.
>>&g
On 16.02.2019 23:40, Jaromír Doleček wrote:
> Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit :
>>
>> We started to build and ship kernel modules through pkgsrc.
>>
>> I would like to reserve 3 major numbers for the HAXM case from the base
>> pool of dev
We started to build and ship kernel modules through pkgsrc.
I would like to reserve 3 major numbers for the HAXM case from the base
pool of devices and prevent potential future conflicts and compatibility
breakage due to picking up another major number in a 3rd party software.
Where and how to
On 12.02.2019 15:23, Martin Husemann wrote:
> On Tue, Feb 12, 2019 at 03:18:19PM +0100, Kamil Rytarowski wrote:
>> Is it viable to get merged the Hyper-V support for NetBSD-9?
>
> What is missing? I thought it all went in already (and even pulled up to -8)?
>
> Martin
&g
Is it viable to get merged the Hyper-V support for NetBSD-9?
signature.asc
Description: OpenPGP digital signature
On 07.02.2019 14:52, Michał Górny wrote:
> Fix the kernel pty driver to report closed slave via master's kevent
> EVFILT_READ. This behavior matches the behavior for pipes, is
> consistent with how FreeBSD implements it and is relied upon by LLDB's
> main loop implementation.
> ---
>
On 02.02.2019 19:33, Mindaugas Rasiukevicius wrote:
> Jason Thorpe wrote:
>> Patch is here:
>> https://patch-diff.githubusercontent.com/raw/thorpej/netbsd-src/pull/5.diff
>
> Thanks for working on this.
>
> - Why not just add a new syscall, instead of the KSEM_PSHARED stuff?
>
> - If you add
On 19.01.2019 18:32, Jason Thorpe wrote:
>
>
>> On Jan 19, 2019, at 8:55 AM, David Holland wrote:
>>
>> That's equivalent to writing out zeros (but more efficient) -- I would
>> say the page shouldn't appear in the dump at all on the grounds that
>> it doesn't actually exist.
>>
>> Whether it's
On 18.01.2019 09:50, Martin Husemann wrote:
> Sorry, I completely fail to parse this - can you start from scratch and
> just describe the problem you think you are seeing?
>
> Martin
>
If we trigger SIGBUS with the trigger_bus() function (mentioned in the
initial message), the core(5) dumping
On 18.01.2019 10:08, Martin Husemann wrote:
> On Fri, Jan 18, 2019 at 10:01:22AM +0100, Kamil Rytarowski wrote:
>> It's interrupted because we cannot access the pages that are not
>> assigned (which is the cause of the original crash emitting SIGBUS).
>
> Which pages are not
On 18.01.2019 10:03, David Holland wrote:
> On Fri, Jan 18, 2019 at 09:50:38AM +0100, Martin Husemann wrote:
> > Sorry, I completely fail to parse this - can you start from scratch and
> > just describe the problem you think you are seeing?
>
> My understanding is:
>
>- If you map a file
On 18.01.2019 09:00, Martin Husemann wrote:
> On Thu, Jan 17, 2019 at 09:52:17PM +0100, Kamil Rytarowski wrote:
>> The problem is that when we are in coredump_getseghdrs_elf64() and call
>> copyin_proc() -> copyin_vmspace() -> copyin() we trigger a trap that is
>&
On 16.01.2019 10:20, Paul Goyette wrote:
> Given the dearth of response to the notice posted on current-users I
> thought I'd widen the audience a bit, to make sure that all concerned
> have a chance to react!
>
> -- Forwarded message --
> Date: Mon, 14 Jan 2019 08:21:18 +0800
On 04.01.2019 19:56, Maxime Villard wrote:
>
> Interrupt != exception. When a page fault comes in, there's no flag that is
> set in proc/lwp/curcpu, so you can't know if you are in an exception
> context;
> ci_idepth is unrelated.
>
> Of course we could add such a flag under #ifdef KCOV and then
On 30.12.2018 17:12, Jason Thorpe wrote:
>
>
>> On Dec 30, 2018, at 7:59 AM, Kamil Rytarowski wrote:
>>
>> On 30.12.2018 16:51, co...@sdf.org wrote:
>>> Thanks.
>>>
>>> I'm not sure if it is a sufficient explanation
On 30.12.2018 16:51, co...@sdf.org wrote:
> Thanks.
>
> I'm not sure if it is a sufficient explanation though, there's a
> CFATTACH_DECL_NEW(pckbc_acpi, ...
> but no
> CFATTACH_DCEL_NEW(pckbc, ..
>
> Or does that work somehow?
>
During the kernel config process you will get ioconf.c that has
On 30.12.2018 08:07, co...@sdf.org wrote:
> Hi folks,
>
> looking at port-i386/43331 I came across pckbc_cd.
> It doens't appear to be defined anywhere or initialized, though there's
> an extern in sys/arch/i386/pnpbios/pckbc_pnpbios.c
>
> How does this work? how does it compile?! :-)
>
On 20.12.2018 20:29, Robert Swindells wrote:
>
> Kamil Rytarowski wrote:
>> On 20.12.2018 17:58, Jason Thorpe wrote:
>>>
>>>
>>>> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote:
>>>>
>>>> Kamil Rytarowski wrote:
>>>&
On 20.12.2018 17:58, Jason Thorpe wrote:
>
>
>> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote:
>>
>> Kamil Rytarowski wrote:
>>>> While I agree that it’s not exactly difficult to maintain the a.out exec
>>>> package, I do wonder if th
On 20.12.2018 17:03, Jason Thorpe wrote:
> While I agree that it’s not exactly difficult to maintain the a.out exec
> package, I do wonder if there is anyone out there actually running ancient
> a.out binaries.
>
NetBSD 0.9 i386 a.out yes.
signature.asc
Description: OpenPGP digital
time_t, and for dates prior UNIX epoch
you need negative time_t. 64-bit integer type is used in rationale for
current development of the interfaces.
Negative time is not that alien concept in the standard, as there are
mentions about positive and negative leap seconds that must be supported.
On 13.1
On 13.12.2018 03:22, Mouse wrote:
>> In real life it's often needed to store time_t pointing before the
>> UNIX epoch.
>
> I am inclined to doubt it - "real life" needs to store such times,
> certainly, but I have yet to see a case where it imposes any particular
> representation for that
On 12.12.2018 22:27, Joerg Sonnenberger wrote:
> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote:
>> While researching libc++ test failures, I've discovered that NetBSD
>> suffers from the same issue as FreeBSD -- that is, both the userspace
>> tooling and the kernel have problems
On 12.12.2018 18:04, Mouse wrote:
>>> Why would you store pointers in integers at all? Surely the right
>>> thing to do is store them as void * (for data pointers) or
>>> void (*)() (for function pointers)...?
>> kcov utilizes compiler instrumentation that uses low-lever, below the
>> C and C++
On 12.12.2018 16:02, Mouse wrote:
>> kcov returns kernel pointers, 32-bit program executed by 64-bit
>> kernel cannot store them in 32-bit integers.
>
> Why would you store pointers in integers at all? Surely the right
> thing to do is store them as void * (for data pointers) or void (*)()
>
On 12.12.2018 13:23, Martin Husemann wrote:
> On Wed, Dec 12, 2018 at 01:19:40PM +0100, Kamil Rytarowski wrote:
>> Upstream (dvyukov) suggested to evaluate whether to use pointers always
>> in 64bit types (uint64_t), as this way programs will be easier to reuse
>> in 32bit
On 12.12.2018 12:50, Maxime Villard wrote:
> Le 12/12/2018 à 11:01, Siddharth Muralee a écrit :
>> Hello,
>> I have attached a patch which adds the Kernel Code Coverage(KCov)
>> to the NetBSD kernel.
>> This is one of the foundational steps to get Syzkaller (Kernel Fuzzer)
>> fully functional
On 04.12.2018 19:20, Christos Zoulas wrote:
> In article <1543941318.804.8.ca...@gentoo.org>,
> MichaŠGórny wrote:
>> -=-=-=-=-=-
>>
>> Hello,
>>
>> Today me and Kamil noticed some more LLVM tests failing due to the host
>> filesystem being mounted with 'noatime' option. Upon closer
>>
On 20.11.2018 20:06, Christos Zoulas wrote:
> In article <20181120183715.ga11...@homeworld.netbsd.org>,
> wrote:
>> On Tue, Nov 20, 2018 at 08:25:38PM +1030, Brett Lymn wrote:
>>>
>>> Comments? Anyone really care?
>>
>> IMO - your call (or christos's). You two have done more than enough for
>>
On 01.11.2018 12:34, Izumi Tsutsui wrote:
> jmcneill@ wrote:
>
>> On Wed, 31 Oct 2018, Taylor R Campbell wrote:
>>
>>> For the moment, as a provisional workaround to make progress, you can
>>> probably get by with `pa << PGSHIFT', where pa is the physical (byte)
>>
>> I think this should be `pa
On 31.10.2018 18:05, Taylor R Campbell wrote:
> For the moment, as a provisional workaround to make progress, you can
> probably get by with `pa << PGSHIFT', where pa is the physical (byte)
> address of the page you want -- but make sure to add a big scary XXX
> comment saying that this is not
On 27.08.2018 02:39, Mindaugas Rasiukevicius wrote:
> Hi,
>
> Here is patch to import the FreeBSD's libnv library:
>
> http://www.netbsd.org/~rmind/libnv.diff
>
> For more details on libnv:
>
> https://www.freebsd.org/cgi/man.cgi?query=nv=9
>
> I have already converted the standalone/upstream
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:
>> >
>> >
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
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
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
>
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.
>
>
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 :
>>>
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
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
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
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.
>
>
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
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:
>
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
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
101 - 200 of 376 matches
Mail list logo
