On Sat, Dec 11, 2021 at 12:05 AM Coly Li <col...@suse.de> wrote:
>
> Recently I received a bug report that current badblocks code does not
> properly handle multiple ranges. For example,
> badblocks_set(bb, 32, 1, true);
> badblocks_set(bb, 34, 1, true);
> badblocks_set(bb, 36, 1, true);
> badblocks_set(bb, 32, 12, true);
> Then indeed badblocks_show() reports,
> 32 3
> 36 1
> But the expected bad blocks table should be,
> 32 12
> Obviously only the first 2 ranges are merged and badblocks_set() returns
> and ignores the rest setting range.
>
> This behavior is improper, if the caller of badblocks_set() wants to set
> a range of blocks into bad blocks table, all of the blocks in the range
> should be handled even the previous part encountering failure.
>
> The desired way to set bad blocks range by badblocks_set() is,
> - Set as many as blocks in the setting range into bad blocks table.
> - Merge the bad blocks ranges and occupy as less as slots in the bad
> blocks table.
> - Fast.
>
> Indeed the above proposal is complicated, especially with the following
> restrictions,
> - The setting bad blocks range can be acknowledged or not acknowledged.
> - The bad blocks table size is limited.
> - Memory allocation should be avoided.
>
> The basic idea of the patch is to categorize all possible bad blocks
> range setting combinations into to much less simplified and more less
typo error? s/to//g
> special conditions. Inside badblocks_set() there is an implicit loop
> composed by jumping between labels 're_insert' and 'update_sectors'. No
> matter how large the setting bad blocks range is, in every loop just a
> minimized range from the head is handled by a pre-defined behavior from
> one of the categorized conditions. The logic is simple and code flow is
> manageable.
>
> The different relative layout between the setting range and existing bad
> block range are checked and handled (merge, combine, overwrite, insert)
> by the helpers in previous patch. This patch is to make all the helpers
> work together with the above idea.
>
> This patch only has the algorithm improvement for badblocks_set(). There
> are following patches contain improvement for badblocks_clear() and
> badblocks_check(). But the algorithm in badblocks_set() is fundamental
> and typical, other improvement in clear and check routines are based on
> all the helpers and ideas in this patch.
>
> In order to make the change to be more clear for code review, this patch
> does not directly modify existing badblocks_set(), and just add a new
> one named _badblocks_set(). Later patch will remove current existing
> badblocks_set() code and make it as a wrapper of _badblocks_set(). So
> the new added change won't be mixed with deleted code, the code review
> can be easier.
>
> Signed-off-by: Coly Li <col...@suse.de>
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Geliang Tang <geliang.t...@suse.com>
> Cc: Hannes Reinecke <h...@suse.de>
> Cc: Jens Axboe <ax...@kernel.dk>
> Cc: NeilBrown <ne...@suse.de>
> Cc: Vishal L Verma <vishal.l.ve...@intel.com>
> Cc: Wols Lists <antli...@youngman.org.uk>
> ---
> block/badblocks.c | 560 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 540 insertions(+), 20 deletions(-)
>
> diff --git a/block/badblocks.c b/block/badblocks.c
> index 30958cc4469f..f45f82646bb7 100644
> --- a/block/badblocks.c
> +++ b/block/badblocks.c
> @@ -16,6 +16,322 @@
> #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 twp 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), 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 |
> + * +--------+------+
When I read here at the first time, I thought why there is not behind
merge. After reading
the following comments, it should be the 6.3, right?
> + * 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
> able
> + * to them if they are mergeable.
to merge them
> + * +------+
> + * | 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.
It's the codes in the update_sectors, right? It checks the p[prev] and p[prev+1]
> + * 6.2.1) When total size of range E and S <= BB_MAX_LEN, and their
> acknowledge
6.3.1
> + * values are same, the setting range S can behind merges into range E.
> The
> + * result is,
> + * +--------------+
> + * | S |
> + * +--------------+
> + * 6.2.2) Otherwise these two ranges cannot merge, just insert the setting
> range
6.3.2
> + * 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.
> + */
> +
> /*
> * 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
> @@ -392,6 +708,230 @@ static int insert_at(struct badblocks *bb, int at,
> struct badblocks_context *bad
> return len;
> }
>
> +static void badblocks_update_acked(struct badblocks *bb)
> +{
> + bool unacked = false;
> + u64 *p = bb->page;
> + int i;
> +
> + if (!bb->unacked_exist)
> + return;
> +
> + for (i = 0; i < bb->count ; i++) {
> + if (!BB_ACK(p[i])) {
> + unacked = true;
> + break;
> + }
> + }
> +
> + if (!unacked)
> + bb->unacked_exist = 0;
> +}
> +
> +/* Do exact work to set bad block range into the bad block table */
> +static int _badblocks_set(struct badblocks *bb, sector_t s, int sectors,
> + int acknowledged)
> +{
> + int retried = 0, space_desired = 0;
> + int orig_len, len = 0, added = 0;
> + struct badblocks_context bad;
> + int prev = -1, hint = -1;
> + sector_t orig_start;
> + unsigned long flags;
> + int rv = 0;
> + u64 *p;
> +
> + if (bb->shift < 0)
> + /* badblocks are disabled */
> + return 1;
> +
> + if (sectors == 0)
> + /* Invalid sectors number */
> + return 1;
> +
> + if (bb->shift) {
> + /* round the start down, and the end up */
> + sector_t next = s + sectors;
> +
> + rounddown(s, bb->shift);
> + roundup(next, bb->shift);
> + sectors = next - s;
> + }
> +
> + write_seqlock_irqsave(&bb->lock, flags);
> +
> + orig_start = s;
> + orig_len = sectors;
> + bad.ack = acknowledged;
> + p = bb->page;
> +
> +re_insert:
> + bad.start = s;
> + bad.len = sectors;
> + len = 0;
> +
> + if (badblocks_empty(bb)) {
> + len = insert_at(bb, 0, &bad);
> + bb->count++;
> + added++;
> + goto update_sectors;
> + }
> +
> + prev = prev_badblocks(bb, &bad, hint);
> +
> + /* start before all badblocks */
> + if (prev < 0) {
> + if (!badblocks_full(bb)) {
> + /* insert on the first */
> + if (bad.len > (BB_OFFSET(p[0]) - bad.start))
> + bad.len = BB_OFFSET(p[0]) - bad.start;
> + len = insert_at(bb, 0, &bad);
> + bb->count++;
> + added++;
> + hint = 0;
Does it need to set prev to 0 here? It's -1 now. In update_sectors, it
checks p[-1] and p[0].
I guess it should check p[0] and [1].
> + goto update_sectors;
> + }
> +
> + /* No sapce, try to merge */
> + if (overlap_behind(bb, &bad, 0)) {
> + if (can_merge_behind(bb, &bad, 0)) {
> + len = behind_merge(bb, &bad, 0);
> + added++;
> + } else {
> + len = min_t(sector_t,
> + BB_OFFSET(p[0]) - s, sectors);
It doesn't need to check min_t here. sectors must be >= (BB_OFFSET(p[0] - s))
> + space_desired = 1;
> + }
> + hint = 0;
prev=0?
> + goto update_sectors;
> + }
> +
> + /* no table space and give up */
> + goto out;
> + }
> +
> + /* in case p[prev-1] can be merged with p[prev] */
> + if (can_combine_front(bb, prev, &bad)) {
> + front_combine(bb, prev);
> + bb->count--;
> + added++;
> + hint = prev;
> + goto update_sectors;
> + }
> +
> + if (overlap_front(bb, prev, &bad)) {
> + if (can_merge_front(bb, prev, &bad)) {
> + len = front_merge(bb, prev, &bad);
> + added++;
> + } else {
> + int extra = 0;
> +
> + if (!can_front_overwrite(bb, prev, &bad, &extra)) {
> + len = min_t(sector_t,
> + BB_END(p[prev]) - s, sectors);
> + hint = prev;
> + goto update_sectors;
> + }
> +
> + len = front_overwrite(bb, prev, &bad, extra);
> + added++;
> + bb->count += extra;
> +
> + if (can_combine_front(bb, prev, &bad)) {
> + front_combine(bb, prev);
> + bb->count--;
> + }
> + }
> + hint = prev;
> + goto update_sectors;
> + }
> +
> + if (can_merge_front(bb, prev, &bad)) {
> + len = front_merge(bb, prev, &bad);
> + added++;
> + hint = prev;
> + goto update_sectors;
> + }
When I'm here. I have a confused question. Why we need front_combine?
It looks like
front_merge can do this job too. In front_combine, it needs bad->start
== BB_OFFSET(p[prev]).
Why does it need this judgement?
Best Regards
Xiao
> +
> + /* if no space in table, still try to merge in the covered range */
> + if (badblocks_full(bb)) {
> + /* skip the cannot-merge range */
> + if (((prev + 1) < bb->count) &&
> + overlap_behind(bb, &bad, prev + 1) &&
> + ((s + sectors) >= BB_END(p[prev + 1]))) {
> + len = BB_END(p[prev + 1]) - s;
> + hint = prev + 1;
> + goto update_sectors;
> + }
> +
> + /* no retry any more */
> + len = sectors;
> + space_desired = 1;
> + hint = -1;
> + goto update_sectors;
> + }
> +
> + /* cannot merge and there is space in bad table */
> + if ((prev + 1) < bb->count &&
> + overlap_behind(bb, &bad, prev + 1))
> + bad.len = min_t(sector_t,
> + bad.len, BB_OFFSET(p[prev + 1]) - bad.start);
> +
> + len = insert_at(bb, prev + 1, &bad);
> + bb->count++;
> + added++;
> + hint = prev + 1;
> +
> +update_sectors:
> + s += len;
> + sectors -= len;
> +
> + if (sectors > 0)
> + goto re_insert;
> +
> + WARN_ON(sectors < 0);
> +
> + /* Check whether the following already set range can be merged */
> + if ((prev + 1) < bb->count &&
> + BB_END(p[prev]) == BB_OFFSET(p[prev + 1]) &&
> + (BB_LEN(p[prev]) + BB_LEN(p[prev + 1])) <= BB_MAX_LEN &&
> + BB_ACK(p[prev]) == BB_ACK(p[prev + 1])) {
> + p[prev] = BB_MAKE(BB_OFFSET(p[prev]),
> + BB_LEN(p[prev]) + BB_LEN(p[prev + 1]),
> + BB_ACK(p[prev]));
> +
> + if ((prev + 2) < bb->count)
> + memmove(p + prev + 1, p + prev + 2,
> + (bb->count - (prev + 2)) * 8);
> + bb->count--;
> + }
> +
> + if (space_desired && !badblocks_full(bb)) {
> + s = orig_start;
> + sectors = orig_len;
> + space_desired = 0;
> + if (retried++ < 3)
> + goto re_insert;
> + }
> +
> +out:
> + if (added) {
> + set_changed(bb);
> +
> + if (!acknowledged)
> + bb->unacked_exist = 1;
> + else
> + badblocks_update_acked(bb);
> + }
> +
> + write_sequnlock_irqrestore(&bb->lock, flags);
> +
> + if (!added)
> + rv = 1;
> +
> + return rv;
> +}
> +
> /**
> * badblocks_check() - check a given range for bad sectors
> * @bb: the badblocks structure that holds all badblock
> information
> @@ -501,26 +1041,6 @@ int badblocks_check(struct badblocks *bb, sector_t s,
> int sectors,
> }
> EXPORT_SYMBOL_GPL(badblocks_check);
>
> -static void badblocks_update_acked(struct badblocks *bb)
> -{
> - u64 *p = bb->page;
> - int i;
> - bool unacked = false;
> -
> - if (!bb->unacked_exist)
> - return;
> -
> - for (i = 0; i < bb->count ; i++) {
> - if (!BB_ACK(p[i])) {
> - unacked = true;
> - break;
> - }
> - }
> -
> - if (!unacked)
> - bb->unacked_exist = 0;
> -}
> -
> /**
> * badblocks_set() - Add a range of bad blocks to the table.
> * @bb: the badblocks structure that holds all badblock
> information
> --
> 2.31.1
>
