Powered by Linux
Re: Tracking Implicit Dependencies — Semantic Matching Tool

Re: Tracking Implicit Dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 29, 2017 at 03:23:56PM -0400, Andrew Zhu Aday wrote:
> Hi Smatch,
> 
> I ran across a bug: when running  `~/smatch/smatch_scripts/kchecker mm/msync.c`,
> I noticed that FUNCTION_CALL_HOOK and CONDITION_HOOK are not actually
> called within the body msync. Some other syscalls I looked at seem to
> work correctly.
> 
> Do you know why this is the case? Is there a simple fix?

They're definitely called.  I don't know how you're testing...

A lot of the function calls are not recorded in the DB because those
functions are too common.  So if we were trying to parse down_read()
and we looked up all the callers it would take a minute do just merge
all the data.  I don't mind changing it to record the function call and
adding a different flag somewhere that actually don't look up the
caller_info when we're parsing the function itself.

$ echo "select * from caller_info where caller = 'SYSC_msync';" | sqlite3 smatch_db.sqlite
mm/msync.c|SYSC_msync|get_file|110807|1|0|-1||struct file*(*)(struct file*)
mm/msync.c|SYSC_msync|get_file|110807|1|1001|0|$|s64min-(-1),1-s64max
mm/msync.c|SYSC_msync|vfs_fsync_range|110808|0|0|-1||int(*)(struct file*, llong, llong, int)
mm/msync.c|SYSC_msync|vfs_fsync_range|110808|0|1001|0|$|s64min-(-1),1-s64max
mm/msync.c|SYSC_msync|vfs_fsync_range|110808|0|1001|3|$|1

regards,
dan carpenter


--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux