Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

2019-04-10 Thread Mateusz Guzik
On 4/11/19, Rick Macklem wrote: > Mateusz Guzik wrote: >>On 4/11/19, Rick Macklem wrote: >>> Hi, >>> >>> I finally got around to looking at what effect replacing pfind_locked() >>> with >>> pfind() has for the NFSv4 client and it is broken.

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

2019-04-10 Thread Mateusz Guzik
manner and just performs a timestamp check to see if it got the one it expected (with pid reuse in mind). So I think a temporary hack which will do the trick will take the current approach further: rely on struct proc being type-stable (i.e. never being freed) and also store the pointer. You can alw

Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)

2018-12-27 Thread Mateusz Guzik
atch. >> > > I'm a long term top user and it used to work. For example, when I was > running > head -r340287 it worked as I remember. (I recreated such a vintage recently > for a test of something else. The -opid ordering was coherent as I > remember, > unlike the above.) > > It historically seemed to track the time order of process creation, even > around the PID > number wrapping around. (So not a strict PID sort, at least for the PID > shown.) This > was handy for monitoring buildworld buidkernel and port builds (all > parallel). > > I'll probably try the patch when I have a chance, even if it does strict PID > number > order. Thanks. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

2018-12-08 Thread Mateusz Guzik
on? Most importantly, does this show up with a 12.0 kernel? I'm running one amd box and a number of intel boxes with various cpus, no issues. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/lis

Re: rm cannot recursively delete directory on tmpfs on RPi2

2018-12-07 Thread Mateusz Guzik
On 12/7/18, Michal Meloun wrote: > > > On 07.12.2018 7:25, Mateusz Guzik wrote: >> On 12/7/18, Jia-Shiun Li wrote: >>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>> >>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>

Re: rm cannot recursively delete directory on tmpfs on RPi2

2018-12-06 Thread Mateusz Guzik
/systm.h @@ -523,7 +523,7 @@ int alloc_unr_specific(struct unrhdr *uh, u_int item); int alloc_unrl(struct unrhdr *uh); void free_unr(struct unrhdr *uh, u_int item); -#if defined(__mips__) || defined(__powerpc__) +#ifndef __LP64__ #define UNR64_LOCKED #endif -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fuser does not list id of processes that have a file

2018-10-18 Thread Mateusz Guzik
does not resolve the problem for me. > Are you sure you recompiled and reinstalled the tool with the patch applied? You can recompile and install like this: # make -j 3 clean all install If this indeed still does not work, can you show output of: uname -m mount I tested on

Re: fuser does not list id of processes that have a file

2018-10-16 Thread Mateusz Guzik
name; STAILQ_HEAD(, consumer) consumers; -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mateusz Guzik
to pop in another drive or can I do a netdump at this point ? > This should be fixed with https://svnweb.freebsd.org/changeset/base/339355 i.e. just update. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

Re: vmstat -m and netstat -m dumping core when run on vmcores

2018-10-01 Thread Mateusz Guzik
crt1.c:74 >> >> Wonder if it's just me or something is broken here? > > I think this is due to r338899. libmemstat needs an adjustments to handle > that. > Indeed, I'll take care of it. Thanks for the report. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

2018-06-08 Thread Mateusz Guzik
his bug and needs to get a working system in the > meantime, you'll need to revert the following commits which implemented (or > updated) this change: > > r334830 > r334829 > r334824 > > Jonathan > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r334533 renders head unbootable on XenServer 7.4

2018-06-07 Thread Mateusz Guzik
the committer - not everyone watches mailing lists too closely. I set it up on FreeBSD as dom0 and verified the problem exists. I fixed it with the following: https://svnweb.freebsd.org/changeset/base/334820 -- Mateusz Guzik ___ freebsd-current@free

Re: Error build nvidia-driver with r334555

