diff options
-rw-r--r-- | drivers/mtd/ubi/io.c | 22 |
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; |
150 | retry: | 172 | retry: |
151 | err = ubi->mtd->read(ubi->mtd, addr, len, &read, buf); | 173 | err = ubi->mtd->read(ubi->mtd, addr, len, &read, buf); |