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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ACD0C35243 for ; Fri, 24 Jan 2020 04:31:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D1912072C for ; Fri, 24 Jan 2020 04:31:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KDHO7h9B" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730589AbgAXEbD (ORCPT ); Thu, 23 Jan 2020 23:31:03 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35948 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729491AbgAXEbC (ORCPT ); Thu, 23 Jan 2020 23:31:02 -0500 Received: by mail-lj1-f196.google.com with SMTP id r19so934019ljg.3 for ; Thu, 23 Jan 2020 20:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YARMc3ae9hSUEoLGMas34bGpYXx9jRcQkvor0pcL47o=; b=KDHO7h9B/b3mjy26Oj4EeSJIUNyQLYKaSj3d1nBNy4K7dVvqvhrzQt3G+uksHtglCC GEn7l0fqTV7YiLooSM8wJDBDZ3zMa1NiXyT+I4cRb1BWaZgPHz2JpFTvojB+HO94ozad MFaWKBQ9Zo4BEUhjLXI4paXN7kyNHtoN96Dwri5CF7MjQQUEfySc0AQBNxyC2R8iJZCg guQxm94eI0DXd65SS/rnuHoJaoHhIN0BgEW5d7+6uC/9ey1p7B8TnBe/F7DCn8v2dGTO IOVEJ7yvZF/HCRcAWrK9qPC6Itzo8kSjahJNwMYca4x2RJsn6vyrLjbauzKhHQ8haKAe U9uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YARMc3ae9hSUEoLGMas34bGpYXx9jRcQkvor0pcL47o=; b=SqzE7Wc7KFS359rW63jZLcxTdyOxTLnPM0Lqw1kWw4TbkZmPCvoYxbdnBBUWu2/dVR H9x1Tk41920ZJO8GVGi/iTQPHRzM0uZmCiVNhfv5mLQKgceDGvH578i2MUjeavIen7zx VZr93jJOPC1R60QdaqzoqAHBZHKvO7ffr3VgY8M342n84L9m5qLDr5If5gO4xFy9IUVf GrVWOO94ZfZs/uQu7fhZEEyXgTDP7q24lkseix6dyEaTwNHEtu48PEBbmZKTZpzOiIuj i3P+inaFZb5XYrOPTG3C1imQ54WUcjrjcTp6VrOcAu8XJUp8a7ezuJMtRuJCYxlYKQDv VH2Q== X-Gm-Message-State: APjAAAVkJbMV8K+5+6H901C/hVW0go/X4OxD82JCyyVyyE5wCtUhlg3Z tk7JQrHXyerZ/oveGOr208TLZ7bKvfOW/cqssugEFQ== X-Google-Smtp-Source: APXvYqxDuXJqv/c/SqXLq4l0cAQvIWw6dIaAJm1RLNe4FSj10K4FMOIdAwv3/v/qIrOL5GnNI2cG/1NfCFFst9nvTGM= X-Received: by 2002:a2e:7816:: with SMTP id t22mr1024528ljc.161.1579840260417; Thu, 23 Jan 2020 20:31:00 -0800 (PST) MIME-Version: 1.0 References: <20200117214246.235591-1-drosen@google.com> <20200117214246.235591-6-drosen@google.com> <20200120013528.GY8904@ZenIV.linux.org.uk> In-Reply-To: <20200120013528.GY8904@ZenIV.linux.org.uk> From: Daniel Rosenberg Date: Thu, 23 Jan 2020 20:30:49 -0800 Message-ID: Subject: Re: [PATCH v3 5/9] vfs: Fold casefolding into vfs To: Al Viro Cc: "Theodore Ts'o" , linux-ext4@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Eric Biggers , linux-fscrypt@vger.kernel.org, Andreas Dilger , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Gabriel Krisman Bertazi , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > ... buggering the filesystems (and boxen) that never planned to use > that garbage. > I'm planning to rework this as dentry ops again. Your other comments point out some issues that also exist in the old dentry_operations, so that's a good opportunity to fix those up. How do you feel about just having the two entries in struct super_block? With them there, I can add the dentry_operations to fs/unicode where they won't bother anyone else, while not making every filesystem that uses it have to carry near identical code. > > Are you serious? > 1) who said that ->d_inode is stable here? If we are in RCU mode, > it won't be. > 2) page-sized kmalloc/kfree *ON* *COMPONENT* *AFTER* *COMPONENT*? > #2 is the part that made me the saddest in the patch. I'm planning to move this to the unicode subsystem so it can just walk through the name as it computes the hash without needing any allocation. > > ... and again, you are pulling in a lot of cachelines. > I probably should've just given it a DCACHE flag, like what fscrypt is using. A simple flag there would've done everything that I'm doing without making the cache super sad and making any attempts at making it actually work with RCU much simpler. > IMO the whole thing is not a good idea.