On 07/04/20(Tue) 17:14, Vitaliy Makkoveev wrote:
> As Claudio Jeker noticed, NET_LOCK() can release KERNEL_LOCK(). pppx(4)
> code has some NET_LOCK() dances which make it unsafe. [...]
The easiest way to fix that is to move if_detach() out of pppx_if_destroy().
It generally makes sense to call
fifo_poll() honors FREAD and FWRITE. It doesn't return events
incompatible with the open flags. Diff below makes the kqfilters
behave like that as well.
ok?
Index: kern/tty_tty.c
===
RCS file: /cvs/src/sys/kern/tty_tty.c,v
The write socket should be passed to the write filter otherwise checks
are performed against the wrong socket.
ok?
Index: miscfs/fifofs/fifo_vnops.c
===
RCS file: /cvs/src/sys/miscfs/fifofs/fifo_vnops.c,v
retrieving revision 1.73
On 04/04/20(Sat) 22:30, Philip Guenther wrote:
> [...]
> glibc has internal inline functions futex_wait() and futex_wake() and
> there has been at least discussion about exporting some version of them.
> If our signatures matched the last-best-proposal over there (which was
> dropped, mind
On 02/04/20(Thu) 13:44, Vitaliy Makkoveev wrote:
> This diff add ownership checks to the rest pipex_ioctl() commands. A few
> words about pppx_get_closed(): since in-kernel timeout feature was
> disabled for pppx(4) related pipex_sessions, closed pipex_sessions can't
> exist in system, so this
On 03/04/20(Fri) 19:26, Philip Guenther wrote:
> On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> > Depending on the operation requested futex(2) might return the number of
> > woken threads or an error. That means the following...
> >
> > mpv CALL
> > futex(
Depending on the operation requested futex(2) might return the number of
woken threads or an error. That means the following...
mpv CALL futex(0xa58935899b0,0x82,1,0,0)
mpv RET futex -1 errno 1 Operation not permitted
...is not an error but it indicates that 1 thread has been
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
+++
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 retri
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 incoh
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*
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
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
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 =
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()
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
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
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 below has msix
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_sess
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
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
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
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 the
> &g
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
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
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
>
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 complain tha
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_t
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
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:
> >
> > Term
On 19/03/20(Thu) 17:43, Klemens Nanni wrote:
> Index: bt.5
> ===
> RCS file: /cvs/src/usr.sbin/btrace/bt.5,v
> retrieving revision 1.3
> diff -u -p -r1.3 bt.5
> --- bt.5 18 Mar 2020 20:19:42 - 1.3
> +++ bt.5 19 Mar
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
> > > machi
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
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, , ps_list)
> > if (pr->ps_tracevp == vp
Diff below allows ix(4) and em(4) to establish two MSI-X handlers.
Multiqueue support is intentionally not included in this diff.
One handler is for the single queue (index ":0") and one for the
link interrupt:
# vmstat -i |grep ix0
irq114/ix0:0 73178178 3758
irq115/ix0
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
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:
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
---
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
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
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 red
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
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
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
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
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
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(>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
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.
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
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 below turn
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
>
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
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,
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
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
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
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
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 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 b
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
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
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
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, luna88k, alpha,
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
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
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 rep
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 behav
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 :)
+
+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
@@ -0,0 +1,126 @@
+.\"$OpenBSD$
an4/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 Martin Pieuchot
+.\"
+.\" Permission to
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;
~ ^~~~
On 14/01/20(Tue) 17:30, Martin Pieuchot wrote:
> On 14/01/20(Tue) 10:34, Jonathan Gray wrote:
> > On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > > I'm facing a lock ordering issue while profiling the scheduler which
> > > cannot be solved wit
On 14/01/20(Tue) 18:37, Scott Cheloha wrote:
> Ticks to milliseconds.
> [...]
> @@ -303,16 +304,17 @@ lptpushbytes(struct lpt_softc *sc)
> while (NOT_READY()) {
> if (++spin < sc->sc_spinmax)
> continue;
> -
501 - 600 of 2703 matches
Mail list logo