2018-06-03 Thread Mateusz Guzik
memcmp +#undefmemmove +#undefmemcpy +#undef memset #include -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-22 Thread Mateusz Guzik
_handle_long(oidp, , 0, req)); > } > #endif Thanks for testing, committed in r329837. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-22 Thread Mateusz Guzik
On Thu, Feb 22, 2018 at 6:41 PM, O. Hartmann wrote: > Am Wed, 21 Feb 2018 20:05:24 +0100 > "O. Hartmann" schrieb: > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 > 23:06:15 CET > > 2018 amd64) I'm honored by this

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-20 Thread Mateusz Guzik
Committed in https://svnweb.freebsd.org/base?view=revision=329660 thanks for reporting On Tue, Feb 20, 2018 at 6:06 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > I missed a consumer, try this: > > diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c > index 5e8928cb

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-20 Thread Mateusz Guzik
e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at > cpufunc.h:611 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > kgdb is over my head, but I can provide more details under some guidance. > > Hope it helps, > Juan > > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-18 Thread Mateusz Guzik
I committed the fix in https://svnweb.freebsd.org/base?view=revision=329542 i.e. should be stable from this point on. On Sun, Feb 18, 2018 at 11:55 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < > trond.endres...@fagskolen.g

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-18 Thread Mateusz Guzik
On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > > > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > >

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-18 Thread Mateusz Guzik
On Sun, Feb 18, 2018 at 10:50 PM, Mark Millard <marklmi26-f...@yahoo.com> wrote: > > > On 2018-Feb-18, at 1:46 PM, Mark Millard <marklmi26-f...@yahoo.com> wrote: > > > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > >&g

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-18 Thread Mateusz Guzik
29447 works then the issue should be already fixed and in particular fresh head should work fine. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

2018-02-18 Thread Mateusz Guzik
t; sys_vfork() at sys_vfork+0x4c/frame 0xfe00f1130980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfe00f1130ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffc5a0 > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: witness_lock_list_get: witness exhausted

2018-01-08 Thread Mateusz Guzik
U's to a guest and as > much > RAM as I want, I do like to help with edge cases if I can make them occur > pushing > boundaries as I can towards additianional improvements in FreeBSD. > Can you apply this and re-run the test? https://people.freebsd.org/~mjg/witness.diff It bumps the

Re: SVN r325920 breaks build

