From: "Martin K. Petersen" Subject: Re: [PATCH] Performance Improvement in CRC16 Calculations. Date: Sat, 25 Aug 2018 22:35:23 -0400 Message-ID: References: <1533928331-21303-1-git-send-email-jeff.lien@wdc.com> <20180822062016.GA10356@infradead.org> <20180825061205.ygrjjazkooqghrqy@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain Cc: "Martin K. Petersen" , Ard Biesheuvel , Jeffrey Lien , Christoph Hellwig , "linux-kernel\@vger.kernel.org" , "linux-crypto\@vger.kernel.org" , "linux-block\@vger.kernel.org" , "linux-scsi\@vger.kernel.org" , "tim.c.chen\@linux.intel.com" , David Darrington , Jeff Furlong To: Herbert Xu Return-path: In-Reply-To: <20180825061205.ygrjjazkooqghrqy@gondor.apana.org.au> (Herbert Xu's message of "Sat, 25 Aug 2018 14:12:05 +0800") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org Herbert, > I don't think this is safe unless you do some kind of locking > which would slow down the data path. The easiest fix would be > to keep the old tfm around forever, or use RCU if RCU read locking > is acceptable to your use-case. You're right. There's a small race there. Patch series coming... -- Martin K. Petersen Oracle Linux Engineering