Re: [PATCH v2] drop_caches: re-enable message after disabling

[Luis Chamberlain <mcgrof@kernel.org>]

On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> >> When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled,
> >> but there is no interface to enable the message, only by restarting
> >> the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to
> >> enabled the message again.
> >> 
> >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> >
> > You are overcomplicating things, if you just want to re-enable messages
> > you can just use:
> >
> > -		stfu |= sysctl_drop_caches & 4;
> > +		stfu = sysctl_drop_caches & 4;
> >
> > The bool is there as 4 is intended as a bit flag, you can can figure
> > out what values you want and just append 4 to it to get the expected
> > result.
> >
> >  Luis
> 
> Is that what you mean ?
> 
> -               stfu |= sysctl_drop_caches & 4;
> +               stfu ^= sysctl_drop_caches & 4;
> 
> 'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
> This is what I originally thought, but there is uncertainty that when different operators execute the command,
> It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

The way these flags are designed are bits in a flag. If you want to
disable the flag, it'll be disabled. If you want it added it must be
added as a flag. So what I did was just remove the or logic as that
just keeps it on forever. With XOR you end up where if you had it
enabled and then want to enable it again, you disable it.

1 xor 1 = 0

The simple variable setting just always sets it and puts the burden on
the operators to read the existing setting if they don't want to disable
prior settings.

  Luis