* Re: [PATCH] cxl: Unlock on error in probe
@ 2017-05-05 7:14 ` Andrew Donnellan
0 siblings, 0 replies; 14+ messages in thread
From: Andrew Donnellan @ 2017-05-05 7:14 UTC (permalink / raw)
To: Dan Carpenter, Ian Munsie, Christophe Lombard
Cc: kernel-janitors, linuxppc-dev, Frederic Barrat
On 05/05/17 15:34, Dan Carpenter wrote:
> We should unlock if get_cxl_adapter() fails.
>
> Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter from a guest")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/misc/cxl/flash.c b/drivers/misc/cxl/flash.c
> index 7c61c70ba3f6..37475abea3e6 100644
> --- a/drivers/misc/cxl/flash.c
> +++ b/drivers/misc/cxl/flash.c
> @@ -401,8 +401,10 @@ static int device_open(struct inode *inode, struct file *file)
> if (down_interruptible(&sem) != 0)
> return -EPERM;
>
> - if (!(adapter = get_cxl_adapter(adapter_num)))
> - return -ENODEV;
> + if (!(adapter = get_cxl_adapter(adapter_num))) {
> + rc = -ENODEV;
> + goto err_unlock;
> + }
>
> file->private_data = adapter;
> continue_token = 0;
> @@ -446,6 +448,8 @@ static int device_open(struct inode *inode, struct file *file)
> free_page((unsigned long) le);
> err:
> put_device(&adapter->dev);
> +err_unlock:
> + up(&sem);
>
> return rc;
> }
sem is a global and it looks like it's intended to be held after
device_open() returns and only released in device_close(), so this looks
wrong.
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cxl: Unlock on error in probe
2017-05-05 7:14 ` Andrew Donnellan
@ 2017-05-05 7:23 ` walter harms
-1 siblings, 0 replies; 14+ messages in thread
From: walter harms @ 2017-05-05 7:23 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Dan Carpenter, Ian Munsie, Christophe Lombard, kernel-janitors,
linuxppc-dev, Frederic Barrat
Am 05.05.2017 09:14, schrieb Andrew Donnellan:
> On 05/05/17 15:34, Dan Carpenter wrote:
>> We should unlock if get_cxl_adapter() fails.
>>
>> Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter
>> from a guest")
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> diff --git a/drivers/misc/cxl/flash.c b/drivers/misc/cxl/flash.c
>> index 7c61c70ba3f6..37475abea3e6 100644
>> --- a/drivers/misc/cxl/flash.c
>> +++ b/drivers/misc/cxl/flash.c
>> @@ -401,8 +401,10 @@ static int device_open(struct inode *inode,
>> struct file *file)
>> if (down_interruptible(&sem) != 0)
>> return -EPERM;
>>
>> - if (!(adapter = get_cxl_adapter(adapter_num)))
>> - return -ENODEV;
>> + if (!(adapter = get_cxl_adapter(adapter_num))) {
>> + rc = -ENODEV;
>> + goto err_unlock;
>> + }
>>
>> file->private_data = adapter;
>> continue_token = 0;
>> @@ -446,6 +448,8 @@ static int device_open(struct inode *inode, struct
>> file *file)
>> free_page((unsigned long) le);
>> err:
>> put_device(&adapter->dev);
>> +err_unlock:
>> + up(&sem);
>>
>> return rc;
>> }
>
> sem is a global and it looks like it's intended to be held after
> device_open() returns and only released in device_close(), so this looks
> wrong.
>
the patch relates to the error path, do you expect a close() after the open() failed ?
re,
wh
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cxl: Unlock on error in probe
@ 2017-05-05 7:23 ` walter harms
0 siblings, 0 replies; 14+ messages in thread
From: walter harms @ 2017-05-05 7:23 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Dan Carpenter, Ian Munsie, Christophe Lombard, kernel-janitors,
linuxppc-dev, Frederic Barrat
Am 05.05.2017 09:14, schrieb Andrew Donnellan:
> On 05/05/17 15:34, Dan Carpenter wrote:
>> We should unlock if get_cxl_adapter() fails.
>>
>> Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter
>> from a guest")
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> diff --git a/drivers/misc/cxl/flash.c b/drivers/misc/cxl/flash.c
>> index 7c61c70ba3f6..37475abea3e6 100644
>> --- a/drivers/misc/cxl/flash.c
>> +++ b/drivers/misc/cxl/flash.c
>> @@ -401,8 +401,10 @@ static int device_open(struct inode *inode,
>> struct file *file)
>> if (down_interruptible(&sem) != 0)
>> return -EPERM;
>>
>> - if (!(adapter = get_cxl_adapter(adapter_num)))
>> - return -ENODEV;
>> + if (!(adapter = get_cxl_adapter(adapter_num))) {
>> + rc = -ENODEV;
>> + goto err_unlock;
>> + }
>>
>> file->private_data = adapter;
>> continue_token = 0;
>> @@ -446,6 +448,8 @@ static int device_open(struct inode *inode, struct
>> file *file)
>> free_page((unsigned long) le);
>> err:
>> put_device(&adapter->dev);
>> +err_unlock:
>> + up(&sem);
>>
>> return rc;
>> }
>
> sem is a global and it looks like it's intended to be held after
> device_open() returns and only released in device_close(), so this looks
> wrong.
>
the patch relates to the error path, do you expect a close() after the open() failed ?
re,
wh
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cxl: Unlock on error in probe
2017-05-05 7:23 ` walter harms
@ 2017-05-05 7:39 ` Dan Carpenter
-1 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2017-05-05 7:39 UTC (permalink / raw)
To: walter harms
Cc: Andrew Donnellan, Ian Munsie, Christophe Lombard, kernel-janitors,
linuxppc-dev, Frederic Barrat
On Fri, May 05, 2017 at 09:23:02AM +0200, walter harms wrote:
> > sem is a global and it looks like it's intended to be held after
> > device_open() returns and only released in device_close(), so this looks
> > wrong.
> >
>
> the patch relates to the error path, do you expect a close() after the open() failed ?
>
You can't close if open fails. Please don't ask rhetorical questions.
Just state everything in short sentences using simple words.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cxl: Unlock on error in probe
@ 2017-05-05 7:39 ` Dan Carpenter
0 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2017-05-05 7:39 UTC (permalink / raw)
To: walter harms
Cc: Andrew Donnellan, Ian Munsie, Christophe Lombard, kernel-janitors,
linuxppc-dev, Frederic Barrat
On Fri, May 05, 2017 at 09:23:02AM +0200, walter harms wrote:
> > sem is a global and it looks like it's intended to be held after
> > device_open() returns and only released in device_close(), so this looks
> > wrong.
> >
>
> the patch relates to the error path, do you expect a close() after the open() failed ?
>
You can't close if open fails. Please don't ask rhetorical questions.
Just state everything in short sentences using simple words.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cxl: Unlock on error in probe
2017-05-05 7:14 ` Andrew Donnellan
@ 2017-05-05 7:37 ` Dan Carpenter
-1 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2017-05-05 7:37 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Ian Munsie, Christophe Lombard, kernel-janitors, linuxppc-dev,
Frederic Barrat
On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote:
> sem is a global and it looks like it's intended to be held after
> device_open() returns and only released in device_close(), so this looks
> wrong.
>
This doesn't affect the success path, it only means that if
device_open() fails because we don't have enough free memory or whatever
then we can try again later.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cxl: Unlock on error in probe
@ 2017-05-05 7:37 ` Dan Carpenter
0 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2017-05-05 7:37 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Ian Munsie, Christophe Lombard, kernel-janitors, linuxppc-dev,
Frederic Barrat
On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote:
> sem is a global and it looks like it's intended to be held after
> device_open() returns and only released in device_close(), so this looks
> wrong.
>
This doesn't affect the success path, it only means that if
device_open() fails because we don't have enough free memory or whatever
then we can try again later.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20170505073800.4F753124037@b01ledav002.gho.pok.ibm.com>]
* Re: [PATCH] cxl: Unlock on error in probe
[not found] ` <20170505073800.4F753124037@b01ledav002.gho.pok.ibm.com>
@ 2017-05-05 7:46 ` Andrew Donnellan
0 siblings, 0 replies; 14+ messages in thread
From: Andrew Donnellan @ 2017-05-05 7:46 UTC (permalink / raw)
To: Dan Carpenter
Cc: Ian Munsie, Christophe Lombard, kernel-janitors, linuxppc-dev,
Frederic Barrat
On 05/05/17 17:37, Dan Carpenter wrote:
> On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote:
>> sem is a global and it looks like it's intended to be held after
>> device_open() returns and only released in device_close(), so this looks
>> wrong.
>>
>
> This doesn't affect the success path, it only means that if
> device_open() fails because we don't have enough free memory or whatever
> then we can try again later.
Argh, I completely missed the "return 0" above err1 and thought the
success path fell through. My mistake, that's what I get for trying to
review patches after staring at hardware simulation logs all day...
In that case, the patch looks fine to me.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cxl: Unlock on error in probe
@ 2017-05-05 7:46 ` Andrew Donnellan
0 siblings, 0 replies; 14+ messages in thread
From: Andrew Donnellan @ 2017-05-05 7:46 UTC (permalink / raw)
To: Dan Carpenter
Cc: Ian Munsie, Christophe Lombard, kernel-janitors, linuxppc-dev,
Frederic Barrat
On 05/05/17 17:37, Dan Carpenter wrote:
> On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote:
>> sem is a global and it looks like it's intended to be held after
>> device_open() returns and only released in device_close(), so this looks
>> wrong.
>>
>
> This doesn't affect the success path, it only means that if
> device_open() fails because we don't have enough free memory or whatever
> then we can try again later.
Argh, I completely missed the "return 0" above err1 and thought the
success path fell through. My mistake, that's what I get for trying to
review patches after staring at hardware simulation logs all day...
In that case, the patch looks fine to me.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 14+ messages in thread