On Sat, Oct 08, 2022 at 11:22:59AM -0600, Todd C. Miller wrote:
> On Sat, 08 Oct 2022 16:01:18 -, Klemens Nanni wrote:
>
> > Account for this to make permanent redirection failure trigger the ERR
> > trap:
> >
> > $ ./obj/ksh -c 'trap "echo ERR" ERR ; exec >/'
> > ksh: cannot create /:
On Sat, 08 Oct 2022 16:01:18 -, Klemens Nanni wrote:
> Account for this to make permanent redirection failure trigger the ERR
> trap:
>
> $ ./obj/ksh -c 'trap "echo ERR" ERR ; exec >/'
> ksh: cannot create /: Is a directory
> ERR
>
> Also add three new regress cases covering
Failure to permanently redirect I/O for the shell itself, i.e. when no
command is executed, must trigger the ERR trap like any other failure,
but that is currently not happening:
(non-zero exit code is trigger, no redirection)
$ ksh -c 'trap "echo ERR" ERR ; false'
This won't fly since an exact argc check breaks the case where a disk
and an explicit first stage is given while for the second stage the
default is used:
installboot sd0 /usr/mdec/biosboot
Also, the following mistyped/bogus usages are still argc-valid regarless
of this diff:
insta
Just forgot to pass the disk during sparc64 tests and was surprised to
see it treating a file as disk:
# installboot -nv /usr/mdec/bootblk /ofwboot.test
Using / as root
would install bootstrap on ./usr/mdec/bootblk
using first-stage ./ofwboot.test, second-stage /usr
> but please wait with putting in further diffs until Theo has started
> building snaps
That is very important: continual community testing of snapshot kernels
is incredibly important, otherwise layers of related commits can happen,
and it becomes harder to diagnose introduced problems.
> Date: Fri, 1 Oct 2021 20:07:20 +0200
> From: Martin Pieuchot
>
> amaps operation are already serialized by their own lock so it is
> possible to free them w/o holding the KERNEL_LOCK(). This has been
> tested by many as part of the UVM unlocking diff.
>
> ok?
ok ke
amaps operation are already serialized by their own lock so it is
possible to free them w/o holding the KERNEL_LOCK(). This has been
tested by many as part of the UVM unlocking diff.
ok?
Index: uvm/uvm_map.c
===
RCS file: /cvs/src
> Date: Thu, 9 Sep 2021 17:03:54 +0200
> From: Martin Pieuchot
>
> The check to avoid a panic for contented rwlock(9) should be outside of
> #ifdef DIAGNOSTIC.
>
> ok?
ok kettenis@
> Index: kern//kern_synch.c
> ===
> RCS file: /c
The check to avoid a panic for contented rwlock(9) should be outside of
#ifdef DIAGNOSTIC.
ok?
Index: kern//kern_synch.c
===
RCS file: /cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.177
diff -u -p -r1.177 kern_synch.c
--- ke
;legacy' driver.
>
> While our code expects (and requires) an I/O BAR, it seems to be that
> the PCI device only provides two memory BARs.
>
> Linux still works, probably because they don't care about the type.
> So I figured, let's just do that as well. With the
Hi,
so on the new Parallels version, when using the 'Other' OS setting,
virtio(4) won't attach. Apparently it's not Virtio 1.0, because even
Fedora 34 falls back to the 'legacy' driver.
While our code expects (and requires) an I/O BAR, it seems to be that
the PCI d
On Wed, Jul 28, 2021 at 10:33:05AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > With the current wording, I'd either expect usage error when passing
> > `-o output' or more wording explaining the behaviour when fetching
> > multiple files.
> >
Klemens Nanni wrote:
> With the current wording, I'd either expect usage error when passing
> `-o output' or more wording explaining the behaviour when fetching
> multiple files.
>
> Usage error seems wrong since our synopsis explicitly allows it, but
> writing the c
With the current wording, I'd either expect usage error when passing
`-o output' or more wording explaining the behaviour when fetching
multiple files.
Usage error seems wrong since our synopsis explicitly allows it, but
writing the contents behind multiple URLs into the same f
On Mon, Mar 08, 2021 at 11:07:01AM +0100, Martin Pieuchot wrote:
> On 04/03/21(Thu) 10:44, Martin Pieuchot wrote:
> > single_thread_clear() manipulates the same data structures as
> > single_thread_set() and, as such, doesn't need the KERNEL_LOCK().
> >
> > However cursig() does need some sort of
On 04/03/21(Thu) 10:44, Martin Pieuchot wrote:
> single_thread_clear() manipulates the same data structures as
> single_thread_set() and, as such, doesn't need the KERNEL_LOCK().
>
> However cursig() does need some sort of serialization to ensure that
> per-process data structures like signals, fl
single_thread_clear() manipulates the same data structures as
single_thread_set() and, as such, doesn't need the KERNEL_LOCK().
However cursig() does need some sort of serialization to ensure that
per-process data structures like signals, flags and traced-signum stay
consistent. So the diff below
On Wed, Sep 09, 2020 at 06:23:22PM +0200, Martin Pieuchot wrote:
> On 09/09/20(Wed) 10:02, Claudio Jeker wrote:
> > On Wed, Sep 09, 2020 at 08:33:30AM +0200, Martin Pieuchot wrote:
> > > Per-process data structures needed to suspend the execution of threads
> > > are since recently protected by the
On 09/09/20(Wed) 10:02, Claudio Jeker wrote:
> On Wed, Sep 09, 2020 at 08:33:30AM +0200, Martin Pieuchot wrote:
> > Per-process data structures needed to suspend the execution of threads
> > are since recently protected by the SCHED_LOCK(). So the KERNEL_LOCK()
> > dance inside issignal() is no lo
On Wed, Sep 09, 2020 at 08:33:30AM +0200, Martin Pieuchot wrote:
> Per-process data structures needed to suspend the execution of threads
> are since recently protected by the SCHED_LOCK(). So the KERNEL_LOCK()
> dance inside issignal() is no longer necessary and can be removed, ok?
This is not q
Per-process data structures needed to suspend the execution of threads
are since recently protected by the SCHED_LOCK(). So the KERNEL_LOCK()
dance inside issignal() is no longer necessary and can be removed, ok?
Note that CURSIG() is currently always called with the KERNEL_LOCK()
held so the cod
On Mon, 06 Jul 2020 22:22:36 +0200, Jeremie Courreges-Anglas wrote:
> Requested by ajacoutot@, here's an attempt at implementing set -o
> pipefail. As pointed by sthen@ this option should be included in the
> next POSIX standard:
>
> https://www.austingroupbugs.net/view.
Requested by ajacoutot@, here's an attempt at implementing set -o
pipefail. As pointed by sthen@ this option should be included in the
next POSIX standard:
https://www.austingroupbugs.net/view.php?id=789
There are several ways to implement it, the diff I showed to Antoine was
bas
On 09/04/20(Thu) 20:07, Vitaliy Makkoveev wrote:
> usb_detach_wait() will simply wait usb_detach_wakeup() for 60 sec. So
> ugen_detach() will continue to destroy device context before threads
> finish their io.
Is it a theory or is it a fact? If it's a theory how can one be sure
the proposed chan
usb_detach_wait() will simply wait usb_detach_wakeup() for 60 sec. So
ugen_detach() will continue to destroy device context before threads
finish their io.
Index: sys/dev/usb/ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrievi
On Thu, Nov 14, 2019 at 1:36 PM Christian Weisgerber
wrote:
> I found this discrepancy surprising:
>
> $ find /bin -print | cpio -o -Hustar >foo
> $ file foo
> foo: POSIX tar archive
> $ find /bin -print | cpio -Hustar -o >foo
> $ file foo
> foo: ASCII cpio a
Klemens Nanni:
> cpio -o [-AaBcjLvZz] [-C bytes] [-F archive] [-H format] [-O archive]
> < name-list [> archive]
> cpio -i [-6BbcdfjmrSstuvZz] [-C bytes] [-E file] [-F archive] [-H format]
> [-I archive] [pattern ...] [< archive]
> cpio -p [-adLlmuv] destinati
On Thu, Nov 14, 2019 at 10:09:20PM +0100, Christian Weisgerber wrote:
> The argument order should not matter here.
The synopsis however seems to dictate it coming first:
cpio -o [-AaBcjLvZz] [-C bytes] [-F archive] [-H format] [-O archive]
< name-list [> archive]
cpio -i [-6Bbcdfj
I found this discrepancy surprising:
$ find /bin -print | cpio -o -Hustar >foo
$ file foo
foo: POSIX tar archive
$ find /bin -print | cpio -Hustar -o >foo
$ file foo
foo: ASCII cpio archive (SVR4 with CRC)
The argument order should not matter here.
Fix
Maximilian Lorlacks wrote:
> This looks okay to me.
>
> (plus two months ping)
oh, good news, committed two months ago. sorry, forgot to reply.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 16, 2019 8:19 PM, Ted Unangst wrote:
>
> > Oh, right, I reworded it slightly, but I think th
This looks okay to me.
(plus two months ping)
‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 8:19 PM, Ted Unangst wrote:
> Oh, right, I reworded it slightly, but I think this is something we should
> note.
>
> Index: fsync.2
>
> =
selwakeup() does a filtered wakeup because all threads waiting in
poll(2) or select(2) are blocking on the same wait channel.
The wakeup is currently implemented by first grabbing a reference
to a thread via tfind(). This makes removing the KERNEL_LOCK()
complicated because we need to ensure the
On 21/04/19(Sun) 16:45, Martin Pieuchot wrote:
> Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
>
> To do so, it redefines the ifp <-> bridge relationship. Currently every
> interface in a bridge(4) contains a pointer to that bridge's port. This
> relationship is guarant
> On 22 Apr 2019, at 5:45 am, Martin Pieuchot wrote:
>
> Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
>
> To do so, it redefines the ifp <-> bridge relationship. Currently every
> interface in a bridge(4) contains a pointer to that bridge's port. This
> relationsh
Hi,
tried it on a router with three bridges (etherip/vether over IPSec and
vxlan/vlan) and it works, if you want dmesg/ifconfig output I'll send it to you.
Regards,
S. Rudzio
Am So., 21. Apr. 2019 um 21:47 Uhr schrieb Martin Pieuchot :
>
> Diff below removes the KERNEL_LOCK() from bridge(4)'s o
Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
To do so, it redefines the ifp <-> bridge relationship. Currently every
interface in a bridge(4) contains a pointer to that bridge's port. This
relationship is guaranteed to be valid as long as the KERNEL_LOCK() is
held. We
Oh, right, I reworded it slightly, but I think this is something we should
note.
Index: fsync.2
===
RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v
retrieving revision 1.14
diff -u -p -r1.14 fsync.2
--- fsync.2 10 Sep 2015 17:55:2
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, February 16, 2019 7:40 AM, Maximilian Lorlacks
wrote:
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm
> alexander.bl...@gmx.net wrote:
>
> > On Thu, Jan 31, 2019 at
On Sat, Feb 16, 2019 at 07:40:42AM +, Maximilian Lorlacks wrote:
> People may object to errors being lost when the vnode is released,
> as that would lose errors in a scenario like write -> close -> open
> -> fsync.
Is there any guarantee an application will be operating on the same
underlying
On Saturday, February 16, 2019, Abel Abraham Camarillo Ojeda <
acam...@verlet.org> wrote:
>
>
> On Saturday, February 16, 2019, Maximilian Lorlacks <
> maxlor...@protonmail.com> wrote:
>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm <
>> alexande
On Saturday, February 16, 2019, Maximilian Lorlacks <
maxlor...@protonmail.com> wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm <
> alexander.bl...@gmx.net> wrote:
>
> > On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
> >
> > > Ins
‐‐‐ Original Message ‐‐‐
On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm
wrote:
> On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
>
> > Instead, we note that the write failed and mark a flag in the vnode. Future
> > calls to fsync will then return EIO when this fla
On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote:
> Instead, we note that the write failed and mark a flag in the vnode. Future
> calls to fsync will then return EIO when this flag is set. We clear the flag
> when the vnode is released.
Sounds reasonable.
OK bluhm@
> Index: kern/vfs_b
Ted Unangst wrote:
> > Keeping a buf with an error in the delayed write list would probably have
> > some
> > serious consequences. When would we ever remove it?
>
> Thought about this some more. The best approach may be to set a flag in
> the vnode that there was an IO error, and return that for
Ted Unangst wrote:
> Maximilian Lorlacks wrote:
> > Good day,
> >
> > It seems that fsync(2) may data after returning EIO once[1]. This
> > behaviour seems to cause problems with databases such as PostgreSQL
> > and goes contrary to the man page's description, which says that
> > "fsync() and fda
Maximilian Lorlacks wrote:
> Good day,
>
> It seems that fsync(2) may data after returning EIO once[1]. This
> behaviour seems to cause problems with databases such as PostgreSQL
> and goes contrary to the man page's description, which says that
> "fsync() and fdatasync() should be used by progra
Good day,
It seems that fsync(2) may data after returning EIO once[1]. This
behaviour seems to cause problems with databases such as PostgreSQL
and goes contrary to the man page's description, which says that
"fsync() and fdatasync() should be used by programs that require a
file to be in a known
On 2019-01-19 16:09:05, Ted Unangst wrote:
> Bryan Linton wrote:
> > Hello tech@,
> >
> > I'd appreciate it if someone could review both this patch and my
> > analysis.
>
> There is no reason for etime to be a global. We can make it a local with the
> correct value in the two functions that use
Bryan Linton wrote:
> Hello tech@,
>
> I'd appreciate it if someone could review both this patch and my
> analysis.
There is no reason for etime to be a global. We can make it a local with the
correct value in the two functions that use it, avoiding future problems as
well.
Index: vmstat.c
On 2019-01-19 15:00:20, Otto Moerbeek wrote:
> On Sat, Jan 19, 2019 at 09:30:12PM +0900, Bryan Linton wrote:
>
> > Hello tech@,
> >
> > I'd appreciate it if someone could review both this patch and my
> > analysis.
> >
> > [...]
> >
> > ADDENDUM
> >
> >
> > I'm curious why iostat.c u
On Sat, Jan 19, 2019 at 09:30:12PM +0900, Bryan Linton wrote:
> Hello tech@,
>
> I'd appreciate it if someone could review both this patch and my
> analysis.
>
>
> PROBLEM
> ---
> When running systat, the vmstat page shows inaccurate numbers for
Hello tech@,
I'd appreciate it if someone could review both this patch and my
analysis.
PROBLEM
---
When running systat, the vmstat page shows inaccurate numbers for
disk i/o speed (likely only on multiprocessor systems) when
compared to both the iostat page, as well as the stati
Now that almost all USB drivers match a properly configured device, we
can simplify them. Instead of calling usbd_device2interface_handle()
simply use the `iface' argument passed to the *attach() function. This
works well in uhub(4) because the interface 0 of the first configuration
is always use
Hi Raphael,
Raphael Graf wrote on Sat, Dec 22, 2018 at 03:32:45PM +0100:
> The html output contains nested anchor tags if the TABLE OF CONTENTS
> has a second level.
> For example, see http://man.openbsd.org/mdoc
>
> The diff closes the anchor tag before printing the 'ul' of the second level.
I
The html output contains nested anchor tags if the TABLE OF CONTENTS
has a second level.
For example, see http://man.openbsd.org/mdoc
The diff closes the anchor tag before printing the 'ul' of the second level.
Index: mdoc_html.c
==
d to
> be able to export private keys as RFC4716 format.
OK.
> > I also noticed that the -f flag with -A was documented in ssh-keygen(1)
> > but not in usage, so I updated usage to match ssh-keygen(1).
> >
> > OKs for the diff below?
After I sent this email, djm@ made ch
On 4 August 2018 at 18:15, Jeremy Evans wrote:
[...]
> I checked -A and that also respects -o, so I documented that. I'm
> not sure how much it matters as the host keys -A generates are not
> password protected, but maybe there are other reasons to use the
> newer format.
The
bgw
device islrtc
attach islrtc at i2c
file dev/i2c/isl1208.c islrtc
+
+# NXP PCF8574 I/O port expander
+device pcfgpio: gpiobus
+attach pcfgpio at i2c
+file dev/i2c/pcf8574.c pcfgpio
Index: sys/dev/i2c/pcf8574.c
On Sat, Aug 04, 2018 at 01:15:14AM -0700, Jeremy Evans wrote:
> On 08/03 09:28, Jeremy Evans wrote:
> > The ssh-keygen -o flag wasn't listed in the synopsis, and -a was only
> > listed with -T (where it specifies the number of primality tests), not
> > for specifying t
On 08/03 09:28, Jeremy Evans wrote:
> The ssh-keygen -o flag wasn't listed in the synopsis, and -a was only
> listed with -T (where it specifies the number of primality tests), not
> for specifying the number of KDF rounds of new-format private key files.
>
> I only tested cr
On Fri, Aug 03, 2018 at 09:28:52PM -0700, Jeremy Evans wrote:
> The ssh-keygen -o flag wasn't listed in the synopsis, and -a was only
> listed with -T (where it specifies the number of primality tests), not
> for specifying the number of KDF rounds of new-format private key file
The ssh-keygen -o flag wasn't listed in the synopsis, and -a was only
listed with -T (where it specifies the number of primality tests), not
for specifying the number of KDF rounds of new-format private key files.
I only tested creating a new private key and conversion of existing
keys with
t socket *head, int conns
/*
* XXXSMP as long as `so' and `head' share the same lock, we
-* can call soreserve() and pr_attach() below w/o expliclitly
-* locking `so'.
+* can call soqinsque() below w/o expliclitly locking `so'.
I rely on the `-s' flag to fstat(1) for a lot of dev work. It's a bit
of a pain sometimes that the I/O counter returned has only KByte
granularity.
I've been modifying fstat.c as needed. This time I considered whether
sending a patch would be acceptable. It simply adds a `-b&
On 18/04/18(Wed) 12:06, Martin Pieuchot wrote:
> On 16/04/18(Mon) 12:33, Martin Pieuchot wrote:
> > Diff below is a rewrite/cleanup of fdcopy() to avoid using memcpy().
> >
> > The problem with the memcpys is that they introduce a window where
> > some 'struct file *' are duplicated without being
On 16/04/18(Mon) 12:33, Martin Pieuchot wrote:
> Diff below is a rewrite/cleanup of fdcopy() to avoid using memcpy().
>
> The problem with the memcpys is that they introduce a window where
> some 'struct file *' are duplicated without being refcounted. We
> should instead use the following common
Diff below is a rewrite/cleanup of fdcopy() to avoid using memcpy().
The problem with the memcpys is that they introduce a window where
some 'struct file *' are duplicated without being refcounted. We
should instead use the following common idiom:
FREF(fp);
fdp->fd_ofiles[i] = fp
When memory mapped I/O isn't enabled, we disable the associated
windows. Do the same for "port" I/O. Otherwise we will (incorrectly)
advertise that I/O space is available to devices downstream from the
bridge.
ok?
Index
On Tue, Jan 09, 2018 at 11:24:14AM +0100, Martin Pieuchot wrote:
> On 02/01/18(Tue) 16:04, Martin Pieuchot wrote:
> > New year, new diff. Assuming we can live with the kqueue(2) races,
> > here's a diff to remove the KERNEL_LOCK() from all pr_input() routines.
> >
> > I'd appreciate tests.
>
> I
On 02/01/18(Tue) 16:04, Martin Pieuchot wrote:
> New year, new diff. Assuming we can live with the kqueue(2) races,
> here's a diff to remove the KERNEL_LOCK() from all pr_input() routines.
>
> I'd appreciate tests.
I got multiple positive reports, I'd like to commit this to see if
anything brea
New year, new diff. Assuming we can live with the kqueue(2) races,
here's a diff to remove the KERNEL_LOCK() from all pr_input() routines.
I'd appreciate tests.
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revisi
next(k), hence it must be floor(k). Using the
> > > > conventional integer value of a boolean expression, this result can be
> > > > summarised as
> > > >
> > > > next(log_10(x)) = floor(k) + (x >= 10^floor(k)).
> > > >
> > &g
t; > next(log_10(x)) cannot be next(k), hence it must be floor(k). Using the
> > > > conventional integer value of a boolean expression, this result can be
> > > > summarised as
> > > >
> > > > next(log_10(x)) = floor(k) + (x >= 10^floor(k)).
> >
an additional refinement, one may further notice that if
> > >
> > > floor(k) = floor(log_10(2) * floor(log_2(x)))
> > >
> > > then
> > >
> > > 10^floor(k) = 10^floor(log_10(2) * floor(log_2(x)))
> > > <= 10^(log_
al refinement, one may further notice that if
> >
> > floor(k) = floor(log_10(2) * floor(log_2(x)))
> >
> > then
> >
> > 10^floor(k) = 10^floor(log_10(2) * floor(log_2(x)))
> > <= 10^(log_10(2) * floor(log_2(x)))
> >
)).
>
> As an additional refinement, one may further notice that if
>
> floor(k) = floor(log_10(2) * floor(log_2(x)))
>
> then
>
> 10^floor(k) = 10^floor(log_10(2) * floor(log_2(x)))
> <= 10^(log_10(2) * floor(log_2(x)))
>
On Tue, Nov 28 2017, Alexander Bluhm wrote:
> On Tue, Nov 28, 2017 at 02:42:58PM +0100, Martin Pieuchot wrote:
>> > login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed:
>> > file "/usr/src/sys/kern/uipc_socket.c", line 1882
>> > Stopped at db_enter+0x4: popl%ebp
>
>
On Tue, Nov 28, 2017 at 02:42:58PM +0100, Martin Pieuchot wrote:
> > login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed:
> > file "/usr/src/sys/kern/uipc_socket.c", line 1882
> > Stopped at db_enter+0x4: popl%ebp
Next crash, now during regress/usr.bin/openssl. Look
On 27/11/17(Mon) 14:01, Alexander Bluhm wrote:
> On Mon, Nov 27, 2017 at 12:20:34PM +0100, Martin Pieuchot wrote:
> > Questions, comments, tests?
>
> New panic with regress. I think it was sys/kern/sosplice this time.
>
> login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed: fi
On Mon, Nov 27, 2017 at 12:20:34PM +0100, Martin Pieuchot wrote:
> Questions, comments, tests?
New panic with regress. I think it was sys/kern/sosplice this time.
login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed: file
"/usr/src/sys/kern/uipc_socket.c", line 1882
Stopped at
On 20/11/17(Mon) 16:22, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK() around all pr_input() routines.
> It's a bit rough so I'd appreciate more tests before splitting it into
> pieces.
>
> I'm using tasks to delay selwakeup/csignal calls, just like I did for
> bpf(4).
Updated versi
r(log_2(x))
<= x
so that it can readily be concluded that
next(log_10(x)) = next(k)
without having to compute 10^floor(k).
The BN library permits computation of k in O(1) and 10^floor(k) in
O(log(k)) which is O(log(log(x))). Therefore, one can compute
next(log_1
alizing access to
> `sb_flags'.
>
> We're now moving towards running sockets functions w/o KERNEL_LOCK()
> in protocol input paths. So I'd like to assert that the socket lock
> is held when sb_flags are modified.
>
> There's currently one exception to this rule,
On Wed, Nov 22, 2017 at 12:19:49PM +0100, Martin Pieuchot wrote:
> On 22/11/17(Wed) 11:05, Martin Pieuchot wrote:
> > ip_deliver() dispatches incoming packets to their corresponding protocol
> > input function. It doesn't need the KERNEL_LOCK(), so remove the assert
> > and mark the dispatch table
When we converted most of the splsoftnet() to NET_LOCK() we ended up
with some "lock" inversions between the socket buffer "lock" and the
NET_LOCK(). At that time the KERNEL_LOCK() was serializing access to
`sb_flags'.
We're now moving towards running sockets
On 22/11/17(Wed) 11:05, Martin Pieuchot wrote:
> ip_deliver() dispatches incoming packets to their corresponding protocol
> input function. It doesn't need the KERNEL_LOCK(), so remove the assert
> and mark the dispatch tables as 'const' all over the kernel.
>
> ok?
I missed netinet6/ bits in th
ip_deliver() dispatches incoming packets to their corresponding protocol
input function. It doesn't need the KERNEL_LOCK(), so remove the assert
and mark the dispatch tables as 'const' all over the kernel.
ok?
Index: kern/uipc_domain.c
ket/1
cc -O2 -pipe -I/usr/src/regress/lib/libpthread/socket/1/../../include -Wall
-DSRCDIR='"/usr/src/regress/lib/libpthread/socket/1"'
-I/usr/src/regress/lib/libpthread/socket/1/../include -MD -MP -c
/usr/src/regress/lib/libpthread/socket/1/socket1.c
cc -o socket1 socket1
Diff below remove the KERNEL_LOCK() around all pr_input() routines.
It's a bit rough so I'd appreciate more tests before splitting it into
pieces.
I'm using tasks to delay selwakeup/csignal calls, just like I did for
bpf(4).
Questions, Comments?
Index: kern/uipc_socket.c
Including doesn't require , is
enough.
ok?
Index: gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.284
diff -u -p -r1.284 sysctl.3
--- gen/sysctl.316 Oct 2017 15:09:43 - 1.284
+++ g
On 16/10/17(Mon) 12:47, Martin Pieuchot wrote:
> On 11/10/17(Wed) 17:01, Martin Pieuchot wrote:
> > OpenBSD 6.2 includes nice performance and latency improvements due to
> > the work done in the Network Stack in the previous years. However as
> > soon as IPsec is enabled, all network related proce
Stuart Henderson writes:
> On 2017/10/21 14:52, Tim Stewart wrote:
>> Stuart Henderson writes:
>>
>> > On 2017/10/21 12:04, Tim Stewart wrote:
>> >> *49727 296965 0 0 7 0x14200crynlk
>> >
>> > aha, it was that one. Try this diff on top.
>> >
>> > Index: fpu.c
>>
On 2017/10/21 14:52, Tim Stewart wrote:
> Stuart Henderson writes:
>
> > On 2017/10/21 12:04, Tim Stewart wrote:
> >> *49727 296965 0 0 7 0x14200crynlk
> >
> > aha, it was that one. Try this diff on top.
> >
> > Index: fpu.c
> >
Stuart Henderson writes:
> On 2017/10/21 12:04, Tim Stewart wrote:
>> *49727 296965 0 0 7 0x14200crynlk
>
> aha, it was that one. Try this diff on top.
>
> Index: fpu.c
> ===
> RCS file: /cvs/src/sys/a
On 2017/10/21 12:06, Tim Stewart wrote:
>
> Stuart Henderson writes:
>
> > On 2017/10/21 10:33, Tim Stewart wrote:
> >> I don't have much experience with capturing OpenBSD kernel panics. I've
> >> set up screen on another system so that I'll have a log of serial
> >> console activity (this is a
On 2017/10/21 12:04, Tim Stewart wrote:
> *49727 296965 0 0 7 0x14200crynlk
aha, it was that one. Try this diff on top.
Index: fpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/fpu.c,v
retrieving revis
Stuart Henderson writes:
> On 2017/10/21 10:33, Tim Stewart wrote:
>> I don't have much experience with capturing OpenBSD kernel panics. I've
>> set up screen on another system so that I'll have a log of serial
>> console activity (this is an apu2c4) and have set ddb.console=1. I will
>> also
Tim Stewart writes:
> Martin Pieuchot writes:
>
>> On 11/10/17(Wed) 17:01, Martin Pieuchot wrote:
>>> OpenBSD 6.2 includes nice performance and latency improvements due to
>>> the work done in the Network Stack in the previous years. However as
>>> soon as IPsec is enabled, all network related
On 2017/10/21 10:33, Tim Stewart wrote:
> I don't have much experience with capturing OpenBSD kernel panics. I've
> set up screen on another system so that I'll have a log of serial
> console activity (this is an apu2c4) and have set ddb.console=1. I will
> also reboot with bsd.gdb this time.
Do
1 - 100 of 274 matches
Mail list logo
