[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Yang Xu]

Currently, running this case will report EINVAL error if I run "ulimit -c
1023" command firstly. From setrlimit(2)manpage, it got EINVAL error because
rlim->rlim_cur was greater than rlim->rlim_max. So add a check for it before
setrlimit.

Reported-by: Pankaj Vinadrao Joshi <Pankaj.VJ@exaleapsemi.com>
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
---
 testcases/kernel/syscalls/kill/kill11.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/testcases/kernel/syscalls/kill/kill11.c b/testcases/kernel/syscalls/kill/kill11.c
index 83fba5beb..5f70b0a07 100644
--- a/testcases/kernel/syscalls/kill/kill11.c
+++ b/testcases/kernel/syscalls/kill/kill11.c
@@ -201,6 +201,9 @@ void setup(void)
 
 	SAFE_GETRLIMIT(NULL, RLIMIT_CORE, &rlim);
 
+	if (rlim.rlim_max < MIN_RLIMIT_CORE)
+		tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
+				rlim.rlim_max, MIN_RLIMIT_CORE);
 	if (rlim.rlim_cur < MIN_RLIMIT_CORE) {
 		tst_resm(TINFO, "Adjusting RLIMIT_CORE to %i", MIN_RLIMIT_CORE);
 		rlim.rlim_cur = MIN_RLIMIT_CORE;
-- 
2.18.0

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Xiao Yang]

On 2020/2/12 13:44, Yang Xu wrote:
> Currently, running this case will report EINVAL error if I run "ulimit -c
> 1023" command firstly. From setrlimit(2)manpage, it got EINVAL error because
> rlim->rlim_cur was greater than rlim->rlim_max. So add a check for it before
> setrlimit.
Hi Xu,

It seems better to fix the issue by setting both rlim_cur and rlimit_max 
to the MIN_RLIMIT_CORE.

Thanks,
Xiao Yang
> Reported-by: Pankaj Vinadrao Joshi<Pankaj.VJ@exaleapsemi.com>
> Signed-off-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
> ---
>   testcases/kernel/syscalls/kill/kill11.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/testcases/kernel/syscalls/kill/kill11.c b/testcases/kernel/syscalls/kill/kill11.c
> index 83fba5beb..5f70b0a07 100644
> --- a/testcases/kernel/syscalls/kill/kill11.c
> +++ b/testcases/kernel/syscalls/kill/kill11.c
> @@ -201,6 +201,9 @@ void setup(void)
>
>   	SAFE_GETRLIMIT(NULL, RLIMIT_CORE,&rlim);
>
> +	if (rlim.rlim_max<  MIN_RLIMIT_CORE)
> +		tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
> +				rlim.rlim_max, MIN_RLIMIT_CORE);
>   	if (rlim.rlim_cur<  MIN_RLIMIT_CORE) {
>   		tst_resm(TINFO, "Adjusting RLIMIT_CORE to %i", MIN_RLIMIT_CORE);
>   		rlim.rlim_cur = MIN_RLIMIT_CORE;

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Yang Xu]

on 2020/02/12 14:11, Xiao Yang wrote:
> On 2020/2/12 13:44, Yang Xu wrote:
>> Currently, running this case will report EINVAL error if I run "ulimit -c
>> 1023" command firstly. From setrlimit(2)manpage, it got EINVAL error 
>> because
>> rlim->rlim_cur was greater than rlim->rlim_max. So add a check for it 
>> before
>> setrlimit.
> Hi Xu,
> 
> It seems better to fix the issue by setting both rlim_cur and rlimit_max 
> to the MIN_RLIMIT_CORE.
> We can not raise rlim_max value under unprivileged user. Or, should I 
cleanup this case and use needs_root=1 ?

