Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4321847pxb; Tue, 2 Nov 2021 07:52:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWaKCyQx+Uj+oaHrr9zBbFqszQXt7RQqGhyU8649PnulZHPBS0D3Kb6YNPXny1djs8Gh3b X-Received: by 2002:a05:6e02:1ca1:: with SMTP id x1mr15283393ill.141.1635864727927; Tue, 02 Nov 2021 07:52:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635864727; cv=none; d=google.com; s=arc-20160816; b=yPgWrWgHCy6v0rVOgdYE/BjXboRizLOZ2I5ozyD8cS/Do3jWsCetZif0wjfR5j3Riq 3YCnLZVV0A6INIXwAtYlesPYlyIy7UqpXUxZ0McQF8SGrn9eXywEmxeqzgDpXAZf7307 4UZQNborNldns7eZNfINtRR4oDfd9TqA1AQUJqsQvoEzNilGb0AoVhKk25+WrS3uJaIr CNxKhbdfeiZLLjyec+rD/boZ9kea85VBcKM4Mp77XdkaHLdTHmsNC+4DvNRbTa61DBXb jlSrnggeiSBoXJM50xV9Foci4fj6lDAIzVtdduOwSSCalEkmQEBAyYs0vbVu5ArDHZbK c2gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=hUR1+HJbWQQ47r9x8xPETncMuUN4UXEP73XAuC0V2SE=; b=UMZZKCOHj9CocLSQTzQn7tUZmfiA07iQSXsBb0xZjB2VkI0n77IRaCp/oMgfMoBeq7 djIQ3cjiKlfHvkOt4n8x+MJ62BvEiz/Y93WreynmLtgmkWWWNLe+D/IUzsiWH5TVqjZm U5tHKIChjeV8AQjXCCCZFbBX7xH6Di6ixa3yaxUXGJfPeYnZrY1jc5FXGKBw7PJgH2MR wmj735Ej0NUwMw6MnhKDhxZk3NfnzN3MIH+sH9TAOiRtmbCP2gICAuZdIIY2F9c1umkV BV57Ia4We3bW6uZaBV12YGDLs4E1FEDzj2yi19hrQipYM9lUvMX4idi4uCm/xjSi6Rhi gHQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Q1buZLmw; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si13460647iow.16.2021.11.02.07.51.50; Tue, 02 Nov 2021 07:52:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Q1buZLmw; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233404AbhKBOxc (ORCPT + 99 others); Tue, 2 Nov 2021 10:53:32 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:48476 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232985AbhKBOxa (ORCPT ); Tue, 2 Nov 2021 10:53:30 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 67A481FD4C; Tue, 2 Nov 2021 14:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1635864654; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hUR1+HJbWQQ47r9x8xPETncMuUN4UXEP73XAuC0V2SE=; b=Q1buZLmwVNFTcORhqbeBaA5ReztWd8isw4byGjZVw0NjdL0YObpeLVoIITtGIIsyDXfxxa RS/EvdlsIiuMHGIsiXgEFw3l6oDZpaBNrpUpTu524LiyUikMuwFNRZe+nXcacXhM+148ny nru2XvSo9B3bNc22G5oT6x9hETLTEDU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1635864654; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hUR1+HJbWQQ47r9x8xPETncMuUN4UXEP73XAuC0V2SE=; b=P37eNTEvq9XTW4hMU/dAT/benTNmc0IeqMmaHavyX99QFglCHrUGSN4ekuMqbAUWtEG/C+ YckmuzwLhtLFyeDw== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 5E6FDA3B81; Tue, 2 Nov 2021 14:50:54 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 2214ADA7A9; Tue, 2 Nov 2021 15:50:19 +0100 (CET) Date: Tue, 2 Nov 2021 15:50:18 +0100 From: David Sterba To: Linus Torvalds Cc: David Sterba , Qu Wenruo , linux-btrfs , Linux Kernel Mailing List Subject: Re: [GIT PULL] Btrfs updates for 5.16 Message-ID: <20211102145018.GK20319@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Linus Torvalds , David Sterba , Qu Wenruo , linux-btrfs , Linux Kernel Mailing List 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 01, 2021 at 01:03:25PM -0700, Linus Torvalds wrote: > On Mon, Nov 1, 2021 at 9:46 AM David Sterba wrote: > > > > There's a merge conflict due to the last minute 5.15 changes (kmap > > reverts) and the conflict is not trivial. > > You don't say. > > I ended up just re-doing that resolution entirely, and as I did so, I > think I found a bug in the original revert that caused the conflict in > the first place. > > And since that revert made it into 5.15, I felt like I had to fix that > bug first - and separately - so that the fix can be backported to > stable. > > I then re-did my merge on top of that hopefully fixed state, and maybe > it's correct. > > Or maybe I messed up entirely. > > I did end up comparing it to your other branch too, but that was > equally as messy, apart from the "ok, I can mindlessly just take your > side". > > And it was fairly different from what I had done in my merge > resolution, so who knows. Looks good to me, thanks for catching the bug. > ANYWAY. What I'm trying to say is that you should look very very > carefully at commits > > 2cf3f8133bda ("btrfs: fix lzo_decompress_bio() kmap leakage") > 037c50bfbeb3 ("Merge tag 'for-5.16-tag' of git://git.../linux") > > because I marked that first one for stable, and the second is > obviously my entirely untested merge. > > It makes sense to me, but apart from "it builds", I've not actually > tested any of it. This is all purely from looking at the code and > trying to figure out what the RightThing(tm) is. > > Obviously the kmap thing tends to only be noticeable on 32-bit > platforms, and that lzo_decompress_bio() bug also needs just the > proper filesystem settings to trigger in the first place. > > Again - please take a careful look. Both at my merge and at that > alleged kmap fix. I checked the commits individually and in the source files, all the kmaps seem to be correctly paired with kunmaps. We'll do more tests too. I'm sorry that it turned out to be such mess.