From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761404AbdAINTD convert rfc822-to-8bit (ORCPT ); Mon, 9 Jan 2017 08:19:03 -0500 Received: from smtp-out6.electric.net ([192.162.217.186]:56347 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S940297AbdAINSR (ORCPT ); Mon, 9 Jan 2017 08:18:17 -0500 From: David Laight To: "'Eric Biggers'" , David Miller CC: "Jason@zx2c4.com" , "jeanphilippe.aumasson@gmail.com" , "gregkh@linuxfoundation.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ak@linux.intel.com" , "tom@herbertland.com" , "hannes@stressinduktion.org" , "eric.dumazet@gmail.com" , "luto@kernel.org" Subject: RE: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5 Thread-Topic: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5 Thread-Index: AQHSaPQeK1lCwyB2YUm4r2ZJTTpVGaEtip0AgAAI04CAAo5sEA== Date: Mon, 9 Jan 2017 13:18:09 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB025AC4D@AcuExch.aculab.com> References: <20170107144057.15432-1-Jason@zx2c4.com> <20170107144057.15432-4-Jason@zx2c4.com> <20170107.163736.2224609477435674963.davem@davemloft.net> <20170107220911.GB8327@zzz> In-Reply-To: <20170107220911.GB8327@zzz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Biggers > Sent: 07 January 2017 22:09 .. > Out of curiosity, is this actually a solvable problem, e.g. by making the code > using the XMM registers responsible for saving and restoring the ones clobbered, > or by optimizing kernel_fpu_begin()/kernel_fpu_end()? Or does it in fact remain > impractical for such instructions to be used for applications like this one? I think it should be possible to fast-save a couple of FP registers by telling the IPI save code where to save them from (to load into a different cpu). But there might be issues with other parts of the FP state. This might be ok provided the kernel doesn't actually use FP instructions. (I thought about this when adding AVX support to NetBSD.) David