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 0CD5AC77B73 for ; Sat, 27 May 2023 07:05:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231292AbjE0HE6 (ORCPT ); Sat, 27 May 2023 03:04:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbjE0HEx (ORCPT ); Sat, 27 May 2023 03:04:53 -0400 Received: from out-16.mta1.migadu.com (out-16.mta1.migadu.com [95.215.58.16]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12505EB for ; Sat, 27 May 2023 00:04:51 -0700 (PDT) Date: Sat, 27 May 2023 03:04:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1685171090; 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=iou0GTPq4Ljp/eKRqegKeRywXowmKecKWFtCM8AzuyE=; b=vaqBn89cvOB6cMJpgVHg8c9LyrFKdkyl6wiaHAmBzmvw/5hJ3K7b2CFzuKlroi18Gt2y87 9A5XRCQIl6o2dJEOPbDlTOqFs3MkIgYM/WKORNr10fKe9m7Inp7yE3R8RsDuDj518bJBPj ymlbbkFW7ZnF6yfDkkv8vgKc5h9Z7SQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Song Liu Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, mcgrof@kernel.org, peterz@infradead.org, tglx@linutronix.de, x86@kernel.org, rppt@kernel.org Subject: Re: [PATCH 0/3] Type aware module allocator Message-ID: References: <20230526051529.3387103-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230526051529.3387103-1-song@kernel.org> X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 25, 2023 at 10:15:26PM -0700, Song Liu wrote: > This set implements the second part of module type aware allocator > (module_alloc_type), which was discussed in [1]. This part contains the > interface of the new allocator, as well as changes in x86 code to use the > new allocator (modules, BPF, ftrace, kprobe). > > The set does not contain a binpack allocator to enable sharing huge pages > among different allocations. But this set defines the interface used by > the binpack allocator. [2] has some discussion on different options of the > binpack allocator. I'm afraid the more I look at this patchset the more it appears to be complete nonsense. The exposed interface appears to be both for specifying architecture dependent options (which should be hidden inside the allocator internals!) _and_ a general purpose interface for module/bpf/kprobes - but it's not very clear, and the rational appears to be completely missing. I think this needs to back to the drawing board and we need something simpler just targeted at executable memory; architecture specific options should definitely _not_ be part of the exposed interface. The memory protection interface also needs to go, we've got a better interface to model after (text_poke(), although that code needs work too!). And the instruction fill features need a thorough justification if they're to be included.