From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 25 Feb 2019 15:52:50 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyIYj-0000fz-4B for speck@linutronix.de; Mon, 25 Feb 2019 16:52:49 +0100 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D43430014CC for ; Mon, 25 Feb 2019 15:52:42 +0000 (UTC) Received: from tonnant.bos.jonmasters.org (ovpn-123-18.rdu2.redhat.com [10.10.123.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03B8F19C65 for ; Mon, 25 Feb 2019 15:52:41 +0000 (UTC) References: <8d04705a73208de4bb4a4062bf3d977b5ee5c5f4.1551019522.git.ak@linux.intel.com> <20190225151935.GA19947@kroah.com> <20190225153411.GO16922@tassilo.jf.intel.com> <20190225154935.GA17057@kroah.com> From: Jon Masters Message-ID: <81d31cd3-5e8f-5cbd-7aa1-0e92394b2950@redhat.com> Date: Mon, 25 Feb 2019 10:52:30 -0500 MIME-Version: 1.0 In-Reply-To: <20190225154935.GA17057@kroah.com> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="1ukgOL6KP8AivuiqHyDpyyKRIU9kjKd4G"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --1ukgOL6KP8AivuiqHyDpyyKRIU9kjKd4G Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Jon Masters To: speck for Greg KH Subject: Re: [PATCH v6 31/43] MDSv6 --1ukgOL6KP8AivuiqHyDpyyKRIU9kjKd4G Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/25/19 10:49 AM, speck for Greg KH wrote: > On Mon, Feb 25, 2019 at 07:34:11AM -0800, speck for Andi Kleen wrote: >> However I will probably not be able to write a detailed >> description for each of the interrupt handlers changed because >> there are just too many. >=20 > Then how do you expect each subsystem / driver author to know if this i= s > an acceptable change or not? How do you expect to educate driver > authors to have them determine if they need to do this on their new > drivers or not? Are you going to hand-audit each new driver that gets > added to the kernel for forever? >=20 > Without this type of information, this seems like a futile exercise. Forgive me if I'm being too cautious here, but it seems to make most sense to have the basic MDS infrastructure in place at unembargo. Unless it's very clear how the auto stuff can be safe, and the audit comprehensive, I wonder if that shouldn't just be done after. Jon. --=20 Computer Architect | Sent with my Fedora powered laptop --1ukgOL6KP8AivuiqHyDpyyKRIU9kjKd4G--