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

[SeongJae Park]

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

> On Wed, 26 Feb 2025 17:57:52 -0800 SeongJae Park <sj@xxxxxxxxxx> 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

[...]