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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Stephen Rothwell <sfr@canb.auug.org.au>
CC:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Neil Brown <neilb@suse.de>
Subject: Re: linux-next: manual merge of the nfsd tree with the cel-fixes tree
Thread-Topic: linux-next: manual merge of the nfsd tree with the cel-fixes
 tree
Thread-Index: AQHYxwdWTUb6RimhjkSTD3F9xU+W363cl2CA
Date:   Tue, 13 Sep 2022 01:47:01 +0000
Message-ID: <2D1DCBBA-FC98-49D7-82CE-9CDA31BB72B6@oracle.com>
References: <20220913102507.3295ce32@canb.auug.org.au>
In-Reply-To: <20220913102507.3295ce32@canb.auug.org.au>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?oBAPN/Vz3oz538mYTnZWBJwJemxFBROm4f3O4RChvwrxnu+DiVk5onfda3fj?=
 =?us-ascii?Q?ngEpfmV6uI53pYygLQT63UROZl0ud6iFnU+8V7tRg07ZMCed0gyaZn8C7q1x?=
 =?us-ascii?Q?tnTlPyypLilDbbYFOqLv6GDbiOaimBR3VLPuRb5a0pDmMCXeTvXhlslvMv8B?=
 =?us-ascii?Q?fP4mgMwCLen0/W2ZNyIufrWEdw0/AW2fWrkf3MfSvLDxt0kTQCMNEJBi15cz?=
 =?us-ascii?Q?d+yWfqS1izvb2tvddSX4NZVJ82OxXpg+4Mlt+XBa1SQc/Y0DBQNfd7g6R+N6?=
 =?us-ascii?Q?bbIuwcwqRDOFk7NYK/hoAKCtG0Ekh+GlsPO1aEiNCby5D7m/Ig3MrBYDL2uY?=
 =?us-ascii?Q?LwAvM0FvQmRaecCvM3/kKOxTmhwLRADjj0qQZ+iT+VEgMPquiKlAGj69Qeyo?=
 =?us-ascii?Q?/gUIVqg6p9maeZxfGRsOhLnOO42dV1QaybNmhwP5o5tp0wsCZ4EGZlz26wPH?=
 =?us-ascii?Q?obo/iimhr/D11zNBXbgvmlQLrYvZ8ZQSrwyvnkBbiFL+wEXZRD3V/KK32zkh?=
 =?us-ascii?Q?ohoC1/FDZHQaUvK0p3iaQS/bI8IpqyT/hAHKjcc19gVTRpI+7GDRYIlxevFd?=
 =?us-ascii?Q?KIjMMHKqhJWtC3v07GcZc1YudPbz3fFQ4MfF7EUjWcJigcttsgilrelYUOiM?=
 =?us-ascii?Q?tiG7y/z/rx3FkVeXdozIR25rvFN4DDheIc/ODWMokrtIb5KqYe2aJ/8aZK8g?=
 =?us-ascii?Q?NS1QwAd4PDaM3HDS/4Ie2GEE/dj6rjswpNRM1+Adg3HdCT5lKP8OBR6z1Tcn?=
 =?us-ascii?Q?xLdOfoOKrW3TIcvUHvRvo1ushzKlAKSjfCpn2FoeJ3qVwBIvxINC9gXxg8r2?=
 =?us-ascii?Q?qarj+rc1v/iP9jyJl04jRQl101UmbGJuDRTAaew/7dskVCAz7d26n9ZemyEO?=
 =?us-ascii?Q?mbfTpoRSz/b76+V0tJYpSnQKo69EpFCLzmhqSbGIZW2r/Rg2Lk9yeQywOZZ6?=
 =?us-ascii?Q?99nv5Mi7CjR+Z8luZOJLc9FNjKLQ4gx8RdBg0oPnzadimgbBLy3bOLozrM8l?=
 =?us-ascii?Q?nkrxbMa1EmW7EsGJg9m/ZewyR9zeTJ/DAlD9gDtiR0R1hcu+o5IUD5D+WihR?=
 =?us-ascii?Q?13CVcJFu1g37xgin1TMEm1hhepdm4J1S9ALrXtMRpTNq4CAv53VMiAxiKDHt?=
 =?us-ascii?Q?qJKOdelwz/F3rUJrQdaZMzV11/1lmNmer3uXrv0GDf6htunJrz7xgVTBRytq?=
 =?us-ascii?Q?G10Lq0E9VxA2fd5N2YHtuLJg3acbgrOS643CcacCkSLAZcPurELDiZSyrzZK?=
 =?us-ascii?Q?TJIiNS3xQFWgzu5kyp8vBXNwFvdaSNpFzAK/1N4bqKZEgOe6mWsrINhpzJ2T?=
 =?us-ascii?Q?0yvEYYt+BQZeyKYKhgYLQM56pXur/GhQubmt3gvCvXbM9pWfStlm3adYMkDc?=
 =?us-ascii?Q?4y2vayoqAp76VX47cseg0fkCPr5EZytxv8O9IP5u2dQRR+U7l6r80JWF59Y1?=
 =?us-ascii?Q?LOrVMP/avLiCHUV6Nf42x8RioGpeloJzcTwNw3RcQmapVjhsc6xafyf6HGDg?=
 =?us-ascii?Q?Lb9MAOMNr9jc+XqRiFOASlao7/iNvdfxU+3jSKJ3bIA98/XxMF50HsfG/+oN?=
 =?us-ascii?Q?9bgLiC63jPfQYs5lAu64NZcWoXlkzaR/Dsp9IW/QAZ3uwm2n01Tx2g33MiGd?=
 =?us-ascii?Q?rQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CEC33AB63005C64887A891A465A3CB28@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b9ae890-d8ce-4cdf-cb3c-08da9529da7e
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2022 01:47:01.7818
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IcUapjR8Q3xWoPu6FZDMhMX3Y3bG1knWPjo67TZ1eEQMTu3pUEvTE8+Fbetk46pms+UNf+JRrG32No85ul9cLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4565
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-12_16,2022-09-12_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 spamscore=0
 suspectscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000
 definitions=main-2209130006
