char devices without SI_UNMAPPED?

[Alan Somers]

On Sun, Dec 13, 2020 at 3:06 PM Alan Somers <asomers at freebsd.org> wrote:

> On Sun, Dec 13, 2020 at 2:37 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Sun, Dec 13, 2020 at 1:37 PM Alan Somers <asomers at freebsd.org> wrote:
>>
>>> On Sun, Dec 13, 2020 at 12:40 PM Konstantin Belousov <
>>> kostikbel at gmail.com> 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 <imp at bsdimp.com> wrote:
>>>> >
>>>> > >
>>>> > >
>>>> > > On Sun, Dec 13, 2020 at 11:18 AM Ian Lepore <ian at freebsd.org>
>>>> 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?
>>>
>>
>> It looks like none of the devices in the tree set it, except the goem
>> namespace, the sa CAM device and the geom disk devices. This leaves plenty
>> of other devices in the tree that use physio() that aren't marked: pt,
>> zvol, altera avgen, altera sd card, amr, cfi, firewire, a bunch of
>> different flash devices, mfi, mlx, pst, and twe.
>>
>
> I previously tested zvol and saw that it had SI_UNMAPPED set.  But that
> was with vfs.zfs.vol.mode=1.  With 2, I see that it no longer sets
> SI_UNMAPPED.
>

Oh, and it turns out that there's bug with the ZFS volmode property that
also interferes with this test.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251828 .


>
>
>> None of these drivers have been converted over to grok unmapped I/O,
>> which is a relatively new feature. Now, some of these devices might have a
>> good case made for obsoleting, but they aren't there yet... What makes you
>> think this is obsolete?
>>
>
> Just because so few places check it (2), and it was set by all geom
> devices.  It smelled like the kind of thing that might've been leftover
> from before some critical refactor.  But I guess I was wrong.
>
>
>>
>> Warner
>>
>>
>>>
>>>> After all, an option for geom_nop should be trivial, to force all bios
>>>> to
>>>> map, instead of inheriting from the lower provider.
>>>>
>>>