[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240822074845.5f932d6d@kernel.org>
Date: Thu, 22 Aug 2024 07:48:45 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Bharat Bhushan <bharatb.linux@...il.com>
Cc: Bharat Bhushan <bbhushan2@...vell.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, sgoutham@...vell.com, gakula@...vell.com,
sbhatta@...vell.com, hkelam@...vell.com, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, jerinj@...vell.com,
lcherian@...vell.com, richardcochran@...il.com,
b@...a-0016f401.pphosted.com
Subject: Re: [net-next,v6 1/8] octeontx2-pf: map skb data as device
writeable
On Thu, 22 Aug 2024 09:15:43 +0530 Bharat Bhushan wrote:
> On Wed, Aug 21, 2024 at 4:06 AM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Mon, 19 Aug 2024 17:53:41 +0530 Bharat Bhushan wrote:
> > > Crypto hardware need write permission for in-place encrypt
> > > or decrypt operation on skb-data to support IPsec crypto
> > > offload. So map this memory as device read-write.
> >
> > How do you know the fragments are not read only?
>
> IOMMU permission faults will be reported if the DMA_TO_DEVICE direction flag
> is used in dma_map_page_attrs(). This is because iommu creates read only mapping
> if the DMA_TO_DEVICE direction flag is used. If the direction flag used in
> dma_map_pages() is DMA_BIDIRECTIONAL then iommu creates mapping with
> both read and write permission.
The other way around, I understand that your code makes the pages
writable for the device. What I'm concerned about is that if this
code path is fed Tx skbs you will corrupt them. Are these not Tx
skbs that you're mapping? Have you fully CoW'd them to make sure
they are writable?
Powered by blists - more mailing lists