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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29403C433F5 for ; Mon, 27 Sep 2021 09:26:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E5C36103B for ; Mon, 27 Sep 2021 09:26:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233656AbhI0J2L convert rfc822-to-8bit (ORCPT ); Mon, 27 Sep 2021 05:28:11 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.85.151]:42651 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233650AbhI0J2I (ORCPT ); Mon, 27 Sep 2021 05:28:08 -0400 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-4-3AuGKXHNP3yOOjk_BFzmyA-1; Mon, 27 Sep 2021 10:26:28 +0100 X-MC-Unique: 3AuGKXHNP3yOOjk_BFzmyA-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 27 Sep 2021 10:16:17 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.023; Mon, 27 Sep 2021 10:16:17 +0100 From: David Laight To: 'Mark Rutland' , Kees Cook CC: Vito Caputo , Jann Horn , "Thomas Gleixner" , Josh Poimboeuf , "Ingo Molnar" , Borislav Petkov , "H. Peter Anvin" , Jens Axboe , Peter Zijlstra , Stefan Metzmacher , Andy Lutomirski , Lai Jiangshan , Christian Brauner , Andrew Morton , "Kenta.Tada@sony.com" , Daniel Bristot de Oliveira , =?iso-8859-1?Q?Michael_Wei=DF?= , Anand K Mistry , Alexey Gladkov , Michal Hocko , "Helge Deller" , Dave Hansen , "Andrea Righi" , Ohhoon Kwon , Kalesh Singh , YiFei Zhu , "Eric W. Biederman" , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-hardening@vger.kernel.org" Subject: RE: [PATCH] proc: Disable /proc/$pid/wchan Thread-Topic: [PATCH] proc: Disable /proc/$pid/wchan Thread-Index: AQHXsUu6q24nweQ620C+j1L7pwAX2Ku3nV0w Date: Mon, 27 Sep 2021 09:16:17 +0000 Message-ID: <19928a006302450a89b17e7f9b9e4848@AcuMS.aculab.com> References: <20210923233105.4045080-1-keescook@chromium.org> <20210923234917.pqrxwoq7yqnvfpwu@shells.gnugeneration.com> <20210924002230.sijoedia65hf5bj7@shells.gnugeneration.com> <202109231814.FD09DBAD3@keescook> <20210924135424.GA33573@C02TD0UTHF1T.local> In-Reply-To: <20210924135424.GA33573@C02TD0UTHF1T.local> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland > Sent: 24 September 2021 14:54 > > On Thu, Sep 23, 2021 at 06:16:16PM -0700, Kees Cook wrote: > > On Thu, Sep 23, 2021 at 05:22:30PM -0700, Vito Caputo wrote: > > > Instead of unwinding stacks maybe the kernel should be sticking an > > > entrypoint address in the current task struct for get_wchan() to > > > access, whenever userspace enters the kernel? > > > > wchan is supposed to show where the kernel is at the instant the > > get_wchan() happens. (i.e. recording it at syscall entry would just > > always show syscall entry.) > > It's supposed to show where a blocked task is blocked; the "wait > channel". > > I'd wanted to remove get_wchan since it requires cross-task stack > walking, which is generally painful. > > We could instead have the scheduler entrypoints snapshot their caller > into a field in task_struct. If there are sufficiently few callers, that > could be an inline wrapper that passes a __func__ string. Otherwise, we > still need to symbolize. It ought to be something stashed in the 'wait_queue_head'. Perhaps defaulting to the address/name of the function that initialised it. That would be much nearer the original (pre Linux) semantics. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)