2017-11-16 Thread Mateusz Guzik
_mutex.c:1015:6: error: use of undeclared > identifier 'v' > if (v & MTX_RECURSED) { > ^ > /usr/src/sys/kern/kern_mutex.c:1024:6: error: use of undeclared > identifier 'v' > if (v == tid && _mtx_release_lock(m, tid)) > ^ >

Re: There is *NO* abi stability in -head

2017-10-26 Thread Mateusz Guzik
On Tue, Oct 24, 2017 at 10:47 AM, Hans Petter Selasky <h...@selasky.org> wrote: > On 10/23/17 22:35, Mateusz Guzik wrote: > >> This is your friendly reminder that in head struct layouts can change >> and each update requires you to rebuild *all* modules (including ones

There is *NO* abi stability in -head

2017-10-23 Thread Mateusz Guzik
to be evicted. For interested parties I can't recommend enough: https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo

Re: Build failure: non-SMP after SVN r324778

2017-10-20 Thread Mateusz Guzik
nction declaration is > not a prototype [-Werror,-Wstrict-prototypes] > 2 errors generated. > *** [kern_mutex.o] Error code 1 > > oops, fixed in r324803. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

Re: pfind_locked(pid) fails when in a jail?

2017-10-16 Thread Mateusz Guzik
calling it in the first place. The calls I grepped in nfscl_procdoesntexist are highly suspicious - there is no guarantee the process you found here is the same you had at the time you were saving the pid. There is no usable process exit notification right now, but it can be added if necessary. -- Mateu

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-03-02 Thread Mateusz Guzik
On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: > > On 2017-Feb-28, at 10:13 PM, Mateusz Guzik wrote: > > On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote: > >> On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote: > >>> Thu

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-28 Thread Mateusz Guzik
On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote: > On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote: > > Thus the PowerMac G5 so-called "Quad Core" is back to > > -r313254 without your patches. (The "Quad Core" really has &g

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-25 Thread Mateusz Guzik
k what to do with it, worst case I'll #ifdef changes with powerpc. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-24 Thread Mateusz Guzik
On Tue, Feb 21, 2017 at 01:37:25AM -0800, Mark Millard wrote: > [Back to the powerpc64 context.] > > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote: > >> [Note: I expe

Re: Laptop very sluggish diring smoke-test @r314036

2017-02-21 Thread Mateusz Guzik
> magnitude of a slowdown overall. > Can you check if the problem IS NOT present on r313995 but IS present on r313996? Only rebuilding the kernel + modules is necessary. If the problem was not introduced by r313996 I'm afraid you will have to bisect. -- Mateusz Guzik ___

Re: weird panic at mount

2017-02-20 Thread Mateusz Guzik
you recompile your modules? Several fields seem off by a multiply of 8 bytes, which coincidently fits r313992. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik
gt; and 2100021 for the kernel and world for -r313999, > just like for -r313864. > I think this is r313992. I don't see why __FreeBSD_version would be modified for this. You are expected to always recompilel your modules while tracking -curren

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Mateusz Guzik
On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote: > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > > With a kernel and world from r313943 sources (circa > > > Feb 19, 2017)

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Mateusz Guzik
ches/complete-locks.diff and check if it breaks If it does not break, revert the patch and bisect the kernel please. Otherwise I'll devise smaller diffs to narrow this down. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.free

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik
On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote: > On 2017-Feb-20, at 2:58 PM, Mark Millard <mar...@dsl-only.net> wrote: > > > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik wrote: > > > >> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik
spin mutexes were not properly handling this, fixed in r313996. Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64 fcmpset to simulate failures. Everything works, while it would easily fail without the patch. That said, I hope this concludes the 'missing check for not-reread v

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-18 Thread Mateusz Guzik
On Sat, Feb 18, 2017 at 01:58:49PM -0800, Mark Millard wrote: > On 2017-Feb-18, at 12:58 PM, Mateusz Guzik wrote: > > Well either the primitive itself is buggy or the somewhat (now) unusual > > condition of not providing the failed value (but possibly a stale one) > > is

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-18 Thread Mateusz Guzik
might be exposed by > the extra checks). > Well either the primitive itself is buggy or the somewhat (now) unusual condition of not providing the failed value (but possibly a stale one) is not handled correctly in locking code. That said, I would start with putting barriers "on bot

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-02-11 Thread Mateusz Guzik
On Thu, Oct 27, 2016 at 09:09:16PM +0800, Ben Woods wrote: > On 24 September 2016 at 18:13, Ben Woods <woods...@gmail.com> wrote: > > > On 22 September 2016 at 21:01, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > >> On Thu, Sep 22, 2016 at 08:48:

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

2017-01-21 Thread Mateusz Guzik
On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote: > The most recent CURRENT panics spontanously and crashes with the error > message: > > > Panic String: __lockmgr_args: unknown lockmgr request 0x0 > That's a braino in r312600, will be fixed shortly.

Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

2016-11-13 Thread Mateusz Guzik
} } - if (!(ncp->nc_flag & NCF_NEGATIVE)) { - TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst); - if (ncp == ncp->nc_vp->v_cache_dd) - ncp->nc_vp->v_cac

Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

2016-11-12 Thread Mateusz Guzik
race where the entry is demoted and loses the HOTNEGATIVE. But the demotion code has the hot list locked and so does this code if it spots the flag. What's more, the race is handled by re-checking the flag after the lock was taken. That said, there is something seriously fishing going on here. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2016-09-22 Thread Mateusz Guzik
On Thu, Sep 22, 2016 at 03:01:41PM +0200, Mateusz Guzik wrote: > On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote: > > #13 0x80b4d91c in turnstile_broadcast (ts=0x0, queue=1) at > > /usr/src/sys/kern/subr_turnstile.c:837 > > #14 0x80ae5e1f in

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2016-09-22 Thread Mateusz Guzik
at /usr/src/sys/kern/kern_rwlock.c:1027 can you please: f 14 x/xg c -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic @r305116 in transition to multi-user mode

2016-08-31 Thread Mateusz Guzik
x7fffe7f0 --- > db> dump > Dumping 1299 out of 32687 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..92% > Dump complete > db> > This is most likely r305091 which I reverted in r305124, i.e. just upgrade and see if it helps. Sorry for trouble, -- Mateusz Guzik _

Re: SVN r303643 breaks non-SMP compilation

2016-08-01 Thread Mateusz Guzik
or reporting. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] randomized delay in locking primitives, take 2

