Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756753AbbHFV4L (ORCPT ); Thu, 6 Aug 2015 17:56:11 -0400 Received: from smtp.variantweb.net ([104.131.104.118]:41723 "EHLO smtp.variantweb.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754630AbbHFV4I (ORCPT ); Thu, 6 Aug 2015 17:56:08 -0400 X-Greylist: delayed 342 seconds by postgrey-1.27 at vger.kernel.org; Thu, 06 Aug 2015 17:56:08 EDT Date: Thu, 6 Aug 2015 16:50:23 -0500 From: Seth Jennings To: Andrew Morton Cc: Dan Streetman , Linux-MM , linux-kernel Subject: Re: [PATCH 1/3] zpool: add zpool_has_pool() Message-ID: <20150806215023.GA8670@cerebellum.local.variantweb.net> References: <1438782403-29496-1-git-send-email-ddstreet@ieee.org> <1438782403-29496-2-git-send-email-ddstreet@ieee.org> <20150805130836.16c42cd0a9fe6f4050cf0620@linux-foundation.org> <20150805150659.eefc5ff531741ab34f48b330@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150805150659.eefc5ff531741ab34f48b330@linux-foundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1434 Lines: 35 On Wed, Aug 05, 2015 at 03:06:59PM -0700, Andrew Morton wrote: > On Wed, 5 Aug 2015 18:00:26 -0400 Dan Streetman wrote: > > > > > > > If there's some reason why this can't happen, can we please have a code > > > comment which reveals that reason? > > > > zpool_create_pool() should work if this returns true, unless as you > > say the module is rmmod'ed *and* removed from the system - since > > zpool_create_pool() will call request_module() just as this function > > does. I can add a comment explaining that. > > I like comments ;) > > Seth, I'm planning on sitting on these patches until you've had a > chance to review them. Thanks Andrew. I'm reviewing now. Patch 2/3 is pretty huge. I've got the gist of the changes now. I'm also building and testing for myself as this creates a lot more surface area for issues, alternating between compressors and allocating new compression transforms on the fly. I'm kinda with Sergey on this in that it adds yet another complexity to an already complex feature. This adds more locking, more RCU, more refcounting. It's becoming harder to review, test, and verify. I should have results tomorrow. Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/