linux-stable.git/drivers/mtd, branch v4.1.41

mtd: avoid stack overflow in MTD CFI code

2017-06-13T13:29:19+00:00

[ Upstream commit fddcca5107051adf9e4481d2a79ae0616577fd2c ]

When map_word gets too large, we use a lot of kernel stack, and for
MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended
1024 bytes in a number of functions:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize':
drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=]
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=]

This can be avoided if all operations on the map word are done
indirectly and the stack gets reused between the calls. We can
mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever
MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other
bank width is enabled, we also need to use a non-constant
map_bankwidth() to convince the compiler to use less stack.

Signed-off-by: Arnd Bergmann 
[Brian: this patch mostly achieves its goal by forcing
    MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit
    mappings; the rest of the change is mostly a wash, though it helps
    reduce stack size slightly. If we really care about supporting
    256-bit mappings though, we should consider rewriting some of this
    code to avoid keeping and assigning so many 256-bit objects on the
    stack.]
Signed-off-by: Brian Norris 

Signed-off-by: Sasha Levin

mtd: bcm47xxpart: fix parsing first block after aligned TRX

2017-06-13T13:29:16+00:00

[ Upstream commit bd5d21310133921021d78995ad6346f908483124 ]

After parsing TRX we should skip to the first block placed behind it.
Our code was working only with TRX with length not aligned to the
blocksize. In other cases (length aligned) it was missing the block
places right after TRX.

This fixes calculation and simplifies the comment.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin

ubi/upd: Always flush after prepared for an update

2017-05-17T19:07:44+00:00

[ Upstream commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 ]

In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:

|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592

All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.

So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.

Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

mtd: nand: xway: disable module support

2017-03-03T02:51:40+00:00

[ Upstream commit 73529c872a189c747bdb528ce9b85b67b0e28dec ]

The xway_nand driver accesses the ltq_ebu_membase symbol which is not
exported. This also should not get exported and we should handle the
EBU interface in a better way later. This quick fix just deactivated
support for building as module.

Fixes: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.")
Cc: 
Signed-off-by: Hauke Mehrtens 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

2016-12-22T03:45:42+00:00

[ Upstream commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c ]

This fixes subpage writes when using 4-bit HW ECC.

There has been numerous reports about ECC errors with devices using this
driver for a while.  Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.

What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
  written and the RS code properly generated, re-reading the same page
  the HW detects some ECC error, reading the same page again no ECC
  error is detected

Note that the ECC engine is already reinitialized in the 1-bit case.

Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].

[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")

Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Cc: 
Signed-off-by: Karl Beldan 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin

ubi: Make volume resize power cut aware

2016-08-20T03:07:58+00:00

[ Upstream commit 4946784bd3924b1374f05eebff2fd68660bae866 ]

When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Cc: 
Reported-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Fix early logging

2016-08-20T03:07:58+00:00

[ Upstream commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 ]

We cannot use ubi_* logging functions before the UBI
object is initialized.

Cc: 
Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Fix race condition between ubi device creation and udev

2016-08-20T03:07:58+00:00

[ Upstream commit 714fb87e8bc05ff78255afc0dca981e8c5242785 ]

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Cc: 
Signed-off-by: Iosif Harutyunov 
[rw: massaged commit message]
Signed-off-by: Richard Weinberger 

Signed-off-by: Sasha Levin

mtd: nand: fix bug writing 1 byte less than page size

2016-08-20T03:07:58+00:00

[ Upstream commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 ]

nand_do_write_ops() determines if it is writing a partial page with the
formula:
	part_pagewr = (column || writelen < (mtd->writesize - 1))

When 'writelen' is exactly 1 byte less than the NAND page size the formula
equates to zero, so the code doesn't process it as a partial write,
although it should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0xffffffff and iterating endlessly.

The bug may not be easy to reproduce in Linux since user space tools
usually force the padding or round-up the write size to a page-size
multiple.
This was discovered in U-Boot where the issue can be reproduced by
writing any size that is 1 byte less than a page-size multiple.
For example, on a NAND with 2K page (0x800):
	=> nand erase.part 
	=> nand write $loadaddr  7ff

[Editor's note: the bug was added in commit 29072b96078f, but moved
around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base
poi databuf as bounce buffer")]

Fixes: 29072b96078f ("[MTD] NAND: add subpage write support")
Signed-off-by: Hector Palacios 
Acked-by: Boris Brezillon 
Cc: 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin

ubi: Make recover_peb power cut aware

2016-07-11T00:20:01+00:00

[ Upstream commit 972228d87445dc46c0a01f5f3de673ac017626f7 ]

recover_peb() was never power cut aware,
if a power cut happened right after writing the VID header
upon next attach UBI would blindly use the new partial written
PEB and all data from the old PEB is lost.

In order to make recover_peb() power cut aware, write the new
VID with a proper crc and copy_flag set such that the UBI attach
process will detect whether the new PEB is completely written
or not.
We cannot directly use ubi_eba_atomic_leb_change() since we'd
have to unlock the LEB which is facing a write error.

Cc: stable@vger.kernel.org
Reported-by: Jörg Pfähler 
Reviewed-by: Jörg Pfähler 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin