This reverts commit 197a1e96.

The consumers of the mousedev data in MIPS uperspace assume
that the data is little endian. So if we are running on a
big endian CPU we force the output data to be little endian.

Note: this may be reverted if/when the consuming devices
add options, or options are found that can byte swap the
data in userspace. This is simply a commit of convienience
to demonstrate an issue.

Signed-off-by: Richard Griffiths <richard.griffiths@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

commit id 79896cf4 use request_resource() to replace the
insert_resource() in pci_claim_resource(). But this does
not fit the malta pci. With the new request_resource()
kernel allocate a collision io resource for PCI ethernet.
This disturb the PCI io space. One device use 0x1000 - 0x103f
and the PCI ethernet use 0x1020 - 0x103f and this is cause the
ethernet can't be accessed.

This fix supplies a fixup function to fix the ioport collision.

The old kernel log:

pci 0000:00:0a.1: BAR 4: assigned [io  0x1040-0x104f]
pci 0000:00:0a.1: BAR 4: set to [io  0x1040-0x104f] (PCI address [0x1040-0x104f]
pci 0000:00:0a.2: BAR 4: assigned [io  0x1000-0x101f]
pci 0000:00:0a.2: BAR 4: set to [io  0x1000-0x101f] (PCI address [0x1000-0x101f]
pci 0000:00:0a.3: address space collision: [io  0x1000-0x103f] already in use
pci 0000:00:0a.3: quirk: [io  0x1000-0x103f] claimed by PIIX4 ACPI
pci 0000:00:0a.3: address space collision: [io  0x1100-0x110f] already in use
pci 0000:00:0a.3: quirk: [io  0x1100-0x110f] claimed by PIIX4 SMB
pci 0000:00:0a.3: BAR 7: [io  0x1000-0x103f] has bogus alignment
pci 0000:00:0a.3: BAR 8: [io  0x1100-0x110f] has bogus alignment
pci 0000:00:0b.0: BAR 0: assigned [io  0x1020-0x103f]
pci 0000:00:0b.0: BAR 0: set to [io  0x1020-0x103f] (PCI address [0x1020-0x103f]
pci 0000:00:0b.0: BAR 1: assigned [mem 0x10111000-0x1011101f]
pci 0000:00:0b.0: BAR 1: set to [mem 0x10111000-0x1011101f] (PCI address [0x10111000-0x1011101f]
pci 0000:00:0b.0: BAR 6: assigned [mem 0x10000000-0x100fffff pref]
pci 0000:00:0c.0: BAR 0: assigned [mem 0x10110000-0x10110fff]
pci 0000:00:0c.0: BAR 0: set to [mem 0x10110000-0x10110fff] (PCI address [0x10110000-0x10110fff]
pci 0000:00:0c.0: BAR 1: assigned [mem 0x10100000-0x1010ffff]
pci 0000:00:0c.0: BAR 1: set to [mem 0x10100000-0x1010ffff] (PCI address [0x10100000-0x1010ffff]
......
pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
pcnet32: No access methods
......
......

And a fixup to the original change:

[
   mips: malta PCI fixup, fix __init annotation warning

   Currently we see the following link warning:

     WARNING: vmlinux.o(.pci_fixup_final+0xefc): Section mismatch in
     reference from the variable __pci_fixup_malta_pcnet32_ioports_fixup164
     to the function .init.text:malta_pcnet32_ioports_fixup()
     The variable __pci_fixup_malta_pcnet32_ioports_fixup164 references
     a function __init malta_pcnet32_ioports_fixup().
     This is often seen when error handling in the init function
     uses functionality in the exit path.
     The fix is often to remove the __init annotation of
     malta_pcnet32_ioports_fixup() so it may be used outside an exit section.

   This is from the addition of "mti_malta32: fix the pci resource conflicts"
   (5c19c1c3 on v5.2/standard/mti-malta32) - which is a relatively old
   commit, but w/o a malta+PCnet32, I can't speak to whether this commit is
   still needed, or if the PCI resource overlap was solved another way.

   Hence here, we take the safe path and just remove the __init annotation.
]

Signed-off-by: Jack Tan <jack.tan@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

On 5.10+ we are seeing some MSI interrupt assignment errors. In
our emulated 32bit platform, we are lacking this support. To avoid
the warnings, we define our own platform and select the MSI arch
fallback, which handles the missing support.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

At the moment it is currently possible to sneak a core into nohz_full
that lies between nr_possible and NR_CPUS - but you won't "see" it
because cpumask_pr_args() implicitly hides anything above nr_cpu_ids.

This becomes a problem when the nohz_full CPU set doesn't contain at
least one other valid nohz CPU - in which case we end up with the
tick_nohz_full_running set and no tick core specified, which trips an
endless sequence of WARN() and renders the machine unusable.

I inadvertently opened the door for this when fixing an overly
restrictive nohz_full conditional in the below Fixes: commit - and then
courtesy of my optimistic ACPI reporting nr_possible of 64 (the default
Kconfig for NR_CPUS) and the not-so helpful implict filtering done by
cpumask_pr_args, I unfortunately did not spot it during my testing.

So here, I don't rely on what was printed anymore, but code exactly what
our restrictions should be in order to be aligned with rcu_nocbs - which
was the original goal.  Since the checks lie in "__init" code it is largely
free for us to do this anyway.

Building with NOHZ_FULL and NR_CPUS=128 on an otherwise defconfig, and
booting with "rcu_nocbs=8-127 nohz_full=96-127" on the same 16 core T5500
Dell machine now results in the following (only relevant lines shown):

 smpboot: Allowing 64 CPUs, 48 hotplug CPUs
 setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:64 nr_node_ids:2
 housekeeping: kernel parameter 'nohz_full=' or 'isolcpus=' contains nonexistent CPUs.
 housekeeping: kernel parameter 'nohz_full=' or 'isolcpus=' has no valid CPUs.
 rcu:     RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=64.
 rcu:     Note: kernel parameter 'rcu_nocbs=', 'nohz_full', or 'isolcpus=' contains nonexistent CPUs.
 rcu:     Offload RCU callbacks from CPUs: 8-63.

One can see both new housekeeping checks are triggered in the above.
The same invalid boot arg combination would have previously resulted in
an infinitely scrolling mix of WARN from all cores per tick on this box.

Link: https://lore.kernel.org/lkml/20211206145950.10927-2-paul.gortmaker@windriver.com


Fixes: 915a2bc3 ("sched/isolation: Reconcile rcu_nocbs= and nohz_full=")
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

In the event debugfs is not mounted, or if built with the .config
setting DEBUG_FS_ALLOW_NONE chosen, this gives the sysadmin access
to reset the WARN_ONCE() state on a periodic basis.

Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com


Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Existing documentation has a write of "1" to clear/reset all the
WARN_ONCE and similar to the as-booted state, so they can possibly
be re-triggered again during debugging/testing.

But having them auto-reset once a day, or once a week, might shed
valuable information to a sysadmin on what the system is doing while
trying to debug an issue.

Here we extend the existing debugfs variable to bind a timer to the
written value N, so that it will reset every N minutes, for N>1.
Writing a zero will clear any previously set timer value.

The pre-existing behaviour of writing N=1 will do a one-shot clear.

Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com


Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

The existing clear_warn_once variable is write-only; used as per the
documentation to reset the warn_once to as-booted state with:

	echo 1 > /sys/kernel/debug/clear_warn_once

The objective is to expand on that functionality, which requires the
debugfs variable to be read/write and not just write-only.

Here, we deal with the debugfs boilerplate associated with converting
it from write-only to read-write, in order to factor that out for easier
review, and for what may be a possible future useful bisect point.

Existing functionality is unchanged - the only difference is that we
have tied in a variable that lets you now read the variable and see
the last value written.

Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com


Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

These options are not needed with OE/Yocto since compiler is already
passing these options via TOOLCHAIN_OPTIONS, having these options infact
regressed OE builds because build time --sysroot on OE cross compiler is
/not/exist and that creates problems where clang can no more find system
headers anymore during compilation

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Clang warns on 32-bit ARM on this comparision

libbpf.c:10497:18: error: result of comparison of constant 4294967296 with expression of type 'size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
        if (ref_ctr_off >= (1ULL << PERF_UPROBE_REF_CTR_OFFSET_BITS))
            ~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Check for platform long int to be larger than 32-bits before enabling
this check, it false on 32bit anyways.

Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Song Liu <song@kernel.org>
Cc: Yonghong Song <yhs@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Record PC value from regs[15], it should be regs[32], which cause perf
parser the backtrace failed.

Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

The 32bit x86 perf build does not find the system definitions of error
return values, hence we end up with:

| In file included from util/libunwind/x86_32.c:32:0:
| util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function 'libunwind__x86_reg_id':
| util/libunwind/../../arch/x86/util/unwind-libunwind.c:109:11: error: 'EINVAL' undeclared (first use in this function); did you mean 'UNW_EINVAL'?
|    return -EINVAL;
|            ^~~~~~
|            UNW_EINVAL

By explicitly including errno.h, we can fix this build without impacting
other architectures.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

On MIPS64, "__u64" is "unsigned long" type, so the "%llu" specifier will cause
build error on MIPS64.

Convert __u64 to unsigned long long in those sprintf calls to avoid the build
error.

Signed-off-by: Yang Shi <yang.shi@windriver.com>

Taken from: https://lkml.org/lkml/2013/6/20/80



Fix the following errors on gcc 4.8.1 / x86:

bench/numa.c: In function worker_thread:
bench/numa.c:1113:20: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
    if (diff.tv_sec >= g->p.nr_secs) {
                    ^
bench/numa.c:1161:6: error: format %lx expects argument of type long unsigned int, but argument 5 has type u64 [-Werror=format=]
      process_nr, thread_nr, runtime_ns_max / bytes_done, val);
      ^
Signed-off-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Signed-off-by: Yang Shi <yang.shi@windriver.com>

CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
work with hosts that have "/usr/include/slang/slang.h" as well as hosts
that have "/usr/include/slang.h". This path can cause compile warnings
like:

cc1: warning: '/usr/include/slang' doesn't exists.

or

cc1: warning: include location "/usr/include/slang" is unsafe for
cross-compilation [-Wpoison-system-directories]

Then in some cases warnings become errors if WERROR is enabled hence
build errors.

To fix this issue, we can use -idirafter to downgrade the priority of the
default hard coded path. We can also make the slang include directory
a variable, to allow the user to specify SLANG_INC and set their own
include location. And add a '=' prefix to indicate better
compatibility with sysroot/cross compile cases.

Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>

Allow Python.h to find the definitions it needs on mips i.e. get rid
of the error: "_ABIN32" is not defined.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

Otherwise we get the sysroot path appended to the build path, not what
we want.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

If libperl isn't found, display a message to that effect along with
some hints on how to fix it.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

Large parts of perf use bool variables and assignments.
Rather than depending on transient includes, we force it
by including <stdbool.h> directly in perf.h

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

The prandom_u32() is just wrapper of get_random_u32() and has been
removed by commit de492c83 ("prandom: remove unused functions").
So use get_random_u32() directly.

Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Introduced in commit 16b6ba6d7f6b0e8a2baeb14b128df0bb0a0a5680
("FAT: Add CONFIG_VFAT_FS_NO_DUALNAMES option"), the use of
random32 is no longer allowed.

The compatibility wrappers have been removed, so we have to
align the additions from this older patch to match upstream
commit 496f2f93 ("random32: rename
random32 to prandom")  which does:

    This renames all random32 functions to have 'prandom_' prefix as follows:

      void prandom_seed(u32 seed);      /* rename from srandom32() */
      u32 prandom_u32(void);            /* rename from random32() */

    [...]

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

This patch adds a new flag field 'FAT_NO_83NAME' for FAT files. When
this flag is set on an 8.3 FAT entry, both the MSDOS and VFAT
filesystems will skip the entry. For MSDOS this makes the file
inaccessible. For VFAT it makes the file only accessible by the long
filename.

Signed-off-by: Andrew Tridgell <tridge@samba.org>

When this option is enabled this will refuse to create new files with
long names. Accessing existing files with long names will continue to
work.

File names to be created must conform to the 8.3 format.  Mixed case is
not allowed in either the prefix or the suffix.

Signed-off-by: Andrew Tridgell <tridge@samba.org>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

This patch adds a new config option VFAT_FS_NO_DUALNAMES. When
VFAT_FS_NO_DUALNAMES is enabled, VFAT will never create a file with
both a long and a short filename. If a long filename is needed, then
dummy bytes are stored in the 8.3 entry, and the 8.3 entry is marked
as having no short name using the FAT_NO_83NAME flag.

Signed-off-by: Andrew Tridgell <tridge@samba.org>

The following build warning helps us find a real mishandling of array length.

fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' call
is the same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]

If an array is passed as a function parameter it'll be treated as a simple
pointer and thus sizeof will return the length of a pointer rather than the
length of the array.

Add and pass the buffer length to make it work correctly.

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

commit c1632a0f [fs: port ->setattr() to
pass mnt_idmap] changes the parameters to attr operations to a
mnt_idmap.

yaffs2 isn't using the user namespace directly, so we switch to the
default map.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

commit 900d156b [block: remove bdevname]
removed this function, we follow the pattern and use sprintf as a
replacement.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

This is a first pass of changing yaffs2 to use the new read_folio,
versus readpage routines. We also adjust writepage to no longer use
flags, which have been dropped in 5.19+

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

When run below command to mount a yaffs2 FS to nor flash, there
is kernel panic as below:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
......
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 335 Comm: mount Not tainted 5.10.73-yocto-standard #1
......
Call trace:
 yaffs_internal_read_super.constprop.0+0x24c/0x6fc
 yaffs2_internal_read_super_mtd+0x28/0x40
 mount_bdev+0x1cc/0x200
 ......
 el0_sync_handler+0x1a4/0x1b0
 el0_sync+0x180/0x1c0
Because in function yaffs_get_mtd_device(), it check the type of
mtd device. If it is not NAND flash, NULL will be returned. This
causes kernel panic if the ret value is not checked whether it
is NULL or not. So, replace IS_ERR with IS_ERR_OR_NULL to check
both ERR and NULL.

Signed-off-by: Meng Li <Meng.Li@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

In yaffs_fix_null_name, "if (strnlen(name, YAFFS_MAX_NAME_LENGTH) == 0)"
is used to judge if the "name" string is zero length. But this is wrong
when the "name" char array size is less than YAFFS_MAX_NAME_LENGTH and
this will trigger compile warnig as below:

fs/yaffs2/yaffs_guts.c:4501:13: warning: ‘strnlen’ specified bound 255 exceeds source size 16 [-Wstringop-overread]
 4501 |         if (strnlen(name, YAFFS_MAX_NAME_LENGTH) == 0) {
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Let's use buffer_size to do this instead of YAFFS_MAX_NAME_LENGTH
because buffer_size is passed to yaffs_fix_null_name by caller with
appropriate value which is fixed to the size of "name" char array.

Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

The definition of BDEVNAME_SIZE has moved, so we add the new .h

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

A variable declaration landed one function higher than intended,
leading to an unused variable warning for configurations with
YAFFS_USE_DIR_ITERATE=y and a build failure for configurations
with the same being unset.

Fixes: "yaffs: Fix build failure by handling inode i_version with proper atomic API"
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

commit  27f18203551940abf35826a66978daf1b8124c6b from
git://www.aleph1.co.uk/yaffs2



Thanks to Jisheng Zhang <Jisheng.Zhang@synaptics.com> for supplying this patch

There is a kernel memory leak observed when the proc file /proc/yaffs
is read. This reason is that in yaffs_proc_open, single_open is called
and the respective release function is not called during release.

Fix with correct release function - single_release().

Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

When kernel booting, mount_block_root will be called to judge
the filesystem type of root device. Then .mount function in file_system_type
structure will do the check operation. But yaffs filesystem has a
relaxed examination because as a filesystem for NAND Flash, it doesn't
examinate whether the root device is the MTD NAND device. This results
that yaffs filesystem will do mount operation even though the root device
is a MMC card with a btrfs filesystem, and will crash kernel after
mounting failed. The crash log is as below:

md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
yaffs: dev is 187695107 name is "mmcblk0p3" rw
yaffs: passed flags ""
yaffs: dev is 187695107 name is "mmcblk0p3" rw
yaffs: passed flags ""
------------[ cut here ]------------
kernel BUG at fs/yaffs2/yaffs_getblockinfo.h:30!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.2.24-yocto-standard+ #250
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : yaffs_rd_chunk_tags_nand+0xf0/0x110
lr : yaffs_rd_chunk_tags_nand+0x108/0x110
sp : ffffff801003b770
x29: ffffff801003b770 x28: ffffffc876fe8000
x27: 00000000000c0000 x26: 0000000000000000
x25: 00000000ffffffe1 x24: 0000000000010000
x23: 0000000000000000 x22: ffffff8011228000
x21: 000000000000005f x20: ffffff801003b890
x19: ffffffc876fe8000 x18: ffffffffffffffff
x17: 0000000000000000 x16: 0000000000000000
x15: ffffff80112285c8 x14: ffffff801137d228
x13: ffffff801137ce74 x12: ffffff8011246000
x11: 0000000000000000 x10: ffffff801137c000
x9 : 0000000000000000 x8 : 0000000000000007
x7 : 000000000000015c x6 : ffffff801137c490
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000ffffffff x2 : 50c80792e0663400
x1 : 0000000000000000 x0 : 0000000000000037
Call trace:
 yaffs_rd_chunk_tags_nand+0xf0/0x110
 yaffs_summary_read+0x10c/0x2e0
 yaffs2_scan_backwards+0x28c/0xf58
 yaffs_guts_initialise+0x71c/0x7a0
 yaffs_internal_read_super.isra.20+0x4ec/0x838
 yaffs2_internal_read_super_mtd+0x2c/0x48
 mount_bdev+0x1a4/0x1e0
 yaffs2_mount+0x44/0x58
 legacy_get_tree+0x34/0x60
 vfs_get_tree+0x34/0x120
 do_mount+0x708/0x980
 ksys_mount+0x9c/0x110
 mount_block_root+0x128/0x29c
 mount_root+0x148/0x17c
 prepare_namespace+0x178/0x1c0
 kernel_init_freeable+0x370/0x390
 kernel_init+0x18/0x110
 ret_from_fork+0x10/0x1c
Code: d65f03c0 f00069c0 b9440400 37f00060 (d4210000)
---[ end trace 68aa0995bdf59f76 ]---
BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:34
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
Preemption disabled at:
[<ffffff80100a4598>] debug_exception_enter+0x30/0x40
CPU: 3 PID: 1 Comm: swapper/0 Tainted: G      D           5.2.24-yocto-standard+ #250
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
Call trace:
 dump_backtrace+0x0/0x148
 show_stack+0x24/0x30
 dump_stack+0x98/0xbc
 ___might_sleep+0x130/0x188
 __might_sleep+0x58/0x90
 exit_signals+0x44/0x258
 do_exit+0xb4/0xa38
 die+0x1bc/0x1e0
 bug_handler+0x48/0x98
 call_break_hook+0x7c/0xa8
 brk_handler+0x28/0x68
 do_debug_exception+0xc4/0x188
 el1_dbg+0x18/0x8c
 yaffs_rd_chunk_tags_nand+0xf0/0x110
 yaffs_summary_read+0x10c/0x2e0
 yaffs2_scan_backwards+0x28c/0xf58
 yaffs_guts_initialise+0x71c/0x7a0
 yaffs_internal_read_super.isra.20+0x4ec/0x838
 yaffs2_internal_read_super_mtd+0x2c/0x48
 mount_bdev+0x1a4/0x1e0
 yaffs2_mount+0x44/0x58
 legacy_get_tree+0x34/0x60
 vfs_get_tree+0x34/0x120
 do_mount+0x708/0x980
 ksys_mount+0x9c/0x110
 mount_block_root+0x128/0x29c
 mount_root+0x148/0x17c
 prepare_namespace+0x178/0x1c0
 kernel_init_freeable+0x370/0x390
 kernel_init+0x18/0x110
 ret_from_fork+0x10/0x1c
note: swapper/0[1] exited with preempt_count 1
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,20002004
Memory Limit: none
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Use yaffs_get_mtd_device to add strict check.

Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

The function yaffs_get_mtd_device use wrong function to retrieve
mtd_info structure (using yaffs_get_mtd_device itself will cause
dead loop).

Use get_mtd_device to do this.

Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

i_version in struct inode has changed to atomic64_t in mainline kernel.
This patch handles i_version with proper atomic API.

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

when using yaffs2 filesystem, after umounting, yaffs_put_super
function doesn't free the context_os memory, it is malloced in
yaffs_internal_read_super.

unreferenced object 0xd9103980 (size 64):
  comm "mount", pid 5694, jiffies 159571 (age 45.150s)
  hex dump (first 32 bytes):
    80 39 10 d9 80 39 10 d9 00 b0 83 dc 00 b0 07 d9 .9...9..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  backtrace:
    [<c0131b20>] kmem_cache_alloc_trace+0x188/0x350
    [<c0386720>] yaffs_internal_read_super.isra.18+0x1d0/0x7e4
    [<c0386d58>] yaffs2_internal_read_super_mtd+0x24/0x34
    [<c0147110>] mount_bdev+0x178/0x1a0
    [<c03835c8>] yaffs2_mount+0x28/0x30
    [<c0147a74>] mount_fs+0x54/0x194
    [<c01620e0>] vfs_kern_mount+0x58/0xf0
    [<c0164b18>] do_mount+0x210/0xa48
    [<c01656a4>] SyS_mount+0x94/0xc8
    [<c000ec80>] ret_fast_syscall+0x0/0x30
    [<ffffffff>] 0xffffffff

Signed-off-by: czou <cao.zou@windriver.com>

YAFFS doesn't sopport ACL yet, it must refuse any related settings.

Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>