<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/mtd, branch v3.10.72</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.72</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.72'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2015-01-16T14:59:01Z</updated>
<entry>
<title>UBI: Fix double free after do_sync_erase()</title>
<updated>2015-01-16T14:59:01Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2014-11-06T15:47:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ccebbb7e53c8d028961340d3081d69658f8a5bef'/>
<id>urn:sha1:ccebbb7e53c8d028961340d3081d69658f8a5bef</id>
<content type='text'>
commit aa5ad3b6eb8feb2399a5d26c8fb0060561bb9534 upstream.

If the erase worker is unable to erase a PEB it will
free the ubi_wl_entry itself.
The failing ubi_wl_entry must not free()'d again after
do_sync_erase() returns.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UBI: Fix invalid vfree()</title>
<updated>2015-01-16T14:59:01Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2014-10-26T23:46:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=398dd8fd97a3cf7777c5ee0fb1b52b8ec2edf9b8'/>
<id>urn:sha1:398dd8fd97a3cf7777c5ee0fb1b52b8ec2edf9b8</id>
<content type='text'>
commit f38aed975c0c3645bbdfc5ebe35726e64caaf588 upstream.

The logic of vfree()'ing vol-&gt;upd_buf is tied to vol-&gt;updating.
In ubi_start_update() vol-&gt;updating is set long before vmalloc()'ing
vol-&gt;upd_buf. If we encounter a write failure in ubi_start_update()
before vmalloc() the UBI device release function will try to vfree()
vol-&gt;upd_buf because vol-&gt;updating is set.
Fix this by allocating vol-&gt;upd_buf directly after setting vol-&gt;updating.

