From owner-freebsd-hackers@freebsd.org Sun Dec 13 20:37:27 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 A67F14C2D24 for ; Sun, 13 Dec 2020 20:37:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 4CvGY34FSxz4rh5; Sun, 13 Dec 2020 20:37:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f171.google.com with SMTP id 15so16901750oix.8; Sun, 13 Dec 2020 12:37:27 -0800 (PST) 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=2txaVs2CEdy1Mjq/UpHQd5a22nguXMOlw0XE9zvfjD4=; b=Qyu5wZrISJywHQS6Pq9a7R3cl38m8Gppee/MW2nynWva3hqGHyuu3K8o/1Lt9CCUR/ o7wbiH31zD16cKqpk5n2MjPEGxIPvXcwv5R1AjbtoeSsUb+4LfFOMjprZ/9IWrMtZpud zLA5F/mZVFsGH3t3py755qVXg3CyUdH0LBTfKsi+q0F71iCLxFq6nw5DkiDPOYRqHDsS LeWQeCO/8yMzHxOYZh17wOiDxDb9G7pnangDFATCNEONim0ZPNzEMa8G4sPUqlMfCefF FKAZ9KHeNLoPqNa6Jk4M9jxIbTaEh1nnw7tGEAwlUpcIJQ4nBxrIhxZ1BEVN5GlEAjQD uQYA== X-Gm-Message-State: AOAM531y7gaLokt/SvPOOjs5uYE3irJlScgrfLyJn/I0FFGVdHyKWyS/ aenn/odTzDIQSmRbWxcqmtA5996c476m+yq3/648q4XO7pq/hA== X-Google-Smtp-Source: ABdhPJzXUoXjpGXwWbemPOisgfyFm1mJI1L1eLaLoDlGXhmYw3UVHNC5V+6zTUqLzkmu3uysguWlBcNXqk7k1z1iThc= X-Received: by 2002:aca:dd09:: with SMTP id u9mr15648566oig.73.1607891846562; Sun, 13 Dec 2020 12:37:26 -0800 (PST) MIME-Version: 1.0 References: <6dd927984d69ef0e95e1e90651bcd8087bc4eec4.camel@freebsd.org> In-Reply-To: From: Alan Somers Date: Sun, 13 Dec 2020 13:37:15 -0700 Message-ID: Subject: Re: char devices without SI_UNMAPPED? To: Konstantin Belousov Cc: Warner Losh , Ian Lepore , FreeBSD Hackers X-Rspamd-Queue-Id: 4CvGY34FSxz4rh5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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: Sun, 13 Dec 2020 20:37:27 -0000 On Sun, Dec 13, 2020 at 12:40 PM Konstantin Belousov wrote: > On Sun, Dec 13, 2020 at 12:20:49PM -0700, Alan Somers wrote: > > On Sun, Dec 13, 2020 at 11:20 AM Warner Losh wrote: > > > > > > > > > > > On Sun, Dec 13, 2020 at 11:18 AM Ian Lepore wrote: > > > > > >> On Sun, 2020-12-13 at 10:27 -0700, alan somers wrote: > > >> > I'm trying to exercise the aio code that handles character devices > > >> > that > > >> > don't set the SI_UNMAPPED flag. But I can't find any. Are there > any > > >> > remaining character devices that don't allow unmapped I/O? > > >> > > > >> > -Alan > > >> > > > >> > > >> I assume you mean disk-like devices? Probably mmcsd, flash/at45d, > > >> flash/mx25l. > > >> > > > > > Hm. I don't have any of those. > > > > > > > > > > There are times that it's disabled administratively as well, but that > may > > > be on a per-I/O basis. > > > vfs.zfs.vol.unmap_enabled: 1 > > > > > > > This one doesn't seem to work. It looks like the only functionality it > > gates these days is DIOCGDELETE. > > > > > > > vfs.unmapped_buf_allowed: 1 > > > > > > > Well, this one works. Thanks for the tip. Unfortunately, it's a > tunable, > > so I can't use it for any kind of automated testing. > > There is enough geoms which do not support unmapped bios, even if only in > some configurations. Recursively grep for G_PF_ACCEPT_UNMAPPED in sys/geom > to see what I mean. > That's different. If a provider clears G_PF_ACCEPT_UNMAPPED, geom will create a transient mapping for any unmapped bios sent to that provider. But the provider still has SI_UNMAPPED set. SI_UNMAPPED is used in so few places, I'm wondering if it still has a purpose at all. Is it obsolete? > > After all, an option for geom_nop should be trivial, to force all bios to > map, instead of inheriting from the lower provider. >