In article ,
Sevan Janiyan wrote:
>
>
>On 02/15/18 01:23, Valery Ushakov wrote:
>> As someone has already mentioned upthread, because printing a
>> backtrace might cause another panic, so the default was selected to be
>> on the safe(r) side. At least that's what I recall.
>
>On 02/15/18 01:33,
In article ,
Sevan Janiyan wrote:
>Hello,
>Is there any reason good reason why we should not opt for
>DDB_COMMANDONENTER="bt" by default across the board??
>We have it set or a variation of, on some ports (amd64, some evbarm and
>evbmips configs, i386, macppc). Would be useful to have it there by
In article
,
Ryota Ozaki wrote:
>
>Is the fix appropriate?
Looks right to me, but it is above my pay grade :-)
christos
In article ,
Dimitris Karagkasidis wrote:
>On 02/07/2018 11:14 AM, Martin Husemann wrote:
> > QEMU should never let the kernel see any exceptions or other traces of being
> > debugged, IMHO.
> >
> > To me this sounds like a qemu bug.
>
>Martin is right. It is a QEMU bug that only occurs when KVM
In article ,
Maxime Villard wrote:
>Le 18/01/2018 à 13:43, Tom Ivar Helbekkmo a écrit :
>> Maxime Villard writes:
>>
>>> Well, looking at the code, it seems to me that _kvm_open() should be
>>> changed to keep /dev/ksyms open, the same way it keeps /dev/kmem open.
>>
>> Agreed. This works f
In article <20180120144510.ga61...@atom.tmux.org>,
Tobias Ulmer wrote:
>TLDR: nfs_reqq crrptin, see diff below.
>
>I've been trying to track down the source of NFS client hangs and
>crashes over the last weeks, in order to get back to the things I really
>wanted to do...
>
>No special setup, the
In article <20180117152524.ga11...@sdf.org>, wrote:
>-=-=-=-=-=-
>
>This leaks information that unprivileged user probably has no reason to
>own:
>
>> cat /dev/ksyms > ksyms
>> readelf -a ksyms |wc -l
> 47594
>
>Any strong reason not to apply the following?
>Presumably it will have benefits for
On Jan 12, 11:27am, campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell)
wrote:
-- Subject: Re: MP-safe DAD timer destruction with callout_stop
| > Date: Fri, 12 Jan 2018 04:33:06 + (UTC)
| > From: chris...@astron.com (Christos Zoulas)
| >
| > Even then (with callout_h
In article ,
Ryota Ozaki wrote:
>Hi,
>
>For a certain reason(*), DAD timers are hard to use
>callout_halt to destroy DAD timer objects. So I was going
>to fall back to callout_stop (as of NetBSD 7) that is
>almost safe but still has a possibility of going wrong(**).
>
>(*) See the thread starting
On Jan 7, 9:03pm, al...@yandex.ru (Alexander Nasonov) wrote:
-- Subject: Re: Go binary panics on amd64-current - SIG*unknown
Thanks! Committed (3 x)
christos
In article <20180106224309.w2vicky2i6rf6fvu@neva>,
Alexander Nasonov wrote:
>I downloaded IACA tool from intel.com but I couldn't run it:
>
>$ ktrace ./iaca-v3.0-lin64/iaca
>fatal error: rt_sigaction read failure
>
>runtime stack:
>runtime.throw(0x75de24, 0x19)
>/nfs/iil/disks/kfw/tools/g
In article ,
Maxime Villard wrote:
>Hi,
>Here is a patch [1] that hides the addresses of the kernel modules when
>'modstat -k' is entered by an unprivileged user. The current behavior is
>preserved for root.
>
>The addresses currently leaked cannot be used to reconstruct the layout of
>the kernel
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>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 ext
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>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 no
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/msg022836.html
Yes, the first patch is exactly what I had in mind; remove the
assem
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>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
>>
On Dec 25, 4:54pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
-- Subject: Re: RFC: ipsec(4) pseudo interface
| Here is the updated patch series and unified patch.
| - https://www.netbsd.org/~knakahara/if_ipsec/if_ipsec4.tgz
| - https://www.netbsd.org/~knakahara/if_ipsec/if_ipsec4-unifie
In article ,
Robert Swindells wrote:
>
>What is wrong with your idea of updatesockopt(2) ? Or maybe call it
>getsockopt2() and only use it for the "get with extra argument" case.
I guess getsockopt2/updatesockopt is not that bad after all. Perhaps
we should go with that?
christos
In article ,
Kengo NAKAHARA wrote:
>Hi,
>
>Thank you for your reviewing.
Thanks for fixing; more nit-picking:
1. there is a variable called err instead of error why (all the rest
are called error)?
2. I prefer fewer lines of code, fewer variables for all the copies
of those similar functi
In article <75925357-8e16-0f0f-b7a0-78155c865...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Hi,
>
>On 2017/12/19 2:54, Christos Zoulas wrote:
>> In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>,
>> Kengo NAKAHARA wrote:
>>> Hi,
>>>
>>
In article <20171218184400.ga27...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
>> (a) Add if_ipsec.4
>> (b) move current ipsec.4(for ipsec protocol) to ipsec.9, and then
>> add ipsec.4(for ipsec pseudo interface)
>
In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Hi,
>
>We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
>interface manages its security policy(SP) by itself, in particular, we do
># ifconfig ipsec0 tunnel 10.0.0.1 10.0.0.2
>the SPs "
In article ,
Robert Swindells wrote:
>
>There are about 40 options defined by SCTP. I would need to go through
>the list to see how many of them were of which type.
>
>There isn't any source shared between FreeBSD and NetBSD anymore, their
>stack has diverged a lot from KAME.
Ok.
>
>>> Selecti
On Dec 14, 10:37pm, marti...@sdf.org ("Stephen M. Jones") wrote:
-- Subject: Re: panic ffs_valloc dup_alloc
| > Stephen M. Jones wrote:
| > >> > In some cases the filesystem corruption can only be corrected by a
newfs.
| > >>
| > >> Does it happen with FFSv2? I also had lot of FS corruption lat
In article <201712140640.vbe6epxc013...@sdf.org>,
Stephen M. Jones wrote:
>> > In some cases the filesystem corruption can only be corrected by a newfs.
>>
>> Does it happen with FFSv2? I also had lot of FS corruption lately. it
>> only hapened on some specific machines (moving VM to another host
In article <201712132230.vbdmu37i021...@sdf.org>,
Stephen M. Jones wrote:
>
>I have NetBSD-7 deployed on many systems (the majority being amd64) and
>have noticed that the busy machines (smtpd, imapd, httpd) tend to develop
>filesystem inconsistencies that get worse with time. The inconsistencie
In article ,
Robert Swindells wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>Robert Swindells wrote:
>>>
>>>chris...@astron.com (Christos Zoulas) wrote:
>>>>In article ,
>>>>Robert Swindells wrote:
>
In article ,
Robert Swindells wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>Robert Swindells wrote:
>>>
>>>chris...@astron.com (Christos Zoulas) wrote:
>>>>In article ,
>>>>
>>>>So depending on th
In article ,
Robert Swindells wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>
>>So depending on the contents of the sockval we do something different?
>
>FreeBSD does. The calls to copy in or out the data are scattered
>throughout the net
In article <3e9dfc2e-418b-6006-72c6-25892b0b5...@kardel.name>,
Frank Kardel wrote:
>Hi !
>
>
>I am pretty skeptical by the hardwired constant of 20 (clockticks). At
>the usual/common clock interrupt rate of 100 Hz this is 200ms.
>
>So any nanosleep below 200ms will be a kernel busy loop...
>
>Fo
In article ,
Robert Swindells wrote:
>
>I wrote:
>>Does anyone know why we don't use the input 'optlen' parameter to the
>>getsockopt(2) syscall, we do write back to it on return.
>>
>>In ip_output() there is this, which suggests that someone had come
>>across this before.
>>
>>#if 0 /* defined
In article <20171207211246.ga15...@spathi.chuq.com>,
Chuck Silvers wrote:
>hi folks,
>
>as taylor requested after the previous mail about this,
>I've made a copy of the freebsd files that I started with
>and put them in the netbsd source tree layout so that they
>can easily be diffed against the
In article <20171207074102.gc19...@mail.duskware.de>,
Martin Husemann wrote:
>On Wed, Dec 06, 2017 at 06:22:48PM -0500, Christos Zoulas wrote:
>> This has also the unfortunate side effect that makes the problem
>> undebuggable (aside from wasting CPU resources). The followin
Hello,
Currently processes that catch SIGSEGV/SIGBUS/SIGFPE and receive
a signal again while they are processing the signal handler end in
an infinite loop spinning because the signal is masked during delivery
(and executing the handler).
This is not desirable behavior. I would be better to just
In article <27887.1512591...@splode.eterna.com.au>,
matthew green wrote:
>kernel libraries are supposed to be built as a .o not a .a,
>for modular/lkm kernels. did this get lost some where?
>
>ie, if you have a MODULAR kernel, then the build should always
>include all the library stuff, in libke
@ -0,0 +1,136 @@
+/* $NetBSD: t_write.c,v 1.6 2017/07/09 22:18:43 christos Exp $ */
+
+/*-
+ * Copyright (c) 2017 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Christos Zoulas.
+ *
+ * Redistribution and us
In article <20171120103643.gh4...@trav.math.uni-bonn.de>,
Edgar Fuß wrote:
>> Is there anything ringing a bell to someone here?
>Yes, but I guess that doesn't help.
>I experienced something remotely similar after a disc firmware crash followed
>by a mpt(4) lockup (before I wrote the timeout reco
In article <5cee5471-dc6f-db16-8914-75ad5ad15...@m00nbsd.net>,
Maxime Villard wrote:
>Le 04/10/2017 à 21:00, Maxime Villard a écrit :
>> Here is a Kernel ASLR implementation for NetBSD-amd64.
>> [...]
>> Known issues:
>> * Right now, the kernel segments are contiguous. Starting from this
>>
On Nov 8, 6:54am, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: namei and path canonicalization
| We don't, at least as of your changes this afternoon which always set
| it... I'm wondering if we should though. Any setugid program that uses
| that value is presumptively doing so
On Nov 8, 3:12am, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: namei and path canonicalization
| On Tue, Nov 07, 2017 at 11:11:16PM +, Christos Zoulas wrote:
| > In article <20171107222924.ge17...@netbsd.org>,
| > David Holland wrote:
| > >
| >
In article <20171107222924.ge17...@netbsd.org>,
David Holland wrote:
>
>Also it occurs to me that there's no reason for the kernel to do the
>getcwd call; it should just provide the argument given to exec in all
>cases, and ld.so can do the getcwd call itself if necessary (if the
>string it finds
On Nov 2, 6:11am, abhirup@hotmail.com (Abhirup Das) wrote:
-- Subject: Re: ext3 support
| Just curious what is missing from the google summer of code work that you
| linked in your email. Why hasn't that been merged into the main repository?
It has all been merged.
christos
In article ,
Christos Zoulas wrote:
>>(note: we've always had this issue, so what, no one has ever tried to
>>modload COMPAT_16 on amd64?)
>
>I would declare getval_unlocked as taking void *symp, remove the cast
>in the call, and change:
>
> *symp = (void
In article <34ff5b41-51bb-fa19-b893-bbfff43f7...@m00nbsd.net>,
Maxime Villard wrote:
>Throwing this here in case someone cares. In the kernel module relocator we
>don't support absolute symbols coming from the kernel, and it means that we
>can't modload a module containing for example:
>
>
In article
,
Abhirup Das wrote:
>Hi,
>
>I just came across the ext3 implementation project listed on the netbsd
>website, https://wiki.netbsd.org/projects/project/ext3fs/
>and I would like to take the time to implement this. But I am not too
>sure on how to start this project, I have read up o
In article <20171029134534.gc24...@mail.duskware.de>,
Martin Husemann wrote:
>To give a better idea of what changes: here is a tested patch that solves
>the original problem for me.
>
>It is kinda ugly, but I don't see an easier solution.
Let's go with that for now.
christos
In article
,
Rocky Hotas wrote:
>Hi all!
>I am working to adapt the OpenBSD if_msk.c driver to NetBSD. If needed,
>these are my previous messages as a recap:
>
>http://mail-index.netbsd.org/tech-kern/2017/10/11/msg022430.html
>http://mail-index.netbsd.org/tech-kern/2017/10/11/msg022431.html
>
>Op
In article <20171019102654.gh16...@mail.duskware.de>,
Martin Husemann wrote:
>-=-=-=-=-=-
>
>Hey folks,
>
>at startup all arm machines show a warning:
>
>total memory = 512 MB
>avail memory = 495 MB
>sysctl_createv: sysctl_create(machine_arch) returned 17
>timecounter: Timecounters tick every 10.
In article ,
Robert Swindells wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>Robert Swindells wrote:
>>>
>>>I wrote:
>>>>Does anyone know why we don't use the input 'optlen' parameter to the
>&g
In article ,
Robert Swindells wrote:
>
>I wrote:
>>Does anyone know why we don't use the input 'optlen' parameter to the
>>getsockopt(2) syscall, we do write back to it on return.
>>
>>In ip_output() there is this, which suggests that someone had come
>>across this before.
>>
>>#if 0 /* defined
In article ,
Robert Swindells wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>Robert Swindells wrote:
>>>
>>>matthew green wrote:
>>>>Robert Swindells writes:
>>>>>
>>>>> Do we care a
On Sep 16, 5:09pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: Proposal: Disable autoload of compat_xyz modules
| > The sysctl does not have to live in the module space.
|
| Where do you put the helper then? It needs access to linux_execsw, which is in
| the module space.
It could
On Sep 16, 4:15pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: Proposal: Disable autoload of compat_xyz modules
| Le 13/09/2017 à 22:00, Christos Zoulas a écrit :
| > Can't we add a sysctl that controls the behavior and have autoload
| > of the compat modules off
In article <20170910185148.ga7...@antioche.eu.org>,
Manuel Bouyer wrote:
>On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote:
>> Le 10/09/2017 à 19:59, Manuel Bouyer a écrit :
>> > There's something I don't understand in this thread: what is the point
>> > of having the code in kernel
In article <20170908115647.ga29...@mail.duskware.de>,
Martin Husemann wrote:
>On Fri, Sep 08, 2017 at 12:55:37PM +0200, Thomas Klausner wrote:
>> What's the best answer for NetBSD?
>
>If the kernel is 64bit:
>kvm_getproc2() and check the process flags for P_32.
>
>If not: all of them ;-}
>
>I wou
In article ,
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_FSTRACEÂ Â Â 0x0001 */
>>> instead of completely removing the constants for now as a rem
On Aug 27, 8:09am, da...@netbsd.org (D'Arcy Cain) wrote:
-- Subject: Re: /proc/#/ctl removal
| Isn't that sort of duplicating what CVS does?
Yes, but:
1. it has been existing practice
2. it is not easy to find the missing value from cvs
3. when someone wants to add a new value, it is best to und
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 Monday.
LGTM, perhaps leave a comment /* old P_FSTRACE 0x0001 */
instead of complet
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I plan to remove the filesystem process tracing capability through
>/proc/#/ctl. This is a legacy interface from 4.4BSD, and it was
>introduced to overcome shortcomings of ptrace(2) at that time, which are
>no longer relevant (perf
In article ,
Nima Sahraneshin wrote:
>-=-=-=-=-=-
>
>Dear Sir/Madam,
>
>I am NIma :) I want to know the status of this project. Is it available
>now?
>
>https://wiki.netbsd.org/projects/project/aprint/
Yes, it is still available :-)
christos
On Jul 13, 10:29am, net...@precedence.co.uk (Stephen Borrill) wrote:
-- Subject: Re: IPfilter panic in 7.1
| On Tue, 11 Jul 2017, Christos Zoulas wrote:
| > In article <1n8zh65.79uodgaqcnrcm%m...@netbsd.org>,
| > Emmanuel Dreyfus wrote:
| >> Hi
| >>
| >> I am hit by
In article <1n8zh65.79uodgaqcnrcm%m...@netbsd.org>,
Emmanuel Dreyfus wrote:
>Hi
>
>I am hit by frequent IPfilter panics on a firewall setup after upgrading
>to 7.1. Is it something someone else experienced?
Sounds like a bug we squashed in head with a patch from FreeBSD.
christos
Hello,
Since ntpd will start supporting SO_TIMESTAMPING, I thought it would
be nice to revive and commit the GSoC 2012 timestamping code from Vlad Balan.
This copies the linux timestamping API, shown in the first part of the
diff as . Support for the Intel gigabit card is provided,
although I don'
In article <20170702202656.gc29...@netbsd.org>,
David Holland wrote:
>On Fri, Jun 30, 2017 at 07:36:41PM +0200, Joerg Sonnenberger wrote:
> > From the follow-up, it is far from clear that it is fixed completely.
>
>Yes, I was wondering about that but people have been saying it works
>on -8...
>
>
On Jul 2, 3:31pm, jo...@bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: nanosleep() for shorted than schedule slice
| > The solution is to implement "tickless kernel". It is not that difficult.
|
| Yes and no. The difficult hard is introducing it without creating
| noticable performance regre
In article <1n8j63y.1pcs0owrn6gcem%m...@netbsd.org>,
Emmanuel Dreyfus wrote:
>Hello
>
>I just encountered a situation where PHP performance on NetBSD is rather
>weak compared to Linux or MacOS X.
>
>The code calls PHP's uniqid() a lot of time. uniqid() creates an unique
>id based on the clock. In
In article ,
Robert Swindells wrote:
>
>matthew green wrote:
>>Robert Swindells writes:
>>>
>>> Do we care about keeping all the Linux procfs code in
>>> sys/miscfs/proc/procfs_linux.c ?
>>>
>>> Some Linux applications have started grovelling in /proc/self/status to
>>> read various values.
>>
In article ,
Ripunjay Tripathi wrote:
>-=-=-=-=-=-
>
>To understand the ASLR and its impact on application address space I
>modified the NetBSD kern_pax.c code as below. My line of thought is to
>increase entropy by bringing in lower bytes into play. Original PAX code
>causes stack to be page ali
On May 24, 10:35pm, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: Adding ruminit(4)
| > Not really :-) It should take < 1 hour to merge the existing code in
| > a single file...
It took more like 10 minutes :-)
christos
On May 24, 10:35pm, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: Adding ruminit(4)
| I haven't looked too closely, but Linux usb_modeswitch seems to have
| several dozens of different magic commands.
We have 1/2 a dozen, but it is simple enough to put some bytes in an
array and call
In article <20170524183723.gc18...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>On Wed, May 24, 2017 at 17:20:52 +, Christos Zoulas wrote:
>
>> Why not move the all the code into a single "ubulkdisable" or
>> something driver?
>
>Finally a thumb to use
In article ,
Pierre Pronchery wrote:
>-=-=-=-=-=-
>
> Hi tech-kernel@,
>
>as some of you may have noticed, I just added a USB ID to the rum(4)
>driver [1]. It is for a device called "Windy 31" from Synet Electronics,
>product name MW-P54SS [2] (yes it's old).
>
>As it happ
On Apr 30, 10:50pm, c...@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: New diagnostic routine - mutex_ownable()
| this is still much more expensive than necessary.
| it would be easy to add a new lockdebug interface to perform this check
| rather than using mutex_enter() to get the recursion-che
In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>While working on getting the localcount(9) stuff whipped into shape, I
>ran across a situation where it is desirable to ensure that the current
>process/lwp does not already own a mutex.
>
>We cannot use !mutex_owned() since that doesn't return t
In article ,
Christos Zoulas wrote:
>In article <20170420113134.gb23...@britannica.bec.de>,
>Joerg Sonnenberger wrote:
>>On Thu, Apr 20, 2017 at 06:48:01AM +0200, Martin Husemann wrote:
>>> On Thu, Apr 20, 2017 at 02:29:26AM +0200, Joerg Sonnenberger wrote:
>&
In article <20170420113134.gb23...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Thu, Apr 20, 2017 at 06:48:01AM +0200, Martin Husemann wrote:
>> On Thu, Apr 20, 2017 at 02:29:26AM +0200, Joerg Sonnenberger wrote:
>> > As discussed previously, I think the patch makes the behavior worse and
>>
In article <20170420044801.ga3...@mail.duskware.de>,
Martin Husemann wrote:
>On Thu, Apr 20, 2017 at 02:29:26AM +0200, Joerg Sonnenberger wrote:
>> As discussed previously, I think the patch makes the behavior worse and
>> the Go implementation is kind of stupid as well.
>
>No comment on the patc
Hello,
This issue came up recently with the go language signal tests failing.
The problem is that NetBSD copies the l_sigstk on lwp_creation and if
threads happen to get signals at the same time, then they share the
signal stack and they die (if sigaltstack is set). Go attempts to work
around thi
In article <20170420002926.ga17...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Wed, Apr 19, 2017 at 07:52:25PM -0400, Christos Zoulas wrote:
>> This issue came up recently with the go language signal tests failing.
>> The problem is that NetBSD copies the l_sigstk o
Hello,
This issue came up recently with the go language signal tests failing.
The problem is that NetBSD copies the l_sigstk on lwp_creation and if
threads happen to get signals at the same time, then they share the
signal stack and they die (if sigaltstack is set). Go attempts to work
around this
In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>On Mon, 17 Apr 2017, Christos Zoulas wrote:
>
>> In article ,
>> Paul Goyette wrote:
>>> -=-=-=-=-=-
>>>
>>> On Mon, 17 Apr 2017, Paul Goyette wrote:
>>>
>>>> While perusi
In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>On Mon, 17 Apr 2017, Paul Goyette wrote:
>
>> While perusing the code, I noticed some possible issues:
>>
>> 1. In kobj_unload() the calls to kobj_machdep() for data and rodata
>> sections are conditional on the appropriate ko->ko_xxx_address bei
On Apr 12, 5:48pm, r...@marples.name (Roy Marples) wrote:
-- Subject: Re: route(4): Adding ROUTE_MSGFILTER socket option
| On 12/04/2017 00:00, Christos Zoulas wrote:
| > Don't forget the racoon.
|
| I don't use racoon, so only compile tested, but it's fairly straight
| forwa
In article <18202.1491947...@andromeda.noi.kre.to>,
Robert Elz wrote:
>Date:Tue, 11 Apr 2017 19:25:33 +0100
>From:Roy Marples
>Message-ID: <49383066-985b-f8ee-3d6f-28f131ea1...@marples.name>
>
> | I didn't see any other RTM_* consumers in our tree.
>
>sbin/routed an
In article ,
Talha Karadeniz wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hi,
>
>I am writing this mail to request authorization for joining the development
>of the project 'fallocate for FFS' [I am new at NetBSD and system
>programming, so I chose this one as a starting point:
>http://wiki.netbsd.org/pro
On Apr 7, 7:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: ELFOSABI_NETBSD
| Currently we set e_ident[EI_OSABI] to ELFOSABI_SYSV. This makes parsing
| NetBSD core(5) core files cross-system little bit less obvious. In LLDB
| we are recognized as generic or unknown unix.
|
| Function EL
In article <534552fb-af29-4219-8390-7514a2665...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>Currently vfs_busy() / vfs_unbusy() get used to
>
>- Enter/leave a critical section against unmounting
>
>- Add a reference to the mount
>
>- return the next mount from the mountlist on error
>
>Plan is to
In article ,
Miles Fertel wrote:
>-=-=-=-=-=-
>
>Hello,
>
>I'm a computer science undergraduate at Harvard studying Operating Systems
>and I'm interested in implementing ext3 for a Google Summer of Code
>project.
>
>First off, the project page states that several years of ext3 GSoC projects
>have
In article ,
Greg Troxel wrote:
>-=-=-=-=-=-
>
>
>Maxime Villard writes:
>
>> I would also add - even if it is not a relevant argument - that most
>> "commonly-used" operating systems do have kernel aslr: Windows, Mac, Linux,
>> etc.
>
>There's another point, which various people may also consid
On Mar 3, 8:55am, nj...@pasteur.fr (Nicolas Joly) wrote:
-- Subject: Re: {clock,pthread}_getcpuclockid return values
| Here is a patch, for review, that fix them on the wrapper side ... I
| prefer keeping the never failing syscalls as an exception.
|
| I'll do a second pass later on the man page
In article <20170227153935.ga9...@issan.sis.pasteur.fr>,
Nicolas Joly wrote:
>
>Hi,
>
>Checking the Opengroup online specifications, i noticed that both
>clock_getcpuclockid[1] and pthread_getcpuclockid[2] should return 0 on
>success and an error number otherwise. But our implementation does not
On Feb 27, 3:41am, campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell)
wrote:
-- Subject: Re: PAX mprotect and JIT
| (a) enable the backing object to be dupable,
|
| (b) allow any dup'd mapping to use at most the bits in maxprot, and
|
| (c) return a mapping using only as many bits of max
In article <20170226213704.ded7260...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>
>The idiom I imagine is something like:
>
> void *buf = mmap(NULL, len, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_ANON|MAP_REMAPDUP, -1, 0);
This is never allowed (rwx).
> /* initialize buf w
In article <20170226153519.ga28...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sun, Feb 26, 2017 at 03:20:46PM +, Christos Zoulas wrote:
>> Any type of foreign API we introduce (MREMAP_DUP or whatever) we'll have to
>> maintain separate patches for (which is
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 26.02.2017 15:05, co...@sdf.org wrote:
>> On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote:
>>> Can we have something like MAP_NOMPROTECT? Something like it would be
>>> used to mmap(2) RWX region:
>>>
>>> void
In article ,
J. Hannken-Illjes wrote:
>
>Comments or objections anyone?
Will that detect open for write file descriptors to removed files?
christos
In article <897028fd-f18a-9ec4-bd5f-3930f40dc...@gmx.com>,
Kamil Rytarowski wrote:
>
>There is one nit... this code (at least to my tests) cannot unstop a
>thread that was created by a tracee with LWP_SUSPENDED.
>
>http://netbsd.org/~kamil/patch-00028-pt_suspend-pt_resume.txt-resume2
>(man pages
On Feb 11, 12:49am, krytarow...@gmail.com (Kamil Rytarowski) wrote:
-- Subject: LWP resume and suspend ptrace(2) API
| I'm proposing an API to restore the functionality to resume or suspend a
| specified thread from execution.
|
| This interface was implemented in the past in user-space inside
|
In article <93c56002-6eb8-0694-3b68-20805ed07...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Hi,
>
>My co-workers implemented L2TPv3(RFC3931) interface for old version NetBSD.
>And then, I port the inteface to NetBSD-current and MP-ify. Here is the patch.
>http://netbsd.org/~knakahara/if-l2tp/if-l2tp.
On Jan 19, 1:39pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: Fixed modular kernel path and different kernels
| OK, I looked into this a bit more.
|
| Doing the 'prompt for module path' thing is non-trivial, at least for
| someone who is totally unfamiliar with the boot code, and I
201 - 300 of 818 matches
Mail list logo
