2.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/isak
,
Mathieu J. PAPINEAU
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans
+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:16, Mathieu - wrote:
> >Syno
ck 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. As pointed
r
> 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 these functions mp-safe
n 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
> diff -u -p -r1.195 kern_ex
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.
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
@@ -61,6 +61,7
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 t
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-
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
>
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
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
> > >
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
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 <m...@openbsd.org> wrote:
>
> > On 08/05/18(Tue) 14:12, Philip Guenther wrote:
> > > On Tue,
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 will
0% 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
> ===
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=148459545413976=2
[2]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_descrip.c.diff?r1=1.137=1.138
diff --git dev/diskmap.c dev
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
Philip Guenther wrote:
> On Wed, Sep 21, 2016 at 1:30 AM, Mathieu - <naa...@poolp.org> wrote:
> > Ted Unangst wrote:
> >> Mathieu - wrote:
> >> > Hello list,
> >> >
> >> > I'm introducing hashfree, a counterpart to hashi
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, thos
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.
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
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
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
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_machde
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
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
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!
>
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
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
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
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,
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
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
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
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'
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
> > ponder
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).
oups include the list this time sorry for the noise Pascal.
On 12 December 2011 16:00, Pascal Stumpf pascal.stu...@cubes.de 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 pascal.stu...@cubes.de
I still
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 error you
41 matches
Mail list logo
