From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by sourceware.org (Postfix) with ESMTPS id A8A0C385842C for ; Wed, 8 Sep 2021 14:21:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8A0C385842C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodji@seketeli.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id ACAADC001F; Wed, 8 Sep 2021 14:21:24 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 5E707580018; Wed, 1 Sep 2021 10:53:04 +0200 (CEST) From: Dodji Seketeli To: Matthias Maennich Cc: libabigail@sourceware.org, gprocida@google.com, kernel-team@android.com Subject: Re: [PATCH] tools-utils: Do not skip symbolic links when analyzing a linux tree In-Reply-To: <20210824213012.2486940-1-maennich@google.com> (Matthias Maennich's message of "Tue, 24 Aug 2021 22:30:12 +0100") Organization: Me, myself and I References: <20210824213012.2486940-1-maennich@google.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) X-Operating-System: Fedora 36 X-URL: http://www.seketeli.net/~dodji Date: Wed, 01 Sep 2021 10:53:04 +0200 Message-ID: <8735qohe33.fsf@seketeli.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DATE_IN_PAST_96_XX, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 14:21:28 -0000 Hello Matthias, Matthias Maennich a =C3=A9crit: > For various reasons, (parts of) a linux kernel tree containing vmlinux > and kernel modules might be organized using symbolic links. One reason > is that those binaries physically reside on a different storage and are > linked into place. To support such scenarios by allowing to traverse > symbolic links when discovering linux kernel binaries. > > I could not see a reason why this was disabled in the first place. > Ignoring symbolic links had been the default since the inception of the > kernel mode. Following symbolic link is disabled because there can be cases where the link points to a directory of the kernel tree, causing cycles in the tree. In that case, fts_read can return the same file several times. I seem to remember that it had noticeable performance impacts on the tests I did with our kernels. So to support symbolic link, we'd need to properly handle (avoid?) those cycles, probably by taking into account the FTS_DC bit of the FTSENT::fts_info data member. I haven't looked into it in details, though. Have you seen the same think in those cases? Thanks. [...] --=20 Dodji