Best Regards
Yang Xu
> Thanks,
> Xiao Yang
>> Reported-by: Pankaj Vinadrao Joshi<Pankaj.VJ@exaleapsemi.com>
>> Signed-off-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
>> ---
>> ? testcases/kernel/syscalls/kill/kill11.c | 3 +++
>> ? 1 file changed, 3 insertions(+)
>>
>> diff --git a/testcases/kernel/syscalls/kill/kill11.c 
>> b/testcases/kernel/syscalls/kill/kill11.c
>> index 83fba5beb..5f70b0a07 100644
>> --- a/testcases/kernel/syscalls/kill/kill11.c
>> +++ b/testcases/kernel/syscalls/kill/kill11.c
>> @@ -201,6 +201,9 @@ void setup(void)
>>
>> ????? SAFE_GETRLIMIT(NULL, RLIMIT_CORE,&rlim);
>>
>> +??? if (rlim.rlim_max<? MIN_RLIMIT_CORE)
>> +??????? tst_brkm(TCONF, NULL, "hard limit(%lu)less than 
>> MIN_RLIMT_CORE(%i)",
>> +??????????????? rlim.rlim_max, MIN_RLIMIT_CORE);
>> ????? if (rlim.rlim_cur<? MIN_RLIMIT_CORE) {
>> ????????? tst_resm(TINFO, "Adjusting RLIMIT_CORE to %i", 
>> MIN_RLIMIT_CORE);
>> ????????? rlim.rlim_cur = MIN_RLIMIT_CORE;
> 

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Jan Stancek]

----- Original Message -----
> Currently, running this case will report EINVAL error if I run "ulimit -c
> 1023" command firstly. From setrlimit(2)manpage, it got EINVAL error because
> rlim->rlim_cur was greater than rlim->rlim_max. So add a check for it before
> setrlimit.
> 
> Reported-by: Pankaj Vinadrao Joshi <Pankaj.VJ@exaleapsemi.com>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> ---
>  testcases/kernel/syscalls/kill/kill11.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/testcases/kernel/syscalls/kill/kill11.c
> b/testcases/kernel/syscalls/kill/kill11.c
> index 83fba5beb..5f70b0a07 100644
> --- a/testcases/kernel/syscalls/kill/kill11.c
> +++ b/testcases/kernel/syscalls/kill/kill11.c
> @@ -201,6 +201,9 @@ void setup(void)
>  
>  	SAFE_GETRLIMIT(NULL, RLIMIT_CORE, &rlim);
>  
> +	if (rlim.rlim_max < MIN_RLIMIT_CORE)
> +		tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
> +				rlim.rlim_max, MIN_RLIMIT_CORE);

This looks OK, but could we also raise the limit when possible?


+       if (rlim.rlim_max < MIN_RLIMIT_CORE) {
+               if (geteuid() != 0) {
+                       tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
+                               rlim.rlim_max, MIN_RLIMIT_CORE);
+               }
+               tst_resm(TINFO, "Raising rlim_max to %i", MIN_RLIMIT_CORE);
+               rlim.rlim_max = MIN_RLIMIT_CORE;
+       }

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Yang Xu]

on 2020/02/12 21:32, Jan Stancek wrote:
> 
> 
> ----- Original Message -----
>> Currently, running this case will report EINVAL error if I run "ulimit -c
>> 1023" command firstly. From setrlimit(2)manpage, it got EINVAL error because
>> rlim->rlim_cur was greater than rlim->rlim_max. So add a check for it before
>> setrlimit.
>>
>> Reported-by: Pankaj Vinadrao Joshi <Pankaj.VJ@exaleapsemi.com>
>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
>> ---
>>   testcases/kernel/syscalls/kill/kill11.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/testcases/kernel/syscalls/kill/kill11.c
>> b/testcases/kernel/syscalls/kill/kill11.c
>> index 83fba5beb..5f70b0a07 100644
>> --- a/testcases/kernel/syscalls/kill/kill11.c
>> +++ b/testcases/kernel/syscalls/kill/kill11.c
>> @@ -201,6 +201,9 @@ void setup(void)
>>   
>>   	SAFE_GETRLIMIT(NULL, RLIMIT_CORE, &rlim);
>>   
>> +	if (rlim.rlim_max < MIN_RLIMIT_CORE)
>> +		tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
>> +				rlim.rlim_max, MIN_RLIMIT_CORE);
> 
> This looks OK, but could we also raise the limit when possible?
> 
Of course. Your way is more wise.
But I also want to change this size of MIN_RLIMIT_CORE.
 From ulimit manpage, I know in posix mode "-c" used 512-byte block. I 
