Re: md5sum (from libkcapi) fails as splice() returns -ENOKEY

[Stephan Müller]

Am Montag, 11. September 2017, 19:07:31 CEST schrieb christophe leroy:

Hi christophe,

> Hello Stephan,
> 
> I'm trying to use md5sum from the latest libkcapi 0.14 and I getting a
> failure with return code -5.
> 
> What am I missing ? See strace below, splice() return -ENOKEY.

The ENOKEY error is due to an accept() at the wrong location. But I do not see 
that error:

tar xvfJ libkcapi-0.14.0.tar.xz
cd libkcapi-0.14.0
autoreconf -i
./configure --enable-kcapi-hasher
make
cd bin/.libs/ # I make no make install for testing
ln kcapi-hasher md5sum # create md5sum app
export LD_LIBRARY_PATH=../../.libs/ # location of current library

$ ./md5sum md5sum 
ddd1a82680b16fb6c241d81656b844df  md5sum

So, it works for me.

Can you please check whether you use the current library version? Note, 
library version 0.10.1 fixed the aforementioned accept() call for kernel 4.4 
and later.

$ ./md5sum -v
md5sum: libkcapi 0.14.0

Ciao
Stephan

Re: [Outreachy kernel] [PATCH v2] Staging: ccree: Remove unused variable monitor_lock

[Gilad Ben-Yossef]

On Mon, Sep 11, 2017 at 7:36 PM, Sean Paul  wrote:
> On Mon, Sep 11, 2017 at 12:28 PM, Srishti Sharma  
> wrote:
>> Remove the variable monitor_lock as it is not used anywhere.
>>
>> Signed-off-by: Srishti Sharma 
>
> Reviewed-by: Sean Paul 

That variable is a left-over I've missed when I deleted an implementation of
something that was almost, but not quite, entirely unlike perf and is
no longer used.

So, assuming it compiles fine (I'm away from my build infrastructure
at the moment):

Acked-by: Gilad Ben-Yossef 

Thank you,
Gilad

>
>> ---
>> Changes in v2:
>>  -The variable that was not to be declared as volatile can be
>>   eliminated as it is not being used anywhere.
>>
>>  drivers/staging/ccree/ssi_request_mgr.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
>> b/drivers/staging/ccree/ssi_request_mgr.c
>> index e5c2f92..b94a91f 100644
>> --- a/drivers/staging/ccree/ssi_request_mgr.c
>> +++ b/drivers/staging/ccree/ssi_request_mgr.c
>> @@ -49,7 +49,6 @@ struct ssi_request_mgr_handle {
>> dma_addr_t dummy_comp_buff_dma;
>> struct cc_hw_desc monitor_desc;
>>
>> -   volatile unsigned long monitor_lock;
>>  #ifdef COMP_IN_WQ
>> struct workqueue_struct *workq;
>> struct delayed_work compwork;
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/1505147317-13411-1-git-send-email-srishtishar%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

md5sum (from libkcapi) fails as splice() returns -ENOKEY

[christophe leroy]

Hello Stephan,

I'm trying to use md5sum from the latest libkcapi 0.14 and I getting a 
failure with return code -5.


What am I missing ? See strace below, splice() return -ENOKEY.

Christophe

execve("./md5sum", ["./md5sum", "kcapi.tar"], [/* 11 vars */]) = 0
brk(0)  = 0x10024000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/ppc823/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/tls/ppc823", 0x7ffa2328) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/tls", 0x7ffa2328)  = -1 ENOENT (No such file or directory)
open("/usr/lib/ppc823/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/ppc823", 0x7ffa2328)   = -1 ENOENT (No such file or directory)
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=3568, ...}) = 0
open("/lib/tls/ppc823/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
stat64("/lib/tls/ppc823", 0x7ffa2328)   = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
stat64("/lib/tls", 0x7ffa2328)  = -1 ENOENT (No such file or directory)
open("/lib/ppc823/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
stat64("/lib/ppc823", 0x7ffa2328)   = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\2\35\\\0\0\0004"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1797540, ...}) = 0
mmap(0xfe58000, 1661856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xfe58000
mprotect(0xffc8000, 114688, PROT_NONE)  = 0
mmap(0xffe4000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17c000) = 0xffe4000
mmap(0xffec000, 7072, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffec000
close(3)= 0
mprotect(0xffe4000, 16384, PROT_READ)   = 0
mprotect(0x1001c000, 16384, PROT_READ)  = 0
mprotect(0x779f8000, 16384, PROT_READ)  = 0
brk(0)  = 0x10024000
brk(0x10048000) = 0x10048000
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "0\n", 1024)= 2
close(3)= 0
socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
pipe([4, 5])= 0
socket(PF_NETLINK, SOCK_RAW, 21)= 6
bind(6, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(6, {sa_family=AF_NETLINK, pid=266, groups=}, [12]) = 0
sendmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=}, 
msg_iov(1)=[{"\0\0\0\340\0\23\0\1\0;\232\247\0\0\0\0md5\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
 224}], msg_controllen=0, msg_flags=0}, 0) = 224
recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=}, 
msg_iov(1)=[{"\0\0\0014\0\23\0\0\0;\232\247\0\0\1\nmd5\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
 4096}], msg_controllen=0, msg_flags=0}, 0) = 308
