> On Dec 9, 2019, at 1:08 PM, Paul Goyette wrote:
>
> On Mon, 9 Dec 2019, Andrew Doran wrote:
>
>> Module Name: src
>> Committed By:ad
>> Date:Mon Dec 9 21:05:23 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: kern_mutex.c
>>
>> Log Message:
>> - Add a mutex_own
On Mon, 9 Dec 2019, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Mon Dec 9 21:05:23 UTC 2019
Modified Files:
src/sys/kern: kern_mutex.c
Log Message:
- Add a mutex_owner_running() for the benefit of the pagedaemon, which
needs help with locking things in
On Sun, Dec 08, 2019 at 12:58:20PM +0100, Maxime Villard wrote:
> kMSan has special constraints which, in this specific case, come down to: each
> function called from a KCOV instrumentation callback must be a static inline
> tagged with __nomsan.
>
> This was not the case with the updated in_inte
Le 08/12/2019 à 00:51, Kamil Rytarowski a écrit :
On 08.12.2019 00:35, matthew green wrote:
Module Name:src
Committed By: kamil
Date: Sat Dec 7 19:50:34 UTC 2019
Modified Files:
src/sys/kern: subr_kcov.c
Log Message:
Revert the in_interrupt() change to use again the x8
On 08.12.2019 00:35, matthew green wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Dec 7 19:50:34 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: subr_kcov.c
>>
>> Log Message:
>> Revert the in_interrupt() change to use again the x86 specific code
>>
>> Th
> Module Name: src
> Committed By: kamil
> Date: Sat Dec 7 19:50:34 UTC 2019
>
> Modified Files:
> src/sys/kern: subr_kcov.c
>
> Log Message:
> Revert the in_interrupt() change to use again the x86 specific code
>
> This is prerequisite for kMSan and upcoming kernel changes.
>
>
Le 01/12/2019 à 16:27, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Sun Dec 1 15:27:58 UTC 2019
Modified Files:
src/sys/kern: kern_lwp.c
Log Message:
Fix a longstanding problem with LWP limits. When changing the user's
LWP count, we must use the proces
On 2019/11/30 23:35, Andrew Doran wrote:
Hmm, it works fine on amd64 and looks OK but me, but I have backed it out
for the time being.
Thanks! Also thank you for working on this area!
rin
Hi,
On Sat, Nov 30, 2019 at 04:52:38PM +0900, Rin Okuyama wrote:
> On 2019/11/30 5:50, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Fri Nov 29 20:50:54 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> >
> > Log Message:
On 2019/11/30 5:50, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Fri Nov 29 20:50:54 UTC 2019
Modified Files:
src/sys/kern: kern_rwlock.c
Log Message:
A couple more tweaks to avoid reading the lock word.
To generate a diff of this commit:
cvs rdiff -u -r1
On Nov 7, 6:08pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Please review:
|
| http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
|
| This patch works for me.
|
| Patch inspired by:
|
| Avoid misaligned access in disklabel(8) in find_label
On Thu, Nov 07, 2019 at 19:06:29 +0100, Martin Husemann wrote:
> OK, why is it 8 byte aligned? Checking
>
> > revision 1.108
> > date: 2011-01-18 20:52:24 +0100; author: matt; state: Exp; lines: +2 -1;
> > Make struct disklabel 8 byte aligned. This increases its size by 4 bytes
> > on IPL
On 07.11.2019 19:32, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 18:08:40 +0100, Kamil Rytarowski wrote:
>
>> On 07.11.2019 16:45, Kamil Rytarowski wrote:
>>> On 07.11.2019 16:26, Martin Husemann wrote:
On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> On 07.11.2019
On Thu, Nov 07, 2019 at 18:08:40 +0100, Kamil Rytarowski wrote:
> On 07.11.2019 16:45, Kamil Rytarowski wrote:
> > On 07.11.2019 16:26, Martin Husemann wrote:
> >> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> >>> On 07.11.2019 14:25, Valery Ushakov wrote:
> If the sanit
On Thu, Nov 07, 2019 at 06:46:48PM +0100, Kamil Rytarowski wrote:
> member access within misaligned address 0x942d3de8c03c for type
> 'const struct disklabel' which requires 8 byte alignment
OK, why is it 8 byte aligned? Checking
> revision 1.108
> date: 2011-01-18 20:52:24 +0100; author
On 07.11.2019 18:20, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 06:08:40PM +0100, Kamil Rytarowski wrote:
>> Please review:
>>
>> http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
>>
>> This patch works for me.
>
> Yes, I believe that it does - but why is it needed?
>
syzbot rep
On Thu, Nov 07, 2019 at 06:08:40PM +0100, Kamil Rytarowski wrote:
> Please review:
>
> http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
>
> This patch works for me.
Yes, I believe that it does - but why is it needed?
dlp = (void *)a->bp->b_data;
Here we can assume that b_da
On 07.11.2019 16:45, Kamil Rytarowski wrote:
> On 07.11.2019 16:26, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
>>> On 07.11.2019 14:25, Valery Ushakov wrote:
If the sanitizer does complain about other uses, there is little point
in fixing o
David Young wrote in <20191107155806.gl1...@pobox.com>:
|On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
|> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
|>> On 07.11.2019 14:25, Valery Ushakov wrote:
..
|I think the problem is that if you have the series o
On 07.11.2019 17:20, Kamil Rytarowski wrote:
> On 07.11.2019 17:08, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>>> 6.3.2.1 C11
>>>
>>> 'An lvalue is an expression (with an object type other than void) that
>>> potentially designates an object'
>>>
>>
On Thu, Nov 07, 2019 at 09:58:06 -0600, David Young wrote:
> On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
> > On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> > > On 07.11.2019 14:25, Valery Ushakov wrote:
> > > > If the sanitizer does complain about other us
On 07.11.2019 17:09, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 09:58:06AM -0600, David Young wrote:
>> I think the problem is that if you have the series of statements,
>>
>> element_t *e = &s->element;
>>
>> if (s == NULL)
>> return;
>
> Note that this examp
On 07.11.2019 17:08, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>> 6.3.2.1 C11
>>
>> 'An lvalue is an expression (with an object type other than void) that
>> potentially designates an object'
>>
>> This means that real dereference is not needed, only
On Thu, Nov 07, 2019 at 09:58:06AM -0600, David Young wrote:
> I think the problem is that if you have the series of statements,
>
> element_t *e = &s->element;
>
> if (s == NULL)
> return;
Note that this example has *nothing* in common with Kamil's code change.
H
On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
> 6.3.2.1 C11
>
> 'An lvalue is an expression (with an object type other than void) that
> potentially designates an object'
>
> This means that real dereference is not needed, only a potential. And
> there are special cases of poi
On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> > On 07.11.2019 14:25, Valery Ushakov wrote:
> > > If the sanitizer does complain about other uses, there is little point
> > > in fixing one instance and not the o
On 07.11.2019 16:49, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:45:31PM +0100, Kamil Rytarowski wrote:
>> Unfortunately the C committee went into the opposite direction here and
>> specified a potential dereference.
>
> Where?
>
> Martin
>
6.3.2.1 C99
"An lvalue is an expression with
On Thu, Nov 07, 2019 at 04:45:31PM +0100, Kamil Rytarowski wrote:
> Unfortunately the C committee went into the opposite direction here and
> specified a potential dereference.
Where?
Martin
On 07.11.2019 16:26, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
>> On 07.11.2019 14:25, Valery Ushakov wrote:
>>> If the sanitizer does complain about other uses, there is little point
>>> in fixing one instance and not the others.
>>
>> We already ag
On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> On 07.11.2019 14:25, Valery Ushakov wrote:
> > If the sanitizer does complain about other uses, there is little point
> > in fixing one instance and not the others.
>
> We already agreed with Christos that this is appeasing of GCC
On 07.11.2019 14:25, Valery Ushakov wrote:
> If the sanitizer does complain about other uses, there is little point
> in fixing one instance and not the others.
We already agreed with Christos that this is appeasing of GCC. If you
want to scan the whole kernel (or whole C) file for more occurrence
On Thu, Nov 07, 2019 at 15:48:55 +0300, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
>
> > On 07.11.2019 13:17, Valery Ushakov wrote:
> > > On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
> > >
> > >> I have checked received the followin
On Thu, Nov 07, 2019 at 13:59:37 +0100, Kamil Rytarowski wrote:
> On 07.11.2019 13:48, Valery Ushakov wrote:
> > On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
> >
> >> On 07.11.2019 13:17, Valery Ushakov wrote:
> >>> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote
On 07.11.2019 13:48, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
>
>> On 07.11.2019 13:17, Valery Ushakov wrote:
>>> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
>>> As a side note - the C99 standard contains "derefer" exactly once, in
On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
> On 07.11.2019 13:17, Valery Ushakov wrote:
> > On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
> >
> >> I have checked received the following patch and received a feedback from
> >> a LLVM developer.
> >>
> >> On 07
On 07.11.2019 13:17, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
>
>> I have checked received the following patch and received a feedback from
>> a LLVM developer.
>>
>> On 07.11.2019 05:47, 'Dmitry Vyukov' via syzkaller-netbsd-bugs wrote:
>>> I've consu
On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
> I have checked received the following patch and received a feedback from
> a LLVM developer.
>
> On 07.11.2019 05:47, 'Dmitry Vyukov' via syzkaller-netbsd-bugs wrote:
> > I've consulted with some people and _presumably_ (to the deg
On 07.11.2019 11:53, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 11:46:47AM +0100, Kamil Rytarowski wrote:
>> Please see my newer mail with rationale and another one with a
>> confirmation that this was real UB.
>
> Confirmation? The dereference in this case happens in memcmp()
> only, so wha
On Thu, Nov 07, 2019 at 11:46:47AM +0100, Kamil Rytarowski wrote:
> Please see my newer mail with rationale and another one with a
> confirmation that this was real UB.
Confirmation? The dereference in this case happens in memcmp()
only, so what misalignment could there be?
Martin
On 07.11.2019 07:25, Martin Husemann wrote:
> On Wed, Nov 06, 2019 at 11:17:23PM +0100, Kamil Rytarowski wrote:
>> Technically, I think that this is a real UB.
>>
>> 6.3.2.3/7
>> A pointer to an object type may be converted to a pointer to a
>> different object type. If the resulting pointer is not
On Wed, Nov 06, 2019 at 11:17:23PM +0100, Kamil Rytarowski wrote:
> Technically, I think that this is a real UB.
>
> 6.3.2.3/7
> A pointer to an object type may be converted to a pointer to a
> different object type. If the resulting pointer is not correctly
> aligned for the referenced type, the
/managers/netbsd-kubsan/kernel/sys/kern/vfs_subr.c:793:14,
member access within null pointer of type 'struct vnode_impl'
On 07.11.2019 00:03, Kamil Rytarowski wrote:
> On 06.11.2019 23:38, Christos Zoulas wrote:
>> On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
>> --
On 06.11.2019 23:38, Christos Zoulas wrote:
> On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/sys/kern
>
> | Technically, I think that this is a real UB.
> |
> | 6.3.2.3/7
> | A pointer to an object type may be converted to a point
On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Technically, I think that this is a real UB.
|
| 6.3.2.3/7
| A pointer to an object type may be converted to a pointer to a
| different object type. If the resulting pointer is not correctly
On 06.11.2019 22:43, Christos Zoulas wrote:
> In article <20191106130732.c6c5af...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Wed Nov 6 13:07:32 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: subr_di
In article <20191106130732.c6c5af...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Wed Nov 6 13:07:32 UTC 2019
>
>Modified Files:
> src/sys/kern: subr_disk_mbr.c
>
>Log Message:
>Avoid unaligned pointer arithmetic in check_
On Mon, Oct 14, 2019 at 04:27:04PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Mon Oct 14 16:27:04 UTC 2019
>
> Modified Files:
> src/sys/kern: uipc_socket.c
>
> Log Message:
> Add a check before the memcpy. memcpy is defined to never take NULL as
>
Le 30/09/2019 à 20:51, Nick Hudson a écrit :
On 30 Sep 2019, at 18:06, Tobias Nygren wrote:
On Mon, 23 Sep 2019 05:39:59 +
Nick Hudson wrote:
Modified Files:
src/sys/kern: subr_pool.c
Log Message:
Enable POOL_REDZONE with DIAGNOSTIC.
The bug in the arm pmap was fixed long ago.
T
On Sun, Oct 06, 2019 at 08:41:35AM +0200, Maxime Villard wrote:
> Le 01/10/2019 à 18:36, Chuck Silvers a écrit :
> > Module Name:src
> > Committed By: chs
> > Date: Tue Oct 1 16:36:58 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: sysv_shm.c
> >
> > Log Messag
Le 01/10/2019 à 18:36, Chuck Silvers a écrit :
Module Name:src
Committed By: chs
Date: Tue Oct 1 16:36:58 UTC 2019
Modified Files:
src/sys/kern: sysv_shm.c
Log Message:
in shmdt(), wait until shmat() completes before detaching.
Reported-by: syzbot+8f470a1bf36b47ae0...@
Sent from my iPhone
> On 30 Sep 2019, at 18:06, Tobias Nygren wrote:
>
> On Mon, 23 Sep 2019 05:39:59 +
> Nick Hudson wrote:
>
>> Modified Files:
>>src/sys/kern: subr_pool.c
>>
>> Log Message:
>> Enable POOL_REDZONE with DIAGNOSTIC.
>>
>> The bug in the arm pmap was fixed long ag
On Mon, 23 Sep 2019 05:39:59 +
Nick Hudson wrote:
> Modified Files:
> src/sys/kern: subr_pool.c
>
> Log Message:
> Enable POOL_REDZONE with DIAGNOSTIC.
>
> The bug in the arm pmap was fixed long ago.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.258 -r1.259 src/sys/ker
I was thinking of doing that too. The problem is that we don't have a standard
way to pass feedback to the user why the mount fail, and returning EINVAL seems
suboptimal. It also changes the current semantics.
christos
> On Aug 19, 2019, at 6:35 PM, Robert Elz wrote:
>
>Date:Mon,
Date:Mon, 19 Aug 2019 05:32:42 -0400
From:"Christos Zoulas"
Message-ID: <20190819093242.88152f...@cvs.netbsd.org>
| Log Message:
| If we could not start extattr for some reason, don't advertise extattr
| in the mount.
I would have expected a better result would
On 16/08/2019 09:21, Maxime Villard wrote:
Le 16/08/2019 à 07:46, Nick Hudson a écrit :
yet? Can 32bit platforms and limit KVA have KASAN?
If you are telling me they could reliably use KMEM_GUARD before, then it
likely means they can have KASAN. If you want to add KASAN to more arches,
feel
On Fri, Aug 16, 2019 at 08:05:01AM +1000, matthew green wrote:
> "Maxime Villard" writes:
> > Module Name:src
> > Committed By: maxv
> > Date: Thu Aug 15 12:06:42 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: subr_kmem.c
> >
> > Log Message:
> > Retire KMEM_GU
Le 16/08/2019 à 00:05, matthew green a écrit :
KMEM_GUARD is useful for platforms that don't have kasan yet.
Verily it was not.
1) The place where diagnostic/debug features should be implemented is pool(9),
not kmem(9). Pools represent all of the dynamic system memory, kmem only a
sma
On 15/08/2019 23:05, matthew green wrote:
"Maxime Villard" writes:
Module Name:src
Committed By: maxv
Date: Thu Aug 15 12:06:42 UTC 2019
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Retire KMEM_GUARD. It has been superseded by kASan, which is much more
powerfu
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Thu Aug 15 12:06:42 UTC 2019
>
> Modified Files:
> src/sys/kern: subr_kmem.c
>
> Log Message:
> Retire KMEM_GUARD. It has been superseded by kASan, which is much more
> powerful, has much more coverage - far b
> On Jun 29, 2019, at 2:29 AM, Maxime Villard wrote:
[...]
> Ah because now I should teach people C programming?
No, but you should be helpful and assume that the people working on this
project are not trying to annoy you or ignore you. If would have been
better to explain what the bugs are, in
Le 29/06/2019 à 02:12, Hisashi T Fujinaka a écrit :
On Thu, 27 Jun 2019, Maxime Villard wrote:
Le 27/06/2019 ? 20:56, Christos Zoulas a ?crit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 ? 19:07, Christos Zoulas a
On Thu, 27 Jun 2019, Maxime Villard wrote:
Le 27/06/2019 ? 20:56, Christos Zoulas a ?crit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 ? 19:07, Christos Zoulas a ??crit? :
| > Module Name: src
| > Commit
On Fri, Jun 28, 2019 at 06:43:45AM +1000, matthew green wrote:
> "Maxime Villard" writes:
> > Module Name:src
> > Committed By: maxv
> > Date: Thu Jun 27 19:56:10 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_exec.c
> >
> > Log Message:
> > Fix this fucki
Le 27/06/2019 à 20:56, Christos Zoulas a écrit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
| > Module Name: src
| > Committed By:christos
| > Date:Thu
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Thu Jun 27 19:56:10 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_exec.c
>
> Log Message:
> Fix this fucking shit once and for all, for fuck's sake.
this is unacceptable behaviour.
please stop being so
Le 27/06/2019 à 21:56, Maxime Villard a écrit :
Module Name:src
Committed By: maxv
Date: Thu Jun 27 19:56:10 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Fix this fucking shit once and for all, for fuck's sake.
To generate a diff of this commit:
cvs
In article <20190627195610.c4be7f...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Thu Jun 27 19:56:10 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_exec.c
>
>Log Message:
>Fix this fucking shit once and for all, for fuck's
On Jun 27, 9:26pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| > I don't know, is this the most efficient way to communicate it if I did?
|
| This got to be a fucking joke.
Well, you know the bug, and I think it is more valuable for me to
sp
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
| > Module Name:src
| > Committed By: christos
| > Date: Thu Jun 27 17:07:51 UTC 2019
| >
| >
Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Jun 27 17:07:51 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Return an error if the path was too long. Pointed out by maxv
To generate a diff of this co
Le 26/06/2019 à 23:21, Christos Zoulas a écrit :
In article <20190626202859.b5ccef...@cvs.netbsd.org>,
Maxime Villard wrote:
-=-=-=-=-=-
Module Name:src
Committed By: maxv
Date: Wed Jun 26 20:28:59 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Remove
On Jun 27, 6:59pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Yet it seems pretty obvious to me. As you explained in the comment, the
| function is supposed to return an absolute path. Here, however, it does
| not return an absolute path:
|
| if
Le 26/06/2019 à 22:33, Christos Zoulas a écrit :
On Jun 26, 10:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
| > Module Name: src
| > Committed By:christos
| > Date:Tue
On 26.06.2019 23:21, Christos Zoulas wrote:
> In article <20190626202859.b5ccef...@cvs.netbsd.org>,
> Maxime Villard wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:maxv
>> Date:Wed Jun 26 20:28:59 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: kern_exec.
In article <20190626202859.b5ccef...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Wed Jun 26 20:28:59 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_exec.c
>
>Log Message:
>Remove useless debugging messages which achieved no
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Jun 26 20:28:59 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_exec.c
>
> Log Message:
> Remove useless debugging messages which achieved nothing but hiding bugs.
considering the author of these change
On Jun 26, 10:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
| > Module Name:src
| > Committed By: christos
| > Date: Tue Jun 25 21:32:58 UTC 2019
| >
| >
Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Jun 25 21:32:58 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Fail if getcwd fails. Pointed out by maxv@
To generate a diff of this commit:
cvs rdiff -u
Le 25/06/2019 à 20:06, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Jun 25 18:06:29 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
add a comment explaining what this does.
To generate a diff of this commit:
cvs rdiff -u -r
On Tue, May 07, 2019 at 09:22:49AM +0800, Paul Goyette wrote:
> Currently we have the global sysctl variable, but I wonder if it should be
> made local to a particular emulation and/or to an individual process?
It's a global flag because it has security impliciations. Making it
per-emulation or ev
I hope the slop makes everyone happy :-)
christos
Date:Wed, 08 May 2019 06:54:04 +1000
From:matthew green
Message-ID: <7543.1557262...@splode.eterna.com.au>
| > Log Message:
| > Use the max limit (aka maxfiles or the moral equivalent of OPEN_MAX) which
| > makes poll(2) align with the Posix documentation (which
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue May 7 20:10:21 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_select.c
>
> Log Message:
> Use the max limit (aka maxfiles or the moral equivalent of OPEN_MAX) which
> makes poll(2) align with the P
On 07.05.2019 03:22, Paul Goyette wrote:
> Just a thought
>
> Currently we have the global sysctl variable, but I wonder if it should
> be made local to a particular emulation and/or to an individual process?
>
I think it would be too much.
We already warn a user with ttyprintf(9) once it's
Just a thought
Currently we have the global sysctl variable, but I wonder if it should
be made local to a particular emulation and/or to an individual process?
On Tue, 7 May 2019, Kamil Rytarowski wrote:
On 07.05.2019 02:49, matthew green wrote:
I see. I will document in the man page th
On 07.05.2019 02:49, matthew green wrote:
>> I see. I will document in the man page that (void *)0 and (void *)1 are
>> special cases and they have to be set with PTRACE_REG_SET_PC()
>> explicitly if really intended.
>>
>> Keeping allowed 0x0 in PT_CONTINUE/PT_DETACH/.. makes it harder to
>> distin
> I see. I will document in the man page that (void *)0 and (void *)1 are
> special cases and they have to be set with PTRACE_REG_SET_PC()
> explicitly if really intended.
>
> Keeping allowed 0x0 in PT_CONTINUE/PT_DETACH/.. makes it harder to
> distinguish between broken kernel and broken program.
On 06.05.2019 22:59, Joerg Sonnenberger wrote:
> On Thu, May 02, 2019 at 03:01:31AM +0200, Kamil Rytarowski wrote:
>> We forbid NULL pointer dereference on modern ports. It was certainly
>> used by PDP-11 as there was a special zeroed mask in 0x0 and
>> dereferencing NULL pointer was returning zero
On Thu, May 02, 2019 at 03:01:31AM +0200, Kamil Rytarowski wrote:
> We forbid NULL pointer dereference on modern ports. It was certainly
> used by PDP-11 as there was a special zeroed mask in 0x0 and
> dereferencing NULL pointer was returning zero.
No, we forbid NULL pointer dereferences on shared
That's a good point. Should I revert to something similar like before,
or do you have a better idea?
Thanks,
christos
> On May 5, 2019, at 9:09 PM, Robert Elz wrote:
>
>Date:Sun, 5 May 2019 16:38:04 -0400
>From:Christos Zoulas
>Message-ID: <41fb59a5-c9e0-4392-bd5c
Date:Sun, 5 May 2019 16:38:04 -0400
From:Christos Zoulas
Message-ID: <41fb59a5-c9e0-4392-bd5c-508e5b80e...@zoulas.com>
| I did not want to make it smaller, but yes,
| you are right I will remove the slop.
|
| > On May 5, 2019, at 4:30 PM, matthew green wrote:
I did not want to make it smaller, but yes, you are right I will remove the
slop.
christos
> On May 5, 2019, at 4:30 PM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat May 4 15:46:58 UTC 2019
>>
>> Modified
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat May 4 15:46:58 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_select.c
>
> Log Message:
> PR/54158: Anthony Mallet: poll(2) does not allow polling all possible fds
> (hardcoded limit to 1000 + #).
On 02.05.2019 02:48, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Wed May 1 17:02:40 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: sys_ptrace_common.c
>>
>> Log Message:
>> Disallow resuming program with PC=0x0 i
"Kamil Rytarowski" writes:
> Module Name: src
> Committed By: kamil
> Date: Wed May 1 17:02:40 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_ptrace_common.c
>
> Log Message:
> Disallow resuming program with PC=0x0 in ptrace(2)
>
> If the address parameter is 0, report error.
>
Date:Thu, 28 Mar 2019 18:12:24 +
From:"Maxime Villard"
Message-ID: <20190328181224.bd6b4f...@cvs.netbsd.org>
| Log Message:
| Move pnbuf_cache into vfs_init.c, where it belongs.
That causes:
/tmp/bracket/build/2019.03.28.18.12.24-i386/tools/bin/i486--netbsde
Hi,
Running Linux binaries on amd64 hits this KASSERT:
sys/kern/vfs_lookup.c
https://nxr.netbsd.org/xref/src/sys/kern/vfs_lookup.c#592
585 /*
586 * Get a reference to the start dir so we can safely unlock
cwdi.
587 *
588 * Must hold references
In article <20190314195150.27756f...@cvs.netbsd.org>,
Palle Lyckegaard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: palle
>Date: Thu Mar 14 19:51:50 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_scdebug.c
>
>Log Message:
>syscall debug - fix build when SYSCALL_DEBUG
On Fri, Jan 11, 2019 at 08:22:23PM +0100, Christoph Badura wrote:
>
> What exactly did your change do to improve the awareness of these side
> effects? I'm at a loss when it comes to that.
You noticed that some side effects were already removed.
> Here's more defects and functionality changes:
On Fri, Jan 11, 2019 at 12:41:36AM +0100, Michael van Elst wrote:
> On Thu, Jan 10, 2019 at 05:50:30PM +0100, Christoph Badura wrote:
> >
> > If you hadn't reversed the order of
> >
> > tftproot_dhcpboot()
> > if (md_is_root) ...
> > rootspec = bootspec
> >
> > that would wouldn't have need fixi
101 - 200 of 685 matches
Mail list logo
