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 [...]