close(6)= 0
open("kcapi.tar", O_RDONLY|O_CLOEXEC)   = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=378880, ...}) = 0
mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x7795c000
accept(3, 0, NULL)  = 7
vmsplice(5, 
[{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 378880}], 
1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144
splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not 
available)
write(2, "Generation of hash for file kcap"..., 50) = 50
munmap(0x7795c000, 378880)  = 0
close(6)= 0
close(3)= 0
close(7)= 0
close(4)= 0
close(5)= 0
exit_group(-5)  = ?
+++ exited with 251 +++


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: [PATCH v2] Staging: ccree: Prefer using BIT macro.

[Srishti Sharma]

On Mon, Sep 11, 2017 at 9:54 PM, Greg KH  wrote:
> On Thu, Sep 07, 2017 at 07:44:52PM +0530, Srishti Sharma wrote:
>> Use BIT(x) instead of using (1<>
>> Signed-off-by: Srishti Sharma 
>> ---
>> Changes in v2:
>>  - Add tab spaces before BIT macro.
>>
>>  drivers/staging/ccree/ssi_cipher.h | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> This change is already in my tree from someone else, sorry.
Oh.. It's okay !

Thanks,
Srishti
>
> greg k-h

Re: [Outreachy kernel] [PATCH v2] Staging: ccree: Remove unused variable monitor_lock

[Sean Paul]

On Mon, Sep 11, 2017 at 12:28 PM, Srishti Sharma  wrote:
> Remove the variable monitor_lock as it is not used anywhere.
>
> Signed-off-by: Srishti Sharma 

Reviewed-by: Sean Paul 

> ---
> Changes in v2:
>  -The variable that was not to be declared as volatile can be
>   eliminated as it is not being used anywhere.
>
>  drivers/staging/ccree/ssi_request_mgr.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
> b/drivers/staging/ccree/ssi_request_mgr.c
> index e5c2f92..b94a91f 100644
> --- a/drivers/staging/ccree/ssi_request_mgr.c
> +++ b/drivers/staging/ccree/ssi_request_mgr.c
> @@ -49,7 +49,6 @@ struct ssi_request_mgr_handle {
> dma_addr_t dummy_comp_buff_dma;
> struct cc_hw_desc monitor_desc;
>
> -   volatile unsigned long monitor_lock;
>  #ifdef COMP_IN_WQ
> struct workqueue_struct *workq;
> struct delayed_work compwork;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505147317-13411-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [Outreachy kernel] Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Srishti Sharma]

On Mon, Sep 11, 2017 at 9:45 PM, Srishti Sharma  wrote:
> On Mon, Sep 11, 2017 at 9:41 PM, Julia Lawall  wrote:
>>
>>
>> On Mon, 11 Sep 2017, Srishti Sharma wrote:
>>
>>> On Mon, Sep 11, 2017 at 9:34 PM, Greg KH  wrote:
>>> > On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
>>> >> The use of volatile for the variable monitor_lock is unnecessary.
>>> >>
>>> >> Signed-off-by: Srishti Sharma 
>>> >> ---
>>> >>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
>>> >> b/drivers/staging/ccree/ssi_request_mgr.c
>>> >> index e5c2f92..7d77941 100644
>>> >> --- a/drivers/staging/ccree/ssi_request_mgr.c
>>> >> +++ b/drivers/staging/ccree/ssi_request_mgr.c
>>> >> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>>> >>   dma_addr_t dummy_comp_buff_dma;
>>> >>   struct cc_hw_desc monitor_desc;
>>> >>
>>> >> - volatile unsigned long monitor_lock;
>>> >> + unsigned long monitor_lock;
>>> >
>>> > While volatile is not right, odds are, this is still totally wrong as
>>> > well.  How about using a "real" lock instead?
>>>
>>> I tried to find where is this variable being used in the code, but I
>>> didn't find any usage of it . It might be an important attribute of
>>> this structure definition but, I don't see it's value being set to
>>> anything or being used somewhere .
>>
>> Try removing it and see if the code still compiles.  There is always a
>> danger that a use of something could be constructed using ## in a macro,
>> although given the uses of ## for this driver, it doesn't seem likely
>> here.

It compiles, so I have removed the variable and sent another patch

Thanks,
Srishti

>
> Yes, I'll do that.
>
> Regards,
> Srishti
>>
>> julia

[PATCH v2] Staging: ccree: Remove unused variable monitor_lock

[Srishti Sharma]

Remove the variable monitor_lock as it is not used anywhere.

Signed-off-by: Srishti Sharma 
---
Changes in v2:
 -The variable that was not to be declared as volatile can be
  eliminated as it is not being used anywhere.

 drivers/staging/ccree/ssi_request_mgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index e5c2f92..b94a91f 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -49,7 +49,6 @@ struct ssi_request_mgr_handle {
dma_addr_t dummy_comp_buff_dma;
struct cc_hw_desc monitor_desc;

-   volatile unsigned long monitor_lock;
 #ifdef COMP_IN_WQ
struct workqueue_struct *workq;
struct delayed_work compwork;
--
2.7.4

Re: [PATCH] staging: ccree: Add missing newlines

[Greg Kroah-Hartman]

On Sat, Sep 09, 2017 at 11:18:02PM -0700, Joe Perches wrote:
> Logging without newlines are still prone to interleaving.
> Add newlines where necessary.

Doesn't apply to my staging-testing branch, due to other changes in this
driver.  Can you rebase it onto that branch and resend?

thanks,

greg k-h

Re: [PATCH v2] Staging: ccree: Prefer using BIT macro.

[Greg KH]

On Thu, Sep 07, 2017 at 07:44:52PM +0530, Srishti Sharma wrote:
> Use BIT(x) instead of using (1< 
> Signed-off-by: Srishti Sharma 
> ---
> Changes in v2:
>  - Add tab spaces before BIT macro.
> 
>  drivers/staging/ccree/ssi_cipher.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

This change is already in my tree from someone else, sorry.

greg k-h

Re: [Outreachy kernel] Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Srishti Sharma]

On Mon, Sep 11, 2017 at 9:41 PM, Julia Lawall  wrote:
>
>
> On Mon, 11 Sep 2017, Srishti Sharma wrote:
>
>> On Mon, Sep 11, 2017 at 9:34 PM, Greg KH  wrote:
>> > On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
>> >> The use of volatile for the variable monitor_lock is unnecessary.
>> >>
>> >> Signed-off-by: Srishti Sharma 
>> >> ---
>> >>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
>> >> b/drivers/staging/ccree/ssi_request_mgr.c
>> >> index e5c2f92..7d77941 100644
>> >> --- a/drivers/staging/ccree/ssi_request_mgr.c
>> >> +++ b/drivers/staging/ccree/ssi_request_mgr.c
>> >> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>> >>   dma_addr_t dummy_comp_buff_dma;
>> >>   struct cc_hw_desc monitor_desc;
>> >>
>> >> - volatile unsigned long monitor_lock;
>> >> + unsigned long monitor_lock;
>> >
>> > While volatile is not right, odds are, this is still totally wrong as
>> > well.  How about using a "real" lock instead?
>>
>> I tried to find where is this variable being used in the code, but I
>> didn't find any usage of it . It might be an important attribute of
>> this structure definition but, I don't see it's value being set to
>> anything or being used somewhere .
>
> Try removing it and see if the code still compiles.  There is always a
> danger that a use of something could be constructed using ## in a macro,
> although given the uses of ## for this driver, it doesn't seem likely
> here.

Yes, I'll do that.

Regards,
Srishti
>
> julia

Re: [Outreachy kernel] Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Julia Lawall]

On Mon, 11 Sep 2017, Srishti Sharma wrote:

> On Mon, Sep 11, 2017 at 9:34 PM, Greg KH  wrote:
> > On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
> >> The use of volatile for the variable monitor_lock is unnecessary.
> >>
> >> Signed-off-by: Srishti Sharma 
> >> ---
> >>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
> >> b/drivers/staging/ccree/ssi_request_mgr.c
> >> index e5c2f92..7d77941 100644
> >> --- a/drivers/staging/ccree/ssi_request_mgr.c
> >> +++ b/drivers/staging/ccree/ssi_request_mgr.c
> >> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
> >>   dma_addr_t dummy_comp_buff_dma;
> >>   struct cc_hw_desc monitor_desc;
> >>
> >> - volatile unsigned long monitor_lock;
> >> + unsigned long monitor_lock;
> >
> > While volatile is not right, odds are, this is still totally wrong as
> > well.  How about using a "real" lock instead?
>
> I tried to find where is this variable being used in the code, but I
> didn't find any usage of it . It might be an important attribute of
> this structure definition but, I don't see it's value being set to
> anything or being used somewhere .

Try removing it and see if the code still compiles.  There is always a
danger that a use of something could be constructed using ## in a macro,
although given the uses of ## for this driver, it doesn't seem likely
here.

julia

Re: [Outreachy kernel] Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Sean Paul]

