Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp14969imm; Tue, 17 Jul 2018 19:35:58 -0700 (PDT) X-Google-Smtp-Source: AAOMgpccoCxipMPXxPDt9fn+CQwjpme6eqRnjvqu9TDAUpaTp5iOzUn4ManfafK/Yn4nLT9Gnxmj X-Received: by 2002:a63:ff21:: with SMTP id k33-v6mr3862590pgi.38.1531881358564; Tue, 17 Jul 2018 19:35:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531881358; cv=none; d=google.com; s=arc-20160816; b=XyPfFLwjfv2+LvtgeIEEm27b58VexFnQRQYNyRCpNm5BCFbFFVMrZS3GLK5hXL9lMS eUeen54kGcgJwiW0KOGbKMDy143+spOoZ8vhDv6vwq/UYNnvOh56clVS807lfAA2CTNA 1nisX1TKL/na0z56IyZOFjtIyetFxK5usOSjYQSyMMJ6horppgnUvg4uu9gd2Xjw1XZ5 FJOE0b+3+qYvKhtt28r/Vq3GkfVcDzgELTuaxbbwqeTkIq0ov2QGg3hHK0c9n8YHOAU/ xBgTaKlSo22yakjnVo11Bmld7iR+LZiJ8krr5ViYYA/7T6AHB6OM8hbrm+utJ7rQchcv h1fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=yG4dCqA+kq14xKV0qGpA2BT21IaqHkXU1gE9vW6Ft3k=; b=uQOk2pFrR+bnD3nz7Vi2EZAMlQF9roSy3bGErflC2AlDT6M/xYbRI7ieVU/Xdv9wlr 9D0BAS8tq8/fddGKqHz97P5yKH1DaIvx0l6+nQmkc7BZ7EjqyfR/eYerTvxEVJzEWXD3 ICG5mu980HJVq8o91gimZ2ALn3nJlhwFvpIYigCJ0D2EdMGei4IUkBhXQnh+jw+TL6j2 dovNxaUX9FHm9iIuLg3i6OdDbbEJrNlpiiD7lcmc+Z/SlVzBYKN+NWjlPxcPRQOEhbO4 kLbas5gGA6nJRcJbD4ktoj8+NpFc5/3Zoa6gSZvnpiJAN0n68EYUURpyF7MairtsYSz/ b+hQ== 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 h1-v6si2242320pll.416.2018.07.17.19.35.41; Tue, 17 Jul 2018 19:35:58 -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 S1731643AbeGRDKj (ORCPT + 99 others); Tue, 17 Jul 2018 23:10:39 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43962 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730614AbeGRDKj (ORCPT ); Tue, 17 Jul 2018 23:10:39 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id E6F08BDB; Wed, 18 Jul 2018 02:35:05 +0000 (UTC) Date: Tue, 17 Jul 2018 19:35:04 -0700 From: Andrew Morton To: Omar Sandoval Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Alexey Dobriyan , Eric Biederman , James Morse , Bhupesh Sharma , kernel-team@fb.com Subject: Re: [PATCH v2 1/7] proc/kcore: don't grab lock for kclist_add() Message-Id: <20180717193504.1d76fb1a43d0c8687d969143@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote: > From: Omar Sandoval > > kclist_add() is only called at init time, so there's no point in > grabbing any locks. We're also going to replace the rwlock with a rwsem, > which we don't want to try grabbing during early boot. > > ... > > --- a/fs/proc/kcore.c > +++ b/fs/proc/kcore.c > @@ -62,6 +62,7 @@ static LIST_HEAD(kclist_head); > static DEFINE_RWLOCK(kclist_lock); > static int kcore_need_update = 1; > > +/* This doesn't grab kclist_lock, so it should only be used at init time. */ > void > kclist_add(struct kcore_list *new, void *addr, size_t size, int type) > { > @@ -69,9 +70,7 @@ kclist_add(struct kcore_list *new, void *addr, size_t size, int type) > new->size = size; > new->type = type; > > - write_lock(&kclist_lock); > list_add_tail(&new->list, &kclist_head); > - write_unlock(&kclist_lock); > } So we can mark kclist_add() as __init, yes? That way we save a scrap of ram and if someone starts calling kclist_add() from non-__init code we get a build-time warning. --- a/fs/proc/kcore.c~proc-kcore-dont-grab-lock-for-kclist_add-fix +++ a/fs/proc/kcore.c @@ -63,7 +63,7 @@ static DEFINE_RWLOCK(kclist_lock); static int kcore_need_update = 1; /* This doesn't grab kclist_lock, so it should only be used at init time. */ -void +void __init kclist_add(struct kcore_list *new, void *addr, size_t size, int type) { new->addr = (unsigned long)addr; --- a/include/linux/kcore.h~proc-kcore-dont-grab-lock-for-kclist_add-fix +++ a/include/linux/kcore.h @@ -35,7 +35,7 @@ struct vmcoredd_node { }; #ifdef CONFIG_PROC_KCORE -extern void kclist_add(struct kcore_list *, void *, size_t, int type); +extern void __init kclist_add(struct kcore_list *, void *, size_t, int type); #else static inline void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)