[LTP] [PATCH] save_restore: Check whether path is writable

Martin Doucha mdoucha@suse.cz
Wed Oct 26 15:27:56 CEST 2022


On 26. 10. 22 13:29, Jan Stancek wrote:
> On Tue, Oct 25, 2022 at 6:13 PM Martin Doucha <mdoucha@suse.cz> wrote:
>> It does affect all 3 but slightly differently, depending on the "val"
>> field of the respective .save_restore item. The current implementation
>> behaves like this without root privileges:
>> - (no prefix): If val is NULL, the test will save the data, run the test
>> and trigger TWARN at the end.
> 
> Is this real scenario? Why is test saving sysfs value, which is then
> never changed?
> I would expect that in this case, you could drop save_restore entirely.

Some tests use simplified sysfile handling and only write a string 
constant passed in the .save_restore array. These have problem with lack 
of root privileges because the write happens in library code. Other 
tests write something non-constant in setup() or run(), these can handle 
read-only sysfiles themselves.

> The case 2) looks like it could apply to non-optional paths too. So maybe
> best option would be to drop "!" and "?" prefixes and turn them into flags/enums
> which can be then combined together.
> 
> "/proc/sys/kernel/pid_max", 0, val // TCONF if path doesn't exist
> "/proc/sys/kernel/pid_max", SR_MUST_EXIST, val // TBROK if path doesn't exist
> "/proc/sys/kernel/pid_max", SR_MAY_EXIST, val // if exists, save it
> "/proc/sys/kernel/pid_max", SR_CONST_VAL, val // if already has val,
> skip saving it
> "/proc/sys/kernel/pid_max", SR_MAY_EXIST | SR_CONST_VAL, val // if
> exists check it already has val, otherwise save it
> 
> What do you think? Would that make it easier to represent/implement all cases?

Sounds good, I'll prepare a patchset for that.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic



More information about the ltp mailing list