Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1272682pxu; Wed, 6 Jan 2021 18:14:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJwYKhV/HHDAUfp1sJn2l5QNjw3mrAbVxYSEUFPPH9Ih3HhfE00BI3BaqTePzgAfiEv1CXp0 X-Received: by 2002:a17:906:13da:: with SMTP id g26mr4642723ejc.285.1609985694606; Wed, 06 Jan 2021 18:14:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609985694; cv=none; d=google.com; s=arc-20160816; b=KWK4ggTFlVb3UW0eWMRpJg0bLtG/F6d8BY2HEvObCguJq95lmIi0ObdsjTxElRHhMv gucFfNTjpk3Oiz12+oaLy8Ov8Ppl0PWa+kGKLDRjyRRVlY7uGkoGk9uk4Tk/rUVLZbC9 3cUOhcnOWiTU9ofdYMBhUgvtS75OIdBBi9+triQPQMFRUDo2k9b/sl3G/YD61WAyzv2E qZ5U7gvZnOlLkgbr3t91lN+CVwbBVmphaTq5x8DZ9+4ljWgK6SoUSDV6HG44T36Xh2Xn y2P3YDH9heFhvsBnT8wOa1HHIv1qBlFeYJ/u62RV16+zKCj3Q1x2DeVEzA6XnWyhi0vX u5Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=7QUKDV8GhR0Hal3SMjWQ+BvIoYteQVe/RM0xw5OztWs=; b=QPW3HEAUDn/369AO6ADbpxOeGGQS1DePey99ty/+p45F174Rsf07usFM0zZH32vs0A sI/4VC6X6M+ZkTUUYBlLekg8sAb20/r++++ddIEWB8om+kK/mDVoyOc+M5MDIM01QKe2 X13Of3YHbSlYw6HZBVID428XcRjCVHIVt6CP1HonqQPyk+qqnFLnNR02CjkI2agiaNeU +zYPAm+w8sVoqLerJxY1mxynzU5H3Oi8dCobO1AaGzGTdgf5TZhYk5IpNTjjRIagm94S 14McBR/qhhDgyVwCu6gehtP9JV6ocQn0LkXl2T9v7srutf0lVaz+fMXUVS9mUc42qiRT oCdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=i4RKVO87; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b15si1593514ejc.100.2021.01.06.18.14.25; Wed, 06 Jan 2021 18:14:54 -0800 (PST) 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=@google.com header.s=20161025 header.b=i4RKVO87; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726788AbhAGCMr (ORCPT + 99 others); Wed, 6 Jan 2021 21:12:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726086AbhAGCMq (ORCPT ); Wed, 6 Jan 2021 21:12:46 -0500 Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EBC8C0612EF for ; Wed, 6 Jan 2021 18:12:06 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id h6so2859414vsr.6 for ; Wed, 06 Jan 2021 18:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7QUKDV8GhR0Hal3SMjWQ+BvIoYteQVe/RM0xw5OztWs=; b=i4RKVO87xQDD+OHygS/7nJBRBxgtFlnBHuiJMdXRggb+7FIB9GFulzfuHXlTGOfyCQ lKVdCnLvycIAnj2agamwAe6A3DGtzF3hL5Mt3jWXGT/ys8+xXuU+3qLpeXzxx3TPrmOh ykGYRaOklikyjYiAw3nKv0s38DcRNOy627qPug6NpPA3RrOb1fra+XRhx8joUYwKYLcQ m4rByeYQBBqRfmTxySw7XY1/qtxAbk2OQHzVfr77kEu75OCfEq3uopLsQGqJhTI8RsWC Y7btRuv/pAr/eZSRLptQn5vCOk6ES+stdaon3n0b/wui/e4cfm4macRk4nH4PTID0bAI 1ifg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7QUKDV8GhR0Hal3SMjWQ+BvIoYteQVe/RM0xw5OztWs=; b=EE5FBC27PcwXfgsWDOfyf96MDd5SKBhcLg4KXdK3h3w19fAif/qvebz0ZChRZKrP4R JUEm7b4Rqb0BOES+Lh2uaCNoFpaQfTeV3z4yMYAib+XqUpzRtw8W43vMadiOLCZrFdEL wCDz8n/QEenITG0LzCU/6TMNx0/jFOOiCLetns8jmo+3vcSj/08TYJWIRJWzCov6M32s Z2tihMOX15CYPwS64KVZE7E+mK6TZ4q3fGSGV+ksF7FvhD9yLnuvOiIeFFT47yaOSOCa xu6P4qP0m2j5XAOMM/RPCtsBvocffJ890Bj0hLMZOl/SF0g1xJFBcafDIGRLerOSqRwE YUKw== X-Gm-Message-State: AOAM531HIBQZWOcjgIwusSLfLVt3frOLuQF97z6zpLpU8AyyjV83vZiJ 7I5CFtyHxy5HYUNc8VfCetemtgSyrzDI4UOOsOykhQ== X-Received: by 2002:a67:f043:: with SMTP id q3mr5511928vsm.14.1609985525023; Wed, 06 Jan 2021 18:12:05 -0800 (PST) MIME-Version: 1.0 References: <20201118194838.753436396@linutronix.de> <20201118204007.169209557@linutronix.de> <20210106180132.41dc249d@gandalf.local.home> <20210106174917.3f8ad0d8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20210106174917.3f8ad0d8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> From: Willem de Bruijn Date: Wed, 6 Jan 2021 21:11:27 -0500 Message-ID: Subject: Re: [BUG] from x86: Support kmap_local() forced debugging To: Jakub Kicinski Cc: Linus Torvalds , Steven Rostedt , David Miller , Jonathan Lemon , Thomas Gleixner , LKML , "the arch/x86 maintainers" , Christoph Hellwig , Matthew Wilcox , Daniel Vetter , Andrew Morton , Linux-MM , Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Netdev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 6, 2021 at 8:49 PM Jakub Kicinski wrote: > > On Wed, 6 Jan 2021 17:03:48 -0800 Linus Torvalds wrote: > > I wonder whether there is other code that "knows" about kmap() only > > affecting PageHighmem() pages thing that is no longer true. > > > > Looking at some other code, skb_gro_reset_offset() looks suspiciously > > like it also thinks highmem pages are special. > > > > Adding the networking people involved in this area to the cc too. > > Thanks for the detailed analysis! skb_gro_reset_offset() checks if > kernel can read data in the fragments directly as an optimization, > in case the entire header is in a fragment. > > IIUC DEBUG_KMAP_LOCAL_FORCE_MAP only affects the mappings from > explicit kmap calls, which GRO won't make - it will fall back to > pulling the header out of the fragment and end up in skb_copy_bits(), > i.e. the loop you fixed. So GRO should be good. I think.. Agreed. That code in skb_gro_reset_offset skips the GRO frag0 optimization in various cases, including if the first fragment is in high mem. That specific check goes back to the introduction of the frag0 optimization in commit 86911732d399 ("gro: Avoid copying headers of unmerged packets"), at the time in helper skb_gro_header(). Very glad to hear that the fix addresses the crash in skb_frag_foreach_page. Thanks!