From owner-freebsd-hackers@freebsd.org Tue Mar 30 18:51:12 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 9FCDC5A9AB7 for ; Tue, 30 Mar 2021 18:51:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8z743mnZz588S for ; Tue, 30 Mar 2021 18:51:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 817995A9B39; Tue, 30 Mar 2021 18:51:12 +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 814045A9DDC for ; Tue, 30 Mar 2021 18:51:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5c.ore.mailhop.org (outbound5c.ore.mailhop.org [54.244.192.240]) (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 4F8z741sCtz583x for ; Tue, 30 Mar 2021 18:51:11 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1617130270; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=rBTewYrdFtWJRYhrC6fF9XfNVegCKV/L7xqYxp7PxmU0Ps8tzwoJp7UR2Yjl5/RZgQtbeAupH7lh2 edgF2/kM705s9WbVG3UnBwJX+kufLzrUPUYmV+mgdCZicwtZO7LC8Hv1r04VAvl5mJTV1xskuzjFXl tlbtVfr0uEpspWrNz3p5C40NX5PcB4G46Yw4NzFzjrmj6Ae7Y9csNXAP2ARFozysDz6Ro9jf50kJzK 1JqEQQMo8XmrgTZD9dbqOZI9wakUhiiH393Ju5BPEdhoMwJV1c8vF3PdZHJGIfVMrDSgDqF2JugRGC B8qYZM6sUw2ZTA3TKBIqgOgOMmJ2Rjg== 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=KS7l6obHgWlW/R+B0PZzwKaaT9YBgi2PcO82oYBrucM=; b=IChb68A/6aIcnsnbYzECdsm7tpOATlpnCUdsIP9bClI8/i8aiM1syn79qXlu7BDpEdnqIZ15AbI0B z0eQ4pX6yAdry8akZ9sYOfkVqze+2P57fnls0iyA9xhLQCGPPv5TNecrlMFLrRLSQ9fGsQCn+Z5TIy bn4JpFy0Y+6JQkmEbqboUg8fsOPphDt7fnnkLs/b5g4mRcl35XI0r1gNNSP+56H8rWZDbGnCH9Pks0 3MBAacHJ0hbDz3BqNc160hjpYu1/MYcOnah3/WPcOhr0AOgYzy5GH6gd0gHDPa7HHGWfv/QxMjbL2R bkkYBWcPp1XiDsB0zh9fdyzdtUvNZmw== ARC-Authentication-Results: i=1; outbound3.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=KS7l6obHgWlW/R+B0PZzwKaaT9YBgi2PcO82oYBrucM=; b=R8LxFKHczvhYPZ227zHdY09wHe4iJ16zW9ICXdD51sQpD20rRESYNgUYj6XNGZqcOFYZ9ExKWAeHV L4+ibO85I6mi8uxDkIeXaQH/jyfp4iJCv/9hd/WtlmV6X0+wY5GUCz9p4Kn5hXHgarh/3YSm1Wlqwb NzNS4w97JYetjqGRHroIZpP4amh9c7WpoVFC63bAwkP3t/mohyFWBLFHOVrwlUCrDdDdDC42dRsZVg AC/rKwIzMRQPyjr+A954hEdlfo7A+NW8QnaZU62vqZEDp/FNZGWNfADWdTwIWSHHJfzkWKyMcpj22m S7K9T1zaCxYOQ/o5GE+jZ196B6N3ucg== X-Originating-IP: 67.177.211.60 X-MHO-RoutePath: aGlwcGll X-MHO-User: e3567dd8-9188-11eb-aa8a-bf9d68d023b6 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id e3567dd8-9188-11eb-aa8a-bf9d68d023b6; Tue, 30 Mar 2021 18:51:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 12UIp7o7063547; Tue, 30 Mar 2021 12:51:07 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: RFC: possible issue with kqueue From: Ian Lepore To: John-Mark Gurney , Emanuel Haupt Cc: hackers@FreeBSD.org Date: Tue, 30 Mar 2021 12:51:07 -0600 In-Reply-To: <20210330181402.GM14975@funkthat.com> 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: 4F8z741sCtz583x 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 18:51:12 -0000 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? -- Ian