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
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
> =
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
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,
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
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
> > >
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
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
>
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-
>
> > 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
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@
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
@@ -
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
& 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
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
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.
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
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
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
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
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
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
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
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
>
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
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 --
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
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
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&
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
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
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
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
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
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
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
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
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
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!
>
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
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
> >
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
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 ?
>
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
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
45 matches
Mail list logo
