From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B683C761A6 for ; Tue, 4 Apr 2023 13:48:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 189426B0072; Tue, 4 Apr 2023 09:48:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 139FF900003; Tue, 4 Apr 2023 09:48:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1CA9900002; Tue, 4 Apr 2023 09:48:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E0E366B0072 for ; Tue, 4 Apr 2023 09:48:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A0B77AAC06 for ; Tue, 4 Apr 2023 13:48:45 +0000 (UTC) X-FDA: 80643839010.10.149C71A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id F104FC0005 for ; Tue, 4 Apr 2023 13:48:42 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=blD8ShY0; spf=pass (imf28.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680616123; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qC4UT8lxzq31LeVabrzLRsj8WNrkKFZMfS75uySqe4E=; b=pazSiSDatFc6JYVXyQKlHNd4T2O+fSEm36ehrMLxQxQJZbtOB2MRNbFPKb0bcoNOGhqQmi iC0laEMfnHjrRTBqGeuA/C1QIMfTwahRNAyHxrBubqMqjudggROjdNJy8Z+nWo+8YsBxa4 P1yMvWIm8/RJZVcOssrR4sam4u7emic= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=blD8ShY0; spf=pass (imf28.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680616123; a=rsa-sha256; cv=none; b=J57oKIoQDwBNj4F9SHGQ3yFJ9oSVlMVJ/4rePHhNl2+JO/FZjvBuJJgPbCb3vM6oPFgvOy WN5/LbXH9iDY7jXH7c0qRmCygaJiFCJtdKOVNAQL+dSifj+IzIF1SK3YXZmD3eFDTYePFQ IVddcs/UntBelZvWkqtvFJ1voA8ahuw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F16FA63150; Tue, 4 Apr 2023 13:48:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06B53C4339B; Tue, 4 Apr 2023 13:48:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680616121; bh=vSqwQdgD2srET/ADmzV+Ts391AbzKPWVNMOCV2W1ums=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=blD8ShY0ASRyJcmtrG8C2GMr53i1W4GVN2oe5kztE/i0nI+cvI45PeplYp3Dm061P 7xoNrxgab7eUNHhvVikTk16ZDSohhFQnJtjF3stYNcvAAAbYtnS3rn3oAOh2bUehln 40HO3KTZcv141pZyPiWBz34JZRsW/y3HSMjqSDxJrKT6tWouetpi0xA7s3d1G+uKCF NBHof6R9uIxEwRQAwoR/czy0cYuw/j4Vx1nov6eynnEnYWT1ii4oY1Cirbe1WjhQ/V 7Cf2pqthxfgjUvhdTxhtwnN6pnUCAexrM2w+XUH+g0T2JJ5eCmz3vuA2aNXdxK+FaZ nqKtGHgteddZw== Date: Tue, 4 Apr 2023 15:48:36 +0200 From: Carlos Maiolino To: Jan Kara Cc: hughd@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH 4/6] shmem: prepare shmem quota infrastructure Message-ID: <20230404134836.blwy3mfhl3n2bfyj@andromeda> References: <20230403084759.884681-1-cem@kernel.org> <20230403084759.884681-5-cem@kernel.org> <4sn9HjMu80MnoBrnTf2T-G0QFQc9QOwiM7e6ahvv7dZ0N6lpoMY-NTul3DgbNZF08r69V6BuAQI1QcdSzdAFKQ==@protonmail.internalid> <20230404123442.kettrnpmumpzc2da@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230404123442.kettrnpmumpzc2da@quack3> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F104FC0005 X-Stat-Signature: z4h4ehbwz3n16cb6erqi5rqbjy73sgrc X-Rspam-User: X-HE-Tag: 1680616122-809712 X-HE-Meta: U2FsdGVkX18UJSe2p9dBVBjbRdmpGrK6rOnUr49NY/giH/kKhkA2TVQ1prwsy1a/eDHHdx+upv5rmXYbOcLZowfCQP5/5dQdCQG+LH9qv8Y7xlaLqjzPv8vMA/9PqkqhHF1/4x/e4Ift7F1N0LZ4/Drt6PrMGq7Wfw8ZZih4fudA0TE6ebhdx7TddYFSOYfcN5iNA+SHnc5vgcCrBPwMF5lch3X2TxHZ+iVhvY8Dv8aw7k/FS80hPlhy8ysjpaWXjtOJY01kb88aBZrmWMyb/2nIZFtz7oLh56x8mJwDCR55SgeXds4SY6pCJiDPlMreXeB+jd4I5Ooe2ZU9pIGcJEuTaU3WapPvmHYrTj/7RI6k0BXkPvPFVt16bnhl7C9XJyBGhDXQMpc/CP3iK6344N3zDcbcNWa0YbFI6Vt2d13pNNsBwp7gFp1BKMgXWfLSV4hsXfA/byDM3x/xteySDJOa/Ig8i1I5m9zFOAz/X/SMXYJAVIvBV6MDTPMNngBj1lCeD27FmS+dcYMgYtu+yQvzURFumQVxo3xdVYR4lCeEAMCAGw14fJSvNN07l95WStXPaOXr5UOSTA2ntZs60QlnJ0ECKwPq46oPf30lM8Rj654K8oSqLFM9VdFU+kTCL0LR09vwqt6uVZjq4hRsVrg2BvDVkvWhawNbfpvRgcI5OQ3qsh+EaOkdghVFJvTW8kDGWyaAV3F7A0GlE0RWg1pjiycon273Sb44V87stiBshDei9vxu9Ybj/cBpP/qrn7ftj+RL7LVydLzfiLBWaWKX0qUgCIIk4qr0lOQ2DU4EiRMK8+2MM19p1r8s1RDDdpl4sTpu7dyzz7hJBMxAxcgC7P5FsFx0q1C1i09UQ+eiNTqD2bwOBlvTGByFR5Qs7QF31mHiJGdDg4L1gEe41w/uNeDvdTvpIjWvcmN7YNL2udXZvtbHf3QMU39QnfrEwr5xtqV5/X+nAP7dbPY t9gGz0rd nsORVmRvJuZriaeBGdojnqM4Ni7M4C+HblAhayZJs7moj36BgSYJ9P21FAW4UMqsFzjszW+oOSbMZn9PrGhcJ4Cud1bkDkDdbNxp4kZ4FswNzOCBY+jLFh5kwqReLbyLkTRMiiIHKioDaS1Xcuk8k6MAtAxfiP3B7N/pdEE4FWz/PPO3QB12TLKo3KAJaG9I2QMAgKNOgSL1odXQcRS+HfxLZBgHhChAA1KdaatcHMj4sDpFnY58ZZNoz+OG18HzNUZL6BdavjIHhenXbVH7hUMCChBp5jEsyyAOJnLjr4jcCMCpCkd5kmAQX0dZeQSgewgSXDDtkZ8TtZo5S7FuQTOsn0QBAZ5gPOgnLzFqpuCWSNeo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Honza. > > + if (!dquot->dq_dqb.dqb_bhardlimit && > > + !dquot->dq_dqb.dqb_bsoftlimit && > > + !dquot->dq_dqb.dqb_ihardlimit && > > + !dquot->dq_dqb.dqb_isoftlimit) > > + set_bit(DQ_FAKE_B, &dquot->dq_flags); > > + spin_unlock(&dquot->dq_dqb_lock); > > + > > + /* Make sure flags update is visible after dquot has been filled */ > > + smp_mb__before_atomic(); > > + set_bit(DQ_ACTIVE_B, &dquot->dq_flags); > > I'm slightly wondering whether we shouldn't have a dquot_mark_active() > helper for this to hide the barrier details... This sounds good to me, would be ok for you if I simply add this to my todo list, and do it once this series is merged? I'd rather avoid to add more patches to the series now adding more review overhead. I can send a new patch later creating a new helper and replacing all set_bit(DQ_ACTIVE_B, ...) calls with the new helper. > > > +out_unlock: > > + up_write(&dqopt->dqio_sem); > > + mutex_unlock(&dquot->dq_lock); > > + return ret; > > +} > > + > > +/* > > + * Store limits from dquot in the tree unless it's fake. If it is fake > > + * remove the id from the tree since there is no useful information in > > + * there. > > + */ > > +static int shmem_release_dquot(struct dquot *dquot) > > +{ > > + struct mem_dqinfo *info = sb_dqinfo(dquot->dq_sb, dquot->dq_id.type); > > + struct rb_node *node = ((struct rb_root *)info->dqi_priv)->rb_node; > > + qid_t id = from_kqid(&init_user_ns, dquot->dq_id); > > + struct quota_info *dqopt = sb_dqopt(dquot->dq_sb); > > + struct quota_id *entry = NULL; > > + > > + mutex_lock(&dquot->dq_lock); > > + /* Check whether we are not racing with some other dqget() */ > > + if (dquot_is_busy(dquot)) > > + goto out_dqlock; > > + > > + down_write(&dqopt->dqio_sem); > > + while (node) { > > + entry = rb_entry(node, struct quota_id, node); > > + > > + if (id < entry->id) > > + node = node->rb_left; > > + else if (id > entry->id) > > + node = node->rb_right; > > + else > > + goto found; > > + } > > + > > + up_write(&dqopt->dqio_sem); > > + mutex_unlock(&dquot->dq_lock); > > We should report some kind of error here, shouldn't we? We do expect to > have the quota_id allocated from shmem_acquire_dquot() and we will be > possibly loosing set limits here. > Sounds correct, I'll update it once we agree on how to proceed with your above suggestion of dquot_mark_active(). > Otherwise the patch looks good to me. > > Honza > -- > Jan Kara > SUSE Labs, CR -- Carlos Maiolino