Hi Michal, On 3/3/22 02:14, Michal Koutný wrote: > On Wed, Mar 02, 2022 at 04:53:19PM -0800, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: >> I don't think those strings (even with invalid option values) should be >> added to init's environment. > > Isn't mere presence of the handler sufficient to filter those out? [1] What is [1] here? > (Counter-example would be 'foo=1 foo=2' where 1 is accepted value by the > handler, 2 is unrecognized and should be passed to init. Is this a real > use case?) I don't know of any case where "foo=2" should be passed to init if there is a setup function for "foo=" defined. >> I'm willing to add a pr_warn() or pr_notice() for any unrecognized >> option value, but it should still return 1 IMO. > > Regardless of the handler existence check, I see returning 1 would be > consistent with the majority of other memcg handlers. > > For the uniformity, > Reviewed-by: Michal Koutný <mkoutny@xxxxxxxx> > > (Richer reporting or -EINVAL is by my understanding now a different > problem.) -- ~Randy