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); |
