Re: [RFC PATCH v2 7/9] mm/damon/core: set damos_filter default allowance behavior based on installed filters

SeongJae Park
2025-02-28T04:48:48Z

On Wed, 26 Feb 2025 21:50:54 -0800 SeongJae Park <sj@kernel.org> wrote:

> On Wed, 26 Feb 2025 17:57:52 -0800 SeongJae Park <sj@kernel.org> wrote:
>
> > Decide whether to allow or reject by default on core and opertions layer
> > handled filters evaluation stages. It is decided as the opposite of the
> > last installed filter's behavior. If there is no filter at all, allow
> > by default. If there is any operations layer handled filters, core
> > layer's filtering stage sets allowing as the default behavior regardless
> > of the last filter of core layer-handling ones, since the last filter of
> > core layer handled filters in the case is not really the last filter of
> > the entire filtering stage.
>
> This is not sufficient enough. Even with this change, core-handled allow
> filters after core-handled reject filters are still meaningless.
>
> If a region is matched to a core layer handled filter, the allow/reject
> decision should be respected while ignoring all remaining filters, regardless
> of on what layer those are handled. It works in the way for reect filters,
> since core layer-rejected regions are not passed to the ops layer at all. In
> case of allow filter, however, the region is passed to ops layer without the
> information about whether it has passed to the ops layer because it was
> allowed, or just not matched to any filter. Hence, all ops filters can be
> applied to the region.
>
> We can implement this missing part by storing the core layer filtering stage
> decision somewhere and let ops filter filtering stage repsect it. Changes like
> attached diff at the end of this mail may work. I will add such changes to
> next version of this patch series.

I now realize this is not a missing part of this improvement patch series, but
a sole fix for the allow filter behavior. The current behavior is not matching
with the documented one, and this change will fix it. I will post a patch for
this fix separately from this patch series.

Thanks,
SJ …