Amend the manual, per POSIX [0], the function "shall unblock at least
one of the threads".
This can happen in our implementation when the function is called w/o
holding the corresponding mutex. If a thread is blocking on the futex
lock, the sequence number will change and futex(2) will return EAG
Some plumbing to makes upcoming locking changes easier to review:
- Move the `m_len' check first, this does require any locking and will
save us a lock/unlock dance.
- Use the `!ETHER_IS_MULTICAST()' idiom to be coherent with the rest of
the driver. It is also clear that if the bridge(4) is
On 28/01/19(Mon) 13:36, David Gwynne wrote:
>
>
> > On 27 Dec 2018, at 5:42 pm, Claudio Jeker wrote:
> >
> > On Wed, Dec 26, 2018 at 09:27:59PM +0100, Denis Fondras wrote:
> >> Resend because of nasty typo :/
> >>
> >> On Mon, Dec 24, 2018 at
On 27/01/19(Sun) 01:02, Mark Kettenis wrote:
> > Date: Sat, 26 Jan 2019 14:46:41 -0200
> > From: Martin Pieuchot
> >
> > On MP machines, when a CPU executes mi_switch() and doesn't have any
> > thread on its runqueue it will try to steal one from another CPU&#x
If pfkeyv2_send() tries to send a message without a required extension
or with a non-allowed extension it will silently fail. I spent many
hours debugging the code exporting counters because of this. I'd like
to return an error code instead.
Ok?
Index: /sys/net/pfkeyv2.c
===
Last time I enabled this code, I forgot to whitelist the extension for
SADB_GET. Thanks to the help from Mark Patruck, who originally reported
the regression with iked(8) via bugs@, I came up with the diff below.
ok to enable it again?
Index: net/pfkeyv2.c
===
On MP machines, when a CPU executes mi_switch() and doesn't have any
thread on its runqueue it will try to steal one from another CPU's
runqueue. If it fails to steal a thread from another runqueue it
will pick its own Idle thread.
To decide which thread should be picked, the scheduler evaluate t
On 25/01/19(Fri) 11:16, Raphael Graf wrote:
> On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > Index: video.c
> > > ===
> > > RCS file: /cvs/xenocara/app/video/video.c,v
> > &
On 31/12/18(Mon) 16:58, Alexandre Ratchov wrote:
> Hi,
>
> Here's a new driver for both USB audio class (UAC) v1.0 and v2.0
> devices, it would replace the current one. It focuses on reliability
> and proper synchronization, including in low-latency configurations.
Some comments about the code.
Hello Raphael,
On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> Here is an attempt to make video(1) work with the modesetting driver.
> See https://marc.info/?l=openbsd-bugs&m=152231686416039&w=2
>
> The general idea:
> If there is no common encoding for input (device) and output (Xv), the
> encodin
Directly pass a pointer, which implies we have a valid reference for
the given interface. This will matters when we'll start using ifp
indexes.
ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revis
If a bridge(4) is down packets don't flow through it, so be coherent and
do not copy them for span ports.
ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.316
diff -u -p -r1.316 if_bridge.
On 09/01/19(Wed) 19:12, Theo de Raadt wrote:
> Philip Guenther wrote:
>
> > On Wed, Jan 9, 2019 at 1:11 AM Klemens Nanni wrote:
> >
> > > On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote:
> > > > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked
> > > trunks */
> >
The last extension type isn't set in pfkeyv2_sysctl_policydumper().
So fix the bug instead of working around it in export_counter().
ok?
Index: net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.193
diff
On 09/01/19(Wed) 10:11, Martin Pieuchot wrote:
> On 23/12/18(Sun) 14:41, Martin Pieuchot wrote:
> > Using SLIST() instead of TAILQ() is a step towards using lock-less
> > lists.
> >
> > As found in my previous attempts the interface list cannot be protected
> >
On 23/12/18(Sun) 14:41, Martin Pieuchot wrote:
> Using SLIST() instead of TAILQ() is a step towards using lock-less
> lists.
>
> As found in my previous attempts the interface list cannot be protected
> by a mutex as long a if_enqueue() might grab the KERNEL_LOCK(). So I'
On 26/12/18(Wed) 17:13, Denis Fondras wrote:
> On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
> > I'm not happy with adding the IFF_MULTICAST flag and SIOC{ADD,DEL}MULTI
> > ioctls. It seems to be a common pattern between in existing pseudo-driver,
> &g
On 25/12/18(Tue) 20:32, Martin Pieuchot wrote:
> Simple change to have verbose USB device fit into 80 chars in usbdevs(8):
New version using 'iSerial'. This is coherent w/ what lsusb(8) displays
and isn't ambiguous with regard to the device descriptor name as pointed
out by
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
ok?
Index: crypto/cryptosoft.c
===
RCS file: /cvs/src/sys/crypto/cryptosoft.c,v
retrieving revision 1.84
diff -u -p -r1.84 cryptosoft.c
--- crypto/cryptosoft.c 31 May 2018 19:40:58 - 1.84
+++ crypto/cryptosoft.c 29 Nov 2018 1
usbd_fill_deviceinfo() does not generate any I/O so there's no need to
call it from a USB thread. So the diff below kills usb_fill_di_task().
While here do not skip USB devices without attached drivers. If you
disable ugen(4) in your kernel they are properly handled. usbdevs(8)
will simply not
Simple change to have verbose USB device fit into 80 chars in usbdevs(8):
Before
==
$ usbdevs -v
addr 04: 0b95:1790 ASIX Elec. Corp., AX88179
high speed, power 248 mA, config 1, rev 1.00, iSerialNumber
133B8B1B30
driver: axen0
After
On 25/12/18(Tue) 21:16, Denis Fondras wrote:
> On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
> > It would be great if you could think the IPv4 version as well to take
> > a 'struct sockaddr' argument instead of a `struct in_ifaddr'.
> >
&g
On 25/12/18(Tue) 20:05, Denis Fondras wrote:
> On Tue, Dec 25, 2018 at 04:50:17PM -0200, Martin Pieuchot wrote:
> > On 25/12/18(Tue) 10:25, Denis Fondras wrote:
> > > On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
> > > > On 24/12/18(M
On 24/12/18(Mon) 20:07, Scott Cheloha wrote:
> On Tue, Dec 18, 2018 at 03:39:43PM -0600, Ian Sutton wrote:
> > On Mon, Aug 14, 2017 at 3:07 PM Martin Pieuchot wrote:
> > >
> > > I'd like to improve the fairness of the scheduler, with the goal of
> > > m
On 25/12/18(Tue) 10:25, Denis Fondras wrote:
> On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
> > On 24/12/18(Mon) 17:31, Denis Fondras wrote:
> > > Index: net/if_ethersubr.c
> > > ===
&
On 24/12/18(Mon) 17:31, Denis Fondras wrote:
> Thank you for the comments Martin. Here is an improved diff.
I think you should commit the icmp6_do_error() refactoring. It's ok mpi@
with some nits below.
It would be great if you could think the IPv4 version as well to take
a 'struct sockaddr' arg
Using SLIST() instead of TAILQ() is a step towards using lock-less
lists.
As found in my previous attempts the interface list cannot be protected
by a mutex as long a if_enqueue() might grab the KERNEL_LOCK(). So I'm
heading towards using SRPL_*().
Ok?
Index: net/if_bridge.c
==
On 18/12/18(Tue) 12:13, Denis Fondras wrote:
> Here is a serie of diffs to enable MPLSv6, MPLS transport over IPv6.
Nice!
> First diff : allow mpe(4) to handle IPv6 trafic.
Comments below
> Index: net/if_ethersubr.c
> ===
> RCS fi
On 20/12/18(Thu) 11:35, David Gwynne wrote:
> My last attempt in "let etherip(4) output directly to the ip stack"
> didn't go so well. This one at least doesn't break bridge(4) on
> Ethernet.
It breaks it on mpw(4).
> This diff effectively turns if_enqueue into a per interface function
> pointer.
On 12/12/18(Wed) 12:03, David Gwynne wrote:
> with the previous if_ethersubr.c diff, this allows etherip(4) to output
> directly to the network stack.
What do you mean with "directly"?
To my understanding ip{,6}_etherip_output() call ip{,6}_send() to enqueue
packets.
> direct output relies on t
- Unify the two hooks by passing the same argument
- Check for nullity before dereferencing `if_bridgeport', this will
matter when we go MP
- Use the same pattern to find a member in the ioctl path
ok?
Index: net/if_bridge.c
===
RC
ok?
Index: kern/sysv_shm.c
===
RCS file: /cvs/src/sys/kern/sysv_shm.c,v
retrieving revision 1.69
diff -u -p -r1.69 sysv_shm.c
--- kern/sysv_shm.c 15 Sep 2016 02:00:16 - 1.69
+++ kern/sysv_shm.c 11 Dec 2018 16:42:55 -0
ok?
Index: kern/sysv_sem.c
===
RCS file: /cvs/src/sys/kern/sysv_sem.c,v
retrieving revision 1.53
diff -u -p -r1.53 sysv_sem.c
--- kern/sysv_sem.c 14 Mar 2015 03:38:50 - 1.53
+++ kern/sysv_sem.c 11 Dec 2018 16:36:20 -0
Stop passing `sc' when it is not necessary. Also prefer passing the
brigde's ifp rather than `sc' when it's enough. This makes auditing
easier. Different structures need different locking.
As a bonus is removes an horrible cast in net/if_switch.c.
ok?
Index: net/if_bridge.c
==
bstp_create() is called on by bridge/switch_clone_create(). Nothing it
touches is reachable, so there's no need for splnet().
ok?
Index: net/bridgestp.c
===
RCS file: /cvs/src/sys/net/bridgestp.c,v
retrieving revision 1.66
diff -u -
Keep track of the allocated size and use it later :)
ok?
Index: kern/vfs_subr.c
===
RCS file: /cvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.282
diff -u -p -r1.282 vfs_subr.c
--- kern/vfs_subr.c 29 Sep 2018 04:29:48 -
On 01/12/18(Sat) 16:34, Anton Lindqvist wrote:
> On Tue, Nov 27, 2018 at 05:52:15PM -0800, Greg Steuck wrote:
> > I booted the patched kernel and it seems to have gone farther and I believe
> > reached init before crashing.
>
> By performing a semi-automated bisect I was able to identify the sourc
On 30/11/18(Fri) 13:49, Benjamin Baier wrote:
> Hi
>
> There is a leak of *arg in
> dev/usb/if_athn_usb.c:athn_usb_newauth() line 1263
> since Rev. 1.49
> Because athn_usb_do_async() memcpy's the argument anyway.
>
> Found with llvm/scan-build.
>
> Instead of adding free(arg) I opted to make th
On 30/11/18(Fri) 07:07, Edgar Pettijohn wrote:
> Here is a diff to remove the dubious example and fix one gramatical issue.
Thanks. Don't forget to use "mandoc -Tlint" to spot potentials errors
after a change. In this case you forgot to remove an ".Ed".
Keep the good work. All fuse manuals ne
On 29/11/18(Thu) 22:42, Alexandre Ratchov wrote:
> On Thu, Nov 29, 2018 at 04:51:19PM -0200, Martin Pieuchot wrote:
> > Trivial one, ok?
> >
> > Index: kern/sysv_msg.c
> > ===
> > RCS fil
On 30/11/18(Fri) 12:35, David Gwynne wrote:
> On Fri, Nov 30, 2018 at 12:21:11PM +1000, David Gwynne wrote:
> > i have a plan to allow virtual interfaces (eg, vlan, etherip, etc) to
> > provide their own output functions so they can bypass the ifq machinery
> > and push the packet onto the underlyi
On 29/11/18(Thu) 10:57, Edgar Pettijohn wrote:
> Mostly just typos. Corrected the example some. However, please see below. I
> don't
> think the example works or I'm just doing something wrong.
If we can fix the example, I'd say it's better to remove it. There are
other places to find documentat
Trivial one, ok?
Index: kern/sysv_msg.c
===
RCS file: /cvs/src/sys/kern/sysv_msg.c,v
retrieving revision 1.33
diff -u -p -r1.33 sysv_msg.c
--- kern/sysv_msg.c 15 Sep 2016 02:00:16 - 1.33
+++ kern/sysv_msg.c 29 Nov 201
This one is a bit tricky. In the indirect case, config_make_softc()
allocates a chunk corresponding to a given `cf->cf_attach->ca_devsize'.
ok?
Index: kern/subr_autoconf.c
===
RCS file: /cvs/src/sys/kern/subr_autoconf.c,v
retrieving
Trivial sizes, ok?
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.567
diff -u -p -r1.567 if.c
--- net/if.c12 Nov 2018 23:41:22 - 1.567
+++ net/if.c28 Nov 2018 20:57:21 -
@@ -1088,9 +10
Here's another diff to get rid of a driver attaching to a device in
unconfigured state. I'd like to convert them all to enforce that a
USB device can only be matched if the stack already managed to set
its configuration.
I'm looking for tests and oks.
Index: uticom.c
Instead of setting the configuration in the *match() routine let the
stack do it for us. This operation can fail, so it's better to not
attach any driver if something bad happens.
This change is similar to what I did with the rest of the drivers some
years ago when I fuzzed the stack.
I'm lookin
Instead of setting the configuration in the *match() routine let the
stack do it for us. This operation can fail, so it's better to not
attach any driver if something bad happens.
This change is similar to what I did with the rest of the drivers some
years ago when I fuzzed the stack.
I'm lookin
We need to keep track of the number of slots, so add a new field for
that.
ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.141
diff -u -p -r1.141 usb_subr.c
--- usb_subr.c 16 Nov 2018 11:5
Diff below uses the, already calculated, number of read-ahead buffers to
pass the correct size to free(9).
While here I unified the two loops calculating this number of buffers,
as we know for sure the first one isn't NULL.
ok?
Index: kern/vfs_bio.c
==
Pass the sizes of the interrupt and isochronous arrays to free(9).
While here convert a malloc(9) to mallocarray(9).
Untested for lack of hardware.
ok?
Index: uhci.c
===
RCS file: /cvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1
We already have the number of available interfaces in the configuration
descriptor, so use it to free the array.
ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.140
diff -u -p -r1.140 usb_s
On 12/11/18(Mon) 23:36, Ben Pye wrote:
> On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote:
> > On 11/11/18(Sun) 13:10, Ben Pye wrote:
> > > Hey all,
> > >
> > > In my quest for better OpenBSD support on my Chromebook 13 I have found
> &
On 09/11/18(Fri) 16:25, Ben Pye wrote:
> On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote:
> > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote:
> > > Hi all,
> > >
> > > This patch adds a new touchpad driver, elan(4), which supports older non
> > > PTP I2C Elantech
On 11/11/18(Sun) 13:10, Ben Pye wrote:
> Hey all,
>
> In my quest for better OpenBSD support on my Chromebook 13 I have found
> that sdmmc(4)'s current strategy for suspend/resume only really works
> for removable storage. Upon a suspend it marks the device as dying, and
> upon resume will detach
I'd like to protect bridge(4) data structures with a mutex. Using a
mutex is necessary because bridge_output() is called from interrupt
handlers in wireless drivers. This forces us to decouple data gathering
from copying to userland when executing some ioctl(2)s. Diff below does
that by moving t
The length of the configuration descriptor is already used in
usbd_parse_idesc(). The diff below reuses the same pattern to
add the size argument to free(9), ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retri
The driver already keeps track of the size of the allocated buffer, so
use it.
Diff is untested as I don't have a wi(4) @ USB.
ok?
Index: if_wi_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_wi_usb.c,v
retrieving revision 1.68
diff -u
The driver already keeps track of the number of ports, so use this piece
of information to free allocated structures.
Ok?
Index: uhub.c
===
RCS file: /cvs/src/sys/dev/usb/uhub.c,v
retrieving revision 1.90
diff -u -p -r1.90 uhub.c
---
Keep track of the number of allocated endpoints and use it when freeing
the array.
ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.138
diff -u -p -r1.138 usb_subr.c
--- usb_subr.c 19 Jul 2
I'd like to take brigde_input() & bridge_output() outside of the
KERNEL_LOCK(). My previous approach relying on the NET_LOCK() didn't
work because wireless drivers might call bridge_output() from their
interrupt handler.
So we'll need another mechanism. The first step would be to use a
mutex. O
On 18/10/18(Thu) 11:34, David Hill wrote:
> Hello -
>
> This diff splits the ctloutput functions into getopt/setopt, which could
> offer more fine-grained locking. It also removes some indentation and
> imo is easier to read.
>
> Thoughts?
Splitting the read and write path makes sense, it will
On 19/10/18(Fri) 12:15, Scott Cheloha wrote:
> Hi,
>
> If we introduce a mutex for the igmp module we can drop the NETLOCK
> from igmp_slowtimo(). The router_info list, rti_head, and its entries
> are only ever accessed within the igmp module. The mutex also needs
> to protect igmp_timers_are_ru
Diff below rename the remaining "struct bridge_iflist" variables to
`bif', cohérence oblige!
Ok?
Index: net/bridgectl.c
===
RCS file: /cvs/src/sys/net/bridgectl.c,v
retrieving revision 1.8
diff -u -p -r1.8 bridgectl.c
--- net/bridge
This is a requirement to get the bridge input/output path out of the
KERNEL_LOCK().
The diff is simple, use the non-locked version of SRP lists, as it is
already done in other paths in carp(4).
Ok?
Index: netinet/ip_carp.c
===
RCS f
I'd like to always use the same name of `bridge_iflist', it helps me
deal with the different data structures and their relation with `ifp'.
Diff below use `bif' everywhere, ok?
No intentional functional change.
Index: net/if_bridge.c
==
On 06/09/18(Thu) 23:01, Michael Mikonos wrote:
> Hello,
>
> In the umidi(4) driver the function alloc_all_endpoints_fixed_ep()
> returns USBD_NOMEM if mallocarray() fails, but the return value is
> always USBD_INVAL when 'goto error' happens. OK?
Note that it'd be better to *not* use `usbd_status
On 04/09/18(Tue) 14:59, Naoki Fukaumi wrote:
> hi tech@,
>
> "_nfiles" was renamed to "_numfiles" by this commit,
> https://marc.info/?l=openbsd-cvs&m=147199491615345&w=2
>
> then fstat/pstat put following errors,
>
> # fstat -M bsd.0.core -N bsd.0
> fstat: _nfiles: no such symbol
>
> # pst
Stop naming 'struct tdb *' `sa', we always use `tdb' in the rest of the
kernel.
No functional change, ok?
Index: net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.190
diff -u -p -r1.190 pfkeyv2.c
--- net/
On 09/08/18(Thu) 22:14, Stuart Henderson wrote:
> While looking into something unrelated I found a strange extra ::1
> address on lo1 (I usually hang my loopback addresses for IBGP off lo1).
>
> lo1: flags=8049 mtu 32768
> index 12 priority 0 llprio 3
> groups: lo
> inet xx
On 02/08/18(Thu) 13:06, Martin Pieuchot wrote:
> On 01/08/18(Wed) 01:53, Mark Kettenis wrote:
> > > Date: Tue, 31 Jul 2018 14:55:45 -0300
> > > From: Martin Pieuchot
> > >
> > > On 26/06/18(Tue) 12:31, Martin Pieuchot wrote:
> > > > These sys
On 01/08/18(Wed) 01:53, Mark Kettenis wrote:
> > Date: Tue, 31 Jul 2018 14:55:45 -0300
> > From: Martin Pieuchot
> >
> > On 26/06/18(Tue) 12:31, Martin Pieuchot wrote:
> > > These syscalls do two operations: they allocate FDs and some buffers.
> > > Th
On 26/06/18(Tue) 12:31, Martin Pieuchot wrote:
> These syscalls do two operations: they allocate FDs and some buffers.
> Thanks to the work done for sockets the file-related bits are now
> mp-safe, so we can push the KERNEL_LOCK() down.
>
> Diff below adds some KERNEL_LOCK/UNLOCK(
When a per-protocol attach function is called the given socket is not
yet reachable, so there's no need to lock it. So the diff below remove
the solock/sounlock dance and shows where the NET_LOCK() is required to
protect some specific global data structures.
I reordered the different blocks in al
On 12/07/18(Thu) 12:25, Martin Pieuchot wrote:
> Diff below extends 'struct usb_device_info' to include the port number
> where the USB device is attached to. It doesn't grow the structure and
> reuse implicit padding.
>
> I'd like to export the port number t
On 12/07/18(Thu) 17:53, Alexander Bluhm wrote:
> On Thu, Jul 12, 2018 at 02:38:48PM +0200, Martin Pieuchot wrote:
> > @@ -83,12 +91,6 @@ soo_ioctl(struct file *fp, u_long cmd, c
> > switch (cmd) {
> >
> > case FIONBIO:
> > - s = solock(so);
Sockets and files have one flag each to indicate the I/O mode is
non-blocking. This is redundant. Keeping both flags in sync is
hard since races can happen between the two different layers.
So the diff below gets rid of SS_NBIO. It is fairly simple since
sosend(9) and soreceive(9) already take
Diff below extends 'struct usb_device_info' to include the port number
where the USB device is attached to. It doesn't grow the structure and
reuse implicit padding.
I'd like to export the port number to userland to satisfy devel/libusb1,
see: https://github.com/libusb/libusb/issues/314
Ok?
Ind
Instead of having a button for printing the driver(s) attached to a USB
device, do it when invoked with '-v'. This allows me to recycle '-d'.
I'm now using it, like pcidump(8) does, to specify a specific device
node.
My plan is then to use '-f' to force a device to attach as ugen(4). In
that ca
On 11/07/18(Wed) 09:55, Claudio Jeker wrote:
> On busy servers I seen multiple RTM_LOSING message per second being
> generated. This is not helpful (especially since nothing is doing
> something with it). This diff removes the part where RTM_LOSING is
> generated
I'm fine with that. However what
On 10/07/18(Tue) 18:01, Florian Obser wrote:
> When an interface doesn't have a layer 2 address in6_get_soii_ifid()
> failes and then later on a in in6_get_ifid() a layer 2 address is
> "borrowed" from from another interface.
>
> Do the "borrowing" in in6_get_soii_ifid(), too s
On 03/07/18(Tue) 12:38, Martin Pieuchot wrote:
> The next important step towards removing the KERNEL_LOCK() from the
> kernel is to be able to execute ioctl(2)s without it.
>
> The first area that can benefit from this is obviously the Network
> Stack. tb@ and kn@ are working
On 04/07/18(Wed) 17:00, Martin Pieuchot wrote:
> Diff below adds support for printing USB ports status. It includes an
> ABI change as we currently do not export port status/change to userland.
>
> I'd really like to export the current cached value to userland via the
> US
Diff below unlocks 12 network syscalls. It relies on the recent work
that has been to make 'struct file' refcounting mpsafe and on the
corresponding socket lock before messing with the content of any
socket.
Why can we unlock the following syscall? Here's an explanation.
- sys_recvmsg() and sys
On 05/07/18(Thu) 09:28, Landry Breuil wrote:
> On Fri, Jun 29, 2018 at 01:50:24PM +0200, Landry Breuil wrote:
> > On Fri, Jun 29, 2018 at 09:05:56AM +0200, Remco wrote:
> > > > > If you don't find any better solution, I'd suggest using a device ID
> > > > > check rather than adding a quirk. Becaus
Diff below adds support for printing USB ports status. It includes an
ABI change as we currently do not export port status/change to userland.
I'd really like to export the current cached value to userland via the
USB_DEVICEINFO ioctl(2) to reduce the numbers of I/O.
Note that this diff also fix
The next important step towards removing the KERNEL_LOCK() from the
kernel is to be able to execute ioctl(2)s without it.
The first area that can benefit from this is obviously the Network
Stack. tb@ and kn@ are working on this area so they'll soon need a
way to test really test their diffs.
Bu
Our kernel contains multiple of such definitions that are generally a
sign for dead code. Most of them are related to some DRM glue so I
wouldn't touch them. But you might be interested by the others.
$ ctfconv -d obj/bsd.gdb |grep "(0 bytes)"
[282] STRUCT lock_list_
Here's the next iteration on my work on usbdevs(8). It is now printing
the USB IDs by default with the expected Vendor:Device order.
Additional information is printed on a second line. Port status are
still missing but are coming in the next diff.
Examples:
$ ./obj/usbdevs
Controller /dev
Diff below adds & exports per-TDB counters via ipsecctl(8) and adds &
exports global IPsec counters via netstat(1). The goal of this diff
is to introduce a new framework to improve monitoring & error reporting
of IPsec traffic.
Here's an example of "# ipsecctl -s sa -v":
ipcomp tunnel from 10.18
On 02/07/18(Mon) 23:08, David Bern wrote:
> > Is it necessary to parse these examples? Or maybe we can live with
> > your strtonum() fix for now.
> I can live with that.
>
> > I don't know. So unless somebody else gives us some input I'd suggest
> > we move forward with your safe diff even if it
On 02/07/18(Mon) 11:22, Martin Pieuchot wrote:
> Let's use a array of structures to keep track of open files. This will
> allow us to simplify locking when expending it.
>
> While here consistently use M_ZERO when (re)allocating M_FILEDESC
> structures. I doubt the memset(
Let's use a array of structures to keep track of open files. This will
allow us to simplify locking when expending it.
While here consistently use M_ZERO when (re)allocating M_FILEDESC
structures. I doubt the memset() solution makes any difference these
days and the resulting code is simpler to
On 29/06/18(Fri) 16:21, Alexander Bluhm wrote:
> On Thu, Jun 28, 2018 at 01:54:29PM +0200, Martin Pieuchot wrote:
> > > It may happen that the worker thread is in the signal handler and
> > > also blocks the signals.
> >
> > Are you saying that the worker thread mo
On 30/06/18(Sat) 23:47, David Bern wrote:
> > Note that your diff doesn't apply. You have tab vs spaces issues.
> Sorry about that, it seems like I need to setup a proper mail-client.
>
> > I don't understand what you're talking about. Can you give example of
> > the 3 scenarios you're talking a
This message isn't used in base and I couldn't find a use for it in
codesearch.debian.net. It is redundant with RTM_CHANGE.
As I an now trying to make the content of 'struct rtentry' mp-safe
without relying on the NET_LOCK(), getting rid of this message would
help me.
Ok?
Index: sbin/route/rout
On 22/06/18(Fri) 22:37, Alexander Bluhm wrote:
> Hi,
>
> Since the recent futex(2) changes the posixtestsuite regress does
> not finish within the given time frame. Depending on some races
> tests hang, e.g. this one:
>
> /usr/local/libexec/posixtestsuite/conformance/interfaces/pthread_atfork/3-
My recent work to force USB devices to attach as ugen(4) [0] and Ilya's
work to enable/disable USB devices [1] have a lot in common. Now I'd
argue that we don't want new userland tool for these functionalities.
IMHO we should improve usbdevs(8).
Sadly usbdevs(8) output is hard to read. So here'
On 18/06/18(Mon) 20:57, David Bern wrote:
> I take back my previous answer to this question:
> > Are you sure the name always contain an underscore? Can't it be
> > "Button:Button42" ?
>
> In my previous response I had only discovered three cases of usage -1.
> I took another look and discovered
801 - 900 of 2816 matches
Mail list logo
