Re: Detecting user data on base types
Dan Carpenter <[email protected]>
| Newsgroups | org.kernel.vger.smatch |
|---|---|
| Message-ID | <20190606094004.GX24680@kadam> |
On Wed, Jun 05, 2019 at 09:29:26AM +0100, Andrew Murray wrote:
> On Thu, May 30, 2019 at 08:46:42PM +0300, Dan Carpenter wrote:
> > Then I use the smatch_data/db/smdb.py script to figure out the warnings.
> > I should add an option so that it only shows callers which pass user
> > data. Each call site has a unique caller ID.
>
> Thanks - I hadn't looked at that script, but looks very useful.
>
> By the way with the following hunk you can, for a given function, which call sites
> pass user data.
>
> @@ -614,6 +642,7 @@ elif sys.argv[1] == "call_info":
> print_caller_info(filename, func)
> elif sys.argv[1] == "user_data":
> func = sys.argv[2]
> + filename = sys.argv[3]
> print_caller_info(filename, func, "USER_DATA")
> elif sys.argv[1] == "param_value":
> func = sys.argv[2]
>
Could you send me a normal patch with a Signed-off-by and I will apply
it? Otherwise I can handle it if you want.
> The database doesn't know that when do_mlock calls apply_vma_lock_flags the first argument of
> apply_vma_lock_flags is the first argument of do_mlock. There is no data source associated and
> our tracing of params stops early. Do you have any clue why this may be?
It's because the start variable gets modified in do_mlock():
mm/mlock.c
671 static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t flags)
^^^^^^^^^^^^^^^^^^^
672 {
673 unsigned long locked;
674 unsigned long lock_limit;
675 int error = -ENOMEM;
676
677 if (!can_do_mlock())
678 return -EPERM;
679
680 len = PAGE_ALIGN(len + (offset_in_page(start)));
681 start &= PAGE_MASK;
^^^^^^^^^^^^^^^^^^
Modified here.
I could change this behavior if you wanted. I'd record the source and
add an "[m]" or something to say that it had been modified in that
function... I'm tempted to change the "p 0" to "$0" but I would leave
the "r function" format the same for now.
regards,
dan carpenter