Bare email addresses with non alphanumeric characters require escape
quoting before being substituted in the parse_email routine.

e.g. Reported-by: syzbot+bbd8e9a06452cc48059b@syzkaller.appspotmail.com

Do so.

Link: http://lkml.kernel.org/r/1518631805.3678.12.camel@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sometimes files may be created by using output from printk.  As the scan
traverses the directory tree we should parse each path name and check if
it is leaking an address.

Add check for leaking address on each path name.
Suggested-by: NTycho Andersen <tycho@tycho.ws>
Acked-by: NTycho Andersen <tycho@tycho.ws>
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently sub routine may_leak_address() is checking regex against Perl
special variable $_ which is _fortunately_ being set correctly in a loop
before this sub routine is called.  We already have declared a variable
to hold this value '$line' we should use it.

Use $line in regex match instead of implicit $_
Signed-off-by: NTobin C. Harding <me@tobin.cc>

We have git now, we don't need a version number.  This was originally
added because leaking_addresses.pl shamelessly (and mindlessly) copied
checkpatch.pl

Remove version number from script.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

The pointers listed in /proc/1/syscall are user pointers, and negative
syscall args will show up like kernel addresses.

For example

/proc/31808/syscall: 0 0x3 0x55b107a38180 0x2000 0xffffffffffffffb0 \
0x55b107a302d0 0x55b107a38180 0x7fffa313b8e8 0x7ff098560d11

Skip parsing /proc/1/syscall
Suggested-by: NTycho Andersen <tycho@tycho.ws>
Signed-off-by: NTobin C. Harding <me@tobin.cc>

When the system is idle it is likely that most files under /proc/PID
will be identical for various processes.  Scanning _all_ the PIDs under
/proc is unnecessary and implies that we are thoroughly scanning /proc.
This is _not_ the case because there may be ways userspace can trigger
creation of /proc files that leak addresses but were not present during
a scan.  For these two reasons we should exclude all PID directories
under /proc except '1/'

Exclude all /proc/PID except /proc/1.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently we are repeatedly calling `uname -m`.  This is causing the
script to take a long time to run (more than 10 seconds to parse
/proc/kallsyms).  We can use Perl state variables to cache the result of
the first call to `uname -m`.  With this change in place the script
scans the whole kernel in under a minute.

Cache machine architecture in state variable.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script has multiple configuration arrays.  This is confusing,
evident by the fact that a bunch of the entries are in the wrong place.
We can simplify the code by just having a single array for absolute
paths to skip and a single array for file names to skip wherever they
appear in the scanned directory tree.  There are also currently multiple
subroutines to handle the different arrays, we can reduce these to a
single subroutine also.

Simplify the path skipping code.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script parses binary files.  Since we are scanning for
readable kernel addresses there is no need to parse binary files.  We
can use Perl to check if file is binary and skip parsing it if so.

Do not parse binary files.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script only supports x86_64 and ppc64.  It would be nice to be
able to scan 32-bit machines also.  We can add support for 32-bit
architectures by modifying how we check for false positives, taking
advantage of the page offset used by the kernel, and using the correct
regular expression.

Support for 32-bit machines is enabled by the observation that the kernel
addresses on 32-bit machines are larger [in value] than the page offset.
We can use this to filter false positives when scanning the kernel for
leaking addresses.

Programmatic determination of the running architecture is not
immediately obvious (current 32-bit machines return various strings from
`uname -m`).  We therefore provide a flag to enable scanning of 32-bit
kernels.  Also we can check the kernel config file for the offset and if
not found default to 0xc0000000.  A command line option to parse in the
page offset is also provided.  We do automatically detect architecture
if running on ix86.

Add support for 32-bit kernels.  Add a command line option for page
offset.
Suggested-by: NKaiwan N Billimoria <kaiwan.billimoria@gmail.com>
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently there is duplicate code when checking the architecture type.
We can remove the duplication by implementing a wrapper function
is_arch().

Implement and use wrapper function is_arch().
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script uses Perl to get the machine architecture. This can be
erroneous since Perl uses the architecture of the machine that Perl was
compiled on not the architecture of the running machine. We should use
the systems `uname` command instead.

Use `uname -m` instead of Perl to get the machine architecture.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script only supports 4 page table levels because of the way
the kernel address regular expression is crafted. We can do better than
this. Using previously added support for kernel configuration options we
can get the number of page table levels defined by
CONFIG_PGTABLE_LEVELS. Using this value a correct regular expression can
be crafted. This only supports 5 page tables on x86_64.

