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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B03B9C43444 for ; Wed, 16 Jan 2019 06:22:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 803E820866 for ; Wed, 16 Jan 2019 06:22:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dZegR2Qa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387471AbfAPGWm (ORCPT ); Wed, 16 Jan 2019 01:22:42 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:43662 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729622AbfAPGWm (ORCPT ); Wed, 16 Jan 2019 01:22:42 -0500 Received: by mail-yb1-f196.google.com with SMTP id t16so2063781ybk.10; Tue, 15 Jan 2019 22:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s5tRU2BAh5wQm1Z35izUxtrQDWlFue8aankPz1iDq14=; b=dZegR2Qa1wkxk7COgo3CTw49uB8+lIEdiTEnLiFcKIjxufpyTNu49dSl6HmpygKSoh eDhEiYGDptf2J2GVCf1GtDSBJt3X9BIz0uU7ZIlRZ7H3zPGs0lkW1eVPaCFvj+xjH//z VU7YUZo37xKwXPPuq0WCTo/+otK4wFsOtWbxy4QhqhnRiqbynh81HK9+3nIIxGZoIMjd vKeBbZgunAmQbCbjqurP523P0VmzsedvpN5t6nQmngXtPIGKwyl20d0NHNZArE2jQ6Jg dVyz2/cWEETk6x0yDNhGp5zuoYSTOzWyAE1vpIHiESr7CZBlZh+yu97R+C/lMDl4XC9/ p8Ig== 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=s5tRU2BAh5wQm1Z35izUxtrQDWlFue8aankPz1iDq14=; b=DcwuHbtywMEpUUkr+U9VSZ2Exte7NiG92VmoeoQdIC9hKeIgX0XfmDVjr4U3QRcKk/ I2ypCt9LiIKbcdEpRb1elXtwGZUhNjlpiri0P+XuBrpm9/qb0ekV1iOat1oAKpISJDZy AdigAb1nmNq3JpHncVUYoteVCukkstLLky7UoRi2SqCasE2Uc+ktGi7OcSwSGDQQX9OW Emq5oDz83K0uRJ0Ow6qh+oQgFkg099pRbbrjViZPAP7owL1VWHX/xhnEX7u63rYHe2SP Imill49Vb9DInF1S05NtlBIGXxZJtORzLJbTkvO1lV1uqdztKruIlfnwdHrIg+zhAAiU lViQ== X-Gm-Message-State: AJcUukeFtwvgKTK1kP8xeBlr0NZyKtiAp/AS/Wb/OjjRsqIZZdMVHTlY DQtVI1Wvgg2eTJHhC55nwHl3qXLjzcu0mai7ixo= X-Google-Smtp-Source: ALg8bN4bNtJ/UsDC+O5xwJhGkpu32xBOnQ38slXCAVPxWz62HmAFgDLoNlplJ1+bX8cIirdlpn0NMbnSwcqlB2S+gAQ= X-Received: by 2002:a25:8003:: with SMTP id m3mr957826ybk.337.1547619760952; Tue, 15 Jan 2019 22:22:40 -0800 (PST) MIME-Version: 1.0 References: <20190102174736.GB29127@quack2.suse.cz> <20190108100500.GA15801@quack2.suse.cz> <20190115092414.GA4138@quack2.suse.cz> In-Reply-To: From: Amir Goldstein Date: Wed, 16 Jan 2019 08:22:29 +0200 Message-ID: Subject: Re: [GIT PULL] dtype handling cleanup for v4.21-rc1 To: Linus Torvalds Cc: Jan Kara , linux-fsdevel , Ext4 , Al Viro 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 On Wed, Jan 16, 2019 at 4:56 AM Linus Torvalds wrote: > > On Tue, Jan 15, 2019 at 9:24 PM Jan Kara wrote: > > > > What has happened to this pull request? It may be too late for this to be > > merged now but I'd like to understand why it was not merged or rejected... > > Sorry, initially I left if for later consideration after rc1, and then > I just forgot about it. > > I didn't see much point to the cleanup when it actually adds lots of > lines and no actual advantage. The whole dentry type translation > really is fs-specific and it might just happen to be shared. But why > share it if it only adds complexity and unnecessary abstraction? > Linus, I guess some of the reasoning got lost from the original patch series to the pull request. The pull request fails to mention this is an ext2 (very very old) bug fix. Jan has agreed to carry these 2 patches first to ease to herding all other filesystem patches in the series: https://marc.info/?l=linux-fsdevel&m=154060161813861&w=2 https://marc.info/?l=linux-fsdevel&m=154289087825040&w=2 The overall cleanup reduces ~100LOC and was acked by many filesystem maintainers as a welcome improvement (not as added complexity) Instead of fixing a potential out-of-bounds access bug that was copy&pasted from ext2 to many other filesystems, the approach taken was to create a single correct implementation and use it in all those filesystems. It is true, that this is filesystem specific code and new filesystem on-disk formats is not bound to use the same values. But the on-disk values used for all those filesystems formats are not going to change for eternity, so there is no meat on the fs-specific argument. The conversion is common de-facto forever for code that wants to read inodes from existing drives. If you pull these 2 patches now, other patches could be applied by fs maintainers for next cycle. Thanks, Amir.