From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:55914 "EHLO mx0b-00069f02.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346335AbhIMPLJ (ORCPT ); Mon, 13 Sep 2021 11:11:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=corp-2021-07-09; bh=B7pFfAWSS3sL/RELxuT0DCHJfNoa/JiGl7d88PG3ocU=; b=U5Y5AZtZFZTkWcfe9P8w7+36vXqwyQk/+PpPSt9zsbTEzTzJyJnGP4meRvM8ydCPi2df UpF1zxg9Xy4SYkvtJ7R2HPuAATKfJu2cQrfxnfe7X1nplgrxY5qb09zGLLNnTRSfFYyb 6ut1AN4+KcJ92OJU9m8T8N8vlYDLk8f+171tSMxXO1gcX2JE8XrT6u6zzKCP7+BRyiK2 8Nf9dFuuKeDB5IlalISIhbj+YxwkSMb94DhwXVFXgI40G4PvSddPktgyfe4aI3VR6fuz kfjUFx1eNufgxqjNMqCH6j2zW5xpnKztvR5MWPO2/cmZ8MqLJjoFkCgkJ69k0BbojYIf Vw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=corp-2020-01-29; bh=B7pFfAWSS3sL/RELxuT0DCHJfNoa/JiGl7d88PG3ocU=; b=vFuaP9WIo7RGN7ABf4rSolrbZEOvwHikoPpPv3zPRY5mFWda5Y3WggPUN1EB4Yx4k3BJ vGhOk5dqM7Putd+Oe7VwpmCDn5N+6C5vxYycWLxrW0qJxPNqGCpAL+CtLR61QQA6Q+sy FP9WQNCiaHE6AGONaHGfYdfP5uvKYpe3h8rXJmfVOqfL813Cjk1oKIaO/PghH3Py4fhh i/NowP5T1AiO0/zQ4qbXASZqQdacECAE+CiyQ0nNnc3CTYM2T6xRbaMflJXfh/wqfhYU GexARVfo/RT+upyF5od1HvffLbN2oF0WSDhGseTKAW0/YofBSeYJwjRcML26xhhejF1A Sw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B7pFfAWSS3sL/RELxuT0DCHJfNoa/JiGl7d88PG3ocU=; b=KpqFJtauayO98XTXyniCevKaxHJV17Lj2+K77K4GlH23EdjHWTylnfIIG75l5EZdu0pmVgDdtMTUPu5bu381xD64mPqLhktxsva417f42bitE149umXk9YNngIlFf19gcZBruzwMNnAaLQ01w/y2sg6KikaGYhfePNgkYP0m7mw= Date: Mon, 13 Sep 2021 18:09:33 +0300 From: Dan Carpenter Subject: Re: BKM on generating a call graph for smatch warnings Message-ID: <20210913150933.GL7203@kadam> References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: MIME-Version: 1.0 List-ID: To: "Reshetova, Elena" Cc: "smatch@vger.kernel.org" Hi, I'm really sorry, I missed your email. I was on vacation that week and didn't see your email until now. On Tue, Aug 17, 2021 at 07:32:21AM +0000, Reshetova, Elena wrote: > Hi, > > Quick question: are there some suggested methods for obtaining a call graph > for a warning that a smatch pattern reports when I run it for the whole kernel? > > I can see that there are a couple of existing patterns (check_capable, check_locking) > that use sql methods for saving the caller_info, but I don't fully understand how it > works, maybe there is some description somewhere on this that I missed? How the Smatch cross function database works is that you run: /path/to/smatch/smatch_scripts/build_kernel_data.sh This takes a long time to run. It does a complete Smatch run and it outputs a ton of SQL insert commands. Then it does: cat sql.txt | sqlite3 smatch_db.sqlite It doesn't literally cat that because that would be very slow. It's uses a perl script to handle transactions, caching and syncing etc. There is also a little bit of tweaking for some of the tables. The final database on my system is 30GB. What I do is I rebuild my database every night. Each time you rebuild the database then the knowledge about the call tree gets pushed out one call further. In my experience if you rebuild the DB 5-7 times, that's basically the limit. The call tree is complete, of course, right away. foo() calls bar() calls baz(). But it takes two rebuilds before the user data from foo() gets to baz(). The /path/to/smatch/smatch_data/db/smdb.py script is a way to see what's stored in the database. `smdb.py foo` will print all the callers of foo() and `smdb.py return_states foo` will show what it returns. Again, very sorry for the long delay. Please let me know if you have any questions. regards, dan carpenter