Message ID | 20230306125150.12166-1-fmdefrancesco@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1836343wrd; Mon, 6 Mar 2023 05:21:21 -0800 (PST) X-Google-Smtp-Source: AK7set/teNetLyN724NW7ssKWaX7G+k9TYPVzSbvfvBB+v8KLVGatt2F+nj1dgeYlyIEUEXcJ6pi X-Received: by 2002:a17:906:1846:b0:888:1f21:4429 with SMTP id w6-20020a170906184600b008881f214429mr10575849eje.19.1678108881510; Mon, 06 Mar 2023 05:21:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678108881; cv=none; d=google.com; s=arc-20160816; b=NDBb8kt7X2yzWhuN+jlhUL9a/XSECpg8AHQFydqKx7aZckxxWNOtKWxNPmcNbvCDKi 9EFWqaegb0FGcyR2sBLpjE75Yj6jpZABdAFy/1d6ykf2lOT6FmEJExb9+btr62Ptg1VM c2L0H2C6ber9mjLN83h8ehrz6L9YMc8uqUjaF7F9zUYCm1xDCbt2IgOU51R96D0KcErN ltxm5HtuSferIFoY/wXvW9FwlFFgBnp82Gtf9gc2RjF4ro9wxFE8WOLFDOt3QnqTvWqq 38QedgQqqYl9n9FVtT15gxuA78DMEjnD0ByxP2Qm+/UjapdGtEIALOqIyepASURKewZW t+UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=xf3l4GRdn5RdXOF0TrzQkV+XhTtN1QTwo37gy5enBAY=; b=SoejN06pDyHoUHOvq6MIuyQ6yZD+3ri6ROvYqaYn1wNWF9/kansE7Vsg9Iv0VgUr8O jASlTagAtlAOgSULl9Z4utJ1q6xt9uwF6N0qjtyWyS9uX/QmkNQHkeMFmg4KLiDPg/qL L7APsF+msc3bX5bu8IBj7orK0Sk15GCZ3qsXri8q76ze6bTScAqwJiU+vLU8VUkZAYTZ ccAQtmlQcDvbPxvPE0K9ZywkfHFtDog+1bYrHn+2iuAGXe5y07KJy50XAVj+yD0MKa+B 52FQRODKEy+sL772geEJOuaUc8jIIDNuAVDs9UUxw08u9ocjWwHxgTr8Wq7aq7g2AGhe 98Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eykxkvNN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qt23-20020a170906ecf700b008d9f600f9e4si9268057ejb.702.2023.03.06.05.20.58; Mon, 06 Mar 2023 05:21:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eykxkvNN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229929AbjCFMwA (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 6 Mar 2023 07:52:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229646AbjCFMv6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Mar 2023 07:51:58 -0500 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D7402B609 for <linux-kernel@vger.kernel.org>; Mon, 6 Mar 2023 04:51:57 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id m25-20020a7bcb99000000b003e7842b75f2so5114418wmi.3 for <linux-kernel@vger.kernel.org>; Mon, 06 Mar 2023 04:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678107116; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=xf3l4GRdn5RdXOF0TrzQkV+XhTtN1QTwo37gy5enBAY=; b=eykxkvNNtMYSWf6ufwdJrWSX6oeFvtqDQdklHyj2cOoxMKF7g8mNivFFRO9bCSD69+ 7+go8HWk9r0E+UAM8VNsYaOsHREzYxdFNykPSpJCqDWjOyWFxznwNrIK2AKlHTbF9dkq EPwTmVznTwgAPK3FxL3a+yoPv4fd813hpQ9iMV/kRUqtpuuL4k+opXneFZYKo3i9c5Wm ZU7eW+7wpz9e+OrD1m1uT7QH0xJDNVPzWaTOE1L5zZzcqyHkSZHutSJ10LkmJeQIhO/J GchdAs1OyPK0I82uGMXocbMt+pCe+OFDk4EzrQFZlVdz2OMfRiBXWuPrfXvl15ejZNM0 RmVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678107116; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xf3l4GRdn5RdXOF0TrzQkV+XhTtN1QTwo37gy5enBAY=; b=TLHobKda+Lx0Ba/Alq1nmEHKWvFVnPF8cqoM9kDI57lJP6UxpmnqMx7YITNr9ZMQzU MESpyyrW1hnusZskzJCH3hJ/XBMlLG+JW9oueOfDR2jMwyBAafLts7jpPqSu+n4MrrK8 guQ+yvo34FUzNWkANbqDP7RPa1ybaOKLdCUU4ybnCnDHom/3elLV924OrC6TG9zOPine J5An2Y6BBYCwHiIdYP3ZhP+c/gG/YSURwu5WLkOK4E/tXxzv1E50Cl0lj+1d3t6NgBHR Va5/HSMgtUjt/ROmuiFE71ODqLm4V7uQ7//Ybssr0dR+7VYv8ZI6Qu5HxKZqsxeo1tw1 sPDw== X-Gm-Message-State: AO0yUKVxdL63TYuU8XmI12K2/yevfQPbRMm8jqRV1TJa9u9uTVj6HIT1 SW4hNnMRx2I+mjWdvasLcnU= X-Received: by 2002:a05:600c:310a:b0:3dc:555c:dd30 with SMTP id g10-20020a05600c310a00b003dc555cdd30mr9256513wmo.27.1678107115653; Mon, 06 Mar 2023 04:51:55 -0800 (PST) Received: from localhost.localdomain (host-79-43-1-179.retail.telecomitalia.it. [79.43.1.179]) by smtp.gmail.com with ESMTPSA id h6-20020a1ccc06000000b003e118684d56sm14161383wmb.45.2023.03.06.04.51.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Mar 2023 04:51:54 -0800 (PST) From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com> To: Christian Brauner <brauner@kernel.org>, Dave Chinner <dchinner@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, "Fabio M. De Francesco" <fmdefrancesco@gmail.com>, linux-kernel@vger.kernel.org Cc: Ira Weiny <ira.weiny@intel.com> Subject: [PATCH] fs/sysv: Don't round down address for kunmap_flush_on_unmap() Date: Mon, 6 Mar 2023 13:51:50 +0100 Message-Id: <20230306125150.12166-1-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759624698718950723?= X-GMAIL-MSGID: =?utf-8?q?1759624698718950723?= |
Series |
fs/sysv: Don't round down address for kunmap_flush_on_unmap()
|
|
Commit Message
Fabio M. De Francesco
March 6, 2023, 12:51 p.m. UTC
The kernel virtual address passed to kunmap_flush_on_unmap() has no more
any need to be rounded down.
Therefore, delete the rounding down of "page_addr" when passed to
kunmap_local() in dir_put_page().
Don't backport without commit 88d7b12068b9 ("highmem: round down the
address passed to kunmap_flush_on_unmap()").
Cc: Ira Weiny <ira.weiny@intel.com>
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
---
fs/sysv/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Mar 06, 2023 at 01:51:50PM +0100, Fabio M. De Francesco wrote: > The kernel virtual address passed to kunmap_flush_on_unmap() has no more > any need to be rounded down. > > Therefore, delete the rounding down of "page_addr" when passed to > kunmap_local() in dir_put_page(). > > Don't backport without commit 88d7b12068b9 ("highmem: round down the > address passed to kunmap_flush_on_unmap()"). Applied (#work.misc). FWIW, I've rebased the ext2 series to -rc1 (and realized what got Jan confused about ext2_rename() changes). Re minixfs: it's actually very close to sysv, so much that at one point I considered merging them - making minixfs one of sysvfs flavours. Think of it as v7 filesystem with the simpler improvements copied from FFS. Cylinder groups and variable-sized directory entries - too complex for Minix purposes. Lifting the name length limit from 14 to 30 - sure, why not? 32bit block numbers - eventually made it, so did 32bit inode numbers (in v3). The main advance compared to v7 is the use of bitmaps for block and inode allocation. Unlike FFS it's all in one lump, but at least it's not the "free block list". For directory contents handling it doesn't matter at all - there minixfs is really just another sysvfs variant. Directory is stored the same way as a regular file would've been, the data in it is an array of fixed-sized entries (16, 32 or 64 bytes, depending upon the filesystem version), each consisting of inode number (2 or 4 bytes) + array of characters representing the name; name shorter than the longest possible are NUL-terminated. Anyway, I've slapped together a counterpart of your sysv series, see #work.minix
On lunedì 6 marzo 2023 18:27:59 CET Al Viro wrote: > On Mon, Mar 06, 2023 at 01:51:50PM +0100, Fabio M. De Francesco wrote: > > The kernel virtual address passed to kunmap_flush_on_unmap() has no more > > any need to be rounded down. > > > > Therefore, delete the rounding down of "page_addr" when passed to > > kunmap_local() in dir_put_page(). > > > > Don't backport without commit 88d7b12068b9 ("highmem: round down the > > address passed to kunmap_flush_on_unmap()"). > > Applied (#work.misc). Thanks! I'm using (again, sorry) this opportunity to remind you that I'd really appreciate if you could also set aside some time to look at my patch to fs/ aio.c. Instead I'm not sure yet who is at the moment responsible for the patches to fs/ufs... > FWIW, I've rebased the ext2 series to -rc1 (and > realized what got Jan confused about ext2_rename() changes). I just git-clone(ed) your "vfs" tree and started with building and testing the #work.ext2 branch, without and with your latest commits (from Linux 6.3-rc1 merge onward). As said in the thread with the pull request of my fs/sysv related patches I'll test with (x)fstests in a QEMU/KVM x86_32 VM, 6GB RAM, running an HIGHMEM64GB kernel. > Re minixfs: it's actually very close to sysv, so much that at one point > I considered merging them - making minixfs one of sysvfs flavours. OK, so porting fs/sysv (or fs/ufs) changes to fs/minix should be an easy task. > Think of it as v7 filesystem with the simpler improvements copied from > FFS. Cylinder groups and variable-sized directory entries - too > complex for Minix purposes. Lifting the name length limit from 14 to > 30 - sure, why not? 32bit block numbers - eventually made it, > so did 32bit inode numbers (in v3). > > The main advance compared to v7 is the use of bitmaps for block > and inode allocation. Unlike FFS it's all in one lump, but at least > it's not the "free block list". > > For directory contents handling it doesn't matter at all - there minixfs > is really just another sysvfs variant. Directory is stored the same > way as a regular file would've been, the data in it is an array of > fixed-sized entries (16, 32 or 64 bytes, depending upon the filesystem > version), each consisting of inode number (2 or 4 bytes) + array of > characters representing the name; name shorter than the longest possible > are NUL-terminated. > > Anyway, I've slapped together a counterpart of your sysv series, > see #work.minix I must admit that I don't yet own enough good knowledge of the details you are mentioning above. However, thanks for sharing! Those insights surely help me to better understand what details to look at when trying to tell the differences and commonalities between filesystems. I'll take a look at #work.minix in the next days (build, test, review), but only when I'm done with #work.ext2 (I have little spare time because ATM I'm attending some courses and, in the meantime, I'm also volunteering as a co- mentor with Ira). Again thanks, Fabio
diff --git a/fs/sysv/dir.c b/fs/sysv/dir.c index 999bceb99974..e2d26eb78af7 100644 --- a/fs/sysv/dir.c +++ b/fs/sysv/dir.c @@ -30,7 +30,7 @@ const struct file_operations sysv_dir_operations = { inline void dir_put_page(struct page *page, void *page_addr) { - kunmap_local((void *)((unsigned long)page_addr & PAGE_MASK)); + kunmap_local(page_addr); put_page(page); }