Messages in this thread | | | Subject | Re: BUG: bad usercopy in memdup_user | From | Laura Abbott <> | Date | Tue, 19 Dec 2017 14:24:08 -0800 |
| |
On 12/19/2017 01:36 PM, Linus Torvalds wrote: > On Tue, Dec 19, 2017 at 5:22 AM, Matthew Wilcox <willy@infradead.org> wrote: >> >> Could we have a way to know that the printed address is hashed and not just >> a pointer getting completely scrogged? Perhaps prefix it with ... a hash! >> So this line would look like: > > The problem with that is that it will break tools that parse things. > > So no, it won't work. > > When we find something like this, we should either remove it, fix the > permissions, or switch to %px. > > In this case, there's obviously no permission issue: it's an error > report. So it's either "remove it, or switch to %px". > > I'm personally not clear on whether the pointer really makes any sense > at all. But if it does, it should just be changed to %px, since it's a > bug report. > > But honestly, what do people expect that the pointer value will > actually tell you if it is unhashed? > > I suspect that an "offset and size within the kernel object" value > might make sense. But what does the _pointer_ tell you? > > I've noticed this with pretty much every report. People get upset > about the hashing, but don't seem to actually be able to ever tell > what the f*ck they would use the non-hashed pointer value for. > > I've asked for this before: whenever somebody complains about the > hashing, you had better tell exactly what the unhashed value would > have given you, and how it would have helped debug the problem. > > Because if you can't tell that, then dammit, then we should just > _remove_ the stupid %p. > > Instead, people ask for "can I get everything unhashed" even when they > can't give a reason for it. > > Linus >
It's most useful in the "I really have no idea what's going on" case. Sometimes just narrowing down if a pointer was kernel or vmalloc or kmap or whatever is the only starting point. I agree that size plus offset from object would be helpful.
Thanks, Laura
| |