On Fri, May 28, 2021 at 03:09:28PM +0000, Justin He wrote:
> > I'm not sure why it's so complicated. p->len records how many bytes
> > are needed for the entire path; can't you just return -p->len ?
>
> prepend_name() will return at the beginning if p->len is <0 in this case,
> we can't even get the correct full path size if keep __prepend_path unchanged.
> We need another new helper __prepend_path_size() to get the full path size
> regardless of the negative value p->len.
It's a little hard to follow, based on just the patches. Is there a
git tree somewhere of Al's patches that you're based on?
Seems to me that prepend_name() is just fine because it updates p->len
before returning false:
static bool prepend_name(struct prepend_buffer *p, const struct qstr *name)
{
const char *dname = smp_load_acquire(&name->name); /* ^^^ */
u32 dlen = READ_ONCE(name->len);
char *s;
p->len -= dlen + 1;
if (unlikely(p->len < 0))
return false;
I think the only change you'd need to make for vsnprintf() is in
prepend_path():
- if (!prepend_name(&b, &dentry->d_name))
- break;
+ prepend_name(&b, &dentry->d_name);
Would that hurt anything else?
> More than that, even the 1st vsnprintf could have _end_ > _buf_ in some case:
> What if printk("%pD", filp) ? The 1st vsnprintf has positive (end-buf).
I don't understand the problem ... if p->len is positive, then you
succeeded. if p->len is negative then -p->len is the expected return
value from vsnprintf(). No?
