* [PATCH v2 02/12] block: Consolidate static integrity profile properties
From: Dan Williams @ 2015-10-15 19:59 UTC (permalink / raw)
To: martin.petersen
Cc: axboe, linux-raid, linux-nvdimm, linux-nvme, Sagi Grimberg,
dm-devel, Ross Zwisler, hch
In-Reply-To: <20151015195939.20721.23101.stgit@dwillia2-desk3.jf.intel.com>
From: Martin K. Petersen <martin.petersen@oracle.com>
We previously made a complete copy of a device's data integrity profile
even though several of the fields inside the blk_integrity struct are
pointers to fixed template entries in t10-pi.c.
Split the static and per-device portions so that we can reference the
template directly.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
[djbw: make nvdimm profile static]
Tested-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
block/bio-integrity.c | 8 ++++----
block/blk-integrity.c | 17 ++++++++---------
block/t10-pi.c | 16 ++++------------
drivers/nvdimm/core.c | 11 +++++++----
drivers/nvme/host/pci.c | 8 ++++----
drivers/scsi/sd_dif.c | 29 ++++++++++++++++-------------
drivers/target/target_core_iblock.c | 10 +++++-----
include/linux/blkdev.h | 20 +++++++++++---------
include/linux/t10-pi.h | 8 ++++----
9 files changed, 63 insertions(+), 64 deletions(-)
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index 14b8faf8b09d..a10ffe19a8dd 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -177,11 +177,11 @@ bool bio_integrity_enabled(struct bio *bio)
if (bi == NULL)
return false;
- if (bio_data_dir(bio) == READ && bi->verify_fn != NULL &&
+ if (bio_data_dir(bio) == READ && bi->profile->verify_fn != NULL &&
(bi->flags & BLK_INTEGRITY_VERIFY))
return true;
- if (bio_data_dir(bio) == WRITE && bi->generate_fn != NULL &&
+ if (bio_data_dir(bio) == WRITE && bi->profile->generate_fn != NULL &&
(bi->flags & BLK_INTEGRITY_GENERATE))
return true;
@@ -340,7 +340,7 @@ int bio_integrity_prep(struct bio *bio)
/* Auto-generate integrity metadata if this is a write */
if (bio_data_dir(bio) == WRITE)
- bio_integrity_process(bio, bi->generate_fn);
+ bio_integrity_process(bio, bi->profile->generate_fn);
return 0;
}
@@ -361,7 +361,7 @@ static void bio_integrity_verify_fn(struct work_struct *work)
struct bio *bio = bip->bip_bio;
struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
- bio->bi_error = bio_integrity_process(bio, bi->verify_fn);
+ bio->bi_error = bio_integrity_process(bio, bi->profile->verify_fn);
/* Restore original bio completion handler */
bio->bi_end_io = bip->bip_end_io;
diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index 182bfd2383ea..daf590ab3b46 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -176,10 +176,10 @@ int blk_integrity_compare(struct gendisk *gd1, struct gendisk *gd2)
return -1;
}
- if (strcmp(b1->name, b2->name)) {
+ if (b1->profile != b2->profile) {
printk(KERN_ERR "%s: %s/%s type %s != %s\n", __func__,
gd1->disk_name, gd2->disk_name,
- b1->name, b2->name);
+ b1->profile->name, b2->profile->name);
return -1;
}
@@ -275,8 +275,8 @@ static ssize_t integrity_attr_store(struct kobject *kobj,
static ssize_t integrity_format_show(struct blk_integrity *bi, char *page)
{
- if (bi != NULL && bi->name != NULL)
- return sprintf(page, "%s\n", bi->name);
+ if (bi != NULL && bi->profile->name != NULL)
+ return sprintf(page, "%s\n", bi->profile->name);
else
return sprintf(page, "none\n");
}
@@ -401,7 +401,8 @@ bool blk_integrity_is_initialized(struct gendisk *disk)
{
struct blk_integrity *bi = blk_get_integrity(disk);
- return (bi && bi->name && strcmp(bi->name, bi_unsupported_name) != 0);
+ return (bi && bi->profile->name && strcmp(bi->profile->name,
+ bi_unsupported_name) != 0);
}
EXPORT_SYMBOL(blk_integrity_is_initialized);
@@ -446,14 +447,12 @@ int blk_integrity_register(struct gendisk *disk, struct blk_integrity *template)
/* Use the provided profile as template */
if (template != NULL) {
- bi->name = template->name;
- bi->generate_fn = template->generate_fn;
- bi->verify_fn = template->verify_fn;
+ bi->profile = template->profile;
bi->tuple_size = template->tuple_size;
bi->tag_size = template->tag_size;
bi->flags |= template->flags;
} else
- bi->name = bi_unsupported_name;
+ bi->profile->name = bi_unsupported_name;
disk->queue->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES;
diff --git a/block/t10-pi.c b/block/t10-pi.c
index 24d6e9715318..2c97912335a9 100644
--- a/block/t10-pi.c
+++ b/block/t10-pi.c
@@ -160,38 +160,30 @@ static int t10_pi_type3_verify_ip(struct blk_integrity_iter *iter)
return t10_pi_verify(iter, t10_pi_ip_fn, 3);
}
-struct blk_integrity t10_pi_type1_crc = {
+struct blk_integrity_profile t10_pi_type1_crc = {
.name = "T10-DIF-TYPE1-CRC",
.generate_fn = t10_pi_type1_generate_crc,
.verify_fn = t10_pi_type1_verify_crc,
- .tuple_size = sizeof(struct t10_pi_tuple),
- .tag_size = 0,
};
EXPORT_SYMBOL(t10_pi_type1_crc);
-struct blk_integrity t10_pi_type1_ip = {
+struct blk_integrity_profile t10_pi_type1_ip = {
.name = "T10-DIF-TYPE1-IP",
.generate_fn = t10_pi_type1_generate_ip,
.verify_fn = t10_pi_type1_verify_ip,
- .tuple_size = sizeof(struct t10_pi_tuple),
- .tag_size = 0,
};
EXPORT_SYMBOL(t10_pi_type1_ip);
-struct blk_integrity t10_pi_type3_crc = {
+struct blk_integrity_profile t10_pi_type3_crc = {
.name = "T10-DIF-TYPE3-CRC",
.generate_fn = t10_pi_type3_generate_crc,
.verify_fn = t10_pi_type3_verify_crc,
- .tuple_size = sizeof(struct t10_pi_tuple),
- .tag_size = 0,
};
EXPORT_SYMBOL(t10_pi_type3_crc);
-struct blk_integrity t10_pi_type3_ip = {
+struct blk_integrity_profile t10_pi_type3_ip = {
.name = "T10-DIF-TYPE3-IP",
.generate_fn = t10_pi_type3_generate_ip,
.verify_fn = t10_pi_type3_verify_ip,
- .tuple_size = sizeof(struct t10_pi_tuple),
- .tag_size = 0,
};
EXPORT_SYMBOL(t10_pi_type3_ip);
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index cb62ec6a12d0..7df89b547ae1 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -399,19 +399,22 @@ static int nd_pi_nop_generate_verify(struct blk_integrity_iter *iter)
int nd_integrity_init(struct gendisk *disk, unsigned long meta_size)
{
- struct blk_integrity integrity = {
+ struct blk_integrity bi;
+ static struct blk_integrity_profile profile = {
.name = "ND-PI-NOP",
.generate_fn = nd_pi_nop_generate_verify,
.verify_fn = nd_pi_nop_generate_verify,
- .tuple_size = meta_size,
- .tag_size = meta_size,
};
int ret;
if (meta_size == 0)
return 0;
- ret = blk_integrity_register(disk, &integrity);
+ bi.profile = &profile;
+ bi.tuple_size = meta_size;
+ bi.tag_size = meta_size;
+
+ ret = blk_integrity_register(disk, &bi);
if (ret)
return ret;
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index ad58ee3c3b57..5dba51d4bae6 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -558,7 +558,7 @@ static int nvme_noop_generate(struct blk_integrity_iter *iter)
return 0;
}
-struct blk_integrity nvme_meta_noop = {
+struct blk_integrity_profile nvme_meta_noop = {
.name = "NVME_META_NOOP",
.generate_fn = nvme_noop_generate,
.verify_fn = nvme_noop_verify,
@@ -570,14 +570,14 @@ static void nvme_init_integrity(struct nvme_ns *ns)
switch (ns->pi_type) {
case NVME_NS_DPS_PI_TYPE3:
- integrity = t10_pi_type3_crc;
+ integrity.profile = &t10_pi_type3_crc;
break;
case NVME_NS_DPS_PI_TYPE1:
case NVME_NS_DPS_PI_TYPE2:
- integrity = t10_pi_type1_crc;
+ integrity.profile = &t10_pi_type1_crc;
break;
default:
- integrity = nvme_meta_noop;
+ integrity.profile = &nvme_meta_noop;
break;
}
integrity.tuple_size = ns->ms;
diff --git a/drivers/scsi/sd_dif.c b/drivers/scsi/sd_dif.c
index 5c06d292b94c..5a5ec9aa26b3 100644
--- a/drivers/scsi/sd_dif.c
+++ b/drivers/scsi/sd_dif.c
@@ -43,6 +43,7 @@ void sd_dif_config_host(struct scsi_disk *sdkp)
struct scsi_device *sdp = sdkp->device;
struct gendisk *disk = sdkp->disk;
u8 type = sdkp->protection_type;
+ struct blk_integrity bi;
int dif, dix;
dif = scsi_host_dif_capable(sdp->host, type);
@@ -58,36 +59,38 @@ void sd_dif_config_host(struct scsi_disk *sdkp)
/* Enable DMA of protection information */
if (scsi_host_get_guard(sdkp->device->host) & SHOST_DIX_GUARD_IP) {
if (type == SD_DIF_TYPE3_PROTECTION)
- blk_integrity_register(disk, &t10_pi_type3_ip);
+ bi.profile = &t10_pi_type3_ip;
else
- blk_integrity_register(disk, &t10_pi_type1_ip);
+ bi.profile = &t10_pi_type1_ip;
- disk->integrity->flags |= BLK_INTEGRITY_IP_CHECKSUM;
+ bi.flags |= BLK_INTEGRITY_IP_CHECKSUM;
} else
if (type == SD_DIF_TYPE3_PROTECTION)
- blk_integrity_register(disk, &t10_pi_type3_crc);
+ bi.profile = &t10_pi_type3_crc;
else
- blk_integrity_register(disk, &t10_pi_type1_crc);
+ bi.profile = &t10_pi_type1_crc;
+ bi.tuple_size = sizeof(struct t10_pi_tuple);
sd_printk(KERN_NOTICE, sdkp,
- "Enabling DIX %s protection\n", disk->integrity->name);
+ "Enabling DIX %s protection\n", bi.profile->name);
- /* Signal to block layer that we support sector tagging */
if (dif && type) {
-
- disk->integrity->flags |= BLK_INTEGRITY_DEVICE_CAPABLE;
+ bi.flags |= BLK_INTEGRITY_DEVICE_CAPABLE;
if (!sdkp->ATO)
- return;
+ goto out;
if (type == SD_DIF_TYPE3_PROTECTION)
- disk->integrity->tag_size = sizeof(u16) + sizeof(u32);
+ bi.tag_size = sizeof(u16) + sizeof(u32);
else
- disk->integrity->tag_size = sizeof(u16);
+ bi.tag_size = sizeof(u16);
sd_printk(KERN_NOTICE, sdkp, "DIF application tag size %u\n",
- disk->integrity->tag_size);
+ bi.tag_size);
}
+
+out:
+ blk_integrity_register(disk, &bi);
}
/*
diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index 0f19e11acac2..f29c69120054 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -155,17 +155,17 @@ static int iblock_configure_device(struct se_device *dev)
if (bi) {
struct bio_set *bs = ib_dev->ibd_bio_set;
- if (!strcmp(bi->name, "T10-DIF-TYPE3-IP") ||
- !strcmp(bi->name, "T10-DIF-TYPE1-IP")) {
+ if (!strcmp(bi->profile->name, "T10-DIF-TYPE3-IP") ||
+ !strcmp(bi->profile->name, "T10-DIF-TYPE1-IP")) {
pr_err("IBLOCK export of blk_integrity: %s not"
- " supported\n", bi->name);
+ " supported\n", bi->profile->name);
ret = -ENOSYS;
goto out_blkdev_put;
}
- if (!strcmp(bi->name, "T10-DIF-TYPE3-CRC")) {
+ if (!strcmp(bi->profile->name, "T10-DIF-TYPE3-CRC")) {
dev->dev_attrib.pi_prot_type = TARGET_DIF_TYPE3_PROT;
- } else if (!strcmp(bi->name, "T10-DIF-TYPE1-CRC")) {
+ } else if (!strcmp(bi->profile->name, "T10-DIF-TYPE1-CRC")) {
dev->dev_attrib.pi_prot_type = TARGET_DIF_TYPE1_PROT;
}
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 830f9c07d4bb..f36c6476f1c7 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1462,16 +1462,18 @@ struct blk_integrity_iter {
typedef int (integrity_processing_fn) (struct blk_integrity_iter *);
-struct blk_integrity {
- integrity_processing_fn *generate_fn;
- integrity_processing_fn *verify_fn;
-
- unsigned short flags;
- unsigned short tuple_size;
- unsigned short interval;
- unsigned short tag_size;
+struct blk_integrity_profile {
+ integrity_processing_fn *generate_fn;
+ integrity_processing_fn *verify_fn;
+ const char *name;
+};
- const char *name;
+struct blk_integrity {
+ struct blk_integrity_profile *profile;
+ unsigned short flags;
+ unsigned short tuple_size;
+ unsigned short interval;
+ unsigned short tag_size;
};
extern bool blk_integrity_is_initialized(struct gendisk *);
diff --git a/include/linux/t10-pi.h b/include/linux/t10-pi.h
index 6a8b9942632d..dd8de82cf5b5 100644
--- a/include/linux/t10-pi.h
+++ b/include/linux/t10-pi.h
@@ -14,9 +14,9 @@ struct t10_pi_tuple {
};
-extern struct blk_integrity t10_pi_type1_crc;
-extern struct blk_integrity t10_pi_type1_ip;
-extern struct blk_integrity t10_pi_type3_crc;
-extern struct blk_integrity t10_pi_type3_ip;
+extern struct blk_integrity_profile t10_pi_type1_crc;
+extern struct blk_integrity_profile t10_pi_type1_ip;
+extern struct blk_integrity_profile t10_pi_type3_crc;
+extern struct blk_integrity_profile t10_pi_type3_ip;
#endif
^ permalink raw reply related
* [PATCH v2 01/12] block: Move integrity kobject to struct gendisk
From: Dan Williams @ 2015-10-15 19:59 UTC (permalink / raw)
To: martin.petersen
Cc: axboe, linux-raid, linux-nvdimm, linux-nvme, Sagi Grimberg,
dm-devel, Ross Zwisler, hch
In-Reply-To: <20151015195939.20721.23101.stgit@dwillia2-desk3.jf.intel.com>
From: Martin K. Petersen <martin.petersen@oracle.com>
The integrity kobject purely exists to support the integrity
subdirectory in sysfs and doesn't really have anything to do with the
blk_integrity data structure. Move the kobject to struct gendisk where
it belongs.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Tested-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
block/blk-integrity.c | 22 +++++++++++-----------
include/linux/blkdev.h | 2 --
include/linux/genhd.h | 1 +
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index 75f29cf70188..182bfd2383ea 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -249,8 +249,8 @@ struct integrity_sysfs_entry {
static ssize_t integrity_attr_show(struct kobject *kobj, struct attribute *attr,
char *page)
{
- struct blk_integrity *bi =
- container_of(kobj, struct blk_integrity, kobj);
+ struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
+ struct blk_integrity *bi = blk_get_integrity(disk);
struct integrity_sysfs_entry *entry =
container_of(attr, struct integrity_sysfs_entry, attr);
@@ -261,8 +261,8 @@ static ssize_t integrity_attr_store(struct kobject *kobj,
struct attribute *attr, const char *page,
size_t count)
{
- struct blk_integrity *bi =
- container_of(kobj, struct blk_integrity, kobj);
+ struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
+ struct blk_integrity *bi = blk_get_integrity(disk);
struct integrity_sysfs_entry *entry =
container_of(attr, struct integrity_sysfs_entry, attr);
ssize_t ret = 0;
@@ -385,8 +385,8 @@ subsys_initcall(blk_dev_integrity_init);
static void blk_integrity_release(struct kobject *kobj)
{
- struct blk_integrity *bi =
- container_of(kobj, struct blk_integrity, kobj);
+ struct gendisk *disk = container_of(kobj, struct gendisk, integrity_kobj);
+ struct blk_integrity *bi = blk_get_integrity(disk);
kmem_cache_free(integrity_cachep, bi);
}
@@ -429,14 +429,14 @@ int blk_integrity_register(struct gendisk *disk, struct blk_integrity *template)
if (!bi)
return -1;
- if (kobject_init_and_add(&bi->kobj, &integrity_ktype,
+ if (kobject_init_and_add(&disk->integrity_kobj, &integrity_ktype,
&disk_to_dev(disk)->kobj,
"%s", "integrity")) {
kmem_cache_free(integrity_cachep, bi);
return -1;
}
- kobject_uevent(&bi->kobj, KOBJ_ADD);
+ kobject_uevent(&disk->integrity_kobj, KOBJ_ADD);
bi->flags |= BLK_INTEGRITY_VERIFY | BLK_INTEGRITY_GENERATE;
bi->interval = queue_logical_block_size(disk->queue);
@@ -479,9 +479,9 @@ void blk_integrity_unregister(struct gendisk *disk)
bi = disk->integrity;
- kobject_uevent(&bi->kobj, KOBJ_REMOVE);
- kobject_del(&bi->kobj);
- kobject_put(&bi->kobj);
+ kobject_uevent(&disk->integrity_kobj, KOBJ_REMOVE);
+ kobject_del(&disk->integrity_kobj);
+ kobject_put(&disk->integrity_kobj);
disk->integrity = NULL;
}
EXPORT_SYMBOL(blk_integrity_unregister);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 19c2e947d4d1..830f9c07d4bb 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1472,8 +1472,6 @@ struct blk_integrity {
unsigned short tag_size;
const char *name;
-
- struct kobject kobj;
};
extern bool blk_integrity_is_initialized(struct gendisk *);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 2adbfa6d02bc..9e6e0dfa97ad 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -199,6 +199,7 @@ struct gendisk {
struct disk_events *ev;
#ifdef CONFIG_BLK_DEV_INTEGRITY
struct blk_integrity *integrity;
+ struct kobject integrity_kobj;
#endif
int node_id;
};
^ permalink raw reply related
* [PATCH v2 00/12] blk-integrity lifetime fixes
From: Dan Williams @ 2015-10-15 19:59 UTC (permalink / raw)
To: martin.petersen
Cc: Jens Axboe, Keith Busch, linux-raid, Mike Snitzer, linux-nvdimm,
axboe, Vishal Verma, James Bottomley, NeilBrown, linux-nvme,
Sagi Grimberg, dm-devel, Matthew Wilcox, Ross Zwisler, hch
Changes since v1 [1]:
1/ Added a unification of nop profile definitions (Christoph)
2/ Fixed the CONFIG_BLK_DEV_INTEGRITY=n case (Martin)
3/ Folded a fix into "block: Consolidate static integrity profile
properties", and squahsed the blk_integrity_unregister() removal patches
into one. (Christoph, Martin)
4/ Collected Acked and Tested -by's from Keith, Neil, Vishal, and Ross
5/ Fixed up Documentation/ABI/testing/sysfs-block to reflect moving
"integrity" sysfs attributes from "disk" to "disk/queue".
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-October/002430.html
---
The recent "Block integrity registration update" caused a failing
signature that had been triggering intermittently in the libnvdimm unit
tests to start failing reliably every run. These tests run through
several blk_integrity configurations and as result exercise the
block-device setup/teardown path. This is a re-flow of "Block integrity
registration update" with incremental fixes.
Patches apply on Jens' block.git for-4.4/drivers, also available here:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm for-4.4/blk-integrity
---
Dan Williams (7):
md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
md: suspend i/o during runtime blk_integrity_unregister
nvme: suspend i/o during runtime blk_integrity_unregister
block: generic request_queue reference counting
block: move blk_integrity to request_queue
block: blk_flush_integrity() for bio-based drivers
block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
Martin K. Petersen (5):
block: Move integrity kobject to struct gendisk
block: Consolidate static integrity profile properties
block: Reduce the size of struct blk_integrity
block: Export integrity data interval size in sysfs
block: Inline blk_integrity in struct gendisk
Documentation/ABI/testing/sysfs-block | 17 ++-
block/bio-integrity.c | 17 ++-
block/blk-core.c | 74 +++++++++++-
block/blk-integrity.c | 199 +++++++++++++++------------------
block/blk-mq-sysfs.c | 6 -
block/blk-mq.c | 80 ++++---------
block/blk-sysfs.c | 7 +
block/blk.h | 22 ++++
block/partition-generic.c | 1
block/t10-pi.c | 16 +--
drivers/md/dm-table.c | 88 ++++++++-------
drivers/md/dm.c | 2
drivers/md/md.c | 13 +-
drivers/md/multipath.c | 2
drivers/md/raid1.c | 2
drivers/md/raid10.c | 2
drivers/nvdimm/btt.c | 1
drivers/nvdimm/core.c | 21 +--
drivers/nvme/host/pci.c | 40 ++-----
drivers/scsi/sd.c | 1
drivers/scsi/sd_dif.c | 29 +++--
drivers/target/target_core_iblock.c | 10 +-
fs/block_dev.c | 2
include/linux/blk-mq.h | 1
include/linux/blkdev.h | 54 ++++-----
include/linux/genhd.h | 25 ++++
include/linux/t10-pi.h | 8 +
27 files changed, 383 insertions(+), 357 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 7/7] Smack: Handle labels consistently in untrusted mounts
From: Seth Forshee @ 2015-10-15 19:24 UTC (permalink / raw)
To: Casey Schaufler
Cc: Eric W. Biederman, Alexander Viro, Serge Hallyn, Andy Lutomirski,
linux-fsdevel, linux-security-module, selinux, linux-kernel,
linux-mtd, linux-bcache, dm-devel, linux-raid, James Morris,
Serge E. Hallyn
In-Reply-To: <561F3DC7.4070901@schaufler-ca.com>
On Wed, Oct 14, 2015 at 10:46:47PM -0700, Casey Schaufler wrote:
> On 10/13/2015 10:04 AM, Seth Forshee wrote:
> > The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
> > differently in untrusted mounts. This is confusing and
> > potentically problematic. Change this to handle them all the same
> > way that SMACK64 is currently handled; that is, read the label
> > from disk and check it at use time. For SMACK64 and SMACK64MMAP
> > access is denied if the label does not match smk_root. To be
> > consistent with suid, a SMACK64EXEC label which does not match
> > smk_root will still allow execution of the file but will not run
> > with the label supplied in the xattr.
> >
> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>
> Aside from the one comment below (which I can be talked out of)
> this looks fine.
>
> > ---
> > security/smack/smack_lsm.c | 28 ++++++++++++++++++----------
> > 1 file changed, 18 insertions(+), 10 deletions(-)
> >
> > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> > index 621200f86b56..bee0b2652bf4 100644
> > --- a/security/smack/smack_lsm.c
> > +++ b/security/smack/smack_lsm.c
> > @@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> > struct inode *inode = file_inode(bprm->file);
> > struct task_smack *bsp = bprm->cred->security;
> > struct inode_smack *isp;
> > + struct superblock_smack *sbsp;
> > int rc;
> >
> > if (bprm->cred_prepared)
> > @@ -900,6 +901,10 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> > if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
> > return 0;
> >
> > + sbsp = inode->i_sb->s_security;
> > + if (sbsp->smk_flags & SMK_SB_UNTRUSTED && isp->smk_task != sbsp->smk_root)
>
> Call me old fashioned, but how about
>
> if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) && isp->smk_task != sbsp->smk_root)
>
> naked '&'s give me the willies.
That's fine by me.
Seth
^ permalink raw reply
* kernel: BUG: soft lockup - CPU#1 stuck for 60s! [md0_raid5:1614]
From: Rainer Fügenstein @ 2015-10-15 13:38 UTC (permalink / raw)
To: Linux-RAID
Hi,
my NAS-like server with 5*3TB SATA drives in RAID5 configuration was
running without problems for what seems an eternity; since about 3
weeks it keeps freezing every other day with the following error:
# grep soft /var/log/messages
Oct 15 11:26:49 alfred kernel: BUG: soft lockup - CPU#1 stuck for 60s! [md0_raid5:1614]
Oct 15 11:26:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:26:49 alfred kernel: [<ffffffff80012583>] __do_softirq+0x51/0x133
Oct 15 11:26:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:26:49 alfred kernel: [<ffffffff8006d63a>] do_softirq+0x2c/0x7d
Oct 15 11:27:49 alfred kernel: BUG: soft lockup - CPU#1 stuck for 60s! [md0_raid5:1614]
Oct 15 11:27:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:27:49 alfred kernel: [<ffffffff80012583>] __do_softirq+0x51/0x133
Oct 15 11:27:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:27:49 alfred kernel: [<ffffffff8006d63a>] do_softirq+0x2c/0x7d
Oct 15 11:28:49 alfred kernel: BUG: soft lockup - CPU#1 stuck for 60s! [md0_raid5:1614]
Oct 15 11:28:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:28:49 alfred kernel: [<ffffffff80012583>] __do_softirq+0x51/0x133
Oct 15 11:28:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:28:49 alfred kernel: [<ffffffff8006d63a>] do_softirq+0x2c/0x7d
[...]
this is only part of the story, check the end of this message for
a detailed log.
sometimes the server recovers after 60+ seconds, sometimes it requires
a hard reset (causing mdraid to re-sync the whole array).
IIRC, it started when a drive in the array failed with "SATA
connection timeouts" (kind of). this drive has been replaced by a new
one, but yet the CPU lockups keep coming.
I suspect that aging hardware slowly starts to fail, but not sure
which part (drives? SATA controller? cables? NIC? CPU? ...)
here's some info that might be useful:
# uname -a
Linux alfred 2.6.18-406.el5 #1 SMP Tue Jun 2 17:25:57 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[7] sdf1[3] sdc1[5] sde1[0] sdd1[8]
11721061376 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[=>...................] resync = 5.2% (154579584/2930265344) finish=3347.7min speed=13816K/sec
unused devices: <none>
excerpt:
ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata9.00: ATA-8: WDC WD30EZRX-00MMMB0, 80.00A80, max UDMA/133
ata9.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata9.00: configured for UDMA/133
sdb : very big device. try to use READ CAPACITY(16).
SCSI device sdb: 5860533168 512-byte hdwr sectors (3000593 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb : very big device. try to use READ CAPACITY(16).
SCSI device sdb: 5860533168 512-byte hdwr sectors (3000593 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 4:0:0:0: Attached scsi disk sdb
sd 4:0:0:0: Attached scsi generic sg1 type 0
Vendor: ATA Model: WDC WD30EZRX-00D Rev: 80.0
Type: Direct-Access ANSI SCSI revision: 05
# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 3 (rev 01)
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 01)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 01)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 01)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
05:00.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller (rev 09)
# cat /proc/cpuinfo
[...]
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
stepping : 10
cpu MHz : 1666.686
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3333.36
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
= = = detailed log:
Oct 15 11:27:49 alfred kernel: BUG: soft lockup - CPU#1 stuck for 60s! [md0_raid5:1614]
Oct 15 11:27:49 alfred kernel: CPU 1:
Oct 15 11:27:49 alfred kernel: Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat ip_
nat xt_state ip_conntrack nfnetlink ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge autofs4 ipv6 xfrm_nalgo crypto
_api xfs loop dm_multipath scsi_dh raid456 xor video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acp
i acpi_memhotplug ac parport_pc lp parport sg i2c_i801 i2c_core serio_raw tpm_tis pcspkr tpm sata_mv r8169 tpm_bios shpchp mii d
m_raid45 dm_message dm_region_hash dm_mem_cache dm_snapshot dm_zero dm_mirror dm_log dm_mod usb_storage ahci libata sd_mod scsi_
mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Oct 15 11:27:49 alfred kernel: Pid: 1614, comm: md0_raid5 Not tainted 2.6.18-406.el5 #1
Oct 15 11:27:49 alfred kernel: RIP: 0010:[<ffffffff881d35a2>] [<ffffffff881d35a2>] :r8169:rtl8169_interrupt+0x248/0x26f
Oct 15 11:27:49 alfred kernel: RSP: 0018:ffff81007eec7df8 EFLAGS: 00000206
Oct 15 11:27:49 alfred kernel: RAX: 0000000000000040 RBX: ffff81007de0a000 RCX: 0000000000000042
Oct 15 11:27:49 alfred kernel: RDX: 00000000ffe2001d RSI: ffffffff80047254 RDI: ffff81007de0a180
Oct 15 11:27:49 alfred kernel: RBP: ffff81007eec7d70 R08: 0000000000000003 R09: ffffffff8005e298
Oct 15 11:27:49 alfred kernel: R10: 0000000000000001 R11: 0000000000000060 R12: ffffffff8005dc9e
Oct 15 11:27:49 alfred kernel: R13: 0000000000000040 R14: ffffffff800796ae R15: ffff81007eec7d70
Oct 15 11:27:49 alfred kernel: FS: 0000000000000000(0000) GS:ffff81007ef179c0(0000) knlGS:0000000000000000
Oct 15 11:27:49 alfred kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Oct 15 11:27:49 alfred kernel: CR2: 00002b0a2bbba30c CR3: 00000000547e8000 CR4: 00000000000006a0
Oct 15 11:27:49 alfred kernel:
Oct 15 11:27:49 alfred kernel: Call Trace:
Oct 15 11:27:49 alfred kernel: <IRQ> [<ffffffff881d356b>] :r8169:rtl8169_interrupt+0x211/0x26f
Oct 15 11:27:49 alfred kernel: [<ffffffff80010dc0>] handle_IRQ_event+0x51/0xa6
Oct 15 11:27:49 alfred kernel: [<ffffffff800becc5>] __do_IRQ+0xfb/0x15b
Oct 15 11:27:49 alfred kernel: [<ffffffff8006d4c5>] do_IRQ+0xe9/0xf7
Oct 15 11:27:49 alfred kernel: [<ffffffff8005d625>] ret_from_intr+0x0/0xa
Oct 15 11:27:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:27:49 alfred kernel: [<ffffffff80012583>] __do_softirq+0x51/0x133
Oct 15 11:27:49 alfred kernel: [<ffffffff8005e298>] call_softirq+0x1c/0x28
Oct 15 11:27:49 alfred kernel: [<ffffffff8006d63a>] do_softirq+0x2c/0x7d
Oct 15 11:27:49 alfred kernel: [<ffffffff8005dc9e>] apic_timer_interrupt+0x66/0x6c
Oct 15 11:27:49 alfred kernel: <EOI> [<ffffffff80064b30>] _spin_unlock_irqrestore+0x8/0x9
Oct 15 11:27:49 alfred kernel: [<ffffffff88075d16>] :scsi_mod:scsi_dispatch_cmd+0x207/0x2b1
Oct 15 11:27:49 alfred kernel: [<ffffffff8807b926>] :scsi_mod:scsi_request_fn+0x2c3/0x392
Oct 15 11:27:49 alfred kernel: [<ffffffff8014af49>] elv_insert+0xac/0x1c4
Oct 15 11:27:49 alfred kernel: [<ffffffff8000c21c>] __make_request+0x47f/0x4ce
Oct 15 11:27:49 alfred kernel: [<ffffffff8001c84f>] generic_make_request+0x211/0x228
Oct 15 11:27:49 alfred kernel: [<ffffffff8001b125>] bio_alloc_bioset+0x89/0xd9
Oct 15 11:27:49 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:27:49 alfred kernel: [<ffffffff8003368c>] submit_bio+0xe6/0xed
Oct 15 11:27:49 alfred kernel: [<ffffffff80222dfe>] md_update_sb+0x1af/0x23a
Oct 15 11:27:49 alfred kernel: [<ffffffff8022812e>] md_check_recovery+0x15d/0x454
Oct 15 11:27:49 alfred kernel: [<ffffffff8833549f>] :raid456:raid5d+0x15/0x182
Oct 15 11:27:49 alfred kernel: [<ffffffff8003b13b>] prepare_to_wait+0x34/0x61
Oct 15 11:27:49 alfred kernel: [<ffffffff80225acc>] md_thread+0xf8/0x10e
Oct 15 11:27:49 alfred kernel: [<ffffffff800a3fb1>] autoremove_wake_function+0x0/0x2e
Oct 15 11:27:49 alfred kernel: [<ffffffff802259d4>] md_thread+0x0/0x10e
Oct 15 11:27:49 alfred kernel: [<ffffffff80032c1d>] kthread+0xfe/0x132
Oct 15 11:27:49 alfred kernel: [<ffffffff8005dfc1>] child_rip+0xa/0x11
Oct 15 11:27:49 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:27:49 alfred kernel: [<ffffffff80032b1f>] kthread+0x0/0x132
Oct 15 11:27:49 alfred kernel: [<ffffffff8005dfb7>] child_rip+0x0/0x11
Oct 15 11:27:49 alfred kernel:
Oct 15 11:28:14 alfred kernel: INFO: task pdflush:10294 blocked for more than 120 seconds.
Oct 15 11:28:14 alfred kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 15 11:28:14 alfred kernel: pdflush D ffff810002536420 0 10294 27 10375 1706 (L-TLB)
Oct 15 11:28:14 alfred kernel: ffff81006318baa0 0000000000000046 0000000000000003 0000000082147ce0
Oct 15 11:28:14 alfred kernel: 00900000000000d8 000000000000000a ffff8100614ff040 ffffffff8031db60
Oct 15 11:28:14 alfred kernel: 00004a61ef4e2a4e 0000000000008115 ffff8100614ff228 000000006166ea40
Oct 15 11:28:14 alfred kernel: Call Trace:
Oct 15 11:28:14 alfred kernel: [<ffffffff80224647>] md_write_start+0xf2/0x108
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3fb1>] autoremove_wake_function+0x0/0x2e
Oct 15 11:28:14 alfred kernel: [<ffffffff883cce08>] :xfs:xfs_page_state_convert+0x4f7/0x546
Oct 15 11:28:14 alfred kernel: [<ffffffff88335db1>] :raid456:make_request+0x4e/0x4e3
Oct 15 11:28:14 alfred kernel: [<ffffffff8001c84f>] generic_make_request+0x211/0x228
Oct 15 11:28:14 alfred kernel: [<ffffffff800238ac>] mempool_alloc+0x31/0xe7
Oct 15 11:28:14 alfred kernel: [<ffffffff8003368c>] submit_bio+0xe6/0xed
Oct 15 11:28:14 alfred kernel: [<ffffffff883ce805>] :xfs:_xfs_buf_ioapply+0x1f2/0x254
Oct 15 11:28:14 alfred kernel: [<ffffffff883ce8a0>] :xfs:xfs_buf_iorequest+0x39/0x64
Oct 15 11:28:14 alfred kernel: [<ffffffff883b89e2>] :xfs:xlog_bdstrat_cb+0x16/0x3c
Oct 15 11:28:14 alfred kernel: [<ffffffff883b99e4>] :xfs:xlog_sync+0x218/0x3ad
Oct 15 11:28:14 alfred kernel: [<ffffffff883ba744>] :xfs:xlog_state_sync_all+0xb9/0x1d9
Oct 15 11:28:14 alfred kernel: [<ffffffff883bacc7>] :xfs:_xfs_log_force+0x59/0x68
Oct 15 11:28:14 alfred kernel: [<ffffffff883bace1>] :xfs:xfs_log_force+0xb/0x3f
Oct 15 11:28:14 alfred kernel: [<ffffffff883c6587>] :xfs:xfs_syncsub+0x33/0x226
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:28:14 alfred kernel: [<ffffffff883d3cad>] :xfs:xfs_fs_write_super+0x1b/0x21
Oct 15 11:28:14 alfred kernel: [<ffffffff800e8c5a>] sync_supers+0x80/0xe1
Oct 15 11:28:14 alfred kernel: [<ffffffff8005697a>] pdflush+0x0/0x1fb
Oct 15 11:28:14 alfred kernel: [<ffffffff800cdca0>] wb_kupdate+0x3e/0x16a
Oct 15 11:28:14 alfred kernel: [<ffffffff8005697a>] pdflush+0x0/0x1fb
Oct 15 11:28:14 alfred kernel: [<ffffffff80056acb>] pdflush+0x151/0x1fb
Oct 15 11:28:14 alfred kernel: [<ffffffff800cdc62>] wb_kupdate+0x0/0x16a
Oct 15 11:28:14 alfred kernel: [<ffffffff80032c1d>] kthread+0xfe/0x132
Oct 15 11:28:14 alfred kernel: [<ffffffff8005dfc1>] child_rip+0xa/0x11
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:28:14 alfred kernel: [<ffffffff80032b1f>] kthread+0x0/0x132
Oct 15 11:28:14 alfred kernel: [<ffffffff8005dfb7>] child_rip+0x0/0x11
Oct 15 11:28:14 alfred kernel:
Oct 15 11:28:14 alfred kernel: INFO: task md0_resync:13543 blocked for more than 120 seconds.
Oct 15 11:28:14 alfred kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 15 11:28:14 alfred kernel: md0_resync D ffff810037f117f0 0 13543 27 10375 (L-TLB)
Oct 15 11:28:14 alfred kernel: ffff81004dad3c50 0000000000000046 0000000000000001 0000000000000000
Oct 15 11:28:14 alfred kernel: ffff81007eb6f5f0 000000000000000a ffff81005fe63080 ffff810037f117f0
Oct 15 11:28:14 alfred kernel: 00004a613eedffb5 00000000003a50b4 ffff81005fe63268 0000000000000003
Oct 15 11:28:14 alfred kernel: Call Trace:
Oct 15 11:28:14 alfred kernel: [<ffffffff8002e493>] __wake_up+0x38/0x4f
Oct 15 11:28:14 alfred kernel: [<ffffffff880756c0>] :scsi_mod:scsi_done+0x0/0x18
Oct 15 11:28:14 alfred kernel: [<ffffffff88330dc5>] :raid456:get_active_stripe+0x242/0x4bd
Oct 15 11:28:14 alfred kernel: [<ffffffff8008f4f9>] default_wake_function+0x0/0xe
Oct 15 11:28:14 alfred kernel: [<ffffffff88335ccc>] :raid456:sync_request+0x6c0/0x757
Oct 15 11:28:14 alfred kernel: [<ffffffff8807b9a0>] :scsi_mod:scsi_request_fn+0x33d/0x392
Oct 15 11:28:14 alfred kernel: [<ffffffff801583ef>] __next_cpu+0x19/0x28
Oct 15 11:28:14 alfred kernel: [<ffffffff80225f46>] md_do_sync+0x464/0x84b
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:28:14 alfred kernel: [<ffffffff80225acc>] md_thread+0xf8/0x10e
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:28:14 alfred kernel: [<ffffffff802259d4>] md_thread+0x0/0x10e
Oct 15 11:28:14 alfred kernel: [<ffffffff80032c1d>] kthread+0xfe/0x132
Oct 15 11:28:14 alfred kernel: [<ffffffff8005dfc1>] child_rip+0xa/0x11
Oct 15 11:28:14 alfred kernel: [<ffffffff800a3d99>] keventd_create_kthread+0x0/0xc4
Oct 15 11:28:14 alfred kernel: [<ffffffff80032b1f>] kthread+0x0/0x132
Oct 15 11:28:14 alfred kernel: [<ffffffff8005dfb7>] child_rip+0x0/0x11
Oct 15 11:28:14 alfred kernel:
tnx & cu
--
Best regards,
Rainer mailto:rfu@oudeis.org
^ permalink raw reply
* Re: Debian jessie - RAID 6 reshape - making no progress after >48 hours
From: Alexander Afonyashin @ 2015-10-15 10:08 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: Phil Reynolds, Linux-RAID
In-Reply-To: <alpine.DEB.2.02.1510150906280.8750@uplift.swm.pp.se>
Hi,
It seems that --backup-file option is missed.
Regards,
Alexander
On Thu, Oct 15, 2015 at 10:09 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Wed, 14 Oct 2015, Phil Reynolds wrote:
>
>> What can I safely do to move this along?
>
>
> Please check the mailing list archives from the past months, you are not
> alone in having this problem. Do not reboot your machine or stop the array
> unless you absolutely need to, it might be possible to just issue --continue
> to the array.
>
> --
> Mikael Abrahamsson email: swmike@swm.pp.se
>
> --
> 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: Scalability of MD raid 1 mirror devices
From: Ankur Bose @ 2015-10-15 9:04 UTC (permalink / raw)
To: linux-raid, neilb; +Cc: Suresh Babu Kandukuru
In-Reply-To: <a8179bae-f8e8-4239-b760-cd85252e48bc@default>
Hi, it seems like this is very active group , I don't see any reason why anyone is not replying to the below mail.
Kindly reply we are in middle of something.
Thanks,
ankur.
-----Original Message-----
From: Suresh Babu Kandukuru
Sent: 12 October 2015 17:34
To: linux-raid@vger.kernel.org; neilb@suse.de
Subject: Scalability of MD raid 1 mirror devices
Dear Group,
We are doing scalability of MD raid 1 mirror devices on the Linux host running the 3.17.2 . we see the number of RAID 1 devices limited to 128 in one case and 511 in another case . we would like to know why this limitation ?. Appreciate any kind of inputs and pointers
We can create the RAID 1 device in 3 ways.
1. /dev/mdX -> here X is the number, we can specify from 0 to 511.
2. /dev/md/X -> here also X is a number from 0 to 511. It creates it as a link to the actual device /dev/mdX. ( similar to above but creates a link also).
3. /dev/md/”name” -> This creates a link to actual device, whichever is free starting from 127 to 0. Below is the function which is responsible for it.
char *find_free_devnm(int use_partitions) {
static char devnm[32];
int devnum;
for (devnum = 127; devnum != 128; devnum = devnum ? devnum-1 : (1<<20)-1) {
if (use_partitions)
sprintf(devnm, "md_d%d", devnum);
else
sprintf(devnm, "md%d", devnum);
if (mddev_busy(devnm))
continue;
if (!conf_name_is_free(devnm))
continue;
if (!use_udev()) {
/* make sure it is new to /dev too, at least as a
* non-standard */
int devid = devnm2devid(devnm);
if (devid) {
char *dn = map_dev(major(devid),
minor(devid), 0);
if (dn && ! is_standard(dn, NULL))
continue;
}
}
break;
}
if (devnum == 128)
return NULL;
return devnm;
}
So ideally we should not create a device which is more than 128 { The program may crash }.
Then we tried to find how we are able to create up to 511 and why it is failing after that.
int dev_open(char *dev, int flags)
inside this function
fd = open(dev, flags); / this line is assigning fd to -1 , which is causing the program to fail. So I wrote a simple program to crosscheck it.
int main(){
char devname[32] = "/dev/hello1";
// The flags I have set according to the code.
int flags = O_RDWR;
flags |= O_DIRECT;
if (mknod(devname, S_IFBLK|0600, makedev(9,511)) == 0) {
int fd = open(devname, flags);
cout<<fd<<endl;
unlink(devname);
}
}
So if the minor number is more than 511, the “fd” is assigned to -1, if it is in the range of 0 to 511 It is working fine.
So should we go with the range of 511 or stick to 128 ?
Thanks
/Suresh
--
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
^ permalink raw reply
* Re: Debian jessie - RAID 6 reshape - making no progress after >48 hours
From: Mikael Abrahamsson @ 2015-10-15 7:09 UTC (permalink / raw)
To: Phil Reynolds; +Cc: linux-raid
In-Reply-To: <20151014181019.6f7f9d0a@topdeck.tinsleyviaduct.com>
On Wed, 14 Oct 2015, Phil Reynolds wrote:
> What can I safely do to move this along?
Please check the mailing list archives from the past months, you are not
alone in having this problem. Do not reboot your machine or stop the
array unless you absolutely need to, it might be possible to just issue
--continue to the array.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* RE: [PATCH] MD: fix missing cpu_to_le32 for MD_FEATURE_JOURNAL
From: Song Liu @ 2015-10-15 6:54 UTC (permalink / raw)
To: Neil Brown, linux-raid@vger.kernel.org; +Cc: Shaohua Li
In-Reply-To: <87d1wgwsbx.fsf@notabene.neil.brown.name>
> -----Original Message-----
> From: Neil Brown [mailto:neilb@suse.com]
> Sent: Wednesday, October 14, 2015 11:37 PM
> To: Song Liu <songliubraving@fb.com>; linux-raid@vger.kernel.org
> Cc: Song Liu <songliubraving@fb.com>; Shaohua Li <shli@fb.com>
> Subject: Re: [PATCH] MD: fix missing cpu_to_le32 for
> MD_FEATURE_JOURNAL
>
> Song Liu <songliubraving@fb.com> writes:
>
> > sb->feature_map is __le32, add missing cpu_to_le32()
> >
> > Reported-by: kbuild test robot <fengguang.wu@intel.com>
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
> > drivers/md/md.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/md/md.c b/drivers/md/md.c index 378b9f0..163b548
> > 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -1812,7 +1812,7 @@ retry:
> > sb->dev_roles[i] = cpu_to_le16(MD_DISK_ROLE_FAULTY);
> >
> > if (test_bit(MD_HAS_JOURNAL, &mddev->flags))
> > - sb->feature_map |= MD_FEATURE_JOURNAL;
> > + sb->feature_map |= cpu_to_le32(MD_FEATURE_JOURNAL);
> >
> > rdev_for_each(rdev2, mddev) {
> > i = rdev2->desc_nr;
> > --
> > 2.4.6
>
> Thanks.
> I just emrged this in rather than create a new patch.
>
> NeilBrown
That's awesome!
Thanks,
Song
^ permalink raw reply
* Re: [PATCH] MD: fix missing cpu_to_le32 for MD_FEATURE_JOURNAL
From: Neil Brown @ 2015-10-15 6:37 UTC (permalink / raw)
To: linux-raid; +Cc: Song Liu, shli
In-Reply-To: <1444888404-994890-1-git-send-email-songliubraving@fb.com>
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
Song Liu <songliubraving@fb.com> writes:
> sb->feature_map is __le32, add missing cpu_to_le32()
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> drivers/md/md.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 378b9f0..163b548 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1812,7 +1812,7 @@ retry:
> sb->dev_roles[i] = cpu_to_le16(MD_DISK_ROLE_FAULTY);
>
> if (test_bit(MD_HAS_JOURNAL, &mddev->flags))
> - sb->feature_map |= MD_FEATURE_JOURNAL;
> + sb->feature_map |= cpu_to_le32(MD_FEATURE_JOURNAL);
>
> rdev_for_each(rdev2, mddev) {
> i = rdev2->desc_nr;
> --
> 2.4.6
Thanks.
I just emrged this in rather than create a new patch.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* [PATCH] MD: fix missing cpu_to_le32 for MD_FEATURE_JOURNAL
From: Song Liu @ 2015-10-15 5:53 UTC (permalink / raw)
To: linux-raid; +Cc: Song Liu, neilb, shli
sb->feature_map is __le32, add missing cpu_to_le32()
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/md/md.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 378b9f0..163b548 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -1812,7 +1812,7 @@ retry:
sb->dev_roles[i] = cpu_to_le16(MD_DISK_ROLE_FAULTY);
if (test_bit(MD_HAS_JOURNAL, &mddev->flags))
- sb->feature_map |= MD_FEATURE_JOURNAL;
+ sb->feature_map |= cpu_to_le32(MD_FEATURE_JOURNAL);
rdev_for_each(rdev2, mddev) {
i = rdev2->desc_nr;
--
2.4.6
^ permalink raw reply related
* Re: [PATCH v2 7/7] Smack: Handle labels consistently in untrusted mounts
From: Casey Schaufler @ 2015-10-15 5:46 UTC (permalink / raw)
To: Seth Forshee, Eric W. Biederman
Cc: Alexander Viro, Serge Hallyn, Andy Lutomirski, linux-fsdevel,
linux-security-module, selinux, linux-kernel, linux-mtd,
linux-bcache, dm-devel, linux-raid, James Morris, Serge E. Hallyn
In-Reply-To: <1444755861-54997-8-git-send-email-seth.forshee@canonical.com>
On 10/13/2015 10:04 AM, Seth Forshee wrote:
> The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
> differently in untrusted mounts. This is confusing and
> potentically problematic. Change this to handle them all the same
> way that SMACK64 is currently handled; that is, read the label
> from disk and check it at use time. For SMACK64 and SMACK64MMAP
> access is denied if the label does not match smk_root. To be
> consistent with suid, a SMACK64EXEC label which does not match
> smk_root will still allow execution of the file but will not run
> with the label supplied in the xattr.
>
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Aside from the one comment below (which I can be talked out of)
this looks fine.
> ---
> security/smack/smack_lsm.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 621200f86b56..bee0b2652bf4 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> struct inode *inode = file_inode(bprm->file);
> struct task_smack *bsp = bprm->cred->security;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int rc;
>
> if (bprm->cred_prepared)
> @@ -900,6 +901,10 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
> return 0;
>
> + sbsp = inode->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED && isp->smk_task != sbsp->smk_root)
Call me old fashioned, but how about
if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) && isp->smk_task != sbsp->smk_root)
naked '&'s give me the willies.
> + return 0;
> +
> if (bprm->unsafe & (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
> struct task_struct *tracer;
> rc = 0;
> @@ -1703,6 +1708,7 @@ static int smack_mmap_file(struct file *file,
> struct task_smack *tsp;
> struct smack_known *okp;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int may;
> int mmay;
> int tmay;
> @@ -1714,6 +1720,10 @@ static int smack_mmap_file(struct file *file,
> isp = file_inode(file)->i_security;
> if (isp->smk_mmap == NULL)
> return 0;
> + sbsp = file_inode(file)->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED &&
> + isp->smk_mmap != sbsp->smk_root)
> + return -EACCES;
> mkp = isp->smk_mmap;
>
> tsp = current_security();
> @@ -3492,16 +3502,14 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode)
> if (rc >= 0)
> transflag = SMK_INODE_TRANSMUTE;
> }
> - if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) {
> - /*
> - * Don't let the exec or mmap label be "*" or "@".
> - */
> - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> - if (IS_ERR(skp) || skp == &smack_known_star ||
> - skp == &smack_known_web)
> - skp = NULL;
> - isp->smk_task = skp;
> - }
> + /*
> + * Don't let the exec or mmap label be "*" or "@".
> + */
> + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> + if (IS_ERR(skp) || skp == &smack_known_star ||
> + skp == &smack_known_web)
> + skp = NULL;
> + isp->smk_task = skp;
>
> skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp);
> if (IS_ERR(skp) || skp == &smack_known_star ||
^ permalink raw reply
* [md:devel 40/44] drivers/md/md.c:1813:33: sparse: invalid assignment: |=
From: kbuild test robot @ 2015-10-15 3:53 UTC (permalink / raw)
To: Song Liu; +Cc: kbuild-all, linux-raid, NeilBrown, Shaohua Li
tree: git://neil.brown.name/md devel
head: 3ad01dcc5180761bf7686dd6e6fb8083ca22b913
commit: 768e16727c9b1f35a809a8068b218743fd8fb557 [40/44] MD: add new bit to indicate raid array with journal
reproduce:
# apt-get install sparse
git checkout 768e16727c9b1f35a809a8068b218743fd8fb557
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/md/md.c:1480:34: sparse: cast to restricted __le64
drivers/md/md.c:1782:40: sparse: incorrect type in assignment (different base types)
drivers/md/md.c:1782:40: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident>
drivers/md/md.c:1782:40: got restricted __le64 [usertype] <noident>
>> drivers/md/md.c:1813:33: sparse: invalid assignment: |=
drivers/md/md.c:1813:33: left side has type restricted __le32
drivers/md/md.c:1813:33: right side has type int
drivers/md/md.c:1862:26: sparse: incorrect type in assignment (different base types)
drivers/md/md.c:1862:26: expected restricted __le64 [usertype] super_offset
drivers/md/md.c:1862:26: got unsigned long [unsigned] [usertype] sb_start
drivers/md/md.c:2268:31: sparse: cast to restricted __le64
drivers/md/md.c:2268:31: sparse: cast from restricted __le32
vim +1813 drivers/md/md.c
1797 max_dev = rdev2->desc_nr+1;
1798
1799 if (max_dev > le32_to_cpu(sb->max_dev)) {
1800 int bmask;
1801 sb->max_dev = cpu_to_le32(max_dev);
1802 rdev->sb_size = max_dev * 2 + 256;
1803 bmask = queue_logical_block_size(rdev->bdev->bd_disk->queue)-1;
1804 if (rdev->sb_size & bmask)
1805 rdev->sb_size = (rdev->sb_size | bmask) + 1;
1806 } else
1807 max_dev = le32_to_cpu(sb->max_dev);
1808
1809 for (i=0; i<max_dev;i++)
1810 sb->dev_roles[i] = cpu_to_le16(MD_DISK_ROLE_FAULTY);
1811
1812 if (test_bit(MD_HAS_JOURNAL, &mddev->flags))
> 1813 sb->feature_map |= MD_FEATURE_JOURNAL;
1814
1815 rdev_for_each(rdev2, mddev) {
1816 i = rdev2->desc_nr;
1817 if (test_bit(Faulty, &rdev2->flags))
1818 sb->dev_roles[i] = cpu_to_le16(MD_DISK_ROLE_FAULTY);
1819 else if (test_bit(In_sync, &rdev2->flags))
1820 sb->dev_roles[i] = cpu_to_le16(rdev2->raid_disk);
1821 else if (test_bit(Journal, &rdev2->flags))
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [md:devel 12/62] drivers/md/md-cluster.c:943:24: sparse: incorrect type in assignment (different base types)
From: kbuild test robot @ 2015-10-15 3:32 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: kbuild-all, linux-raid, Goldwyn Rodrigues
tree: git://neil.brown.name/md devel
head: 3ad01dcc5180761bf7686dd6e6fb8083ca22b913
commit: faeff83fa478b4dca9877d6b10a25ad252891f14 [12/62] md-cluster: make other members of cluster_msg is handled by little endian funcs
reproduce:
# apt-get install sparse
git checkout faeff83fa478b4dca9877d6b10a25ad252891f14
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/md/md-cluster.c:218:15: sparse: restricted __le64 degrades to integer
drivers/md/md-cluster.c:421:49: sparse: cast to restricted __le32
drivers/md/md-cluster.c:435:29: sparse: cast to restricted __le32
drivers/md/md-cluster.c:442:52: sparse: cast to restricted __le32
drivers/md/md-cluster.c:447:17: sparse: cast to restricted __le32
drivers/md/md-cluster.c:454:52: sparse: cast to restricted __le32
drivers/md/md-cluster.c:459:17: sparse: cast to restricted __le32
drivers/md/md-cluster.c:574:20: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:574:20: expected int [signed] slot
drivers/md/md-cluster.c:574:20: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:794:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:794:19: expected int [signed] type
drivers/md/md-cluster.c:794:19: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:849:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:849:19: expected int [signed] [addressable] type
drivers/md/md-cluster.c:849:19: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:855:40: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:855:40: expected int [signed] [addressable] [assigned] raid_slot
drivers/md/md-cluster.c:855:40: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:888:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:888:19: expected int [signed] type
drivers/md/md-cluster.c:888:19: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:889:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:889:19: expected int [signed] slot
drivers/md/md-cluster.c:889:19: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:890:18: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:890:18: expected unsigned long [unsigned] [usertype] low
drivers/md/md-cluster.c:890:18: got restricted __le64 [usertype] <noident>
drivers/md/md-cluster.c:891:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:891:19: expected unsigned long [unsigned] [usertype] high
drivers/md/md-cluster.c:891:19: got restricted __le64 [usertype] <noident>
drivers/md/md-cluster.c:941:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:941:19: expected int [signed] [addressable] type
drivers/md/md-cluster.c:941:19: got restricted __le32 [usertype] <noident>
>> drivers/md/md-cluster.c:943:24: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:943:24: expected int [signed] [addressable] raid_slot
drivers/md/md-cluster.c:943:24: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:986:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:986:19: expected int [signed] type
drivers/md/md-cluster.c:986:19: got restricted __le32 [usertype] <noident>
>> drivers/md/md-cluster.c:987:24: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:987:24: expected int [signed] raid_slot
drivers/md/md-cluster.c:987:24: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:999:19: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:999:19: expected int [signed] type
drivers/md/md-cluster.c:999:19: got restricted __le32 [usertype] <noident>
drivers/md/md-cluster.c:1000:24: sparse: incorrect type in assignment (different base types)
drivers/md/md-cluster.c:1000:24: expected int [signed] raid_slot
drivers/md/md-cluster.c:1000:24: got restricted __le32 [usertype] <noident>
vim +943 drivers/md/md-cluster.c
884
885 add_resync_info(mddev, cinfo->bitmap_lockres, lo, hi);
886 /* Re-acquire the lock to refresh LVB */
887 dlm_lock_sync(cinfo->bitmap_lockres, DLM_LOCK_PW);
888 cmsg.type = cpu_to_le32(RESYNCING);
889 cmsg.slot = cpu_to_le32(slot);
> 890 cmsg.low = cpu_to_le64(lo);
891 cmsg.high = cpu_to_le64(hi);
892
893 return sendmsg(cinfo, &cmsg);
894 }
895
896 static int resync_finish(struct mddev *mddev)
897 {
898 struct md_cluster_info *cinfo = mddev->cluster_info;
899 cinfo->resync_lockres->flags &= ~DLM_LKF_NOQUEUE;
900 dlm_unlock_sync(cinfo->resync_lockres);
901 return resync_info_update(mddev, 0, 0);
902 }
903
904 static int area_resyncing(struct mddev *mddev, int direction,
905 sector_t lo, sector_t hi)
906 {
907 struct md_cluster_info *cinfo = mddev->cluster_info;
908 int ret = 0;
909 struct suspend_info *s;
910
911 if ((direction == READ) &&
912 test_bit(MD_CLUSTER_SUSPEND_READ_BALANCING, &cinfo->state))
913 return 1;
914
915 spin_lock_irq(&cinfo->suspend_lock);
916 if (list_empty(&cinfo->suspend_list))
917 goto out;
918 list_for_each_entry(s, &cinfo->suspend_list, list)
919 if (hi > s->lo && lo < s->hi) {
920 ret = 1;
921 break;
922 }
923 out:
924 spin_unlock_irq(&cinfo->suspend_lock);
925 return ret;
926 }
927
928 /* add_new_disk() - initiates a disk add
929 * However, if this fails before writing md_update_sb(),
930 * add_new_disk_cancel() must be called to release token lock
931 */
932 static int add_new_disk(struct mddev *mddev, struct md_rdev *rdev)
933 {
934 struct md_cluster_info *cinfo = mddev->cluster_info;
935 struct cluster_msg cmsg;
936 int ret = 0;
937 struct mdp_superblock_1 *sb = page_address(rdev->sb_page);
938 char *uuid = sb->device_uuid;
939
940 memset(&cmsg, 0, sizeof(cmsg));
> 941 cmsg.type = cpu_to_le32(NEWDISK);
942 memcpy(cmsg.uuid, uuid, 16);
> 943 cmsg.raid_slot = cpu_to_le32(rdev->desc_nr);
944 lock_comm(cinfo);
945 ret = __sendmsg(cinfo, &cmsg);
946 if (ret)
947 return ret;
948 cinfo->no_new_dev_lockres->flags |= DLM_LKF_NOQUEUE;
949 ret = dlm_lock_sync(cinfo->no_new_dev_lockres, DLM_LOCK_EX);
950 cinfo->no_new_dev_lockres->flags &= ~DLM_LKF_NOQUEUE;
951 /* Some node does not "see" the device */
952 if (ret == -EAGAIN)
953 ret = -ENOENT;
954 if (ret)
955 unlock_comm(cinfo);
956 else
957 dlm_lock_sync(cinfo->no_new_dev_lockres, DLM_LOCK_CR);
958 return ret;
959 }
960
961 static void add_new_disk_cancel(struct mddev *mddev)
962 {
963 struct md_cluster_info *cinfo = mddev->cluster_info;
964 unlock_comm(cinfo);
965 }
966
967 static int new_disk_ack(struct mddev *mddev, bool ack)
968 {
969 struct md_cluster_info *cinfo = mddev->cluster_info;
970
971 if (!test_bit(MD_CLUSTER_WAITING_FOR_NEWDISK, &cinfo->state)) {
972 pr_warn("md-cluster(%s): Spurious cluster confirmation\n", mdname(mddev));
973 return -EINVAL;
974 }
975
976 if (ack)
977 dlm_unlock_sync(cinfo->no_new_dev_lockres);
978 complete(&cinfo->newdisk_completion);
979 return 0;
980 }
981
982 static int remove_disk(struct mddev *mddev, struct md_rdev *rdev)
983 {
984 struct cluster_msg cmsg;
985 struct md_cluster_info *cinfo = mddev->cluster_info;
986 cmsg.type = cpu_to_le32(REMOVE);
> 987 cmsg.raid_slot = cpu_to_le32(rdev->desc_nr);
988 return __sendmsg(cinfo, &cmsg);
989 }
990
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH] md: fix 32-bit build warning
From: Neil Brown @ 2015-10-14 22:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-raid, linux-kernel, Goldwyn Rodrigues, linux-arm-kernel
In-Reply-To: <11281560.gJ28rX782P@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]
Arnd Bergmann <arnd@arndb.de> writes:
> On Monday 12 October 2015 15:59:27 Neil Brown wrote:
>> > diff --git a/drivers/md/md.c b/drivers/md/md.c
>> > index 7fff1e6884d6..e13f72a3b561 100644
>> > --- a/drivers/md/md.c
>> > +++ b/drivers/md/md.c
>> > @@ -8987,9 +8987,9 @@ static void check_sb_changes(struct mddev *mddev, struct md_rdev *rdev)
>> >
>> > /* recovery_cp changed */
>> > if (le64_to_cpu(sb->resync_offset) != mddev->recovery_cp) {
>> > - pr_info("%s:%d recovery_cp changed from %lu to %lu\n", __func__,
>> > - __LINE__, mddev->recovery_cp,
>> > - (unsigned long) le64_to_cpu(sb->resync_offset));
>> > + pr_info("%s:%d recovery_cp changed from %llu to %llu\n", __func__,
>> > + __LINE__, (u64)mddev->recovery_cp,
>> > + (u64) le64_to_cpu(sb->resync_offset));
>> > mddev->recovery_cp = le64_to_cpu(sb->resync_offset);
>> > }
>> >
>>
>> Thanks, but is this really right?
>> I think u64 is "unsigned long" on 64bit.
>> I have always used (unsigned long long) when I want to use %llu on
>> sector_t.
>>
>> How confident are you of using "u64" ?
>
> Very confident ;-)
>
> This used to not work until some linux-2.6 version when we changed all
> architectures to use asm-generic/int-ll64.h in the kernel, because
> a lot of code relied on printing u64 variables using %lld.
>
> I tend to use u64 for things like this because it's shorter than
> 'unsigned long long'.
>
Ahh.. good to know - thanks.
It seems that we've since removed those 'pr_info' lines, so there is
nothing to fix any more. I'll remember that about using "u64" though -
using "unsigned long long" always felt so clumsy.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: mdadm RAID 5 reshape not working
From: Daniel J. R. May @ 2015-10-14 20:37 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1444850463.3967.19.camel@kada-media.com>
On Wed, 2015-10-14 at 20:21 +0100, Daniel J. R. May wrote:
> I attempted to add a disk to an mdadm RAID 5 array with the
> following:
>
> mdadm --manage /dev/md1 --add /dev/sdf1
> mdadm --grow --raid-devices=5 --backup-file=/root/md1-grow.bak
> /dev/md1
>
> These command gave no errors, but although mdadm reports that the
> array
> is reshaping it does not seem to have done anything after a couple of
> hours:
Having hunted around on this mailing list I see that this is a pretty
common problem. I was able to get my reshape going by issuing:
mdadm --grow --continue --backup-file=/root/md1-grow.bak /dev/md1
So we're now off and running!
[root@sulphur ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md1 : active raid5 sdf1[5] sde1[4] sdb1[0] sdd1[2] sdc1[1]
11720656896 blocks super 1.2 level 5, 512k chunk, algorithm 2
[5/5] [UUUUU]
[>....................] reshape = 0.3% (15161292/3906885632)
finish=1270.9min speed=51032K/sec
bitmap: 0/30 pages [0KB], 65536KB chunk
Best wishes,
Dan
^ permalink raw reply
* mdadm RAID 5 reshape not working
From: Daniel J. R. May @ 2015-10-14 19:21 UTC (permalink / raw)
To: linux-raid
I attempted to add a disk to an mdadm RAID 5 array with the following:
mdadm --manage /dev/md1 --add /dev/sdf1
mdadm --grow --raid-devices=5 --backup-file=/root/md1-grow.bak /dev/md1
These command gave no errors, but although mdadm reports that the array
is reshaping it does not seem to have done anything after a couple of
hours:
[root@sulphur ~]# mdadm -D /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Thu May 14 18:19:10 2015
Raid Level : raid5
Array Size : 11720656896 (11177.69 GiB 12001.95 GB)
Used Dev Size : 3906885632 (3725.90 GiB 4000.65 GB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Oct 14 18:48:37 2015
State : clean, reshaping
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Reshape Status : 0% complete
Delta Devices : 1, (4->5)
Name : sulphur.kada-media.red:1 (local to host sulphur.kada
-media.red)
UUID : dbadf568:66ef2f61:ba13ddd6:176fb4f5
Events : 14870
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
4 8 65 3 active sync /dev/sde1
5 8 81 4 active sync /dev/sdf1
[root@sulphur ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md1 : active raid5 sdf1[5] sde1[4] sdb1[0] sdd1[2] sdc1[1]
11720656896 blocks super 1.2 level 5, 512k chunk, algorithm 2
[5/5] [UUUUU]
[>....................] reshape = 0.0% (0/3906885632)
finish=19225133047.4min speed=0K/sec
bitmap: 0/30 pages [0KB], 65536KB chunk
md0 : active raid5 sdk1[5] sdh1[1] sdi1[3] sdm1[7] sdg1[0] sdl1[4]
sdj1[2]
17580804096 blocks super 1.2 level 5, 512k chunk, algorithm 2
[7/7] [UUUUUUU]
bitmap: 0/22 pages [0KB], 65536KB chunk
unused devices: <none>
Output of dmesg:
[ 7351.071351] md: bind<sdf1>
[ 7351.398116] RAID conf printout:
[ 7351.398123] --- level:5 rd:4 wd:4
[ 7351.398127] disk 0, o:1, dev:sdb1
[ 7351.398131] disk 1, o:1, dev:sdc1
[ 7351.398134] disk 2, o:1, dev:sdd1
[ 7351.398136] disk 3, o:1, dev:sde1
[ 7420.751226] RAID conf printout:
[ 7420.751234] --- level:5 rd:5 wd:5
[ 7420.751239] disk 0, o:1, dev:sdb1
[ 7420.751242] disk 1, o:1, dev:sdc1
[ 7420.751245] disk 2, o:1, dev:sdd1
[ 7420.751248] disk 3, o:1, dev:sde1
[ 7420.751251] disk 4, o:1, dev:sdf1
[ 7420.751524] md: reshape of RAID array md1
[ 7420.751530] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 7420.751534] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for reshape.
[ 7420.751542] md: using 128k window, over a total of 3906885632k.
The array is used as the physical volume for a single volume group
which I deactivated before performing the mdadm grow.
Can you tell me what I should do to get the reshape to start (and
complete) or rescue the array?
Thank you in advance for any help!
Dan
^ permalink raw reply
* Debian jessie - RAID 6 reshape - making no progress after >48 hours
From: Phil Reynolds @ 2015-10-14 17:10 UTC (permalink / raw)
To: linux-raid
I have recently tried to add 4 additional devices to a RAID 6 array,
with this command:
mdadm -G /dev/md1 -n 8 -a /dev/sdb2 /dev/sdf2 /dev/sdg2 /dev/sdh2
Output from the command, I do not have, but it is what I would take as
normal - it confirmed what I had asked with no error.
dmesg | grep -w md shows this:
[ 2.339195] md: bind<sde2>
[ 2.339957] md: bind<sdc1>
[ 2.341128] md: bind<sdd2>
[ 2.342079] md: bind<sdc3>
[ 2.342735] md: bind<sdd3>
[ 2.343667] md: bind<sdc2>
[ 2.344923] md: bind<sdd1>
[ 2.345939] md: bind<sde1>
[ 2.347212] md: bind<sde3>
[ 3.413622] md: bind<sda2>
[ 3.660395] md: raid6 personality registered for level 6
[ 3.660396] md: raid5 personality registered for level 5
[ 3.660397] md: raid4 personality registered for level 4
[ 3.660548] md/raid:md1: device sda2 operational as raid disk 0
[ 3.660550] md/raid:md1: device sdc2 operational as raid disk 1
[ 3.660551] md/raid:md1: device sdd2 operational as raid disk 2
[ 3.660552] md/raid:md1: device sde2 operational as raid disk 3
[ 3.660844] md/raid:md1: allocated 0kB
[ 3.660862] md/raid:md1: raid level 6 active with 4 out of 4
devices, algorithm 2 [ 3.731726] md: bind<sda3>
[ 3.733039] md: raid0 personality registered for level 0
[ 3.733168] md/raid0:md2: md_size is 234129408 sectors.
[ 3.733170] md: RAID0 configuration for md2 - 1 zone
[ 3.733171] md: zone0=[sda3/sdd3/sde3]
[ 3.739588] md: bind<sda1>
[ 3.759253] md: raid1 personality registered for level 1
[ 3.759429] md/raid1:md0: active with 4 out of 4 mirrors
[ 3.918565] md: array md3 already has disks!
[ 3.918697] md: bind<md2>
[ 3.919332] md: linear personality registered for level -1
[ 2733.499792] md: bind<sdb1>
[ 2735.135587] md: bind<sdf1>
[ 2735.256588] md: bind<sdg1>
[ 2735.402403] md: could not open unknown-block(8,81).
[ 2735.402412] md: md_import_device returned -16
[ 2735.402428] md: could not open unknown-block(8,81).
[ 2735.402432] md: md_import_device returned -16
[ 2735.447468] md: bind<sdh1>
[ 2735.741173] md: recovery of RAID array md0
[ 2735.741174] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 2735.741175] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for recovery.
[ 2735.741183] md: using 128k
window, over a total of 96256k.
[ 2745.098791] md: md0: recovery done.
[ 2779.774452] md: bind<sdb2>
[ 2779.887067] md: bind<sdf2>
[ 2780.051949] md: bind<sdg2>
[ 2780.162323] md: bind<sdh2>
[ 2780.559396] md: reshape of RAID array md1
[ 2780.559399] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 2780.559400] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for reshape.
[ 2780.559408] md: using 128k window, over a total of 205077632k.
(note: I have already tried adjusting the minimum speed)
/proc/mdstat is looking like this:
Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [linear]
md2 : active raid0 sda3[0] sde3[2] sdd3[1]
117064704 blocks super 1.2 512k chunks
md3 : active linear md2[0] sdc3[1]
400277156 blocks super 1.2 0k rounding
md0 : active raid1 sdh1[4] sdg1[5] sdf1[6] sdb1[7] sda1[0] sde1[3]
sdd1[1] sdc1[ 2]
96256 blocks [8/8] [UUUUUUUU]
bitmap: 0/12 pages [0KB], 4KB chunk
md1 : active raid6 sdh2[4] sdg2[5] sdf2[6] sdb2[7] sda2[0] sdc2[1]
sdd2[2] sde2[ 3]
410155264 blocks super 0.91 level 6, 64k chunk, algorithm 2 [8/8]
[UUUUUUU U]
[>....................] reshape = 0.0% (0/205077632)
finish=39282834032. 1min speed=0K/sec
bitmap: 10/196 pages [40KB], 512KB chunk
unused devices: <none>
mdadm --detail /dev/md1 gives:
/dev/md1:
Version : 0.91
Creation Time : Sat Oct 4 15:01:57 2008
Raid Level : raid6
Array Size : 410155264 (391.15 GiB 420.00 GB)
Used Dev Size : 205077632 (195.58 GiB 210.00 GB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 1
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Oct 14 18:09:32 2015
State : clean, reshaping
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Reshape Status : 0% complete
Delta Devices : 4, (4->8)
UUID : 7b4ddd0f:d04e8dbf:93c13954:ca72c56a
Events : 0.5558446
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 34 1 active sync /dev/sdc2
2 8 50 2 active sync /dev/sdd2
3 8 66 3 active sync /dev/sde2
4 8 114 4 active sync /dev/sdh2
5 8 98 5 active sync /dev/sdg2
6 8 82 6 active sync /dev/sdf2
7 8 18 7 active sync /dev/sdb2
What can I safely do to move this along?
--
Phil Reynolds
mail: phil@tinsleyviaduct.com
Web: http://phil.tinsleyviaduct.com/
^ permalink raw reply
* Re: First 12Mb of data missing after accidental deletion of first drive (4 2TB raid5)
From: Benjamin ESTRABAUD @ 2015-10-14 10:48 UTC (permalink / raw)
To: Adam Goryachev, Marek, Weedy; +Cc: Linux RAID, Alexander Afonyashin
In-Reply-To: <561DA4DC.1080804@websitemanagers.com.au>
On 14/10/15 01:42, Adam Goryachev wrote:
> On 14/10/15 05:09, Benjamin ESTRABAUD wrote:
>> Hi Marek,
>>
>> On 13/10/15 16:04, Marek wrote:
>>> Could it be that the raid wasnt synced at the time i overwrote
>>> /dev/sda ? i have run the command you suggested and will report after
>>> its done. would it still be possible to recover the raid?
>>>
>> So what likely happened is that you wrote ontop of a RAID member drive
>> while the RAID was likely not assembled (during your install).
>>
>> If you do a resync it won't unfortunately *recover* the previously
>> written data, it will go over each stripe and recalculate the parity.
>> It is true that it *might* have been possible to do the opposite
>> operation by not touching anything and figuring out the previous data
>> with the data and parity blocks from the remaining RAID members
>> (assuming they weren't overwritten), but it would have been a tricky
>> operation. However, since you've done the resync now, the previous
>> parity blocks have been overwritten leaving you with a consistent
>> RAID, but with part of the data on a disk that you want to revert.
>>
> Or better action would be to stop the array, start the array excluding
> sda (not sure best way to manually mark it failed, or maybe physically
> remove it, or zero superblock should work too). Then you should have
> clean degraded array with all data. Now you could add sda back, and it
> will re-write correct data. (Assuming no writes were done to sdb/sdc/sdd).
>
I agree with Adam, in this particular case the data would be recovered
on "sda". Doing a plain and simple resync with the array not degraded
would do another operation which is precisely what you don't want, i.e.
make sure that the parity are recalculated from the current data.
> Depending on what you actually did, and what order, it might still work....
>
If the resync didn't run while sda was in the array it should, otherwise
the data recalculated on sda will be identical to the current data.
> Regards,
> Adam
>
>> At this stage you should recover the old data from a backup.
>>
>>> On Tue, Oct 13, 2015 at 4:36 PM, Weedy <weedy2887@gmail.com> wrote:
>>>>
>>>> On 13 Oct 2015 10:06 am, "Marek" <mlf.conv@gmail.com> wrote:
>>>>>
>>>>> no, i had a working raid consisting of 4 2TB drives (raid5)
>>>>> sda,sdb,sdc,sdb ( no partitions were created on drives) - then i
>>>>> accidentally deleted /dev/sda by installing ubuntu. when inspecting
>>>>> dev/md127 with a hex editor i discovered first 12mb are missing.
>>>>
>>>> Wait, if it's a raid5 can't you just resync it?
>>>>
>>>> Also I believe 1.2 metadata is at the end of a partition. If your
>>>> saying the
>>>> raids hasn't noticed you can run a check and it should fix itself.
>>>>
>>>> echo check > /sys/block/mdX/md/sync_action
>>> --
>>> 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
>
>
^ permalink raw reply
* Re: First 12Mb of data missing after accidental deletion of first drive (4 2TB raid5)
From: Adam Goryachev @ 2015-10-14 0:42 UTC (permalink / raw)
To: Benjamin ESTRABAUD, Marek, Weedy; +Cc: Linux RAID, Alexander Afonyashin
In-Reply-To: <561D48F6.6010106@mpstor.com>
On 14/10/15 05:09, Benjamin ESTRABAUD wrote:
> Hi Marek,
>
> On 13/10/15 16:04, Marek wrote:
>> Could it be that the raid wasnt synced at the time i overwrote
>> /dev/sda ? i have run the command you suggested and will report after
>> its done. would it still be possible to recover the raid?
>>
> So what likely happened is that you wrote ontop of a RAID member drive
> while the RAID was likely not assembled (during your install).
>
> If you do a resync it won't unfortunately *recover* the previously
> written data, it will go over each stripe and recalculate the parity.
> It is true that it *might* have been possible to do the opposite
> operation by not touching anything and figuring out the previous data
> with the data and parity blocks from the remaining RAID members
> (assuming they weren't overwritten), but it would have been a tricky
> operation. However, since you've done the resync now, the previous
> parity blocks have been overwritten leaving you with a consistent
> RAID, but with part of the data on a disk that you want to revert.
>
Or better action would be to stop the array, start the array excluding
sda (not sure best way to manually mark it failed, or maybe physically
remove it, or zero superblock should work too). Then you should have
clean degraded array with all data. Now you could add sda back, and it
will re-write correct data. (Assuming no writes were done to sdb/sdc/sdd).
Depending on what you actually did, and what order, it might still work....
Regards,
Adam
> At this stage you should recover the old data from a backup.
>
>> On Tue, Oct 13, 2015 at 4:36 PM, Weedy <weedy2887@gmail.com> wrote:
>>>
>>> On 13 Oct 2015 10:06 am, "Marek" <mlf.conv@gmail.com> wrote:
>>>>
>>>> no, i had a working raid consisting of 4 2TB drives (raid5)
>>>> sda,sdb,sdc,sdb ( no partitions were created on drives) - then i
>>>> accidentally deleted /dev/sda by installing ubuntu. when inspecting
>>>> dev/md127 with a hex editor i discovered first 12mb are missing.
>>>
>>> Wait, if it's a raid5 can't you just resync it?
>>>
>>> Also I believe 1.2 metadata is at the end of a partition. If your
>>> saying the
>>> raids hasn't noticed you can run a check and it should fix itself.
>>>
>>> echo check > /sys/block/mdX/md/sync_action
>> --
>> 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
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: [PATCH 0/9] raid5-cache fixes
From: Neil Brown @ 2015-10-13 21:03 UTC (permalink / raw)
To: Shaohua Li, linux-raid; +Cc: Kernel-team, songliubraving, hch, dan.j.williams
In-Reply-To: <cover.1444360850.git.shli@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
Shaohua Li <shli@fb.com> writes:
> Hi,
>
> some fixes for raid5-cache/md. Mainly supports trim, handle IO error and
> handling array assemble with missing/faulty disks.
> patch 1: fix a bug
> patch 2: support trim
> patch 3-4, IO error handling
> patch 5-9, handle assemble issue when journal disk is missing/faulty
>
> If there is IO error to journal disk, write IO will fail immediately. If we
> assemble an array with journal feature enabled but with journal disk
> missing/faulty, the raid array will start readonly.
>
> Thanks,
> Shaohua
>
> Shaohua Li (6):
> MD: fix info output for journal disk
> raid5-cache: add trim support for log
> raid5: journal disk can't be removed
> raid5-cache: IO error handling
> raid5-cache: start raid5 readonly if journal is missing
> MD: set journal disk ->raid_disk
>
> Song Liu (3):
> MD: add new bit to indicate raid array with journal
> MD: kick out journal disk if it's not fresh
> MD: when RAID journal is missing/faulty, block RESTART_ARRAY_RW
>
Thanks,
I've applied all of these.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH V2] MD: fix info output for journal disk
From: Neil Brown @ 2015-10-13 20:50 UTC (permalink / raw)
To: Shaohua Li, linux-raid; +Cc: Kernel-team, songliubraving, hch, dan.j.williams
In-Reply-To: <6e6d9cd5bc79883cfb22a62b9bdc98b161aad301.1444694209.git.shli@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Shaohua Li <shli@fb.com> writes:
> journal disk can be faulty. The Journal and Faulty aren't exclusive with
> each other.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/md/md.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 0729cc7..f1114a6 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -5857,7 +5857,8 @@ static int get_disk_info(struct mddev *mddev, void __user * arg)
> else if (test_bit(In_sync, &rdev->flags)) {
> info.state |= (1<<MD_DISK_ACTIVE);
> info.state |= (1<<MD_DISK_SYNC);
> - } else if (test_bit(Journal, &rdev->flags))
> + }
> + if (test_bit(Journal, &rdev->flags))
> info.state |= (1<<MD_DISK_JOURNAL);
> if (test_bit(WriteMostly, &rdev->flags))
> info.state |= (1<<MD_DISK_WRITEMOSTLY);
> @@ -7339,14 +7340,12 @@ static int md_seq_show(struct seq_file *seq, void *v)
> bdevname(rdev->bdev,b), rdev->desc_nr);
> if (test_bit(WriteMostly, &rdev->flags))
> seq_printf(seq, "(W)");
> + if (test_bit(Journal, &rdev->flags))
> + seq_printf(seq, "(J)");
> if (test_bit(Faulty, &rdev->flags)) {
> seq_printf(seq, "(F)");
> continue;
> }
> - if (test_bit(Journal, &rdev->flags)) {
> - seq_printf(seq, "(J)");
> - continue;
> - }
> if (rdev->raid_disk < 0)
> seq_printf(seq, "(S)"); /* spare */
> if (test_bit(Replacement, &rdev->flags))
> --
> 2.4.6
Applied, thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] md: don't export log device
From: Neil Brown @ 2015-10-13 20:41 UTC (permalink / raw)
Cc: Shaohua Li, linux-raid, Kernel-team, songliubraving, hch,
dan.j.williams
In-Reply-To: <20151013120719.GA9734@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
Christoph Hellwig <hch@infradead.org> writes:
> On Thu, Oct 08, 2015 at 05:04:54PM +1100, Neil Brown wrote:
>> Having two disks with ->raid_disk==0 does seem a little weird, but we do
>> already have that in some cases.
>> When you have a hot-replace going, both the original and the replacement
>> have the same ->raid_disk numbers. They can be distinguished by the
>> Replacement flag.
>> I'm suggesting the same (sort of) for journals, and distinguish by the
>> Journal flag.
>>
>> I did quick audit and just found setup_conf, run() and md_update_sb().
>> If you could do an audit to that would be good. I'd be surprised if you
>> find many more places where Journal needs to be tested with ->raid_disk.
>
> Overloading positive numbers for the journal disk sounds like a bad idea
> to me as it will cause a lot of confusion. I'd rather assign specific
> negative values to special roles outside the actual rate. This will
> require an initial audit, but give us nicely understandable rules later
> on.
The positive numbers are in different name-spaces:
primary raid disks
replacement raid disks
journal disks
While confusion is always possible, I think keeping these separate is
not that hart. For example ->raid_disk is primarily used to place the
rdev in an array after which it is the position in the array which is
primarily used. The value of ->raid_disk is mostly tested only for
whether it is <0 or not.
I'm certainly happy to do our best to remove sources of confusion from
the user-space view of these numbers (e.g. put 'journal' or 'none' in
the 'slot' file, not '0' (and definitely not "-5")). But internally to
the kernel it is important to remember that it isn't a primary key - and
once you do that there is not much chance of confusion.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] selinux: Add support for unprivileged mounts from user namespaces
From: Stephen Smalley @ 2015-10-13 20:27 UTC (permalink / raw)
To: Seth Forshee, Eric W. Biederman, Paul Moore, Eric Paris
Cc: linux-bcache, Serge Hallyn, James Morris, dm-devel, linux-kernel,
Andy Lutomirski, linux-raid, linux-security-module, linux-mtd,
Alexander Viro, selinux, linux-fsdevel
In-Reply-To: <1444755861-54997-6-git-send-email-seth.forshee@canonical.com>
On 10/13/2015 01:04 PM, Seth Forshee wrote:
> Security labels from unprivileged mounts in user namespaces must
> be ignored. Force superblocks from user namespaces whose labeling
> behavior is to use xattrs to use mountpoint labeling instead.
> For the mountpoint label, default to converting the current task
> context into a form suitable for file objects, but also allow the
> policy writer to specify a different label through policy
> transition rules.
>
> Pieced together from code snippets provided by Stephen Smalley.
>
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> security/selinux/hooks.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index de05207eb665..09be1dc21e58 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -756,6 +756,28 @@ static int selinux_set_mnt_opts(struct super_block *sb,
> goto out;
> }
> }
> +
> + /*
> + * If this is a user namespace mount, no contexts are allowed
> + * on the command line and security labels must be ignored.
> + */
> + if (sb->s_user_ns != &init_user_ns) {
> + if (context_sid || fscontext_sid || rootcontext_sid ||
> + defcontext_sid) {
> + rc = -EACCES;
> + goto out;
> + }
> + if (sbsec->behavior == SECURITY_FS_USE_XATTR) {
> + sbsec->behavior = SECURITY_FS_USE_MNTPOINT;
> + rc = security_transition_sid(current_sid(), current_sid(),
> + SECCLASS_FILE, NULL,
> + &sbsec->mntpoint_sid);
> + if (rc)
> + goto out;
> + }
> + goto out_set_opts;
> + }
> +
> /* sets the context of the superblock for the fs being mounted. */
> if (fscontext_sid) {
> rc = may_context_mount_sb_relabel(fscontext_sid, sbsec, cred);
> @@ -824,6 +846,7 @@ static int selinux_set_mnt_opts(struct super_block *sb,
> sbsec->def_sid = defcontext_sid;
> }
>
> +out_set_opts:
> rc = sb_finish_set_opts(sb);
> out:
> mutex_unlock(&sbsec->lock);
>
^ permalink raw reply
* Re: [PATCH 00/14] md-cluster: A better way for METADATA_UPDATED processing
From: Neil Brown @ 2015-10-13 20:12 UTC (permalink / raw)
To: rgoldwyn, linux-raid; +Cc: gqjiang
In-Reply-To: <1444746335-22624-1-git-send-email-rgoldwyn@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
rgoldwyn@suse.de writes:
> The processing of METADATA_UPDATED message is too simple and prone to
> errors. Besides, it would not update the internal data structures as
> required.
>
> This set of patches reads the superblock from one of the device of the MD
> and checks for changes in the in-memory data structures. If there is a change,
> it performs the necessary actions to keep the internal data structures
> as it would be in the primary node.
>
> An example is if a devices turns faulty. The algorithm is:
>
> 1. The initiator node marks the device as faulty and updates the superblock
> 2. The initiator node sends METADATA_UPDATED with an advisory device number to the rest of the nodes.
> 3. The receiving node on receiving the METADATA_UPDATED message
> 3.1 Reads the superblock
> 3.2 Detects a device has failed by comparing with memory structure
> 3.3 Calls the necessary functions to record the failure and get the device out of the active array.
> 3.4 Acknowledges the message.
>
> The patch series also fixes adding the disk which was impacted because of
> the changes.
>
> Patches can also be found at
> https://github.com/goldwynr/linux branch md-next
>
> Changes since V2:
> - Fix status synchrnoization after --add and --re-add operations
> - Included Guoqing's patches on endian correctness, zeroing cmsg etc
> - Restructure add_new_disk() and cancel()
Thanks a lots. Looks good.
I have pull all this in and will push it out shortly.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 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