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 8C1A9C41513 for ; Mon, 31 Jul 2023 19:40:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229722AbjGaTk3 (ORCPT ); Mon, 31 Jul 2023 15:40:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229528AbjGaTk2 (ORCPT ); Mon, 31 Jul 2023 15:40:28 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52396199D; Mon, 31 Jul 2023 12:40:27 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3fe24dd8898so7975865e9.2; Mon, 31 Jul 2023 12:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690832426; x=1691437226; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Sy6unmAOZDl25dmGqDdgjGgEy7Fu7QkLZ+dEPeEHA3w=; b=YxP7d8TWxCj/8uRCfpev70zLJ8T6kn2yrBYF+HLOCBjzaOHt4NwNCVBvah7A0UklMg mwWGcrgmoahWw2R/NUUpoiob5wzBTIdDS8TKisYfpYbw9YVNLHekCJFmT0VWmqLzo1X+ qbHGtlsCuBP2BCTt8II0U8tNT2mrvOb0J2TWuowGCQWJWDL8Zxg1RC1OjvhXj24jMRHQ BytEqC8bzLxlUYa73oF+xG5FFyM8dWWp15GpUNAa3eC/Y7Erif2T1Qh1+oJX92z5mFL2 heCTlwjYVwsCvDk1KjCt1CLGBlRI/QM86OWtS1+QWWpNDTbI/DeEJo4pEGDA0Xu31unn FnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690832426; x=1691437226; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Sy6unmAOZDl25dmGqDdgjGgEy7Fu7QkLZ+dEPeEHA3w=; b=IzEi+WTT69Xn8cVm6g+od97aLjQrvzR94MEvXrUxUkOX3Y1S9u8eLZcU9hWlTkT7z9 NpfAlX6rw+B4SnNGizDXHeEe+zCqA8hUbW5ccuULC9wMTJPh68vNU7OUwTQvHSfumiNp +jaoJidZN+Z3bgbLdTMcdNjD0HC1gDadDhtLbUQoi4DSRn8JIdWOXUIDqh0cbjfEfSgc GsNdKSZjVL2aasrfub7sokgXlwDoxTceKAYr3sQHnMNRp6ODx6oAImDzFIHHktuXM+6a d9i4jgHFs3Cr4pdzQKc2kvPRntshdYAA4mC4XKR4kAtHcvHVFySHUN5JS7zFjTVx4x+p pnCw== X-Gm-Message-State: ABy/qLbbJ6z+W0MJDhs/K7Jobhhxe2PNt+/xvKPjrGtYH7fS9GgRyIxq utShGpPlxi9FZF46RjXmB/o= X-Google-Smtp-Source: APBJJlHyxbZ3YfFVMVMFa8QzM/PIEhuoxubhFCWwG9Ka8E8RRQw7oYWoWGESWMBP2fP0bvQMoyFrsw== X-Received: by 2002:a5d:6146:0:b0:314:dea:f1f8 with SMTP id y6-20020a5d6146000000b003140deaf1f8mr501942wrt.11.1690832425604; Mon, 31 Jul 2023 12:40:25 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id r8-20020adfe688000000b0031434c08bb7sm13861184wrm.105.2023.07.31.12.40.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 12:40:24 -0700 (PDT) Date: Mon, 31 Jul 2023 20:40:24 +0100 From: Lorenzo Stoakes To: David Hildenbrand Cc: 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: <32b8c5e4-c8e3-0244-1b1a-ca33bd44f38a@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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... 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? > today, maybe that's related. > > -- > Cheers, > > David / dhildenb >