Re: [PATCH v4] scripts/config: honor $KBUILD_OUTPUT by default

[Dmitry Voytik]

Hi Nathan,

Thanks for taking time for the review and suggestions!

On Fri, Oct 2, 2026 at 10:15 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
>
> Hi Dmitry,
>
> > If $KBUILD_OUTPUT is set, use it by default if --file is not passed.
> >
> > Fix the issue when the script silently updates a stale .config in
> > the root directory, while the user expects ${KBUILD_OUTPUT}/.config
> > to be updated.
> > Handle properly if the config file is a relative path.
> >
> > The problem can be worked around with --file, but this is easy to miss,
> > and is inconsistent with how the Makefile and other tools work
> > (e.g., scripts/diffconfig).
> >
> > How to reproduce the issue:
> >       rm .config
> >       export KBUILD_OUTPUT=.out
> >       make defconfig
> >       ./scripts/config \
> >              -e CONFIG_UBSAN
> >       grep: .config: No such file or directory
> >
> > How the patch was tested:
> >       make mrproper
> >       export KBUILD_OUTPUT=.out
> >       make defconfig
> >       grep "CONFIG_UBSAN=y" $KBUILD_OUTPUT/.config || echo "OK"
> >
> > Test the basic usage:
> >       ./scripts/config -e CONFIG_UBSAN
> >       grep "CONFIG_UBSAN=y" $KBUILD_OUTPUT/.config && echo "OK"
> >
> > Test --refresh picks up correct config file by using $KBUILD_OUTPUT
> >       ./scripts/config -d CONFIG_UBSAN
> >       ./scripts/config --refresh -e CONFIG_UBSAN
> >       grep "CONFIG_UBSAN=y" $KBUILD_OUTPUT/.config && echo "OK"
> >
> > Test --file takes precedence over $KBUILD_OUTPUT and
> > a relative path is handled properly
> >       ./scripts/config -d CONFIG_UBSAN
> >       mkdir .out2
> >       cp .out/.config .out2/.my_config
> >       grep "CONFIG_UBSAN=y" .out2/.my_config
> >       ./scripts/config --file .out2/.my_config --refresh \
> >              -e CONFIG_UBSAN
> >       grep "CONFIG_UBSAN=y" .out2/.my_config && echo "OK"
> >       ls .out/.out2 || echo "OK"
> >       ls .out/.out || echo "OK"
> >
> > Signed-off-by: Dmitry Voytik <voytikd@xxxxxxxxx>
> > ---
> > v4:
> >  - Addressed Nicolas Schier's comments - dropped the change how '--refresh'
> >    is handled
> >  - Implemented conversion of $FN to the absolute path which helps with
> >    '--refresh' and relative paths
> >  - Documented testing steps in the commit message
> > v3:
> >  - Added an example in the commit message how to reproduce the issue
> > v2:
> >  - Addressed comments by sashiko:
> >    - https://sashiko.dev/#/patchset/20260920064350.17999-1-voytikd%40gmail.com
> >    - use basename when --refresh is used
> >    - remove echo which can be misleading when --file is passed
> > v1:
> >  - https://lore.kernel.org/all/20260920064350.17999-1-voytikd@xxxxxxxxx/
> > ---
> >  scripts/config | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/scripts/config b/scripts/config
> > index 32428ea909c2..0b28fc498195 100755
> > --- a/scripts/config
> > +++ b/scripts/config
> > @@ -130,6 +130,10 @@ on_exit() {
> >  trap on_exit EXIT
> >
> >  FN=.config
> > +if [ -n "${KBUILD_OUTPUT}" ]; then
> > +     FN=${KBUILD_OUTPUT}/${FN}
> > +fi
> > +
> >  CMDS=()
> >  while [[ $# -gt 0 ]]; do
> >       if [ "$1" = "--file" ]; then
> > @@ -143,6 +147,7 @@ while [[ $# -gt 0 ]]; do
> >               shift
> >       fi
> >  done
> > +FN=$(realpath "$FN")
>
> Sashiko has a couple of comments here:
>
>   https://sashiko.dev/#/patchset/20261001214618.283635-1-voytikd%40gmail.com
>
> The second comment around KBUILD_OUTPUT / '--file' beginning with '-' is
> a fairly contrived example but sticking '--' in there does not seem like
> an unreasonable hardening move.

That's an interesting finding.
I tested the patch with a hyphen in the filename, and it indeed wreaks havoc.
Thanks for the pointer!

> As for the first comment, I am not sure I want to rely on 'realpath -m'
> since that is a coreutils-ism and up until now, this could work on any
> operating system (as least as far as I can tell). Maybe we could do
> something like
>
>   FN=$(realpath -q -- "$FN" || echo "$FN")

Sure, let me reuse your suggestion in the next patch (v5).
Thanks!

> to just try and hobble along if we cannot resolve $FN properly but maybe
> there is a better solution that I am just not seeing at the moment.
>
> --
> Cheers,
> Nathan

Best Regards,
Dmitry Voytik.