From: kernel test robot <[email protected]>
Opportunity for min().
Generated by: scripts/coccinelle/misc/minmax.cocci
Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
CC: Denis Efremov <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: kernel test robot <[email protected]>
Signed-off-by: Julia Lawall <[email protected]>
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git for-5.12
head: cbc8ed0b4f7eeb782c153ec88d6d20bc0f0ca3a7
commit: 8636e3295ce33515c50ef728f0ff3800d97f9f44 [1/4] coccinelle: misc: add minmax script
:::::: branch date: 2 days ago
:::::: commit date: 2 weeks ago
inotify_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -382,7 +382,7 @@ static int inotify_add_to_idr(struct idr
spin_unlock(idr_lock);
idr_preload_end();
- return ret < 0 ? ret : 0;
+ return min(ret, 0);
}
static struct inotify_inode_mark *inotify_idr_find_locked(struct fsnotify_group *group,
On Tue 06-04-21 22:49:26, Julia Lawall wrote:
> From: kernel test robot <[email protected]>
>
> Opportunity for min().
>
> Generated by: scripts/coccinelle/misc/minmax.cocci
>
> Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
> CC: Denis Efremov <[email protected]>
> Reported-by: kernel test robot <[email protected]>
> Signed-off-by: kernel test robot <[email protected]>
> Signed-off-by: Julia Lawall <[email protected]>
...
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -382,7 +382,7 @@ static int inotify_add_to_idr(struct idr
>
> spin_unlock(idr_lock);
> idr_preload_end();
> - return ret < 0 ? ret : 0;
> + return min(ret, 0);
> }
Honestly, while previous expression is a standard idiom for "if 'ret' holds
an error, return it", the new expression is harder to understand for me. So
I prefer to keep things as they are in this particular case...
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Wed, 7 Apr 2021, Jan Kara wrote:
> On Tue 06-04-21 22:49:26, Julia Lawall wrote:
> > From: kernel test robot <[email protected]>
> >
> > Opportunity for min().
> >
> > Generated by: scripts/coccinelle/misc/minmax.cocci
> >
> > Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
> > CC: Denis Efremov <[email protected]>
> > Reported-by: kernel test robot <[email protected]>
> > Signed-off-by: kernel test robot <[email protected]>
> > Signed-off-by: Julia Lawall <[email protected]>
> ...
> > --- a/fs/notify/inotify/inotify_user.c
> > +++ b/fs/notify/inotify/inotify_user.c
> > @@ -382,7 +382,7 @@ static int inotify_add_to_idr(struct idr
> >
> > spin_unlock(idr_lock);
> > idr_preload_end();
> > - return ret < 0 ? ret : 0;
> > + return min(ret, 0);
> > }
>
> Honestly, while previous expression is a standard idiom for "if 'ret' holds
> an error, return it", the new expression is harder to understand for me. So
> I prefer to keep things as they are in this particular case...
OK, I had doubts about it as well, but I forwarded it because I found them
equally obscure...
Denis, maybe the semantic patch should be updated to avoid this case.
julia
On 4/7/21 8:02 PM, Julia Lawall wrote:
>
>
> On Wed, 7 Apr 2021, Jan Kara wrote:
>
>> On Tue 06-04-21 22:49:26, Julia Lawall wrote:
>>> From: kernel test robot <[email protected]>
>>>
>>> Opportunity for min().
>>>
>>> Generated by: scripts/coccinelle/misc/minmax.cocci
>>>
>>> Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
>>> CC: Denis Efremov <[email protected]>
>>> Reported-by: kernel test robot <[email protected]>
>>> Signed-off-by: kernel test robot <[email protected]>
>>> Signed-off-by: Julia Lawall <[email protected]>
>> ...
>>> --- a/fs/notify/inotify/inotify_user.c
>>> +++ b/fs/notify/inotify/inotify_user.c
>>> @@ -382,7 +382,7 @@ static int inotify_add_to_idr(struct idr
>>>
>>> spin_unlock(idr_lock);
>>> idr_preload_end();
>>> - return ret < 0 ? ret : 0;
>>> + return min(ret, 0);
>>> }
>>
>> Honestly, while previous expression is a standard idiom for "if 'ret' holds
>> an error, return it", the new expression is harder to understand for me. So
>> I prefer to keep things as they are in this particular case...
>
> OK, I had doubts about it as well, but I forwarded it because I found them
> equally obscure...
>
> Denis, maybe the semantic patch should be updated to avoid this case.
No problem, I'll send an update.
Thanks,
Denis