Re: svn commit: r344487 - in head/sys: conf gnu/gcov

2019-02-25 Thread K. Macy
> We had a brief discussion of this commit within a subset of core. This > addition of GPLv2 code is fine as the code is easily removal to a module > (per kmoore@) should the day come that we're read to evict all GPL code. I don't execute the ctors until coverage is enabled because I have to

Re: svn commit: r333242 - head/sys/kern

2018-05-04 Thread K. Macy
Yes. Good catch. Thanks. -M > > Missing Approved by: sbruno? > > >> Modified: >> head/sys/kern/kern_descrip.c >> >> Modified: head/sys/kern/kern_descrip.c >> == >> --- head/sys/kern/kern_descrip.c Fri May 4

Re: svn commit: r333175 - in head/sys: kern net netinet netinet6 sys

2018-05-03 Thread K. Macy
Can you give any context on what they're doing? In addition - even on a production kernel it's possible to compile in DDB to at least get a backtrace. Your report only gives us enough information to know that there is _an_ issue. It's difficult to proceed on this alone. I do have a report from the

Re: svn commit: r332419 - head/sys/net

2018-04-11 Thread K. Macy
There was a panic inducing merge error, please apply if you encounter problems: @ -2288,7 +2294,7 @@ iflib_stop(if_ctx_t ctx) for (i = 0; i < scctx->isc_nrxqsets; i++, rxq++) { /* make sure all transmitters have completed before proceeding XXX */ - for (j =

Re: svn commit: r332389 - head/sys/net

2018-04-11 Thread K. Macy
Yup. git<->phab patch update fail. Maybe some day we can move to git. -M On Wed, Apr 11, 2018 at 10:12 AM, Jonathan T. Looney wrote: > It appears this is causing panics (see the emails on freebsd-current@). > > From a brief glance, it appears that the new STATE_LOCK macros is

Re: svn commit: r300854 - in head/sys: netinet netinet6

2016-05-28 Thread K. Macy
On Friday, May 27, 2016, Bjoern A. Zeeb wrote: > > > On 28 May 2016, at 00:02 , Gleb Smirnoff wrote: > > > > On Fri, May 27, 2016 at 02:27:45PM -0700, Adrian Chadd wrote: > > A> Hm, doesnt this make sense to do as part of RO_RTFREE? > > > > I

Re: svn commit: r300113 - in head/sys: conf kern net sys

2016-05-21 Thread K. Macy
On Sat, May 21, 2016 at 3:36 AM, Hans Petter Selasky wrote: > On 05/18/16 06:35, Scott Long wrote: >> >> Author: scottl >> Date: Wed May 18 04:35:58 2016 >> New Revision: 300113 >> URL: https://svnweb.freebsd.org/changeset/base/300113 >> >> Log: >> Import the 'iflib' API

Re: svn commit: r300113 - in head/sys: conf kern net sys

2016-05-18 Thread K. Macy
Those are new. Please just patch iflib to use them and let's move on. -M On Wed, May 18, 2016 at 4:58 PM, Gleb Smirnoff wrote: > Hi! > > On Wed, May 18, 2016 at 04:35:58AM +, Scott Long wrote: > S> >

Re: svn commit: r285021 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2015-08-05 Thread K. Macy
His proposed solution looks fine to me. Why don't we commit that? -K On Wed, Aug 5, 2015 at 7:22 PM, Glen Barber g...@freebsd.org wrote: On Thu, Aug 06, 2015 at 04:17:23AM +0200, Pawel Jakub Dawidek wrote: On Mon, Aug 03, 2015 at 04:20:04PM +0300, Andriy Gapon wrote: On 30/07/2015 10:24, K

Re: svn commit: r285021 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2015-07-30 Thread K. Macy
Just FYI this change introduces a deadlock with with the spa_namespace_lock. Mount will be holding this lock while trying to acquire the spa_namespace_lock. zfskern on the other hand holds the spa_namespace_lock when calling zfs_freebsd_access which in turn tries to acquire the teardown lock.

Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s

2015-07-16 Thread K. Macy
On Thu, Jul 16, 2015 at 3:28 PM, K. Macy km...@freebsd.org wrote: I discovered this when I MFC'd and my kernel wouldn't link because of unresolved symbols. I thought I had put the issue aside when I added RANDOM_DUMMY to my kernel config. However, I just hit this: while

Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s

2015-07-16 Thread K. Macy
I discovered this when I MFC'd and my kernel wouldn't link because of unresolved symbols. I thought I had put the issue aside when I added RANDOM_DUMMY to my kernel config. However, I just hit this: while (!random_alg_context.ra_seeded()) { if (nonblock) {

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-22 Thread K. Macy
Sigh, you still do not understand. It is your duty to identify all pieces which break after your change. After that, we can argue whether each of them is critical or not to allow the migration. But this must have been done before the KPI change hit the tree. Hi, Are you saying that

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-21 Thread K. Macy
HPS: Your change failed to meet these guidelines. Some of us are upset because these guidelines are fairly fundamental for the on-going viability of FreeBSD. Due to linguistic / time zone / cultural differences these expectations have not been adequately communicated to you. You are not in

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-21 Thread K. Macy
They originally found that things were spinning for way too long. Hans found something similar and determined/concluded that the migration code in callouts was racy-by-design and dramatically simplified it and also put very hard constraints on what is a valid situation to support migrating

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
Please back this out now. It was a substantial interface change without review. This should not be up for debate. I hope the others have the fortitude to insist upon this. -K On Thu, Jan 15, 2015 at 7:32 AM, Hans Petter Selasky hsela...@freebsd.org wrote: Author: hselasky Date: Thu Jan 15

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
On Tue, Jan 20, 2015 at 3:48 PM, K. Macy km...@freebsd.org wrote: Are any other drivers hitting this? e.g. cxgb/cxgbe? The evidence is simply past experience of recurring locking and control flow bugs in the intel drivers. -K -K On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno sbr

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
On Tue, Jan 20, 2015 at 4:22 PM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/20/15 15:59, K. Macy wrote: On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno sbr...@ignoranthack.me wrote: On 01/20/15 15:48, K. Macy wrote: Are any other drivers

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
I think you're working around driver locking bugs by crippling the callout code. -K On Tue, Jan 20, 2015 at 3:35 PM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/20/15 14:30, Hans Petter Selasky wrote: On 01/20/15 22:11, Gleb Smirnoff wrote:

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/20/15 15:48, K. Macy wrote: Are any other drivers hitting this? e.g. cxgb/cxgbe? -K Unkown to me. Nor am I aware of anyone else who ever hit our panics either

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

2015-01-20 Thread K. Macy
Are any other drivers hitting this? e.g. cxgb/cxgbe? -K On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/20/15 15:40, K. Macy wrote: I think you're working around driver locking bugs by crippling the callout

Re: svn commit: r230623 - in head/sys: amd64/amd64 cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs sys vm

2012-01-28 Thread K Macy
Il giorno 28/gen/2012, alle ore 09:39, Pawel Jakub Dawidek p...@freebsd.org ha scritto: On Fri, Jan 27, 2012 at 08:18:32PM +, Kip Macy wrote: Author: kmacy Date: Fri Jan 27 20:18:31 2012 New Revision: 230623 URL: http://svn.freebsd.org/changeset/base/230623 Log: exclude

Re: svn commit: r230623 - in head/sys: amd64/amd64 cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs sys vm

2012-01-28 Thread K. Macy
On Sat, Jan 28, 2012 at 9:39 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Fri, Jan 27, 2012 at 08:18:32PM +, Kip Macy wrote: Author: kmacy Date: Fri Jan 27 20:18:31 2012 New Revision: 230623 URL: http://svn.freebsd.org/changeset/base/230623 Log:   exclude kmem_alloc'ed ARC data

Re: svn commit: r229800 - head/sys/conf

2012-01-09 Thread K. Macy
The problem with having ZFS compiled into the kernel is that OpenSolaris compatiblity layer needs its headers to be included before system headers, which is/was impossible or hard to express for kernel compilation. AFAIR Kip Macy was working on it and my understanding was that he finished it

Re: svn commit: r225617 - in head/sys: amd64/amd64 amd64/linux32 arm/arm cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/sparc/dtrace compat/freebsd32 compat/linux compat/svr4

2011-10-09 Thread K. Macy
Will do - sorry for the delay. Thanks, Kip On Wed, Oct 5, 2011 at 6:17 PM, David O'Brien obr...@freebsd.org wrote: On Fri, Sep 16, 2011 at 01:58:51PM +, Kip Macy wrote: Author: kmacy Date: Fri Sep 16 13:58:51 2011 New Revision: 225617 Log:   In order to maximize the re-usability of

Re: svn commit: r206140 - head/sys/vm

2010-04-19 Thread K. Macy
How has the problem been addressed? I'm seeing periodic panics with non-zero resident count with the page lock patch applied. It is possible that I've inadvertently re-introduced an issue you've fixed. Thanks, Kip On Sat, Apr 3, 2010 at 9:20 AM, Alan Cox a...@freebsd.org wrote: Author: alc

Re: svn commit: r205487 - head/sys/vm

2010-03-23 Thread K. Macy
On Tue, Mar 23, 2010 at 6:54 AM, John Baldwin j...@freebsd.org wrote: On Tuesday 23 March 2010 6:33:51 am K. Macy wrote: The size change causes the initialization path to change in a way that currently causes crashes. Are you planning on debugging it further?  Does UMA_BOOTPAGES or NKPT need

Re: svn commit: r205132 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2010-03-20 Thread K. Macy
Be my guest. I've established the technical merits in production. Thanks, Kip On Mar 20, 2010 4:10 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Sat, Mar 13, 2010 at 09:41:53PM +, Kip Macy wrote: Author: kmacy Date: Sat Mar 13 21:41:5... This is another[1] change we agreed (I hoped)

Re: svn commit: r205132 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2010-03-20 Thread K. Macy
On Sat, Mar 20, 2010 at 3:10 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Sat, Mar 13, 2010 at 09:41:53PM +, Kip Macy wrote: Author: kmacy Date: Sat Mar 13 21:41:52 2010 New Revision: 205132 URL: http://svn.freebsd.org/changeset/base/205132 Log:   Don't bottleneck on acquiring

Re: svn commit: r204654 - in head: sbin/newfs usr.bin/truncate

2010-03-03 Thread K. Macy
This broke world. On Wed, Mar 3, 2010 at 11:25 AM, Maxim Sobolev sobo...@freebsd.org wrote: Author: sobomax Date: Wed Mar  3 19:25:28 2010 New Revision: 204654 URL: http://svn.freebsd.org/changeset/base/204654 Log:  Use expand_number(3) from libutil instead of home-grown function to parse