Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp982457iob; Fri, 13 May 2022 18:31:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0IgvU7DDQ4WFjX/oDyLJ7RfLxsm8q1E38gK7pMsyTMGlD5OxhzZyebAFegHgzccKvZoXF X-Received: by 2002:adf:e642:0:b0:20c:b18f:f607 with SMTP id b2-20020adfe642000000b0020cb18ff607mr5859414wrn.293.1652491878672; Fri, 13 May 2022 18:31:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652491878; cv=none; d=google.com; s=arc-20160816; b=z9cdbBD0LYVe+rYkAezCC3zMtIoZmtBQ2YI4GMnxBX0a1IOIurbygDv2W9CT/W6xGS AyD6yw5sc0GCk3pTU7GH/O/KRNIbCrHf7BNp+9l2ojpRuyqVKo4nK+73aieFlvHPOhpV pJgt2NVkhbA62dJE5Va1GHYxmBCTrr3zDhC9m1IRR3qQJCc+HS3tySma0TWuVdEplSVh ifTRNYawBY9RPxYIDX2WJ0reFWTEY5bIniHtoy7HRdqP3FCuOyXcZalx2Npw/BqMQ/jd nu5RR8H7fEBuIeoL2O3lIhiULCQqh2x74le00YwRnpygEi08DMduRmNMwacQbRA0+r9E Nxsg== 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:dkim-signature; bh=WSIXDWoWhUX8n7imNCPH8e48agYhT4xUKD1pQ6vTWU8=; b=tvM+BKr7BQVYr1KkDOI4Z0UW2b/0KNjViO6otq4GUomoVYRYYqJfZqW08qrWy7xG84 wvyGYikmfBMngtYBcSR7XRZJ+TKffv2w2bsVrvDx91ONRQW7pGjr8OsiojE4JiEkvPLf IF42W7cXDx9Adct4H1tKCHncD0V88Xbq5mGwg2ccRzV7nzEOA/AhY8WdHCl78RnZJDZw dCA1sb0QzcxNYJHQUAUq+vpDa727kLMpWTg1S7RQsWyQCO+3eT5ZalsjBJNeYvkg6KOf IP/jr9E1jBhqjYOPxUI73Gv3KB3qJaIa2AwksuVsGgnmo/HIrQ8E+UILL6xmBLmpCO4F HiKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=ljjOYQwa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r12-20020a05600c424c00b0038ff7f48189si3579295wmm.105.2022.05.13.18.31.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 18:31:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=ljjOYQwa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 852963FB6DA; Fri, 13 May 2022 16:59:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242980AbiELMvR (ORCPT + 99 others); Thu, 12 May 2022 08:51:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352089AbiELMvM (ORCPT ); Thu, 12 May 2022 08:51:12 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 049EE3ED3D; Thu, 12 May 2022 05:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WSIXDWoWhUX8n7imNCPH8e48agYhT4xUKD1pQ6vTWU8=; b=ljjOYQwaLTm69ZjncJWJrVQt4d 7rlw+tAxAfv5KDuhx+0zhSl8IqqRc2cF9pfZsCeiIX8SD5URBmD70dRoiP3LKsaU+6pW1VlnuOFlV 8BrL/LjySLhAL9pDJSj+wWhXuf3Dn8zyue0WgMJ3Yms4/uwSLaNfFMuAN4vrkmUncr7pGOhx1/y8r tNt9lW1eC1OTvZczWe4SDuo5fesUmiaM86fLMKydghZgbWmMfDMhsdzt1nD5eqf/bBfCqOk9whbgz 9n7Wp3dLrleWRnSZtSC24PwHFKwDl9Av0a9iZ2uivd16nJL9POPr0Ndmtnlo/D6tVgNCfDy4xJGEw qpNxtRlw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1np8HY-006OiR-0D; Thu, 12 May 2022 12:51:04 +0000 Date: Thu, 12 May 2022 13:51:03 +0100 From: Matthew Wilcox To: Ryusuke Konishi Cc: Andrew Morton , Stephen Rothwell , Linux Kernel Mailing List , Linux Next Mailing List , Yang Li Subject: Re: linux-next: manual merge of the mm tree with the folio tree Message-ID: References: <20220512182650.7d1a94c7@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2022 at 08:52:17PM +0900, Ryusuke Konishi wrote: > On Thu, May 12, 2022 at 5:26 PM Stephen Rothwell wrote: > > > > Hi all, > > > > Today's linux-next merge of the mm tree got a conflict in: > > > > fs/nilfs2/inode.c > > > > between commit: > > > > f132ab7d3ab0 ("fs: Convert mpage_readpage to mpage_read_folio") > > > > from the folio tree and commit: > > > > e38ed506c42f ("nilfs2: Fix some kernel-doc comments") > > > > from the mm tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > Thanks, Stephen. > > Andrew, please once drop > > e38ed506c42f ("nilfs2: Fix some kernel-doc comments") > > from -mm tree. I will resend a modified patch after the folio patch is merged > to the mainline. I'd be happy to take this patch through my tree instead, if you point me to where I can pick it up (I don't see it on fsdevel or mm). Although I do think we need to consider whether implementations of fs entry points (aops, fops, iops, etc) should have documentation in the individual filesystems. I understand why individual filesystem authors want that, but it would be better if we had really good central documentation of VFS/FS requirements (and honestly Documentation/filesystems/{locking.rst,vfs.rst} aren't bad) instead of reiterating them in each individual filesystem.