On Sat, Nov 25, 2023 at 11:36:34 -0800, Alistair Crooks wrote:
> I find it better to have
>
> MAN+= bar.7
> MAN+= foo.7
>
> Since a grep for 'MAN.*foo' will produce meaningful results
Also good for diffs in the future, e.g.
MAN += f.3
-MAN += g.3
MAN += h.3
vs.
f.3 \
-g.3 \
On Fri, Nov 24, 2023 at 18:09 Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sat, 25 Nov 2023 02:05:25 +
> > From: Taylor R Campbell
> >
> > > Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> > > From: chris...@astron.com (Christos Zoulas)
> > >
> > > Yes,
> Date: Sat, 25 Nov 2023 02:05:25 +
> From: Taylor R Campbell
>
> > Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> > From: chris...@astron.com (Christos Zoulas)
> >
> > Yes, this is indeed a lot better. I prefer though:
> >
> > MAN+= \
> > bar.7 \
> > foo.7
> >
> > It is faster to parse,
> Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> Yes, this is indeed a lot better. I prefer though:
>
> MAN+= \
> bar.7 \
> foo.7
>
> It is faster to parse, involves less typing, whitespace is cleaner.
This one doesn't have the same pattern for
In article <20231123211614.011a1f...@cvs.netbsd.org>,
Taylor R Campbell wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: riastradh
>Date: Thu Nov 23 21:16:13 UTC 2023
>
>Modified Files:
> src/share/man/man7: Makefile
>
>Log Message:
>share/man/man7/Makefile: Split MAN on
On Wednesday, November 15, 2023 4:15:28 AM CET you wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Nov 15 03:15:28 UTC 2023
>
> Modified Files:
> src/lib/libc/ssp: Makefile.inc
> Added Files:
> src/lib/libc/ssp: ssp_redirect.c
>
> Log Message:
> provide
Thank you, I should pay attention to that.
On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
> ->
>
>
> To
On 2023/10/18 17:25, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Oct 18 08:25:14 UTC 2023
Modified Files:
src/tests/sbin/ifconfig: t_capabilities.sh
Log Message:
ifconfig/t_capabilities: Skip unless run_unsafe is configured to yes
The test modifies
On 2023/10/12 14:50, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Oct 12 05:50:56 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixgbe.c
>
> Log Message:
> ixg(4): Don't print wrong error message about ixgbe_num_queues.
>
> Don't override
On 2023-10-15 17.06, Joerg Sonnenberger wrote:
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
Module Name:src
Committed By: oster
Date: Sun Oct 15 22:36:53 UTC 2023
Modified Files:
src/sys/dev/pci/igc: if_igc.c
Log Message:
Fix build of the MODULAR
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
> Module Name: src
> Committed By: oster
> Date: Sun Oct 15 22:36:53 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/igc: if_igc.c
>
> Log Message:
> Fix build of the MODULAR kernel, which explicitly excludes vlans.
> Date: Fri, 13 Oct 2023 19:03:35 +
> From: Andrew Doran
>
> On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > This is not true for RUMP. Hero you added sleepq_remove() as
> > "sleepq_unsleep(l, true)". This will unlock l_mutex without changing.
> >
> > Just poking
> Minor changes to jemalloc100 (the old one that only vax etc currently uses).
thanks.
i'm still using this version on a bunch of modern machines.
new jemalloc was problematic for a few things for me a
number of years ago and i keep meaning to test again, but
for now i'm still mostly using this
On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > On 10. Oct 2023, at 20:58, Andrew Doran wrote:
> >
> > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> >
> >>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >>
> >> -sleepq_unsleep(l,
> Date: Fri, 13 Oct 2023 17:52:07 +0900
> From: Rin Okuyama
>
> It would be really nice if we can find some systematical/reliable methods to
> figure out files that really depends on struct syncobj, e.g.. I tried
> ctfdump(1) to
> *.o for kernel modules, but I cannot extract information better
> Date: Tue, 10 Oct 2023 18:58:29 +
> From: Andrew Doran
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
> > > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >
> > -sleepq_unsleep(l, false);
> > +sleepq_remove(l->l_sleepq, l, true);
> > }
> >
On Thu, Oct 12, 2023 at 8:23 PM Taylor R Campbell
wrote:
>
> > Date: Thu, 12 Oct 2023 17:06:02 +0900
> > From: Rin Okuyama
> >
> > On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
> > >
> > > Module Name:src
> > > Committed By: ad
> > > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> Date: Thu, 12 Oct 2023 17:06:02 +0900
> From: Rin Okuyama
>
> On Thu, Oct 5, 2023 at 5:39â¯AM Andrew Doran wrote:
> >
> > Module Name:src
> > Committed By: ad
> > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> On 10. Oct 2023, at 20:58, Andrew Doran wrote:
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
>>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>>
>> -sleepq_unsleep(l, false);
>> +sleepq_remove(l->l_sleepq, l, true);
>>}
>> }
>>
Cool! Can I send a pull up request to netbsd-10?
I've not yet observed deadlocks since this was committed,
fortunately or unfortunately, although ;)
Thanks,
rin
On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
>
> Module Name:src
> Committed By: ad
> Date: Wed Oct 4 20:39:35
On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>
> -sleepq_unsleep(l, false);
> +sleepq_remove(l->l_sleepq, l, true);
> }
>}
>mutex_spin_exit(lock);
>
> Looks like sleepq_remove() unlocks l->l_mutex
> On 8. Oct 2023, at 15:23, Andrew Doran wrote:
>
> Module Name: src
> Committed By: ad
> Date: Sun Oct 8 13:23:05 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_condvar.c kern_sleepq.c kern_timeout.c
>kern_turnstile.c sys_lwp.c sys_select.c
> src/sys/rump/librump/rumpkern: sleepq.c
>
OK, it makes sense. I will revert the changes. Thanks for your explanations.
On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote:
>
> > I was changing news68k specific code, thus wasn't treating them as
> > common. But I understand the point.
>
> there's a *LOT* of m68k code that is copied
> I was changing news68k specific code, thus wasn't treating them as
> common. But I understand the point.
there's a *LOT* of m68k code that is copied into all the ports
that is almost identical, and should really be shared, but it
not, and changes like can make this harder to share.
ie, while
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not
On Thu, Oct 05, 2023 at 12:15:23PM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> > Yes that makes sense and is what I plan to do after work today if nobody
> > beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> > IMO.
>
On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> Yes that makes sense and is what I plan to do after work today if nobody
> beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> IMO.
Hey, this is a tiny landisk kernel, do not bloat it :-)
Unfortunately it
Martin,
On Thu, Oct 05, 2023 at 11:42:03AM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote:
> > No, I was confused by the #ifdef maze - it breaks the build for
> > non-MULTIPROCESSOR kernels only, and I am not actually sure what "use"
> > gcc sees
On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote:
> No, I was confused by the #ifdef maze - it breaks the build for
> non-MULTIPROCESSOR kernels only, and I am not actually sure what "use"
> gcc sees for the "nlocks" variable at all in that case.
Scratch that too, I'll get coffee.
On Thu, Oct 05, 2023 at 11:28:49AM +0200, Martin Husemann wrote:
> This breaks the build:
>
> ../../../../kern/kern_synch.c: In function 'kpause':
> ../../../../kern/kern_synch.c:257:10: error: 'nlocks' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 257 | error =
On Wed, Oct 04, 2023 at 08:29:18PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Wed Oct 4 20:29:18 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_condvar.c kern_exec.c kern_exit.c kern_sig.c
> kern_sleepq.c kern_synch.c kern_timeout.c
In this case maybe I should remove all FPSP references (vectors.S,
locore.S, Makefile.news68k (MD_LIBS={FPSP})?
On Sun, Oct 1, 2023 at 10:08 PM Izumi Tsutsui wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Sun Oct 1 18:50:53 UTC 2023
> >
> > Modified Files:
> >
> Module Name: src
> Committed By: andvar
> Date: Sun Oct 1 18:50:53 UTC 2023
>
> Modified Files:
> src/sys/arch/news68k/conf: Makefile.news68k
>
> Log Message:
> include fpsp Makefile.inc in Makefile.news68k, same as other m68k ports.
>
> needed for FPSP option to build,
Date:Wed, 27 Sep 2023 09:44:10 +
From:"Taylor R Campbell"
Message-ID: <20230927094410.b9257f...@cvs.netbsd.org>
| gpt(8): Make gpt type array and enum match again.
Thanks, and apologies for not checking that better - I did test
that it recognised the new one
On Sun, Sep 24, 2023 at 03:51:07AM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2023/09/24 3:21, Andrew Doran wrote:
> > Index: src/common/lib/libc/gen/radixtree.c
> > diff -u src/common/lib/libc/gen/radixtree.c:1.31
> > src/common/lib/libc/gen/radixtree.c:1.32
> > ---
Hi,
On 2023/09/24 3:21, Andrew Doran wrote:
Index: src/common/lib/libc/gen/radixtree.c
diff -u src/common/lib/libc/gen/radixtree.c:1.31
src/common/lib/libc/gen/radixtree.c:1.32
--- src/common/lib/libc/gen/radixtree.c:1.31Tue Sep 12 16:17:21 2023
+++ src/common/lib/libc/gen/radixtree.c Sat
On Mon, Sep 11, 2023 at 12:27:25PM +1000, matthew green wrote:
> "Rin Okuyama" writes:
> > Module Name:src
> > Committed By: rin
> > Date: Mon Sep 11 01:54:18 UTC 2023
> >
> > Modified Files:
> > src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
On 2023/09/11 11:27, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Sep 11 01:54:18 UTC 2023
Modified Files:
src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
elf.em
Log Message:
ld: Enable
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Sep 11 01:54:18 UTC 2023
>
> Modified Files:
> src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
> elf.em
>
> Log Message:
> ld: Enable --copy-dt-needed-entries by default again
On Fri, Sep 8, 2023 at 21:38 matthew green wrote:
> Module Name:src
> Committed By: mrg
> Date: Sat Sep 9 04:38:49 UTC 2023
>
> Modified Files:
> src/usr.bin/make: main.c
>
> Log Message:
> add explicit cast for long -> int truncation warning-as-error.
>
> as this is
Hi,
Oops, I didn't notice it is not generated. Sorry for bothering you!
Thanks,
rin
On Mon, Sep 4, 2023 at 10:46 PM Andrius V wrote:
>
> Hi,
>
> Thanks for the note. I honestly wasn't aware that we have generated
> configs and will be more careful in changing them in the future to
> account
On Tue, Sep 5, 2023 at 4:46 AM matthew green wrote:
>
> > I did similar verification for gdb/dist/bfd also. I'd like to
> > sync {binutils,gdb}/dist/bfd, but there are huge diffs between
> > them. Most of them seem like binutils or gdb specific fixes,
> > but I may overlook something...
> >
> >
> I did similar verification for gdb/dist/bfd also. I'd like to
> sync {binutils,gdb}/dist/bfd, but there are huge diffs between
> them. Most of them seem like binutils or gdb specific fixes,
> but I may overlook something...
>
> It must be nice if we could unify two libbfd's. The upstream
> uses
Hi,
Thanks for the note. I honestly wasn't aware that we have generated
configs and will be more careful in changing them in the future to
account that.
However, MDINSTALL config seems to be some older/legacy config, which
was not generated from GENERIC.in, I believe. I may try to transform
into
Hi,
On 2023/08/31 5:17, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Wed Aug 30 20:17:06 UTC 2023
Modified Files:
src/sys/arch/amiga/conf: MDINSTALL
Log Message:
s/Piccalo/Piccolo/ in device description.
Some ports including amiga use
On 2023/08/28 19:55, Valery Ushakov wrote:
On Mon, Aug 28, 2023 at 00:02:50 +, Rin Okuyama wrote:
Log Message:
binutils/bfd: Adjust blank line to reduce diff from upstream
Thanks a lot for these cleanups!
Do we need to apply similar cleanups to the bfd version in gdb?
Thanks for kind words!
Apparently, we need some test to detect kernel and userland mismatch
for bpf(4) header...
I'd also like to fix problems by which ATF does not complete on ERL3.
Some CPU/memory consuming tests, e.g., lib/libc/regex/t_exhaust,
trigger watchdog.
I guess something wrong in
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Sep 3 18:45:26 UTC 2023
>
> Modified Files:
> src/external/gpl3/gcc.old/dist/gcc: ubsan.c
>
> Log Message:
> remap generated ubsan filename string labels. fixes reproducible builds.
> reported by wiz@
On Mon, Aug 28, 2023 at 00:02:50 +, Rin Okuyama wrote:
> Log Message:
> binutils/bfd: Adjust blank line to reduce diff from upstream
Thanks a lot for these cleanups!
Do we need to apply similar cleanups to the bfd version in gdb?
(external/gpl3/gdb/dist/bfd)
-uwe
Module Name:src
Committed By: rin
Date: Wed Aug 23 13:21:17 UTC 2023
Modified Files:
src/sys/net: bpf.h
Log Message:
bpf: Fix SIZEOF_BPF_HDR (for LP64 userland) on mips64
It cannot fit within 18 bytes, of course ;)
As we had never provided working bpf(4) implementation
On 2023-08-25 13:30, Taylor R Campbell wrote:
> Since VOP_READDIR requires vp to be locked, I can infer that the
> handle_write caller must already hold vp locked. But that means that
> we have ifd_lock -> vnode lock in one path, and vnode lock -> ifd_lock
> in another path, which is forbidden
> Date: Fri, 25 Aug 2023 13:38:02 -0400
> From: Theodore Preduta
>
> On 2023-08-25 13:13, Taylor R Campbell wrote:
> > This can't be right, and it's a little unsettling that the problem
> > isn't caught by any automatic tests.
> >
> > As I understand it, the `ie_name' member is supposed to
On 2023-08-25 13:13, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By: christos
>> Date: Wed Aug 23 19:17:59 UTC 2023
>>
>> Modified Files:
>> src/sys/compat/linux/common: linux_inotify.c
>>
>> Log Message:
>> put variable length structure at the end, so that
> Module Name:src
> Committed By: christos
> Date: Thu Aug 24 19:51:24 UTC 2023
>
> Modified Files:
> src/sys/compat/linux/common: linux_inotify.c
>
> Log Message:
> fix a locking bug (Theodore Preduta)
>
> if (needs_lock)
> vn_lock(vp, LK_SHARED
> Module Name:src
> Committed By: christos
> Date: Wed Aug 23 19:17:59 UTC 2023
>
> Modified Files:
> src/sys/compat/linux/common: linux_inotify.c
>
> Log Message:
> put variable length structure at the end, so that clang does not complain.
>
> struct inotify_entry {
>
Yes, I committed it (I had the change in my tree).
Best,
christos
> On Aug 21, 2023, at 3:40 PM, Ryo ONODERA wrote:
>
> Hi,
>
> "Christos Zoulas" writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Sun Aug 20 18:08:57 UTC 2023
>>
>> Modified Files:
>>
Hi,
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Aug 20 18:08:57 UTC 2023
>
> Modified Files:
> src/sys/compat/linux: files.linux
>
> Log Message:
> add inotify (forgot to commit this)
>
>
> To generate a diff of this commit:
> cvs rdiff -u
Ah, it must be better. Thank you for useful comment as always :)
I've confirmed the same files are generated. I will commit soon, but
commit mail seems to be delayed for some reasons...
Thanks,
rin
On Sun, Aug 20, 2023 at 11:17 AM Valery Ushakov wrote:
>
> On Sun, Aug 20, 2023 at 02:02:40
On Sun, Aug 20, 2023 at 02:02:40 +, Rin Okuyama wrote:
> Modified Files:
> src/external/gpl3/gdb/dist/gnulib: configure
> src/external/gpl3/gdb/dist/gnulib/import/m4: rename.m4
>
> Log Message:
> gdb/gnulib: ``guess yes'' to rename(2) checks for NetBSD
Can't we just set
> For vax, something still wrong.
This was due to my test environment built by GCC 12. For system built by GCC 10,
GDB 13 works just fine (except for C++ exception handling), as far as I can see.
Thanks,
rin
On Thu, Aug 17, 2023 at 4:45 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed
This was not correct. Core file support for NetBSD/riscv was present for
our local version of GDB 11, and lost during merge.
Thanks,
rin
On Thu, Aug 17, 2023 at 4:37 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 07:37:36 UTC 2023
>
> Modified
> binutils/bfd: Correct auxv offset for NetBSD, from gdb/bfd
binutils.old/bfd for this commit...
rin
On Thu, Aug 17, 2023 at 3:49 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 06:49:01 UTC 2023
>
> Modified Files:
>
> gcc/ppc: Register NetBSD OSABI for rs6000, lost during merge
oops, apparently "gdb/ppc", not "gcc".
Thanks,
rin
On Thu, Aug 17, 2023 at 2:53 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 05:53:45 UTC 2023
>
> Modified Files:
>
I would agree with Taylor, it is not tested well enough to be enabled
by default and mainly unmaintained by now. I guess the better solution
would be to attempt to integrate openchrome-drm instead at some point
in the future. I think making viadrmums as kernel module is quite a
good trade off
> Date: Thu, 10 Aug 2023 07:42:53 +1000
> from: matthew green
>
> > Log Message:
> > viadrmums(4): build legacy VIA DRM UMS driver module for amd64.
> >
> > This driver is not built-in by default, thus loadable module can help
> > (un)lucky
>
> if it works, why isn't it in GENERIC as well as a
On Sat, 12 Aug 2023 at 16:16, Andrius V wrote:
>
> Hi,
>
> Sorry, didn't notice the email until today. To answer your question
> why it is not enabled in GENERIC by default, I am not sure
> (Taylor(?)), it was commented since the day one both on i386 and
> amd64.
>
> However, I have some doubts
Hi,
Sorry, didn't notice the email until today. To answer your question
why it is not enabled in GENERIC by default, I am not sure
(Taylor(?)), it was commented since the day one both on i386 and
amd64.
However, I have some doubts if it is very relevant driver to enable
it. From the context
In article <20230803122447.d5e18f...@cvs.netbsd.org>,
Nia Alarie wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: nia
>Date: Thu Aug 3 12:24:47 UTC 2023
>
>Modified Files:
> src/distrib/sets/lists/comp: mi
> src/distrib/sets/lists/debug: mi
>
> Date: Thu, 10 Aug 2023 17:42:35 +0900
> From: Kengo NAKAHARA
>
> Could you tell me how you test this fix for future reference?
I asked skrll@ to boot a VM with vmxnet3 and hammer on it with a
combination of:
1. dhcp
2. host$ nc -l 54321 /dev/null
guest$ nc host 54321 /dev/null
3. for i in
Hi,
On 2023/08/10 18:07, Nick Hudson wrote:
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor suggested
host$ nc -l 54321 /dev/null
guest$ nc
Hi,
Could you tell me how you test this fix for future reference?
Thanks,
On 2023/08/10 17:24, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Thu Aug 10 08:24:45 UTC 2023
Modified Files:
src/sys/dev/pci: if_vmx.c
Log Message:
vmxnet(4): Fix
> Log Message:
> viadrmums(4): build legacy VIA DRM UMS driver module for amd64.
>
> This driver is not built-in by default, thus loadable module can help
> (un)lucky
if it works, why isn't it in GENERIC as well as a module?
thanks.
.mrg.
please review this. i'll try to figure out tests for everything,
though it seems annoying :)
https://www.netbsd.org/~mrg/gcc12-use-after-free.diff
it should handle all the open use-after-free problems.
.mrg.
ps: you'll notice no new headers needed for ptrdiff_t usage ;)
matthew green writes:
> > > - used = dst - conv->wbuff;
> > > + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
> >
> > Any particular reason why there is a cast to uintptr_t here? I don't
> > think there is a guarantee that you can calculate an offset by
> > subtracting
> > - used = dst - conv->wbuff;
> > + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
>
> Any particular reason why there is a cast to uintptr_t here? I don't
> think there is a guarantee that you can calculate an offset by
> subtracting uintptr_ts calculated from
On Tue 08 Aug 2023 at 14:10:41 +0200, Joerg Sonnenberger wrote:
> On Tue, Aug 08, 2023 at 01:42:39PM +0200, Rhialto wrote:
> > On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> > > Index: lib/libedit/chartype.c
> > > ===
>
On Tue, Aug 08, 2023 at 01:42:39PM +0200, Rhialto wrote:
> On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> > Index: lib/libedit/chartype.c
> > ===
> > RCS file: /cvsroot/src/lib/libedit/chartype.c,v
> > retrieving
On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> Index: lib/libedit/chartype.c
> ===
> RCS file: /cvsroot/src/lib/libedit/chartype.c,v
> retrieving revision 1.36
> diff -p -u -r1.36 chartype.c
> --- lib/libedit/chartype.c
On Tue, Aug 08, 2023 at 04:01:19PM +1000, matthew green wrote:
> Joerg Sonnenberger writes:
> > On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > > Module Name: src
> > > Committed By: mrg
> > > Date: Thu Aug 3 08:16:31 UTC 2023
> > >
> > > Modified Files:
>
> Date: Mon, 7 Aug 2023 23:58:50 +0200
> From: Tobias Nygren
>
> Is this sort of fix acceptable for the above cases?
>
> + ptrdiff_t offset = pos - buf;
> new_buf = realloc(buf, buf_size);
> if (!new_buf)
>
Joerg Sonnenberger writes:
> On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Thu Aug 3 08:16:31 UTC 2023
> >
> > Modified Files:
> > src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> >
Valery Ushakov writes:
> On Mon, Aug 07, 2023 at 23:58:50 +0200, Tobias Nygren wrote:
>
> > Is this sort of fix acceptable for the above cases?
> [...]
> > + ptrdiff_t offset = pos - buf;
> [...]
> > - pos = new_buf + (pos - buf);
> > + pos =
On Tue, Aug 08, 2023 at 00:44:41 +0200, Roland Illig wrote:
> Am 07.08.2023 um 23:58 schrieb Tobias Nygren:
> > Is this sort of fix acceptable for the above cases?
> >
> > + ptrdiff_t offset = pos - buf;
> > new_buf = realloc(buf, buf_size);
> > - pos = new_buf + (pos - buf);
> > + pos
On Mon, Aug 07, 2023 at 23:58:50 +0200, Tobias Nygren wrote:
> Is this sort of fix acceptable for the above cases?
[...]
> + ptrdiff_t offset = pos - buf;
[...]
> - pos = new_buf + (pos - buf);
> + pos = new_buf + offset;
I think so.
Am 07.08.2023 um 23:58 schrieb Tobias Nygren:
> Is this sort of fix acceptable for the above cases?
>
> + ptrdiff_t offset = pos - buf;
> new_buf = realloc(buf, buf_size);
> - pos = new_buf + (pos - buf);
> + pos = new_buf + offset;
Yes.
Instead of ptrdiff_t, I prefer to use
On Thu, 3 Aug 2023 23:30:31 +0900
Rin Okuyama wrote:
> On 2023/08/03 23:23, Valery Ushakov wrote:
> > On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
> >
> >> -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
> >>
> >>newbuf = realloc(buf, size);
> >>p =
On 2023/08/04 20:18, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 4 11:18:18 UTC 2023
Modified Files:
src/sys/arch/sun2/dev: sc_mbmem.c
Log Message:
sun2/sc(4): Fix panic due to wrong ENOMEM for DMA buffer
Use kmem_zalloc(9) for
> > Ah, I only thought about "obvious" impl. Thank you for kind
> > explanation! I will revert them for now.
>
> We should fix those cases that gcc12 found.
i was able to fix some of them with some code to apply offsets
generated before realloc() or free(), but not in all case.
a couple of them
On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Thu Aug 3 08:16:31 UTC 2023
>
> Modified Files:
> src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c
>
On Thu, Aug 03, 2023 at 23:30:31 +0900, Rin Okuyama wrote:
> On 2023/08/03 23:23, Valery Ushakov wrote:
> > On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
> >
> > > -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
> > >
> > > newbuf = realloc(buf, size);
> > >
On 2023/08/03 23:23, Valery Ushakov wrote:
On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
-Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
newbuf = realloc(buf, size);
p = newbuf + (p - buf);
Let shut this up for GCC 12 (with hoping it gets
On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
> -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
>
> newbuf = realloc(buf, size);
> p = newbuf + (p - buf);
>
> Let shut this up for GCC 12 (with hoping it gets improved for 13!).
C99 says
J.2
Let's not make a mountain out of a molehill. Thanks Ryo for looking into it and
the changes are good. In fact I had forgotten to commit the:
M dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.h
And the others worked for me because of the compat name stuff that I added as
Hi,
I have no strong opinion about this change.
I just want to unbreak the build to test the latest epoll(2) related
side effects for pkgsrc packages.
Thank you.
On Wed, Aug 2, 2023 at 4:20 PM Taylor R Campbell
wrote:
>
> Let's please just revert all these ioctl renames now, and go back to
>
Let's please just revert all these ioctl renames now, and go back to
the drawing board, rather than continue to dig ourselves into a deeper
hole with unnecessary incremental cosmetic changes that are breaking
all the builds.
I generally agree that calling something plain `old' is bad and the
Ryo ONODERA writes:
> I have the same build failure.
> I think that there are some typos and inconsistencies.
>
> With the attached patch, I can finish build.sh build successfully.
this looks like what i expected.
the before / after showed fewer of the new names. please commit.
we'll need
Hi,
I have the same build failure.
I think that there are some typos and inconsistencies.
With the attached patch, I can finish build.sh build successfully.
Thank you.
On Wed, Aug 2, 2023 at 2:32 AM Christos Zoulas wrote:
>
> I am looking into it. With new code that restores the old names it
Bumped.
christos
> On Aug 1, 2023, at 2:17 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Jul 31 17:38:28 UTC 2023
>>
>> Modified Files:
>> src/distrib/sets/lists/comp: mi
>> src/include:
1 - 100 of 11237 matches
Mail list logo
