Re: Kernel hang under concurrent vfs ops on the same hierarchy.

2020-10-30 Thread Mathieu -
yscall+0x389 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x58cd3c8dcf0, count: 8 [1]: https://github.com/freebsd/freebsd/commit/dbebfe18a15ceac757fc126dd8caa59045ec9e47 [2]: https://gitweb.dragonflybsd.org/dragonfly.git/commit/ad1212685b9caac64c086a2363d15842dff21fd8 On 06 Oct 10

Re: hashinit(): power of 2 fast path

2018-04-28 Thread Mathieu -
80% of the calls to hashinit() includes a > power of 2 size. > > Comments? OK? Hi, Dunno how much a win it is. But anyhow this will blow in hashfree as hashsize won't be the same. Mathieu. > > Index: kern/kern_subr.c > =

Re: hashinit(): power of 2 fast path

2018-04-29 Thread Mathieu -
Disregard that, brainfart on my side. Mathieu - wrote: > Anton Lindqvist wrote: > > Hi, > > If the elements argument passed to hashinit() is a power of 2 there's no > > need to find the closest power of 2 that can fit all elements since > > elements == hashsize wil

Re: Say no to LARVAL

2018-05-11 Thread Mathieu -
about the behavior : https://github.com/torvalds/linux/blob/master/fs/file.c#L810 My 2 cts, Mathieu- Philip Guenther wrote: > On Wed, May 9, 2018 at 3:31 AM, Martin Pieuchot wrote: > > > On 08/05/18(Tue) 14:12, Philip Guenther wrote: > > > On Tue, 8 May 2018,

Re: Unlock 16 network-related syscalls

2018-05-23 Thread Mathieu -
Martin Pieuchot wrote: > By assuming that `f_data' is immutable, which AFAIK is true for sockets, > we can remove the KERNEL_LOCK() from the following syscalls iff files are > refcounted in an MP-safe way. > > This diff includes the EBUSY check in dup2(2) which is currently required > to avoid rac

Re: Unlock 16 network-related syscalls

2018-05-23 Thread Mathieu -
Martin Pieuchot wrote: > On 23/05/18(Wed) 11:14, Hrvoje Popovski wrote: > > On 22.5.2018. 17:03, Theo Buehler wrote: > > > I applied the diff, made syscalls, then built and installed a new > > > kernel. With that, I ran into a reliable complete lockup on my x230 by > > > starting in an xterm > > >

Re: Unlock 16 network-related syscalls

2018-05-24 Thread Mathieu -
Mathieu - wrote: > Martin Pieuchot wrote: > > On 23/05/18(Wed) 11:14, Hrvoje Popovski wrote: > > > On 22.5.2018. 17:03, Theo Buehler wrote: > > > > I applied the diff, made syscalls, then built and installed a new > > > > kernel. With that, I ran int

Re: Unlock 16 network-related syscalls

2018-05-24 Thread Mathieu -
Mathieu - wrote: > Mathieu - wrote: > > Martin Pieuchot wrote: > > > On 23/05/18(Wed) 11:14, Hrvoje Popovski wrote: > > > > On 22.5.2018. 17:03, Theo Buehler wrote: > > > > > I applied the diff, made syscalls, then built and installed a new >

Re: Unlock 16 network-related syscalls

2018-05-25 Thread Mathieu -
main laptop since Visa figured out the > problem on Wednesday and saw no more issues since then. I've completed > a make build with a WITNESS kernel while letting youtube play videos. > Hello, Same here, been running with this since last night and I can't reproduce the hang despite hitting hard on it. (The hang would happen in 10 seconds after starting chrome on my machine). Mathieu-

Re: IPL_VM for `f_mtx'

2018-05-28 Thread Mathieu -
> > > ok? > > I suppose IPL_VM is the most sensible default for mutexes that need to > block all interrupts that might need the kernel lock. > > ok kettenis@ Hello, Wouldn't IPL_MPFLOOR be more appropriate? After all mutexes are already raising t

