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 B2686C433F5 for ; Tue, 8 Mar 2022 18:42:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09CF58D0008; Tue, 8 Mar 2022 13:42:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 04C938D0001; Tue, 8 Mar 2022 13:42:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E55D18D0008; Tue, 8 Mar 2022 13:42:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id D78658D0001 for ; Tue, 8 Mar 2022 13:42:51 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 90762A32A4 for ; Tue, 8 Mar 2022 18:42:51 +0000 (UTC) X-FDA: 79222090542.28.4A35438 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf31.hostedemail.com (Postfix) with ESMTP id 364992000D for ; Tue, 8 Mar 2022 18:42:51 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id w4so23158720edc.7 for ; Tue, 08 Mar 2022 10:42:50 -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=PtUIO+KlIHnuwZcxB8rQEEiVqAu06QZDgLrU97vhKCg=; b=cgcY5LKW2TzJAfELjjvu0YRJX0cVXNV6yOUNqzYRkaYtWQEF1q1FXcSpdlHjJbunMR 0IbdURZXDS7gbD0Dqozrcw4EE0wCiRe7NhG/aY7qMDiLpEncbBRE3msFVv86nACqBYIf Xv2BbgPMeS5GkaXhGA6UU/fXBTXoXyHyEm648= 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=PtUIO+KlIHnuwZcxB8rQEEiVqAu06QZDgLrU97vhKCg=; b=CzpO4qsVlfDNpJzmn9RYMd2LV1mPe6kfyqim5k3px066fBV4i/fofCOOqRmaRgZNk7 /MHmPVR8wQ+IQYnNWs1x54ihdywSHmHmHaRYaPQeyjm8nYSr7rvH1IAYhaZBAtu2YRoa Tl2GrcUqQKYR49fAsFKsOWGfy4rXGQM0k19raBjMpQD1TAqn6aEyknmIfaTp3xUO0re+ pdrIMNpSqK6mrkoBoclgPPe3zgs30kWF0tvqmwjZ8nISCi/JxLYf0IB2SR5ILIrg7G56 INluUHP/qja8tv99o0+odUXl+q5RESXIx9s7qBvuVyKLyva5eruO54jwhAYOBtNNGIdC jjPA== X-Gm-Message-State: AOAM5327BRBXhysL2ROQew1Rfw+zJG61cDfZpcxoe3Dai3lQTpgiF8d/ lwElK7aXD7Vo8Ga81/Mv3Sx11bRY3GlulHpdkpQ= X-Google-Smtp-Source: ABdhPJzqDi/F5YSZ8/mKaKOP4+40tuoiKqLipYW22Xql8dqHs5BIRa7r7XcVb/gZXHbE2og6CocPMw== X-Received: by 2002:a05:6402:424c:b0:416:7b05:e30e with SMTP id g12-20020a056402424c00b004167b05e30emr2516055edb.290.1646764969372; Tue, 08 Mar 2022 10:42:49 -0800 (PST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id fs6-20020a170907600600b006da8ec6e4a6sm6160308ejc.26.2022.03.08.10.42.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 10:42:49 -0800 (PST) Received: by mail-wr1-f54.google.com with SMTP id i8so29955176wrr.8 for ; Tue, 08 Mar 2022 10:42:49 -0800 (PST) X-Received: by 2002:a2e:924d:0:b0:246:370c:5618 with SMTP id v13-20020a2e924d000000b00246370c5618mr11487227ljg.358.1646764958731; Tue, 08 Mar 2022 10:42:38 -0800 (PST) MIME-Version: 1.0 References: <20220308141437.144919-1-david@redhat.com> <20220308141437.144919-6-david@redhat.com> <0FFA6BBC-766F-4ABC-821A-062632632475@vmware.com> In-Reply-To: <0FFA6BBC-766F-4ABC-821A-062632632475@vmware.com> From: Linus Torvalds Date: Tue, 8 Mar 2022 10:42:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 05/15] mm/rmap: convert RMAP flags to a proper distinct rmap_t type To: Nadav Amit Cc: David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 364992000D X-Stat-Signature: a41fhf7kr4nbxe1iu5nqhwrygqx167fr X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=cgcY5LKW; dmarc=none; spf=pass (imf31.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam03 X-HE-Tag: 1646764971-33546 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 Tue, Mar 8, 2022 at 10:24 AM Nadav Amit wrote: > > I see your point regarding passing an arg. The or=E2=80=99ing of bitfield= s > can easily be resolved, unless I am missing something, with a union > that holds the aggregate value and an anonymous struct that holds > the individual flags. I think that falls under the same heading as passing them as arguments: it's certainly doable, but it requires special work that is hidden by helper macros/functions/types. I mean, even the "pass as arguments" can certainly work. It's not impossible to hide the odd syntax behind a macro, particularly if you only ever have a couple of specific cases. So you can do typedef struct rmap_flags { unsigned int exclusive:1, compound:1; } rmap_t; #define RMAP_EXCLUSIVE (rmap_t) { .exclusive =3D 1 } #define RMAP_COMPOUND (rmap_t) { .compound =3D 1 } and now you can use RMAP_EXCLUSIVE when you pass it as an argument, and in the functions themselves you can use if (flags.exclusive) {... which is certainly not unreadable. But it does mean that you basically have one syntax for testing "is this exclusive" and another for passing that value in. And you can't do RMAP_EXCLUSIVE | RMAP_COMPOUND to say "I want to pass in both exclusive and compound", but you *can* do flags.exclusive =3D 1; to set the exclusive bit. Again - that is certainly not unreadable on its own, but it's an example of how inconsistent and inconvenient the interface gets once you do anything outside of some very specific cases. And yes, you can solve these cases by simply always limiting yourself to specific syntax (in particular, just make the rule be that you can never create values out of thin air, you always have a variable that gets set. The bitfield thing does have the advantage that it ends up having very strict type checking. But in general, I'd say that the disadvantages are huge enough that you should never use a bitfield "on its own". Once it's part of a structure that you have to pass around and initialize as a structure *anyway*, then most of the problems go away. So bitfields as part of structures are fine - and we obviously use them extensively in that form. Even then they can have problems if there are any kinds of atomicity issues (ie think "page flags" or anything like that) but that's obviously a different thing, and using a union to get both ways to access things isn't out of the question. Of course, if you use unions to get "both as a bitfield and as a value" things working, you suddenly have "bit order issues", so that can be really problematic too. Bit endianness doesn't even have to follow byte endianness. End result: bitfields are actually often more complex than you think they a= re. Linus