[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1lg8t7t3o.fsf@oracle.com>
Date: Sat, 25 Aug 2018 22:35:23 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Jeffrey Lien <Jeff.Lien@....com>,
Christoph Hellwig <hch@...radead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto\@vger.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-block\@vger.kernel.org" <linux-block@...r.kernel.org>,
"linux-scsi\@vger.kernel.org" <linux-scsi@...r.kernel.org>,
"tim.c.chen\@linux.intel.com" <tim.c.chen@...ux.intel.com>,
David Darrington <david.darrington@....com>,
Jeff Furlong <jeff.furlong@....com>
Subject: Re: [PATCH] Performance Improvement in CRC16 Calculations.
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
Powered by blists - more mailing lists