Messages in this thread | | | Date | Fri, 28 May 2021 16:22:16 +0100 | From | Matthew Wilcox <> | Subject | Re: [PATCH RFCv2 2/3] lib/vsprintf.c: make %pD print full path for file |
| |
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?
| |