aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mtd/ubi
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-11-13 08:08:29 -0500
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2011-02-06 12:18:32 -0500
commit276832d878d8a892ac7b40fd0ee07fe757e080c7 (patch)
tree8da446b3091065c088f1aae8b35833eba9b91308 /drivers/mtd/ubi
parent2fff570e7c8f97e411cd852d64b77b92d9ab8da9 (diff)
UBI: try to reveal buggy MTD drivers
When reading data from the flash, corrupt the buffer we are about to read to. The idea is to fix the following possible situation: 1. The buffer contains data from previous operation, e.g., read from another PEB previously. The data looks like expected, e.g., if we just do not read anything and return - the caller would not notice this. E.g., if we are reading a VID header, the buffer may contain a valid VID header from another PEB. 2. The driver is buggy and returns use success or -EBADMSG or -EUCLEAN, but it does not actually put any data to the buffer. This may confuse UBI or upper layers - they may think the buffer contains valid data while in fact it is just old data. Thus, try to reveal such buggy MTD drivers with simple debugging code which fills the read buffer with 0x12 constant. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'drivers/mtd/ubi')
-rw-r--r--drivers/mtd/ubi/io.c22
1 files changed, 22 insertions, 0 deletions
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 65915a649861..339a74f11c0b 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -146,6 +146,28 @@ int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset,
146 if (err) 146 if (err)
147 return err; 147 return err;
148 148
149 /*
150 * Deliberately corrupt the buffer to improve robustness. Indeed, if we
151 * do not do this, the following may happen:
152 * 1. The buffer contains data from previous operation, e.g., read from
153 * another PEB previously. The data looks like expected, e.g., if we
154 * just do not read anything and return - the caller would not
155 * notice this. E.g., if we are reading a VID header, the buffer may
156 * contain a valid VID header from another PEB.
157 * 2. The driver is buggy and returns us success or -EBADMSG or
158 * -EUCLEAN, but it does not actually put any data to the buffer.
159 *
160 * This may confuse UBI or upper layers - they may think the buffer
161 * contains valid data while in fact it is just old data. This is
162 * especially possible because UBI (and UBIFS) relies on CRC, and
163 * treats data as correct even in case of ECC errors if the CRC is
164 * correct.
165 *
166 * Try to prevent this situation by changing the first byte of the
167 * buffer.
168 */
169 *((uint8_t *)buf) ^= 0xFF;
170
149 addr = (loff_t)pnum * ubi->peb_size + offset; 171 addr = (loff_t)pnum * ubi->peb_size + offset;
150retry: 172retry:
151 err = ubi->mtd->read(ubi->mtd, addr, len, &read, buf); 173 err = ubi->mtd->read(ubi->mtd, addr, len, &read, buf);