On Thu, Jun 06, 2019 at 01:15:09PM +0300, Dan Carpenter wrote: > On Wed, Jun 05, 2019 at 01:28:41PM +0100, Andrew Murray wrote: > > Actually it looks there is logic associated to get_user in handle_get_user within > > smatch_kernel_user_data.c - however this doesn't seem to trigger in the following (it looks > > like it does something with the return value of the macro, but this is just an error flag): > > > > do_pages_move -calls-> add_page_for_migration - the second argument of > > add_page_for_migration 'addr' comes from get_user - but it isn't marked as USER_DATA in > > the database. I don't understand why this is. > > > > That's weird. It's working for me. > > mm/migrate.c | do_pages_move | add_page_for_migration | USER_DATA | 1 | addr | 0-u64max > > Btw, I pushed the fix for untagged_addr() and my DB was built with that > fix. You could try see if that makes a difference, I guess? > > kchecker --info mm/migrate.c > info.txt > ~/path/to/smatch/smatch_data/db/reload_partial.sh info.txt I still don't see it. I'll investigate further. (I'm running the tools on x86_64, cross building for ARM64 - I'll share some patches in due course for cross-compilation). Thanks, Andrew Murray > > regards, > dan carpenter
