From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14935 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Petr Vorel Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] fanotify_event_info_fid incompatibility Date: Tue, 12 Nov 2019 23:01:51 +0100 Message-ID: <20191112220151.GC27331@x230> References: <20191112200520.GA13138@x230> <20191112204619.GI25646@port70.net> <20191112205831.GA27331@x230> <20191112212947.GJ25646@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123952"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.12.2 (2019-09-21) To: musl@lists.openwall.com, Rich Felker , Szabolcs Nagy Original-X-From: musl-return-14951-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 12 23:02:10 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iUeEj-000W4m-CA for gllmg-musl@m.gmane.org; Tue, 12 Nov 2019 23:02:09 +0100 Original-Received: (qmail 9615 invoked by uid 550); 12 Nov 2019 22:02:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9591 invoked from network); 12 Nov 2019 22:02:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=535o7uYa3XfPoFBoozGrmH49XVgEVluWLYnwHKmD8Sc=; b=IPIux4TvnfacnYjYgr63crQp5AHldXLjaRz6Kf0G9ffyJ12+YrKIslW8YO6WAtc5TL 00iAt4A0pg7oghh5mucChKDNbi7t07CK5KJ7mDfgV6Hu1q6g8OlSqHHB/8NDL7bMDvzl ejTkpRbvUEbB4iKcUHRSXjYImlN7LA2vtwfzey8Unk06wSpyqyVVIk6TCtJ983gED87g ctLOaNEsE8DzUKfKlOIBzF7AGcXKs5UvUYB0xtDCGM9r6vb7Xh3E9NYi5elj3Gxuvyr9 uubc+HNAxF+HRA6yYxLkyFxCE0NWUQ2/r1iHHVYqoxzvMlpL1O0f/lIViRnVvXdogoVF nL1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=535o7uYa3XfPoFBoozGrmH49XVgEVluWLYnwHKmD8Sc=; b=KQ/fBZq+gADIHcQbZQ4YCUOHyZO4P1cOOooDGtA0G1NxEFlkZSCPNb1e7hmUyZ/S1R nvgWaEBFpPKgUH8jcytYhbLtjgtnTDNE4WIaJ0Hpeg3D/VzhNydYFl9pvNgGO9RlfPRQ TX0ho9GDaQ5YLw0rjkTzoOA2k/nljejy6O9qCd8yahw7PNAWLWHDPX4EwE5Z+f3OmBd2 7sgyQ76/CA0k6SM1zfGMtHelBxlZFI58k6FZdlRGIZMNaoZOxYMdz8YH1288j8UjL/FM MAu33QXPMTKiQt13WCCzaFQ+UgMfCVtKoBByE84s291yMfM4VYYIKYl7PbKNhFMrxmpV q3Ig== X-Gm-Message-State: APjAAAXcRpIevfZUTkrY1WItXTMGctsvsxxvolGFpCA+5iiii49q/+xu VnR6cNx3rkoAZ0vF4FBDZ2j2TaZ7 X-Google-Smtp-Source: APXvYqzOUgRmJvEXSpzjrz92gh/3QSBHJ3yv95jpy7sdaejajrvmqibneXIZ6eGJ7qlnoe2DvfEmmA== X-Received: by 2002:a05:600c:2257:: with SMTP id a23mr6400792wmm.143.1573596114539; Tue, 12 Nov 2019 14:01:54 -0800 (PST) Content-Disposition: inline In-Reply-To: <20191112212947.GJ25646@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:14935 Archived-At: Hi, > > [1] https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/fanotify > this test code has internal apis like > static inline void fanotify_get_fid(const char *path, __kernel_fsid_t *fsid, > struct file_handle *handle) > which will not work if fsid has any other type than __kernel_fsid_t, > so matching the field name is not enough, you need the linux type here. Yep, that's exactly the problem. But I didn't ask to find a solution for LTP (that's not difficult), I wanted to raise the problem for musl developers to reconsider that incompatibility. The only thing I'm not sure, if any other application will want to access fsid member (searching on sources.debian.org and github.com I found only fatrace [2], but it don't touch val/__val, so probably not). > mixing linux and libc types have lot of problems, so i'd suggest to > just use linux headers instead of libc ones to test this api. > there are other solutions (like replicating the struct definitions > with different names and memcpy the api struct to that before access), > but it can't be completely clean, because there is a fundamental > conflict. (unfortunately that conflict is documented: the linux man > pages document the linux types as public api even though they don't > mix well with libc types) Yep, known problem [3]. Kind regards, Petr [2] https://sources.debian.org/src/fatrace/0.15-1/fatrace.c/?hl=149#L149 [3] https://sourceware.org/glibc/wiki/Synchronizing_Headers