2016-08-01 Thread Mateusz Guzik
On Mon, Aug 01, 2016 at 11:37:50AM -0700, John Baldwin wrote: > On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote: > > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > > [snip] > > > > After an irc discussion, the following was produced (a

Re: [PATCH] randomized delay in locking primitives, take 2

2016-08-01 Thread Mateusz Guzik
On Mon, Aug 01, 2016 at 09:38:09AM -0700, Maxim Sobolev wrote: > On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > Did you tes

Re: [PATCH] randomized delay in locking primitives, take 2

2016-08-01 Thread Mateusz Guzik
ere. > The patch is the simplest hack possible so that this has a chance of getting into 11.0 as it helps /a lot/ even in the simplest form. Revamping this stuff in a more "here to stay" manner is a much longer endeavor. -- Mateusz Guzik ___ free

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik
% operation acts a randomizer. It is optional and I'm happy to ifdef it based on the architecture. It does seem to be useful at least on amd64. As a side note, exponential backoff is not used to keep things smaller (see above). It is definitely subject to ch

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik
On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: [snip] After an irc discussion, the following was produced (also available at: https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): Differences: - uint64_t usage was converted to u_int (also see r303584) - currently

[PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik
The patch can be found inline below and also here: https://people.freebsd.org/~mjg/lock_backoff_complete.diff The previous version of the patch was posted here: https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html This time around instead of a total hack I have something of

Re: [PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

2016-07-16 Thread Mateusz Guzik
On Sun, Jul 10, 2016 at 08:32:01AM -0600, Ian Lepore wrote: > On Sun, 2016-07-10 at 13:13 +0200, Mateusz Guzik wrote: > > If the lock is contended, primitives like __mtx_lock_sleep will spin > > checking if the owner is running or the lock was freed. The problem >

Re: [PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

2016-07-10 Thread Mateusz Guzik
On Sun, Jul 10, 2016 at 03:22:47PM +0300, Konstantin Belousov wrote: > On Sun, Jul 10, 2016 at 01:13:26PM +0200, Mateusz Guzik wrote: > > If the lock is contended, primitives like __mtx_lock_sleep will spin > > checking if the owner is running or the lock was freed. The problem i

[PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

2016-07-10 Thread Mateusz Guzik
If the lock is contended, primitives like __mtx_lock_sleep will spin checking if the owner is running or the lock was freed. The problem is that once it is discovered that the lock is free, multiple CPUs are likely to try to do the atomic op which will make it more costly for everyone and

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-06-01 Thread Mateusz Guzik
On Fri, May 27, 2016 at 04:21:11PM -0700, John Baldwin wrote: > On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > > Hello there, > > > > quite some time ago I posted a trivial patch to locking primitives. What > > they do is the inline part tries an

[PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-05-27 Thread Mateusz Guzik
Hello there, quite some time ago I posted a trivial patch to locking primitives. What they do is the inline part tries an atomic op and if that fails the actual function is called, which immediately tries the same op. The obvious optimisation checks for the availability of the lock first. There

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-18 Thread Mateusz Guzik
er the systems remain stable. > Thanks, fix committed in https://svnweb.freebsd.org/base?view=revision=292440 -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-18 Thread Mateusz Guzik
On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote: > On 17 Dec, Mateusz Guzik wrote: > > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote: > >> On 17 Dec, Konstantin Belousov wrote: > >> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-18 Thread Mateusz Guzik
On Fri, Dec 18, 2015 at 09:44:10AM -0800, Don Lewis wrote: > On 18 Dec, Mateusz Guzik wrote: > > On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote: > >> On 17 Dec, Mateusz Guzik wrote: > >> > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote: > >

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-17 Thread Mateusz Guzik
PRS_NEW state and poisoned pointers in debug kernels to help ensuring that all loops handle the case. Not signing up for any of this work though. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

2015-12-16 Thread Mateusz Guzik
t is copied on creation. */ #definep_endcopy p_xsig + struct pgrp *p_pgrp;/* (c + e) Pointer to process group. */ struct knlist p_klist;/* (c) Knotes attached to this proc. */ int p_numthreads; /* (c) Number of threads. */

Re: panic "ffs_checkblk: bad block" on recent -head kernels

2015-12-03 Thread Mateusz Guzik
_vdrop(struct vnode *vp, bool locked) vp->v_op = NULL; #endif bzero(>v_un, sizeof(vp->v_un)); + vp->v_lasta = vp->v_clen = vp->v_cstart = vp->v_lastw = 0; vp->v_iflag = 0; vp->v_vflag = 0; bo->bo_flag = 0; -- Mateusz Gu

Re: panic "ffs_checkblk: bad block" on recent -head kernels

2015-12-03 Thread Mateusz Guzik
On Thu, Dec 03, 2015 at 03:07:48PM -0800, Kirk McKusick wrote: > > Date: Thu, 3 Dec 2015 23:47:52 +0100 > > From: Mateusz Guzik <mjgu...@gmail.com> > > To: Rick Macklem <rmack...@uoguelph.ca> > > Cc: FreeBSD Current <freebsd-current@freebsd.org> >

Re: r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512

2015-12-02 Thread Mateusz Guzik
gt; I could not find a reference to this panic. > please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204949 -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Mateusz Guzik
On Thu, Nov 05, 2015 at 11:04:13AM -0800, John Baldwin wrote: > On Thursday, November 05, 2015 04:26:28 PM Konstantin Belousov wrote: > > On Thu, Nov 05, 2015 at 12:32:18AM +0100, Mateusz Guzik wrote: > > > mtx_lock will unconditionally try to grab the lock and if that fail

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Mateusz Guzik
On Thu, Nov 05, 2015 at 04:35:22PM -0700, Ian Lepore wrote: > On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: > > On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: > > > On 5 November 2015 at 11:26, Mateusz Guzik <mjgu...@gmail.com> > > > wr

[PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-04 Thread Mateusz Guzik
\ + else\ + _mtx_lock_sleep((mp), _tid, (opts), (file), (line));\ } while (0) /* -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.free

Re: Instant panic while trying run ports-mgmt/poudriere

2015-08-06 Thread Mateusz Guzik
or guessing. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic in sysctl code in recent head

2015-08-03 Thread Mateusz Guzik
you are seeing. What you can do is show your panic (at least the backtrace) and preferably narrow the problem down to the exact revision which introduced it. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http

Re: panic in sysctl code in recent head

2015-07-30 Thread Mateusz Guzik
in r286094. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: null pointer dereference panic in cap_rights_contains() on 11.0-CURRENT r285785 amd64

2015-07-23 Thread Mateusz Guzik
a semaphore. */ -error = ksem_get(td, uap-id, 0, fp); +error = ksem_get(td, uap-id, cap_rights_init(rights), fp); if (error) return (error); ks = fp-f_data; Correct, please commit. -- Mateusz Guzik mjguzik gmail.com

Re: Instant panic while trying run ports-mgmt/poudriere

2015-07-13 Thread Mateusz Guzik
, if the problem is really that reproducible it would be best if you narrowed it down to the exact commit. However, quick look suggests you may be a victim of r284861. Can you enter kgdb and: f 26 p *list ? -- Mateusz Guzik mjguzik gmail.com

Re: unp gc vs socket close/shutdown race

2015-07-09 Thread Mateusz Guzik
On Wed, Jul 08, 2015 at 02:15:38AM +0200, Mateusz Guzik wrote: First off note the patch below is a total hack with the easiest solution possible so that it can be MFCed for 10.2. The issue: Closing the socket involves: if (pr-pr_flags PR_RIGHTS pr-pr_domain-dom_dispose != NULL

Re: unp gc vs socket close/shutdown race

2015-07-08 Thread Mateusz Guzik
and will likely want a detailed review/rewrite at some point. Hopefully the patch is a sufficient band aid until such time comes. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo

unp gc vs socket close/shutdown race

2015-07-07 Thread Mateusz Guzik
it. */ /* * These flags are used to handle non-atomicity in connect() and bind() -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail

Re: xargs -P0 suport

2015-05-22 Thread Mateusz Guzik
On Fri, May 22, 2015 at 01:43:21PM -0400, Nikolai Lifanov wrote: On 05/22/15 13:27, Mateusz Guzik wrote: On Fri, May 22, 2015 at 12:32:52PM -0400, Allan Jude wrote: There is some question about if nargs is a sane value for maxprocs in the negative case. 5000 does seem a bit high

Re: xargs -P0 suport

2015-05-22 Thread Mateusz Guzik
suggestions? GNU xargs imposes no limit whatsoever, but it also supports reallocating its process table, while our xargs allocates one upfront and does not change it. I would say reading hard proc resource limit and using that as the limit would do the job just fine. -- Mateusz Guzik mjguzik

Re: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Mateusz Guzik
On Sat, Mar 21, 2015 at 09:29:04PM +0200, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote: On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: On Sat, Mar 21, 2015

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #862

2015-03-21 Thread Mateusz Guzik
() at Xfast_syscall+0xfb/frame 0xfe0097440bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 0x7fffc2d8, rbp = 0x7fffc340 --- Should be fixed starting with https://svnweb.freebsd.org/changeset/base/280331 -- Mateusz Guzik mjguzik gmail.com

Re: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Mateusz Guzik
On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote: On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: From: Mateusz Guzik m

[PATCH 2/3] cred: add proc_set_cred_init helper

2015-03-20 Thread Mateusz Guzik
From: Mateusz Guzik m...@freebsd.org proc_set_cred_init can be used to set first credentials of a new process. Update proc_set_cred assertions so that it only expects already used processes. This fixes panics where p_ucred of a new process happens to be non-NULL. --- sys/kern/init_main.c | 2

[PATCH 3/3] proc: use MTX_NEW flag in proc_init

2015-03-20 Thread Mateusz Guzik
From: Mateusz Guzik m...@freebsd.org This allows us to get rid of bzero which was added specifically to make mtx_init on p_mtx reliable. This also fixes a potential problem where mtx_init on other mutexes could trip over on unitialized memory and fire an assertion. --- sys/kern/kern_proc.c | 11

[PATCH 1/3] fork: assign refed credentials earlier

2015-03-20 Thread Mateusz Guzik
From: Mateusz Guzik m...@freebsd.org Prior to this change the kernel would take p1's credentials and assign them tempororarily to p2. But p1 could change credentials at that time and in effect give us a use-after-free. --- sys/kern/kern_fork.c | 15 +++ 1 file changed, 7 insertions

Re: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-20 Thread Mateusz Guzik
On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote: From: Mateusz Guzik m...@freebsd.org Prior to this change the kernel would take p1's credentials and assign them tempororarily to p2. But p1 could change

[PATCH 0/3] fix up some recent proc fallout and more

2015-03-20 Thread Mateusz Guzik
From: Mateusz Guzik m...@freebsd.org Patches in this series fix a bug introduced in r280130 and deal with additional issues. I'm not happy with how sutff is being done at the moment. In particular we zero out various fields on process exit, which puts it into a state state which

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854

2015-03-20 Thread Mateusz Guzik
On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote: On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote: On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote: lib/libc/sys/setrlimit_test:setrlimit_nproc - maxproc limit exceeded by uid 977

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854

2015-03-19 Thread Mateusz Guzik
() at Xfast_syscall+0xfb/frame 0xfe009749abf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffc2d8, rbp = 0x7fffc340 --- KDB: enter: panic [ thread pid 660 tid 100065 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why Weird, I'll look at that. -- Mateusz Guzik mjguzik

Re: [PATCH] Convert the VFS cache lock to an rmlock

2015-03-18 Thread Mateusz Guzik
On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote: On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: Below is partial results from a profile of a parallel (-j7) buildworld on a 6-core machine that I did

Re: [PATCH] Convert the VFS cache lock to an rmlock

2015-03-17 Thread Mateusz Guzik
On Fri, Mar 13, 2015 at 11:23:06AM -0400, Ryan Stone wrote: On Thu, Mar 12, 2015 at 1:36 PM, Mateusz Guzik mjgu...@gmail.com wrote: Workloads like buildworld and the like (i.e. a lot of forks + execs) run into very severe contention in vm, which is orders of magnitude bigger than anything

Re: [PATCH] Convert the VFS cache lock to an rmlock

2015-03-12 Thread Mateusz Guzik
, but as it is I do not expect namecache lock contention to have significant impact on buildworld/kernel. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send

Re: [PATCH] Convert the VFS cache lock to an rmlock

2015-03-12 Thread Mateusz Guzik
run? I suggest you grab a machine from zoo[1] and run some tests on bigger hardware. A perf improvement, even slight, is definitely welcome. [1] https://wiki.freebsd.org/TestClusterOneReservations -- Mateusz Guzik mjguzik gmail.com ___ freebsd

Re: Finding a rogue src/sys commit with bisection?

2014-11-15 Thread Mateusz Guzik
. In absolutely worst case yu can check out git tree and bisect that :- -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current

Re: Build failed in Jenkins: FreeBSD_HEAD #1835

2014-11-13 Thread Mateusz Guzik
://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/sys/filedesc.h:161:1: note: 'fdinit' declared here struct filedesc *fdinit(struct filedesc *fdp); ^ That's my fault, fixed in https://svnweb.freebsd.org/changeset/base/274485 -- Mateusz Guzik mjguzik gmail.com

Re: junior kernel tasks

2014-11-02 Thread Mateusz Guzik
On Sat, Oct 25, 2014 at 10:45:36PM +0200, Mateusz Guzik wrote: Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return

Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161

2014-10-31 Thread Mateusz Guzik
to /var. Looks like the test in question assumes it always gets /dev/md0. The test works for me not what the regression is fixed. I guess jenkins didn't catch up to it yet. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list

junior kernel tasks

2014-10-25 Thread Mateusz Guzik
are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a no Cheers, -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http

  1   2   >