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 2D98AC7EE25 for ; Sun, 14 May 2023 23:43:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64C6E900003; Sun, 14 May 2023 19:43:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FC68900002; Sun, 14 May 2023 19:43:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C3AA900003; Sun, 14 May 2023 19:43:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 39B84900002 for ; Sun, 14 May 2023 19:43:35 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F0BD2A0CF2 for ; Sun, 14 May 2023 23:43:34 +0000 (UTC) X-FDA: 80790489948.13.309F256 Received: from out-51.mta1.migadu.com (out-51.mta1.migadu.com [95.215.58.51]) by imf12.hostedemail.com (Postfix) with ESMTP id 170CB40009 for ; Sun, 14 May 2023 23:43:31 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OobDuuQT; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.51 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684107812; 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=mggwEpH/XfQSgikEQX+k7jG5jsZJxafKLG7tZ7lLfpw=; b=BgtKcWTxFsqO0gC1zLTqk+wV5jjRvnZWh8AlxGG0p/EJPxIKsrsZ3CJ8zdPc1onD9xeC0/ doEqWLtprblXR58wZ089BCIJVKav0WnIkivZBvJcEiqZY/2+QWcliE9Xl0ldY7eli/hreF cx2crU2tRmvpR93LR4Sv2nAiozE93Ik= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684107812; a=rsa-sha256; cv=none; b=vs4EAMIYQxHfZuvyaZd/o1aZydhQAtoaG/djp07/m44tOaZdWCGbUsPz5jkWH1hPTqUxGU kmwoNdaXa8FFndY7ZgqNjrGHixMrmj4MGkwo9sFA0WC50+/gwOGiwvxeLn3s/hROOillSR BQlZ6wuIv0k/DHxK4WL5ppBIP9EOEgQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OobDuuQT; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.51 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Sun, 14 May 2023 19:43:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1684107809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mggwEpH/XfQSgikEQX+k7jG5jsZJxafKLG7tZ7lLfpw=; b=OobDuuQTCFp7GRpcbbdm5KWHoEDDSxa6orNliLPqe6jh/lLy2gYgq3nnBl6YmX2w0KPz6o tUCwQ8VtQY6HHlqkOtt3I++X1mDl00GGgKEjaAT+6pfgUJE72HPUtYI5rX018dKoR44SJA 0g2A4B9Z9yGIXTzH0S3Wq70l1qJu4NM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Christophe Leroy Cc: Lorenzo Stoakes , Christoph Hellwig , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-bcachefs@vger.kernel.org" , Kent Overstreet , Andrew Morton , Uladzislau Rezki , "linux-mm@kvack.org" Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Message-ID: References: <20230509165657.1735798-1-kent.overstreet@linux.dev> <20230509165657.1735798-8-kent.overstreet@linux.dev> <8f76b8c2-f59d-43fc-9613-bb094e53fb16@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: sfuzys99186tfgyknwqefdbeyxh9eexo X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 170CB40009 X-HE-Tag: 1684107811-515416 X-HE-Meta: U2FsdGVkX1/5YkPENV/BOvw6nouWsVwKu8lpHjdFd/V71WsvetLu8bhzKe/i+fdVQm3Whj6aUbF4280ZHnQA0dQSCpj5tMn6XbuAkyEKTVxekBV1MoHlWmqZxYVhqx0X2E0MIdVo5PETR6l5gCBGXpR/1B/JN5f6MxnLoj3EBbvAQgAAP2dR2czo91HjpVHF8b0WTYOdnoeNfNHFP9o/NXRnd5YWNSCPb1RtwSFHj+xRkyeOavq4cJ/pU7aiVJQ5oYzr1Za3+6KN12G3HmroGk+ZEd0fm+QH5pSEkfOLmJkXcheWHDOMA1bLbl7elmXeSCNpHn7SSuOVW7S8AO6jzGY5k+c+gSlgamlToJ7nlfSIupqOFutR9aN1kN21gdz0tYIjFNFClK7y7qd7ITzHoVjPxfUt+afKuPeNtJQcVV1sDxFSJFVaIjZrD9qpaMjSdTp8olNzCfCZusnEgxwkTG91+e0/n8N8z6CcbUM5+KV0ehoxupbl2uGzVxilBiUebIO86urWC0KDLgK098e838mpDF6I17sUyE01pAk9/f4lcISVuiDsHl1QgseeRZ4/MzUisrlF6LmBa2lzwAJhW6SEMQGHwLGjIjPhSMArcY7og7dONeMhZfnWbes1iH1vP/lmp382vse+ITu+nlUHGDk/dk74kfuYZa8RO+R6265Mt2KWum3gBGPgGMsosmBSPSs15U701kgBd1dbtPaxTdklCbr8Vq3KCmAQvABwaGog55xAcOZpX+/pMfJc4jyyglhMHzyDtTeDfG4YvGlTFcq4nMFnZwcGDqXQVUR85Cm/O5cNmIhazs+fkDVkI4sqsTKwCPDGS+RxpdCmiEnba38etRjp6EPNpisEBqOEokoRImXTug8dd1mK1jclFp/By6VYw7gZehrSHVA0hfY658E/fCYjoFiR1SG2SW84AHLiMqKE8qn4ZwFnny+miss9tEfXyLY5iYeXh3y+d0m 63s1jjeA mgMM0RF/B/iETs4Bev2TEQZmpyNQLAaKxjfv0ZTeSznmkgf2J/mLeaCFp/lfaLYTf8iDXf+RcvOl/KswVC2cfd0YkrAcKLvn21Z+K42e6ZbRyLOUBtftNP3ejB1B8N6AOziN6ygPzXT5FuTesRsk1AxNMTrIsYgEk7y7KvRux5KewJdk2qJE7PlOJfWa/xH2unFypKO3FwMrAeXY= 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 Sun, May 14, 2023 at 06:39:00PM +0000, Christophe Leroy wrote: > I addition to that, I still don't understand why you bring back > vmalloc_exec() instead of using module_alloc(). > > As reminded in a previous response, some architectures like powerpc/32s > cannot allocate exec memory in vmalloc space. On powerpc this is because > exec protection is performed on 256Mbytes segments and vmalloc space is > flagged non-exec. Some other architectures have a constraint on distance > between kernel core text and other text. > > Today you have for instance kprobes in the kernel that need dynamic exec > memory. It uses module_alloc() to get it. On some architectures you also > have ftrace that gets some exec memory with module_alloc(). > > So, I still don't understand why you cannot use module_alloc() and need > vmalloc_exec() instead. Because I didn't know about it :) Looks like that is indeed the appropriate interface (if a bit poorly named), I'll switch to using that, thanks. It'll still need to be exported, but it looks like the W|X attribute discussion is not really germane here since it's what other in kernel users are using, and there's nothing particularly special about how bcachefs is using it compared to them.