* [PATCH v4 05/12] crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, linux-ima-user, qat-linux, d.kasatkin,
bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, akpm, zohar,
linux-btrfs, serge
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/crypto/n2_core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 7263c10..f8e3207 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -445,10 +445,7 @@ static int n2_hmac_async_setkey(struct crypto_ahash *tfm, const u8 *key,
struct n2_hmac_ctx *ctx = crypto_ahash_ctx(tfm);
struct crypto_shash *child_shash = ctx->child_shash;
struct crypto_ahash *fallback_tfm;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(child_shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, child_shash);
int err, bs, ds;
fallback_tfm = ctx->base.fallback_tfm;
@@ -456,15 +453,15 @@ static int n2_hmac_async_setkey(struct crypto_ahash *tfm, const u8 *key,
if (err)
return err;
- desc.shash.tfm = child_shash;
- desc.shash.flags = crypto_ahash_get_flags(tfm) &
+ shash->tfm = child_shash;
+ shash->flags = crypto_ahash_get_flags(tfm) &
CRYPTO_TFM_REQ_MAY_SLEEP;
bs = crypto_shash_blocksize(child_shash);
ds = crypto_shash_digestsize(child_shash);
BUG_ON(ds > N2_HASH_KEY_MAX);
if (keylen > bs) {
- err = crypto_shash_digest(&desc.shash, key, keylen,
+ err = crypto_shash_digest(shash, key, keylen,
ctx->hash_key);
if (err)
return err;
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v4 06/12] crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, linux-ima-user, qat-linux, d.kasatkin,
bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, akpm, zohar,
linux-btrfs, serge
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/crypto/omap-sham.c | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 710d863..24ef489 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -949,17 +949,14 @@ static int omap_sham_finish_hmac(struct ahash_request *req)
struct omap_sham_hmac_ctx *bctx = tctx->base;
int bs = crypto_shash_blocksize(bctx->shash);
int ds = crypto_shash_digestsize(bctx->shash);
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(bctx->shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, bctx->shash);
- desc.shash.tfm = bctx->shash;
- desc.shash.flags = 0; /* not CRYPTO_TFM_REQ_MAY_SLEEP */
+ shash->tfm = bctx->shash;
+ shash->flags = 0; /* not CRYPTO_TFM_REQ_MAY_SLEEP */
- return crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, bctx->opad, bs) ?:
- crypto_shash_finup(&desc.shash, req->result, ds, req->result);
+ return crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, bctx->opad, bs) ?:
+ crypto_shash_finup(shash, req->result, ds, req->result);
}
static int omap_sham_finish(struct ahash_request *req)
@@ -1118,18 +1115,15 @@ static int omap_sham_update(struct ahash_request *req)
return omap_sham_enqueue(req, OP_UPDATE);
}
-static int omap_sham_shash_digest(struct crypto_shash *shash, u32 flags,
+static int omap_sham_shash_digest(struct crypto_shash *tfm, u32 flags,
const u8 *data, unsigned int len, u8 *out)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
- desc.shash.tfm = shash;
- desc.shash.flags = flags & CRYPTO_TFM_REQ_MAY_SLEEP;
+ shash->tfm = tfm;
+ shash->flags = flags & CRYPTO_TFM_REQ_MAY_SLEEP;
- return crypto_shash_digest(&desc.shash, data, len, out);
+ return crypto_shash_digest(shash, data, len, out);
}
static int omap_sham_final_shash(struct ahash_request *req)
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v4 07/12] crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, linux-ima-user, qat-linux, d.kasatkin,
bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, akpm, zohar,
linux-btrfs, serge
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/crypto/qat/qat_common/qat_algs.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c
index 59df488..9cabadd 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -152,10 +152,7 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
const uint8_t *auth_key,
unsigned int auth_keylen, uint8_t *auth_state)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(ctx->hash_tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, ctx->hash_tfm);
struct sha1_state sha1;
struct sha256_state sha256;
struct sha512_state sha512;
@@ -167,12 +164,12 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
__be64 *hash512_state_out;
int i, offset;
- desc.shash.tfm = ctx->hash_tfm;
- desc.shash.flags = 0x0;
+ shash->tfm = ctx->hash_tfm;
+ shash->flags = 0x0;
if (auth_keylen > block_size) {
char buff[SHA512_BLOCK_SIZE];
- int ret = crypto_shash_digest(&desc.shash, auth_key,
+ int ret = crypto_shash_digest(shash, auth_key,
auth_keylen, buff);
if (ret)
return ret;
@@ -195,10 +192,10 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
*opad_ptr ^= 0x5C;
}
- if (crypto_shash_init(&desc.shash))
+ if (crypto_shash_init(shash))
return -EFAULT;
- if (crypto_shash_update(&desc.shash, ipad, block_size))
+ if (crypto_shash_update(shash, ipad, block_size))
return -EFAULT;
hash_state_out = (__be32 *)hash->sha.state1;
@@ -206,19 +203,19 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
switch (ctx->qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
- if (crypto_shash_export(&desc.shash, &sha1))
+ if (crypto_shash_export(shash, &sha1))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha1.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
- if (crypto_shash_export(&desc.shash, &sha256))
+ if (crypto_shash_export(shash, &sha256))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha256.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
- if (crypto_shash_export(&desc.shash, &sha512))
+ if (crypto_shash_export(shash, &sha512))
return -EFAULT;
for (i = 0; i < digest_size >> 3; i++, hash512_state_out++)
*hash512_state_out = cpu_to_be64(*(sha512.state + i));
@@ -227,10 +224,10 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
return -EFAULT;
}
- if (crypto_shash_init(&desc.shash))
+ if (crypto_shash_init(shash))
return -EFAULT;
- if (crypto_shash_update(&desc.shash, opad, block_size))
+ if (crypto_shash_update(shash, opad, block_size))
return -EFAULT;
offset = round_up(qat_get_inter_state_size(ctx->qat_hash_alg), 8);
@@ -239,19 +236,19 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
switch (ctx->qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
- if (crypto_shash_export(&desc.shash, &sha1))
+ if (crypto_shash_export(shash, &sha1))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha1.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
- if (crypto_shash_export(&desc.shash, &sha256))
+ if (crypto_shash_export(shash, &sha256))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha256.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
- if (crypto_shash_export(&desc.shash, &sha512))
+ if (crypto_shash_export(shash, &sha512))
return -EFAULT;
for (i = 0; i < digest_size >> 3; i++, hash512_state_out++)
*hash512_state_out = cpu_to_be64(*(sha512.state + i));
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v4 08/12] crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: john.griffin, Behan Webster, linux-ima-devel, qat-linux, pageexec,
zohar, gmazyland, serge, thomas.lendacky, linux-ima-user,
d.kasatkin, linux-raid, james.l.morris, bruce.w.allan,
linux-kernel, linux-security-module, linux-crypto,
Jan-Simon Möller, akpm, torvalds, linux-btrfs
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: pageexec@freemail.hu
Cc: gmazyland@gmail.com
Cc: "David S. Miller" <davem@davemloft.net>
---
drivers/md/dm-crypt.c | 34 ++++++++++++++--------------------
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index cd15e08..fc93b93 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -526,29 +526,26 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8 *iv,
u8 *data)
{
struct iv_lmk_private *lmk = &cc->iv_gen_private.lmk;
- struct {
- struct shash_desc desc;
- char ctx[crypto_shash_descsize(lmk->hash_tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(desc, lmk->hash_tfm);
struct md5_state md5state;
__le32 buf[4];
int i, r;
- sdesc.desc.tfm = lmk->hash_tfm;
- sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ desc->tfm = lmk->hash_tfm;
+ desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
- r = crypto_shash_init(&sdesc.desc);
+ r = crypto_shash_init(desc);
if (r)
return r;
if (lmk->seed) {
- r = crypto_shash_update(&sdesc.desc, lmk->seed, LMK_SEED_SIZE);
+ r = crypto_shash_update(desc, lmk->seed, LMK_SEED_SIZE);
if (r)
return r;
}
/* Sector is always 512B, block size 16, add data of blocks 1-31 */
- r = crypto_shash_update(&sdesc.desc, data + 16, 16 * 31);
+ r = crypto_shash_update(desc, data + 16, 16 * 31);
if (r)
return r;
@@ -557,12 +554,12 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8 *iv,
buf[1] = cpu_to_le32((((u64)dmreq->iv_sector >> 32) & 0x00FFFFFF) | 0x80000000);
buf[2] = cpu_to_le32(4024);
buf[3] = 0;
- r = crypto_shash_update(&sdesc.desc, (u8 *)buf, sizeof(buf));
+ r = crypto_shash_update(desc, (u8 *)buf, sizeof(buf));
if (r)
return r;
/* No MD5 padding here */
- r = crypto_shash_export(&sdesc.desc, &md5state);
+ r = crypto_shash_export(desc, &md5state);
if (r)
return r;
@@ -679,10 +676,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
struct iv_tcw_private *tcw = &cc->iv_gen_private.tcw;
u64 sector = cpu_to_le64((u64)dmreq->iv_sector);
u8 buf[TCW_WHITENING_SIZE];
- struct {
- struct shash_desc desc;
- char ctx[crypto_shash_descsize(tcw->crc32_tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(desc, tcw->crc32_tfm);
int i, r;
/* xor whitening with sector number */
@@ -691,16 +685,16 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
crypto_xor(&buf[8], (u8 *)§or, 8);
/* calculate crc32 for every 32bit part and xor it */
- sdesc.desc.tfm = tcw->crc32_tfm;
- sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ desc->tfm = tcw->crc32_tfm;
+ desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
for (i = 0; i < 4; i++) {
- r = crypto_shash_init(&sdesc.desc);
+ r = crypto_shash_init(desc);
if (r)
goto out;
- r = crypto_shash_update(&sdesc.desc, &buf[i * 4], 4);
+ r = crypto_shash_update(desc, &buf[i * 4], 4);
if (r)
goto out;
- r = crypto_shash_final(&sdesc.desc, &buf[i * 4]);
+ r = crypto_shash_final(desc, &buf[i * 4]);
if (r)
goto out;
}
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v4 09/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, Jan-Simon Möller, linux-ima-user, qat-linux,
d.kasatkin, bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, akpm, pageexec, zohar,
linux-btrfs, serge
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: pageexec@freemail.hu
---
crypto/hmac.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 8d9544c..e392219 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -52,20 +52,17 @@ static int hmac_setkey(struct crypto_shash *parent,
struct hmac_ctx *ctx = align_ptr(opad + ss,
crypto_tfm_ctx_alignment());
struct crypto_shash *hash = ctx->hash;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(hash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, hash);
unsigned int i;
- desc.shash.tfm = hash;
- desc.shash.flags = crypto_shash_get_flags(parent) &
- CRYPTO_TFM_REQ_MAY_SLEEP;
+ shash->tfm = hash;
+ shash->flags = crypto_shash_get_flags(parent)
+ & CRYPTO_TFM_REQ_MAY_SLEEP;
if (keylen > bs) {
int err;
- err = crypto_shash_digest(&desc.shash, inkey, keylen, ipad);
+ err = crypto_shash_digest(shash, inkey, keylen, ipad);
if (err)
return err;
@@ -81,12 +78,12 @@ static int hmac_setkey(struct crypto_shash *parent,
opad[i] ^= 0x5c;
}
- return crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, ipad, bs) ?:
- crypto_shash_export(&desc.shash, ipad) ?:
- crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, opad, bs) ?:
- crypto_shash_export(&desc.shash, opad);
+ return crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, ipad, bs) ?:
+ crypto_shash_export(shash, ipad) ?:
+ crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, opad, bs) ?:
+ crypto_shash_export(shash, opad);
}
static int hmac_export(struct shash_desc *pdesc, void *out)
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v4 10/12] crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: pageexec@freemail.hu
Cc: "David S. Miller" <davem@davemloft.net>
---
lib/libcrc32c.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/lib/libcrc32c.c b/lib/libcrc32c.c
index b3131f5..6a08ce7 100644
--- a/lib/libcrc32c.c
+++ b/lib/libcrc32c.c
@@ -41,20 +41,18 @@ static struct crypto_shash *tfm;
u32 crc32c(u32 crc, const void *address, unsigned int length)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
+ u32 *ctx = (u32 *)shash_desc_ctx(shash);
int err;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
- *(u32 *)desc.ctx = crc;
+ shash->tfm = tfm;
+ shash->flags = 0;
+ *ctx = crc;
- err = crypto_shash_update(&desc.shash, address, length);
+ err = crypto_shash_update(shash, address, length);
BUG_ON(err);
- return *(u32 *)desc.ctx;
+ return *ctx;
}
EXPORT_SYMBOL(crc32c);
--
1.9.1
^ permalink raw reply related
* [PATCH v4 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster, tglx
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: tglx@linutronix.de
---
security/integrity/ima/ima_crypto.c | 47 +++++++++++++++----------------------
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0bd7328..e35f5d9 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -380,17 +380,14 @@ static int ima_calc_file_hash_tfm(struct file *file,
loff_t i_size, offset = 0;
char *rbuf;
int rc, read = 0;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
hash->length = crypto_shash_digestsize(tfm);
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -420,7 +417,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
break;
offset += rbuf_len;
- rc = crypto_shash_update(&desc.shash, rbuf, rbuf_len);
+ rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
}
@@ -429,7 +426,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
kfree(rbuf);
out:
if (!rc)
- rc = crypto_shash_final(&desc.shash, hash->digest);
+ rc = crypto_shash_final(shash, hash->digest);
return rc;
}
@@ -487,18 +484,15 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
struct ima_digest_data *hash,
struct crypto_shash *tfm)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
int rc, i;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
hash->length = crypto_shash_digestsize(tfm);
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -508,7 +502,7 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
u32 datalen = field_data[i].len;
if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
- rc = crypto_shash_update(&desc.shash,
+ rc = crypto_shash_update(shash,
(const u8 *) &field_data[i].len,
sizeof(field_data[i].len));
if (rc)
@@ -518,13 +512,13 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
data_to_hash = buffer;
datalen = IMA_EVENT_NAME_LEN_MAX + 1;
}
- rc = crypto_shash_update(&desc.shash, data_to_hash, datalen);
+ rc = crypto_shash_update(shash, data_to_hash, datalen);
if (rc)
break;
}
if (!rc)
- rc = crypto_shash_final(&desc.shash, hash->digest);
+ rc = crypto_shash_final(shash, hash->digest);
return rc;
}
@@ -565,15 +559,12 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
{
u8 pcr_i[TPM_DIGEST_SIZE];
int rc, i;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -581,10 +572,10 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
for (i = TPM_PCR0; i < TPM_PCR8; i++) {
ima_pcrread(i, pcr_i);
/* now accumulate with current aggregate */
- rc = crypto_shash_update(&desc.shash, pcr_i, TPM_DIGEST_SIZE);
+ rc = crypto_shash_update(shash, pcr_i, TPM_DIGEST_SIZE);
}
if (!rc)
- crypto_shash_final(&desc.shash, digest);
+ crypto_shash_final(shash, digest);
return rc;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v4 12/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c
From: behanw @ 2014-09-23 4:42 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec
In-Reply-To: <1411447337-22362-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: pageexec@freemail.hu
---
crypto/testmgr.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ac2b631..b959c0c 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1714,16 +1714,14 @@ static int alg_test_crc32c(const struct alg_test_desc *desc,
}
do {
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(shash, tfm);
+ u32 *ctx = (u32 *)shash_desc_ctx(shash);
- sdesc.shash.tfm = tfm;
- sdesc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
- *(u32 *)sdesc.ctx = le32_to_cpu(420553207);
- err = crypto_shash_final(&sdesc.shash, (u8 *)&val);
+ *ctx = le32_to_cpu(420553207);
+ err = crypto_shash_final(shash, (u8 *)&val);
if (err) {
printk(KERN_ERR "alg: crc32c: Operation failed for "
"%s: %d\n", driver, err);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* behind_writes
From: lilofile @ 2014-09-23 5:11 UTC (permalink / raw)
To: stan, Linux RAID, lilofile
In-Reply-To: <36ffd6f7-bfb0-4298-a18c-f45b07cab326@aliyun.com>
in struct bitmap,what the behind_writes variable means?
^ permalink raw reply
* Re: Moving root to raid, weird raid behaviour
From: Wols Lists @ 2014-09-23 8:52 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20140923103704.7116d112@notabene.brown>
On 23/09/14 01:37, NeilBrown wrote:
> On Mon, 22 Sep 2014 19:29:46 +0100 Wols Lists
> <antlists@youngman.org.uk> wrote:
>
>> I'm not sure if this is weird raid, stupid grub2 or incompetent
>> newbie, but whatever ... and the system is my development/test
>> system so if it gets trashed it's no disaster, but I would like
>> to understand what is going on ...
>>
>> Old setup / = sdb2 /var = sdc2 /home = mdX (sdb3, sdc3), mirror
>>
>> I added sdd and made a new / = mdY (sdd3, missing) mirror and
>> added sdd4 to mdX /home = mdX (sdb3 sdc3 sdd4)
>>
>> Weirdo one - sdd4 mirrored and synced fine. Then I rebooted ...
>> mdX = (sdb3 sdc3 missing) mdZ = (sdd4 missing missing)
>
> You probably have something silly in your initrd which is making
> invalid assumptions. What does /etc/mdadm.conf in your
> initrd/initramfs contain?
There shouldn't be anything there. I bombed into a grub2 shell, and
mdadm.conf appeared to be the empty default. I also used ark to peer
into the initramfs file and there didn't appear to be an mdadm.conf.
But I've just had a bit of an uh-oh moment. Bear in mind I have two
/boot's (mdY/boot and sdb2/boot), and two grubs or more (sda, sdb,
sdd), I could be barking up a wrong tree. So that's my next step, try
and *make* *sure* which grub I'm working with! Too many variables...
>
>>
>> wtf?!?!? - oh and both of them share the same uuid. The obvious
>> (but it shouldn't make any difference?) possibility is that sdb
>> and sdc are 500Gb, partitioned identically. sdd is 1Tb, so sdd4
>> is twice the size of the other two.
>>
>> The other weirdo is I'm trying to migrate from grub/mbr to
>> grub2/gpt. Of course that's causing me fun, but I've managed to
>> get the system booting fine from mdY. Only snag is, when I list
>> /dev, mdY isn't there! mount shows it as mounted on / but that's
>> the only place I can find it!
>
> udev should create it. 'udevadm trigger' should cause udev to
> create device files for all devices. That should be done as part
> of the boot sequence. If you run "udevadm trigger" does /dev/mdX
> get created?
>
No errors, no messages, no disk ...
>
>>
>> mdadm v3.2.6 kernel 3.14.14-gentoo
>>
>> Any ideas what's going on? I've googled, but everything I find
>> looks out of date or not relevant.
>
> "out of date or not relevant"?? You must have been looking on the
> Internet ?!?! :-)
:-)
The search results were mostly ubuntu (I run gentoo, but so what),
grub1, I'm migrating to grub2, and any mention of root/boot got plenty
of results about not finding root and failing to boot, but absolutely
nothing about successfully booting off a root that wasn't there! Plus
they all seemed to be 2010 or earlier ...
>
> NeilBrown
>
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH v4 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
From: Dmitry Kasatkin @ 2014-09-23 8:55 UTC (permalink / raw)
To: behanw, agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, james.l.morris, john.griffin, linux-btrfs,
linux-crypto, linux-ima-devel, linux-ima-user, linux-kernel,
linux-raid, linux-security-module, neilb, qat-linux, serge,
thomas.lendacky, zohar, torvalds, tglx
In-Reply-To: <1411447337-22362-12-git-send-email-behanw@converseincode.com>
On 23/09/14 07:42, behanw@converseincode.com wrote:
> From: Behan Webster <behanw@converseincode.com>
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This patch allocates the appropriate amount of memory
> using a char array using the SHASH_DESC_ON_STACK macro.
>
> The new code can be compiled with both gcc and clang.
>
> Signed-off-by: Behan Webster <behanw@converseincode.com>
> Reviewed-by: Mark Charlebois <charlebm@gmail.com>
> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: tglx@linutronix.de
Looks good. Thanks.
Acked-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
> ---
> security/integrity/ima/ima_crypto.c | 47 +++++++++++++++----------------------
> 1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 0bd7328..e35f5d9 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -380,17 +380,14 @@ static int ima_calc_file_hash_tfm(struct file *file,
> loff_t i_size, offset = 0;
> char *rbuf;
> int rc, read = 0;
> - struct {
> - struct shash_desc shash;
> - char ctx[crypto_shash_descsize(tfm)];
> - } desc;
> + SHASH_DESC_ON_STACK(shash, tfm);
>
> - desc.shash.tfm = tfm;
> - desc.shash.flags = 0;
> + shash->tfm = tfm;
> + shash->flags = 0;
>
> hash->length = crypto_shash_digestsize(tfm);
>
> - rc = crypto_shash_init(&desc.shash);
> + rc = crypto_shash_init(shash);
> if (rc != 0)
> return rc;
>
> @@ -420,7 +417,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
> break;
> offset += rbuf_len;
>
> - rc = crypto_shash_update(&desc.shash, rbuf, rbuf_len);
> + rc = crypto_shash_update(shash, rbuf, rbuf_len);
> if (rc)
> break;
> }
> @@ -429,7 +426,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
> kfree(rbuf);
> out:
> if (!rc)
> - rc = crypto_shash_final(&desc.shash, hash->digest);
> + rc = crypto_shash_final(shash, hash->digest);
> return rc;
> }
>
> @@ -487,18 +484,15 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> struct ima_digest_data *hash,
> struct crypto_shash *tfm)
> {
> - struct {
> - struct shash_desc shash;
> - char ctx[crypto_shash_descsize(tfm)];
> - } desc;
> + SHASH_DESC_ON_STACK(shash, tfm);
> int rc, i;
>
> - desc.shash.tfm = tfm;
> - desc.shash.flags = 0;
> + shash->tfm = tfm;
> + shash->flags = 0;
>
> hash->length = crypto_shash_digestsize(tfm);
>
> - rc = crypto_shash_init(&desc.shash);
> + rc = crypto_shash_init(shash);
> if (rc != 0)
> return rc;
>
> @@ -508,7 +502,7 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> u32 datalen = field_data[i].len;
>
> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
> - rc = crypto_shash_update(&desc.shash,
> + rc = crypto_shash_update(shash,
> (const u8 *) &field_data[i].len,
> sizeof(field_data[i].len));
> if (rc)
> @@ -518,13 +512,13 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> data_to_hash = buffer;
> datalen = IMA_EVENT_NAME_LEN_MAX + 1;
> }
> - rc = crypto_shash_update(&desc.shash, data_to_hash, datalen);
> + rc = crypto_shash_update(shash, data_to_hash, datalen);
> if (rc)
> break;
> }
>
> if (!rc)
> - rc = crypto_shash_final(&desc.shash, hash->digest);
> + rc = crypto_shash_final(shash, hash->digest);
>
> return rc;
> }
> @@ -565,15 +559,12 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
> {
> u8 pcr_i[TPM_DIGEST_SIZE];
> int rc, i;
> - struct {
> - struct shash_desc shash;
> - char ctx[crypto_shash_descsize(tfm)];
> - } desc;
> + SHASH_DESC_ON_STACK(shash, tfm);
>
> - desc.shash.tfm = tfm;
> - desc.shash.flags = 0;
> + shash->tfm = tfm;
> + shash->flags = 0;
>
> - rc = crypto_shash_init(&desc.shash);
> + rc = crypto_shash_init(shash);
> if (rc != 0)
> return rc;
>
> @@ -581,10 +572,10 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
> for (i = TPM_PCR0; i < TPM_PCR8; i++) {
> ima_pcrread(i, pcr_i);
> /* now accumulate with current aggregate */
> - rc = crypto_shash_update(&desc.shash, pcr_i, TPM_DIGEST_SIZE);
> + rc = crypto_shash_update(shash, pcr_i, TPM_DIGEST_SIZE);
> }
> if (!rc)
> - crypto_shash_final(&desc.shash, digest);
> + crypto_shash_final(shash, digest);
> return rc;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: not enough operational mirrors
From: Ian Young @ 2014-09-23 17:07 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <CANs+QMyuNDsxRVLbR_4-ki79x8OHRCwwMGOmbPkLRwM38ZBAaA@mail.gmail.com>
I booted from a live CD so I could use version 3.1.10 of xfs_repair
(versions < 3.1.8 reportedly have a bug when using ag_stride), then
ran the following command:
xfs_repair -P -o bhash=16384 -o ihash=16384 -o ag_stride=16
/dev/mapper/vg_raid10-srv
It stopped after a few seconds, saying:
xfs_repair: read failed: Input/output error
XFS: failed to find log head
zero_log: cannot find log head/tail (xlog_find_tail=5), zeroing it anyway
xfs_repair: libxfs_device_zero write failed: Input/output error
However, I was able to mount the volume after that and my data was
still there! Thanks for pointing me in the right direction with the
RAID.
On Mon, Sep 22, 2014 at 5:55 PM, Ian Young <ian@duffrecords.com> wrote:
> It's XFS. I'm running:
>
> xfs_repair -n /dev/mapper/vg_raid10-srv
>
> I expect it will take hours or days as this volume is 8.15 TiB.
>
> On Mon, Sep 22, 2014 at 4:53 PM, NeilBrown <neilb@suse.de> wrote:
>> On Mon, 22 Sep 2014 10:17:46 -0700 Ian Young <ian@duffrecords.com> wrote:
>>
>>> I forced the three good disks and the one that was behind by two
>>> events to assemble:
>>>
>>> mdadm --assemble --force /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sde2
>>>
>>> Then I added the other two disks and let it sync overnight:
>>>
>>> mdadm --add --force /dev/md0 /dev/sdd2
>>> mdadm --add --force /dev/md0 /dev/sdf2
>>>
>>> I rebooted the system in recovery mode and the root filesystem is
>>> back! However, / is read-only and my /srv partition, which is the
>>> largest and has most of my data, can't mount. When I try to examine
>>> the array, it says "no md superblock detected on /dev/md0." On top of
>>> the software RAID, I have four logical volumes. Here is the full LVM
>>> configuration:
>>>
>>> http://pastebin.com/gzdZq5DL
>>>
>>> How do I recover the superblock?
>>
>> What sort of filesystem is it? ext4??
>>
>> Try "fsck -n" and see if it finds anything.
>>
>> The fact that LVM found everything suggests that the array is mostly
>> working. Maybe just one superblock got corrupted somehow. If 'fsck' doesn't
>> get you anywhere you might need to ask on a forum dedicated to the particular
>> filesystem.
>>
>> NeilBrown
>>
>>
>>>
>>> On Sun, Sep 21, 2014 at 10:47 PM, NeilBrown <neilb@suse.de> wrote:
>>> > On Sun, 21 Sep 2014 22:32:19 -0700 Ian Young <ian@duffrecords.com> wrote:
>>> >
>>> >> My 6-drive software RAID 10 array failed. The individual drives
>>> >> failed one at a time over the past few months but it's been an
>>> >> extremely busy summer and I didn't have the free time to RMA the
>>> >> drives and rebuild the array. Now I'm wishing I had acted sooner
>>> >> because three of the drives are marked as removed and the array
>>> >> doesn't have enough mirrors to start. I followed the recovery
>>> >> instructions at raid.wiki.kernel.org and, before making things any
>>> >> worse, saved the status using mdadm --examine and consulted this
>>> >> mailing list. Here's the status:
>>> >>
>>> >> http://pastebin.com/KkV8e8Gq
>>> >>
>>> >> I can see that the event counts on sdd2 and sdf2 are significantly far
>>> >> behind, so we can consider that data too old. sdc2 is only behind by
>>> >> two events, so any data loss there should be minimal. If I can make
>>> >> the array start with sd[abce]2 I think that will be enough to mount
>>> >> the filesystem, back up my data, and start replacing drives. How do I
>>> >> do that?
>>> >
>>> > Use the "--force" option with "--assemble".
>>> >
>>> > NeilBrown
>>
^ permalink raw reply
* [GIT PULL REQUEST] late md/raid1 bug fixes for 3.17
From: NeilBrown @ 2014-09-24 2:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux RAID, lkml, Alexander Lyakas, Bassow Jonathan, majianpeng
[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]
Hi Linus,
it is amazing how much easier it is to find bugs when you know one is there.
Two bug reports resulted in finding 7 bugs!!
All are tagged for -stable. Those that can't cause (rare) data corruption,
cause lockups.
Thanks,
NeilBrown
The following changes since commit d030671f3f261e528dc6e396a13f10859a74ae7c:
Merge branch 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2014-09-07 20:20:16 -0700)
are available in the git repository at:
git://git.neil.brown.name/md/ tags/md/3.17-more-fixes
for you to fetch changes up to b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd:
md/raid1: fix_read_error should act on all non-faulty devices. (2014-09-22 11:26:01 +1000)
----------------------------------------------------------------
Bugfixes for md/raid1
particularly, but not only, fixing new "resync" code.
----------------------------------------------------------------
NeilBrown (8):
md/raid1: intialise start_next_window for READ case to avoid hang
md/raid1: be more cautious where we read-balance during resync.
md/raid1: clean up request counts properly in close_sync()
md/raid1: make sure resync waits for conflicting writes to complete.
md/raid1: Don't use next_resync to determine how far resync has progressed
md/raid1: update next_resync under resync_lock.
md/raid1: count resync requests in nr_pending.
md/raid1: fix_read_error should act on all non-faulty devices.
drivers/md/raid1.c | 40 ++++++++++++++++++++++------------------
1 file changed, 22 insertions(+), 18 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Fixes for RAID1 resync
From: Brassow Jonathan @ 2014-09-24 4:25 UTC (permalink / raw)
To: NeilBrown; +Cc: Eivind Sarto, linux-raid, majianpeng
In-Reply-To: <20140918174846.6a445eaf@notabene.brown>
On Sep 18, 2014, at 2:48 AM, NeilBrown wrote:
> On Tue, 16 Sep 2014 11:31:26 -0500 Brassow Jonathan <jbrassow@redhat.com>
> wrote:
>
>>
>> On Sep 14, 2014, at 10:30 PM, NeilBrown wrote:
>>
>>> On Thu, 11 Sep 2014 12:12:01 -0500 Brassow Jonathan <jbrassow@redhat.com>
>>> wrote:
>>>
>>>>
>>>> On Sep 10, 2014, at 10:45 PM, Brassow Jonathan wrote:
>>>>
>>>>>
>>>>> On Sep 10, 2014, at 1:20 AM, NeilBrown wrote:
>>>>>
>>>>>>
>>>>>> Jon: could you test with these patches on top of what you
>>>>>> have just in case something happens to fix the problem without
>>>>>> me realising it?
>>>>>
>>>>> I'm on it. The test is running. I'll know later tomorrow.
>>>>>
>>>>> brassow
>>>>
>>>> The test is still failing from here. I grabbed 3.17.0-rc4, added the 5 patches, and got the attached backtraces when testing. As I said, the hangs are not exactly the same. This set shows the mdX_raid1 thread in the middle of handling a read failure.
>>>
>>> Thanks.
>>> mdX_raid1 is blocked in freeze_array.
>>> That could be caused by conf->nr_pending nor aligning properly with
>>> conf->nr_queued.
>>>
>>> Both normal IO and resync IO can be retried with reschedule_retry()
>>> and so be counted into ->nr_queued, but only normal IO gets counted in
>>> ->nr_pending.
>>>
>>> Previously could could only possibly have on or the other and when handling
>>> a read failure it could only be normal IO. But now that they two types can
>>> interleave, we can have both normal and resync IO requests queued, so we need
>>> to count them both in nr_pending.
>>>
>>> So the following patch might help.
>>>
>>> How complicated are your test scripts? Could you send them to me so I can
>>> try too?
>>>
>>> Thanks,
>>> NeilBrown
>>>
>>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>>> index 888dbdfb6986..6a9c73435eb8 100644
>>> --- a/drivers/md/raid1.c
>>> +++ b/drivers/md/raid1.c
>>> @@ -856,6 +856,7 @@ static void raise_barrier(struct r1conf *conf, sector_t sector_nr)
>>> conf->next_resync + RESYNC_SECTORS),
>>> conf->resync_lock);
>>>
>>> + conf->nr_pending++;
>>> spin_unlock_irq(&conf->resync_lock);
>>> }
>>>
>>> @@ -865,6 +866,7 @@ static void lower_barrier(struct r1conf *conf)
>>> BUG_ON(conf->barrier <= 0);
>>> spin_lock_irqsave(&conf->resync_lock, flags);
>>> conf->barrier--;
>>> + conf->nr_pending--;
>>> spin_unlock_irqrestore(&conf->resync_lock, flags);
>>> wake_up(&conf->wait_barrier);
>>> }
>>
>> No luck, it is failing faster than before.
>>
>> I haven't looked into this myself, but the dm-raid1.c code makes use of dm-region-hash.c which coordinates recovery and nominal I/O in a way that allows them to both occur in a simple, non-overlapping way. I'm not sure it would make sense to use that instead of this new approach. I have no idea how much effort that would be, but I could have someone look into it at some point if you think it might be interesting.
>>
>
> Hi Jon,
> I can see the appeal of using known-working code, but there is every chance
> that we would break it when plugging it into md ;-)
>
> I've found another bug.... it is a very subtle one and it has been around
> since before the patch you bisected to so it probably isn't your bug.
> It also only affects array with bad-blocks listed. The patch is below
> but I very much doubt testing will show any change...
>
> I'll keep looking..... oh, found one. This one looks more convincing.
> If memory is short, make_request() will allocate an r1bio from the mempool
> rather than from the slab. That r1bio won't have just been zeroed.
> This is mostly OK as we initialise all the fields that aren't left in
> a clean state ... except ->start_next_window.
> We initialise that for write requests, but not for read.
> So when we use a mempool-allocated r1bio that was previously used for
> write and had ->start_next_window set, and is now used for read,
> then things will go wrong.
> So this patch definitely is worth testing.
> Thanks for your continued patience in testing!!!
>
>
> Thanks,
> NeilBrown
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index a95f9e179e6f..7187d9b8431f 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1185,6 +1185,7 @@ read_again:
> atomic_read(&bitmap->behind_writes) == 0);
> }
> r1_bio->read_disk = rdisk;
> + r1_bio->start_next_window = 0;
>
> read_bio = bio_clone_mddev(bio, GFP_NOIO, mddev);
> bio_trim(read_bio, r1_bio->sector - bio->bi_iter.bi_sector,
> @@ -1444,6 +1445,7 @@ read_again:
> r1_bio->state = 0;
> r1_bio->mddev = mddev;
> r1_bio->sector = bio->bi_iter.bi_sector + sectors_handled;
> + start_next_window = wait_barrier(conf, bio);
> goto retry_write;
> }
Sorry, still not there yet.
I'm sorry I haven't had more time to spend on this. I'll try to get some help (perhaps from Heinz) and see if we can pitch-in instead of making you do all the work.
brassow
Sep 23 05:01:39 bp-01 kernel: INFO: task kworker/u129:2:19096 blocked for more than 120 seconds.
Sep 23 05:01:39 bp-01 kernel: Tainted: G E 3.17.0-rc6 #1
Sep 23 05:01:39 bp-01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 23 05:01:39 bp-01 kernel: kworker/u129:2 D 0000000000000002 0 19096 2 0x00000080
Sep 23 05:01:39 bp-01 kernel: Workqueue: writeback bdi_writeback_workfn (flush-253:29)
Sep 23 05:01:39 bp-01 kernel: ffff8802079138c8 0000000000000046 ffffea0006f7b738 ffff880217260f00
Sep 23 05:01:39 bp-01 kernel: ffff880207910010 0000000000012bc0 0000000000012bc0 ffff880216aca0d0
Sep 23 05:01:39 bp-01 kernel: ffff880207913898 ffff88021fa52bc0 ffff880216aca0d0 ffff880207913980
Sep 23 05:01:39 bp-01 kernel: Call Trace:
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81580ac0>] ? yield_to+0x180/0x180
Sep 23 05:01:39 bp-01 kernel: [<ffffffff815807d9>] schedule+0x29/0x70
Sep 23 05:01:39 bp-01 kernel: [<ffffffff815808ac>] io_schedule+0x8c/0xd0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81580aec>] bit_wait_io+0x2c/0x50
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81580bd6>] __wait_on_bit_lock+0x76/0xb0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811cd006>] ? block_write_full_page+0xc6/0x100
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81134cd8>] __lock_page+0xa8/0xb0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8108eb30>] ? wake_atomic_t_function+0x40/0x40
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81141258>] write_cache_pages+0x318/0x510
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8113fdb0>] ? set_page_dirty+0x60/0x60
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811414a1>] generic_writepages+0x51/0x80
Sep 23 05:01:39 bp-01 kernel: [<ffffffff81141505>] do_writepages+0x35/0x40
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811bfbe9>] __writeback_single_inode+0x49/0x230
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811c3029>] writeback_sb_inodes+0x249/0x360
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811c3309>] wb_writeback+0xf9/0x2c0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811c3552>] wb_do_writeback+0x82/0x1f0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff811c3730>] bdi_writeback_workfn+0x70/0x210
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8106b62e>] process_one_work+0x14e/0x430
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8106ba2f>] worker_thread+0x11f/0x3c0
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8106b910>] ? process_one_work+0x430/0x430
Sep 23 05:01:39 bp-01 kernel: [<ffffffff8107080e>] kthread+0xce/0xf0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81070740>] ? kthread_freezable_should_stop+0x70/0x70
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815843ac>] ret_from_fork+0x7c/0xb0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81070740>] ? kthread_freezable_should_stop+0x70/0x70
Sep 23 05:01:40 bp-01 kernel: INFO: task kjournald:21626 blocked for more than 120 seconds.
Sep 23 05:01:40 bp-01 kernel: Tainted: G E 3.17.0-rc6 #1
Sep 23 05:01:40 bp-01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 23 05:01:40 bp-01 kernel: kjournald D 0000000000000002 0 21626 2 0x00000080
Sep 23 05:01:40 bp-01 kernel: ffff8802024bbc08 0000000000000046 ffff8802024bbbd8 ffff880217260f00
Sep 23 05:01:40 bp-01 kernel: ffff8802024b8010 0000000000012bc0 0000000000012bc0 ffff880214de9240
Sep 23 05:01:40 bp-01 kernel: ffff8802024bbc08 ffff88021fa52bc0 ffff880214de9240 ffffffff81580ac0
Sep 23 05:01:40 bp-01 kernel: Call Trace:
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580ac0>] ? yield_to+0x180/0x180
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815807d9>] schedule+0x29/0x70
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815808ac>] io_schedule+0x8c/0xd0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580aec>] bit_wait_io+0x2c/0x50
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580dd5>] __wait_on_bit+0x65/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580ac0>] ? yield_to+0x180/0x180
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580e78>] out_of_line_wait_on_bit+0x78/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8108eb30>] ? wake_atomic_t_function+0x40/0x40
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811ca05e>] __wait_on_buffer+0x2e/0x30
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa03f9372>] journal_commit_transaction+0x872/0xf80 [jbd]
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8108844f>] ? put_prev_entity+0x2f/0x400
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8108eaa0>] ? bit_waitqueue+0xb0/0xb0
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa03fcae1>] kjournald+0xf1/0x270 [jbd]
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8108eaa0>] ? bit_waitqueue+0xb0/0xb0
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa03fc9f0>] ? commit_timeout+0x10/0x10 [jbd]
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8107080e>] kthread+0xce/0xf0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81070740>] ? kthread_freezable_should_stop+0x70/0x70
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815843ac>] ret_from_fork+0x7c/0xb0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81070740>] ? kthread_freezable_should_stop+0x70/0x70
Sep 23 05:01:40 bp-01 kernel: INFO: task xdoio:21891 blocked for more than 120 seconds.
Sep 23 05:01:40 bp-01 kernel: Tainted: G E 3.17.0-rc6 #1
Sep 23 05:01:40 bp-01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 23 05:01:40 bp-01 kernel: xdoio D 0000000000000001 0 21891 21890 0x00000080
Sep 23 05:01:40 bp-01 kernel: ffff880405d8f978 0000000000000082 ffff880414ec0c00 ffff880217254150
Sep 23 05:01:40 bp-01 kernel: ffff880405d8c010 0000000000012bc0 0000000000012bc0 ffff8803e7be9080
Sep 23 05:01:40 bp-01 kernel: ffff880405d8f958 ffff88021fa32bc0 ffff8803e7be9080 ffffffff81580ac0
Sep 23 05:01:40 bp-01 kernel: Call Trace:
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580ac0>] ? yield_to+0x180/0x180
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815807d9>] schedule+0x29/0x70
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815808ac>] io_schedule+0x8c/0xd0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580aec>] bit_wait_io+0x2c/0x50
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580dd5>] __wait_on_bit+0x65/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580ac0>] ? yield_to+0x180/0x180
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81580e78>] out_of_line_wait_on_bit+0x78/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8108eb30>] ? wake_atomic_t_function+0x40/0x40
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811ca05e>] __wait_on_buffer+0x2e/0x30
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811cb440>] __sync_dirty_buffer+0xb0/0xd0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811cb473>] sync_dirty_buffer+0x13/0x20
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa03f7e12>] journal_dirty_data+0x1f2/0x260 [jbd]
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa0415200>] ext3_journal_dirty_data+0x20/0x50 [ext3]
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa0415255>] journal_dirty_data_fn+0x25/0x30 [ext3]
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa04148d4>] walk_page_buffers+0x84/0xc0 [ext3]
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa0415230>] ? ext3_journal_dirty_data+0x50/0x50 [ext3]
Sep 23 05:01:40 bp-01 kernel: [<ffffffffa041897f>] ext3_ordered_write_end+0xaf/0x1e0 [ext3]
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81134742>] generic_perform_write+0x112/0x1c0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8113789f>] __generic_file_write_iter+0x18f/0x390
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81137aee>] generic_file_write_iter+0x4e/0xd0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81197187>] do_iter_readv_writev+0x77/0xb0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8122e343>] ? security_file_permission+0x23/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81137aa0>] ? __generic_file_write_iter+0x390/0x390
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81137aa0>] ? __generic_file_write_iter+0x390/0x390
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811988a0>] do_readv_writev+0xd0/0x320
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81137aa0>] ? __generic_file_write_iter+0x390/0x390
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81197240>] ? do_sync_readv_writev+0x80/0x80
Sep 23 05:01:40 bp-01 kernel: [<ffffffff810c722f>] ? do_futex+0xaf/0x1b0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81198b31>] vfs_writev+0x41/0x50
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81198c66>] SyS_writev+0x56/0xf0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff810ec466>] ? __audit_syscall_exit+0x216/0x2c0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81584452>] system_call_fastpath+0x16/0x1b
Sep 23 05:01:40 bp-01 kernel: INFO: task sync:21916 blocked for more than 120 seconds.
Sep 23 05:01:40 bp-01 kernel: Tainted: G E 3.17.0-rc6 #1
Sep 23 05:01:40 bp-01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 23 05:01:40 bp-01 kernel: sync D 0000000000000001 0 21916 21915 0x00000080
Sep 23 05:01:40 bp-01 kernel: ffff88020902bd68 0000000000000086 ffff88020902bd28 ffff880217254150
Sep 23 05:01:40 bp-01 kernel: ffff880209028010 0000000000012bc0 0000000000012bc0 ffff880216c36dc0
Sep 23 05:01:40 bp-01 kernel: ffff88020902bda8 ffff88020902bec8 ffff88020902bed0 7fffffffffffffff
Sep 23 05:01:40 bp-01 kernel: Call Trace:
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815807d9>] schedule+0x29/0x70
Sep 23 05:01:40 bp-01 kernel: [<ffffffff815832ed>] schedule_timeout+0x13d/0x1d0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8106af82>] ? __queue_delayed_work+0xb2/0x1a0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81581756>] wait_for_completion+0xc6/0x100
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8107e3a0>] ? try_to_wake_up+0x220/0x220
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81583c3b>] ? _raw_spin_unlock_bh+0x1b/0x20
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811c74b0>] ? fdatawrite_one_bdev+0x20/0x20
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811c058d>] sync_inodes_sb+0x9d/0xd0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811c74cd>] sync_inodes_one_sb+0x1d/0x30
Sep 23 05:01:40 bp-01 kernel: [<ffffffff8119aab3>] iterate_supers+0xb3/0xe0
Sep 23 05:01:40 bp-01 kernel: [<ffffffff811c7515>] sys_sync+0x35/0x90
Sep 23 05:01:40 bp-01 kernel: [<ffffffff81584452>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH 0/5] Fixes for RAID1 resync
From: NeilBrown @ 2014-09-24 4:49 UTC (permalink / raw)
To: Brassow Jonathan; +Cc: Eivind Sarto, linux-raid, majianpeng
In-Reply-To: <398DA7BB-7BED-49E0-8178-0CA4384E8A84@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On Tue, 23 Sep 2014 23:25:12 -0500 Brassow Jonathan <jbrassow@redhat.com>
wrote:
>
> Sorry, still not there yet.
No?? I was *sure* I had it that time!
>
> I'm sorry I haven't had more time to spend on this. I'll try to get some help (perhaps from Heinz) and see if we can pitch-in instead of making you do all the work.
Could you include /proc/PID/stack for the two md kernel threads? They are
unlikely to differ from what we have seen before but as they are the
strongest pointer to where the problem is, I like to be able to see them :-)
Also I'd like to see the disassembly of raise_barrier() just to be certain
which of the two 'wait's it is waiting in.
One thing that might be useful is to change the various wait_event_lock_irq()
calls to wait_event_lock_irq_cmd() with an extra argument 'dotrace(conf)'
where dotrace() is a new function that first calls
schedule_timeout(60*HZ);
and then if that returns 0, prints out all fields that might be of interest.
Also get it to print which 'wait' it was called from (e.g. pass a string to
dotrace).
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: More 'D' state processes
From: Pavel Hofman @ 2014-09-24 11:14 UTC (permalink / raw)
To: linux RAID
> On Mon, 06 Jan 2014 17:00:35 +0100 hans@xxxxxxxxxxxxxx wrote:
>>
>>
>> Hi Neil,
>>
>> the output of 'uname -r' is: 3.2.0-4-amd64. A standard Debian Wheezy.
>>
>> I rebooted the system in the meantime. The re-sync started anew but
>> finished otherwise without flaws.
>
> I guess there must be some other bug then. I still expect that it is related
> to md_flush_request(). Probably related to the fact that you have an md
> device on top of other md devices....
>
> I had a quick look and cannot find the cause of the problem. Maybe it will
> have to wait until someone else hit it :-(
>
> Thanks for the report,
> NeilBrown
Hi Neil,
IMO I have been hitting the same bug.
I have a layered setup with several MDs on top of each other (backup
server with offline copies).
Sometimes, when mdadm is checking/resyncing, my XFS filesystem gets
stuck. Recovery of a small partition (raid1, md1, ext3) finishes, while
recovery of large (raid1, md6) gets stuck. XFS is on md7 composed of
raid1 - md5 + md6.
Kernel 3.2 was OK, kernels 3.14, 3.16 produce the lockup.
Please let me know what other diagnostics I have to run.
Thanks a lot for your kind help.
Pavel.
dmesg
----------
[1295936.011721] md: recovery of RAID array md6
[1295936.011730] md: minimum _guaranteed_ speed: 100000 KB/sec/disk.
[1295936.011733] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for recovery.
[1295936.011738] md: using 128k window, over a total of 4356343672k.
[1295936.033832] md: export_rdev(sde2)
[1295936.114241] md: bind<sde2>
[1295936.188266] md1: Warning: Device sde2 is misaligned
[1295936.188273] RAID1 conf printout:
[1295936.188275] --- wd:4 rd:6
[1295936.188278] disk 0, wo:0, o:1, dev:sdc1
[1295936.188280] disk 1, wo:0, o:1, dev:sdd1
[1295936.188283] disk 2, wo:0, o:1, dev:sdb2
[1295936.188285] disk 3, wo:0, o:1, dev:sda2
[1295936.188287] disk 4, wo:1, o:1, dev:sde2
[1296065.585142] md: recovery of RAID array md1
[1296065.585145] md: minimum _guaranteed_ speed: 100000 KB/sec/disk.
[1296065.585147] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for recovery.
[1296065.585152] md: using 128k window, over a total of 10739328k.
[1296196.841709] md: md1: recovery done.
[1296197.003548] RAID1 conf printout:
[1296197.003558] --- wd:6 rd:6
[1296197.003565] disk 0, wo:0, o:1, dev:sdc1
[1296197.003570] disk 1, wo:0, o:1, dev:sdd1
[1296197.003574] disk 2, wo:0, o:1, dev:sdb2
[1296197.003578] disk 3, wo:0, o:1, dev:sda2
[1296197.003582] disk 4, wo:0, o:1, dev:sde2
[1296197.003586] disk 5, wo:0, o:1, dev:sdf1
[1296360.756072] INFO: task BackupPC_tarExt:17592 blocked for more than
120 seconds.
[1296360.756146] Tainted: G I 3.16.0-tecmintkernel #2
[1296360.756197] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[1296360.756261] BackupPC_tarExt D 0000000000000000 0 17592 17581
0x00000000
[1296360.756270] ffff8800b9680b00 0000000000000082 0000000000014640
ffff88006cb77fd8
[1296360.756277] 0000000000014640 ffff8800b9680b00 ffff880039476cf0
ffff88006cb77940
[1296360.756284] 7fffffffffffffff ffff8800b9680b00 0000000000000000
ffff8800ba0ec4c0
[1296360.756290] Call Trace:
[1296360.756307] [<ffffffff814de639>] ? schedule_timeout+0x1f9/0x270
[1296360.756316] [<ffffffff814e153b>] ? __down+0x6b/0xa0
[1296360.756362] [<ffffffffa0420b25>] ? _xfs_buf_find+0x135/0x280 [xfs]
[1296360.756371] [<ffffffff810a767c>] ? down+0x3c/0x50
[1296360.756391] [<ffffffffa042095a>] ? xfs_buf_lock+0x2a/0xc0 [xfs]
[1296360.756411] [<ffffffffa0420b25>] ? _xfs_buf_find+0x135/0x280 [xfs]
[1296360.756430] [<ffffffffa0420c8e>] ? xfs_buf_get_map+0x1e/0x1a0 [xfs]
[1296360.756451] [<ffffffffa042168f>] ? xfs_buf_read_map+0x1f/0x130 [xfs]
[1296360.756484] [<ffffffffa047f03b>] ?
xfs_trans_read_buf_map+0x20b/0x480 [xfs]
[1296360.756510] [<ffffffffa046ddb9>] ? xfs_imap_to_bp+0x59/0xe0 [xfs]
[1296360.756537] [<ffffffffa046e27b>] ? xfs_iread+0x6b/0x390 [xfs]
[1296360.756558] [<ffffffffa042907b>] ? xfs_iget+0x24b/0x6b0 [xfs]
[1296360.756586] [<ffffffffa046849e>] ? xfs_lookup+0xce/0xf0 [xfs]
[1296360.756607] [<ffffffffa042e0de>] ? xfs_vn_lookup+0x4e/0xa0 [xfs]
[1296360.756616] [<ffffffff8119f10b>] ? lookup_dcache+0x7b/0xb0
[1296360.756622] [<ffffffff8119e7e4>] ? lookup_real+0x14/0x60
[1296360.756628] [<ffffffff8119f16a>] ? __lookup_hash+0x2a/0x40
[1296360.756635] [<ffffffff811a0b3b>] ? link_path_walk+0x46b/0xeb0
[1296360.756643] [<ffffffff811a15d2>] ? path_lookupat+0x52/0xd60
[1296360.756667] [<ffffffffa0443779>] ?
xfs_bmap_search_extents+0x59/0xe0 [xfs]
[1296360.756675] [<ffffffff811a2300>] ? filename_lookup+0x20/0xc0
[1296360.756682] [<ffffffff811a65af>] ? user_path_at_empty+0x4f/0xa0
[1296360.756688] [<ffffffff8119a168>] ? vfs_fstatat+0x48/0xa0
[1296360.756695] [<ffffffff8119a60a>] ? SYSC_newstat+0x1a/0x40
[1296360.756703] [<ffffffff81195a9c>] ? vfs_read+0x11c/0x170
[1296360.756709] [<ffffffff8119660d>] ? SyS_read+0x3d/0xa0
[1296360.756715] [<ffffffff814e2f29>] ? system_call_fastpath+0x16/0x1b
[1296360.756724] INFO: task BackupPC_link:22685 blocked for more than
120 seconds.
[1296360.756784] Tainted: G I 3.16.0-tecmintkernel #2
[1296360.756834] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[1296360.756896] BackupPC_link D 0000000000000000 0 22685 1718
0x00000000
[1296360.756902] ffff8800b87792f0 0000000000000082 0000000000014640
ffff88000041bfd8
[1296360.756909] 0000000000014640 ffff8800b87792f0 ffff880016d569f0
ffff88000041b9f0
[1296360.756914] 7fffffffffffffff ffff8800b87792f0 0000000000000000
ffff8800bafdd880
[1296360.756921] Call Trace:
[1296360.756929] [<ffffffff814de639>] ? schedule_timeout+0x1f9/0x270
[1296360.756952] [<ffffffffa0089adb>] ? nv_swncq_qc_issue+0x5b/0x90
[sata_nv]
[1296360.756960] [<ffffffff8101b695>] ? sched_clock+0x5/0x10
[1296360.756967] [<ffffffff814e153b>] ? __down+0x6b/0xa0
[1296360.756974] [<ffffffff81094e00>] ?
__clear_sched_clock_stable+0x20/0x20
[1296360.756996] [<ffffffffa0420b25>] ? _xfs_buf_find+0x135/0x280 [xfs]
[1296360.757003] [<ffffffff810a767c>] ? down+0x3c/0x50
[1296360.757021] [<ffffffffa042095a>] ? xfs_buf_lock+0x2a/0xc0 [xfs]
[1296360.757040] [<ffffffffa0420b25>] ? _xfs_buf_find+0x135/0x280 [xfs]
[1296360.757060] [<ffffffffa0420c8e>] ? xfs_buf_get_map+0x1e/0x1a0 [xfs]
[1296360.757079] [<ffffffffa042168f>] ? xfs_buf_read_map+0x1f/0x130 [xfs]
[1296360.757105] [<ffffffffa047f03b>] ?
xfs_trans_read_buf_map+0x20b/0x480 [xfs]
[1296360.757131] [<ffffffffa046ddb9>] ? xfs_imap_to_bp+0x59/0xe0 [xfs]
[1296360.757156] [<ffffffffa046e27b>] ? xfs_iread+0x6b/0x390 [xfs]
[1296360.757177] [<ffffffffa042907b>] ? xfs_iget+0x24b/0x6b0 [xfs]
[1296360.757204] [<ffffffffa046849e>] ? xfs_lookup+0xce/0xf0 [xfs]
[1296360.757225] [<ffffffffa042e0de>] ? xfs_vn_lookup+0x4e/0xa0 [xfs]
[1296360.757232] [<ffffffff8119f10b>] ? lookup_dcache+0x7b/0xb0
[1296360.757239] [<ffffffff8119e7e4>] ? lookup_real+0x14/0x60
[1296360.757245] [<ffffffff8119f16a>] ? __lookup_hash+0x2a/0x40
[1296360.757251] [<ffffffff811a1e83>] ? path_lookupat+0x903/0xd60
[1296360.757276] [<ffffffffa0437598>] ? xfs_trans_free_items+0x78/0xa0
[xfs]
[1296360.757283] [<ffffffff811a2300>] ? filename_lookup+0x20/0xc0
Processes in D state:
----------------------
29 ? D 72:29 [kswapd0]
1815 ? D 36:22 [xfsaild/md7]
17592 ? D 33:37 /usr/bin/perl
/usr/share/backuppc/bin/BackupPC_tarExtract orion-1000 / 3
21086 ? D 3:58 /usr/bin/rsync --server --sender
--numeric-ids --perms --owner --group -D --links --hard-links --times
--block-size=2048 --recursive -D --one-file-system .
/mnt/raid/local-copies/nemeton/
22341 ? D 0:00 [md6_resync]
22685 ? D 0:00 /usr/bin/perl
/usr/share/backuppc/bin/BackupPC_link hestia
orfeus:~# cat /proc/mdstat
---------------------------
Personalities : [raid1] [raid0]
md9 : active raid0 sde4[0] sdf3[1]
4356343808 blocks super 1.0 512k chunks
md7 : active raid1 md5[2] md6[1]
4356343536 blocks super 1.0 [2/2] [UU]
md6 : active raid1 md9[2] md4[0]
4356343672 blocks super 1.0 [2/1] [U_]
[>....................] recovery = 0.0% (6208/4356343672)
finish=200447042.5min speed=0K/sec
bitmap: 9/9 pages [36KB], 262144KB chunk
md5 : active raid1 md3[0]
4356343616 blocks super 1.0 [2/1] [U_]
bitmap: 33/33 pages [132KB], 65536KB chunk
md4 : active raid0 sdb4[0] sdd3[1]
4356343808 blocks super 1.0 512k chunks
md3 : active raid0 sda4[0] sdc3[1]
4356343808 blocks super 1.0 512k chunks
md2 : active raid1 sdc2[0] sda3[3] sdb3[2] sdd2[1]
8787456 blocks [4/4] [UUUU]
md1 : active raid1 sdf1[5] sde2[4] sdc1[0] sda2[3] sdb2[2] sdd1[1]
10739328 blocks [6/6] [UUUUUU]
>
>
>>
>> Regards, Hans
>>
>> Am 05.01.2014 23:00, schrieb NeilBrown:
>>
>> > On Sun, 22 Dec 2013 17:43:43 +0100 Hans Kraus <hans@xxxxxxxxxxxxxx> wrote:
>> >
>> >> Hi Neil,
>> >
>> > Hi Hans,
>> > sorry for the delay - Christmas/New Year vacation...
>> > [40800.777037] xfsaild/dm-0 D ffff88003754c300 0 20798 2 0x00000000 [40800.777042] ffff88003754c300 0000000000000046 0000000000000000 ffff88005d7c51a0 [40800.777047] 0000000000013780 ffff88001b01ffd8 ffff88001b01ffd8 ffff88003754c300 [40800.777052] ffff880071fede00 ffffffff81070fc1 0000000000000046 ffff88003734a400 [40800.777057] Call Trace: [40800.777061] [<ffffffff81070fc1>] ? arch_local_irq_save+0x11/0x17 [40800.777071] [<ffffffffa0170466>] ? md_flush_request+0x96/0x111 [md_mod] [40800.777076] [<ffffffff8103f6c4>] ? try_to_wake_up+0x197/0x197 [40800.777082] [<ffffffffa0f11711>] ? make_request+0x25/0x37a [raid456] [40800.777091] [<ffffffffa0185873>] ?
>>
>> This looks like the most likely root of the problem - something wrong in
>> md_flush_request.
>>
>> There was a bug here fixed in 2.6.37
>>
>> commit a035fc3e2531703b539f23bec4ca7943cfc69349
>> Author: NeilBrown <neilb@xxxxxxx>
>> Date: Thu Dec 9 16:17:51 2010 +1100
>>
>> md: fix possible deadlock in handling flush requests.
>>
>> You didn't say which kernel you were running. Could it be earlier than
>> 2.6.37???
>>
>> NeilBrown
>>
>>
^ permalink raw reply
* Re: Moving root to raid, weird raid behaviour
From: Wols Lists @ 2014-09-24 20:13 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <542134C3.4090003@youngman.org.uk>
I've just had a flash of inspiration, and if I'm right it's a pretty
nasty "feature", but surely it would have bitten people before me...
What's the purpose of the array name? And what's going on with multiple
arrays all sharing the same name? This system I'm working on, all three
arrays are called "ashdown:0".
And I've just thoroughly screwed up my dev system - I've lost /home ...
all because I did a --wipe-superblock on a DIFFERENT partition on a
DIFFERENT array!
(Oh, and I've got the boot sequence moaning that sdd and sdd4 have very
similar superblocks - wtf? sdd DOESN'T HAVE a superblock as far as I know!)
But that thing about array names, what I've been doing is creating array
0 (or 1), and when I reboot, it gets changed to 127 or whatever, so the
next array I create is 0 (or 1), etc etc. There seems to be precious
little mention of names, what they do etc, they're treated as an
afterthought. I didn't even realise arrays *had* names, until I noticed
a reference to "mdhome" or something like that. Does that mean I can do
"mdadm --create /dev/mdhome ..." ?
Any light to shed?
(At least I now grok grub2 enough to achieve what I want to, it's just
that it's now making the raid mess worse as grub2 doesn't like it when
arrays disappear under it!)
Cheers,
Wol
On 23/09/14 09:52, Wols Lists wrote:
> On 23/09/14 01:37, NeilBrown wrote:
>> On Mon, 22 Sep 2014 19:29:46 +0100 Wols Lists
>> <antlists@youngman.org.uk> wrote:
>>
>>> I'm not sure if this is weird raid, stupid grub2 or incompetent
>>> newbie, but whatever ... and the system is my development/test
>>> system so if it gets trashed it's no disaster, but I would like
>>> to understand what is going on ...
>>>
>>> Old setup / = sdb2 /var = sdc2 /home = mdX (sdb3, sdc3), mirror
>>>
>>> I added sdd and made a new / = mdY (sdd3, missing) mirror and
>>> added sdd4 to mdX /home = mdX (sdb3 sdc3 sdd4)
>>>
>>> Weirdo one - sdd4 mirrored and synced fine. Then I rebooted ...
>>> mdX = (sdb3 sdc3 missing) mdZ = (sdd4 missing missing)
>>
>> You probably have something silly in your initrd which is making
>> invalid assumptions. What does /etc/mdadm.conf in your
>> initrd/initramfs contain?
>
> There shouldn't be anything there. I bombed into a grub2 shell, and
> mdadm.conf appeared to be the empty default. I also used ark to peer
> into the initramfs file and there didn't appear to be an mdadm.conf.
>
> But I've just had a bit of an uh-oh moment. Bear in mind I have two
> /boot's (mdY/boot and sdb2/boot), and two grubs or more (sda, sdb,
> sdd), I could be barking up a wrong tree. So that's my next step, try
> and *make* *sure* which grub I'm working with! Too many variables...
>>
>>>
>>> wtf?!?!? - oh and both of them share the same uuid. The obvious
>>> (but it shouldn't make any difference?) possibility is that sdb
>>> and sdc are 500Gb, partitioned identically. sdd is 1Tb, so sdd4
>>> is twice the size of the other two.
>>>
>>> The other weirdo is I'm trying to migrate from grub/mbr to
>>> grub2/gpt. Of course that's causing me fun, but I've managed to
>>> get the system booting fine from mdY. Only snag is, when I list
>>> /dev, mdY isn't there! mount shows it as mounted on / but that's
>>> the only place I can find it!
>>
>> udev should create it. 'udevadm trigger' should cause udev to
>> create device files for all devices. That should be done as part
>> of the boot sequence. If you run "udevadm trigger" does /dev/mdX
>> get created?
>>
> No errors, no messages, no disk ...
>>
>>>
>>> mdadm v3.2.6 kernel 3.14.14-gentoo
>>>
>>> Any ideas what's going on? I've googled, but everything I find
>>> looks out of date or not relevant.
>>
>> "out of date or not relevant"?? You must have been looking on the
>> Internet ?!?! :-)
>
> :-)
>
> The search results were mostly ubuntu (I run gentoo, but so what),
> grub1, I'm migrating to grub2, and any mention of root/boot got plenty
> of results about not finding root and failing to boot, but absolutely
> nothing about successfully booting off a root that wasn't there! Plus
> they all seemed to be 2010 or earlier ...
>>
>> NeilBrown
>>
> Cheers,
> Wol
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Moving root to raid, weird raid behaviour
From: NeilBrown @ 2014-09-25 0:05 UTC (permalink / raw)
To: Wols Lists; +Cc: linux-raid
In-Reply-To: <542325F0.9010306@youngman.org.uk>
[-- Attachment #1: Type: text/plain, Size: 5974 bytes --]
On Wed, 24 Sep 2014 21:13:36 +0100 Wols Lists <antlists@youngman.org.uk>
wrote:
> I've just had a flash of inspiration, and if I'm right it's a pretty
> nasty "feature", but surely it would have bitten people before me...
>
> What's the purpose of the array name? And what's going on with multiple
> arrays all sharing the same name? This system I'm working on, all three
> arrays are called "ashdown:0".
The name is just a name. It can be used to identify arrays and it can be
used to create a symlink in /dev/md, but it is not assumed to be unique.
>
> And I've just thoroughly screwed up my dev system - I've lost /home ...
> all because I did a --wipe-superblock on a DIFFERENT partition on a
> DIFFERENT array!
Oops :-(
>
> (Oh, and I've got the boot sequence moaning that sdd and sdd4 have very
> similar superblocks - wtf? sdd DOESN'T HAVE a superblock as far as I know!)
"mdadm -E /dev/sdd" would tell you.
If you have a 0.90 superblock on sdd4, and sdd4 starts at a multiple for 64K
from the start of the device, then that superblock will appear to exist on
sdd as well. This is one of the several reasons that we use 1.x metadata.
>
> But that thing about array names, what I've been doing is creating array
> 0 (or 1), and when I reboot, it gets changed to 127 or whatever, so the
> next array I create is 0 (or 1), etc etc. There seems to be precious
> little mention of names, what they do etc, they're treated as an
> afterthought. I didn't even realise arrays *had* names, until I noticed
> a reference to "mdhome" or something like that. Does that mean I can do
> "mdadm --create /dev/mdhome ..." ?
Sure can. or "/dev/md/home" or just "home".
If the array gets assembled at '127' despite being created as '1', then there
is something different in the boot environment. Presumably the array is
assembled before the host name is set, and the mdadm.conf in the initrd (I
think you said there wasn't one..) doesn't list the array with the correct
name.
Without one of those hints (the hostname is stored in the metadata so mdadm
knows if the array is "local" or "foreign" so it knows how much to trust the
name), mdadm will punt and use a number like 127.
NeilBrown
>
> Any light to shed?
>
> (At least I now grok grub2 enough to achieve what I want to, it's just
> that it's now making the raid mess worse as grub2 doesn't like it when
> arrays disappear under it!)
>
> Cheers,
> Wol
>
> On 23/09/14 09:52, Wols Lists wrote:
> > On 23/09/14 01:37, NeilBrown wrote:
> >> On Mon, 22 Sep 2014 19:29:46 +0100 Wols Lists
> >> <antlists@youngman.org.uk> wrote:
> >>
> >>> I'm not sure if this is weird raid, stupid grub2 or incompetent
> >>> newbie, but whatever ... and the system is my development/test
> >>> system so if it gets trashed it's no disaster, but I would like
> >>> to understand what is going on ...
> >>>
> >>> Old setup / = sdb2 /var = sdc2 /home = mdX (sdb3, sdc3), mirror
> >>>
> >>> I added sdd and made a new / = mdY (sdd3, missing) mirror and
> >>> added sdd4 to mdX /home = mdX (sdb3 sdc3 sdd4)
> >>>
> >>> Weirdo one - sdd4 mirrored and synced fine. Then I rebooted ...
> >>> mdX = (sdb3 sdc3 missing) mdZ = (sdd4 missing missing)
> >>
> >> You probably have something silly in your initrd which is making
> >> invalid assumptions. What does /etc/mdadm.conf in your
> >> initrd/initramfs contain?
> >
> > There shouldn't be anything there. I bombed into a grub2 shell, and
> > mdadm.conf appeared to be the empty default. I also used ark to peer
> > into the initramfs file and there didn't appear to be an mdadm.conf.
> >
> > But I've just had a bit of an uh-oh moment. Bear in mind I have two
> > /boot's (mdY/boot and sdb2/boot), and two grubs or more (sda, sdb,
> > sdd), I could be barking up a wrong tree. So that's my next step, try
> > and *make* *sure* which grub I'm working with! Too many variables...
> >>
> >>>
> >>> wtf?!?!? - oh and both of them share the same uuid. The obvious
> >>> (but it shouldn't make any difference?) possibility is that sdb
> >>> and sdc are 500Gb, partitioned identically. sdd is 1Tb, so sdd4
> >>> is twice the size of the other two.
> >>>
> >>> The other weirdo is I'm trying to migrate from grub/mbr to
> >>> grub2/gpt. Of course that's causing me fun, but I've managed to
> >>> get the system booting fine from mdY. Only snag is, when I list
> >>> /dev, mdY isn't there! mount shows it as mounted on / but that's
> >>> the only place I can find it!
> >>
> >> udev should create it. 'udevadm trigger' should cause udev to
> >> create device files for all devices. That should be done as part
> >> of the boot sequence. If you run "udevadm trigger" does /dev/mdX
> >> get created?
> >>
> > No errors, no messages, no disk ...
> >>
> >>>
> >>> mdadm v3.2.6 kernel 3.14.14-gentoo
> >>>
> >>> Any ideas what's going on? I've googled, but everything I find
> >>> looks out of date or not relevant.
> >>
> >> "out of date or not relevant"?? You must have been looking on the
> >> Internet ?!?! :-)
> >
> > :-)
> >
> > The search results were mostly ubuntu (I run gentoo, but so what),
> > grub1, I'm migrating to grub2, and any mention of root/boot got plenty
> > of results about not finding root and failing to boot, but absolutely
> > nothing about successfully booting off a root that wasn't there! Plus
> > they all seemed to be 2010 or earlier ...
> >>
> >> NeilBrown
> >>
> > Cheers,
> > Wol
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* 用了一次你就会觉得是最好的短信发送平台 jhdrz7pkm
From: 小范 @ 2014-09-25 5:08 UTC (permalink / raw)
To: linux-raid, linux2007, linux2011, linux212
这个短信发送平台实在是太好用了，再也不愁找不到好的平台了，只要是你发的内容是正规的，轻松就可以发送出去。加QQ193989725具体咨询，可以开账号测效果。
白了，董九星就是卢军超的一条狗。 现在，狗都敢咬人了！董九星的弟弟董四喜竟然嚣张到到地把烟头扔到自己宝贝女儿的脸上。 他的心中是何其的愤怒，如果卢军超、董四白色大洋马胸前那块白嫩的皮肉所吸引，心中暗暗感叹，都说白人毛孔粗大，体毛旺盛，但是这个女人显然不是，皮肤白皙而且细腻，如同奶油一般，她是不是混血呢——看上去她真有点像风的话，那么自己就位于这场台风的台风眼里。 毫无疑问的是，自己这个小小的市场稽查股长已经进入了到钱局长的核心团队，成为了真正的嫡系。 不过，他还是不放心夏小洛去做了，不喝就不是人了，只能一个字，“喝”。 何京生看“程度”差不多了，起身告辞，道：“晚上还有个会！你们慢慢喝！” 转身进入另外一个包厢，这边，汪东平整挺着肚子带着上念了考点分布，然后由何诗韵和王建男发准考证。 洛水县县城一共有五所初中，乡下初中有17所，为了考试公平，避免徇私舞弊现象，所有考生都要集中在洛水县城的中小学考试，那写，郭司长挂名的书，可不能有错误。” 两人讪讪的出了乐巢酒吧，已是深夜，屈小元看了下手机短信，抱歉地对夏小洛，道：“哥们，有一姑娘召唤，我要去安抚她寂寞的小心灵了。
元梗着脖子问。 这小子从来不吃亏，不做无用功。 “即使没有原题，可是这套‘秘籍’里面的知识点很全面，对我们成绩的提高还是很有用的。”何诗韵道。 她一说，典诗词，对诗词的鉴赏能力非常高超，这几句诗如同大锤一样击打在他的胸口上，只觉得心脏不停地跳动。 这种感觉只有他在辽宁博物馆看到被誉为“草圣”的唐代大书法家张旭的《古就如释重负地站起来，去散发传单了，原来，这里真正懂医学的就他一个。 一有行人走过，戴着绶带的女孩子就走上去，递过去一张传单，然后说：“我们有专家义诊，您如果有什么不屈小元愤怒地声音：“我草！谁啊！找死啊，老子正做梦吃娃娃雪糕呢！” “哐当”一声门被拉开了，小元手里拎了一根钢筋，怒气冲冲，看样子要给来人一顿狠揍！ 一看来人是夏系列令屈小元瞠目结舌的事件后，他们之间已经不仅仅有友谊，在屈小元心目中，他已经是神一般的存在，那可是谁也不难伤一分一毫的。 因此，除非大事发生，他绝对不可能不来的。 制服了，嘿，这效率还挺高的。夏擎天心道。 夏擎天从没有走正门，推开众人，单手一撑院墙，飞身越过，其他几个小子也跳进了院子。 夏擎天从夏毛蛋口袋里摸出仅有的一颗烟，
^ permalink raw reply
* [PATCH] md: avoid potential long delay under pers_lock
From: Chao Yu @ 2014-09-25 7:28 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, linux-kernel
printk may cause long time lapse if value of printk_delay in sysctl is
configured large by user. If register_md_personality takes long time to print in
spinlock pers_lock, we may encounter high CPU usage rate when there are other
pers_lock competitors who may be blocked to spin.
We can avoid this condition by moving printk out of coverage of pers_lock
spinlock.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
---
drivers/md/md.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index e02de05..5fcf215 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7200,9 +7200,10 @@ static const struct file_operations md_seq_fops = {
int register_md_personality(struct md_personality *p)
{
+ printk(KERN_INFO "md: %s personality registered for level %d\n",
+ p->name, p->level);
spin_lock(&pers_lock);
list_add_tail(&p->list, &pers_list);
- printk(KERN_INFO "md: %s personality registered for level %d\n", p->name, p->level);
spin_unlock(&pers_lock);
return 0;
}
--
2.0.1.474.g72c7794
^ permalink raw reply related
* Re: /sys/block/md126 still exists even after stopping the array
From: Francis Moreau @ 2014-09-25 16:12 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid, sebastian.riemer
In-Reply-To: <20140625110348.48ab2d7a@notabene.brown>
Hello,
On 06/25/2014 03:03 AM, NeilBrown wrote:
> On Tue, 24 Jun 2014 17:38:30 +0200 Francis Moreau <francis.moro@gmail.com>
> wrote:
>
>> Hello,
>>
>> I'm having the folloing behaviour with kernel 3.14.5 and mdadm v3.3.1.
>>
>> After stopping all arrays, I still can see one of them in /sys/block/:
>>
>> # cat /proc/mdstat
>> Personalities : [raid1]
>> md125 : active raid1 sdb3[1] sda3[0]
>> 483688448 blocks super 1.2 [2/2] [UU]
>> [======>..............] resync = 34.9% (169161280/483688448)
>> finish=44.0min speed=118852K/sec
>> bitmap: 3/4 pages [12KB], 65536KB chunk
>>
>> md126 : active raid1 sdb2[1] sda2[0]
>> 4038656 blocks super 1.2 [2/2] [UU]
>>
>> md127 : active raid1 sdb1[1] sda1[0]
>> 524224 blocks super 1.0 [2/2] [UU]
>>
>> unused devices: <none>
>>
>> # mdadm --stop /dev/md12[567]
>> mdadm: stopped /dev/md125
>> mdadm: stopped /dev/md126
>> mdadm: stopped /dev/md127
>>
>> # cat /proc/mdstat
>> Personalities : [raid1]
>> unused devices: <none>
>>
>> # ls /sys/block/
>> md126 sda sdb sdc sr0
>>
>> # ls /sys/block/md126/md/
>> array_size array_state bitmap chunk_size component_size layout
>> level max_read_errors metadata_version new_dev raid_disks
>> reshape_direction reshape_position resync_start safe_mode_delay
>>
>> # dmesg
>> ....
>> [ 1573.715476] md125: detected capacity change from 495296970752 to 0
>> [ 1573.715626] md: md125 stopped.
>> [ 1573.715633] md: unbind<sdb3>
>> [ 1573.740681] md: export_rdev(sdb3)
>> [ 1573.740694] md: unbind<sda3>
>> [ 1573.754008] md: export_rdev(sda3)
>> [ 1573.773398] md126: detected capacity change from 4135583744 to 0
>> [ 1573.773403] md: md126 stopped.
>> [ 1573.773410] md: unbind<sdb2>
>> [ 1573.820652] md: export_rdev(sdb2)
>> [ 1573.820664] md: unbind<sda2>
>> [ 1573.873974] md: export_rdev(sda2)
>> [ 1573.889904] md127: detected capacity change from 536805376 to 0
>> [ 1573.889910] md: md127 stopped.
>> [ 1573.889917] md: unbind<sdb1>
>> [ 1573.913978] md: export_rdev(sdb1)
>> [ 1573.914033] md: unbind<sda1>
>> [ 1573.940627] md: export_rdev(sda1)
>>
>> After waiting a couple of min, stopping again md126 worked:
>>
>> [ 1835.755661] md: md126 stopped.
>>
>> Is this expected ?
>
> No overly surprising.
>
> This is probably caused by udev, or something udev runs, opening /dev/md126
> after it has been stopped. This has the effect of creating an empty inactive
> array.
> e.g.
>
Sorry for resurecting this again, but I'm still seeing this.
Sebastian saw the same behaviour with udev 215 and it appeared that this
specific version introduced a regression which resulted in the same
behavior I described initialy.
But in my case, the version of udev used is older (204).
I tried to find out what could have opened the md device by using fuser,
but fuser reports no users.
I took a look to the udev rules which are the one shipped by mdadm 3.3.2
but nothing keep the device opened during the remove event.
Could you give me some hints here to debug this ?
Thanks
^ permalink raw reply
* Re: [PATCH] md: avoid potential long delay under pers_lock
From: Henrique de Moraes Holschuh @ 2014-09-25 16:51 UTC (permalink / raw)
To: Chao Yu; +Cc: neilb, linux-raid, linux-kernel
In-Reply-To: <002801cfd892$696e39d0$3c4aad70$@samsung.com>
On Thu, 25 Sep 2014, Chao Yu wrote:
> printk may cause long time lapse if value of printk_delay in sysctl is
> configured large by user. If register_md_personality takes long time to print in
> spinlock pers_lock, we may encounter high CPU usage rate when there are other
> pers_lock competitors who may be blocked to spin.
> We can avoid this condition by moving printk out of coverage of pers_lock
> spinlock.
>
> Signed-off-by: Chao Yu <chao2.yu@samsung.com>
> ---
> drivers/md/md.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index e02de05..5fcf215 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -7200,9 +7200,10 @@ static const struct file_operations md_seq_fops = {
>
> int register_md_personality(struct md_personality *p)
> {
> + printk(KERN_INFO "md: %s personality registered for level %d\n",
> + p->name, p->level);
> spin_lock(&pers_lock);
> list_add_tail(&p->list, &pers_list);
> - printk(KERN_INFO "md: %s personality registered for level %d\n", p->name, p->level);
> spin_unlock(&pers_lock);
> return 0;
> }
Wouldn't it make more sense to move the printk after the spin_unlock ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* [PATCH] dm: sparse: Annotate field with __rcu for checking
From: Pranith Kumar @ 2014-09-25 18:50 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, maintainer:DEVICE-MAPPER LVM,
Neil Brown, linux-raid, open list
Cc: paulmck, josh
Annotate the map field with __rcu since this is a rcu pointer which is checked
by sparse.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
drivers/md/dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 32b958d..746411b 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -140,7 +140,7 @@ struct mapped_device {
* Use dm_get_live_table{_fast} or take suspend_lock for
* dereference.
*/
- struct dm_table *map;
+ struct dm_table __rcu *map;
unsigned long flags;
--
2.1.0
^ permalink raw reply related
* Re: /sys/block/md126 still exists even after stopping the array
From: NeilBrown @ 2014-09-26 0:33 UTC (permalink / raw)
To: Francis Moreau; +Cc: linux-raid, sebastian.riemer
In-Reply-To: <54243ED7.6090904@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3853 bytes --]
On Thu, 25 Sep 2014 18:12:07 +0200 Francis Moreau <francis.moro@gmail.com>
wrote:
> Hello,
>
> On 06/25/2014 03:03 AM, NeilBrown wrote:
> > On Tue, 24 Jun 2014 17:38:30 +0200 Francis Moreau <francis.moro@gmail.com>
> > wrote:
> >
> >> Hello,
> >>
> >> I'm having the folloing behaviour with kernel 3.14.5 and mdadm v3.3.1.
> >>
> >> After stopping all arrays, I still can see one of them in /sys/block/:
> >>
> >> # cat /proc/mdstat
> >> Personalities : [raid1]
> >> md125 : active raid1 sdb3[1] sda3[0]
> >> 483688448 blocks super 1.2 [2/2] [UU]
> >> [======>..............] resync = 34.9% (169161280/483688448)
> >> finish=44.0min speed=118852K/sec
> >> bitmap: 3/4 pages [12KB], 65536KB chunk
> >>
> >> md126 : active raid1 sdb2[1] sda2[0]
> >> 4038656 blocks super 1.2 [2/2] [UU]
> >>
> >> md127 : active raid1 sdb1[1] sda1[0]
> >> 524224 blocks super 1.0 [2/2] [UU]
> >>
> >> unused devices: <none>
> >>
> >> # mdadm --stop /dev/md12[567]
> >> mdadm: stopped /dev/md125
> >> mdadm: stopped /dev/md126
> >> mdadm: stopped /dev/md127
> >>
> >> # cat /proc/mdstat
> >> Personalities : [raid1]
> >> unused devices: <none>
> >>
> >> # ls /sys/block/
> >> md126 sda sdb sdc sr0
> >>
> >> # ls /sys/block/md126/md/
> >> array_size array_state bitmap chunk_size component_size layout
> >> level max_read_errors metadata_version new_dev raid_disks
> >> reshape_direction reshape_position resync_start safe_mode_delay
> >>
> >> # dmesg
> >> ....
> >> [ 1573.715476] md125: detected capacity change from 495296970752 to 0
> >> [ 1573.715626] md: md125 stopped.
> >> [ 1573.715633] md: unbind<sdb3>
> >> [ 1573.740681] md: export_rdev(sdb3)
> >> [ 1573.740694] md: unbind<sda3>
> >> [ 1573.754008] md: export_rdev(sda3)
> >> [ 1573.773398] md126: detected capacity change from 4135583744 to 0
> >> [ 1573.773403] md: md126 stopped.
> >> [ 1573.773410] md: unbind<sdb2>
> >> [ 1573.820652] md: export_rdev(sdb2)
> >> [ 1573.820664] md: unbind<sda2>
> >> [ 1573.873974] md: export_rdev(sda2)
> >> [ 1573.889904] md127: detected capacity change from 536805376 to 0
> >> [ 1573.889910] md: md127 stopped.
> >> [ 1573.889917] md: unbind<sdb1>
> >> [ 1573.913978] md: export_rdev(sdb1)
> >> [ 1573.914033] md: unbind<sda1>
> >> [ 1573.940627] md: export_rdev(sda1)
> >>
> >> After waiting a couple of min, stopping again md126 worked:
> >>
> >> [ 1835.755661] md: md126 stopped.
> >>
> >> Is this expected ?
> >
> > No overly surprising.
> >
> > This is probably caused by udev, or something udev runs, opening /dev/md126
> > after it has been stopped. This has the effect of creating an empty inactive
> > array.
> > e.g.
> >
>
> Sorry for resurecting this again, but I'm still seeing this.
>
> Sebastian saw the same behaviour with udev 215 and it appeared that this
> specific version introduced a regression which resulted in the same
> behavior I described initialy.
>
> But in my case, the version of udev used is older (204).
>
> I tried to find out what could have opened the md device by using fuser,
> but fuser reports no users.
It is probably a transient open/close.
>
> I took a look to the udev rules which are the one shipped by mdadm 3.3.2
> but nothing keep the device opened during the remove event.
>
> Could you give me some hints here to debug this ?
Modify md_open in drivers/md/md.c to add
printk("Opened by %s\n", current->comm);
and build a new kernel. That will tell you the name of the process which
opened the device.
NeilBrown
>
> Thanks
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] md: avoid potential long delay under pers_lock
From: NeilBrown @ 2014-09-26 0:36 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-raid, linux-kernel
In-Reply-To: <002801cfd892$696e39d0$3c4aad70$@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
On Thu, 25 Sep 2014 15:28:34 +0800 Chao Yu <chao2.yu@samsung.com> wrote:
> printk may cause long time lapse if value of printk_delay in sysctl is
> configured large by user. If register_md_personality takes long time to print in
> spinlock pers_lock, we may encounter high CPU usage rate when there are other
> pers_lock competitors who may be blocked to spin.
> We can avoid this condition by moving printk out of coverage of pers_lock
> spinlock.
>
> Signed-off-by: Chao Yu <chao2.yu@samsung.com>
> ---
> drivers/md/md.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index e02de05..5fcf215 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -7200,9 +7200,10 @@ static const struct file_operations md_seq_fops = {
>
> int register_md_personality(struct md_personality *p)
> {
> + printk(KERN_INFO "md: %s personality registered for level %d\n",
> + p->name, p->level);
> spin_lock(&pers_lock);
> list_add_tail(&p->list, &pers_list);
> - printk(KERN_INFO "md: %s personality registered for level %d\n", p->name, p->level);
> spin_unlock(&pers_lock);
> return 0;
> }
I'm not sure I see the pressing need for this - have you noticed actual
problems?
However it seems to make sense so I've applied it.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox