From owner-freebsd-hackers@freebsd.org Wed Aug 26 17:32:42 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 27D2D3B5A81 for ; Wed, 26 Aug 2020 17:32:42 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BcCcB0Clnz4MyY; Wed, 26 Aug 2020 17:32:41 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: by mail-lj1-x232.google.com with SMTP id m22so3305498ljj.5; Wed, 26 Aug 2020 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Krz1YO0dopFz0U2WPsLmF7GGFEEJqM+hDntRP7tMrJ0=; b=A4vJsKz++nrxH+Bu7bh4DQhuXnG8M0Y7IyzIvLSCQZwCc5Og1o/VAWRAOXmzpi3G1s O2jkY8TB5UpPsKawORjookTjL/QmCwJO3O6FMqJI/uZGO2skyRQVx9BXLgKJ7zJWKGc2 NliRX7Lp7iW368rvRV9+vyEJPueOgAPs+nwhHXD1XUAzM2JBhl5ua5vJZBWVS7QD9ElU nByz9+/147yIExUFIDn1o7xj87pxWQVIzYdvxfN1NZTxU+zlJXPtupYbNrNmaR0Yalm1 XkQ/R4w5VPM8nF27QKBTAVoidOcZUeijPjSvc+ZADN4Qgko/Byb3FAZp3Qt3JZYjbC1k 8KZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Krz1YO0dopFz0U2WPsLmF7GGFEEJqM+hDntRP7tMrJ0=; b=WeMcIWVLzYqvHKY7hbejoIlCRa7o1VE5jXpYK25usIk1WpWSMN8HC2KSIkdnBbdiAr 7NgcEJYfXm0v7hcKs+KHJyQR7CExcBnhGT+pNwodH6u8g/yndwgiq+PT/PBUDEYl2oH+ C83pBStxhEEBk87FDNdLptpuKhxB6Q58mW5BfOsIC4umqpGzCfrtCcn7d32m+4ZC1oUZ YjdsEBA3QioI6TXYSCCTsRRJy97sLf8K4esQMU3YLlIladjHdm4ZbnymmhQTRlGT8gVZ 9ryYGT44qWbv46tf2XrBr2/fUHlahwUYakD0ZZY39H9pXNrcBZcrZTo1ltEZ8GnmsK6N XNqA== X-Gm-Message-State: AOAM532EZn3edtTRVMUNZ6sOPaqpQYmlXoh/bgyJ25r6rvNrPLsszzxc iTzcC2YemCvHbKtw5hRvrJlnCFo29A/AjzuWrf5H7NEreV/X8Q== X-Google-Smtp-Source: ABdhPJwYt9lxXHgcBrN8yhcnB/OXtZONVHrMl/MNt/BHcQtAyYT0HHHPda8GLiUSxb+QYZt5rNM+ol04rGj55YPx6sY= X-Received: by 2002:a05:651c:1069:: with SMTP id y9mr7814538ljm.438.1598463160519; Wed, 26 Aug 2020 10:32:40 -0700 (PDT) MIME-Version: 1.0 References: <20200826144013.GV2551@kib.kiev.ua> In-Reply-To: From: J David Date: Wed, 26 Aug 2020 13:32:29 -0400 Message-ID: Subject: Re: pidfile_open() usage in "mount" To: Brandon Bergren Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BcCcB0Clnz4MyY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 17:32:42 -0000 On Wed, Aug 26, 2020 at 12:41 PM Brandon Bergren wrote: > The pidfile_* stuff is meant for the daemon side. As written, agreed, it clearly is. But alas "meant for" and "used for" appear to differ. It looks like there's a client-side use in ZFS as well (cddl/compat/opensolaris/misc/fsshare.c). > Why not just regular open(2)? That's also a solution I'd be fine with submitting. Certainly less work. But there are a couple of reasons not to do that, mostly to do with code reuse. First, the pidfile library does some stuff around path handling that is useful not to try to reinvent. Second, while races do exist, use of pidfiles in this way probably isn't going away, so having the code that tries to minimize those races in one place makes a lot of sense, rather than having potentially multiple idiosyncratic approaches/cases on an ad-hoc basis. ("Don't let the perfect be the enemy of the good" and all that.) The CDDL thing is actually a good example of this, because it looks lifted straight from mount.c, but when mount.c got updated with the mountdpid <= 0 check, fsshare.c didn't, and that's almost certainly a bug because it could lead to inadvertent kill( -1, SIGHUP ) with superuser permissions. Whoops! ZFS just randomly HUP'd every process on the system. Having mount HUP mountd (iff it's running) seems odd to me anyway, but today's filesystems are so weird and complex and diverse that I'm sure it's essential for somebody. Thanks!