Add support for 5 page table levels on x86_64.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Features that rely on the ability to get kernel configuration options
are ready to be implemented in script. In preparation for this we can
add support for kernel config options as a separate patch to ease
review.

Add support for locating and parsing kernel configuration file.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently script checks only first and last address in the vsyscall
memory range. We can do better than this. When checking for false
positives against $match, we can convert $match to a hexadecimal value
then check if it lies within the range of vsyscall addresses.

Check whole range of vsyscall addresses when checking for false
positive.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

A number of the command line options to script are dependant on the
option --input-raw being set. If we indent these options it makes
explicit this dependency.

Indent options dependant on --input-raw.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently help output includes command examples. These were cute when we
first started development of this script but are unnecessary.

Remove command examples.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

leaking_addresses.pl can be run with kptr_restrict==0 now, we don't need
the comment about setting kptr_restrict any more.

Remove comment suggesting setting kptr_restrict.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Currently code uses a check against an undefined variable because the
variable is a sub routine name and is not evaluated.

Evaluate subroutine; add parenthesis to sub routine name.
Signed-off-by: NTobin C. Harding <me@tobin.cc>

Inspired by gdb command 'list', show the code context of target lines.
Here is a example:

$ scripts/faddr2line vmlinux native_write_msr+0x6
native_write_msr+0x6/0x20:
arch_static_branch at arch/x86/include/asm/msr.h:105
100             return EAX_EDX_VAL(val, low, high);
101     }
102
103     static inline void notrace __wrmsr(unsigned int msr, u32 low, u32 high)
104     {
105             asm volatile("1: wrmsr\n"
106                          "2:\n"
107                          _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
108                          : : "c" (msr), "a"(low), "d" (high) : "memory");
109     }
110
(inlined by) static_key_false at include/linux/jump_label.h:142
137     #define JUMP_TYPE_LINKED        2UL
138     #define JUMP_TYPE_MASK          3UL
139
140     static __always_inline bool static_key_false(struct static_key *key)
141     {
142             return arch_static_branch(key, false);
143     }
144
145     static __always_inline bool static_key_true(struct static_key *key)
146     {
147             return !arch_static_branch(key, true);
(inlined by) native_write_msr at arch/x86/include/asm/msr.h:150
145     static inline void notrace
146     native_write_msr(unsigned int msr, u32 low, u32 high)
147     {
148             __wrmsr(msr, low, high);
149
150             if (msr_tracepoint_active(__tracepoint_write_msr))
151                     do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
152     }
153
154     /* Can be uninlined because referenced by paravirt */
155     static inline int notrace

Link: http://lkml.kernel.org/r/1521444205-2259-1-git-send-email-changbin.du@intel.comSigned-off-by: NChangbin Du <changbin.du@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: NeilBrown <neilb@suse.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now recordmcount.pl recognizes RISC-V object files. For the mechanism to
work, we have to disable the linker relaxation.

Cc: Greentime Hu <greentime@andestech.com>
Signed-off-by: NAlan Kao <alankao@andestech.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Since commit 28128c61 ("kconfig.h: Include compiler types to avoid
missed struct attributes"), <linux/kconfig.h> pulls in kernel-space
headers to unrelated places.

Commit 0f9da844 ("MIPS: boot: Define __ASSEMBLY__ for its.S build")
suppress the build error by defining __ASSEMBLY__, but ITS (i.e. DTS)
is not assembly, and should not include <linux/compiler_types.h> in the
first place.

Looking at arch/s390/tools/Makefile, host programs gen_facilities and
gen_opcode_table now pull in <linux/compiler_types.h> as well.

The motivation for that commit was to define necessary attributes
before any struct is defined.  Obviously, this happens only in C.

It is enough to include <linux/compiler_types.h> only when compiling
C files, and only when compiling kernel space.  Move the include to
c_flags.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This changes security_hook_heads to use hlist_heads instead of
the circular doubly-linked list heads. This should cut down
the size of the struct by about half.

In addition, it allows mutation of the hooks at the tail of the
callback list without having to modify the head. The longer-term
purpose of this is to enable making the heads read only.
Signed-off-by: NSargun Dhillon <sargun@sargun.me>
Reviewed-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NJames Morris <james.morris@microsoft.com>

The logic with parses array has a bug that prevents it to
parse arrays like:
	struct {
	...
		struct {
			u64 msdu[IEEE80211_NUM_TIDS + 1];
			...
	...

Fix the parser to accept it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

There is a change in how command line parsing is done in this version.
Excludes and includes are now ordered with the file list. Since
the spec file puts the file list before the exclude list it means newer
tar ignores the excludes and packs all the build output into the
kernel-devel RPM resulting in a huge package.

Simple argument re-ordering fixes the problem.
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since d5d332d3, a couple of links in scripts/dtc/include-prefixes
are additionally required in order to build device trees with the header
package.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The Blackfin port has been removed from the kernel, also remove the
blackfin specific bits from the checkstack.pl script.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

These two architectures are getting removed, so we no longer
need the special cases.
Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Tracking the line number by hand is error-prone since you need to
increment it in every \n matching pattern.

If '%option yylineno' is set, flex defines 'yylineno' to contain the
current line number and automatically updates it each time it reads a
\n character.  This is much more convenient although the lexer does
not initializes yylineno, so you need to set it to 1 each time you
start reading a new file, and restore it you go back to the previous
file.

I tested this with DEBUG_PARSE, and confirmed the same dump message
was produced.

I removed the perf-report option.  Otherwise, I see the following
message:
  %option yylineno entails a performance penalty ONLY on rules that
  can match newline characters
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, the recursive inclusion is not detected when the offending
file is about to be included; it is detected the offending file is
about to include the *next* file.  This is because the detection loop
does not involve the file being included.

Do this check against the file that is about to be included so that
the recursive inclusion is detected before unneeded parsing happens.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

As in the unit test, the error message for the recursive inclusion
looks like this:

  Kconfig.inc1:4: recursive inclusion detected. Inclusion path:
    current file : 'Kconfig.inc1'
    included from: 'Kconfig.inc3:1'
    included from: 'Kconfig.inc2:3'
    included from: 'Kconfig.inc1:4'

The 'Kconfig.inc1:4' is duplicated in the first and last lines.
Also, the single quotes do not help readability.

Change the message like follows:

  Recursive inclusion detected.
  Inclusion path:
    current file : Kconfig.inc1
    included from: Kconfig.inc3:1
    included from: Kconfig.inc2:3
    included from: Kconfig.inc1:4
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

nconf.h includes <curses.h> and "ncurses.h", but it does not need to
include both.  Generally, it should fall back to curses.h only when
ncurses.h is not found.  But, looks like it has never happened;
these includes have been here for many years since commit 692d97c3
("kconfig: new configuration interface (nconfig)"), and nobody has
complained about hard-coding of ncurses.h .  Let's simply drop the
curses.h inclusion.

I replaced "ncurses.h" with <ncurses.h> since it is not a local file.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.

Here is test code to demonstrate how it currently works.

[Test Case]

  config DEP1
          def_bool y

  config DEP2
          bool "DEP2"

  config A
          bool "A"
          select E

  config B
          bool "B"
          depends on DEP2
          select E

  config C
          bool "C"
          depends on DEP1 && DEP2
          select E

  config D
          def_bool n
          select E

  config E
          bool
          depends on DEP1 && DEP2

[Result]

  $ make config
  scripts/kconfig/conf  --oldaskconfig Kconfig
  *
  * Linux Kernel Configuration
  *
  DEP2 (DEP2) [N/y/?] (NEW) n
  A (A) [N/y/?] (NEW) y
  warning: (A && B && D) selects E which has unmet direct
  dependencies (DEP1 && DEP2)

Here, I see some points to be improved.

First, '(A || B || D)' would make more sense than '(A && B && D)'.
I am not sure if this is intentional, but expr_simplify_unmet_dep()
turns OR expressions into AND, like follows:

        case E_OR:
                return expr_alloc_and(

Second, we see false positives.  'A' is a real unmet dependency.
'B' is false positive because 'DEP1' is fixed to 'y', and 'B' depends
on 'DEP2'.  'C' was correctly dropped by expr_simplify_unmet_dep().
'D' is also false positive because it has no chance to be enabled.
Current expr_simplify_unmet_dep() cannot avoid those false positives.

After all, I decided to use the same helpers as used for printing
reverse dependencies in the help.

With this commit, unreadable warnings (most of the reported symbols are
false positives) in the real world:

$ make ARCH=score allyesconfig
scripts/kconfig/conf  --allyesconfig Kconfig
warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM &&
 DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_OXNAS && DWMAC_ROCKCHIP &&
 DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_GEMINI &&
 PINCTRL_OXNAS && PINCTRL_ROCKCHIP && PINCTRL_DOVE &&
 PINCTRL_ARMADA_37XX && PINCTRL_STM32 && S3C2410_WATCHDOG &&
 VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 &&
 LPC18XX_DMAMUX && VIDEO_OMAP4 && COMMON_CLK_GEMINI &&
 COMMON_CLK_ASPEED && COMMON_CLK_NXP && COMMON_CLK_OXNAS &&
 COMMON_CLK_BOSTON && QCOM_ADSP_PIL && QCOM_Q6V5_PIL && QCOM_GSBI &&
 ATMEL_EBI && ST_IRQCHIP && RESET_IMX7 && PHY_HI6220_USB &&
 PHY_RALINK_USB && PHY_ROCKCHIP_PCIE && PHY_DA8XX_USB) selects
 MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
warning: (PINCTRL_AT91 && PINCTRL_AT91PIO4 && PINCTRL_OXNAS &&
 PINCTRL_PISTACHIO && PINCTRL_PIC32 && PINCTRL_MESON &&
 PINCTRL_NOMADIK && PINCTRL_MTK && PINCTRL_MT7622 && GPIO_TB10X)
 selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF &&
 HAS_IOMEM)
warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && LOCKDEP)
 selects FRAME_POINTER which has unmet direct dependencies
 (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN ||
 MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS)

will be turned into:

$ make ARCH=score allyesconfig
scripts/kconfig/conf  --allyesconfig Kconfig

WARNING: unmet direct dependencies detected for MFD_SYSCON
  Depends on [n]: HAS_IOMEM [=n]
  Selected by [y]:
  - PINCTRL_STM32 [=y] && PINCTRL [=y] && (ARCH_STM32 ||
 COMPILE_TEST [=y]) && OF [=y]
  - RTC_DRV_AT91SAM9 [=y] && RTC_CLASS [=y] && (ARCH_AT91 ||
 COMPILE_TEST [=y])
  - RESET_IMX7 [=y] && RESET_CONTROLLER [=y]
  - PHY_HI6220_USB [=y] && (ARCH_HISI && ARM64 ||
 COMPILE_TEST [=y])
  - PHY_RALINK_USB [=y] && (RALINK || COMPILE_TEST [=y])
  - PHY_ROCKCHIP_PCIE [=y] && (ARCH_ROCKCHIP && OF [=y] ||
 COMPILE_TEST [=y])

WARNING: unmet direct dependencies detected for OF_GPIO
  Depends on [n]: GPIOLIB [=y] && OF [=y] && HAS_IOMEM [=n]
  Selected by [y]:
  - PINCTRL_MTK [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
 COMPILE_TEST [=y]) && OF [=y]
  - PINCTRL_MT7622 [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
 COMPILE_TEST [=y]) && OF [=y] && (ARM64 || COMPILE_TEST [=y])

WARNING: unmet direct dependencies detected for FRAME_POINTER
  Depends on [n]: DEBUG_KERNEL [=y] && (CRIS || M68K || FRV || UML ||
 SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS [=n]
  Selected by [y]:
  - LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] &&
 PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND &&
 !ARC && !X86
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NPetr Vorel <petr.vorel@gmail.com>

Commit 246cf9c2 ("kbuild: Warn on selecting symbols with unmet
direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
So, the unmet direct dependencies of tristate symbols are not reported.

[Test Case]

  config MODULES
          def_bool y
          option modules

  config A
          def_bool y
          select B

  config B
          tristate "B"
          depends on m

This causes unmet dependency because 'B' is forced 'y' ignoring
'depends on m'.  This should be warned.

On the other hand, the following case ('B' is bool) should not be
warned, so 'depends on m' for bool symbols should be naturally treated
as 'depends on y'.

[Test Case2 (not unmet dependency)]

  config MODULES
          def_bool y
          option modules

  config A
          def_bool y
          select B

  config B
          bool "B"
          depends on m
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

If recursive inclusion is detected, it should fail with error
messages.  Test this.

This also tests the line numbers in the error message, fixed by
commit 5ae6fcc4 ("kconfig: fix line number in recursive inclusion
error message").
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>

Recursive dependency should be detected and warned.  Test this.

This indirectly tests the line number increments.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>

Commit 3b9a19e0 ("kconfig: loop as long as we changed some symbols
in randconfig") fixed randconfig where a choice contains a sub-choice.
Prior to that commit, the sub-choice values were not set.

I am not sure whether this is an intended feature or just something
people discovered works, but it is used in the real world;
drivers/usb/gadget/legacy/Kconfig is source'd in a choice context,
then creates a sub-choice in it.

For the test case in this commit, there are 3 possible results.

Case 1:
  CONFIG_A=y
  # CONFIG_B is not set

Case 2:
  # CONFIG_A is not set
  CONFIG_B=y
  CONFIG_C=y
  # CONFIG_D is not set

Case 3:
  # CONFIG_A is not set
  CONFIG_B=y
  # CONFIG_C is not set
  CONFIG_D=y
  CONFIG_E=y

So, this test iterates several times, and checks if the result is
either of the three.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>

Commit fbe98bb9 ("kconfig: Fix defconfig when one choice menu
selects options that another choice menu depends on") fixed defconfig
when two choices interact (i.e. calculating the visibility of a choice
requires to calculate another choice).

The test code in that commit log was based on the real world example,
and complicated.  So, I shrunk it down to the following:

defconfig.choice:
---8<---
CONFIG_CHOICE_VAL0=y
---8<---

---8<---
config MODULES
        def_bool y
        option modules

choice
        prompt "Choice"

config CHOICE_VAL0
        tristate "Choice 0"

config CHOICE_VAL1
        tristate "Choice 1"

endchoice

choice
        prompt "Another choice"
        depends on CHOICE_VAL0

config DUMMY
        bool "dummy"

endchoice
---8<---

Prior to commit fbe98bb9,

  $ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice

resulted in:

  CONFIG_MODULES=y
  CONFIG_CHOICE_VAL0=m
  # CONFIG_CHOICE_VAL1 is not set
  CONFIG_DUMMY=y

where the expected result would be:

  CONFIG_MODULES=y
  CONFIG_CHOICE_VAL0=y
  # CONFIG_CHOICE_VAL1 is not set
  CONFIG_DUMMY=y

Roughly, this weird behavior happened like this:

Symbols are calculated a couple of times.  First, all symbols are
calculated in conf_read().  The first 'choice' is evaluated to 'y'
due to the SYMBOL_DEF_USER flag, but sym_calc_choice() clears it
unless all of its choice values are explicitly set by the user.

conf_set_all_new_symbols() clears all SYMBOL_VALID flags.  Then, only
choices are calculated.  Here, the SYMBOL_DEF_USER for the first choice
has been forgotten, so it is evaluated to 'm'.  set_all_choice_values()
sets SYMBOL_DEF_USER again to choice symbols.

When calculating the second choice, due to 'depends on CHOICE_VAL0',
it triggers the calculation of CHOICE_VAL0.  As a result, SYMBOL_VALID
is set for CHOICE_VAL0.

Symbols except choices get the final chance of re-calculation in
conf_write().  In a normal case, CHOICE_VAL0 would be re-calculated,
then the first choice would be indirectly re-calculated with the
SYMBOL_DEF_USER which has been recalled by set_all_choice_values(),
which would be evaluated to 'y'.  But, in this case, CHOICE_VAL0 has
already been marked as SYMBOL_VALID, so this re-calculation does not
happen.  Then, =m from the conf_set_all_new_symbols() phase is written
out to the .config file.

Add a unit test for this naive case.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>

If tristate choice values depend on symbols set to 'm', they should be
hidden when the choice containing them is changed from 'm' to 'y'
(i.e. exclusive choice).

This issue was fixed by commit fa64e5f6 ("kconfig/symbol.c: handle
choice_values that depend on 'm' symbols").

Add a test case to avoid regression.

For the input in this unit test, there is a room for argument if
"# CONFIG_CHOICE1 is not set" should be written to the .config file.

After commit fa64e5f6, this line was written to the .config file.

With commit cb67ab2c ("kconfig: do not write choice values when
their dependency becomes n"), it is not written now.

In this test, "# CONFIG_CHOICE1 is not set" is don't care.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>

Commit cb67ab2c ("kconfig: do not write choice values when their
dependency becomes n") fixed a problem where "# CONFIG_... is not set"
for choice values are wrongly written into the .config file when they
are once visible, then become invisible later.

Add a test for this naive case.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>