On Mon, Sep 11, 2017 at 12:08 PM, Srishti Sharma  wrote:
> On Mon, Sep 11, 2017 at 9:34 PM, Greg KH  wrote:
>> On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
>>> The use of volatile for the variable monitor_lock is unnecessary.
>>>
>>> Signed-off-by: Srishti Sharma 
>>> ---
>>>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
>>> b/drivers/staging/ccree/ssi_request_mgr.c
>>> index e5c2f92..7d77941 100644
>>> --- a/drivers/staging/ccree/ssi_request_mgr.c
>>> +++ b/drivers/staging/ccree/ssi_request_mgr.c
>>> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>>>   dma_addr_t dummy_comp_buff_dma;
>>>   struct cc_hw_desc monitor_desc;
>>>
>>> - volatile unsigned long monitor_lock;
>>> + unsigned long monitor_lock;
>>
>> While volatile is not right, odds are, this is still totally wrong as
>> well.  How about using a "real" lock instead?
>
> I tried to find where is this variable being used in the code, but I
> didn't find any usage of it . It might be an important attribute of
> this structure definition but, I don't see it's value being set to
> anything or being used somewhere .
>

AFAICT, it's not used. Your patch should just remove it instead :)

Sean

> Regards,
> Srishti
>>
>> thanks,
>>
>> greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/CAB3L5oxcyhgyy8EuGuPo9QtJQd-W7JTgQQE1PfopZFmSx58P9g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Srishti Sharma]