doubt whether we can change MIN_RLIMIT_CORE(512 *1024), so this case
can also pass in unbuntu(default environment).
What do you think about this?

ps: I tested it on el7,el8, they all pass.

> 
> +       if (rlim.rlim_max < MIN_RLIMIT_CORE) {
> +               if (geteuid() != 0) {
> +                       tst_brkm(TCONF, NULL, "hard limit(%lu)less than MIN_RLIMT_CORE(%i)",
> +                               rlim.rlim_max, MIN_RLIMIT_CORE);
> +               }
> +               tst_resm(TINFO, "Raising rlim_max to %i", MIN_RLIMIT_CORE);
> +               rlim.rlim_max = MIN_RLIMIT_CORE;
> +       }
> 
> 
> 

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Jan Stancek]

----- Original Message -----
> > This looks OK, but could we also raise the limit when possible?
> > 
> Of course. Your way is more wise.
> But I also want to change this size of MIN_RLIMIT_CORE.
>  From ulimit manpage, I know in posix mode "-c" used 512-byte block. I
> doubt whether we can change MIN_RLIMIT_CORE(512 *1024), so this case
> can also pass in unbuntu(default environment).
> What do you think about this?

I don't see problem with that, we only check for correct signal.
Though it probably should be separate patch. Can you re-post
both as 2 patch series?

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Yang Xu]

on 2020/02/13 16:35, Jan Stancek wrote:
> 
> 
> ----- Original Message -----
>>> This looks OK, but could we also raise the limit when possible?
>>>
>> Of course. Your way is more wise.
>> But I also want to change this size of MIN_RLIMIT_CORE.
>>   From ulimit manpage, I know in posix mode "-c" used 512-byte block. I
>> doubt whether we can change MIN_RLIMIT_CORE(512 *1024), so this case
>> can also pass in unbuntu(default environment).
>> What do you think about this?
> 
> I don't see problem with that, we only check for correct signal.
> Though it probably should be separate patch. Can you re-post
> both as 2 patch series?
Hi Jan
  I perfer to cleanup this case to use new API and also include this two 
points.

Best Regard
Yang Xu
> 
> 
> 

[LTP] [PATCH] syscalls/kill11: add a check between hard limit and MIN_RLIMIT_CORE

[Yang Xu]

on 2020/02/13 16:41, Yang Xu wrote:
> 
> 
> on 2020/02/13 16:35, Jan Stancek wrote:
>>
>>
>> ----- Original Message -----
>>>> This looks OK, but could we also raise the limit when possible?
>>>>
>>> Of course. Your way is more wise.
>>> But I also want to change this size of MIN_RLIMIT_CORE.
>>> ? From ulimit manpage, I know in posix mode "-c" used 512-byte block. I
>>> doubt whether we can change MIN_RLIMIT_CORE(512 *1024), so this case
>>> can also pass in unbuntu(default environment).
>>> What do you think about this?
>>
>> I don't see problem with that, we only check for correct signal.
>> Though it probably should be separate patch. Can you re-post
>> both as 2 patch series?
Hi Jan
Since abort01 has the same issue, I will send a patch series as you 
advise, and then cleanup kill11 when I have free time.

Best Regargd
Yang Xu
> Hi Jan
>  ?I perfer to cleanup this case to use new API and also include this two 
> points.
> 
> Best Regard
> Yang Xu
>>
>>
>>
> 
> 
>