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
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
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
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
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
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,
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
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
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
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
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
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
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:
>> -- Subject: Re: CVS commit: src/sys/kern
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:
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
On 2019/11/04 20:20, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Nov 4 11:20:22 UTC 2019
Modified Files:
src/sys/compat/netbsd32: syscalls.master
Log Message:
For netbsd32_readlinkat(2), bufsize is netbsd_size_t, not size_t.
Since bufsize is the last
On Thu, Oct 31, 2019 at 11:59:40AM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Thu Oct 31 11:59:40 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_urndis.c
>
> Log Message:
> check if buf/bufsz are non-NULL before freeing.
>
> not all control
On 22.10.2019 14:09, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Oct 22 12:09:11 UTC 2019
>
> Modified Files:
> src/sys/dev/ic: wdc.c
>
> Log Message:
> Fix channel locking - patch from Christos.
>
>
> #include
> -__KERNEL_RCSID(0, "$NetBSD:
Tobias Nygren writes:
> Yep, MSI works now. According to the PCI Express Base Specification,
> Revision 3.0, table 7-3, having the bus master bit set to 0 disables
> MSI. Asmedia chip seems to have a bug which makes DMA work regardless ...
Yup - it works just fine! Well done! :)
ahcisata0:
On Fri, 18 Oct 2019 20:32:53 +0200
Tom Ivar Helbekkmo wrote:
> Tobias Nygren writes:
>
> > Module Name:src
> > Committed By: tnn
> > Date: Fri Oct 18 17:16:50 UTC 2019
> >
> > Modified Files:
> > src/sys/dev/pci: ahcisata_pci.c
> >
> > Log Message:
> > ahcisata:
Tobias Nygren writes:
> Module Name: src
> Committed By: tnn
> Date: Fri Oct 18 17:16:50 UTC 2019
>
> Modified Files:
> src/sys/dev/pci: ahcisata_pci.c
>
> Log Message:
> ahcisata: make sure bus mastering and memory space are actually enabled
>
> This makes the "ROCKPro64 PCI-e to
This change causes evbarm/aarch64 to hang early on an Allwinner
A64-based Pinebook.
On Tue, Oct 15, 2019 at 05:25:02PM +, Christoph Badura wrote:
> Module Name: src
> Committed By: bad
> Date: Tue Oct 15 17:25:02 UTC 2019
>
> Modified Files:
> src/sys/arch/arm/fdt: cpu_fdt.c
>
On Oct 16, 6:32pm, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: CVS commit: src/sys
| On Wed, Oct 16, 2019 at 11:27:39 -0400, Christos Zoulas wrote:
|
| > Module Name:src
| > Committed By: christos
| > Date: Wed Oct 16 15:27:39
On Wed, Oct 16, 2019 at 11:27:39 -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Oct 16 15:27:39 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_core.c kern_hook.c kern_sig.c kern_veriexec.c
> subr_ipi.c subr_pool.c subr_vmem.c
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
On 11/10/2019 22:56, Michael Lorenz wrote:
> first step to address PR2231
PR22316
http://gnats.netbsd.org/22316
Sevan
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.
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
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:
On Fri, Oct 04, 2019 at 04:57:51 +0200, Kamil Rytarowski wrote:
> At least in certain domains of engineering 0 is a special case as it
> does not need unit (km, lumen, kg, ...) neither base (hex, dec, ..).
>
> It is natural (correct, expected) to print %#x for 0 as 0, without 0x.
I'm happy for
On Thu, Oct 03, 2019 at 22:09:28 -0400, Christos Zoulas wrote:
> Thanks, and zero is special for 0#. Should I revert it?
Yes, please.
> > On Oct 3, 2019, at 10:06 PM, Valery Ushakov wrote:
> >
> >
> >> Modified Files:
> >>src/sys/arch/acorn32/acorn32: rpc_machdep.c
> >>
> >> Log
At least in certain domains of engineering 0 is a special case as it
does not need unit (km, lumen, kg, ...) neither base (hex, dec, ..).
It is natural (correct, expected) to print %#x for 0 as 0, without 0x.
On 04.10.2019 04:09, Christos Zoulas wrote:
> Thanks, and zero is special for 0#.
Thanks, and zero is special for 0#. Should I revert it?
christos
> On Oct 3, 2019, at 10:06 PM, Valery Ushakov wrote:
>
>
>> Modified Files:
>> src/sys/arch/acorn32/acorn32: rpc_machdep.c
>>
>> Log Message:
>> change 0x% -> %x
>
> This should read %#x.
> And this is wrong.
>
> 1) With
> Modified Files:
> src/sys/arch/acorn32/acorn32: rpc_machdep.c
>
> Log Message:
> change 0x% -> %x
This should read %#x.
And this is wrong.
1) With # the 0x is part of the width, so
0x%08x -> 0x0001
%#08x -> 0x01
0x 0x0001
0x01
2) # doesn't add
On Wed, Oct 02, 2019 at 03:44:21AM +, Constantine A. Murenin wrote:
> I'm getting a page fault trap after this patch, at netbsd:dk_open(), in
> VirtualBox 6.0.12 r133076 with an empty NVME controller.
There is a bug in dk_open when attachment didn't complete yet or failed.
I'm about to fix
I'm getting a page fault trap after this patch, at netbsd:dk_open(),
in VirtualBox 6.0.12 r133076 with an empty NVME controller.
C.
On 2019-W40-2 10:59 +, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Tue Oct 1 10:59:50 UTC 2019
Modified Files:
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
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
On Mon, Sep 23, 2019 at 4:14 PM Kamil Rytarowski wrote:
>
> On 23.09.2019 06:53, Rin Okuyama wrote:
> > Hi,
> >
> > On 2019/09/22 18:30, Kamil Rytarowski wrote:
> >> On 12.04.2018 06:38, Ryota Ozaki wrote:
> >>> Module Name:src
> >>> Committed By:ozaki-r
> >>> Date:Thu Apr 12
On 23.09.2019 06:53, Rin Okuyama wrote:
> Hi,
>
> On 2019/09/22 18:30, Kamil Rytarowski wrote:
>> On 12.04.2018 06:38, Ryota Ozaki wrote:
>>> Module Name: src
>>> Committed By: ozaki-r
>>> Date: Thu Apr 12 04:38:13 UTC 2018
>>>
>>> Modified Files:
>>> src/sys/net: if.h route.c
Hi,
On 2019/09/22 18:30, Kamil Rytarowski wrote:
On 12.04.2018 06:38, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Thu Apr 12 04:38:13 UTC 2018
Modified Files:
src/sys/net: if.h route.c route.h rtsock.c
Log Message:
Resolve tangled lock dependencies
Date:Sun, 22 Sep 2019 07:23:00 +0100
From:Nick Hudson
Message-ID: <793d2380-8d1a-78ab-3682-0468aea0d...@gmx.co.uk>
| I was merely pointing out that it exists already.
Understood, and thanks - at a minimum that will avoid adding
it with a different name.
| I'm
On 12.04.2018 06:38, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Thu Apr 12 04:38:13 UTC 2018
>
> Modified Files:
> src/sys/net: if.h route.c route.h rtsock.c
>
> Log Message:
> Resolve tangled lock dependencies in route.c
>
> This change sweeps
On 21/09/2019 20:19, Robert Elz wrote:
Date:Sun, 22 Sep 2019 01:23:41 +0700
From:Robert Elz
Message-ID: <8235.1569090...@jinx.noi.kre.to>
| we'd need it in all the other ports before it can be used in MD code.
I meant MI code of course...
Sure. I was
Date:Sun, 22 Sep 2019 01:23:41 +0700
From:Robert Elz
Message-ID: <8235.1569090...@jinx.noi.kre.to>
| we'd need it in all the other ports before it can be used in MD code.
I meant MI code of course...
kre
Date:Sat, 21 Sep 2019 19:06:15 +0100
From:Nick Hudson
Message-ID:
|
http://src.illumos.org/source/search?q=PRIxBUSADDR=PRIxBUSADDRnetbsd-src
That shows that mips and arm have PRIxBUSADDR - we'd need it in all the
other ports before it can be used in MD code.
On 21/09/2019 17:26, Jason Thorpe wrote:
> Should we make a PRIxxx macro for it?
>
> -- thorpej
> Sent from my iPhone.
>
>> On Sep 21, 2019, at 5:57 AM, Robert Elz wrote:
>>
>> Module Name:src
>> Committed By:kre
>> Date:Sat Sep 21 12:57:25 UTC 2019
>>
>> Modified Files:
>>
Date:Sat, 21 Sep 2019 09:26:21 -0700
From:Jason Thorpe
Message-ID:
| Should we make a PRIxxx macro for it?
[since I deleted the context: "it" is bus_addr_t]
Perhaps, for this particular case it doesn't really matter, but if
code is likely to be printing
Should we make a PRIxxx macro for it?
-- thorpej
Sent from my iPhone.
> On Sep 21, 2019, at 5:57 AM, Robert Elz wrote:
>
> Module Name:src
> Committed By:kre
> Date:Sat Sep 21 12:57:25 UTC 2019
>
> Modified Files:
>src/sys/dev/ic: mpt.c
>
> Log Message:
> bus_addt_t is
On 19.09.2019 16:35, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Thu Sep 19 14:35:00 UTC 2019
>
> Modified Files:
> src/sys/crypto/nist_hash_drbg: nist_hash_drbg.c
>
> Log Message:
> Use CTASSERT where possible, run-time assertion where not.
>
>
On 18.09.2019 21:02, Kamil Rytarowski wrote:
> On 02.09.2019 22:09, Taylor R Campbell wrote:
>> Module Name: src
>> Committed By:riastradh
>> Date:Mon Sep 2 20:09:30 UTC 2019
>>
>> Modified Files:
>> src/sys/conf: files
>> src/sys/dev: rndpseudo.c
>>
On 02.09.2019 22:09, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Mon Sep 2 20:09:30 UTC 2019
>
> Modified Files:
> src/sys/conf: files
> src/sys/dev: rndpseudo.c
> src/sys/kern: subr_cprng.c
> src/sys/rump/kern/lib/libcrypto:
Le 15/09/2019 à 23:00, Manuel Bouyer a écrit :
Module Name:src
Committed By: bouyer
Date: Sun Sep 15 21:00:16 UTC 2019
Modified Files:
src/sys/netinet: ip_input.c
src/sys/netinet6: ip6_input.c
Log Message:
Packet filters can return an mbuf chain with fragmented
In article <20190911145625.450a3f...@cvs.netbsd.org>,
Christos Zoulas wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: christos
>Date: Wed Sep 11 14:56:25 UTC 2019
>
>Modified Files:
> src/sys/sys: atomic.h
>
>Log Message:
>Be consistent about semicolons in macros:
On 05.09.2019 14:57, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Sep 5 12:57:30 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: lock_stubs.S
>
> Log Message:
> Remove unused, and style.
>
>
> To generate a diff of this commit:
> cvs rdiff
In article <19990.1566969...@splode.eterna.com.au>,
matthew green wrote:
>> src/sys/kern: vfs_bio.c
>> src/sys/sys: buf.h
>>
>> Log Message:
>> Change buf_nbuf()'s return value from int to u_int to avoid undefined
>> behavior in wapbl_start() which extended int to size_t.
>>
>>
> src/sys/kern: vfs_bio.c
> src/sys/sys: buf.h
>
> Log Message:
> Change buf_nbuf()'s return value from int to u_int to avoid undefined
> behavior in wapbl_start() which extended int to size_t.
>
> Error message was:
> > UBSan: Undefined Behavior in
On Wed, 28 Aug 2019, Roy Marples wrote:
On 27/08/2019 22:17, Hisashi T Fujinaka wrote:
Is this necessary for -9 too?
Pretty much every BSD with IPv6.
I'll submit a PR for -9 in day or so.
I need to work this and a few other recent changes for -8 and maybe -7 also.
Cool. Thanks for all the
On 27/08/2019 22:17, Hisashi T Fujinaka wrote:
Is this necessary for -9 too?
Pretty much every BSD with IPv6.
I'll submit a PR for -9 in day or so.
I need to work this and a few other recent changes for -8 and maybe -7 also.
Roy
Is this necessary for -9 too?
On Tue, 27 Aug 2019, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Tue Aug 27 21:11:26 UTC 2019
Modified Files:
src/sys/netinet6: nd6.c
Log Message:
inet6: nd6_free assumes all routers are processed by kernel RA
This hasn't
Le 21/08/2019 à 23:47, matthew green a écrit :
"Maxime Villard" writes:
Module Name:src
Committed By: maxv
Date: Wed Aug 21 16:35:10 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Switch from printf to panic. These messages were notorious for
> To generate a diff of this commit:
> cvs rdiff -u -r1.118 -r1.119 src/sys/dev/usb/if_axe.c
FYI: this change included a fix for two problems identified by sc.debug.
Thanks for the quick review! The errors below should be all fixed.
christos
> On Aug 20, 2019, at 3:18 PM, Maxime Villard wrote:
>
> 1) In compat_drm_agp_info(), seems like it should be info64to32.
>
> 2) In compat_drm_getstats(), the assignments in the loop are inverted, it's
> st32 which
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Aug 21 16:35:10 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
> Log Message:
> Switch from printf to panic. These messages were notorious for being
> unreadable, and at least a clean
On 07.08.2019 08:28, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Wed Aug 7 06:28:03 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> Sync with reality.
>
>
Can we enable USER_LDT by default in GENERIC?
> To generate
Le 20/08/2019 à 11:32, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Aug 20 09:32:21 UTC 2019
Modified Files:
src/sys/compat/netbsd32: files.netbsd32 netbsd32_ioctl.c
netbsd32_ioctl.h
Added Files:
src/sys/compat/netbsd32:
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
Hi,
On 2019/08/19 14:25, Kengo NAKAHARA wrote:
Module Name:src
Committed By: knakahara
Date: Mon Aug 19 05:25:38 UTC 2019
Modified Files:
src/sys/arch/x86/pci: if_vmx.c
Log Message:
add vmx(4) basic statistics counters.
Sorry, I have forgotten this TODO in r1.40
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,
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
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
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
"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
On Sun, Aug 11, 2019 at 03:46:02PM +0200, Kamil Rytarowski wrote:
> Not usable in C++, we shipped with patches in 3rd party code.
Patches in 3rd party code means to me: the system header is usable
(but maybe awkward).
Martin
On 11.08.2019 09:17, Martin Husemann wrote:
> On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
>>> can we go back to the drawing board on this one and discuss the original
>>> problem?
>>>
>>
>> C++ and cast rules.
>
> The question is whether we really should play this game in
In article <20190810203301.be06bf...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Aug 10 20:33:01 UTC 2019
>
>Modified Files:
> src/sys/sys: event.h
>
>Log Message:
>Use common macro for _EV_SET() for integer types
>
On Sun, Aug 11, 2019 at 09:17:05AM +0200, Martin Husemann wrote:
> On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
> > > can we go back to the drawing board on this one and discuss the original
> > > problem?
> > >
> >
> > C++ and cast rules.
>
> The question is whether we
On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
> > can we go back to the drawing board on this one and discuss the original
> > problem?
> >
>
> C++ and cast rules.
The question is whether we really should play this game in our system headers.
The original state was usable in
On 10.08.2019 22:37, m...@netbsd.org wrote:
> On Sat, Aug 10, 2019 at 08:33:01PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Aug 10 20:33:01 UTC 2019
>>
>> Modified Files:
>> src/sys/sys: event.h
>>
>> Log Message:
>> Use common
On Sat, Aug 10, 2019 at 08:33:01PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Aug 10 20:33:01 UTC 2019
>
> Modified Files:
> src/sys/sys: event.h
>
> Log Message:
> Use common macro for _EV_SET() for integer types
>
> Deduplicate code.
>
Dear Ryo,
On 2019-07-26, Ryo ONODERA wrote:
> Hi,
>
> O.k.
> I will commit your fix later.
>
> Thank you.
Thanks! I can commit again, and I commited this change.
Please let me know if I broke anything!
(src/sys/dev/usb/ums.c v1.94)
> Yorick Hardy writes:
>
> > Dear Ryo,
> >
> > On
On 08/08/2019 23:32, sc dying wrote:
On Wed, Aug 7, 2019 at 7:06 AM Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Aug 7 07:05:54 UTC 2019
Modified Files:
src/sys/dev/usb: if_smsc.c
Removed Files:
src/sys/dev/usb: if_smscvar.h
Log
On Wed, Aug 7, 2019 at 7:06 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Aug 7 07:05:54 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_smsc.c
> Removed Files:
> src/sys/dev/usb: if_smscvar.h
>
> Log Message:
> Convert smsc(4) to
Le 06/08/2019 à 12:31, Christos Zoulas a écrit :
I did not see any messages about it, and the fix is fine until rmind comes up
with something better.
Yes turns out it was an off-list email
It is not nice to have HEAD unusable for 2 weeks now (since July 22nd).
Given your second commit, I
Yes, rmind asked me to commit the change in private email.
christos
> On Aug 6, 2019, at 3:59 PM, Maxime Villard wrote:
>
> Le 06/08/2019 à 12:31, Christos Zoulas a écrit :
>> I did not see any messages about it, and the fix is fine until rmind comes
>> up with something better.
>
> Yes
I did not see any messages about it, and the fix is fine until rmind comes up
with something better.
It is not nice to have HEAD unusable for 2 weeks now (since July 22nd).
christos
> On Aug 6, 2019, at 1:26 PM, Maxime Villard wrote:
>
> Le 06/08/2019 à 12:25, Christos Zoulas a écrit :
>>
Le 06/08/2019 à 12:25, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Aug 6 10:25:13 UTC 2019
Modified Files:
src/sys/net/npf: npf_conn.c
Log Message:
Introduce an npf_conn_destroy_idx() that can handle partially constructed
conn structures.
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Tue Aug 6 08:10:27 UTC 2019
>
> Modified Files:
> src/sys/uvm: uvm_mmap.c
>
> Log Message:
> Change 'npgs' from int to size_t. Otherwise the 64bit->32bit conversion
> could lead to npgs=0, which is not
On 2019/08/05 23:06, Joerg Sonnenberger wrote:
> On Mon, Aug 05, 2019 at 10:12:04AM +, SAITOH Masanobu wrote:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Aug 5 10:12:04 UTC 2019
>>
>> Modified Files:
>> src/sys/dev/acpi: acpi_ec.c
>>
>> Log Message:
>>
On Mon, Aug 05, 2019 at 10:12:04AM +, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Aug 5 10:12:04 UTC 2019
>
> Modified Files:
> src/sys/dev/acpi: acpi_ec.c
>
> Log Message:
> - Fix a bug that acpiec_space_handler() doesn't access more than
On 2019/08/05 19:12, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Aug 5 10:12:04 UTC 2019
>
> Modified Files:
> src/sys/dev/acpi: acpi_ec.c
>
> Log Message:
> - Fix a bug that acpiec_space_handler() doesn't access more than 64bit
> correctly.
Thank you for rapid response. I was relieved to hear that.
Let me apologize again for the breakage, and thank you
very much for bisectioning the problem.
rin
On 2019/07/30 2:34, Ryo ONODERA wrote:
Hi,
Rin Okuyama writes:
I committed a (possible) fix:
Hi,
Rin Okuyama writes:
> I committed a (possible) fix:
> http://mail-index.netbsd.org/source-changes/2019/07/29/msg107649.html
>
> Could you try rasops_putchar_width.h 1.8?
With rasops_putchar_width.h 1.8, NetBSD/amd64-current on
my laptop works fine again.
Thanks for your quick fix.
>
I committed a (possible) fix:
http://mail-index.netbsd.org/source-changes/2019/07/29/msg107649.html
Could you try rasops_putchar_width.h 1.8?
Thanks,
rin
On 2019/07/30 1:32, Ryo ONODERA wrote:
Hi,
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Jul 29
1001 - 1100 of 5583 matches
Mail list logo