X-Proofpoint-ORIG-GUID: 59u-RJZWMxlDt_ZH8cAT2Ji1sAGGS85d
X-Proofpoint-GUID: 59u-RJZWMxlDt_ZH8cAT2Ji1sAGGS85d
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        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

Hi Stephen-

> On Sep 12, 2022, at 5:25 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrot=
e:
>=20
> Hi all,
>=20
> Today's linux-next merge of the nfsd tree got a conflict in:
>=20
>  fs/nfsd/vfs.c
>=20
> between commit:
>=20
>  00801cd92d91 ("NFSD: fix regression with setting ACLs.")
>=20
> from the cel-fixes tree and commit:
>=20
>  e9de96c3df55 ("NFSD: Refactor nfsd_setattr()")
>=20
> from the nfsd tree.
>=20
> I fixed it up (I think - 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.

Apologies, I didn't realize this state of affairs would create a
merge conflict in linux-next.

nfsd's for-next is currently based on v6.0-rc5, which does not have
00801cd92d91 ("NFSD: fix regression with setting ACLs.") yet. Next
week I will rebase nfsd's for-next on v6.0-rc6, which should resolve
this conflict. I will test the conflict resolution with the usual suite
of NFSD check-in tests before pushing that update to for-next.


> --=20
> Cheers,
> Stephen Rothwell
>=20
> diff --cc fs/nfsd/vfs.c
> index 19f28c33e44d,8eda499de545..000000000000
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@@ -343,6 -339,44 +343,48 @@@ nfsd_get_write_access(struct svc_rqst *
>  	return nfserrno(get_write_access(inode));
>  }
>=20
> + static int __nfsd_setattr(struct dentry *dentry, struct iattr *iap)
> + {
> + 	int host_err;
> +=20
> + 	if (iap->ia_valid & ATTR_SIZE) {
> + 		/*
> + 		 * RFC5661, Section 18.30.4:
> + 		 *   Changing the size of a file with SETATTR indirectly
> + 		 *   changes the time_modify and change attributes.
> + 		 *
> + 		 * (and similar for the older RFCs)
> + 		 */
> + 		struct iattr size_attr =3D {
> + 			.ia_valid	=3D ATTR_SIZE | ATTR_CTIME | ATTR_MTIME,
> + 			.ia_size	=3D iap->ia_size,
> + 		};
> +=20
> + 		if (iap->ia_size < 0)
> + 			return -EFBIG;
> +=20
> + 		host_err =3D notify_change(&init_user_ns, dentry, &size_attr, NULL);
> + 		if (host_err)
> + 			return host_err;
> + 		iap->ia_valid &=3D ~ATTR_SIZE;
> +=20
> + 		/*
> + 		 * Avoid the additional setattr call below if the only other
> + 		 * attribute that the client sends is the mtime, as we update
> + 		 * it as part of the size change above.
> + 		 */
> + 		if ((iap->ia_valid & ~ATTR_MTIME) =3D=3D 0)
> + 			return 0;
> + 	}
> +=20
> -	iap->ia_valid |=3D ATTR_CTIME;
> -	return notify_change(&init_user_ns, dentry, iap, NULL);
> ++	if (iap->ia_valid) {
> ++		iap->ia_valid |=3D ATTR_CTIME;
> ++		return notify_change(&init_user_ns, dentry, iap, NULL);
> ++	}
> ++
> ++	return 0;
> + }
> +=20
>  /*
>   * Set various file attributes.  After this call fhp needs an fh_put.
>   */
> @@@ -357,9 -391,10 +399,10 @@@ nfsd_setattr(struct svc_rqst *rqstp, st
>  	int		accmode =3D NFSD_MAY_SATTR;
>  	umode_t		ftype =3D 0;
>  	__be32		err;
> -	int		host_err;
> +	int		host_err =3D 0;
>  	bool		get_write_count;
>  	bool		size_change =3D (iap->ia_valid & ATTR_SIZE);
> + 	int		retries;
>=20
>  	if (iap->ia_valid & ATTR_SIZE) {
>  		accmode |=3D NFSD_MAY_WRITE|NFSD_MAY_OWNER_OVERRIDE;

--
Chuck Lever