lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1341389164-24409-1-git-send-email-shmulik.ladkani@gmail.com>
Date:	Wed,  4 Jul 2012 11:05:59 +0300
From:	Shmulik Ladkani <shmulik.ladkani@...il.com>
To:	Artem Bityutskiy <dedekind1@...il.com>
Cc:	Shmulik Ladkani <shmulik.ladkani@...il.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Richard Weinberger <richard@....at>,
	Richard Genoud <richard.genoud@...il.com>
Subject: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

The existing mechanism of reserving PEBs for bad PEB handling has two
flaws:
- It is calculated as a percentage of good PEBs instead of total PEBs.
- There's no limit on the amount of PEBs UBI reserves for future bad
  eraseblock handling.

This patchset changes the mechanism to overcome these flaws.

The caculation of PEBs reserved for bad PEB handling will be based on a
new property, ubi->bad_peb_limit, which specifies an upper limit of PEBs
ubi expects to go bad (currently initialized to a fixed percentage of
total PEBs in the ubi device, configurable via CONFIG_MTD_UBI_BEB_LIMIT,
but can be easily augmented to support a per ubi-attach limit).

The desired level of PEBs reserved for bad PEB handling (beb_rsvd_level)
is set to the maximum expected bad eraseblocks (bad_peb_limit) minus the
existing number of bad eraseblocks (bad_peb_count).

The actual amount of PEBs reserved for bad PEB handling is usually set
to the desired level (but in some circumstances may be lower than the
desired level, e.g. when attaching to a device that has too few
available PEBs to satisfy the desired level).

In the case where the device has too many bad PEBs (above the expected
limit), then the desired level, and the actual amount of PEBs reserved
are set to zero. No PEBs will be set aside for future bad eraseblock
handling - even if some PEBs are made available (e.g. by shrinking a
volume).
If another PEB goes bad, and there are available PEBs, then the
eraseblock will be marked bad (consuming one available PEB). But if
there are no available PEBs, ubi will go into readonly mode.


Shmulik Ladkani (5):
  ubi: introduce ubi->bad_peb_limit
  ubi: Limit amount of reserved eraseblocks for bad PEB handling
  ubi: kill CONFIG_MTD_UBI_BEB_RESERVE
  ubi: trivial: fix comment of ubi_calculate_reserved()
  ubi: harmonize the update of ubi->beb_rsvd_pebs

 arch/arm/configs/sam9_l9260_defconfig |    2 +-
 drivers/mtd/ubi/Kconfig               |   24 ++++++++++-------
 drivers/mtd/ubi/build.c               |   13 +++++++++-
 drivers/mtd/ubi/misc.c                |   44 +++++++++++++++++++++++++++++---
 drivers/mtd/ubi/ubi.h                 |    6 ++--
 drivers/mtd/ubi/vmt.c                 |   20 +-------------
 drivers/mtd/ubi/wl.c                  |   44 +++++++++++++++++++++------------
 7 files changed, 99 insertions(+), 54 deletions(-)

-- 
1.7.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