On Mon, Sep 11, 2017 at 9:34 PM, Greg KH  wrote:
> On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
>> The use of volatile for the variable monitor_lock is unnecessary.
>>
>> Signed-off-by: Srishti Sharma 
>> ---
>>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
>> b/drivers/staging/ccree/ssi_request_mgr.c
>> index e5c2f92..7d77941 100644
>> --- a/drivers/staging/ccree/ssi_request_mgr.c
>> +++ b/drivers/staging/ccree/ssi_request_mgr.c
>> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>>   dma_addr_t dummy_comp_buff_dma;
>>   struct cc_hw_desc monitor_desc;
>>
>> - volatile unsigned long monitor_lock;
>> + unsigned long monitor_lock;
>
> While volatile is not right, odds are, this is still totally wrong as
> well.  How about using a "real" lock instead?

I tried to find where is this variable being used in the code, but I
didn't find any usage of it . It might be an important attribute of
this structure definition but, I don't see it's value being set to
anything or being used somewhere .

Regards,
Srishti
>
> thanks,
>
> greg k-h

Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Greg KH]

On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
> The use of volatile for the variable monitor_lock is unnecessary.
> 
> Signed-off-by: Srishti Sharma 
> ---
>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
> b/drivers/staging/ccree/ssi_request_mgr.c
> index e5c2f92..7d77941 100644
> --- a/drivers/staging/ccree/ssi_request_mgr.c
> +++ b/drivers/staging/ccree/ssi_request_mgr.c
> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>   dma_addr_t dummy_comp_buff_dma;
>   struct cc_hw_desc monitor_desc;
> 
> - volatile unsigned long monitor_lock;
> + unsigned long monitor_lock;