Re: IPL_VM for `f_mtx'

2018-05-29 Thread Mathieu -
Mark Kettenis wrote: > > Date: Mon, 28 May 2018 12:24:22 +0200 > > From: Mathieu - > > > > Mark Kettenis wrote: > > > > Date: Mon, 28 May 2018 11:23:47 +0200 > > > > From: Martin Pieuchot > > > > > > > > As found by tb@

Adding IPL_MPFLOOR to sh/armv7

2018-05-30 Thread Mathieu -
allout for the define is not used on those platforms (sys/mutex.h conditionnalize on MULTIPROCESSOR as noted above). Mathieu. diff --git arch/armv7/include/intr.h arch/armv7/include/intr.h index 5b3f320009d..0607ee462e2 100644 --- arch/armv7/include/intr.h +++ arch/armv7/include/intr.h @@ -

Use IPL_MPFLOOR for 'f_mtx'

2018-05-30 Thread Mathieu -
Hello, Now that IPL_MPFLOOR is available on all platforms we can use it. The first user is the f_mtx mutex in kern_descrip. Rev 1.160 initialized it using IPL_VM, we can now use the more appropriate IPL_MPFLOOR value as already done in the MI mutex implementation for the exact same reason. dif

Re: fdinsert(), take 2

2018-05-31 Thread Mathieu -
& tests are more than welcome! > > Ok? Been running it for a while without any problems. Mathieu. > > Index: kern/kern_exec.c > === > RCS file: /cvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.195 > d

Re: fdinsert(), take 3

2018-06-14 Thread Mathieu -
descriptor > itself the fact that it isn't ready yet (LARVAL). Otherwise we have a > chicken & egg problem for reference counting. As pointed by Mathieu > Masson other BSDs do that by using a new structure for open files. We > might want to do that later when we'll turn the

Re: fdinsert(), take 3

2018-06-16 Thread Mathieu -
unlock most of the socket-related > > syscalls. > > > > The important point of this diff is that we don't store on the descriptor > > itself the fact that it isn't ready yet (LARVAL). Otherwise we have a > > chicken & egg problem for reference counting.

ptrace PT_IO write bug

2016-05-25 Thread Mathieu -
Hello everyone, While playing a bit with ptrace to do some debugging I stumbled upon something that looks like a bug. While trying to write to the ptrace'd process using PT_IO in combinaison with PIOD_WRITE_D I kept getting EFAULTs. PIOD_READ_D would work fine on the same address though, and even

Re: ptrace PT_IO write bug

2016-05-28 Thread Mathieu -
or the feedback. The missing callers where an overlook on my part, sorry for that. Here is a regenerated diff including all the call site. As a side note, obviously every one of them was using PT_WRITE_I, that's why it went unnoticed. Mathieu- diff --git a/sys/arch/alpha/alpha/process_m

Re: ptrace PT_IO write bug

2016-05-28 Thread Mathieu -
Mark Kettenis wrote: > The thing you guys are missing is that on some architectures making changes > to instructions (PT_WRITE_I) requires some additional operations to > guarantee that the CPU actually sees those updated instructions. Typically > this is the case on architectures with separate da

Re: ptrace PT_IO write bug

2016-05-31 Thread Mathieu -
Mark Kettenis wrote: > > > The documentation may have been wrong for some time on some archs, it > > > feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed > > > useful at one point. Given that Free and NetBSD document the same > > > guarantee, I personally don't feel comfortable chan

hashfree: sizes for free(9) when using hashinit.

2016-08-31 Thread Mathieu -
Hello list, I'm introducing hashfree, a counterpart to hashinit in order to pass the size to free(9) while hiding the implementation details. Most of the api users are converted in the patch below, those not included just simply do not free the memory (pid hash table etc). All, except for one case

Re: Array of TAILQs in kern_synch.c

2016-09-01 Thread Mathieu -
Ted Unangst wrote: > Michal Mazurek wrote: > > There is what appears to be a sensless hash in kern_synch.c. It's an > > array of 128 TAILQs which are hashed according to the high bits of the > > wchan. It's possible to write a program that adds kern.maxthread entries > > to one of those TAILQs. Jus

Re: hashfree: sizes for free(9) when using hashinit.

2016-09-21 Thread Mathieu -
Ted Unangst wrote: > Mathieu - wrote: > > Hello list, > > > > I'm introducing hashfree, a counterpart to hashinit in order to pass the > > size to free(9) while hiding the implementation details. > > Most of the api users are converted in the patch below, tho

Re: hashfree: sizes for free(9) when using hashinit.

2016-09-24 Thread Mathieu -
Philip Guenther wrote: > On Wed, Sep 21, 2016 at 1:30 AM, Mathieu - wrote: > > Ted Unangst wrote: > >> Mathieu - wrote: > >> > Hello list, > >> > > >> > I'm introducing hashfree, a counterpart to hashinit in order to pass the >

Re: (re)name cpumem_realloc to cpumem_malloc_ncpus

2016-10-24 Thread Mathieu -
David Gwynne wrote: > cos its not resizing the allocation, its allocating them for new cpus. > > the same goes for counters_realloc being named counters_alloc_ncpus. > > this adds doco for them too. Hi, FWIW it makes sense to me, for when I was looking at the per-cpu mbstat diff, I blocked a bit

filedesc's locking.

2017-11-27 Thread Mathieu -
t has been running here for a few days, on a workstation, I also ran the regress tests w/o any regressions. Mathieu. [1] https://marc.info/?l=openbsd-bugs&m=148459545413976&w=2 [2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_descrip.c.diff?r1=1.137&r2=1.138 diff --

umass: size for free

2015-12-07 Thread Mathieu -
Hello, I worked a bit on umass(4) recently and had a diff to pass the umassbus_softc's real size to free so here it is. At some point I pondered about deleting the whole abstraction, as it would simplify the free'ing, for we only have one implementation (umass_scsi_softc, as atapi uses it too). B

Re: umass: size for free

2015-12-10 Thread Mathieu -
Hello, Martin Pieuchot wrote: > Hello, > > On 07/12/15(Mon) 16:48, Mathieu - wrote: > > Hello, > > > > I worked a bit on umass(4) recently and had a diff to pass the > > umassbus_softc's real size to free so here it is. At some point I > > pondered

Re: umass: size for free

2015-12-10 Thread Mathieu -
Mathieu - wrote: > > Hello, > > Martin Pieuchot wrote: > > Hello, > > > > On 07/12/15(Mon) 16:48, Mathieu - wrote: > > > Hello, > > > > > > I worked a bit on umass(4) recently and had a diff to pass the > > > umassbus_softc&

Re: umass: size for free

2015-12-14 Thread Mathieu -
Mathieu - wrote: > Mathieu - wrote: > > > > Hello, > > > > Martin Pieuchot wrote: > > > Hello, > > > > > > On 07/12/15(Mon) 16:48, Mathieu - wrote: > > > > Hello, > > > > > > > > I worked a bit on umass

bus_dma: Size for free

2015-12-17 Thread Mathieu -
Here is a diff to pass around the size to free(9) in amd64's _bus_dmamap allocations. i386 is symmetric but I don't have the hardware currently to test it. Index: bus_dma.c === RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v retr

filedesc: size for free

2015-12-17 Thread Mathieu -
hello, The following patch passes the correct size to free(9) for a filedesc's klist. Index: kern_descrip.c === RCS file: /cvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.125 diff -u -p -r1.125 kern_descrip.c --- kern_descrip

autoconf: size for free

2015-12-18 Thread Mathieu -
Two trivial sizes for free in config_deferred. The other one in the file are a bit trickier and needs more moving things around. Index: subr_autoconf.c === RCS file: /cvs/src/sys/kern/subr_autoconf.c,v retrieving revision 1.90 diff -u

hashfree, a counterpart to hashinit

2015-12-21 Thread Mathieu -
Hello list, Another day another set of sizes for free(9). This time it's around the hashinit function. I introduce a hashfree counterpart to hide the details. Most of the api users are converted in the patch below, those not included just simply do not free the memory (pid hash table etc). All, e

Re: hashfree, a counterpart to hashinit

2015-12-24 Thread Mathieu -
Martin Natano wrote: > Hi, > > the diff reads fine to me, except for following nit-picks: It would be > nice if the hashfree() function would check for negative/zero element > counts, like hashinit() does. Also, new functionality should be > documented in the manual. > > Please find below a regen

Re: hashfree, a counterpart to hashinit

2016-01-04 Thread Mathieu -
Hello, Holidays are over, I'm getting back to this diff, anyone is ok with it? Martin Natano wrote: > Hi, > > the diff reads fine to me, except for following nit-picks: It would be > nice if the hashfree() function would check for negative/zero element > counts, like hashinit() does. Also, new f

Re: rework em(4) tx ring handling

2016-01-08 Thread Mathieu -
Hi, I've been hitting on the diff with iperf and ifconfig up/down cycles. It didn't trigger any watchdog issues (though I've never seen any on this box soo take it with a grain of salt). As Hrvoje said, the box is smoother under high load.. I'll continue hitting it and I'll give the diff a bet

Re: Clustering read for MSDOSFS

2016-01-11 Thread Mathieu -
Martin Pieuchot wrote: > On 03/01/16(Sun) 23:10, Martin Pieuchot wrote: > > Reading files on msdos-formated USB sticks under OpenBSD is really slow. > > *One* of the reasons is that only one block is currently read-ahead if > > possible. > > > > Diff below converts msdosfs_read() to use bread_clus

Re: ffs: cluster_write() is a joke

2016-01-11 Thread Mathieu -
David Gwynne wrote: > On Thu, Jan 07, 2016 at 05:56:17PM +0100, Martin Pieuchot wrote: > > I spent some time trying to implement clustering writes for MSDOSFS > > before I could figure out that our cluster_write() functions is not > > doing anything but delaying the calls do bawrite(). Awesome! >

Re: Clitmouse+pad/Dualpoint

2011-10-16 Thread Mathieu -
Martin Pieuchot wrote: > If your touchpad/clitpad is recognized as an ALPS Dualpoint, like: > > $ dmesg |grep pms0 > pms0: ALPS Dualpoint, version 0x6222 > > Please test the diff below and report me any breakage/improvement. It should > at least fix the "pms0: not in sync yet, discard input" err

Re: Clitmouse+pad/Dualpoint

2011-10-16 Thread Mathieu -
Martin Pieuchot wrote: > On 16/10/11(Sun) 16:05, Mathieu - wrote: > > Martin Pieuchot wrote: > > > If your touchpad/clitpad is recognized as an ALPS Dualpoint, like: > > > > > > $ dmesg |grep pms0 > > > pms0: ALPS Dualpoint, version 0x6222 > >

Re: Allow clang++ to work on OpenBSD

2011-12-12 Thread Mathieu -
oups include the list this time sorry for the noise Pascal. On 12 December 2011 16:00, Pascal Stumpf wrote: > On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: >> > Date: Sun, 11 Dec 2011 19:18:40 +0100 >> > From: Pascal Stumpf >> > >> > > I still think this should be investigated

Re: Allow clang++ to work on OpenBSD

2011-12-12 Thread Mathieu -
On 12 December 2011 16:28, Marc Espie wrote: > On Mon, Dec 12, 2011 at 04:15:23PM +0100, Mathieu - wrote: >> restrict is a C99 keyword and has no meaning (ie doesn't exist) in the >> C++ standard. > > Wrong answer. What's the C++ standard ? C++98 or C++2011 ? >

Patch: support for Dell HBA350i

2023-08-01 Thread mathieu . papineau
e 7 others. Regards, Mathieu J. PAPINEAU Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, expl

Patch: solve IPSEC collisions for IKE1/L2TP peers coming from same IP address

2023-10-05 Thread mathieu . papineau
key_v2.c - sys/net/pfkeyv2.c - sys/net/pfkeyv2_parsemessage.c - sys/netinet/ip_ipsp.c - sys/netinet/ip_ipsp.h - sys/netinet/ip_spd.c Regards, Mathieu J. PAPINEAU diff -r 1f9cc3fc2a87 -r ec38c9134666 sbin/isakmpd/ipsec.c --- sbin/isakmpd/ipsec.cThu Oct 05 10:26:02 2023 +0200 +++ sbin