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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40AD5C433EF for ; Thu, 7 Jul 2022 11:58:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E2456B0072; Thu, 7 Jul 2022 07:58:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96BF86B0073; Thu, 7 Jul 2022 07:58:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 833E96B0074; Thu, 7 Jul 2022 07:58:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 723B66B0072 for ; Thu, 7 Jul 2022 07:58:22 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 46C8B60CCA for ; Thu, 7 Jul 2022 11:58:22 +0000 (UTC) X-FDA: 79660156044.29.2C90717 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf24.hostedemail.com (Postfix) with ESMTP id E740C18003F for ; Thu, 7 Jul 2022 11:58:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657195101; x=1688731101; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Y897ccQh9DniNRVq6CwkRyY6onhzd1oeECrmj1dS8v0=; b=L7cb5Wpy3wpd7sHMEIE4vavi8No4CvsuncpenqH69gqMSu5GA5D0+aq8 hzAG9AfnpDa/aolYzwQq+Yh1AXwghrgo6pyO2khvNi3JVJnBYWQsd7C+a GT4hRy4DzbkTq4kqKYztGjeAdOyEz0c0XhHxi5daceg18PgyuzS2RRe25 uJwsckAqGMHq0x41jfkjkb8+GMlqHFoRufrOCWCBDT9NoS3twwJusNl3V eIi2en0iuOMHu/z/Cs8fK3FglOncisjlXdraa0w10g+QryxGaboLVbihb 9pgNUJQZBtxwj2Rk+NnuJp0hYVbihH0dz+4o8BhlYVEZaq7w3iN5J+cz2 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10400"; a="272799121" X-IronPort-AV: E=Sophos;i="5.92,252,1650956400"; d="scan'208";a="272799121" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2022 04:58:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,252,1650956400"; d="scan'208";a="620762106" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga008.jf.intel.com with ESMTP; 07 Jul 2022 04:58:00 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id C5DCD400; Thu, 7 Jul 2022 14:58:07 +0300 (EEST) Date: Thu, 7 Jul 2022 14:58:07 +0300 From: "Kirill A. Shutemov" To: Alexander Potapenko Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , the arch/x86 maintainers , Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Subject: Re: [PATCHv4 3/8] mm: Pass down mm_struct to untagged_addr() Message-ID: <20220707115807.pzrj7bngm2ndcjwk@black.fi.intel.com> References: <20220622162230.83474-1-kirill.shutemov@linux.intel.com> <20220622162230.83474-4-kirill.shutemov@linux.intel.com> <20220706231349.4ghhewbfpzjln56u@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657195101; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xuotuzqmuqvW/pM1XwazWuXR0jU+xokqDC6ljmKSi7Q=; b=ltWdPcLanlGv2laR2PqO5kdaDxnCRKSwqcnrFT7oEZqSwMRM9/uoTHVBda4cFUvgL6NcNd NfXP/U3B+wdTKYCh7luEWYNCdWVd31x2N9hYiuPcHHbsdKNOfvbMofTr/AwW3Pm0qXPlVl wLhf8mgeT/zhkZ5YxPEsYBrcrWJYBEg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L7cb5Wpy; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657195101; a=rsa-sha256; cv=none; b=B69Wg7SPqviuZLtkYPVRvEnrEGQNjV4MSaDEIVyjHAj4iqRof5NNkBpApHRLKXH34J2Ngd Rk9VqjG1XysObYPM8MGy9C7YeukyQ2Oa6AZ7fBej5V00mqjj2J8AN+fe3uiVr8TSJappr/ 44EBSLRgAmUzEFWUFCHiGnz2hMIu0T0= X-Rspam-User: X-Rspamd-Server: rspam07 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L7cb5Wpy; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Stat-Signature: ob44ctbehg4ki5fibba4bdjhif8zmjg7 X-Rspamd-Queue-Id: E740C18003F X-HE-Tag: 1657195100-139184 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 07, 2022 at 10:56:53AM +0200, Alexander Potapenko wrote: > On Thu, Jul 7, 2022 at 1:14 AM Kirill A. Shutemov > wrote: > > > > On Tue, Jul 05, 2022 at 05:42:21PM +0200, Alexander Potapenko wrote: > > > Kirill, > > > > > > > > > > diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c > > > > index feeb935a2299..abc096a68f05 100644 > > > > --- a/lib/strnlen_user.c > > > > +++ b/lib/strnlen_user.c > > > > @@ -97,7 +97,7 @@ long strnlen_user(const char __user *str, long count) > > > > return 0; > > > > > > > > max_addr = TASK_SIZE_MAX; > > > > - src_addr = (unsigned long)untagged_addr(str); > > > > + src_addr = (unsigned long)untagged_addr(current->mm, str); > > > > > > In a downstream kernel with LAM disabled I'm seeing current->mm being > > > NULL at this point, because strnlen_user() is being called by > > > kdevtmpfs. > > > IIUC current->mm is only guaranteed to be non-NULL in the userspace > > > process context, whereas untagged_addr() may get called in random > > > places. > > > > > > Am I missing something? > > > > Hm. Could you show a traceback? > > > > As strnlen_user() intended to be used on an user string I expected it to > > be called from a process context. I guess I'm wrong, but I don't yet > > understand why. > > Oh, I see now. The old implementation of devtmpfsd() > (https://elixir.bootlin.com/linux/v5.4/source/drivers/base/devtmpfs.c#L397) > uses ksys_mount(), which assumes that the strings must be copied from > the userspace, whereas they are actually constants in kernel .rodata > > Wonder if the validity of mm->current for userspace accesses is > actually enforced anyhow in newer kernels. I think it is. See 967747bbc084 and how it changes strnlen_user(). With max_addr equal to TASK_SIZE_MAX, strnlen_user() will always fail on a kernel string. -- Kirill A. Shutemov