Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 28 Mar 2023 23:56:01 -0400
From:   Gregory Price <gregory.price@memverge.com>
To:     Oleg Nesterov <oleg@redhat.com>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        Gregory Price <gourry.memverge@gmail.com>,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Linux-Arch <linux-arch@vger.kernel.org>, avagin@gmail.com,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>, krisman@collabora.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Jonathan Corbet <corbet@lwn.net>, shuah <shuah@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>, tongtiangen@huawei.com,
        Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v14 1/4] asm-generic,arm64: create task variant of
 access_ok
Message-ID: <ZCO20bzX/IB8J6Gp@memverge.com>
References: <20230328164811.2451-1-gregory.price@memverge.com>
 <20230328164811.2451-2-gregory.price@memverge.com>
 <20230329151515.GA913@redhat.com>
 <9a456346-e207-44e1-873e-40d21334e01b@app.fastmail.com>
 <20230329160322.GA4477@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230329160322.GA4477@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XpJGz43+RC/XrbNtCF9CPCTiRrtcuw0EZb5QxSC2ZahijhZng89VKP41lgah?=
 =?us-ascii?Q?0nST0aft4SyG9g/drJn4pwmTLDWKxnorkI1zY6f2LtjOYdDMtp7w8V26f4jV?=
 =?us-ascii?Q?pZTj5OfBMU3LoPRHe+pT/SC+APAaGuKhPjrIzylvh2IGoyMOa/OqLyycRHKe?=
 =?us-ascii?Q?SnZgQgc6zPHOIKcwLPM9Rb39KCspT1VnLNyNHLUEiwJLqphr7Gfa4Xzb9dJp?=
 =?us-ascii?Q?QyyjvWtbNCJ3WR2qJyO84rI9/4RJLAZo5ew/nC9lt+xN2RBCbwNw/vTVBhDf?=
 =?us-ascii?Q?onkwzYE8I7CYltbbcJ2vSfLME90Rbsc8V594rjl6gT7IewUwu7kdqQezlPna?=
 =?us-ascii?Q?kx3kweh+LVhPgR43CoGN4d+O599cSmEv39UKItblTYu220l/mbLPvCrEuB7C?=
 =?us-ascii?Q?qb5hsfSpWAGu5GPZesDREJilnx9vj1FHNxRzreteTqg/s9UZhDosIjSwvLRu?=
 =?us-ascii?Q?uHfEWF3Lguows7fyxcW5OilK5tIi3BmLxpBUGkWlmrgQmDASLfDQqxRDYA2W?=
 =?us-ascii?Q?vKjA0JjUOJdfkeBzvTcCCtzkFp4BiAmKM8wLaL5hHIe8zhVJSmnhSFNKot+a?=
 =?us-ascii?Q?MNs1bKSYYCsyoq/l9x+TahHFV/+NnRJL59mWijBOLqnk3Mz5LvFQyW7HbN26?=
 =?us-ascii?Q?BoKVYpm2mVsmVkEDkmPKzItZi6vombtVsm5nW7ZEnRYoPSRh5TmvLGUnl7qa?=
 =?us-ascii?Q?0+3oTKeTP2s7lSaQTccc5Gj4ep3unkVZN1pLnPqN8OjrP1ycoEFFpqjGwFy1?=
 =?us-ascii?Q?trAeH0Le0xI2zRy2U+FO0VBa/hsqfqKQEJYuO4pcVMOy+FxvAb7IKoKXLggG?=
 =?us-ascii?Q?6LD+9IygEBM8HxHKH3P6MYNycuvPblj4myB2SQ9fHlBu80uGaoBXT1FxAUWU?=
 =?us-ascii?Q?LlOlx0jEVmndMPdwJiF+SpPrs8QJ3+L9tTrUiH59tvUwF63/t//t86jtv/Ch?=
 =?us-ascii?Q?MXPZ3FP/ik7ysxrop5oPsLNGEPHNA3d7Xzg69U8tPOizaU4pwmeTUDmFuk04?=
 =?us-ascii?Q?OBbKAA1vMunN+wvEEdY60O68HRqUJIpjPYZk06PIbNIQYYaZGi2HCU1Dilmy?=
 =?us-ascii?Q?NzCGXYkZ6aMbi+tjH8M476eU2n3YgRNsdQqWKj9sqpqOHmUduRgFWkyveq8A?=
 =?us-ascii?Q?02ONr7mHuOJQ3djPPQjO1AIWFb51bhhht6uylUYas4dzZu08zsif4VVyzMb8?=
 =?us-ascii?Q?Q7EGwMwB6i80JfL36Ojoo6jyPrP3l73B0HuUUd1S0v24BSpvFxwf09+zTPBZ?=
 =?us-ascii?Q?27pSJkRuRvKNRIwdw/JUd14l5nbQMTJtynZOYCCbsI1wsjplJ+x8kXQknK1G?=
 =?us-ascii?Q?XcP+mdbJUPrsvypztEl2SVxvjUNu8KE+mCGrAZEz83IQGsadQB8NmzrTeekz?=
 =?us-ascii?Q?BmWR7Gu4YfkbX/cXq5md9Iy9H75yJlJ7kRvTaY3t7ZXRWCCuCiNT0zxagyRB?=
 =?us-ascii?Q?v9fN3GGmXlkjSNWkFmnss1Z8iuf9B1EPCStdQsXJ/HnVMGK7Abwd9qkU8cgZ?=
 =?us-ascii?Q?cjWAquKdWD46e+5N7MU8VsGzghG1luIBKM3NMwnjF21bxZCM2BvsXZaC2BUL?=
 =?us-ascii?Q?puD42UsNhcqeLu0fzjRcv5XvW+q64AjagOo9FvHNSUXCfGHjrapkcwERU502?=
 =?us-ascii?Q?pw=3D=3D?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14bd1650-30ac-44d3-1cd2-08db307086d3
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2023 16:13:26.2100
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: d8/0VY0+ZBse6U3Ld3wQx4shLX73gPKolis39IT/T9BOR1mScYjwZE//LAl1LGmjxEnK55JvGTBNu+aN9hlFVOTPcwASkpQeySRmDiXT7IQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR17MB4600
X-Spam-Status: No, score=0.6 required=5.0 tests=DATE_IN_PAST_12_24,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Mar 29, 2023 at 06:03:23PM +0200, Oleg Nesterov wrote:
> On 03/29, Arnd Bergmann wrote:
> >
> > On Wed, Mar 29, 2023, at 17:15, Oleg Nesterov wrote:
> > >
> > > This look as if access_ok() or __access_ok() doesn't depend on task, but
> > > this is not true in general. Say, TASK_SIZE_MAX can check is_32bit_task()
> > > test_thread_flag(TIF_32BIT...) and this uses "current".
> > >
> > > Again, we probably do not care, but I don't like the fact task_access_ok()
> > > looks as if task_access_ok(task) returns the same result as "task" calling
> > > access_ok().
> >
> > I think the idea of TASK_SIZE_MAX is that it is a compile-time constant and in fact independent of current, while TASK_SIZE
> > takes TIF_32BIT into account.
> 
> Say, arch/loongarch defines TASK_SIZE which depends on test_thread_flag(TIF_32BIT_ADDR)
> but it doesn't define TASK_SIZE_MAX, so __access_ok() will use TASK_SIZE.
> 
> Oleg.
> 

I did not notice this at first.  Thinking of solutions, I'd originally
considered writing a similar change in asm-generic that I made in arm64,
but that would have ultimately resulted in "(void) task;" because task
appears unused.

Now it seems like TASK_SIZE/_MAX seems like a dangerous define
combination that hides relevant functionality. Fixing this seeems to
naturally want a "TASK_TASK_SIZE(task)" which is... uh... annoying.

Not sure how I should proceed here, but this makes me wonder if there
are oversights like this elsewhere, as this seems like a pretty easy
thing to overlook.

~Gregory