summaryrefslogtreecommitdiff
path: root/include/uapi/misc
diff options
context:
space:
mode:
authorDan Carpenter <dan.carpenter@oracle.com>2017-02-07 16:15:27 +0300
committerDavid S. Miller <davem@davemloft.net>2017-02-08 13:27:06 -0500
commitff4cf0e5ce952488074aa7f47734af1794f55fbc (patch)
treea8558eaf3e54f9a65ab9f11f5755c192883a01f0 /include/uapi/misc
parent3efa70d78f218e4c9276b0bac0545e5184c1c47b (diff)
net: dsa: bcm_sf2: cleanup bcm_sf2_cfp_rule_get() a little
This patch doesn't affect how the code works. My static checker complains that the mask and shift doesn't make sense because 0xffffff << 16 goes beyond the end of 32 bits. It should be 0xffff instead but the existing code won't cause runtime bugs. Also the casting here is not needed and not consistent with the rest of the code. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/uapi/misc')
0 files changed, 0 insertions, 0 deletions
a 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: <stable@vger.kernel.org> Reported-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat