Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp589912imc; Sun, 10 Mar 2019 15:11:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqwWBU1H84mIUthimhyoUBVFxXNrXfAIXlfvJ2ZAE0glixrV2ZPSDyDLSmPpa5gQja6kaRCp X-Received: by 2002:a62:1b92:: with SMTP id b140mr30495374pfb.159.1552255912119; Sun, 10 Mar 2019 15:11:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552255912; cv=none; d=google.com; s=arc-20160816; b=YTf3fT2HpgOiFP1SH6NeD52P+9692bI1ixZmnLA0bAINtg3qcN93MMBTLypWWXzkkj JsL9GdCZYRIzatPM3Y/DuTOy40Ph7EITwlb4A2WQsdZKpIQx/5UAnfBtpcVQFEFFiow2 AhbrZkKS1uxyviIS6x/kcmdShRPS/DWDiyfmDq8X7EJ/3c5+ptoG/RAeTt3no5VqRnEl oHBOv/QOlkhko4m298a6cGACTfgqoYZN3j123LFlMT+VeO6SZMr0+OHclfoqXDnFRhzV cN9EXCX559LcLijyLqcUqcPcj9U10LrLBJ7NYK2Sn20fzsY0x5sdwr+6QIG8oM5JTjmh Mt+Q== 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=I9sOUYjaMnhvlCMaKm/05hPLXvBPvj8UiQu0gCiBSrY=; b=mWXv0A2dGaeyUg1YqXqNzjXEjWIsZGfqGCm4ane/EBXCszgdjO6Z29QdK4lutaQ/4u 77FpDzmAEQ14lNgT+VwJfNWRz1yP/JrL0rIIUG+wDTKyczQStu2tXMRVW3Qs5DL8QOvq DP2GLXq+4CV6mKcloK9iftaSWR/NBo/hjlGcDBbq2UItvFFMILLQUXCLeSezE62hpwu6 nBpyVo0XH+ssa0y0Tp/xuK4xJC2rjWIoCK25tu4I5bb+WT37YghJln9x428t5IUBqpPL ylq2Vv1/G2D9Fc6lcIbSz6bYemqqDtWmgq0Y7epEo65p7lwAJLz4ndE2TWUvBiOjS+g0 xZ+w== 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 p6si3956819plo.4.2019.03.10.15.11.24; Sun, 10 Mar 2019 15:11:52 -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 S1726921AbfCJVyB (ORCPT + 99 others); Sun, 10 Mar 2019 17:54:01 -0400 Received: from ipmail03.adl2.internode.on.net ([150.101.137.141]:41959 "EHLO ipmail03.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726687AbfCJVyB (ORCPT ); Sun, 10 Mar 2019 17:54:01 -0400 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl2.internode.on.net with ESMTP; 11 Mar 2019 08:23:57 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1h36OJ-00074U-Nd; Mon, 11 Mar 2019 08:53:55 +1100 Date: Mon, 11 Mar 2019 08:53:55 +1100 From: Dave Chinner To: Sean Fu Cc: "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: Use kmem_zalloc for bp->b_pages. Message-ID: <20190310215355.GC23020@dastard> References: <20190309153636.14154-1-fxinrong@gmail.com> <20190309173230.GA4359@magnolia> <20190310050608.dtidrfuqepze6uoh@linux-xjtn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190310050608.dtidrfuqepze6uoh@linux-xjtn> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 10, 2019 at 01:07:32PM +0800, Sean Fu wrote: > On Sat, Mar 09, 2019 at 09:32:30AM -0800, Darrick J. Wong wrote: > > On Sat, Mar 09, 2019 at 11:36:36PM +0800, Sean Fu wrote: > > > Change the allocation of bp->b_pages to use kmem_zalloc instead of > > > kmem_alloc. > > > Remove unnecessary memset for bp->b_pages. > > > > > > This reduces text size by 42 bytes. > > > Before: > > > text data bss dec hex filename > > > 23335 588 8 23931 5d7b ./fs/xfs/xfs_buf.o > > > After: > > > text data bss dec hex filename > > > 23293 588 8 23889 5d51 ./fs/xfs/xfs_buf.o > > > > > > Signed-off-by: Sean Fu > > > --- > > > fs/xfs/xfs_buf.c | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c > > > index 4f5f2ff3f70f..be4f740b97c1 100644 > > > --- a/fs/xfs/xfs_buf.c > > > +++ b/fs/xfs/xfs_buf.c > > > @@ -289,12 +289,11 @@ _xfs_buf_get_pages( > > > if (page_count <= XB_PAGES) { > > > bp->b_pages = bp->b_page_array; > > > } else { > > > - bp->b_pages = kmem_alloc(sizeof(struct page *) * > > > + bp->b_pages = kmem_zalloc(sizeof(struct page *) * > > > page_count, KM_NOFS); > > > if (bp->b_pages == NULL) > > > return -ENOMEM; > > > } > > > - memset(bp->b_pages, 0, sizeof(struct page *) * page_count); > > > > Does this leave b_pages uninitialized in the page_count <= XB_PAGES > > case? > bp is allocated by kmem_zone_zalloc, But i will take a deep look at xfs_buf_associate_memory. We can (and do) reuse buffers with different memory buffers via xfs_buf_associate_memory() (e.g. see the split log buffer code in xlog_sync()]. I'd prefer that we leave the explicit memset here for this re-use case - leaving the page pointer array with stale page pointers (even though beyond b_page_count) means any page array overrun turns into a memory corruption (via access of a stale page) rather than a NULL pointer dereference and immediate fail. IMO, a small decrease in binary size is not worth changing the failure behaviour from a definite, immediate fail to a random memory corruption failure some time in the future... Cheers, Dave. -- Dave Chinner david@fromorbit.com