Fixes:
[   31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, volume is damaged
[   31.559340] ------------[ cut here ]------------
[   31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 __vunmap+0xe3/0x110()
[   31.559344] Trying to vfree() nonexistent vm area (ffffc90001f2b000)
[   31.559345] Modules linked in:
[   31.565620]  0000000000000bba ffff88002a0cbdb0 ffffffff818f0497 ffff88003b9ba148
[   31.566347]  ffff88002a0cbde0 ffffffff8156f515 ffff88003b9ba148 0000000000000bba
[   31.567073]  0000000000000000 0000000000000000 ffff88002a0cbe88 ffffffff8156c10a
[   31.567793] Call Trace:
[   31.568034]  [&lt;ffffffff818f0497&gt;] dump_stack+0x4e/0x7a
[   31.568510]  [&lt;ffffffff8156f515&gt;] ubi_io_write_vid_hdr+0x155/0x160
[   31.569084]  [&lt;ffffffff8156c10a&gt;] ubi_eba_write_leb+0x23a/0x870
[   31.569628]  [&lt;ffffffff81569b36&gt;] vol_cdev_write+0x226/0x380
[   31.570155]  [&lt;ffffffff81179265&gt;] vfs_write+0xb5/0x1f0
[   31.570627]  [&lt;ffffffff81179f8a&gt;] SyS_pwrite64+0x6a/0xa0
[   31.571123]  [&lt;ffffffff818fde12&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UBI: add missing kmem_cache_free() in process_pool_aeb error path</title>
<updated>2014-11-14T16:47:55Z</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@gmail.com</email>
</author>
<published>2014-09-09T12:25:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7a6f66a916d51ac1210c9658b223cd154d92e676'/>
<id>urn:sha1:7a6f66a916d51ac1210c9658b223cd154d92e676</id>
<content type='text'>
commit 1bf1890e86869032099b539bc83b098be12fc5a7 upstream.

I ran into this error after a ubiupdatevol, because I forgot to backport
e9110361a9a4 UBI: fix the volumes tree sorting criteria.

UBI error: process_pool_aeb: orphaned volume in fastmap pool
UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan!
kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects
CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1
[&lt;c000d298&gt;] (unwind_backtrace) from [&lt;c000baa8&gt;] (show_stack+0x10/0x14)
[&lt;c000baa8&gt;] (show_stack) from [&lt;c01b7a68&gt;] (destroy_ai+0x230/0x244)
[&lt;c01b7a68&gt;] (destroy_ai) from [&lt;c01b8fd4&gt;] (ubi_attach+0x98/0x1ec)
[&lt;c01b8fd4&gt;] (ubi_attach) from [&lt;c01ade90&gt;] (ubi_attach_mtd_dev+0x2b8/0x868)
[&lt;c01ade90&gt;] (ubi_attach_mtd_dev) from [&lt;c038b510&gt;] (ubi_init+0x1dc/0x2ac)
[&lt;c038b510&gt;] (ubi_init) from [&lt;c0008860&gt;] (do_one_initcall+0x94/0x140)
[&lt;c0008860&gt;] (do_one_initcall) from [&lt;c037aadc&gt;] (kernel_init_freeable+0xe8/0x1b0)
[&lt;c037aadc&gt;] (kernel_init_freeable) from [&lt;c02730ac&gt;] (kernel_init+0x8/0xe4)
[&lt;c02730ac&gt;] (kernel_init) from [&lt;c00093f0&gt;] (ret_from_fork+0x14/0x24)
UBI: scanning is finished

Freeing the cache in the error path fixes the Slab error.

Tested on at91sam9g35 (3.14.18+fastmap backports)

Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()</title>
<updated>2014-09-17T16:04:02Z</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2014-08-25T23:15:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6562c0cc805b391489e2f511983300e802864aea'/>
<id>urn:sha1:6562c0cc805b391489e2f511983300e802864aea</id>
<content type='text'>
commit 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream.

commit 65b97cf6b8de introduced in v3.7 caused a regression
by using a reversed CS_MASK thus causing omap_calculate_ecc to
always fail. As the NAND base driver never checks for .calculate()'s
return value, the zeroed ECC values are used as is without showing
any error to the user. However, this won't work and the NAND device
won't be guarded by any error code.

Fix the issue by using the correct mask.

Code was tested on omap3beagle using the following procedure
- flash the primary bootloader (MLO) from the kernel to the first
NAND partition using nandwrite.
- boot the board from NAND. This utilizes OMAP ROM loader that
relies on 1-bit Hamming code ECC.

Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc)

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd/ftl: fix the double free of the buffers allocated in build_maps()</title>
<updated>2014-09-17T16:04:02Z</updated>
<author>
<name>Kevin Hao</name>
<email>haokexin@gmail.com</email>
</author>
<published>2014-07-03T02:35:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a9d28db622269c29825f13c28bae0f587f77aada'/>
<id>urn:sha1:a9d28db622269c29825f13c28bae0f587f77aada</id>
<content type='text'>
commit a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream.

I got the following panic on my fsl p5020ds board.

  Unable to handle kernel paging request for data at address 0x7375627379737465
  Faulting instruction address: 0xc000000000100778
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145
  task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000
  NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000
  REGS: c0000000fe08aa00 TRAP: 0300   Not tainted  (3.15.0-next-20140613)
  MSR: 0000000080029000 &lt;CE,EE,ME&gt;  CR: 24ad2e24  XER: 00000000
  DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1
  GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80
  GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000
  GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200
  GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000
  GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8
  GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10
  GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400
  GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80
  NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168
  LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168
  Call Trace:
  [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable)
  [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90
  [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130
  [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64
  [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8
  [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc
  [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384
  [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8
  [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654
  [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4
  [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514
  [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4
  [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94
  [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368
  [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104
  [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734
  [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84
  [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c
  [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104
  [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4
  [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38
  [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac
  [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158
  [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80
  [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30
  [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238
  [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268
  [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c
  [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
  Instruction dump:
  41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008
  7fc9502a 2fbe0000 419e00c8 e93f0022 &lt;7f7e482a&gt; 39200000 88ed06b2 992d06b2
  ---[ end trace b4c9a94804a42d40 ]---

It seems that the corrupted partition header on my mtd device triggers
a bug in the ftl. In function build_maps() it will allocate the buffers
needed by the mtd partition, but if something goes wrong such as kmalloc
failure, mtd read error or invalid partition header parameter, it will
free all allocated buffers and then return non-zero. In my case, it
seems that partition header parameter 'NumTransferUnits' is invalid.

And the ftl_freepart() is a function which free all the partition
buffers allocated by build_maps(). Given the build_maps() is a self
cleaning function, so there is no need to invoke this function even
if build_maps() return with error. Otherwise it will causes the
buffers to be freed twice and then weird things would happen.

Signed-off-by: Kevin Hao &lt;haokexin@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: nand: omap: fix BCHx ecc.correct to return detected bit-flips in erased-page</title>
<updated>2014-07-09T18:14:00Z</updated>
<author>
<name>pekon gupta</name>
<email>pekon@ti.com</email>
</author>
<published>2014-03-20T13:19:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9bdc502feb4ca84fc3afdc7ab4f761a471210828'/>
<id>urn:sha1:9bdc502feb4ca84fc3afdc7ab4f761a471210828</id>
<content type='text'>
commit f306e8c3b667632952f1a4a74ffb910bbc06255f upstream.

fixes: commit 62116e5171e00f85a8d53f76e45b84423c89ff34
       mtd: nand: omap2: Support for hardware BCH error correction.

In omap_elm_correct_data(), if bitflip_count in an erased-page is within the
correctable limit (&lt; ecc.strength), then it is not indicated back to the caller
ecc-&gt;read_page().

This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as
perfectly clean and use it for writing even if actual bitflip_count was
dangerously high (bitflip_count &gt; mtd-&gt;bitflip_threshold).

This patch fixes this above issue, by returning 'stats' to caller
ecc-&gt;read_page() under all scenarios.

Reported-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: eLBC NAND: fix subpage write support</title>
<updated>2014-07-09T18:14:00Z</updated>
<author>
<name>Pekon Gupta</name>
<email>pekon@ti.com</email>
</author>
<published>2014-05-06T04:11:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f8da133c255f2d8742c8105ddbfb383c4eabf2ef'/>
<id>urn:sha1:f8da133c255f2d8742c8105ddbfb383c4eabf2ef</id>
<content type='text'>
commit f034d87def51f026b735d1e2877e9387011b2ba3 upstream.

As subpage write is enabled by default for all drivers, nand_write_subpage_hwecc
causes a crash if the driver did not register ecc-&gt;hwctl or ecc-&gt;calculate.
This behavior was introduced in
   commit 837a6ba4f3b6d23026674e6af6b6849a4634fff9
   "mtd: nand: subpage write support for hardware based ECC schemes".

This fixes a crash by emulating subpage write support by padding sub-page data
with 0xff on either sides to make it full page compatible.

Reported-by: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Tested-by: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
Reviewed-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes()</title>
<updated>2014-05-13T11:59:45Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-12-05T14:53:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=67876f85f8cd0282c652a14e227e16121dc54ed8'/>
<id>urn:sha1:67876f85f8cd0282c652a14e227e16121dc54ed8</id>
<content type='text'>
commit b4c233057771581698a13694ab6f33b48ce837dc upstream.

We always put a NUL terminator one space past the end of the "vendor"
buffer.  Walter Harms also pointed out that this should just use
kstrndup().

Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL')

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: nuc900_nand: NULL dereference in nuc900_nand_enable()</title>
<updated>2014-05-13T11:59:45Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-02-17T20:03:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b5c4957067ada52d90ac2b5b52e56999aae2b4d5'/>
<id>urn:sha1:b5c4957067ada52d90ac2b5b52e56999aae2b4d5</id>
<content type='text'>
commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream.

Instead of writing to "nand-&gt;reg + REG_FMICSR" we write to "REG_FMICSR"
which is NULL and not a valid register.

Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC</title>
<updated>2014-05-13T11:59:45Z</updated>
<author>
<name>Herve Codina</name>
<email>Herve.CODINA@celad.com</email>
</author>
<published>2014-03-03T11:15:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=71eec3f820e23c9f2f9f709c49b9661d04d024fb'/>
<id>urn:sha1:71eec3f820e23c9f2f9f709c49b9661d04d024fb</id>
<content type='text'>
commit 90445ff6241e2a13445310803e2efa606c61f276 upstream.

Crash detected on sam5d35 and its pmecc nand ecc controller.

The problem was a call to chip-&gt;ecc.hwctl from nand_write_subpage_hwecc
(nand_base.c) when we write a sub page.
chip-&gt;ecc.hwctl function is not set when we are using PMECC controller.
As a workaround, set NAND_NO_SUBPAGE_WRITE for PMECC controller in
order to disable sub page access in nand_write_page.

Signed-off-by: Herve Codina &lt;Herve.CODINA@celad.com&gt;
Acked-by: Josh Wu &lt;josh.wu@atmel.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
