On 19.09.22 13:40, Akinobu Mita wrote:
2022年9月19日(月) 18:20 David Hildenbrand david@redhat.com:
On 17.09.22 09:14, Akinobu Mita wrote:
The simple attribute files do not accept a negative value since the commit 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()"), so we can no longer use DEFINE_SIMPLE_ATTRIBUTE() to define a file operations for errno value.
Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()") Reported-by: Zhao Gongyi zhaogongyi@huawei.com Signed-off-by: Akinobu Mita akinobu.mita@gmail.com
But shouldn't we fix simple_attr_write() instead?
I mean, simple_attr_read() might use attr->fmt to print a signed value, but simple_attr_write() fails on signed values now?
I might be wrong, but there is a disconnect. I feel like simple_attr_write() should similarly make decisions based on attr->fmt.
I agree there is a disconnect, but I have no idea how to fix simple_attr_write(). (strcmp(attr->fmt, "%%lld\n") is ugly) If no one seems to come up with a good idea, I'll fix the similar problems in fault-injection the same way I did here.
Maybe we simply want another interface for the handful of %lld users. Or another way to allow DEFINE_SIMPLE_ATTRIBUTE users to specify it.
Might be good enough to specify instead of/in addition to "%llu" an enum that expresses what we want.
$ git grep -C2 DEFINE_SIMPLE | grep "%"
tells me that we have
a) %llu b) %llx c) %lld d) 0x%llx e) 0x%08llx
Maybe we can adjust the debugfs cases to be more similar, to eventually get only a, b and c.