While volatile is not right, odds are, this is still totally wrong as
well.  How about using a "real" lock instead?

thanks,

greg k-h

Re: [Outreachy kernel] [PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Julia Lawall]

On Mon, 11 Sep 2017, Srishti Sharma wrote:

> The use of volatile for the variable monitor_lock is unnecessary.

You need to give more evidence of why this is the case.  How is the
variable used?  I guess this comes from checkpatch, but checkpatch has
only a local view of things, and doesn't know how the variable is used.

julia

>
> Signed-off-by: Srishti Sharma 
> ---
>  drivers/staging/ccree/ssi_request_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
> b/drivers/staging/ccree/ssi_request_mgr.c
> index e5c2f92..7d77941 100644
> --- a/drivers/staging/ccree/ssi_request_mgr.c
> +++ b/drivers/staging/ccree/ssi_request_mgr.c
> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
>   dma_addr_t dummy_comp_buff_dma;
>   struct cc_hw_desc monitor_desc;
>
> - volatile unsigned long monitor_lock;
> + unsigned long monitor_lock;
>  #ifdef COMP_IN_WQ
>   struct workqueue_struct *workq;
>   struct delayed_work compwork;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505145571-11248-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[PATCH] Staging: ccree: Don't use volatile for monitor_lock

[Srishti Sharma]

The use of volatile for the variable monitor_lock is unnecessary.

Signed-off-by: Srishti Sharma 
---
 drivers/staging/ccree/ssi_request_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index e5c2f92..7d77941 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
dma_addr_t dummy_comp_buff_dma;
struct cc_hw_desc monitor_desc;

-   volatile unsigned long monitor_lock;
+   unsigned long monitor_lock;
 #ifdef COMP_IN_WQ
struct workqueue_struct *workq;
struct delayed_work compwork;
--
2.7.4