Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4596572ybi; Sat, 20 Jul 2019 02:18:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqw8dbTBKtbfGuRZWqI3PBnmh/4EdFYJ3BTobE+X2BZSdXkSgGTAg2siFjNvqeM6PrdpJ3YN X-Received: by 2002:a63:c203:: with SMTP id b3mr59768044pgd.450.1563614287337; Sat, 20 Jul 2019 02:18:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563614287; cv=none; d=google.com; s=arc-20160816; b=rGQsNCoBcM++mf/UTU4pJ3ttpa4F1x0k31+QvQk1MxRDiXKXgWzzup5qu0ZyuhW6nl lvn6+SHmnp268ekh+iWkjPCbXaVcpFbcf4+u1yDGtbe1mVP+XYX6fm2rKaYqF7ZLB4eR IS64pYlcyah7CC7gqOfvEiVXnoKMiHAsTCsAFWAlVEGd0LZh1L6/jOYtvEDwifW1O4d7 0a5qGSC+WMk2Dz3/gJetXtMTwN/acg1HvwizwQLE+Q/kJEez2brTVrB+jqiACHP5VSDZ pvmiDpp/nlohI3FX2IkCfcKx8vQA9waqARrUCVl0N2AWnt8OotMRYKANZoNfE/J/UyyL J2nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jH/M+jApZFTQUBQs4B9uZ2RBFZMlEIdyAHV8C1gNwOg=; b=LZ4FhZmkbtq1eY5lNDr5VSLCMD4/RKtNmxygdtzZVHa9nIi308i9WYGlb47fL2ofOX KEV7by/cG/mM97YQyFyvi3Q00ASwEaPwFpy7xDvspGMoUuZXll1ybdQXoxJFJZt7H6C3 ePYshM2JcsfaZ3WaetyQG6ELYRatlymKeyRMgMFLD3XJSycDSFK+ZGdipAUb45k+ehDK mUIPcdTum/q7icqXkq4JEwPToxcCD5FeUQJlsYLMf5SCWaiPeuRWiwlhH31fQbx8yzV9 4Px5jnxZA0RrE4ctg70HwgomZnReHvfo3wKUmZ7bj/gL6DEwAzyaO1tNMaStGJGF6FDk pf3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 12si8371201pgu.469.2019.07.20.02.17.51; Sat, 20 Jul 2019 02:18:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731620AbfGSWdX (ORCPT + 99 others); Fri, 19 Jul 2019 18:33:23 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:49863 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727344AbfGSWdX (ORCPT ); Fri, 19 Jul 2019 18:33:23 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id CCCF08032D; Sat, 20 Jul 2019 00:33:08 +0200 (CEST) Date: Sat, 20 Jul 2019 00:33:19 +0200 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, David Howells , Sasha Levin Subject: Re: [PATCH 4.19 13/47] afs: Fix uninitialised spinlock afs_volume::cb_break_lock Message-ID: <20190719223319.GA32199@amd> References: <20190718030045.780672747@linuxfoundation.org> <20190718030049.759890872@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20190718030049.759890872@linuxfoundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Without this, the following trace may be observed when a volume-break > callback is received: >=20 > INFO: trying to register non-static key. > the code is fine but needs lockdep annotation. I'm sure this fixes the warning... > diff --git a/fs/afs/callback.c b/fs/afs/callback.c > index 5f261fbf2182..4ad701250299 100644 > --- a/fs/afs/callback.c > +++ b/fs/afs/callback.c > @@ -276,9 +276,9 @@ static void afs_break_one_callback(struct afs_server = *server, > struct afs_super_info *as =3D AFS_FS_S(cbi->sb); > struct afs_volume *volume =3D as->volume; > =20 > - write_lock(&volume->cb_break_lock); > + write_lock(&volume->cb_v_break_lock); > volume->cb_v_break++; > - write_unlock(&volume->cb_break_lock); > + write_unlock(&volume->cb_v_break_lock); > } else { > data.volume =3D NULL; > data.fid =3D *fid; But this is the only use of the lock. Which is strange: we have read/write lock, but we only use the write side. Readers don't take the lock, so it does not offer any protection for them. Is that correct? Does this need to be rwlock, or would plain spinlock be enough? atomic_t? (Problem exists in the mainline, nothing stable specific here). Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl0yRS8ACgkQMOfwapXb+vI1ZwCeLs/jEeAzqUrYgS0zSusJliCY MrkAn2aVDKgfaTmyBERlnzdpcQOHnOGL =bvsH -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--