[{"id":25992,"web_url":"https://patchwork.libcamera.org/comment/25992/","msgid":"<Y4pfC9RgjozcEfu+@pendragon.ideasonboard.com>","date":"2022-12-02T20:24:43","subject":"Re: [libcamera-devel] [PATCH 1/2] libcamera: utils: Wrap usage of\n\tlockf()","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Jacopo,\n\nThank you for the patch.\n\nOn Fri, Dec 02, 2022 at 05:41:44PM +0100, Jacopo Mondi via libcamera-devel wrote:\n> The lockf() function is not implemented in the Bionic standard C\n> library.\n> \n> As an alternative, since Linux v2.0 the flock() function is available\n> as a direct system call instead of being emulated in the C library.\n> \n> As lockf() is instead usually implemented as an interface to fcntl()\n> locking, locks placed by flock() and lockf() might not be detected.\n> \n> As reported by the flock() function documentation:\n> \n> Since kernel 2.0, flock() is implemented as a system call in its own right\n> rather than being emulated in the GNU C library as a call to fcntl(2).\n> With this implementation, there is no interaction between the types of\n> lock placed by  flock()  and  fc‐ ntl(2), and flock() does not detect\n> deadlock.  (Note, however, that on some systems, such as the modern\n> BSDs, flock() and fc‐ ntl(2) locks do interact with one another.)\n\nWrong text rewrap, you end up with double spaces and \"fc- ntl\"\n\n> To avoid risks of undetected deadlock, provide an wrapper function\n> utils, which in case flock() is not available, deflects all calls to\n> lockf() instead.\n\nThe patch doesn't match the commit message. I think I'd rather go for a\nfunction in the utils namespace, to make sure we will never mix flock()\nand lock(), and to group all code related to compatibility with\ndifferent libc versions in a single place.\n\n> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>\n> ---\n>  src/libcamera/media_device.cpp | 28 ++++++++++++++++++++++++++++\n>  1 file changed, 28 insertions(+)\n> \n> diff --git a/src/libcamera/media_device.cpp b/src/libcamera/media_device.cpp\n> index 52c8e66e9e99..bffb241efa7c 100644\n> --- a/src/libcamera/media_device.cpp\n> +++ b/src/libcamera/media_device.cpp\n> @@ -20,6 +20,34 @@\n>  \n>  #include <libcamera/base/log.h>\n>  \n> +/*\n> + * Android NDK workaround.\n> + *\n> + * Bionic does not implement the lockf function before API release 24.\n> + * If we're building for a recent enough Android release include the\n> + * correct header, if we're building for an older release, deflect\n> + * flock() on the lockf() system call.\n> + *\n> + * A note on flock()/lockf() co-existency: it would be easier to change\n> + * all usages of lockf() in libcamera to flock(). However lockf() is\n> + * implemented as an interface on fcntl() while flock() is a system call\n> + * since Linux v2.0. Locks set with lockf() won't be detected by flock()\n> + * and vice-versa, hence mixing the two is highly undesirable. For this\n> + * reason if lockf() is available prefer it, assuming all other\n> + * applications in the system will do the same. Only deflect on flock()\n> + * as last resort and only on Android systems.\n> + */\n> +#if __ANDROID_API__ >= 24\n> +\t#include <bits/lockf.h>\n\nfcntl.h includes bits/lockf.h when __USE_GNU or __USE_BSD is defined,\nwhich I think is the case. Is this thus needed, as we include fcntl.h at\nthe beginning of this file ?\n\n> +#elif defined(__ANDROID_API__)\n> +\t#undef F_TLOCK\n> +\t#undef F_ULOCK\n> +\t#include <sys/file.h>\n> +\t#define F_TLOCK (LOCK_EX | LOCK_NB)\n> +\t#define F_ULOCK LOCK_UN\n> +\t#define lockf(f, c, o) flock(f, c)\n> +#endif\n> +\n>  /**\n>   * \\file media_device.h\n>   * \\brief Provide a representation of a Linux kernel Media Controller device","headers":{"Return-Path":"<libcamera-devel-bounces@lists.libcamera.org>","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 03A46BDE6B\n\tfor <parsemail@patchwork.libcamera.org>;\n\tFri,  2 Dec 2022 20:24:49 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 6D3976333F;\n\tFri,  2 Dec 2022 21:24:48 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4921460483\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tFri,  2 Dec 2022 21:24:46 +0100 (CET)","from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi\n\t[213.243.189.158])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 9853C6E0;\n\tFri,  2 Dec 2022 21:24:45 +0100 (CET)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1670012688;\n\tbh=lZup2gG4AU7yG7fcziQM+7osaogj4z+Jzq7RfBYKUBo=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=Vjyf6GcWfBk9MDM9V3AWEDknb0RsnY33/g69GRL5JQCTodqgsenfHgo0PdQIrJ/Ae\n\t+modgfpBCAByEdpsCYrIeBzTd+gh6ZrqroOIi0vP5bJu+XbLmXA8Himj9yhdm5uEks\n\t5IvzQ9oR7K3VhfGyjLUUqMIhUMuMY8FFl7F/CfW4TbxrceFQUmrPd5DK4LEL4t760u\n\tpGO9I4bNujB+vSH6/KKzVA4J+2g8iW8VfXxzUMl5mAgUbf6PyveFRi7UdMN2sDnpGC\n\tdnAm9swPil/lzON8cGV30xYRyqmvsfk4Ar5xNHMtgmVsKvxXC1bTofX+X0Uomq4y8B\n\tNl8oQtra8OK2w==","v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1670012685;\n\tbh=lZup2gG4AU7yG7fcziQM+7osaogj4z+Jzq7RfBYKUBo=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=WLQJmpzMGGud8rzwOpk10jDOQt35070gYsbSpa7R/jcNpSTfPkR8h30i71Y9cp7Rs\n\t9Qw+eEtLowjJFZ7JHwzCN7/AbvKSLhzcISXw8r1talpJvyplIzrjKqIEAmg8mS4Pdz\n\ty0OnmZmnk68EyVqHpWZ6kc4vAqZwoNN5+aWtarPw="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ideasonboard.com\n\theader.i=@ideasonboard.com\n\theader.b=\"WLQJmpzM\"; dkim-atps=neutral","Date":"Fri, 2 Dec 2022 22:24:43 +0200","To":"Jacopo Mondi <jacopo@jmondi.org>","Message-ID":"<Y4pfC9RgjozcEfu+@pendragon.ideasonboard.com>","References":"<20221202164145.30603-1-jacopo@jmondi.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20221202164145.30603-1-jacopo@jmondi.org>","Subject":"Re: [libcamera-devel] [PATCH 1/2] libcamera: utils: Wrap usage of\n\tlockf()","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"<libcamera-devel.lists.libcamera.org>","List-Unsubscribe":"<https://lists.libcamera.org/options/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=unsubscribe>","List-Archive":"<https://lists.libcamera.org/pipermail/libcamera-devel/>","List-Post":"<mailto:libcamera-devel@lists.libcamera.org>","List-Help":"<mailto:libcamera-devel-request@lists.libcamera.org?subject=help>","List-Subscribe":"<https://lists.libcamera.org/listinfo/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=subscribe>","From":"Laurent Pinchart via libcamera-devel\n\t<libcamera-devel@lists.libcamera.org>","Reply-To":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" <libcamera-devel-bounces@lists.libcamera.org>"}}]