From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C8DCC00528 for ; Mon, 31 Jul 2023 20:34:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229772AbjGaUep (ORCPT ); Mon, 31 Jul 2023 16:34:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229638AbjGaUeo (ORCPT ); Mon, 31 Jul 2023 16:34:44 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53ADD1BEF; Mon, 31 Jul 2023 13:34:26 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-316feb137a7so5151334f8f.1; Mon, 31 Jul 2023 13:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690835664; x=1691440464; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=erOfK/Ywaqu4GQR7DM2S2Q8N9sM102JexPWTiAvOnR8=; b=qs3pfJOVNqZT9vEauebmmM5fpl2ScFPDUEnkBr1B0ZgufKpemdRuSao3iArmSKc9gj NN+AA65G9yv9pdF8X4MX73cSZFYYNJA3vo+6xkwE8+umPrjKM0ztlaw7LLjXFxOwnO0D lQc49OdQejgfnDkS34NJhgtxhOFwSQGNHU6DZgpvjBpdzrpvnby3/KChrG5w+Z/icn9g wT8MG/wX6cLQePXDfoNqg6+qV32QM+jm5I6xCUaJWrlvABhbj8j+iTGM655TNHfRlMSl JM8W1Prrr1m2hrPCG+wPPzY0krbT8Ilmi2DAoz45oMRhbsc3/xlWTNutASJCXXKWc7xb DWlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690835664; x=1691440464; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=erOfK/Ywaqu4GQR7DM2S2Q8N9sM102JexPWTiAvOnR8=; b=BQpeQNfkPPzHMIDxgVhzuIwxtna69u4nRnzOaCRslryi3EQgRJiNnzHDtg/ic2PUu2 nYRVN47mN7YMYYfbyzqUGpyR2fGTKU2hvOpLnII4zKe1Qb83EE5qBrPcSz63sI21n4Le NP4Z5iFrgQ4HIkkb011cguwfZHio3SzgkjHknlrsoyVMSsUKbY6fgzkQ3kSiHy94tsrj vPi3gG1v5RfIWV9XGlI1/03W+uwBLf19LwQrb4PNiQQvDzapx0oq1k2TWNoid7CfZYL4 yhfutWfM0NO67h/+smY3382nwpsUq92reWb8saQlSytoWNE6jTbxH3df28vQAFf7E7fY cShw== X-Gm-Message-State: ABy/qLboJiRVtoMf9mcJiwvQMuMUbjvmYuzlrFau3TumMaXijwUmcIMT ni1gBkKCvNYiHNPjE/3f+/w= X-Google-Smtp-Source: APBJJlHv67washl2dS7E0c58n9ODVHLgwkCmP7urrHQMWwYPoR68/ZAARgq0+fSXEzoVv+k7PD7VMQ== X-Received: by 2002:a5d:62c7:0:b0:315:ad00:e628 with SMTP id o7-20020a5d62c7000000b00315ad00e628mr545972wrv.47.1690835664138; Mon, 31 Jul 2023 13:34:24 -0700 (PDT) Received: from krava ([83.240.60.220]) by smtp.gmail.com with ESMTPSA id f11-20020adff58b000000b003143aa0ca8asm14000342wro.13.2023.07.31.13.34.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 13:34:23 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Mon, 31 Jul 2023 22:34:21 +0200 To: Lorenzo Stoakes Cc: David Hildenbrand , Baoquan He , Jiri Olsa , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Matthew Wilcox , Liu Shixin , Jens Axboe , Alexander Viro Subject: Re: [PATCH v8 1/4] fs/proc/kcore: avoid bounce buffer for ktext data Message-ID: References: <86fd0ccb-f460-651f-8048-1026d905a2d6@redhat.com> <32b8c5e4-c8e3-0244-1b1a-ca33bd44f38a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jul 31, 2023 at 08:40:24PM +0100, Lorenzo Stoakes wrote: > On Mon, Jul 31, 2023 at 09:24:50PM +0200, David Hildenbrand wrote: > > On 31.07.23 21:21, Lorenzo Stoakes wrote: > > > On Mon, Jul 24, 2023 at 08:23:55AM +0200, David Hildenbrand wrote: > > > > Hi, > > > > > > > > > > > > > > I met this too when I executed below command to trigger a kcore reading. > > > > > I wanted to do a simple testing during system running and got this. > > > > > > > > > > makedumpfile --mem-usage /proc/kcore > > > > > > > > > > Later I tried your above objdump testing, it corrupted system too. > > > > > > > > > > > > > What do you mean with "corrupted system too" -- did it not only fail to > > > > dump the system, but also actually harmed the system? > > > > > > > > @Lorenzo do you plan on reproduce + fix, or should we consider reverting > > > > that change? > > > > > > > > -- > > > > Cheers, > > > > > > > > David / dhildenb > > > > > > > > > > Apologies I mised this, I have been very busy lately not least with book :) > > > > > > Concerning, I will take a look as I get a chance. I think the whole series > > > would have to be reverted which would be... depressing... as other patches > > > in series eliminates the bounce buffer altogether. > > > > > > > I spotted > > > > https://lkml.kernel.org/r/069dd40aa71e634b414d07039d72467d051fb486.camel@gmx.de > > > > Find that slightly confusing, they talk about just reveritng the patch but then > also add a kern_addr_valid()? > > I'm also confused about people talking about just reverting the patch, as > 4c91c07c93bb drops the bounce buffer altogether... presumably they mean > reverting both? > > Clearly this is an arm64 thing (obviously), I have some arm64 hardware let me > see if I can repro... I see the issue on x86 > > Baoquan, Jiri - are you reverting more than just the one commit? And does doing > this go from not working -> working? Or from not working (worst case oops) -> > error? yes, I used to revert all 4 patches I did quick check and had to revert 2 more patches to get clean revert 38b138abc355 Revert "fs/proc/kcore: avoid bounce buffer for ktext data" e2c3b418d365 Revert "fs/proc/kcore: convert read_kcore() to read_kcore_iter()" d8bc432cb314 Revert "iov_iter: add copy_page_to_iter_nofault()" bf2c6799f68c Revert "iov_iter: Kill ITER_PIPE" ccf4b2c5c5ce Revert "mm: vmalloc: convert vread() to vread_iter()" de400d383a7e Revert "mm/vmalloc: replace the ternary conditional operator with min()" jirka