<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mtd/ubi, branch v4.7.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ubi: Fix race condition between ubi device creation and udev</title>
<updated>2016-08-20T16:11:02+00:00</updated>
<author>
<name>Iosif Harutyunov</name>
<email>iharutyunov@SonicWALL.com</email>
</author>
<published>2016-07-22T23:22:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3db4c640b32485105554e0bfd16bbde585f6fb0'/>
<id>f3db4c640b32485105554e0bfd16bbde585f6fb0</id>
<content type='text'>
commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

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.

Signed-off-by: Iosif Harutyunov &lt;iharutyunov@sonicwall.com&gt;
[rw: massaged commit message]
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

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.

Signed-off-by: Iosif Harutyunov &lt;iharutyunov@sonicwall.com&gt;
[rw: massaged commit message]
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ubi: Fix early logging</title>
<updated>2016-08-20T16:11:02+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-07-04T20:06:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=798775c3a4c8c4e75cb32ea8a3f7a4f2f9a2d186'/>
<id>798775c3a4c8c4e75cb32ea8a3f7a4f2f9a2d186</id>
<content type='text'>
commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 upstream.

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

Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 upstream.

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

Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ubi: Make volume resize power cut aware</title>
<updated>2016-08-20T16:11:02+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-23T17:30:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce5a28e47daf8ca09beba826ddd57955853b77e9'/>
<id>ce5a28e47daf8ca09beba826ddd57955853b77e9</id>
<content type='text'>
commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.

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.

Reported-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.

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.

Reported-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ubi: Make recover_peb power cut aware</title>
<updated>2016-06-22T22:29:32+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-20T22:31:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=972228d87445dc46c0a01f5f3de673ac017626f7'/>
<id>972228d87445dc46c0a01f5f3de673ac017626f7</id>
<content type='text'>
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 &lt;pfaehler@isse.de&gt;
Reviewed-by: Jörg Pfähler &lt;pfaehler@isse.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;pfaehler@isse.de&gt;
Reviewed-by: Jörg Pfähler &lt;pfaehler@isse.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ubi: Don't bypass -&gt;getattr()</title>
<updated>2016-06-14T08:51:42+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-12T22:49:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=61edc3f3b51d2d3948029197cfff6fef7d94e939'/>
<id>61edc3f3b51d2d3948029197cfff6fef7d94e939</id>
<content type='text'>
Directly accessing inode fields bypasses -&gt;getattr()
and can cause problems when the underlying filesystem
does not have the default -&gt;getattr() implementation.

So instead of obtaining the backing inode via d_backing_inode()
use vfs_getattr() and obtain what we need from the kstat struct.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Reported-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Directly accessing inode fields bypasses -&gt;getattr()
and can cause problems when the underlying filesystem
does not have the default -&gt;getattr() implementation.

So instead of obtaining the backing inode via d_backing_inode()
use vfs_getattr() and obtain what we need from the kstat struct.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Reported-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "mtd: switch open_mtd_by_chdev() to use of vfs_stat()"</title>
<updated>2016-06-14T08:51:42+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-12T22:49:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1a498ec45eeabcb246c3c3f5822ed9ac1b4f70d8'/>
<id>1a498ec45eeabcb246c3c3f5822ed9ac1b4f70d8</id>
<content type='text'>
This reverts commit 87f15d4add758fb7fc76655721af94be57a4c17d.

vfs_stat() can only be used on user supplied buffers.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 87f15d4add758fb7fc76655721af94be57a4c17d.

vfs_stat() can only be used on user supplied buffers.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "mtd: switch ubi_open_volume_path() to vfs_stat()"</title>
<updated>2016-06-14T08:51:42+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-12T21:37:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ad022c87187b50f50937bd9bcd1ef312442a89af'/>
<id>ad022c87187b50f50937bd9bcd1ef312442a89af</id>
<content type='text'>
This reverts commit 322ea0bbf3003df17b6253f76e572c37d79a6810.

vfs_stat() can only be used on user supplied buffers.
UBI's kapi.c is the API to the kernel and therefore vfs_stat()
is inappropriate.

This solves the problem that mounting any UBIFS will immediately
fail with -EINVAL.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 322ea0bbf3003df17b6253f76e572c37d79a6810.

vfs_stat() can only be used on user supplied buffers.
UBI's kapi.c is the API to the kernel and therefore vfs_stat()
is inappropriate.

This solves the problem that mounting any UBIFS will immediately
fail with -EINVAL.

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'upstream-4.7-rc1' of git://git.infradead.org/linux-ubifs</title>
<updated>2016-05-28T01:49:29+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-05-28T01:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=23a3e178b9f8be3a900c7b11d795e54b4a131af0'/>
<id>23a3e178b9f8be3a900c7b11d795e54b4a131af0</id>
<content type='text'>
Pull UBI/UBIFS updates from Richard Weinberger:
 "This contains mostly cleanups and minor improvements of UBI and UBIFS"

