Julien Grall writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
> On 04/11/2021 09:18, Michal Orzel wrote:
> > On 01.11.2021 21:51, Stefano Stabellini wrote:
> >> On Mon, 1 Nov 2021, Ian Jackson wrote:
> >>> It sounds like this
On 04/11/2021 09:18, Michal Orzel wrote:
Hello,
Hi Michal,
On 01.11.2021 21:51, Stefano Stabellini wrote:
On Mon, 1 Nov 2021, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
In regards to this specific
Hello,
On 01.11.2021 21:51, Stefano Stabellini wrote:
> On Mon, 1 Nov 2021, Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu
>> master list with a lock"):
>>> In regards to this specific patch and also the conversati
On Mon, 1 Nov 2021, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu
> master list with a lock"):
> > In regards to this specific patch and also the conversation about 4.16
> > or 4.17: I think it would be fine to ta
Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master
list with a lock"):
> In regards to this specific patch and also the conversation about 4.16
> or 4.17: I think it would be fine to take this patch in 4.16 in its
> current form. Although it is n
Hi,
> On 28 Oct 2021, at 21:31, Stefano Stabellini wrote:
>
> On Thu, 28 Oct 2021, Julien Grall wrote:
>> Hi Stefano,
>>
>> First apologies for sending the previous e-mails in HTML (thanks for pointing
>> that out!).
>>
>> On 28/10/2021 01:20, Stefano Stabellini wrote:
>>> On Thu, 28 Oct 2021,
On Thu, 28 Oct 2021, Julien Grall wrote:
> Hi Stefano,
>
> First apologies for sending the previous e-mails in HTML (thanks for pointing
> that out!).
>
> On 28/10/2021 01:20, Stefano Stabellini wrote:
> > On Thu, 28 Oct 2021, Julien Grall wrote:
> > > On Thu, 28 Oct 2021, 00:14 Stefano Stabellin
Julien Grall writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
> Right. PCI passthrough is not going to work in 4.16 whether this patch
> is merged or not. We are past the code freeze and as you said the code
> (and potentially the locking) is g
On 28/10/2021 13:15, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 28.10.2021 12:05, Julien Grall wrote:
The purpose of this patch is to fix the issue that is present in 4.16.
I think this is a latent bug (see more below).
The patch adding support for removal you are reffering to:
-is i
Hi Julien,
On 28.10.2021 12:05, Julien Grall wrote:
> Hi Stefano,
>
> First apologies for sending the previous e-mails in HTML (thanks for pointing
> that out!).
>
> On 28/10/2021 01:20, Stefano Stabellini wrote:
>> On Thu, 28 Oct 2021, Julien Grall wrote:
>>> On Thu, 28 Oct 2021, 00:14 Stefano
Hi Julien,
On 27.10.2021 19:02, Julien Grall wrote:
>
>
> On 27/10/2021 11:41, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 26.10.2021 18:56, Julien Grall wrote:
>>> Hi,
>>>
>>> On 26/10/2021 17:28, Julien Grall wrote:
On 26/10/2021 13:29, Michal Orzel wrote:
> If a device
Hi Stefano,
First apologies for sending the previous e-mails in HTML (thanks for
pointing that out!).
On 28/10/2021 01:20, Stefano Stabellini wrote:
On Thu, 28 Oct 2021, Julien Grall wrote:
On Thu, 28 Oct 2021, 00:14 Stefano Stabellini, wrote:
On Wed, 27 Oct 2021, Julien Grall wrote:
On Thu, 28 Oct 2021, Julien Grall wrote:
> On Thu, 28 Oct 2021, 00:14 Stefano Stabellini, wrote:
> On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > > + return ret;
> > > > > > }
> > > > > > static int register_smmu_master(struct arm_smmu_device
> *smmu,
>
On Thu, 28 Oct 2021, 00:43 Julien Grall, wrote:
>
>
> On Thu, 28 Oct 2021, 00:14 Stefano Stabellini,
> wrote:
>
>> On Wed, 27 Oct 2021, Julien Grall wrote:
>> > > > > > +return ret;
>> > > > > >}
>> > > > > >static int register_smmu_master(struct arm_smmu_device *smmu,
>> > > > > > @
On Thu, 28 Oct 2021, 00:14 Stefano Stabellini,
wrote:
> On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > > +return ret;
> > > > > >}
> > > > > >static int register_smmu_master(struct arm_smmu_device *smmu,
> > > > > > @@ -2056,7 +2066,10 @@ static int arm_smmu_add_device(struct
> de
On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > + return ret;
> > > > > }
> > > > > static int register_smmu_master(struct arm_smmu_device *smmu,
> > > > > @@ -2056,7 +2066,10 @@ static int arm_smmu_add_device(struct device
> > > > > *dev)
> > > > > } else {
> > > > >
On 27/10/2021 11:41, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 26.10.2021 18:56, Julien Grall wrote:
Hi,
On 26/10/2021 17:28, Julien Grall wrote:
On 26/10/2021 13:29, Michal Orzel wrote:
If a device is added to SMMUv1/v2 from DT and PCI
at the same time, there is a concurrent access
Hi Julien,
On 26.10.2021 18:56, Julien Grall wrote:
> Hi,
>
> On 26/10/2021 17:28, Julien Grall wrote:
>> On 26/10/2021 13:29, Michal Orzel wrote:
>>> If a device is added to SMMUv1/v2 from DT and PCI
>>> at the same time, there is a concurrent access
>>> to a smmu master list. This could lead to
Hi,
On 26/10/2021 17:28, Julien Grall wrote:
On 26/10/2021 13:29, Michal Orzel wrote:
If a device is added to SMMUv1/v2 from DT and PCI
at the same time, there is a concurrent access
to a smmu master list. This could lead to a
scenario where one is looking into a list that
is being modified at
Hi Michal,
On 26/10/2021 13:29, Michal Orzel wrote:
If a device is added to SMMUv1/v2 from DT and PCI
at the same time, there is a concurrent access
to a smmu master list. This could lead to a
scenario where one is looking into a list that
is being modified at the same time. Add a lock
to preven
If a device is added to SMMUv1/v2 from DT and PCI
at the same time, there is a concurrent access
to a smmu master list. This could lead to a
scenario where one is looking into a list that
is being modified at the same time. Add a lock
to prevent this issue.
Reuse the existing spinlock arm_smmu_dev
21 matches
Mail list logo
