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 ; 21 Jan 2019 21:25:10 -0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1glh48-0007AA-Lb for speck@linutronix.de; Mon, 21 Jan 2019 22:25:08 +0100 Received: by mail-lf1-x142.google.com with SMTP id y14so16493062lfg.13 for ; Mon, 21 Jan 2019 13:25:08 -0800 (PST) References: <5fc3209d2880402d332ec93cf076467b3706a401.1547858934.git.ak@linux.intel.com> In-Reply-To: <5fc3209d2880402d332ec93cf076467b3706a401.1547858934.git.ak@linux.intel.com> From: Linus Torvalds Date: Tue, 22 Jan 2019 10:24:46 +1300 Message-ID: Subject: [MODERATED] Re: [PATCH v5 22/27] MDSv5 24 Content-Type: text/plain; charset="UTF-8" To: speck@linutronix.de List-ID: On Tue, Jan 22, 2019 at 8:57 AM speck for Andi Kleen wrote: > > Instrument some strategic skbuff functions that either touch > packet data directly, or are likely followed by a user > data touch like a memcpy, to schedule a cpu clear on next > kernel exit. I think this is crazy. We're marking things as "clear cpu state" for when we touch data that WAS VISIBLE ON THE NETWORK! That makes no sense to me. Plus is likely hurts exactly the kinds of loads that people don't want to hurt. Linus