Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4061075pxb; Mon, 4 Oct 2021 16:29:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgWjTdUZrM5cc3sWDFvz7NJvB+UnSTeXmh0E93JFpr653DedYfL4vBMa/MXF5xwYvWBQK9 X-Received: by 2002:a50:cf86:: with SMTP id h6mr21734907edk.104.1633390162900; Mon, 04 Oct 2021 16:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633390162; cv=none; d=google.com; s=arc-20160816; b=ghCy5Axsj5wzBKgmNnbaJHnCQ9cHldjn+jXMyqmY7GwWGX45tBUn7a5k1u0xWPn7CU ZnCFgAroYAuTFuUqq1XbFun8BzjEki8U1M+FLH/tLX3qwRex+UkNXlnOAZ0HdGfBEI6P J7QaHuoIJkae6gkUyWkE6KtD5m6fM0Rhb6jJAocHg+zTN6GkliacrKFr3NgbzGvCbAxH p6QaXRHnzQlm3/tgcxDTGWRJwa8082R9gBrC+RUcGPYM9K5cWK2c0bRfMrS3WWnHzRIC aXS/i56W3bk+syIkHirbqK+xFzqDRBfKpuWp0rSgBu7hwGDRrtjwDNKDW2s18zHZQhm4 aMWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=ksk0ituITPDur7VOi1jCXxieV8Du5TeIguFZkpAVdZs=; b=YugQFUdbHr81y4hNq2r20PtzXnkgdFMU6yGxElmPK7HXEwRHnXg5mOit9h8xhol4mh ZAc1zeZpLnHXsIkOV6SU/uddJQ2Q3UsC1nOsWmxTIcEoqvqQbpsoQf0GsNYPFJdWP5fU tjtS35X5PWbABthsfwZ8LfcYon39+51LgfhkIEZ21i4XBWT88C3tymThk+t0Kssnvf4E su0vzjAoyPF0DiQuK8EgSQitaUYPKkuSczmbABcYZwcg8gAKHAyTrPw54XAuFM90zU2z mSicOdHoRAilv7PjNi3WobMjPTIM0rI4Vq5C8QmYUv+RHvbsx44vtPNMZaySPLf6R8bx 94+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=iccVLZIu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr6si3218472ejc.711.2021.10.04.16.28.59; Mon, 04 Oct 2021 16:29:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=iccVLZIu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238658AbhJDSa4 (ORCPT + 99 others); Mon, 4 Oct 2021 14:30:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238633AbhJDSaw (ORCPT ); Mon, 4 Oct 2021 14:30:52 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9CD1C061749; Mon, 4 Oct 2021 11:29:02 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id rm6-20020a17090b3ec600b0019ece2bdd20so565904pjb.1; Mon, 04 Oct 2021 11:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ksk0ituITPDur7VOi1jCXxieV8Du5TeIguFZkpAVdZs=; b=iccVLZIu59DB5VPOrdxx0bcJFMS/iGHtuLWCAMdKR/gBUXElbZvJTn6B5bMYOsrHnZ xuWo7RKx36K5p+IvSTKGNUw3YM2W1xLIucrR8Z1UrutBLiLzi5mgNGVjtJAz/QJxQ9Jt kWB7Cmh5xaWcTrNSlXGdozrtBCeu5w5iY4y7aVE0DEwqyxChwAhcrolcXYIj1J5Uk3KC f/UA+RvUyKkT8c+fWJ8zmNbTMufzlrrAoqu4C6y/oP0GxY1e6n3XlDOoZ2VTRNNNIq8i piENPpRSmZV1YQLjeTi6b1SlzLg/LndQ8R8JQIR4+Oo7na8633EximFc9+QZ4+MIMb2t RxeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=ksk0ituITPDur7VOi1jCXxieV8Du5TeIguFZkpAVdZs=; b=2yZcF7Y2kT9E+r4MIx7oYk+h+ihA24voUKO80KxYQALro7N5AVKGjXHptP7c/Zz0xw GCT4939HzIXCIVGtQEc3NT/+qkZbiUm2x9eg65Vpl0Rhcbc89rDAb9/30g1VVtIRaYAZ u716kdm9MmTNXJXnMGLFOfD+NKc3QCOSokaaJxgLjM6Mimm+BvRlUks742lnCjwNa9yZ vhC/4/F4MJt7Or2/uH9yR2WhqZeU37Ej5XGFDRSh5CQF3hmEJ3gb5Mr+/VGRuZI+Vudt DJq8zPnd1swZDNKnjzYBCExQmwoYgPdHu10P18/tpQAZNhkF/osTMLiw8iYwrgW81wyX 47RA== X-Gm-Message-State: AOAM532NVNtN5PYQebiuJtmgag4RVsz1VTLqi+mFIomfVH6cWLWtUPgq RzIuJ0zfzoz1uTdPRBcPtEI= X-Received: by 2002:a17:90a:5d01:: with SMTP id s1mr32191111pji.16.1633372142227; Mon, 04 Oct 2021 11:29:02 -0700 (PDT) Received: from google.com ([2620:15c:211:201:db55:938c:e15a:4670]) by smtp.gmail.com with ESMTPSA id 17sm15888836pgr.10.2021.10.04.11.29.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 11:29:01 -0700 (PDT) Sender: Minchan Kim Date: Mon, 4 Oct 2021 11:28:59 -0700 From: Minchan Kim To: Brian Geffon Cc: Andrew Morton , Nitin Gupta , Sergey Senozhatsky , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-block@vger.kernel.org, Suleiman Souhlal , Jesse Barnes Subject: Re: [PATCH] zram: Allow backing device to be assigned after init Message-ID: References: <20211001181627.394921-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211001181627.394921-1-bgeffon@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 01, 2021 at 11:16:27AM -0700, Brian Geffon wrote: > There does not appear to be a technical reason to not > allow the zram backing device to be assigned after the > zram device is initialized. > > This change will allow for the backing device to be assigned > as long as no backing device is already assigned. In that > event backing_dev would return -EEXIST. > > Signed-off-by: Brian Geffon > --- > drivers/block/zram/zram_drv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index fcaf2750f68f..12b4555ee079 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -462,9 +462,9 @@ static ssize_t backing_dev_store(struct device *dev, > return -ENOMEM; > > down_write(&zram->init_lock); > - if (init_done(zram)) { > - pr_info("Can't setup backing device for initialized device\n"); > - err = -EBUSY; > + if (zram->backing_dev) { > + pr_info("Backing device is already assigned\n"); > + err = -EEXIST; > goto out; Hi Brian, I am worry about the inconsistency with other interface of current zram set up. They were supposed to set it up before zram disksize setting because it makes code more simple/maintainalbe in that we don't need to check some feature on the fly. Let's think about when zram extends the writeback of incompressible page on demand. The write path will need the backing_dev under down_read(&zarm->init_lock) or other conditional variable to check whether the feature is enabled or not on the fly. It adds locking dependency as well as performance overhead(I don't think it's a good deal that scarfice hot path for rare event even though it's not that big).