Received-SPF: pass (google.com: domain of linux-nfs-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:     Jeff Layton <jlayton@kernel.org>
CC:     Neil Brown <neilb@suse.de>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v3 3/4] nfsd: close race between unhashing and LRU
 addition
Thread-Topic: [PATCH v3 3/4] nfsd: close race between unhashing and LRU
 addition
Thread-Index: AQHY6v8bPfwg35VNl0uAHle+vjwISq4kNwiAgANEvICAAFV8AIAAejiAgAA0CAA=
Date:   Mon, 31 Oct 2022 13:14:47 +0000
Message-ID: <202AD086-4F1F-41D6-ABDC-BA6C91DA5BBF@oracle.com>
References: <20221028185712.79863-1-jlayton@kernel.org>
 <20221028185712.79863-4-jlayton@kernel.org>
 <08778EE0-CBDC-467B-ACA6-9D8E6719E1BB@oracle.com>
 <166716630911.13915.14442550645061536898@noble.neil.brown.name>
 <1737B8C1-5B93-4887-A673-F9AFA6ED32C0@oracle.com>
 <fb57d2cb6769dbc123e15e76ec2c23b1fa9f32be.camel@kernel.org>
In-Reply-To: <fb57d2cb6769dbc123e15e76ec2c23b1fa9f32be.camel@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9vxWqJy8EuwOLjPMWOx7qJgt1vLYD9UDALcZ2utR0Z0vHscA72nTS5l32oiz?=
 =?us-ascii?Q?jvtWwEkLRvtj3nuHRw08ntuqNRuraiXd/ca5nsfa2GmjguRI2PB2E1z3IePx?=
 =?us-ascii?Q?d8MHEs0I3/N85kCPZgoLWekeD9MOonsium6Eq1ueQk+EFh6a3HXXrqgUjqdZ?=
 =?us-ascii?Q?gNwXGdJ5xfZF/IhKpYygxZQcIB9T3aD5WLTcWSeEQHpQXuTIN3n0O/o6yf+d?=
 =?us-ascii?Q?xDlzyRZwqJWvY14cD11EE+ZouUijOZkTcOJeUQslQJk+IHZVAE7mR7/r8y+m?=
 =?us-ascii?Q?cOxD9WP8+b6Kal+u65SQbqW6A9goOLtVVF5/YcOCuT33p9ujUPeD29r/fYtI?=
 =?us-ascii?Q?UfbCnlpGkE5w4B7macM+sMZXHYuATL+hk75gDjZRl06iBanvZIRay+eeSCOQ?=
 =?us-ascii?Q?rC3VX0960+782z+c0yTit6pT60KX5KwduQJQNuWcXY9Rt9sRbGW3WC9EfpDY?=
 =?us-ascii?Q?n8zvjuN1pc8pJBKaK50II1NgsljJV+ADUMWFLSS5CaZ69uo7uM8Dj35DND/D?=
 =?us-ascii?Q?VlEt7ghR8Lf1kZMuQod/p/8EG9K53dbk39NCRZr0slWnr7/CKyw6nHxgV4Vr?=
 =?us-ascii?Q?9tMtfFsUaMvTisQS2xYjiZqAffZbNJGm7U/HJXCldrAPurEquJ2oD7N+S55c?=
 =?us-ascii?Q?QfYeEJvRaGTqrQEA49XeAnrqoCGrqH9RzpLQ02AJsnRfIXHGQiJTRoEhDyvB?=
 =?us-ascii?Q?MhnTeUfqy+mabxcnIUMuK94ytnbdF63yQUVs4XCvnZDR+5pYYwyOPXEPh/B3?=
 =?us-ascii?Q?NTGLBdwNgCeuEKtRK1gEGg7jhq4iHwi1Ommk3q4qCkcm2sGhEBcjtq2P64H4?=
 =?us-ascii?Q?pE6OcAFtuCP/oU868bLb50uvRd7G/jvT4Q35ySRbz8vh0ouJ4f/9H+xWgphF?=
 =?us-ascii?Q?b8AzLf1tr6jxxK/jsiUI2wbkhGKvCsOrYM3BfenBvctVSTgSllaTo3RcAdBx?=
 =?us-ascii?Q?jgmwUeYFC+5aQbHA6+wBrlx7oQw7nsdBgyHWxKh+e8NPnK7y5phO0O+9fVwj?=
 =?us-ascii?Q?57vlaK9M5HIY0RV9Z6cHpgyVb1Eog0ylTtB0ktit30aFOZrs7ykF+Tgmi2GS?=
 =?us-ascii?Q?yYaUjggEPkcQ1XGQYjPDOxm58eXCiL7Uu+IjxLVWJvPeloQSnpshSo2FAehs?=
 =?us-ascii?Q?TKzR/2lfDkSr2VO/+/IR2Q8YFTvxGDWDQ5PvxNFmYjUd+fiqQ3oD4gUgCVU2?=
 =?us-ascii?Q?WsV1Ho2A2bWWLld+rabXI2UPYRf/xNBrG9hqd92B2GZ9OIBDyiqRMH7WUysg?=
 =?us-ascii?Q?7p7NgHWEIRTFy7Hal9z8WaSTz7RQHg64aDDqRMmFDw6tFtl046MZwWazNJJL?=
 =?us-ascii?Q?/WH+Mp2hUqNz9LNCDsxz0sZSL2nWEJDaFrKZ00wyx72+aeiI1pvmGAmzRjU5?=
 =?us-ascii?Q?+La8mD/OzpzLk1aUqrFu8iQE57VlC70qfmOgQxVTeDf6dcyT+blvc1RcKaKX?=
 =?us-ascii?Q?+7CWdQVqL1L0n1O6+a+OOcZubw5uTBoVHr+x/HL+uzRMag1con5CkMo/zbSu?=
 =?us-ascii?Q?Ehegqqq6tNf8mhj3Y7WjsH0dSFV/Wr88TIfM1dUr4Bdym6o4xXVsxb8l5Jiv?=
 =?us-ascii?Q?e76qvYyEHYCqoD335d8ptbYjf4mCXJp0E/+P03fCkJq4ryMH9h09oHOmPpce?=
 =?us-ascii?Q?QA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B5257F269C9F8145B55BBD4403509B65@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: 6c805572-5daa-47d1-54be-08dabb41e263
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2022 13:14:47.1462
 (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: oGVF/DvnA94nt8y7ZTozCcBWsvzWOc4vpYjAbu8wRP8F9YFDzI8bcjsnyGAm4QFABXWnAd+mzlj2nH6LSwrQnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB5734
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-31_15,2022-10-31_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=988 mlxscore=0
 suspectscore=0 malwarescore=0 spamscore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2210310084
X-Proofpoint-GUID: 46gHBwbEleixM4VwNisce5a2CPIXkEcN
X-Proofpoint-ORIG-GUID: 46gHBwbEleixM4VwNisce5a2CPIXkEcN
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 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-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Oct 31, 2022, at 6:08 AM, Jeff Layton <jlayton@kernel.org> wrote:
>=20
> On Mon, 2022-10-31 at 02:51 +0000, Chuck Lever III wrote:
>>=20
>>> On Oct 30, 2022, at 5:45 PM, NeilBrown <neilb@suse.de> wrote:
>>>=20
>>> On Sat, 29 Oct 2022, Chuck Lever III wrote:
>>>>=20
>>>>> On Oct 28, 2022, at 2:57 PM, Jeff Layton <jlayton@kernel.org> wrote:
>>>>>=20
>>>>> The list_lru_add and list_lru_del functions use list_empty checks to =
see
>>>>> whether the object is already on the LRU. That's fine in most cases, =
but
>>>>> we occasionally repurpose nf_lru after unhashing. It's possible for a=
n
>>>>> LRU removal to remove it from a different list altogether if we lose =
a
>>>>> race.
>>=20
>> Can that issue be resolved by simply adding a "struct list_head nf_dispo=
se"
>> field? That might be more straightforward than adding conditional logic.
>>=20
>=20
> Yes, though that would take more memory.

Not really. pahole says struct nfsd_file is currently 40 bytes short
of two cache lines. So adding a list_head field should not push the
size of nfsd_file to the point where kmalloc would have to allocate
more memory per object.

I'm wondering if a separate list_head field would help simplify
nfsd_file_put() ?


--
Chuck Lever