On Tue, 10 Mar 2020 10:25:56 +1000, David Gwynne wrote:
> how about this? this has the cursor handling move the traversal and
> NULL check back to the for loop instead of looping on its own.
Much better. OK millert@
- todd
On Tue, Mar 10, 2020 at 12:03:24AM +0100, Tobias Heider wrote:
> If 'm = ifq->ifq_ops->ifqop_deq_begin(ifq, &cookie)' is not NULL
> the loop is exited and an uninitialized 'int error' is returned.
> Several lines below error is checked for '!= 0', so i assume it
> was meant to be initialized to '0'
On Mon, Mar 09, 2020 at 11:56:09PM +0100, Klemens Nanni wrote:
> On Mon, Mar 09, 2020 at 10:33:17PM +0100, Tobias Heider wrote:
> > there seems to be a nullptr dereference in if_hooks_run.
> Did your kernel crash here or did you find reading alone?
>
> > When the inner while loop is exited because
Claudio suggested[0] to restrict the visibility of three helper
functions in this file. The diff below goes a bit further, sprinkling
some static and const magic to help the compiler generate better code.
ok?
[0] https://marc.info/?l=openbsd-tech&m=158375920102498&w=2
Index: extern.h
===
Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
varbindlist.
Could you test the diff below?
martijn@
On 3/9/20 11:38 PM, Jan Klemkow wrote:
> Hi,
>
> The following diff fixes the use of the uninitialized pointer iter
> in trapcmd_exec().
>
> iter is just initialized in t
On Mon, Mar 09, 2020 at 11:56:09PM +0100, Klemens Nanni wrote:
> On Mon, Mar 09, 2020 at 10:33:17PM +0100, Tobias Heider wrote:
> > there seems to be a nullptr dereference in if_hooks_run.
> Did your kernel crash here or did you find reading alone?
Coverity Scan found it
> > When the inner while
On Tue, Mar 10, 2020 at 12:01:45AM +0100, Klemens Nanni wrote:
> On Mon, Mar 09, 2020 at 11:41:14PM +0100, Tobias Heider wrote:
> > sr_error takes a sr_softc and a printf like format string + varargs.
> > There's no need to pass DEVNAME(sc) here.
> Either that or embed the device name in the format
If 'm = ifq->ifq_ops->ifqop_deq_begin(ifq, &cookie)' is not NULL
the loop is exited and an uninitialized 'int error' is returned.
Several lines below error is checked for '!= 0', so i assume it
was meant to be initialized to '0'.
ok?
Index: ifq.c
=
On Mon, Mar 09, 2020 at 11:41:14PM +0100, Tobias Heider wrote:
> sr_error takes a sr_softc and a printf like format string + varargs.
> There's no need to pass DEVNAME(sc) here.
Either that or embed the device name in the format string; its usage
inside error messages is already inconsistent aroun
On Mon, Mar 09, 2020 at 10:33:17PM +0100, Tobias Heider wrote:
> there seems to be a nullptr dereference in if_hooks_run.
Did your kernel crash here or did you find reading alone?
> When the inner while loop is exited because 't == NULL' the next
> line is an access to 't->t_func'.
Yes, reads obvi
sr_error takes a sr_softc and a printf like format string + varargs.
There's no need to pass DEVNAME(sc) here.
ok?
Index: softraid.c
===
RCS file: /mount/openbsd/cvs/src/sys/dev/softraid.c,v
retrieving revision 1.398
diff -u -p -r1.3
Hi,
The following diff fixes the use of the uninitialized pointer iter
in trapcmd_exec().
iter is just initialized in traphandler_parse() if vers is SNMP_V2. In
all other cases iter stays uninitialized and may dereferenced in
trapcmd_exec().
OK?
bye,
Jan
Index: traphandler.c
=
Hi,
there seems to be a nullptr dereference in if_hooks_run.
When the inner while loop is exited because 't == NULL' the next
line is an access to 't->t_func'.
Because 't==NULL' means the TAILQ is fully traversed I think we
should break and exit instead.
ok?
Index: if.c
=
Hi there,
I am reading and learning the internals of malloc(3).
So, after compiling the debug version of libc and using it for one
basic sample code for malloc(3).
Not able to understand some parts of the following code snippet:
void
_malloc_init(int from_rthreads)
{
u_int i, nmutexes;
s
Jeremie Courreges-Anglas wrote:
Lovely!
> Agreed. Here's an updated diff that tests the return value of
> output_finish(). Suggestions welcome for the error message in this
> case.
>
> It also drops the extra "out = NULL;", and replaces logx() calls with
> warn(3) in this file. I see no reas
Hi,
Thank you for your test and feedback.
On Fri, 6 Mar 2020 16:38:24 -0600
Andrew Daugherity wrote:
> On Sun, Mar 1, 2020 at 10:41 PM YASUOKA Masahiko wrote:
>>
>> Hi,
>>
>> The problems you are pointing seem to be the same problem.
>>
>> > I'll try to test this diff next week if I can schedul
On 2020/03/09 22:50, David Gwynne wrote:
> this works better on his epyc 2 box, and works right on my epyc 1, esxi
> on epyc 1, and on an apu1.
Fine on apu2 (GX-412TC) and the old HP microserver (Turion N40L) also.
Diff makes sense and I'm happy you found an alternative to my dodgy
CPU_INFO_FOREAC
On Mon, Mar 09, 2020 at 09:41:37AM +0100, Jeremie Courreges-Anglas wrote:
> On Sat, Mar 07 2020, Claudio Jeker wrote:
> > On Sat, Mar 07, 2020 at 08:35:39AM +0100, Jeremie Courreges-Anglas wrote:
> >> On Fri, Mar 06 2020, "Theo de Raadt" wrote:
> >> >> Jeremie Courreges-Anglas wrote:
> >> >> >
On Mon, Mar 09, 2020 at 05:00:37PM +1000, David Gwynne wrote:
> ive been running multi-cpu/core openbsd VMs on esxi on top of amd
> epyc cpus, and have noticed for a long time now that for some reason
> openbsd decides that all the virtual cpus are threads on the one core.
> this is annoying, cos s
Hi Wataru,
On Mon, Mar 09, 2020 at 08:09:24PM +0900, Wataru Ashihara wrote:
> to improve readability.
>
> This is the first time of my commit to OpenBSD, so if I went something
> wrong, let me know that.
Thanks for sharing, committed!
>
> Index: sbin/iked/config.c
> ===
to improve readability.
This is the first time of my commit to OpenBSD, so if I went something
wrong, let me know that.
Index: sbin/iked/config.c
===
RCS file: /cvs/src/sbin/iked/config.c,v
retrieving revision 1.53
diff -u -r1.53 con
On 2020/03/09 11:34, Janne Johansson wrote:
> Den fre 6 mars 2020 kl 12:29 skrev Thomas de Grivel :
>
> > Hello,
> >
> > I was using base gcc but switching to base clang fixes the warnings on
> > -current at least.
> > Is base gcc not supported anymore ?
> >
>
> I think you are supposed to use wh
Den fre 6 mars 2020 kl 12:29 skrev Thomas de Grivel :
> Hello,
>
> I was using base gcc but switching to base clang fixes the warnings on
> -current at least.
> Is base gcc not supported anymore ?
>
I think you are supposed to use whatever gets used when you call "cc" on
the OpenBSD platform you
On Sat, Mar 07 2020, Claudio Jeker wrote:
> On Sat, Mar 07, 2020 at 08:35:39AM +0100, Jeremie Courreges-Anglas wrote:
>> On Fri, Mar 06 2020, "Theo de Raadt" wrote:
>> >> Jeremie Courreges-Anglas wrote:
>> >> >
>> >> >
>> >> > Checking the return value of fprintf is good but not enough to ensu
ive been running multi-cpu/core openbsd VMs on esxi on top of amd
epyc cpus, and have noticed for a long time now that for some reason
openbsd decides that all the virtual cpus are threads on the one core.
this is annoying, cos setting hw.smt=1 feels dirty and wrong.
i spent the weekend figuring t
25 matches
Mail list logo
