// SPDX-License-Identifier: GPL-2.0/* * Bad block management * * - Heavily based on MD badblocks code from Neil Brown * * Copyright (c) 2015, Intel Corporation. */ #include <linux/badblocks.h>#include <linux/seqlock.h>#include <linux/device.h>#include <linux/kernel.h>#include <linux/module.h>#include <linux/stddef.h>#include <linux/types.h>#include <linux/slab.h> /* * The purpose of badblocks set/clear is to manage bad blocks ranges which are * identified by LBA addresses. * * When the caller of badblocks_set() wants to set a range of bad blocks, the * setting range can be acked or unacked. And the setting range may merge, * overwrite, skip the overlapped already set range, depends on who they are * overlapped or adjacent, and the acknowledgment type of the ranges. It can be * more complicated when the setting range covers multiple already set bad block * ranges, with restrictions of maximum length of each bad range and the bad * table space limitation. * * It is difficult and unnecessary to take care of all the possible situations, * for setting a large range of bad blocks, we can handle it by dividing the * large range into smaller ones when encounter overlap, max range length or * bad table full conditions. Every time only a smaller piece of the bad range * is handled with a limited number of conditions how it is interacted with * possible overlapped or adjacent already set bad block ranges. Then the hard * complicated problem can be much simpler to handle in proper way. * * When setting a range of bad blocks to the bad table, the simplified situations * to be considered are, (The already set bad blocks ranges are naming with * prefix E, and the setting bad blocks range is naming with prefix S) * * 1) A setting range is not overlapped or adjacent to any other already set bad * block range. * +--------+ * | S | * +--------+ * +-------------+ +-------------+ * | E1 | | E2 | * +-------------+ +-------------+ * For this situation if the bad blocks table is not full, just allocate a * free slot from the bad blocks table to mark the setting range S. The * result is, * +-------------+ +--------+ +-------------+ * | E1 | | S | | E2 | * +-------------+ +--------+ +-------------+ * 2) A setting range starts exactly at a start LBA of an already set bad blocks * range. * 2.1) The setting range size < already set range size * +--------+ * | S | * +--------+ * +-------------+ * | E | * +-------------+ * 2.1.1) If S and E are both acked or unacked range, the setting range S can * be merged into existing bad range E. The result is, * +-------------+ * | S | * +-------------+ * 2.1.2) If S is unacked setting and E is acked, the setting will be denied, and * the result is, * +-------------+ * | E | * +-------------+ * 2.1.3) If S is acked setting and E is unacked, range S can overwrite on E. * An extra slot from the bad blocks table will be allocated for S, and head * of E will move to end of the inserted range S. The result is, * +--------+----+ * | S | E | * +--------+----+ * 2.2) The setting range size == already set range size * 2.2.1) If S and E are both acked or unacked range, the setting range S can * be merged into existing bad range E. The result is, * +-------------+ * | S | * +-------------+ * 2.2.2) If S is unacked setting and E is acked, the setting will be denied, and * the result is, * +-------------+ * | E | * +-------------+ * 2.2.3) If S is acked setting and E is unacked, range S can overwrite all of bad blocks range E. The result is, * +-------------+ * | S | * +-------------+ * 2.3) The setting range size > already set range size * +-------------------+ * | S | * +-------------------+ * +-------------+ * | E | * +-------------+ * For such situation, the setting range S can be treated as two parts, the * first part (S1) is as same size as the already set range E, the second * part (S2) is the rest of setting range. * +-------------+-----+ +-------------+ +-----+ * | S1 | S2 | | S1 | | S2 | * +-------------+-----+ ===> +-------------+ +-----+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now we only focus on how to handle the setting range S1 and already set * range E, which are already explained in 2.2), for the rest S2 it will be * handled later in next loop. * 3) A setting range starts before the start LBA of an already set bad blocks * range. * +-------------+ * | S | * +-------------+ * +-------------+ * | E | * +-------------+ * For this situation, the setting range S can be divided into two parts, the * first (S1) ends at the start LBA of already set range E, the second part * (S2) starts exactly at a start LBA of the already set range E. * +----+---------+ +----+ +---------+ * | S1 | S2 | | S1 | | S2 | * +----+---------+ ===> +----+ +---------+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now only the first part S1 should be handled in this loop, which is in * similar condition as 1). The rest part S2 has exact same start LBA address * of the already set range E, they will be handled in next loop in one of * situations in 2). * 4) A setting range starts after the start LBA of an already set bad blocks * range. * 4.1) If the setting range S exactly matches the tail part of already set bad * blocks range E, like the following chart shows, * +---------+ * | S | * +---------+ * +-------------+ * | E | * +-------------+ * 4.1.1) If range S and E have same acknowledge value (both acked or unacked), * they will be merged into one, the result is, * +-------------+ * | S | * +-------------+ * 4.1.2) If range E is acked and the setting range S is unacked, the setting * request of S will be rejected, the result is, * +-------------+ * | E | * +-------------+ * 4.1.3) If range E is unacked, and the setting range S is acked, then S may * overwrite the overlapped range of E, the result is, * +---+---------+ * | E | S | * +---+---------+ * 4.2) If the setting range S stays in middle of an already set range E, like * the following chart shows, * +----+ * | S | * +----+ * +--------------+ * | E | * +--------------+ * 4.2.1) If range S and E have same acknowledge value (both acked or unacked), * they will be merged into one, the result is, * +--------------+ * | S | * +--------------+ * 4.2.2) If range E is acked and the setting range S is unacked, the setting * request of S will be rejected, the result is also, * +--------------+ * | E | * +--------------+ * 4.2.3) If range E is unacked, and the setting range S is acked, then S will * inserted into middle of E and split previous range E into two parts (E1 * and E2), the result is, * +----+----+----+ * | E1 | S | E2 | * +----+----+----+ * 4.3) If the setting bad blocks range S is overlapped with an already set bad * blocks range E. The range S starts after the start LBA of range E, and * ends after the end LBA of range E, as the following chart shows, * +-------------------+ * | S | * +-------------------+ * +-------------+ * | E | * +-------------+ * For this situation the range S can be divided into two parts, the first * part (S1) ends at end range E, and the second part (S2) has rest range of * origin S. * +---------+---------+ +---------+ +---------+ * | S1 | S2 | | S1 | | S2 | * +---------+---------+ ===> +---------+ +---------+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now in this loop the setting range S1 and already set range E can be * handled as the situations 4.1), the rest range S2 will be handled in next * loop and ignored in this loop. * 5) A setting bad blocks range S is adjacent to one or more already set bad * blocks range(s), and they are all acked or unacked range. * 5.1) Front merge: If the already set bad blocks range E is before setting * range S and they are adjacent, * +------+ * | S | * +------+ * +-------+ * | E | * +-------+ * 5.1.1) When total size of range S and E <= BB_MAX_LEN, and their acknowledge * values are same, the setting range S can front merges into range E. The * result is, * +--------------+ * | S | * +--------------+ * 5.1.2) Otherwise these two ranges cannot merge, just insert the setting * range S right after already set range E into the bad blocks table. The * result is, * +--------+------+ * | E | S | * +--------+------+ * 6) Special cases which above conditions cannot handle * 6.1) Multiple already set ranges may merge into less ones in a full bad table * +-------------------------------------------------------+ * | S | * +-------------------------------------------------------+ * |<----- BB_MAX_LEN ----->| * +-----+ +-----+ +-----+ * | E1 | | E2 | | E3 | * +-----+ +-----+ +-----+ * In the above example, when the bad blocks table is full, inserting the * first part of setting range S will fail because no more available slot * can be allocated from bad blocks table. In this situation a proper * setting method should be go though all the setting bad blocks range and * look for chance to merge already set ranges into less ones. When there * is available slot from bad blocks table, re-try again to handle more * setting bad blocks ranges as many as possible. * +------------------------+ * | S3 | * +------------------------+ * |<----- BB_MAX_LEN ----->| * +-----+-----+-----+---+-----+--+ * | S1 | S2 | * +-----+-----+-----+---+-----+--+ * The above chart shows although the first part (S3) cannot be inserted due * to no-space in bad blocks table, but the following E1, E2 and E3 ranges * can be merged with rest part of S into less range S1 and S2. Now there is * 1 free slot in bad blocks table. * +------------------------+-----+-----+-----+---+-----+--+ * | S3 | S1 | S2 | * +------------------------+-----+-----+-----+---+-----+--+ * Since the bad blocks table is not full anymore, re-try again for the * origin setting range S. Now the setting range S3 can be inserted into the * bad blocks table with previous freed slot from multiple ranges merge. * 6.2) Front merge after overwrite * In the following example, in bad blocks table, E1 is an acked bad blocks * range and E2 is an unacked bad blocks range, therefore they are not able * to merge into a larger range. The setting bad blocks range S is acked, * therefore part of E2 can be overwritten by S. * +--------+ * | S | acknowledged * +--------+ S: 1 * +-------+-------------+ E1: 1 * | E1 | E2 | E2: 0 * +-------+-------------+ * With previous simplified routines, after overwriting part of E2 with S, * the bad blocks table should be (E3 is remaining part of E2 which is not * overwritten by S), * acknowledged * +-------+--------+----+ S: 1 * | E1 | S | E3 | E1: 1 * +-------+--------+----+ E3: 0 * The above result is correct but not perfect. Range E1 and S in the bad * blocks table are all acked, merging them into a larger one range may * occupy less bad blocks table space and make badblocks_check() faster. * Therefore in such situation, after overwriting range S, the previous range * E1 should be checked for possible front combination. Then the ideal * result can be, * +----------------+----+ acknowledged * | E1 | E3 | E1: 1 * +----------------+----+ E3: 0 * 6.3) Behind merge: If the already set bad blocks range E is behind the setting * range S and they are adjacent. Normally we don't need to care about this * because front merge handles this while going though range S from head to * tail, except for the tail part of range S. When the setting range S are * fully handled, all the above simplified routine doesn't check whether the * tail LBA of range S is adjacent to the next already set range and not * merge them even it is possible. * +------+ * | S | * +------+ * +-------+ * | E | * +-------+ * For the above special situation, when the setting range S are all handled * and the loop ends, an extra check is necessary for whether next already * set range E is right after S and mergeable. * 6.3.1) When total size of range E and S <= BB_MAX_LEN, and their acknowledge * values are same, the setting range S can behind merges into range E. The * result is, * +--------------+ * | S | * +--------------+ * 6.3.2) Otherwise these two ranges cannot merge, just insert the setting range * S in front of the already set range E in the bad blocks table. The result * is, * +------+-------+ * | S | E | * +------+-------+ * * All the above 5 simplified situations and 3 special cases may cover 99%+ of * the bad block range setting conditions. Maybe there is some rare corner case * is not considered and optimized, it won't hurt if badblocks_set() fails due * to no space, or some ranges are not merged to save bad blocks table space. * * Inside badblocks_set() each loop starts by jumping to re_insert label, every * time for the new loop prev_badblocks() is called to find an already set range * which starts before or at current setting range. Since the setting bad blocks * range is handled from head to tail, most of the cases it is unnecessary to do * the binary search inside prev_badblocks(), it is possible to provide a hint * to prev_badblocks() for a fast path, then the expensive binary search can be * avoided. In my test with the hint to prev_badblocks(), except for the first * loop, all rested calls to prev_badblocks() can go into the fast path and * return correct bad blocks table index immediately. * * * Clearing a bad blocks range from the bad block table has similar idea as * setting does, but much more simpler. The only thing needs to be noticed is * when the clearing range hits middle of a bad block range, the existing bad * block range will split into two, and one more item should be added into the * bad block table. The simplified situations to be considered are, (The already * set bad blocks ranges in bad block table are naming with prefix E, and the * clearing bad blocks range is naming with prefix C) * * 1) A clearing range is not overlapped to any already set ranges in bad block * table. * +-----+ | +-----+ | +-----+ * | C | | | C | | | C | * +-----+ or +-----+ or +-----+ * +---+ | +----+ +----+ | +---+ * | E | | | E1 | | E2 | | | E | * +---+ | +----+ +----+ | +---+ * For the above situations, no bad block to be cleared and no failure * happens, simply returns 0. * 2) The clearing range hits middle of an already setting bad blocks range in * the bad block table. * +---+ * | C | * +---+ * +-----------------+ * | E | * +-----------------+ * In this situation if the bad block table is not full, the range E will be * split into two ranges E1 and E2. The result is, * +------+ +------+ * | E1 | | E2 | * +------+ +------+ * 3) The clearing range starts exactly at same LBA as an already set bad block range * from the bad block table. * 3.1) Partially covered at head part * +------------+ * | C | * +------------+ * +-----------------+ * | E | * +-----------------+ * For this situation, the overlapped already set range will update the * start LBA to end of C and shrink the range to BB_LEN(E) - BB_LEN(C). No * item deleted from bad block table. The result is, * +----+ * | E1 | * +----+ * 3.2) Exact fully covered * +-----------------+ * | C | * +-----------------+ * +-----------------+ * | E | * +-----------------+ * For this situation the whole bad blocks range E will be cleared and its * corresponded item is deleted from the bad block table. * 4) The clearing range exactly ends at same LBA as an already set bad block * range. * +-------+ * | C | * +-------+ * +-----------------+ * | E | * +-----------------+ * For the above situation, the already set range E is updated to shrink its * end to the start of C, and reduce its length to BB_LEN(E) - BB_LEN(C). * The result is, * +---------+ * | E | * +---------+ * 5) The clearing range is partially overlapped with an already set bad block * range from the bad block table. * 5.1) The already set bad block range is front overlapped with the clearing * range. * +----------+ * | C | * +----------+ * +------------+ * | E | * +------------+ * For such situation, the clearing range C can be treated as two parts. The * first part ends at the start LBA of range E, and the second part starts at * same LBA of range E. * +----+-----+ +----+ +-----+ * | C1 | C2 | | C1 | | C2 | * +----+-----+ ===> +----+ +-----+ * +------------+ +------------+ * | E | | E | * +------------+ +------------+ * Now the first part C1 can be handled as condition 1), and the second part C2 can be * handled as condition 3.1) in next loop. * 5.2) The already set bad block range is behind overlaopped with the clearing * range. * +----------+ * | C | * +----------+ * +------------+ * | E | * +------------+ * For such situation, the clearing range C can be treated as two parts. The * first part C1 ends at same end LBA of range E, and the second part starts * at end LBA of range E. * +----+-----+ +----+ +-----+ * | C1 | C2 | | C1 | | C2 | * +----+-----+ ===> +----+ +-----+ * +------------+ +------------+ * | E | | E | * +------------+ +------------+ * Now the first part clearing range C1 can be handled as condition 4), and * the second part clearing range C2 can be handled as condition 1) in next * loop. * * All bad blocks range clearing can be simplified into the above 5 situations * by only handling the head part of the clearing range in each run of the * while-loop. The idea is similar to bad blocks range setting but much * simpler. */ /* * Find the range starts at-or-before 's' from bad table. The search * starts from index 'hint' and stops at index 'hint_end' from the bad * table. */static int prev_by_hint(struct badblocks *bb, sector_t s, int hint){ int hint_end = hint + 2; u64 *p = bb->page; int ret = -1; while ((hint < hint_end) && ((hint + 1) <= bb->count) && (BB_OFFSET(p[hint]) <= s)) { if ((hint + 1) == bb->count || BB_OFFSET(p[hint + 1]) > s) { ret = hint; break; } hint++; } return ret;} /* * Find the range starts at-or-before bad->start. If 'hint' is provided * (hint >= 0) then search in the bad table from hint firstly. It is * very probably the wanted bad range can be found from the hint index, * then the unnecessary while-loop iteration can be avoided. */static int prev_badblocks(struct badblocks *bb, struct badblocks_context *bad, int hint){ sector_t s = bad->start; int ret = -1; int lo, hi; u64 *p; if (!bb->count) goto out; if (hint >= 0) { ret = prev_by_hint(bb, s, hint); if (ret >= 0) goto out; } lo = 0; hi = bb->count; p = bb->page;Lines 1–500 of 1550. Load more
// SPDX-License-Identifier: GPL-2.0 /* * Bad block management * * - Heavily based on MD badblocks code from Neil Brown * * Copyright (c) 2015, Intel Corporation. */ #include <linux/badblocks.h> #include <linux/seqlock.h> #include <linux/device.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/stddef.h> #include <linux/types.h> #include <linux/slab.h> /* * The purpose of badblocks set/clear is to manage bad blocks ranges which are * identified by LBA addresses. * * When the caller of badblocks_set() wants to set a range of bad blocks, the * setting range can be acked or unacked. And the setting range may merge, * overwrite, skip the overlapped already set range, depends on who they are * overlapped or adjacent, and the acknowledgment type of the ranges. It can be * more complicated when the setting range covers multiple already set bad block * ranges, with restrictions of maximum length of each bad range and the bad * table space limitation. * * It is difficult and unnecessary to take care of all the possible situations, * for setting a large range of bad blocks, we can handle it by dividing the * large range into smaller ones when encounter overlap, max range length or * bad table full conditions. Every time only a smaller piece of the bad range * is handled with a limited number of conditions how it is interacted with * possible overlapped or adjacent already set bad block ranges. Then the hard * complicated problem can be much simpler to handle in proper way. * * When setting a range of bad blocks to the bad table, the simplified situations * to be considered are, (The already set bad blocks ranges are naming with * prefix E, and the setting bad blocks range is naming with prefix S) * * 1) A setting range is not overlapped or adjacent to any other already set bad * block range. * +--------+ * | S | * +--------+ * +-------------+ +-------------+ * | E1 | | E2 | * +-------------+ +-------------+ * For this situation if the bad blocks table is not full, just allocate a * free slot from the bad blocks table to mark the setting range S. The * result is, * +-------------+ +--------+ +-------------+ * | E1 | | S | | E2 | * +-------------+ +--------+ +-------------+ * 2) A setting range starts exactly at a start LBA of an already set bad blocks * range. * 2.1) The setting range size < already set range size * +--------+ * | S | * +--------+ * +-------------+ * | E | * +-------------+ * 2.1.1) If S and E are both acked or unacked range, the setting range S can * be merged into existing bad range E. The result is, * +-------------+ * | S | * +-------------+ * 2.1.2) If S is unacked setting and E is acked, the setting will be denied, and * the result is, * +-------------+ * | E | * +-------------+ * 2.1.3) If S is acked setting and E is unacked, range S can overwrite on E. * An extra slot from the bad blocks table will be allocated for S, and head * of E will move to end of the inserted range S. The result is, * +--------+----+ * | S | E | * +--------+----+ * 2.2) The setting range size == already set range size * 2.2.1) If S and E are both acked or unacked range, the setting range S can * be merged into existing bad range E. The result is, * +-------------+ * | S | * +-------------+ * 2.2.2) If S is unacked setting and E is acked, the setting will be denied, and * the result is, * +-------------+ * | E | * +-------------+ * 2.2.3) If S is acked setting and E is unacked, range S can overwrite all of bad blocks range E. The result is, * +-------------+ * | S | * +-------------+ * 2.3) The setting range size > already set range size * +-------------------+ * | S | * +-------------------+ * +-------------+ * | E | * +-------------+ * For such situation, the setting range S can be treated as two parts, the * first part (S1) is as same size as the already set range E, the second * part (S2) is the rest of setting range. * +-------------+-----+ +-------------+ +-----+ * | S1 | S2 | | S1 | | S2 | * +-------------+-----+ ===> +-------------+ +-----+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now we only focus on how to handle the setting range S1 and already set * range E, which are already explained in 2.2), for the rest S2 it will be * handled later in next loop. * 3) A setting range starts before the start LBA of an already set bad blocks * range. * +-------------+ * | S | * +-------------+ * +-------------+ * | E | * +-------------+ * For this situation, the setting range S can be divided into two parts, the * first (S1) ends at the start LBA of already set range E, the second part * (S2) starts exactly at a start LBA of the already set range E. * +----+---------+ +----+ +---------+ * | S1 | S2 | | S1 | | S2 | * +----+---------+ ===> +----+ +---------+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now only the first part S1 should be handled in this loop, which is in * similar condition as 1). The rest part S2 has exact same start LBA address * of the already set range E, they will be handled in next loop in one of * situations in 2). * 4) A setting range starts after the start LBA of an already set bad blocks * range. * 4.1) If the setting range S exactly matches the tail part of already set bad * blocks range E, like the following chart shows, * +---------+ * | S | * +---------+ * +-------------+ * | E | * +-------------+ * 4.1.1) If range S and E have same acknowledge value (both acked or unacked), * they will be merged into one, the result is, * +-------------+ * | S | * +-------------+ * 4.1.2) If range E is acked and the setting range S is unacked, the setting * request of S will be rejected, the result is, * +-------------+ * | E | * +-------------+ * 4.1.3) If range E is unacked, and the setting range S is acked, then S may * overwrite the overlapped range of E, the result is, * +---+---------+ * | E | S | * +---+---------+ * 4.2) If the setting range S stays in middle of an already set range E, like * the following chart shows, * +----+ * | S | * +----+ * +--------------+ * | E | * +--------------+ * 4.2.1) If range S and E have same acknowledge value (both acked or unacked), * they will be merged into one, the result is, * +--------------+ * | S | * +--------------+ * 4.2.2) If range E is acked and the setting range S is unacked, the setting * request of S will be rejected, the result is also, * +--------------+ * | E | * +--------------+ * 4.2.3) If range E is unacked, and the setting range S is acked, then S will * inserted into middle of E and split previous range E into two parts (E1 * and E2), the result is, * +----+----+----+ * | E1 | S | E2 | * +----+----+----+ * 4.3) If the setting bad blocks range S is overlapped with an already set bad * blocks range E. The range S starts after the start LBA of range E, and * ends after the end LBA of range E, as the following chart shows, * +-------------------+ * | S | * +-------------------+ * +-------------+ * | E | * +-------------+ * For this situation the range S can be divided into two parts, the first * part (S1) ends at end range E, and the second part (S2) has rest range of * origin S. * +---------+---------+ +---------+ +---------+ * | S1 | S2 | | S1 | | S2 | * +---------+---------+ ===> +---------+ +---------+ * +-------------+ +-------------+ * | E | | E | * +-------------+ +-------------+ * Now in this loop the setting range S1 and already set range E can be * handled as the situations 4.1), the rest range S2 will be handled in next * loop and ignored in this loop. * 5) A setting bad blocks range S is adjacent to one or more already set bad * blocks range(s), and they are all acked or unacked range. * 5.1) Front merge: If the already set bad blocks range E is before setting * range S and they are adjacent, * +------+ * | S | * +------+ * +-------+ * | E | * +-------+ * 5.1.1) When total size of range S and E <= BB_MAX_LEN, and their acknowledge * values are same, the setting range S can front merges into range E. The * result is, * +--------------+ * | S | * +--------------+ * 5.1.2) Otherwise these two ranges cannot merge, just insert the setting * range S right after already set range E into the bad blocks table. The * result is, * +--------+------+ * | E | S | * +--------+------+ * 6) Special cases which above conditions cannot handle * 6.1) Multiple already set ranges may merge into less ones in a full bad table * +-------------------------------------------------------+ * | S | * +-------------------------------------------------------+ * |<----- BB_MAX_LEN ----->| * +-----+ +-----+ +-----+ * | E1 | | E2 | | E3 | * +-----+ +-----+ +-----+ * In the above example, when the bad blocks table is full, inserting the * first part of setting range S will fail because no more available slot * can be allocated from bad blocks table. In this situation a proper * setting method should be go though all the setting bad blocks range and * look for chance to merge already set ranges into less ones. When there * is available slot from bad blocks table, re-try again to handle more * setting bad blocks ranges as many as possible. * +------------------------+ * | S3 | * +------------------------+ * |<----- BB_MAX_LEN ----->| * +-----+-----+-----+---+-----+--+ * | S1 | S2 | * +-----+-----+-----+---+-----+--+ * The above chart shows although the first part (S3) cannot be inserted due * to no-space in bad blocks table, but the following E1, E2 and E3 ranges * can be merged with rest part of S into less range S1 and S2. Now there is * 1 free slot in bad blocks table. * +------------------------+-----+-----+-----+---+-----+--+ * | S3 | S1 | S2 | * +------------------------+-----+-----+-----+---+-----+--+ * Since the bad blocks table is not full anymore, re-try again for the * origin setting range S. Now the setting range S3 can be inserted into the * bad blocks table with previous freed slot from multiple ranges merge. * 6.2) Front merge after overwrite * In the following example, in bad blocks table, E1 is an acked bad blocks * range and E2 is an unacked bad blocks range, therefore they are not able * to merge into a larger range. The setting bad blocks range S is acked, * therefore part of E2 can be overwritten by S. * +--------+ * | S | acknowledged * +--------+ S: 1 * +-------+-------------+ E1: 1 * | E1 | E2 | E2: 0 * +-------+-------------+ * With previous simplified routines, after overwriting part of E2 with S, * the bad blocks table should be (E3 is remaining part of E2 which is not * overwritten by S), * acknowledged * +-------+--------+----+ S: 1 * | E1 | S | E3 | E1: 1 * +-------+--------+----+ E3: 0 * The above result is correct but not perfect. Range E1 and S in the bad * blocks table are all acked, merging them into a larger one range may * occupy less bad blocks table space and make badblocks_check() faster. * Therefore in such situation, after overwriting range S, the previous range * E1 should be checked for possible front combination. Then the ideal * result can be, * +----------------+----+ acknowledged * | E1 | E3 | E1: 1 * +----------------+----+ E3: 0 * 6.3) Behind merge: If the already set bad blocks range E is behind the setting * range S and they are adjacent. Normally we don't need to care about this * because front merge handles this while going though range S from head to * tail, except for the tail part of range S. When the setting range S are * fully handled, all the above simplified routine doesn't check whether the * tail LBA of range S is adjacent to the next already set range and not * merge them even it is possible. * +------+ * | S | * +------+ * +-------+ * | E | * +-------+ * For the above special situation, when the setting range S are all handled * and the loop ends, an extra check is necessary for whether next already * set range E is right after S and mergeable. * 6.3.1) When total size of range E and S <= BB_MAX_LEN, and their acknowledge * values are same, the setting range S can behind merges into range E. The * result is, * +--------------+ * | S | * +--------------+ * 6.3.2) Otherwise these two ranges cannot merge, just insert the setting range * S in front of the already set range E in the bad blocks table. The result * is, * +------+-------+ * | S | E | * +------+-------+ * * All the above 5 simplified situations and 3 special cases may cover 99%+ of * the bad block range setting conditions. Maybe there is some rare corner case * is not considered and optimized, it won't hurt if badblocks_set() fails due * to no space, or some ranges are not merged to save bad blocks table space. * * Inside badblocks_set() each loop starts by jumping to re_insert label, every * time for the new loop prev_badblocks() is called to find an already set range * which starts before or at current setting range. Since the setting bad blocks * range is handled from head to tail, most of the cases it is unnecessary to do * the binary search inside prev_badblocks(), it is possible to provide a hint * to prev_badblocks() for a fast path, then the expensive binary search can be * avoided. In my test with the hint to prev_badblocks(), except for the first * loop, all rested calls to prev_badblocks() can go into the fast path and * return correct bad blocks table index immediately. * * * Clearing a bad blocks range from the bad block table has similar idea as * setting does, but much more simpler. The only thing needs to be noticed is * when the clearing range hits middle of a bad block range, the existing bad * block range will split into two, and one more item should be added into the * bad block table. The simplified situations to be considered are, (The already * set bad blocks ranges in bad block table are naming with prefix E, and the * clearing bad blocks range is naming with prefix C) * * 1) A clearing range is not overlapped to any already set ranges in bad block * table. * +-----+ | +-----+ | +-----+ * | C | | | C | | | C | * +-----+ or +-----+ or +-----+ * +---+ | +----+ +----+ | +---+ * | E | | | E1 | | E2 | | | E | * +---+ | +----+ +----+ | +---+ * For the above situations, no bad block to be cleared and no failure * happens, simply returns 0. * 2) The clearing range hits middle of an already setting bad blocks range in * the bad block table. * +---+ * | C | * +---+ * +-----------------+ * | E | * +-----------------+ * In this situation if the bad block table is not full, the range E will be * split into two ranges E1 and E2. The result is, * +------+ +------+ * | E1 | | E2 | * +------+ +------+ * 3) The clearing range starts exactly at same LBA as an already set bad block range * from the bad block table. * 3.1) Partially covered at head part * +------------+ * | C | * +------------+ * +-----------------+ * | E | * +-----------------+ * For this situation, the overlapped already set range will update the * start LBA to end of C and shrink the range to BB_LEN(E) - BB_LEN(C). No * item deleted from bad block table. The result is, * +----+ * | E1 | * +----+ * 3.2) Exact fully covered * +-----------------+ * | C | * +-----------------+ * +-----------------+ * | E | * +-----------------+ * For this situation the whole bad blocks range E will be cleared and its * corresponded item is deleted from the bad block table. * 4) The clearing range exactly ends at same LBA as an already set bad block * range. * +-------+ * | C | * +-------+ * +-----------------+ * | E | * +-----------------+ * For the above situation, the already set range E is updated to shrink its * end to the start of C, and reduce its length to BB_LEN(E) - BB_LEN(C). * The result is, * +---------+ * | E | * +---------+ * 5) The clearing range is partially overlapped with an already set bad block * range from the bad block table. * 5.1) The already set bad block range is front overlapped with the clearing * range. * +----------+ * | C | * +----------+ * +------------+ * | E | * +------------+ * For such situation, the clearing range C can be treated as two parts. The * first part ends at the start LBA of range E, and the second part starts at * same LBA of range E. * +----+-----+ +----+ +-----+ * | C1 | C2 | | C1 | | C2 | * +----+-----+ ===> +----+ +-----+ * +------------+ +------------+ * | E | | E | * +------------+ +------------+ * Now the first part C1 can be handled as condition 1), and the second part C2 can be * handled as condition 3.1) in next loop. * 5.2) The already set bad block range is behind overlaopped with the clearing * range. * +----------+ * | C | * +----------+ * +------------+ * | E | * +------------+ * For such situation, the clearing range C can be treated as two parts. The * first part C1 ends at same end LBA of range E, and the second part starts * at end LBA of range E. * +----+-----+ +----+ +-----+ * | C1 | C2 | | C1 | | C2 | * +----+-----+ ===> +----+ +-----+ * +------------+ +------------+ * | E | | E | * +------------+ +------------+ * Now the first part clearing range C1 can be handled as condition 4), and * the second part clearing range C2 can be handled as condition 1) in next * loop. * * All bad blocks range clearing can be simplified into the above 5 situations * by only handling the head part of the clearing range in each run of the * while-loop. The idea is similar to bad blocks range setting but much * simpler. */ /* * Find the range starts at-or-before 's' from bad table. The search * starts from index 'hint' and stops at index 'hint_end' from the bad * table. */ static int prev_by_hint(struct badblocks *bb, sector_t s, int hint) { int hint_end = hint + 2; u64 *p = bb->page; int ret = -1; while ((hint < hint_end) && ((hint + 1) <= bb->count) && (BB_OFFSET(p[hint]) <= s)) { if ((hint + 1) == bb->count || BB_OFFSET(p[hint + 1]) > s) { ret = hint; break; } hint++; } return ret; } /* * Find the range starts at-or-before bad->start. If 'hint' is provided * (hint >= 0) then search in the bad table from hint firstly. It is * very probably the wanted bad range can be found from the hint index, * then the unnecessary while-loop iteration can be avoided. */ static int prev_badblocks(struct badblocks *bb, struct badblocks_context *bad, int hint) { sector_t s = bad->start; int ret = -1; int lo, hi; u64 *p; if (!bb->count) goto out; if (hint >= 0) { ret = prev_by_hint(bb, s, hint); if (ret >= 0) goto out; } lo = 0; hi = bb->count; p = bb->page;