Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2165228ioo; Mon, 23 May 2022 11:38:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEmeY6fPA52Mz1tvJvJ4WX1hsQ9SuZYmLFJ3SLZB30lqErH/RG1z/dsr44clSJjVdvzmUv X-Received: by 2002:a17:90b:1642:b0:1e0:96b:c3f2 with SMTP id il2-20020a17090b164200b001e0096bc3f2mr348843pjb.228.1653331111442; Mon, 23 May 2022 11:38:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653331111; cv=none; d=google.com; s=arc-20160816; b=k4XDrwn8pUR/NDrHn3c5G7IRJQhi9pmM+NDQdOX99yO5OE528lp3zFH3HlnSNTUsqj gk+v56XMxpARNYLzPViiSWJT6oGJW8xRvpYcwC6eHo0zx1csQBCEkN6QUoANbevqLhYp /0OdGdpYVc2CWI6JnTv6KWt9D474Cyj3rNfkDKIx5ipEoSg7JEoZe579Iv4DIt72WpM6 dQ6Zwg9e5YK/m3Yj44hez2sILNDKgG2gccP5L6uaq1CGXcsRiq0xmrw311Zp2POvhWQd feH7WPwzR1uRFz/Dk12Qn2cCFI4JVNYre6bLp3DfklQeVh/kFdG6rtw88IhELZqcIAy4 veOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=XHN2onIDV3MVbi3EOUeEmk3CwytP5dSFbX9YBoil65s=; b=DTKmnreJDLg4IfpaM/0Ifv3nov0x4fts4eYNz3wejW1DS6CQe6SrJnNl/wIsM/Q1Kw EL5+CHAufV30HZw+D/kEgGpAmd6/NxNqjEhT34iPBid0TozxoowPAtMN8at034RVqBTW 3v19sELpgS9xsfJhE5meUM+wnrZGH+BiKlZW9LwyIqcLrish2/28nQURCkuGOGd3Yhhr 3j8OT38UD7IzYTgxGZ37OKayv7clhwIoDSI/iPFAWYF+JwW3TKlLsuHraloaQ+XLx4kE yY168XsoLE3Uqq72U0XUDZZfcvFGgZuLorsA19fSX8x6u6N52vZa9+u9TF0q0ilAXDTE riHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=QzOh9WbY; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n8-20020a170902d2c800b0015cdd65c1easi12426694plc.565.2022.05.23.11.38.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 11:38:31 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=QzOh9WbY; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5A459C3D1A; Mon, 23 May 2022 11:37:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241102AbiEWShh (ORCPT + 99 others); Mon, 23 May 2022 14:37:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241100AbiEWShV (ORCPT ); Mon, 23 May 2022 14:37:21 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DB5C132A1B; Mon, 23 May 2022 11:17:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9E4CFB81200; Mon, 23 May 2022 18:15:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 548A0C3411F; Mon, 23 May 2022 18:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653329741; bh=ogr4VAdQS3A7DDk0vo1e70sbPah4iSytiHNoT4xX2UI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QzOh9WbYbDO5tPJqGabgX1gZbWAPOnCpvIze6LeXOPoIqyxihEG3x67zLTOAxWtSd Gm01Gohdz0WEtjQkcrafyhSBwKODgM96cXE8HJ+KMgIuLLdJbadj9oabuO0AG22mA8 jvDFOT9eJmgPlm1Db7ktaM9V2rxr7PHzgy1Ae0k2Il6W6rmp4oMvNcihWsFOpboCjn hagn7SEeNTwTiDVG6gPCXYe9DjaN9BlZm6LOd+gpq7qPBJe7CDgzECF8wcx7XOPxeP lX2GZNxpVwzKKT16ODDgFFGcEebCOJJPOSJ+Iz3FwoP85fS+CWCgfTdpj9Ymko2Lqr +7xz1BGdIVSGQ== Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-2f83983782fso157464317b3.6; Mon, 23 May 2022 11:15:41 -0700 (PDT) X-Gm-Message-State: AOAM5332aiS1jd/9uk+HERSHwQz0K+IBCjvdK88Z+u58k4aPE/aRaUUJ vGKTtngk2/Rm5fmk2TJFOX8vXK3vJ52SBTyfm7k= X-Received: by 2002:a81:5a87:0:b0:2ec:239:d1e with SMTP id o129-20020a815a87000000b002ec02390d1emr24470794ywb.211.1653329740302; Mon, 23 May 2022 11:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20220519191311.17119-1-logang@deltatee.com> <20220519191311.17119-13-logang@deltatee.com> <62b09487-9223-db3d-2165-789a51230060@molgen.mpg.de> In-Reply-To: From: Song Liu Date: Mon, 23 May 2022 11:15:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 12/15] md/raid5-cache: Add RCU protection to conf->log accesses To: Donald Buczek Cc: Logan Gunthorpe , open list , linux-raid , Christoph Hellwig , Guoqing Jiang , Xiao Ni , Stephen Bates , Martin Oliveira , David Sloan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Sun, May 22, 2022 at 11:47 PM Song Liu wrote: > > On Sun, May 22, 2022 at 12:32 AM Donald Buczek wro= te: > > > > On 19.05.22 21:13, Logan Gunthorpe wrote: > > > The mdadm test 21raid5cache randomly fails with NULL pointer accesses > > > conf->log when run repeatedly. conf->log was sort of protected with > > > a RCU, but most dereferences were not done with the correct functions= . > > > > > > Add rcu_read_locks() and rcu_access_pointers() to the appropriate > > > places. > > > > > > Signed-off-by: Logan Gunthorpe > > [...] > > > > diff --git a/drivers/md/raid5-log.h b/drivers/md/raid5-log.h > > > index f26e6f4c7f9a..24b4dbd5b25c 100644 > > > --- a/drivers/md/raid5-log.h > > > +++ b/drivers/md/raid5-log.h > > > @@ -58,7 +58,7 @@ static inline int log_stripe(struct stripe_head *sh= , struct stripe_head_state *s > > > { > > > struct r5conf *conf =3D sh->raid_conf; > > > > > > - if (conf->log) { > > > + if (rcu_access_pointer(conf->log)) { > > > > > > A problem here is that `struct r5l_log` of `conf->log` is private to ra= id5-cache.c and gcc below version 10 (wrongly) regards the `typeof(*p) *loc= al` declaration of __rcu_access_pointer as a dereference: > > > > CC drivers/md/raid5.o > > > > In file included from ./include/linux/rculist.h:11:0, > > > > from ./include/linux/dcache.h:8, > > > > from ./include/linux/fs.h:8, > > > > from ./include/linux/highmem.h:5, > > > > from ./include/linux/bvec.h:10, > > > > from ./include/linux/blk_types.h:10, > > > > from ./include/linux/blkdev.h:9, > > > > from drivers/md/raid5.c:38: > > > > drivers/md/raid5-log.h: In function =E2=80=98log_stripe=E2=80=99: > > > > ./include/linux/rcupdate.h:384:9: error: dereferencing pointer to incom= plete type =E2=80=98struct r5l_log=E2=80=99 > > > > typeof(*p) *local =3D (typeof(*p) *__force)READ_ONCE(p); \ > > > > ^ > > > > ./include/linux/rcupdate.h:495:31: note: in expansion of macro =E2=80= =98__rcu_access_pointer=E2=80=99 > > > > #define rcu_access_pointer(p) __rcu_access_pointer((p), __UNIQUE_ID(r= cu), __rcu) > > > > ^~~~~~~~~~~~~~~~~~~~ > > > > drivers/md/raid5-log.h:61:6: note: in expansion of macro =E2=80=98rcu_a= ccess_pointer=E2=80=99 > > > > if (rcu_access_pointer(conf->log)) { > > > > ^~~~~~~~~~~~~~~~~~ > > > > make[2]: *** [scripts/Makefile.build:288: drivers/md/raid5.o] Error 1 > > > > make[1]: *** [scripts/Makefile.build:550: drivers/md] Error 2 > > > > make: *** [Makefile:1834: drivers] Error 2 > > This is annoying.. And there are a few other cases in raid5-log.h and > raid5.c. > > Maybe we should move the definition of r5l_log to raid5-log.h? Or we can use READ_ONCE(conf->log) for most cases. Thought? Song