It is not obvious that this might refer to an 'if', making the code
pretty cryptic:

	if (menu->list && (!menu->prompt || !menu->prompt->text)) {

Kconfig keeps the 'if' menu nodes even after flattening. Reflect that in
the example to be accurate.

No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

It's easy to miss that choices are special-cased to pass on their mode
as the parent dependency.

No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Not obvious, especially if you don't already know how choices are
implemented.

No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Kconfig was the only user of these.  With Kconfig converted to use
the default 'yy' prefix, we do not need them any more.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>

Flex and Bison provide an option to change the prefix of globally-
visible symbols.  This is useful to link multiple lexers and/or
parsers into the same executable.  However, Kconfig (and any other
host programs in kernel) uses a single lexer and parser.  I do not
see a good reason to change the default 'yy' prefix.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>

conf_unsaved is initialized by conf_read_simple(), but it is possible
to move it to conf_read() so that it can be a local variable.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Sparse reports:
  warning: symbol 'xfgets' was not declared. Should it be static?

It is declared as static, but it is missing in the definition part.
Move the definition up and remove the forward declaration.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Sparse reports:
  warning: symbol 'input_mode' was not declared. Should it be static?
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Avoids mistakes like in the following real-world example, where only the
final help string ("Say Y...") was used. This particular example was
fixed in commit 561b29e4 ("media: fix media Kconfig help syntax
issues").

  config DVB_NETUP_UNIDVB
  	...
	select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
  	---help---
  	  Support for NetUP PCI express Universal DVB card.
       help
  	Say Y when you want to support NetUP Dual Universal DVB card
        ...

This now prints the following warning:

  drivers/media/pci/netup_unidvb:13: warning: 'DVB_NETUP_UNIDVB' defined with more than one help text -- only the last one will be used

Also free() any extra help strings.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

No more users of this keyword.  Drop it according to the notice by
commit 6341e62b ("kconfig: use bool instead of boolean for type
definition attributes").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>

Commit 6341e62b ("kconfig: use bool instead of boolean for type
definition attributes") did treewide replacement of 'boolean', and
also mentioned the keyword 'boolean' would be dropped later on.

Some years have passed, but it has not happened yet.  Meanwhile, some
new instances have come up.

I am really going to drop this keyword.  I need to do the replacement
once again.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

menu_end_entry() is empty and completely unused as far as I can tell:

	$ git log -G menu_end_entry --oneline
	a02f0570 [PATCH] kconfig: improve error handling in the parser
	1da177e4 Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as
well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each
config, menuconfig, and comment is parsed. IMO it hurts more than it
helps in that case by making the parsing code look more complicated at a
glance than it really is, and I suspect it doesn't get used much.

Tested by running the Kconfiglib test suite, which indirectly verifies
that the .config files generated by the C implementation for each
defconfig file in the kernel stays the same.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Many of these functions are quite the head scratchers if you don't know
what they're trying to do. Document them.

Also make it clear which functions rewrite expressions in-place and
which return new expressions. This prevents memory errors.

No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

It's tricky to figure out what it does (and how) without staring at the
code for a long time. Document it to make it more transparent.

No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

When propagating dependencies from parents after parsing, an expression
node is allocated if the parent symbol is a 'choice'. This node was
never freed.

Outline of leak:

	if (sym && sym_is_choice(sym)) {
		...
		*Allocate (in this case only)*
		parentdep = expr_alloc_symbol(sym);
	} else if (parent->prompt)
		parentdep = parent->prompt->visible.expr;
	else
		parentdep = parent->dep;

	for (menu = parent->list; menu; menu = menu->next) {
		...
		*Copy*
		basedep = expr_alloc_and(expr_copy(parentdep), basedep);
		...
	}
	*parentdep lost if the parent is a choice!*

Fix by freeing 'parentdep' after the loop if the parent symbol is a
choice. Note that this only frees the expression node and not the choice
symbol itself.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 1,608 bytes in 67 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 0 bytes in 0 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Only the E_NOT operand and not the E_NOT node itself was freed, due to
accidentally returning too early in expr_free(). Outline of leak:

	switch (e->type) {
	...
	case E_NOT:
		expr_free(e->left.expr);
		return;
	...
	}
	*Never reached, 'e' leaked*
	free(e);

Fix by changing the 'return' to a 'break'.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 44,448 bytes in 1,852 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 1,608 bytes in 67 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

expr_trans_compare() always allocates and returns a new expression,
giving the following leak outline:

	...
	*Allocate*
	basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
	...
	for (menu = parent->next; menu; menu = menu->next) {
		...
		*Copy*
		dep2 = expr_copy(basedep);
		...
		*Free copy*
		expr_free(dep2);
	}
	*basedep lost!*

Fix by freeing 'basedep' after the loop.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,376 bytes in 14,349 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 44,448 bytes in 1,852 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

If a 'mainmenu' entry appeared in the Kconfig files, two things would
leak:

	- The 'struct property' allocated for the default "Linux Kernel
	  Configuration" prompt.

	- The string for the T_WORD/T_WORD_QUOTE prompt after the
	  T_MAINMENU token, allocated on the heap in zconf.l.

To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
if there's no 'mainmenu' and adds the default prompt. That means the
prompt only gets allocated once regardless of whether there's a
'mainmenu' statement or not, and managing it becomes simple.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,568 bytes in 14,352 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,440 bytes in 14,350 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The following strings would leak before this change:

	- option env="LEAKED"
	- option defconfig_list="LEAKED"

These come in the form of T_WORD tokens and are always allocated on the
heap in zconf.l. Free them.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,616 bytes in 14,355 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,568 bytes in 14,352 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The 'source_stmt' nonterminal takes a 'prompt', which consists of either
a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the
heap in zconf.l and need to have their associated strings freed. Free
them.

The existing code already makes sure to always copy the string, but add
a warning to sym_expand_string_value() to make it clear that the string
must be copied, just in case.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 387,504 bytes in 15,545 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,616 bytes in 14,355 blocks
	   ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Prior to this fix, zconf.y did not free symbol names from zconf.l in
these contexts:

	- After T_CONFIG ('config LEAKED')
	- After T_MENUCONFIG ('menuconfig LEAKED')
	- After T_SELECT ('select LEAKED')
	- After T_IMPLY ('imply LEAKED')
	- After T_DEFAULT in a choice ('default LEAKED')

All of these come in the form of T_WORD tokens, which always have their
associated string allocated on the heap in zconf.l and need to be freed.

Fix by introducing a new nonterminal 'nonconst_symbol' which takes a
T_WORD, fetches the symbol, and then frees the T_WORD string. The
already existing 'symbol' nonterminal works the same way but also
accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE
should not be accepted in any of the contexts above, so the 'symbol'
nonterminal can't be reused here.

Fetching the symbol in 'nonconst_symbol' also removes a bunch of
sym_lookup() calls from actions.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 711,571 bytes in 37,756 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 387,504 bytes in 15,545 blocks
           ...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

zconf.lex.c is generated by flex, zconf.tab.c by bison.  Instead of
running flex and bison during the kernel building, we conventionally
version-control those artifacts with _shipped suffix.

It is tedious to manually regenerate them every time we change the
real sources, zconf.l and zconf.y.

Remove the _shipped files and switch over to build-time generation
of the intermediate C files.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix.  During the kernel building,
they are simply shipped (copied) removing the suffix.

This approach can reduce external tool dependency for the kernel build,
but it is tedious to manually regenerate such artifacts from developers'
point of view.  (We need to do "make REGENERATE_PARSERS=1" every time
we touch real source files such as *.l, *.y)

Some months ago, I sent out RFC patches to run flex, bison, and gperf
during the build.

In the review and test, Linus noticed gperf-3.1 had changed the lookup
function prototype.  Then, the use of gperf in kernel was entirely
removed by commit bb3290d9 ("Remove gperf usage from toolchain").

This time, I tested several versions of flex and bison, and I was not
hit by any compatibility issue except a flaw in flex-2.6.3; if you
generate lexer for dtc and genksyms with flex-2.6.3, you will see
"yywrap redefined" warning.  This was not intentional, but a bug,
fixed by flex-2.6.4.  Otherwise, both flex and bison look fairly
stable for a long time.

This commit prepares some build rules to remove the _shipped files.
Also, document minimal requirement for flex and bison.

Rationale for the minimal version:
The -Wmissing-prototypes option of GCC warns "no previous prototype"
for lexers generated by flex-2.5.34 or older, so I chose 2.5.35 as the
required version for flex.  Flex-2.5.35 was released in 2008.  Bison
looks more stable.  I did not see any problem with bison-2.0, released
in 2004.  I did not test bison-1.x, but bison-2.0 should be old enough.

Tested flex versions:
  2.5.35
  2.5.36
  2.5.37
  2.5.39
  2.6.0
  2.6.1
  2.6.2
  2.6.3   (*)
  2.6.4

 (*) flex-2.6.3 causes "yywrap redefined" warning

Tested bison versions:
  2.0
  2.1
  2.2
  2.3
  2.4
  2.4.1
  2.5.1
  2.6
  2.6.1
  2.6.2
  2.6.3
  2.6.4
  2.6.5
  2.7
  2.7.1
  3.0
  3.0.1
  3.0.2
  3.0.3
  3.0.4
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Allow users to use their favorite lexer / parser generators.
This is useful for me to test various flex and bison versions.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Commit 1c199f28 ("kbuild: document recursive dependency limitation
/ resolution") probably intended to show a hint along with "recursive
dependency detected!" error, but it missed to add {...} guard, and the
hint is displayed in every loop of the dep_stack traverse, annoyingly.

This error was detected by GCC's -Wmisleading-indentation when switching
to build-time generation of lexer/parser.

scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’:
scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
   if (stack->sym == last_sym)
   ^~
scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
    fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n");
    ^~~~~~~

I could simply add {...} to surround the three fprintf(), but I rather
chose to move the hint after the loop to make the whole message readable.

Fixes: 1c199f28 ("kbuild: document recursive dependency limitation / resolution"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>

Kconfig currently doesn't handle 'm' appearing in a Kconfig file before
the modules symbol is defined (the symbol with 'option modules'). The
problem is the following code, which runs during parsing:

	/* change 'm' into 'm' && MODULES */
	if (e->left.sym == &symbol_mod)
		return expr_alloc_and(e, expr_alloc_symbol(modules_sym));

If the modules symbol has not yet been defined, modules_sym is NULL,
giving an invalid expression.

Here is a test file where both BEFORE_1 and BEFORE_2 trigger a segfault.
If the modules symbol is removed, all symbols trigger segfaults.

	config BEFORE_1
		def_tristate y if m

	if m
	config BEFORE_2
		def_tristate y
	endif

	config MODULES
		def_bool y
		option modules

	config AFTER_1
		def_tristate y if m

	if m
	config AFTER_2
		def_tristate y
	endif

Fix the issue by rewriting 'm' in menu_finalize() instead. This function
runs after parsing and is the proper place to do it. The following
existing code in conf_parse() in zconf.y ensures that the modules symbol
exists at that point:

	if (!modules_sym)
		modules_sym = sym_find( "n" );

	...

	menu_finalize(&rootmenu);

The following tests were done to ensure no functional changes for
configurations that don't reference 'm' before the modules symbol:

	- zconfdump(stdout) was run with ARCH=x86 and ARCH=arm before
	  and after the change and verified to produce identical output.
	  This function prints all symbols, choices, and menus together
	  with their properties and their dependency expressions. A
	  rewritten 'm' appears as 'm && MODULES'.

	  A small annoyance is that the assert(len != 0) in xfwrite()
	  needs to be disabled in order to use zconfdump(), because it
	  chokes on e.g. 'default ""'.

	- The Kconfiglib test suite was run to indirectly verify that
	  alldefconfig, allyesconfig, allnoconfig, and all defconfigs in
	  the kernel still generate the same final .config.

	- Valgrind was used to check for memory errors and (new) memory
	  leaks.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

menu_finalize() is one of the more opaque parts of Kconfig, and I need
to make some changes to it to fix an issue related to modules. Add some
comments related to expression rewriting and dependency propagation as a
review aid. They will also help other people trying to understand the
code.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

More directly describes the only thing it does.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Looks like a change to a comment in zconf.y was never committed, because
the updated version only appears it zconf.tab.c_shipped. Update the
comment in zconf.y to match.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Visibility and choices in particular might be a bit tricky to figure
out.

Also fix existing comment to point out that P_MENU is also used for
menus.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Understanding what it represents helps a lot when reading the code, and
it's not obvious, so document it.

The ROOT_MENU flag is only set and tested by the gconf and qconf front
ends, so leave it undocumented here. The obvious guess for what it means
is correct.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This will catch mistakes like in the following real-world example, where
a "CONFIG_" prefix snuck in, making an undefined symbol the default:

	choice
		prompt "Compiler optimization level"
		default CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE

	config CC_OPTIMIZE_FOR_PERFORMANCE
		...

	config CC_OPTIMIZE_FOR_SIZE
		...

	endchoice

This now prints the following warning:

	init/Kconfig:1036:warning: choice default symbol 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE' is not contained in the choice

Cases where the default symbol belongs to the wrong choice are also
detected.

(The mistake is harmless here: Since the default symbol is not visible,
the choice falls back on using the first visible symbol as the default,
which is CC_OPTIMIZE_FOR_PERFORMANCE, as intended.)

Discovered while playing around with Kconfiglib
(https://github.com/ulfalizer/Kconfiglib).
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Pull ARM fix from Russell King:
 "Just one fix this time around, for the late commit in the merge window
  that triggered a problem with qemu. Qemu is apparently also going to
  receive a fix for the discovered issue"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: avoid faulting on qemu

Pull i2c fixes from Wolfram Sang:
 "Here are two bugfixes for I2C, fixing a memleak in the core and irq
  allocation for i801.

  Also three bugfixes for the at24 eeprom driver which Bartosz collected
  while taking over maintainership for this driver"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  eeprom: at24: check at24_read/write arguments
  eeprom: at24: fix reading from 24MAC402/24MAC602
  eeprom: at24: correctly set the size for at24mac402
  i2c: i2c-boardinfo: fix memory leaks on devinfo
  i2c: i801: Fix Failed to allocate irq -2147483648 error

Merge tag 'hwmon-for-linus-v4.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:
 "Fixes:

   - Drop reference to obsolete maintainer tree

   - Fix overflow bug in pmbus driver

   - Fix SMBUS timeout problem in jc42 driver

  For the SMBUS timeout handling, we had a brief discussion if this
  should be considered a bug fix or a feature. Peter says "it fixes real
  problems where the application misbehave due to faulty content when
  reading from an eeprom", and he needs the patch in his company's v4.14
  images. This is good enough for me and warrants backport to stable
  kernels"

* tag 'hwmon-for-linus-v4.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (jc42) optionally try to disable the SMBUS timeout
  hwmon: (pmbus) Use 64bit math for DIRECT format values
  hwmon: Drop reference to Jean's tree

Merge tag 'at24-4.15-fixes-for-wolfram' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-current

Please consider pulling the following fixes for v4.15. While it doesn't
fix any regression introduced in the v4.15 merge window, we have a
feature in at24 since linux v4.8 - reading the mac address block from
at24mac series - which turned out to be not working.

This pull request contains changes that fix it together with a patch
that hardens the read and write argument sanitization with
out-of-bounds checks that were missing.

Pull NFS client fixes from Anna Schumaker:
 "These patches fix a problem with compiling using an old version of
  gcc, and also fix up error handling in the SUNRPC layer.

   - NFSv4: Ensure gcc 4.4.4 can compile initialiser for
     "invalid_stateid"

   - SUNRPC: Allow connect to return EHOSTUNREACH

   - SUNRPC: Handle ENETDOWN errors"

* tag 'nfs-for-4.15-2' of git://git.linux-nfs.org/projects/anna/linux-nfs:
  SUNRPC: Handle ENETDOWN errors
  SUNRPC: Allow connect to return EHOSTUNREACH
  NFSv4: Ensure gcc 4.4.4 can compile initialiser for "invalid_stateid"

Pull xfs fixes from Darrick Wong:
 "Here are some bug fixes for 4.15-rc2.

   - fix memory leaks that appeared after removing ifork inline data
     buffer

   - recover deferred rmap update log items in correct order

   - fix memory leaks when buffer construction fails

   - fix memory leaks when bmbt is corrupt

   - fix some uninitialized variables and math problems in the quota
     scrubber

   - add some omitted attribution tags on the log replay commit

   - fix some UBSAN complaints about integer overflows with large sparse
     files

   - implement an effective inode mode check in online fsck

   - fix log's inability to retry quota item writeout due to transient
     errors"

* tag 'xfs-4.15-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: Properly retry failed dquot items in case of error during buffer writeback
  xfs: scrub inode mode properly
  xfs: remove unused parameter from xfs_writepage_map
  xfs: ubsan fixes
  xfs: calculate correct offset in xfs_scrub_quota_item
  xfs: fix uninitialized variable in xfs_scrub_quota
  xfs: fix leaks on corruption errors in xfs_bmap.c
  xfs: fortify xfs_alloc_buftarg error handling
  xfs: log recovery should replay deferred ops in order
  xfs: always free inline data before resetting inode fork during ifree

Merge tag 'riscv-for-linus-4.15-rc2_cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux

Pull RISC-V cleanups and ABI fixes from Palmer Dabbelt:
 "This contains a handful of small cleanups that are a result of
  feedback that didn't make it into our original patch set, either
  because the feedback hadn't been given yet, I missed the original
  emails, or we weren't ready to submit the changes yet.

  I've been maintaining the various cleanup patch sets I have as their
  own branches, which I then merged together and signed. Each merge
  commit has a short summary of the changes, and each branch is based on
  your latest tag (4.15-rc1, in this case). If this isn't the right way
  to do this then feel free to suggest something else, but it seems sane
  to me.

  Here's a short summary of the changes, roughly in order of how
  interesting they are.

   - libgcc.h has been moved from include/lib, where it's the only
     member, to include/linux. This is meant to avoid tab completion
     conflicts.

   - VDSO entries for clock_get/gettimeofday/getcpu have been added.
     These are simple syscalls now, but we want to let glibc use them
     from the start so we can make them faster later.

   - A VDSO entry for instruction cache flushing has been added so
     userspace can flush the instruction cache.

   - The VDSO symbol versions for __vdso_cmpxchg{32,64} have been
     removed, as those VDSO entries don't actually exist.

   - __io_writes has been corrected to respect the given type.

   - A new READ_ONCE in arch_spin_is_locked().

   - __test_and_op_bit_ord() is now actually ordered.

   - Various small fixes throughout the tree to enable allmodconfig to
     build cleanly.

   - Removal of some dead code in our atomic support headers.

   - Improvements to various comments in our atomic support headers"

* tag 'riscv-for-linus-4.15-rc2_cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux: (23 commits)
  RISC-V: __io_writes should respect the length argument
  move libgcc.h to include/linux
  RISC-V: Clean up an unused include
  RISC-V: Allow userspace to flush the instruction cache
  RISC-V: Flush I$ when making a dirty page executable
  RISC-V: Add missing include
  RISC-V: Use define for get_cycles like other architectures
  RISC-V: Provide stub of setup_profiling_timer()
  RISC-V: Export some expected symbols for modules
  RISC-V: move empty_zero_page definition to C and export it
  RISC-V: io.h: type fixes for warnings
  RISC-V: use RISCV_{INT,SHORT} instead of {INT,SHORT} for asm macros
  RISC-V: use generic serial.h
  RISC-V: remove spin_unlock_wait()
  RISC-V: `sfence.vma` orderes the instruction cache
  RISC-V: Add READ_ONCE in arch_spin_is_locked()
  RISC-V: __test_and_op_bit_ord should be strongly ordered
  RISC-V: Remove smb_mb__{before,after}_spinlock()
  RISC-V: Remove __smp_bp__{before,after}_atomic
  RISC-V: Comment on why {,cmp}xchg is ordered how it is
  ...