The max_len is a u32 type variable so the calculation on the
left hand of the last if-condition will potentially overflow
when a cur_len gets closer to UINT_MAX -- note that there're
drivers setting max_seg_size to UINT_MAX:
drivers/dma/dw-edma/dw-edma-core.c:745:
On Fri, 2019-06-21 at 12:10 +0200, Matthias Brugger wrote:
>
> On 20/06/2019 15:59, Yong Wu wrote:
> > On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
> >>
> >> On 10/06/2019 14:17, Yong Wu wrote:
> >>> This patch only rename the variable name from enable_4GB to
> >>> dram_is_4gb for
On Thu, 2019-06-20 at 17:20 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:55, Yong Wu wrote:
> > MediaTek IOMMU has already added device_link between the consumer
> > and smi-larb device. If the jpg device call the pm_runtime_get_sync,
> > the smi-larb's pm_runtime_get_sync also be called
On Wed, 2019-06-19 at 15:52 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:55, Yong Wu wrote:
> > The iommu consumer should use device_link to connect with the
> > smi-larb(supplier). then the smi-larb should run before the iommu
> > consumer. Here we delay the iommu driver until the smi
On Fri, Jun 21, 2019 at 10:05:01PM +0200, Thomas Gleixner wrote:
> On Fri, 21 Jun 2019, Jacob Pan wrote:
> > On Fri, 21 Jun 2019 10:31:26 -0700
> > Jacob Pan wrote:
> >
> > > On Fri, 21 Jun 2019 17:33:28 +0200 (CEST)
> > > Thomas Gleixner wrote:
> > >
> > > > On Wed, 19 Jun 2019, Jacob Pan
On Fri, 21 Jun 2019, Jacob Pan wrote:
> On Fri, 21 Jun 2019 10:31:26 -0700
> Jacob Pan wrote:
>
> > On Fri, 21 Jun 2019 17:33:28 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > On Wed, 19 Jun 2019, Jacob Pan wrote:
> > > > On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
> > > > Thomas Gleixner
On Fri, 21 Jun 2019 10:31:26 -0700
Jacob Pan wrote:
> On Fri, 21 Jun 2019 17:33:28 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Wed, 19 Jun 2019, Jacob Pan wrote:
> > > On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
> > > Thomas Gleixner wrote:
> > > >
> > > > Unless this problem is not
On Wed, Jun 19, 2019 at 05:05:49PM -0400, Alan Stern wrote:
> On Wed, 19 Jun 2019, shuah wrote:
>
> > I missed a lot of the thread info. and went looking for it and found the
> > following summary of the problem:
> >
> > ==
> > The issue which prompted the commit this thread is
On Fri, 21 Jun 2019 17:33:28 +0200 (CEST)
Thomas Gleixner wrote:
> On Wed, 19 Jun 2019, Jacob Pan wrote:
> > On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
> > Thomas Gleixner wrote:
> > >
> > > Unless this problem is not solved and I doubt it can be solved
> > > after talking to IOMMU people and
On Wed, 19 Jun 2019, Jacob Pan wrote:
> On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
> Thomas Gleixner wrote:
> >
> > Unless this problem is not solved and I doubt it can be solved after
> > talking to IOMMU people and studying manuals,
>
> I agree. modify irte might be done with cmpxchg_double()
We see a use-after-free in our CI about 20% of the time on a Skylake
iommu testing host, present since enabling that host. Sadly, it has not
presented itself while running under KASAN.
<4> [302.391799] general protection fault: [#1] PREEMPT SMP PTI
<4> [302.391803] CPU: 7 PID: 4854 Comm:
Quoting Peter Xu (2019-06-21 03:32:05)
> This reverts commit 7560cc3ca7d9d11555f80c830544e463fcdb28b8.
>
> With 5.2.0-rc5 I can easily trigger this with lockdep and iommu=pt:
>
> ==
> WARNING: possible circular locking dependency
On 20/06/2019 15:59, Yong Wu wrote:
> On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
>>
>> On 10/06/2019 14:17, Yong Wu wrote:
>>> This patch only rename the variable name from enable_4GB to
>>> dram_is_4gb for readable.
>>
>> From my understanding this is true when available RAM >
Hi,
On 2019-06-20 10:50, Yoshihiro Shimoda wrote:
> This patch adds a new dma_map_ops of get_merge_boundary() to
> expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/dma-iommu.c | 11 +++
> 1 file changed,
14 matches
Mail list logo
