Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4320286ybl; Mon, 26 Aug 2019 08:42:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+0ZyWcjewqwuao9jDlTTr/wKL8klEcIdPJiQh0WMUDOS9RkCREqfFm0H8iStPgjYprTWL X-Received: by 2002:a17:90a:c20f:: with SMTP id e15mr20262018pjt.123.1566834162104; Mon, 26 Aug 2019 08:42:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566834162; cv=none; d=google.com; s=arc-20160816; b=QDGWUQq40FcA2L2gE3zc+TPUkEHFFcMCGut0bEh5AXy6MFat1oBYI442Xs5pFagF3N C6/X59M1f1Oro2oPwj1jf4Fgr0Xn2WSFVFbasDfl8Z/fvMv0Ke4ehxzXD7RdyGkFz0lS rQ+7Qvhhc0XLt5TiI+z9utSm4yXzwU6Dn5v/NGC5aJ1OrufW7g37ciEPPOsitvibmlIY waXCU7POnr8OqBdjGuclIPsHk7FHA0tT3gHX/PKQydVx0IukKDSiRsJLolxiagpQhH7N 6B9bqfXlrzoDWpO/aQzCJPjGc/6cDenVK6QepZt5Udrxnqx8up1DQ5735ljIPRHHoZso 57VA== 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:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=MFjPgGzUvSQqiGdbnGkXbAu4aJ64lNPh39y/TUjaBRA=; b=RzN2u7VjEatob9u3YfWoByEWLOKVbP7e7b+ba2ZTHt/JMk1xH+sibuCczKP/Z1bvAz J+K2i/w5tDCoD+5kWI5P7SmtkI0bB7LfNqICtELjNg/XrSq2vFtp+yEsR11z8wjdvhN9 ahZQ5Lg5QkYtkVsdlEw1g0DaSO8Qdr2QUlpzvLz0qeZlSzm2fAoYpZJjag8sQ46Qs8O0 B1Qv2mbVDdknwwzLJpxyYRT1WiwE1iNoiRLptUUiIPc84qoH/oI8Vroxq33m8K0LA0e/ KjSWcfxAIV8WlZTthXwhN06oI2z2+SHk2KB0lhhkei5SQ7D1VzhSkhhh6WpgrtXbr+nm xHdw== 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 1si9908812pli.374.2019.08.26.08.42.27; Mon, 26 Aug 2019 08:42:42 -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 S1732436AbfHZPhh (ORCPT + 99 others); Mon, 26 Aug 2019 11:37:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:51520 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731833AbfHZPhg (ORCPT ); Mon, 26 Aug 2019 11:37:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6A496B0B6; Mon, 26 Aug 2019 15:37:34 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id B158EDA98E; Mon, 26 Aug 2019 17:37:57 +0200 (CEST) Date: Mon, 26 Aug 2019 17:37:57 +0200 From: David Sterba To: Christophe Leroy Cc: erhard_f@mailbox.org, Chris Mason , Josef Bacik , David Sterba , Andrew Morton , linux-mm@kvack.org, stable@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH v2] btrfs: fix allocation of bitmap pages. Message-ID: <20190826153757.GW2752@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Christophe Leroy , erhard_f@mailbox.org, Chris Mason , Josef Bacik , David Sterba , Andrew Morton , linux-mm@kvack.org, stable@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 21, 2019 at 03:05:55PM +0000, Christophe Leroy wrote: > Various notifications of type "BUG kmalloc-4096 () : Redzone > overwritten" have been observed recently in various parts of > the kernel. After some time, it has been made a relation with > the use of BTRFS filesystem. > > [ 22.809700] BUG kmalloc-4096 (Tainted: G W ): Redzone overwritten > [ 22.809971] ----------------------------------------------------------------------------- > > [ 22.810286] INFO: 0xbe1a5921-0xfbfc06cd. First byte 0x0 instead of 0xcc > [ 22.810866] INFO: Allocated in __load_free_space_cache+0x588/0x780 [btrfs] age=22 cpu=0 pid=224 > [ 22.811193] __slab_alloc.constprop.26+0x44/0x70 > [ 22.811345] kmem_cache_alloc_trace+0xf0/0x2ec > [ 22.811588] __load_free_space_cache+0x588/0x780 [btrfs] > [ 22.811848] load_free_space_cache+0xf4/0x1b0 [btrfs] > [ 22.812090] cache_block_group+0x1d0/0x3d0 [btrfs] > [ 22.812321] find_free_extent+0x680/0x12a4 [btrfs] > [ 22.812549] btrfs_reserve_extent+0xec/0x220 [btrfs] > [ 22.812785] btrfs_alloc_tree_block+0x178/0x5f4 [btrfs] > [ 22.813032] __btrfs_cow_block+0x150/0x5d4 [btrfs] > [ 22.813262] btrfs_cow_block+0x194/0x298 [btrfs] > [ 22.813484] commit_cowonly_roots+0x44/0x294 [btrfs] > [ 22.813718] btrfs_commit_transaction+0x63c/0xc0c [btrfs] > [ 22.813973] close_ctree+0xf8/0x2a4 [btrfs] > [ 22.814107] generic_shutdown_super+0x80/0x110 > [ 22.814250] kill_anon_super+0x18/0x30 > [ 22.814437] btrfs_kill_super+0x18/0x90 [btrfs] > [ 22.814590] INFO: Freed in proc_cgroup_show+0xc0/0x248 age=41 cpu=0 pid=83 > [ 22.814841] proc_cgroup_show+0xc0/0x248 > [ 22.814967] proc_single_show+0x54/0x98 > [ 22.815086] seq_read+0x278/0x45c > [ 22.815190] __vfs_read+0x28/0x17c > [ 22.815289] vfs_read+0xa8/0x14c > [ 22.815381] ksys_read+0x50/0x94 > [ 22.815475] ret_from_syscall+0x0/0x38 > > Commit 69d2480456d1 ("btrfs: use copy_page for copying pages instead > of memcpy") changed the way bitmap blocks are copied. But allthough > bitmaps have the size of a page, they were allocated with kzalloc(). > > Most of the time, kzalloc() allocates aligned blocks of memory, so > copy_page() can be used. But when some debug options like SLAB_DEBUG > are activated, kzalloc() may return unaligned pointer. > > On powerpc, memcpy(), copy_page() and other copying functions use > 'dcbz' instruction which provides an entire zeroed cacheline to avoid > memory read when the intention is to overwrite a full line. Functions > like memcpy() are writen to care about partial cachelines at the start > and end of the destination, but copy_page() assumes it gets pages. As > pages are naturally cache aligned, copy_page() doesn't care about > partial lines. This means that when copy_page() is called with a > misaligned pointer, a few leading bytes are zeroed. > > To fix it, allocate bitmaps through kmem_cache instead of using kzalloc() > The cache pool is created with PAGE_SIZE alignment constraint. > > Reported-by: Erhard F. > Link: https://bugzilla.kernel.org/show_bug.cgi?id=204371 > Fixes: 69d2480456d1 ("btrfs: use copy_page for copying pages instead of memcpy") > Cc: stable@vger.kernel.org > Signed-off-by: Christophe Leroy > --- > v2: Using kmem_cache instead of get_zeroed_page() in order to benefit from SLAB debugging features like redzone. I'll take this version, thanks. Though I'm not happy about the allocator behaviour. The kmem cache based fix can be backported independently to 4.19 regardless of the SL*B fixes. > +extern struct kmem_cache *btrfs_bitmap_cachep; I've renamed the cache to btrfs_free_space_bitmap_cachep Reviewed-by: David Sterba