From owner-freebsd-hackers@freebsd.org Tue Mar 30 21:05:09 2021 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 DDA625AD9BE for ; Tue, 30 Mar 2021 21:05:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4F925d5BKVz3LfK for ; Tue, 30 Mar 2021 21:05:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B1C225AD493; Tue, 30 Mar 2021 21:05:09 +0000 (UTC) Delivered-To: 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 B16105AD9BD for ; Tue, 30 Mar 2021 21:05:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound4s.ore.mailhop.org (outbound4s.ore.mailhop.org [54.185.97.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F925d2Dydz3LkG for ; Tue, 30 Mar 2021 21:05:08 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1617138307; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NWe2OYxGexHFIHPwlnbEWL9XtJpthpBDMrk60Cw7UzoCA64Z1iRUfq0MpK2Vc9vzbpkHKstaPPsaG TJakkFpAnIvGA+lGeXMpWraphw+QZLly9z6INPeG/3gjFuP2/PdWv1UAA2KLbbA5hrJAqFT56Y/Aan av2uai3Kn8V3tua3/MnpRTiamDalpkVfEOeY/IZXYYggdy+XoIt3P6DkoAgmWQueaPlHFZN6mytxdG WzFa3QesU+kFMQqxfBsyVPYccFR3GEnSakG40iGH4dvFA2OcqPQRnQHyPUaInN/SZqK+ijIZyPAi9A hvY4XL5mcB+Iwlc8fOH9t+Cvmk7TTdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=OddVdHNksZO69Gc+ovbeqO90XQ81EEMpmtaUdB/C+Rk=; b=hF1etdwmXW/GisBoxXY1NnbNwZiG1h4oiJa0pwi5rVPORp92avMUZHi12K42b8TtX76BBQtJ7O8w/ Qu3sbMjmfPKlXiADnRmfSWS3VtTNk5qIV2k/rfaT5HtCOV7uyYxrNmbEZa5eKFQTI1VYaDxji0MEng wAPwpXmb/gHn0kCE6IjcNByRhDJBR/TjT8jgWW+yZi9IEt2/1DPvzEFAgIbvPEzDWtZmA9psyuEM/H vCbGW10dmtKG5RgBTSTxi7VlK/Z30TCCpPONxKq3bPP84+xK/Y8Kqe555ccEGpnniMLL9B6MyJptFb 8Vd4IBcfgyraazWdwP1kbK/nxTqEiuQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=OddVdHNksZO69Gc+ovbeqO90XQ81EEMpmtaUdB/C+Rk=; b=gZcAg6DxebZA+77J178uKdv6CdOldgZjBS8PCR7JOFvOdckTRSPYDRbqENw5RkHuoQ4dAYOpwmSTk QuV28PZWiCv451GEDSlilus0ALSVbK0iDbLjZFznifXLb0FD9nJ4s7/cQQC3SLcpasxrXngNIXpkud 2J3dmTW09O0+/YA8vDYX0V4mZYUQEfhZbJ7TH8IdJxYhdjxerjORjYNqIE2G6wsSy+lKL+1B08MQjr YZ+xSU07cWsXT3cfdVpK5o2qJkpbHDIWqxxta5EEEa0Jle6NIelyt88Dc64pngXGMAweuwMlWo6moY Dn8PkBQYAm701f3rrjJ8nh2U02P3EZw== X-Originating-IP: 67.177.211.60 X-MHO-RoutePath: aGlwcGll X-MHO-User: 9988230f-919b-11eb-a600-89389772cfc7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 9988230f-919b-11eb-a600-89389772cfc7; Tue, 30 Mar 2021 21:05:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 12UL54nJ064048; Tue, 30 Mar 2021 15:05:04 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: RFC: possible issue with kqueue From: Ian Lepore To: Warner Losh Cc: John-Mark Gurney , Emanuel Haupt , "freebsd-hackers@freebsd.org" Date: Tue, 30 Mar 2021 15:05:04 -0600 In-Reply-To: References: <20210327131011.e16291cac86475e75a33812c@FreeBSD.org> <20210330181402.GM14975@funkthat.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4F925d2Dydz3LkG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 21:05:10 -0000 On Tue, 2021-03-30 at 15:01 -0600, Warner Losh wrote: > On Tue, Mar 30, 2021 at 12:51 PM Ian Lepore wrote: > > > On Tue, 2021-03-30 at 11:14 -0700, John-Mark Gurney wrote: > > > Emanuel Haupt wrote this message on Sat, Mar 27, 2021 at 13:10 > > > +0100: > > > > Can someone familiar with kqueue please comment on: > > > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024 > > > > > > Done: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254024#c11 > > > > > > Looks like the user wasn't force unmounting the FS. There really > > > isn't any problem w/ kqueue, as a normal unmount is expected to > > > be > > > refused while files are open. > > > > > > I guess there COULD be a new flag added to file descriptors that > > > flag them as being able to be closed upon unmount. Then when an > > > unmount happens and only these flagged files remain, they are > > > closed > > > allowing the fs to unmount. But this is a new feature and > > > independent > > > of kqueue. > > > > > > > While it's not a kqueue bug per se, it is a weakness in freebsd > > that > > there is no way to monitor a volume, or items within that volume, > > without making it impossible to unmount the volume. I've been > > fighting > > this with various implementations of desktop software for like 20 > > years > > on freebsd. Usually I have to just disable all monitoring and live > > with the reduced desktop functionality. > > > > I wonder if a reasonable fix might be to have some sort of pre- > > unmount > > event that can be delivered via kqueue, so that a userland entity > > monitoring on that volume has a chance to close related descriptors > > so > > that the unmount can proceed? > > > > That's not a bad idea. I've often thought we need a wider range of > quiesce > calls / events / whatever that would allow people with 'soft' > references to > drop > them in advance of an attempted event. I've never been sure what to > do if > the attempted event failed, so I've not gotten off the mark... this > is but > one > example... > > Warner Yeah, I was kinda wondering what do about the case where the unmount ultimately failed. The only thought I had was some kind of followup event to inform folks of that (either a fake mount event, or a specific unmount-failed event). -- Ian