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 4DA5BC433EF for ; Fri, 11 Mar 2022 00:46:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78ECF8D0002; Thu, 10 Mar 2022 19:46:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 73F9A8D0001; Thu, 10 Mar 2022 19:46:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 607188D0002; Thu, 10 Mar 2022 19:46:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 519CD8D0001 for ; Thu, 10 Mar 2022 19:46:46 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 151F5243A4 for ; Fri, 11 Mar 2022 00:46:46 +0000 (UTC) X-FDA: 79230265212.06.D996E9D Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf29.hostedemail.com (Postfix) with ESMTP id 9B74C12001D for ; Fri, 11 Mar 2022 00:46:45 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id bg10so15852494ejb.4 for ; Thu, 10 Mar 2022 16:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MWpPevTXD3OVyRVT3kR8OEKqC1/aCzhwDb8lPZGqgeU=; b=CDZNJsuOi788FY8gAuDZGmuG80aZHvreAMuZ2/qjypwYCvKbhskHBt81S8aJWPM1tr hjtcuXwJ4nOsvWb+oryDzTMfn95fyqZB6BBoKlpNGFr0dtAg2Fgg/OYjjxStPVhsQT+H qKo6KFJIMe0zUgg+i5yc+Ratje7eCBQ+C9VR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MWpPevTXD3OVyRVT3kR8OEKqC1/aCzhwDb8lPZGqgeU=; b=IjIOv3NjdPK74IiYZhBT2R49VQCkvcqR0T4tzLUKj2Ie+m8yUdHbpY4ownOhVBwkOi zcSFeRUPI1fUzeijdUl1f5Z0NUMGkAKXOwikgBwLZWUIHiILzvMAt9wKU7w6vOfDrKRx OgPll1FcR0YdxGT6uEmK6E/01tiuX7ZxZlcP175TTji/SNZ8VkdkbGl7KtFtoxQpqivw So9MAJZQWZp7vbV2IYjbSko36lfyStjUWx7D1Hmh3omzj9Zak52Dd9dPVQ42E47P0Zf8 IS306/2tz25eOo2bFrPGO1+DB3TYypxVsZVVcIJE/6/g+UFzTuIW0PnOWhDAI8WeNeFh fE1g== X-Gm-Message-State: AOAM5321Zp0hw30zeJpe7Kg8JRfkdgEcTuZps8c2lh8GVz1cIdafZOB6 v0xQ5Y0UrDMUtF+w0zFSLM0fxp00agjMgvow6GECYA== X-Google-Smtp-Source: ABdhPJwIBFoifixGR/mxfVGqBIPW9Qoe/+D8Bt3okVLQx4CODl8cRqLb5n7nORyLXZ+SFzDpEKbCzCxuXrLHr7ocLoQ= X-Received: by 2002:a17:906:7316:b0:6d7:16be:b584 with SMTP id di22-20020a170906731600b006d716beb584mr6468336ejc.759.1646959604231; Thu, 10 Mar 2022 16:46:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Thu, 10 Mar 2022 16:46:33 -0800 Message-ID: Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Cc: Xiaomeng Tong , Arnd Bergmann , Greg Kroah-Hartman , Jakob Koschel , Jann Horn , Kees Cook , Linux Kbuild mailing list , Linux Kernel Mailing List , Linux-MM , Netdev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CDZNJsuO; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9B74C12001D X-Stat-Signature: poc51y6m7e79pamt18516bs634kireok X-HE-Tag: 1646959605-952350 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, Mar 10, 2022 at 3:54 PM Micha=C5=82 Miros=C5=82aw wrote: > > If the macro implementation doesn't have to be pretty, maybe it could go > a step further and remember the list_head's offset? That would look > something like following (expanding on your patch; not compile tested): Oh, I thought of it. It gets complicated. For example, a type that refers to a list of itself (and 'struct task_struct' is one such example) cannot actually refer to that other member name while declaring the head entry. That's true even if the target member was declared before the head that points to it - because the type just hasn't been fully instantiated yet, so you can't refer to it AT ALL. And even if that wasn't the case - and we could refer to previous members during the initialization of subsequent ones - you'd still end up with circular issues when one type has a list of another type, which has a list of the first type. Which I'm also fairly certain does happen. With regular "circular pointers", the trick is to just pre-declare the type= , ie struct second; struct first { .. define here, can use 'struct second *' }; struct second { .. define here, can use 'struct first *' }; but that only works as long as you only use a pointer to that type. You can't actually use 'offsetof()' of the members that haven't been described yet. Now, you can combine that "pre-declare the type" model with the "do the offsetof later", but it gets nasty. So I actually think it *can* be made to work, but not using your "pointer to an array of the right size". I think you have to - pre-declare another type (the name needs to be a mix of both the base type and the target type) with one macro - use a pointer to that as-yet undefined but declared type it in that union defined by list_traversal_head() type - then, later on, when that target type has been fully defined, have a *different* macro that then creates the actual type, which can now have the right size, because the target has been declared But that means that you can't really describe that thing inside just the list_traversal_head() thing, you need *another* place that firsat declares that type, and then a *third* place that defines that final the type once all the pieces are in hand. So it gets a lot uglier. But yes, I do believe it it's doable with those extra steps. The extra steps can at least be sanity-checked by that name, so there's some "cross-verification" that you get all the pieces right, but it ends up being pretty nasty. It's extra nasty because that type-name ends up having to contain both the source and destination types, and the member name. We could avoid that before, because the 'name##_traversal_type' thing was entirely internal to the source structure that contains the head, so we didn't need to name that source structure - it was all very naturally encapsulated. So you'd have to do something like #define list_traversal_declare(src, head, dst, member) \ struct src##_##head##_##dst##_##member##_offset_type #define list_traversal_defile(src, head, dst, member) \ list_traversal_declare(src,head,dst,member) { \ char[offsetof(struct dst, member); \ } #define list_traversal_head(src, name, dst, member) \ union { struct list_head name; \ struct dst *name##_traversal_type; \ list_traversal_declare(src,head,dst,member) *name##_target_type_off= set; } and then you'd have to do list_traversal_declare(task_struct, children, task_struct, sibling); struct task_struct { ... list_traversal_entry(task_struct, children, task_struct, sibling); .. }; list_traversal_define(task_struct, children, task_struct, sibling); and now list_traversal() itself can use 'sizeof(*name##_target_type_offset)' to get that offset. NOTE! All of the above was written in my MUA with absolutely no testing, just "I think something like this will work". And note how really ugly it gets. So. Doable? Yes. But at a pretty horrid cost - not just inside the "list_traverse()" macro, but in that now the places declaring how the list works get much much nastier. Linus