Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3900926ybl; Tue, 20 Aug 2019 04:08:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8+2Hz8IcV4Vjq3F0d1lKfBKL2oUQiEtoL4g+Y1Ry15N6CsvisJAB26b85kcouFCkDi/WO X-Received: by 2002:a17:90a:bf82:: with SMTP id d2mr15150378pjs.121.1566299285975; Tue, 20 Aug 2019 04:08:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566299285; cv=none; d=google.com; s=arc-20160816; b=JIm+q5fPjq58NPzeFOZHySetck7QTZwwwgi+Jibc6Bt16jNEUIDdQ0phRNRCTV3pDb SyFyrVgxMih+FkINgnYAx96CboataFNAXHjpfGUmDTT0myKrlAU0HnqnPpXKc3AxPq0d 9t0X60kjX+1Egly/n+NnNwVQ78sVd3Lqu3pREOykwTonwky832A+GzEpFBRyrT2crm71 +9Qr8LaG+aQNUxITRjhrSHJaogPl9gHfLXEDC1U6QqkdscflfUEmXWy9HftHOnmz2Ubo OGl/B8HFwQR6Uu4RF6BfbjFt6FUTMsy79S31MPDrcI9Z52ubluSvTN9Q5Ab3ivTehkSV 7y5A== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=QxqCpiz9w91X18r1f+xg7edqsNC8QO7rH3jC/kXQqEo=; b=eYLEAR6UzxU3Nbp71/66bxH9lWam+1OvYD3yeNQIW1lURgbJAoBUMyhhoWrLxGIPtu S407rNaVYav4ouKy+yFE5cwM/YhKSZAHLcIrYeks9ViHEIsxvE0YHhm3tq/RS9n9OiJ1 00cRryehBulUJAhRbkybpCdarxm5TpHmZ25ismu+RcYrwRbigxRNMwOvYbX5CQEbDCsj EYM4p1HQ4oUGm+i5jHDMyjm4lR2S9nh5eQnfz4LKXCxbPV57nRzW228xD3iDQoGzF623 KgqBbQvjarwfyMFv2rtNyTW4zBWTa5OK0wu2S95XqVMwH/W3xlNEU2qooEuu+jCavcQ7 Y/rQ== 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 x11si8794707pfn.171.2019.08.20.04.07.50; Tue, 20 Aug 2019 04:08:05 -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 S1729764AbfHTLG2 (ORCPT + 99 others); Tue, 20 Aug 2019 07:06:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:43836 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728283AbfHTLG1 (ORCPT ); Tue, 20 Aug 2019 07:06:27 -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 CD029AE9A; Tue, 20 Aug 2019 11:06:25 +0000 (UTC) Subject: Re: [PATCH] btrfs: fix allocation of bitmap pages. To: Christoph Hellwig , dsterba@suse.cz, Christophe Leroy , erhard_f@mailbox.org, Chris Mason , Josef Bacik , David Sterba , Andrew Morton , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org References: <20190817074439.84C6C1056A3@localhost.localdomain> <20190819174600.GN24086@twin.jikos.cz> <20190820023031.GC9594@infradead.org> From: Vlastimil Babka Message-ID: <6f99b73c-db8f-8135-b827-0a135734d7da@suse.cz> Date: Tue, 20 Aug 2019 13:06:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190820023031.GC9594@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/20/19 4:30 AM, Christoph Hellwig wrote: > On Mon, Aug 19, 2019 at 07:46:00PM +0200, David Sterba wrote: >> Another thing that is lost is the slub debugging support for all >> architectures, because get_zeroed_pages lacking the red zones and sanity >> checks. >> >> I find working with raw pages in this code a bit inconsistent with the >> rest of btrfs code, but that's rather minor compared to the above. >> >> Summing it up, I think that the proper fix should go to copy_page >> implementation on architectures that require it or make it clear what >> are the copy_page constraints. > > The whole point of copy_page is to copy exactly one page and it makes > sense to assume that is aligned. A sane memcpy would use the same > underlying primitives as well after checking they fit. So I think the > prime issue here is btrfs' use of copy_page instead of memcpy. The > secondary issue is slub fucking up alignments for no good reason. We > just got bitten by that crap again in XFS as well :( Meh, I should finally get back to https://lwn.net/Articles/787740/ right