* tag 'upstream-4.7-rc1' of git://git.infradead.org/linux-ubifs:
  ubifs: ubifs_dump_inode: Fix dumping field bulk_read
  UBI: Fix static volume checks when Fastmap is used
  UBI: Set free_count to zero before walking through erase list
  UBI: Silence an unintialized variable warning
  UBI: Clean up return in ubi_remove_volume()
  UBI: Modify wrong comment in ubi_leb_map function.
  UBI: Don't read back all data in ubi_eba_copy_leb()
  UBI: Add ro-mode sysfs attribute
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull UBI/UBIFS updates from Richard Weinberger:
 "This contains mostly cleanups and minor improvements of UBI and UBIFS"

* tag 'upstream-4.7-rc1' of git://git.infradead.org/linux-ubifs:
  ubifs: ubifs_dump_inode: Fix dumping field bulk_read
  UBI: Fix static volume checks when Fastmap is used
  UBI: Set free_count to zero before walking through erase list
  UBI: Silence an unintialized variable warning
  UBI: Clean up return in ubi_remove_volume()
  UBI: Modify wrong comment in ubi_leb_map function.
  UBI: Don't read back all data in ubi_eba_copy_leb()
  UBI: Add ro-mode sysfs attribute
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: Fix static volume checks when Fastmap is used</title>
<updated>2016-05-24T13:24:37+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-04-26T14:39:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1900149c835ab5b48bea31a823ea5e5a401fb560'/>
<id>1900149c835ab5b48bea31a823ea5e5a401fb560</id>
<content type='text'>
Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[&lt;ffffffff8140d841&gt;] dump_stack+0x63/0x82
[&lt;ffffffffa003abf6&gt;] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[&lt;ffffffffa00453b3&gt;] ubi_check_volume+0x83/0xf0 [ubi]
[&lt;ffffffffa0039d97&gt;] ubi_open_volume+0x177/0x350 [ubi]
[&lt;ffffffffa00375d8&gt;] vol_cdev_open+0x58/0xb0 [ubi]
[&lt;ffffffff8124b08e&gt;] chrdev_open+0xae/0x1d0
[&lt;ffffffff81243bcf&gt;] do_dentry_open+0x1ff/0x300
[&lt;ffffffff8124afe0&gt;] ? cdev_put+0x30/0x30
[&lt;ffffffff81244d36&gt;] vfs_open+0x56/0x60
[&lt;ffffffff812545f4&gt;] path_openat+0x4f4/0x1190
[&lt;ffffffff81256621&gt;] do_filp_open+0x91/0x100
[&lt;ffffffff81263547&gt;] ? __alloc_fd+0xc7/0x190
[&lt;ffffffff812450df&gt;] do_sys_open+0x13f/0x210
[&lt;ffffffff812451ce&gt;] SyS_open+0x1e/0x20
[&lt;ffffffff81a99e32&gt;] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Tested-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[&lt;ffffffff8140d841&gt;] dump_stack+0x63/0x82
[&lt;ffffffffa003abf6&gt;] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[&lt;ffffffffa00453b3&gt;] ubi_check_volume+0x83/0xf0 [ubi]
[&lt;ffffffffa0039d97&gt;] ubi_open_volume+0x177/0x350 [ubi]
[&lt;ffffffffa00375d8&gt;] vol_cdev_open+0x58/0xb0 [ubi]
[&lt;ffffffff8124b08e&gt;] chrdev_open+0xae/0x1d0
[&lt;ffffffff81243bcf&gt;] do_dentry_open+0x1ff/0x300
[&lt;ffffffff8124afe0&gt;] ? cdev_put+0x30/0x30
[&lt;ffffffff81244d36&gt;] vfs_open+0x56/0x60
[&lt;ffffffff812545f4&gt;] path_openat+0x4f4/0x1190
[&lt;ffffffff81256621&gt;] do_filp_open+0x91/0x100
[&lt;ffffffff81263547&gt;] ? __alloc_fd+0xc7/0x190
[&lt;ffffffff812450df&gt;] do_sys_open+0x13f/0x210
[&lt;ffffffff812451ce&gt;] SyS_open+0x1e/0x20
[&lt;ffffffff81a99e32&gt;] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Tested-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: Set free_count to zero before walking through erase list</title>
<updated>2016-05-24T13:24:33+00:00</updated>
<author>
<name>Heiko Schocher</name>
<email>hs@denx.de</email>
</author>
<published>2016-04-22T10:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=73b0cd57fcd07201b138214f9a2353f76dd9ae2c'/>
<id>73b0cd57fcd07201b138214f9a2353f76dd9ae2c</id>
<content type='text'>
Set free_count to zero before walking through ai-&gt;erase list
in wl_init().

Found in U-Boot as U-Boot has no workqueue/threads, it immediately
calls erase_worker(), which increase for each erased block
free_count. Without this patch, free_count gets after
this initialized to zero in wl_init(), so the free_count
variable always has the maybe wrong value 0 in U-Boot.

Signed-off-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Set free_count to zero before walking through ai-&gt;erase list
in wl_init().

Found in U-Boot as U-Boot has no workqueue/threads, it immediately
calls erase_worker(), which increase for each erased block
free_count. Without this patch, free_count gets after
this initialized to zero in wl_init(), so the free_count
variable always has the maybe wrong value 0 in U-Boot.

Signed-off-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
</feed>
