From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:55292 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726008AbeJKRnD (ORCPT ); Thu, 11 Oct 2018 13:43:03 -0400 Date: Thu, 11 Oct 2018 12:16:25 +0200 From: Jan Kara To: nixiaoming Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Amir Goldstein Subject: Re: [PATCH v3 7/8] fanotify: support reporting thread id instead of process id Message-ID: <20181011101625.GA9467@quack2.suse.cz> References: <20181003212539.2384-1-amir73il@gmail.com> <20181003212539.2384-8-amir73il@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181003212539.2384-8-amir73il@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 04-10-18 00:25:38, Amir Goldstein wrote: > In order to identify which thread triggered the event in a > multi-threaded program, add the FAN_EVENT_INFO_TID flag in fanotify_init > to opt-in for reporting the event creator's thread id information. > > Signed-off-by: nixiaoming > Signed-off-by: Amir Goldstein Just one question occurred to me (after discussion with a colleague about this feature): Ming, why do you actually need to know thread ID and thread-group ID is not enough? Also note that standard glibc threading functions are *not* going to be compatible with the ID returned from fanotify (e.g. it will be different from POSIX thread ID as returned by pthread_self()). So the feature is somewhat difficult to use from userspace... (at least you could use gettid() systemcall to get the ID of current thread but there's not glibc wrapper for it). Honza -- Jan Kara SUSE Labs, CR