On 02/04/20(Thu) 13:44, Vitaliy Makkoveev wrote:
> pipex(4) has pipex_ioctl() interface for pipex_session related routines.
> pipex_ioctl() calls should be done with pipex_iface_contex, so any
> operations should be done with pipex_sessions owned by passed
> pipex_iface_contex. pipex_session check
Unused macro, found while auditing d_poll() functions, ok?
Index: sys/conf.h
===
RCS file: /cvs/src/sys/sys/conf.h,v
retrieving revision 1.148
diff -u -p -r1.148 conf.h
--- sys/conf.h 22 Jan 2020 23:06:05 - 1.148
+++ sys/con
On 02/04/20(Thu) 13:36, Philip Guenther wrote:
> On Tue, Mar 31, 2020 at 11:24 PM Martin Pieuchot wrote:
>
> > The current form of EV_SET(2) declares a `kevp' variable. This can
> > cause to subtle bugs hard to discover if one uses a variable of the
> > same to
On 02/04/20(Thu) 20:25, Mark Kettenis wrote:
> > Date: Thu, 2 Apr 2020 20:12:08 +0200
> > From: Martin Pieuchot
> > Content-Type: text/plain; charset=utf-8
> >
> > While reviewing the all current .d_poll() functions I found those two
> > which are incoherent w
While reviewing the all current .d_poll() functions I found those two
which are incoherent with the rest.
- Most of the devices return POLLERR when the device is no longer valid,
for whatever reason, uhid(4) returns POLLHUP in one of the cases.
- fusepoll() return EINVAL which isn't a POLL* val
Hi there!
I think these are superfluous.
Best,
Martin
Index: cgi.c
===
RCS file: /cvs/src/usr.bin/mandoc/cgi.c,v
retrieving revision 1.109
diff -u -p -r1.109 cgi.c
--- cgi.c 10 Jan 2020 15:20:49 - 1.109
+++ cgi.c
Hello Vitaliy,
On 01/04/20(Wed) 12:59, Vitaliy Makkoveev wrote:
> Updated diff. The idea is to use already existing pipex API for
> pipex_session creation and destruction. pppx_if now holds a reference
> to pipex_session.
This is great!
There are many things in this diff which makes it complicat
On 29/03/20(Sun) 00:16, Vitaliy Makkoveev wrote:
> pipex not used with tun(4)
It seems an oversight from the addition of the new pppac(4) driver. See
net/if_tun.c commits from January this year.
So the right fix would be to replace tun(4) with pppac(4) and add a pppac.4
manpage. Do you feel lik
While working on moving pselect(2) outside of the KERNEL_LOCK() I found
this surprising {p,}select(2) behavior exposed by the libc/sys/t_select.c
regression test. Should it be considered as a bug or feature?
The above mentioned test does the following (simplified):
fd = open("/dev/null",
kevent(2) notifies userland if an event happened based on given filter.
If an error is encountered during execution, the given descriptor will
have the EV_ERROR flag set and `data' will contain an errno(2) value.
This value might come from the kqueue subsystem itself or from the
f_attach() functi
On 01/04/20(Wed) 10:06, Mark Kettenis wrote:
> > Date: Wed, 1 Apr 2020 09:40:05 +0200
> > From: Patrick Wildt
> >
> > On Wed, Apr 01, 2020 at 09:22:07AM +0200, Patrick Wildt wrote:
> > > On Wed, Apr 01, 2020 at 04:47:10PM +1100, Jonathan Gray wrote:
> > > > On Wed, Apr 01, 2020 at 12:58:23PM +110
I've started to refactor some of the kqueue() subsystem to make progress
on moving selwakeup() out of the KERNEL_LOCK(). Diff below is a small
part of this work. It extracts the sleeping logic outside of the main
loop.
I find this easier to read and it allows me to make my huge diff more
easily
The current form of EV_SET(2) declares a `kevp' variable. This can
cause to subtle bugs hard to discover if one uses a variable of the
same to retrieve events.
Diff below prefixes the locally declared variable by an underscore,
like it it done in FD_ZERO(), which should be good enough to prevent
On 31/03/20(Tue) 23:16, Vitaliy Makkoveev wrote:
> On Tue, Mar 31, 2020 at 06:15:46PM +0200, Martin Pieuchot wrote:
> > [...]
> > Well better fix npppd(8), no? Not crashing the kernel is priority 1.
> I made patch for npppd(8) too. I include it to this email below, without
>
On 31/03/20(Tue) 18:58, Vitaliy Makkoveev wrote:
> On Tue, Mar 31, 2020 at 05:23:46PM +0200, Martin Pieuchot wrote:
> > On 31/03/20(Tue) 16:48, Vitaliy Makkoveev wrote:
> > > I refactored pppx(4). The idea is to use pipex(4) as it was designed.
> > > No one holds pipex_
On 31/03/20(Tue) 16:48, Vitaliy Makkoveev wrote:
> I refactored pppx(4). The idea is to use pipex(4) as it was designed.
> No one holds pipex_session outside pipex(4) so pipex_timer() calls are
> safe. Unfortunately, this way gives some performance impact, because we
> need to call pipex_lookup_by_
that the XSIMPLEQ* macros are not documented in the
queue.3 page. From what I gathered from the mailing list is, that these
were added for in kernel use. Is there a specific reason for not
mentioning them in queue.3? If no, would you be open to a diff?
Best,
Martin
Index: queue.h
On 26/03/20(Thu) 12:13, Martin Pieuchot wrote:
> Previous diff had a bug in the interrupt handler refactoring that showed
> up on i386. The version below has been tested on i386 and doesn't seem
> to cause any regression.
>
> Here's the original explanation, diff belo
Hi there!
It seems these are just a coded form for no return value, unless this is
some libssl slang I am not aware of.
Best,
Martin
Index: SSL_CTX_set_client_CA_list.3
===
RCS file: /cvs/src/lib/libssl/man
Hi there!
I found some more.
Best,
Martin
Index: libcrypto/man/RC4.3
===
RCS file: /cvs/src/lib/libcrypto/man/RC4.3,v
retrieving revision 1.7
diff -u -p -r1.7 RC4.3
--- libcrypto/man/RC4.3 6 Jun 2019 01:06:59 - 1.7
Hi there
Unless I miss something ERR_print_errors_cb returns no value as well.
Best,
Martin
Index: ERR_print_errors.3
===
RCS file: /cvs/src/lib/libcrypto/man/ERR_print_errors.3,v
retrieving revision 1.7
diff -u -p -r1.7
On 27/03/20(Fri) 15:16, Vitaliy Makkoveev wrote:
> On Fri, Mar 27, 2020 at 10:43:52AM +0100, Martin Pieuchot wrote:
> > Do you have a backtrace for the memory corruption? Could you share it?
> Yes. Apply path below, compile and run code, and when you had see
> "pipex_session .
On 27/03/20(Fri) 11:58, Vitaliy Makkoveev wrote:
> Each pipex_session has timeout_sec field and if it is not 0,
> pipex_timer() can destroy pipex_session. Each pppx_if contents
> pipex_session. If userland creates pppx_if and pipex_session has
> timeout (for example, npppd.conf has idle-timeout opt
On 26/03/20(Thu) 14:41, Vitaliy Makkoveev wrote:
> On Thu, Mar 26, 2020 at 11:56:27AM +0100, Martin Pieuchot wrote:
> > On 26/03/20(Thu) 13:34, Vitaliy Makkoveev wrote:
> > > Add missing #ifdefs to pppx_if_destroy() as it done in
> > > pipex_destroy_session(). A
Previous diff had a bug in the interrupt handler refactoring that showed
up on i386. The version below has been tested on i386 and doesn't seem
to cause any regression.
Here's the original explanation, diff below has msix toggle to "off":
> Diff below allows ix(4) to establish two MSI-X handlers
On 26/03/20(Thu) 13:34, Vitaliy Makkoveev wrote:
> Add missing #ifdefs to pppx_if_destroy() as it done in
> pipex_destroy_session(). Also remove unnecessary cast.
What's the point of such #ifdef? I understand the current code is not
coherent, but does this reduce the binary size? For a case in a
On 24/03/20(Tue) 15:55, Mark Kettenis wrote:
> > Date: Tue, 24 Mar 2020 15:18:13 +0100
> > From: Martin Pieuchot
> >
> > As soon as an entry is found on `pmr_control.allocs' the boolean
> > `work_done' will be set to true. So it is impossible to reach t
Variable `me' is never NULL before reaching RBT_POISON(). Diff has a
lot of context to ease the review.
CID 1453116 Dereference before null check
ok?
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revisi
As soon as an entry is found on `pmr_control.allocs' the boolean
`work_done' will be set to true. So it is impossible to reach the
case below that sets UVM_PMA_FAIL.
CID 1453061 Logically dead code
Ok?
Index: uvm/uvm_pdaemon.c
===
On 23/03/20(Mon) 15:18, Martin Pieuchot wrote:
> On 19/03/20(Thu) 15:37, Martin Pieuchot wrote:
> > People are starting to capture kernel stack traces and produce
> > Flamegraphs. Those traces currently include the frames used by
> > dt(4) itself:
> >
&g
On 23/03/20(Mon) 18:51, Ted Unangst wrote:
> [...]
> If this is a temporary measure, I think it should include some
> annotation to that effect, so that it doesn't continue spreading.
It isn't, it's to help review or upcoming diffs :o) It's not to make
this nice it's to tedu it!
Most of the VOP_* methods include an argument of type "struct proc *"
called `a_p'. This pointer is always set to `curproc' as confirmed by
the diff below. The diff has been though base build with NFS on amd64
and sparc64 as well as a full port bulk on amd64 and is in the current
octeon port bulk
On 19/03/20(Thu) 15:37, Martin Pieuchot wrote:
> People are starting to capture kernel stack traces and produce
> Flamegraphs. Those traces currently include the frames used by
> dt(4) itself:
>
> dt_pcb_ring_get+0x11d
> dt_prov_profile_enter+0x6e
>
Taken from FreeBSD. I removed a comment to the effect that C's
_Static_assert, if implemented as a macro,
would not work well with C++ due to the possibility of unshielded
commas appearing in template parameter lists,
explaining why *all* C++ standards are excluded rather than just C++11
and later
On 20/03/20(Fri) 12:01, Mark Kettenis wrote:
> > Date: Fri, 20 Mar 2020 11:54:59 +0100
> > From: Martin Pieuchot
> >
> > As explained in my recent ix(4) diff, using a define when an arch
> > doesn't support a given function makes the compiler complai
As explained in my recent ix(4) diff, using a define when an arch
doesn't support a given function makes the compiler complain that
the arguments are unused:
/sys/dev/pci/if_ix.c:1789:21: error: unused variable 'dummy'
[-Werror,-Wunused-variable]
pci_intr_handle_tdummy;
On 19/03/20(Thu) 20:53, Klemens Nanni wrote:
> Changing file permissions on /dev/dt to allow non-root access and a
> simple `btrace -l' as non-root user already dt(4)'s KASSERT()s.
Would you mind sharing traces?
> Instead of panicing the machine I think we can return early just like
> in other f
On 19/03/20(Thu) 19:58, Klemens Nanni wrote:
> On Thu, Mar 19, 2020 at 07:25:05PM +0100, Martin Pieuchot wrote:
> > > +.It Fn exit
> > > +Terminate with exit code 0
> >
> > I don't see the value of mentioning the exit code. What about:
> >
> >
timefmt
> print timestamps using
> .Xr strftime 3
> +.It Fn zero "@map"
> +Set values to 0 for all keys from map
> +.Va @map
Set all values of/from @map to 0?
While here what do you think about replacing 'from map @map' by 'from
@map' in clear() and print(). Since the manual is mentioning pairs
already this now seems redundant to me.
Thanks,
Martin
People are starting to capture kernel stack traces and produce
Flamegraphs. Those traces currently include the frames used by
dt(4) itself:
dt_pcb_ring_get+0x11d
dt_prov_profile_enter+0x6e
hardclock+0x1a9
lapic_clockintr+0x3f
Xresume_lapic_ltimer+0x26
acpicpu_idle+0x261
On 18/03/20(Wed) 20:45, Klemens Nanni wrote:
> It takes a format string, e.g.
>
> syscall:sysctl:entry {
> time("%+\n")
> }
>
This is indeed an improvement, thanks! I don't know how to point that
'format' or 'timefmt' is the same as describe in strftime(3). Does that
On 18/03/20(Wed) 11:55, Mark Kettenis wrote:
> > Date: Wed, 18 Mar 2020 11:34:59 +0100
> > From: Martin Pieuchot
> >
> > On 17/03/20(Tue) 20:08, Mark Kettenis wrote:
> > > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64
> > > machine
On 17/03/20(Tue) 20:08, Mark Kettenis wrote:
> While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64
> machine, I noticed that the kernel was spending a lot of time (6.84%)
> in uvm_map_inentry(). This is caused by kernel lock contention.
> Pushing baack the kernel lock further into th
On 17/03/20(Tue) 07:50, Philip Guenther wrote:
> On Tue, Mar 17, 2020 at 5:18 AM Martin Pieuchot wrote:
> > On 17/03/20(Tue) 04:02, Philip Guenther wrote:
> > > On Tue, Mar 17, 2020 at 1:07 AM Martin Pieuchot wrote:
> > > [...]
> > > > @@ -663,8 +668,6 @@ k
On 17/03/20(Tue) 04:02, Philip Guenther wrote:
> On Tue, Mar 17, 2020 at 1:07 AM Martin Pieuchot wrote:
> [...]
> > @@ -663,8 +668,6 @@ ktrwriteraw(struct proc *curp, struct vn
> > LIST_FOREACH(pr, &allprocess, ps_list)
> > if (pr->ps_tr
em(4).
If you have been testing an earlier version of these diffs, please do
it again :)
Thanks,
Martin
Index: dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.347
diff -u -p -r1.347 if_em.c
--- dev/pc
On 16/03/20(Mon) 14:01, Martin Pieuchot wrote:
> vget(9) might fail, stop right away if that happens.
>
> CID 1453020 Unchecked return value.
Updated diff that stops tracing if vget(9) fails, similar to what's
currently done if VOP_WRITE(9) fails, suggested by visa@.
Code shuffli
If the given `rate' is bigger than the last element of the array there's
an out-of-bound read and `divisor' will contain garbage.
Diff below fix this issue reported by coverity, CID 1453258.
Ok?
Index: umcs.c
===
RCS file: /cvs/src/
vget(9) might fail, stop right away if that happens.
CID 1453020 Unchecked return value.
ok?
Index: kern//kern_ktrace.c
===
RCS file: /cvs/src/sys/kern/kern_ktrace.c,v
retrieving revision 1.100
diff -u -p -r1.100 kern_ktrace.c
--- k
Hello list,
The best way for beginner to start with OpenbBSD programming?
Martin
On 12/03/20(Thu) 14:30, Claudio Jeker wrote:
> On Thu, Mar 12, 2020 at 08:15:00AM -0500, Amit Kulkarni wrote:
> > Hi,
> >
> > In grepping for ps_flags in /sys, it is confusing to see that ps_flags is
> > associated with
> >
> > 1) PWM_POLARITY (power regulation?).
> > Proposed to rename to p
Those two statements are redundant, so keep only one of them, ok?
Index: kern/subr_disk.c
===
RCS file: /cvs/src/sys/kern/subr_disk.c,v
retrieving revision 1.235
diff -u -p -r1.235 subr_disk.c
--- kern/subr_disk.c26 Dec 2019 22:38
On 29/02/20(Sat) 19:55, Martin Pieuchot wrote:
> On 28/02/20(Fri) 18:24, Martin Pieuchot wrote:
> > Diff below fixes multiple issues with traced process, exposed by the
> > regression test attached:
> >
> > - When a debugging process exit, give back the traced process t
On 03/03/20(Tue) 11:37, Martin Pieuchot wrote:
> Currently em_hw_init() uses some hardcorded values to configure TX
> rings. Diff below convert it to use the value of the first queue.
> This is currently a no-op. It makes the code consistent with the
> rest of the driver and reduce
percpu_init() should be called before cpu_configure() if we want to use
per-CPU memory allocation in drivers.
I placed it early, right before mbinit() because it is only initializing
a memory pool and we should allow other subsystems to rely on it.
Ok?
Index: kern/init_main.c
===
Currently em_hw_init() uses some hardcorded values to configure TX
rings. Diff below convert it to use the value of the first queue.
This is currently a no-op. It makes the code consistent with the
rest of the driver and reduce the size of upcoming diffs.
Note that even if a single queue is curr
On 28/02/20(Fri) 18:24, Martin Pieuchot wrote:
> Diff below fixes multiple issues with traced process, exposed by the
> regression test attached:
>
> - When a debugging process exit, give back the traced process to its
> original parent, if it exists, instead of init(8).
>
Diff below fixes multiple issues with traced process, exposed by the
regression test attached:
- When a debugging process exit, give back the traced process to its
original parent, if it exists, instead of init(8).
- When a traced process exit, make sure the original parent receives
the exit
When the original parent of a process *is* its debugger there's no need
to reparent the child upon exit. Diff below prevents a double status
report.
It is the same diff I already sent without the bad typo.
ok?
Index: kern/kern_exit.c
=
On 16/01/20(Thu) 01:07, Vadim Zhukov wrote:
> Hi all.
>
> This fixes an issue I'm seeing with a uvideo(4), that doesn't like
> commands we're sending to it. The camera simply sends nothing,
> and since we're sleeping forever (xfer timeout is 0, which is
> USBD_NO_TIMEOUT), we never get out from 'w
The VOP layer passes a "struct proc" pointer encoded as `a_p' in most
of its arguments. This pointer is most of the time only used to re-
enter the VFS layer. Due to that design, a lot of "struct proc *" are
being passed up to the generic file descriptor layer.
Diff below starts reducing this by
On 24/02/20(Mon) 11:29, Lauri Tirkkonen wrote:
> On Mon, Feb 24 2020 10:24:53 +0100, Martin Pieuchot wrote:
> > On 23/02/20(Sun) 14:48, Lauri Tirkkonen wrote:
> > > I was working on a make jobserver implementation that uses POSIX
> > > semaphores as job tokens instead of
On 23/02/20(Sun) 14:48, Lauri Tirkkonen wrote:
> I was working on a make jobserver implementation that uses POSIX
> semaphores as job tokens instead of a complicated socket-based approach.
> Initially I used named semaphores, which work fine, except if child
> processes with less privileges need to
On 19/02/20(Wed) 14:13, Vitaliy Makkoveev wrote:
> On Wed, Jan 17, 2018 at 11:40:24AM +0100, Martin Pieuchot wrote:
> > Hello Sebastien,
> >
> > On 17/01/18(Wed) 10:19, Sebastien Marie wrote:
> > > [...]
> > > kernel modification is desirable in some cas
ends up being included by 532 files. On amd64 this
represents almost 1/3 of the 1674 kernel source files. So any change
in a header it includes will result in a large number of rebuild.
is one of these headers. In drm land it is necessary to
make some scheduling decision based on the states o
On 18/02/20(Tue) 22:39, Jonathan Matthew wrote:
> On Fri, Feb 14, 2020 at 06:28:20PM +0100, Martin Pieuchot wrote:
> > @@ -2597,13 +2635,6 @@ em_initialize_receive_unit(struct em_sof
> > E1000_WRITE_REG(&sc->hw, ITR, DEFAULT_ITR);
> > }
> >
>
On 15/02/20(Sat) 16:56, Visa Hankala wrote:
> When I added the knote_acquire() call in kqueue_register(), I overlooked
> the fact that the knote could be modified by a (soft) interrupt.
> Interrupts have to be blocked when changing kn_status. Otherwise the
> state could become confused.
Can the sa
During n2k20 we asked ourself why touching a header makes us rebuild a lot
of the kernel again. New year or new cycle maybe, that's time for a new
round of cleanup ;o)
Today I figured out why when I touch I have to rebuild too
much. I came up with two cleanups, diff below is the first one.
is
This diff introduces the concept of "queue" in the em(4) driver. The
logic present in ix(4) has been matched for coherency.
Currently the driver uses a single queue and the diff below doesn't
change anything in that regard. It can be viewed as the introduction
of an abstraction.
I'd like to get
On 13/02/20(Thu) 16:53, Visa Hankala wrote:
> On Thu, Feb 13, 2020 at 12:00:35PM +0100, Martin Pieuchot wrote:
> > These structures are only used by autoconf(9) and don't need to be
> > modified. Some subsystems already define most of them as 'const'.
> > Diff
On 09/02/20(Sun) 16:40, Visa Hankala wrote:
> [...]
> In addition,
> IPL_AUDIO is above IPL_MPFLOOR on some architectures.
That's because audio interrupt handlers have been considered MP-safe, we
now know they aren't 8)
On 06/02/20(Thu) 12:08, Martin Pieuchot wrote:
> As exposed recently via the t_ptrace regression and some make changes an
> exit status might reported twice to its parent via wait(2).
>
> The diff below fixes that by making sure we do not re-parent a child to
> the same parent.
&
As exposed recently via the t_ptrace regression and some make changes an
exit status might reported twice to its parent via wait(2).
The diff below fixes that by making sure we do not re-parent a child to
the same parent.
With it the above mentioned regression as well as the ptrace one that
I'm p
On 04/02/20(Tue) 13:13, Amit Kulkarni wrote:
> [...]
> 'ci' changes after we proceed to another cpu, and cost will be different for
> each cpu+proc combination.
Look at at line 516 of kern/kern_sched.c doest the first argument of
sched_proc_to_cpu_cost() change?
> Actually, in the steal case, if
On 04/02/20(Tue) 08:43, Amit Kulkarni wrote:
> When a cpu is idle, and wants to steal, it should steal from worst loaded
> cpu, i.e. with the highest cost, not the least cost.
What you say might be a valid choice. However I'm not sure to
understand how does it relate to the behavior of the code?
As recently profiled, the softnet thread which runs mostly without
KERNEL_LOCK() is still somehow serialized with the rest of the kernel.
This is because the various subsystems to notify userland, either via
poll(2)/select(2), kqueue(2) or pgsignal(9) still require this lock.
We worked around thi
On 02/02/20(Sun) 09:58, Visa Hankala wrote:
> tty(4) uses custom code for revoking knotes. It should be changed to use
> klist_invalidate() to handle the revocation in one place. The following
> diff does that.
Great, your diff is ok mpi@
> In addition, the patch makes the code store the tty cont
On 31/01/20(Fri) 13:46, Mike Larkin wrote:
> On Thu, Jan 30, 2020 at 09:15:35AM +0100, Martin Pieuchot wrote:
> > On 21/01/20(Tue) 12:31, Martin Pieuchot wrote:
> > > On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> > > > Diff below is a refactoring of the actu
On 21/01/20(Tue) 12:31, Martin Pieuchot wrote:
> On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> > Diff below is a refactoring of the actual em(4) code and defines that
> > will allows me to present a shorter diff to interrupt multiple CPUs and
> > make use of multipl
Hi
Attached a diff to bring the disklabel man page up to date. Information
taken directly from editor.c line 95.
Best,
Martin
Index: disklabel.8
===
RCS file: /cvs/src/sbin/disklabel/disklabel.8,v
retrieving revision 1.138
diff -u
On 23/01/20(Thu) 13:38, Mark Kettenis wrote:
> Martin Pieuchot schreef op 2020-01-23 11:28:
> > [...]
> > We currently have 6 drivers using pci_intr_map_msix(). Since we want to
> > be able to specify a CPU should we introduce a new function like in the
> > diff bel
I'd like to make progress towards interrupting multiple CPUs in order to
one day make use of multiple queues in some network drivers. The road
towards that goal is consequent and I'd like to proceed in steps to make
it easier to squash bugs. I'm currently thinking of the following steps:
1. Is
On 23/01/20(Thu) 08:26, Patrick Wildt wrote:
> Hi,
>
> this is the second attempt of a diff that prepares acpivout(4) to work
> with the X395. The previous one broke due to recursive ACPI locking.
>
> So apparently we cannot change the brightness using the acpivout(4) ACPI
> methods. Instead we
On 22/01/20(Wed) 14:56, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote:
> >
> > > dt(4) is a debugging interface that allows userland to read kernel
> > > addresses. So its access should be restri
Major 30 is taken on both platforms, so use 32 to give a chance for
people to use dt(4) and btrace(8) on these platforms.
Ok?
===
RCS file: /cvs/src/etc/etc.alpha/MAKEDEV.md,v
retrieving revision 1.72
diff -u -p -r1.72 MAKEDEV.md
---
On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> should not size the size until the allocation succeeds, or the free path will
> try to deref the null array.
>
>
> Index: json.c
> ===
> RCS file: /home/cvs/src/usr.sbin/
Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel
addresses.
Diff below makes `allowkmem' a requirement for opening the
pseudo-device.
ok?
Index: sys/dev/ksyms.c
===
RCS file: /cvs/src/sys/dev/ksyms.c,v
retrieving r
dt(4) is a debugging interface that allows userland to read kernel
addresses. So its access should be restricted by default, just like
mem(4).
Diff prevent opening the pseudo-device unless `allowkmem' is set.
ok?
Index: sys/dev/dt/dt_dev.c
===
On 16/01/20(Thu) 11:20, Martin Pieuchot wrote:
> While discussing recent config_detach(9) vs close(2) race I figured
> out that the 'indirect' flag (`cd_indirect') is never set.
>
> Time to kill this feature?
>
> This survived build on x86, armv7, sgi, hppa, l
On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> Diff below is a refactoring of the actual em(4) code and defines that
> will allows me to present a shorter diff to interrupt multiple CPUs and
> make use of multiple queues.
>
> It contains the following items:
>
> - Ab
On 20/01/20(Mon) 07:19, Mark Kettenis wrote:
> > [...]
> > I'd appreciate particular review of the following items:
> >
> > * Event producer/consumer code which currently needs a mutex. The
> >current implementation doesn't always use a PCB per-CPU. Moving
> >to a lockless implementati
Diff below is a refactoring of the actual em(4) code and defines that
will allows me to present a shorter diff to interrupt multiple CPUs and
make use of multiple queues.
It contains the following items:
- Abstract the allocation/freeing of TX/RX ring into em_dma_malloc().
This will ease th
On 14/01/20(Tue) 17:16, Martin Pieuchot wrote:
> On 13/01/20(Mon) 21:31, Martin Pieuchot wrote:
> > I'd like hardclock() to be free of SCHED_LOCK(), the diff below brings
> > us one step away from that goal. Please test with your favorite
> > benchmark and report any r
On 18/01/20(Sat) 14:16, Martin Pieuchot wrote:
> When futex(2) got imported it didn't return ECANCELED. This was changed
> later with futex-based semaphores.
>
> This modification introduced a behavior change in pthread_cond_*wait(3).
> The diff below restores the previous
When futex(2) got imported it didn't return ECANCELED. This was changed
later with futex-based semaphores.
This modification introduced a behavior change in pthread_cond_*wait(3).
The diff below restores the previous behavior by treating ECANCELED like
EINTR.
Note that the __thrsleep(2) version
On 16/01/20(Thu) 12:01, Theo de Raadt wrote:
> +# Keep in sync with /sys/kern/syscalls.c
> +SRCS+= syscalls.c
>
> But that trick never works!
>
> Why not compile from ../../sys/kern/syscalls.c?
Nice! That would work indeed :)
ed-variable
+CFLAGS+= -I${.CURDIR}
+
+LDADD+= -lelf
+DPADD+=${LIBELF}
+
+DEBUG?=-g
+
+.include
diff --git usr.sbin/btrace/bt.5 usr.sbin/btrace/bt.5
new file mode 100644
index 000..bfdaafc7725
--- /dev/null
+++ usr.sbin/btrace/bt.5
134)
_DEV(hotplug, 124)
_DEV(oppr)
Index: share/man/man4/dt.4
===
RCS file: share/man/man4/dt.4
diff -N share/man/man4/dt.4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man4/dt.4 16 Jan 2020 18:34:24 -
@@ -0,0 +1,47 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2019 M
While discussing recent config_detach(9) vs close(2) race I figured
out that the 'indirect' flag (`cd_indirect') is never set.
Time to kill this feature?
This survived build on x86, armv7, sgi, hppa, luna88k, alpha, landisk,
sparc64.
Ok?
Index: sys/sys/device.h
=
Found while compiling sgi kernel:
/sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
(aka 'signed char') changes value from 148 to -108
[-Werror,-Wconstant-conversion]
ra->ipopt_list[0] = IPOPT_RA;
~ ^~~~
/sys/netinet/ip.
601 - 700 of 3387 matches
Mail list logo
