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 D5DA8CDB483 for ; Tue, 17 Oct 2023 21:53:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344026AbjJQVx5 (ORCPT ); Tue, 17 Oct 2023 17:53:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230056AbjJQVxz (ORCPT ); Tue, 17 Oct 2023 17:53:55 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25DB0B0 for ; Tue, 17 Oct 2023 14:53:54 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-9b1ebc80d0aso969706866b.0 for ; Tue, 17 Oct 2023 14:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1697579632; x=1698184432; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=psxzYy8Ro6VCd0vtaHbgahw7/JWUti7oPPeTmbqEN7o=; b=PviMAFjmQlBe39l+CiUpy8lAgv3LnR19JBAVxakMoarbksmaSI2boIW1zM7un9IsVi Ui5pRxSoj5+txLC+2dpT6Yt/qom+Fcl1syBUizMqXnb6jee7fZ9XYR2BIY62nlJ+el2g WZKDlIowslBgSqi5TRn16rnGadiVMB7awMBj4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697579632; x=1698184432; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=psxzYy8Ro6VCd0vtaHbgahw7/JWUti7oPPeTmbqEN7o=; b=s72zq5JmJejoMDztt86Z8iC1PKQee8zAF6cqk86noDdJY1K2+CGE20PANWbJsacT6F g/FqWZ9XtukjKVLlMMiQplzHKTrZsAFarWy1VStEUu7im1C2JiuC73ElnqMlpWai2Uqf VIMdH3rhQddeX9PWijmENgAD/hUyF11JlTJJn0+A1K6DGF3QbDVx9Qa0e7Y1RhTvWVxs 9NU08OOaqPpIyezDf+cK421U2UQxRnsjwQi7QkleVNM3yiD6QxWjCWufPBNHHmYH86CD SAMvh7K0+Antqu0mDPAtzXJv/6F0qBRmNnavtWgGtjXxYXCgapVXq0YaibMP4ydzT5mK a9Bw== X-Gm-Message-State: AOJu0YyvwQNaQIKZ1XaZhsr3MsLf9rJnG4mvt+kmOt/sthX4W6Az0ZxV rKt0v6k+agV3628fw0tGSUBcsTKnRqWZKZ802MOeWKmz X-Google-Smtp-Source: AGHT+IEiYCGvORSzHzMnnLuYN482T9kR7FkRIvPzWMqYnrY/k8G3DD25SGvG4ysms+OrQoRawvFGVw== X-Received: by 2002:a17:907:3fa3:b0:9bd:c592:e0ce with SMTP id hr35-20020a1709073fa300b009bdc592e0cemr2782381ejc.51.1697579632545; Tue, 17 Oct 2023 14:53:52 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id k19-20020a170906579300b0099bd5d28dc4sm429455ejq.195.2023.10.17.14.53.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Oct 2023 14:53:51 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5384975e34cso10918680a12.0 for ; Tue, 17 Oct 2023 14:53:51 -0700 (PDT) X-Received: by 2002:a17:907:25c4:b0:9c4:4b20:44b2 with SMTP id ae4-20020a17090725c400b009c44b2044b2mr2580462ejc.23.1697579631483; Tue, 17 Oct 2023 14:53:51 -0700 (PDT) MIME-Version: 1.0 References: <20231010164234.140750-1-ubizjak@gmail.com> <0617BB2F-D08F-410F-A6EE-4135BB03863C@vmware.com> <7D77A452-E61E-4B8B-B49C-949E1C8E257C@vmware.com> <9F926586-20D9-4979-AB7A-71124BBAABD3@vmware.com> In-Reply-To: From: Linus Torvalds Date: Tue, 17 Oct 2023 14:53:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() To: Uros Bizjak Cc: Nadav Amit , "the arch/x86 maintainers" , Linux Kernel Mailing List , Andy Lutomirski , Brian Gerst , Denys Vlasenko , "H . Peter Anvin" , Peter Zijlstra , Thomas Gleixner , Josh Poimboeuf , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Oct 2023 at 14:06, Uros Bizjak wrote: > > But adding the attached patch on top of both patches boots OK. Funky. Mind adding a WARN_ON_ONCE(!active_mm); to there to give a nice backtrace for the odd NULL case. That code *is* related to 'current', in how we do tsk = current; ... local_irq_disable(); active_mm = tsk->active_mm; tsk->active_mm = mm; tsk->mm = mm; ... activate_mm(active_mm, mm); ... mmdrop_lazy_tlb(active_mm); but I don't see how 'active_mm' could *poossibly* be validly NULL here, and why caching 'current' would matter and change it. Strange. Hmm. We do set tsk->active_mm = NULL; in copy_mm(), and then we have that odd kernel thread case: /* * Are we cloning a kernel thread? * * We need to steal a active VM for that.. */ oldmm = current->mm; if (!oldmm) return 0; but none of this should even matter, because by the time we actually *schedule* that thread, we'll set active_mm to the right thing. Can anybody see what's up? Linus