From owner-svn-src-all@freebsd.org Wed Aug 5 11:27:46 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCDA69B3669; Wed, 5 Aug 2015 11:27:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 739E3954; Wed, 5 Aug 2015 11:27:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZMwrD-000OqL-OL; Wed, 05 Aug 2015 14:27:39 +0300 Date: Wed, 5 Aug 2015 14:27:39 +0300 From: Slawa Olhovchenkov To: Steven Hartland Cc: Warner Losh , src-committers@freebsd.org, Peter Wemm , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Konstantin Belousov , Julian Elischer Subject: Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <20150805112739.GE8792@zxy.spb.ru> References: <55BF557B.60009@multiplay.co.uk> <20150803120359.GC2072@kib.kiev.ua> <55BFC296.5050402@freebsd.org> <20150803194412.GC8792@zxy.spb.ru> <55C07826.9070002@multiplay.co.uk> <20150804161448.GC24698@zxy.spb.ru> <55C11B5F.2080007@multiplay.co.uk> <20150804202411.GD8792@zxy.spb.ru> <55C1EF1F.6040204@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C1EF1F.6040204@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 11:27:46 -0000 On Wed, Aug 05, 2015 at 12:10:23PM +0100, Steven Hartland wrote: > >> Just in case you didn't notice kib committed a fix for i386 thread0 in > >> r286288 so this may not be needed at all any more which is good news :) > > If I understund kib fix (and you about ZFS stack requirements) you > > need check curthread->td_kstack_pages (for case old, unfixed kerenel, > > depended from KSTACK_PAGES in Thread0). > > > > I.e. for all cases: > > > > - unfixed kernel with KSTACK_PAGES < 4 > > - unfixed kernel with KSTACK_PAGES >= 4 > > - fixed kernel with KSTACK_PAGES < 4 > > - fixed kernel with KSTACK_PAGES >= 4 > > - compiling zfs.ko separately from kernel with different KSTACK_PAGES > > - using zfs.ko with old kernel > > > > checking curthread->td_kstack_pages is right way (or, may be > > curthread->td_kstack_pages*PAGE_SIZE -- I am not cleanly understund > > what need to check -- size in bytes or size in pages). > > Checking KSTACK_PAGES by ifdef can produce vrong result. > Its not clear to me if curthread will be thread0 however in unfixed printf("zfs__init thread check: curthread %p thread0 %p\n", curthread, &thread0) ? > thread0 stack size would have been kstack_pages so at the time this was > still correct IMO. Not clear to me where is real limitaion -- in thread0 or in thread executed zfs__init. Just for me, what is correct? 1) limitation in thread0 (some code from ZFS executed later in thread0, not in current tread), not in zfs__init 2) limitation in zfs__init (or in some code executed later in current thread), currently zfs__init exeuted in thread0 > Just to be clear this is not checked by an ifdef, that's just OS guard > which is correct. > > Latest revision which now explicitly checks thread0 stack size is now > available: > https://reviews.freebsd.org/D3279 nice to me.