All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
To: Pranith Kumar
	<bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Pranith Kumar <pranith-/4noJB3qBVQ3uPMLIKxrzw@public.gmane.org>,
	dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/1] use documented cmpxchg api
Date: Fri, 06 Jun 2014 06:55:32 -0400	[thread overview]
Message-ID: <53919E24.3010206@hurleysoftware.com> (raw)
In-Reply-To: <5391136C.3010809-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 06/05/2014 09:03 PM, Pranith Kumar wrote:
> On 06/05/2014 08:34 PM, Peter Hurley wrote:
>> On 06/05/2014 06:19 PM, Pranith Kumar wrote:
>>> use the documented atomic_cmpxchg instead of __cmpxchg64
>>>
>>> This kills the last user of said API in drivers code.
>>>
>>>
>>> Signed-off-by: Pranith Kumar <bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>>    drivers/iommu/intel-iommu.c |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>>> index 6bb3277..270113f 100644
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte)
>>>        return pte->val & VTD_PAGE_MASK;
>>>    #else
>>>        /* Must have a full atomic 64-bit read */
>>> -    return  __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>>> +    return  atomic_cmpxchg(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>>
>> This is not equivalent.
>>
>> The __cmpxchg64() is specifically being used in this case
>> when !CONFIG_64BIT for a full 64-bit RMW, whereas atomic_cmpxchg()
>> uses ints which would be 32-bit RMW.
>>
>
>
> You are right! The previous patch is wrong in that atomic_cmpxchg needs an atomic_t argument.
> cmpxchg() handles the size internally using typeof() to figure out the width of RMW.
> There is also an explicit cmpxchg64() which does the same thing.


This won't work either, and should generate a compile or link error
on CONFIG_X86_32.

The auto-sizing done by __cmpxchg() does not substitute the cmpxchg8b
instruction for the cmpxchg instruction. __X86_CASE_Q is defined as -1 for
CONFIG_X86_32 so the 8-byte size variant is dead-code, and calls
__cmpxchg_wrong_size() instead.


> Fixed with the following v2:
>
> use the documented cmpxchg instead of __cmpxchg64
>
> This kills the last user of said API in drivers code.
>
> Signed-off-by: Pranith Kumar <bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>   drivers/iommu/intel-iommu.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 6bb3277..270113f 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte)
>   	return pte->val & VTD_PAGE_MASK;
>   #else
>   	/* Must have a full atomic 64-bit read */
> -	return  __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
> +	return  cmpxchg(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>   #endif
>   }

WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com>
To: Pranith Kumar <bobby.prani@gmail.com>,
	Pranith Kumar <pranith@gatech.edu>,
	dwmw2@infradead.org, joro@8bytes.org
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] use documented cmpxchg api
Date: Fri, 06 Jun 2014 06:55:32 -0400	[thread overview]
Message-ID: <53919E24.3010206@hurleysoftware.com> (raw)
In-Reply-To: <5391136C.3010809@gmail.com>

On 06/05/2014 09:03 PM, Pranith Kumar wrote:
> On 06/05/2014 08:34 PM, Peter Hurley wrote:
>> On 06/05/2014 06:19 PM, Pranith Kumar wrote:
>>> use the documented atomic_cmpxchg instead of __cmpxchg64
>>>
>>> This kills the last user of said API in drivers code.
>>>
>>>
>>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
>>> ---
>>>    drivers/iommu/intel-iommu.c |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>>> index 6bb3277..270113f 100644
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte)
>>>        return pte->val & VTD_PAGE_MASK;
>>>    #else
>>>        /* Must have a full atomic 64-bit read */
>>> -    return  __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>>> +    return  atomic_cmpxchg(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>>
>> This is not equivalent.
>>
>> The __cmpxchg64() is specifically being used in this case
>> when !CONFIG_64BIT for a full 64-bit RMW, whereas atomic_cmpxchg()
>> uses ints which would be 32-bit RMW.
>>
>
>
> You are right! The previous patch is wrong in that atomic_cmpxchg needs an atomic_t argument.
> cmpxchg() handles the size internally using typeof() to figure out the width of RMW.
> There is also an explicit cmpxchg64() which does the same thing.


This won't work either, and should generate a compile or link error
on CONFIG_X86_32.

The auto-sizing done by __cmpxchg() does not substitute the cmpxchg8b
instruction for the cmpxchg instruction. __X86_CASE_Q is defined as -1 for
CONFIG_X86_32 so the 8-byte size variant is dead-code, and calls
__cmpxchg_wrong_size() instead.


> Fixed with the following v2:
>
> use the documented cmpxchg instead of __cmpxchg64
>
> This kills the last user of said API in drivers code.
>
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> ---
>   drivers/iommu/intel-iommu.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 6bb3277..270113f 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte)
>   	return pte->val & VTD_PAGE_MASK;
>   #else
>   	/* Must have a full atomic 64-bit read */
> -	return  __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
> +	return  cmpxchg(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
>   #endif
>   }



  parent reply	other threads:[~2014-06-06 10:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 22:19 [PATCH 1/1] use documented cmpxchg api Pranith Kumar
2014-06-06  0:34 ` Peter Hurley
2014-06-06  1:03   ` Pranith Kumar
     [not found]     ` <5391136C.3010809-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-06 10:55       ` Peter Hurley [this message]
2014-06-06 10:55         ` Peter Hurley
     [not found]         ` <53919E24.3010206-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
2014-06-06 14:27           ` Pranith Kumar
2014-06-06 14:27             ` Pranith Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53919E24.3010206@hurleysoftware.com \
    --to=peter-wagbzjegnqdsbiue7sb01tbpr1lh4cv8@public.gmane.org \
    --cc=bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pranith-/4noJB3qBVQ3uPMLIKxrzw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.