* Re: [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function
From: Harsh Jain @ 2017-04-15 4:53 UTC (permalink / raw)
To: Logan Gunthorpe, harsh-ut6Up61K2wZBDgjK7y7TUQ
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, netdev@
In-Reply-To: <1492121135-4437-9-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> wrote:
> The get_page in this area looks *highly* suspect due to there being no
> corresponding put_page. However, I've left that as is to avoid breaking
> things.
chcr driver will post the request to LLD driver cxgb4 and put_page is
implemented there. it will no harm. Any how
we have removed the below code from driver.
http://www.mail-archive.com/linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg24561.html
After this merge we can ignore your patch. Thanks
>
> I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead
> code that dates back to when it was first committed...
>
> Signed-off-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
> ---
> drivers/crypto/chelsio/chcr_algo.c | 28 +++++++++++++++-------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
> index 41bc7f4..a993d1d 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -1489,22 +1489,21 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
> return ERR_PTR(-EINVAL);
> }
>
> -static void aes_gcm_empty_pld_pad(struct scatterlist *sg,
> - unsigned short offset)
> +static int aes_gcm_empty_pld_pad(struct scatterlist *sg,
> + unsigned short offset)
> {
> - struct page *spage;
> unsigned char *addr;
>
> - spage = sg_page(sg);
> - get_page(spage); /* so that it is not freed by NIC */
> -#ifdef KMAP_ATOMIC_ARGS
> - addr = kmap_atomic(spage, KM_SOFTIRQ0);
> -#else
> - addr = kmap_atomic(spage);
> -#endif
> - memset(addr + sg->offset, 0, offset + 1);
> + get_page(sg_page(sg)); /* so that it is not freed by NIC */
> +
> + addr = sg_map(sg, SG_KMAP_ATOMIC);
> + if (IS_ERR(addr))
> + return PTR_ERR(addr);
> +
> + memset(addr, 0, offset + 1);
> + sg_unmap(sg, addr, SG_KMAP_ATOMIC);
>
> - kunmap_atomic(addr);
> + return 0;
> }
>
> static int set_msg_len(u8 *block, unsigned int msglen, int csize)
> @@ -1940,7 +1939,10 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
> if (req->cryptlen) {
> write_sg_to_skb(skb, &frags, src, req->cryptlen);
> } else {
> - aes_gcm_empty_pld_pad(req->dst, authsize - 1);
> + err = aes_gcm_empty_pld_pad(req->dst, authsize - 1);
> + if (err)
> + goto dstmap_fail;
> +
> write_sg_to_skb(skb, &frags, reqctx->dst, crypt_len);
>
> }
> --
> 2.1.4
>
^ permalink raw reply
* Re: [md PATCH] md: handle read-only member devices better.
From: NeilBrown @ 2017-04-15 4:45 UTC (permalink / raw)
To: Shaohua Li; +Cc: Linux-RAID, Nanda Kishore Chinnaram
In-Reply-To: <20170413054723.2spvhtze6bljkaop@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]
On Wed, Apr 12 2017, Shaohua Li wrote:
> On Thu, Apr 13, 2017 at 08:53:48AM +1000, Neil Brown wrote:
>>
>> 1/ If an array has any read-only devices when it is started,
>> the array itself must be read-only
>> 2/ A read-only device cannot be added to an array after it is
>> started.
>> 3/ Setting an array to read-write should not succeed
>> if any member devices are read-only
>
> Didn't get these. We call md_import_device() first to open under layer disk. We
> always use FMOD_READ|FMOD_WRITE to open the disk. So if the disk is ro,
> md_import_device should fail, we don't add the disk to the array. Why would we
> have such issues?
>
Because life isn't always as simple as we might like it to be. :-(
md_import_device() calls lock_rdev() which calls blkdev_get_by_dev().
blkdev_get_by_dev() doesn't pay much attention to the mode, nor does
blkdev_get() which it calls. The main place where FMODE_WRITE could be
rejected on a read-only device is in the device's 'open()' function. A
few open functions do check for read-only, but it isn't at all
consistent.
scsi/sd.c does, block/loop.c doesn't, nor does nvme. Most drivers seem
to ignore the mode.
blkdev_get_by_path() has
if ((mode & FMODE_WRITE) && bdev_read_only(bdev)) {
blkdev_put(bdev, mode);
return ERR_PTR(-EACCES);
}
so when you open a device by path name you always get this check, but
not when you open a device by device-number like md does.
It is worth having a look at
Commit: e51900f7d38c ("block: revert block_dev read-only check")
from 2011. The bdev_read_only() check was in blkdev_get() for a while,
but it was moved out because doing that broke md and dm and others.
So at present, callers of blkdev_get_by_dev() need to do their own
bdev_read_only() tests before writing.
We could discuss where in md.c is the best place to put them, but unless
you want to take on a largish project to 'fix' (or audit) all callers of
blkdev_get_by_dev(), they need to go in md somewhere.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* 31187 linux-raid
From: citydesk @ 2017-04-14 19:52 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: 04563488649164.zip --]
[-- Type: application/zip, Size: 4110 bytes --]
^ permalink raw reply
* Re: Linux software raid troubles
From: Anthony Youngman @ 2017-04-14 19:23 UTC (permalink / raw)
To: linuxknight, David C. Rankin; +Cc: mdraid
In-Reply-To: <CAAO=44YCU+OF-xBytuMCHEtV7WbHE6EVyJ_9ncGmM9VNWcj9MA@mail.gmail.com>
On 14/04/17 16:01, linuxknight wrote:
> One last question, is it acceptable to let graphical installers setup
> the software raid for me or should I use one disk and create a raid
> mirror later once the OS is setup?
Can't give you any advice on how to do it, but I'd be inclined to create
one huge array using all your disks. For each physical disk, one
partition for UEFI or grub, possibly a second partition for a mirrored
root partition, then all the rest for a raid array with LVM on top.
I'm hoping to build a new system set up like that, but that's probably a
few months down the line.
Oh - and using the installer to set it up is probably going to be a
nightmare. My experience is gentoo, which expects me to set it up
manually, or SuSE which was a pain setting up custom partitioning.
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-14 16:12 UTC (permalink / raw)
To: Kershner, David A, Christoph Hellwig, Martin K. Petersen,
Sagi Grimberg, Jens Axboe, Tejun Heo, Greg Kroah-Hartman,
Dan Williams, Ross Zwisler, Matthew Wilcox, Sumit Semwal,
Ming Lin, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-raid
Cc: Steve Wise
In-Reply-To: <CY4PR07MB317691139A5B2F902CDA9B0EF0050-tf0iTMRrrlgs/z/azo2A2OFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Great, thanks!
Logan
On 14/04/17 10:07 AM, Kershner, David A wrote:
> Can you add Acked-by for this patch?
>
> Acked-by: David Kershner <david.kershner-GLv8BlqOqDDQT0dZR+AlfA@public.gmane.org>
>
> Tested on s-Par and no problems.
>
> Thanks,
> David Kershner
>
>> ---
>> drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
>> b/drivers/staging/unisys/visorhba/visorhba_main.c
>> index 0ce92c8..2d8c8bc 100644
>> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
>> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
>> @@ -842,7 +842,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
>> scsi_cmnd *scsicmd)
>> struct scatterlist *sg;
>> unsigned int i;
>> char *this_page;
>> - char *this_page_orig;
>> int bufind = 0;
>> struct visordisk_info *vdisk;
>> struct visorhba_devdata *devdata;
>> @@ -869,11 +868,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp,
>> struct scsi_cmnd *scsicmd)
>>
>> sg = scsi_sglist(scsicmd);
>> for (i = 0; i < scsi_sg_count(scsicmd); i++) {
>> - this_page_orig = kmap_atomic(sg_page(sg + i));
>> - this_page = (void *)((unsigned long)this_page_orig |
>> - sg[i].offset);
>> + this_page = sg_map(sg + i, SG_KMAP_ATOMIC);
>> + if (IS_ERR(this_page)) {
>> + scsicmd->result = DID_ERROR << 16;
>> + return;
>> + }
>> +
>> memcpy(this_page, buf + bufind, sg[i].length);
>> - kunmap_atomic(this_page_orig);
>> + sg_unmap(sg + i, this_page, SG_KMAP_ATOMIC);
>> }
>> } else {
>> devdata = (struct visorhba_devdata *)scsidev->host-
>>> hostdata;
>> --
>> 2.1.4
>
^ permalink raw reply
* Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)
From: Logan Gunthorpe @ 2017-04-14 16:09 UTC (permalink / raw)
To: Julia Lawall
Cc: kbuild-all-JC7UmRfGjtg, Steve Wise,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-crypto
In-Reply-To: <alpine.DEB.2.20.1704141717510.3212@hadrien>
Thanks Julia. I missed that and I'll fix it in my series.
Logan
On 14/04/17 09:19 AM, Julia Lawall wrote:
> It looks like &udev->cmdr_lock should be released at line 512 if it has
> not been released otherwise. The lock was taken at line 438.
>
> julia
>
> ---------- Forwarded message ----------
> Date: Fri, 14 Apr 2017 22:21:44 +0800
> From: kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> To: kbuild-JC7UmRfGjtg@public.gmane.org
> Cc: Julia Lawall <julia.lawall-L2FTfq7BK8M@public.gmane.org>
> Subject: Re: [PATCH 04/22] target: Make use of the new sg_map function at 16
> call sites
>
> Hi Logan,
>
> [auto build test WARNING on scsi/for-next]
> [also build test WARNING on v4.11-rc6]
> [cannot apply to next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> :::::: branch date: 8 hours ago
> :::::: commit date: 8 hours ago
>
>>> drivers/target/target_core_user.c:512:2-8: preceding lock on line 438
> drivers/target/target_core_user.c:512:2-8: preceding lock on line 471
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 78082134e7afdc59d744eb8d2def5c588e89c378
> vim +512 drivers/target/target_core_user.c
>
> 7c9e7a6f Andy Grover 2014-10-01 432 sizeof(struct tcmu_cmd_entry));
> 7c9e7a6f Andy Grover 2014-10-01 433 command_size = base_command_size
> 7c9e7a6f Andy Grover 2014-10-01 434 + round_up(scsi_command_size(se_cmd->t_task_cdb), TCMU_OP_ALIGN_SIZE);
> 7c9e7a6f Andy Grover 2014-10-01 435
> 7c9e7a6f Andy Grover 2014-10-01 436 WARN_ON(command_size & (TCMU_OP_ALIGN_SIZE-1));
> 7c9e7a6f Andy Grover 2014-10-01 437
> 7c9e7a6f Andy Grover 2014-10-01 @438 spin_lock_irq(&udev->cmdr_lock);
> 7c9e7a6f Andy Grover 2014-10-01 439
> 7c9e7a6f Andy Grover 2014-10-01 440 mb = udev->mb_addr;
> 7c9e7a6f Andy Grover 2014-10-01 441 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
> 26418649 Sheng Yang 2016-02-26 442 data_length = se_cmd->data_length;
> 26418649 Sheng Yang 2016-02-26 443 if (se_cmd->se_cmd_flags & SCF_BIDI) {
> 26418649 Sheng Yang 2016-02-26 444 BUG_ON(!(se_cmd->t_bidi_data_sg && se_cmd->t_bidi_data_nents));
> 26418649 Sheng Yang 2016-02-26 445 data_length += se_cmd->t_bidi_data_sg->length;
> 26418649 Sheng Yang 2016-02-26 446 }
> 554617b2 Andy Grover 2016-08-25 447 if ((command_size > (udev->cmdr_size / 2)) ||
> 554617b2 Andy Grover 2016-08-25 448 data_length > udev->data_size) {
> 554617b2 Andy Grover 2016-08-25 449 pr_warn("TCMU: Request of size %zu/%zu is too big for %u/%zu "
> 3d9b9555 Andy Grover 2016-08-25 450 "cmd ring/data area\n", command_size, data_length,
> 7c9e7a6f Andy Grover 2014-10-01 451 udev->cmdr_size, udev->data_size);
> 554617b2 Andy Grover 2016-08-25 452 spin_unlock_irq(&udev->cmdr_lock);
> 554617b2 Andy Grover 2016-08-25 453 return TCM_INVALID_CDB_FIELD;
> 554617b2 Andy Grover 2016-08-25 454 }
> 7c9e7a6f Andy Grover 2014-10-01 455
> 26418649 Sheng Yang 2016-02-26 456 while (!is_ring_space_avail(udev, command_size, data_length)) {
> 7c9e7a6f Andy Grover 2014-10-01 457 int ret;
> 7c9e7a6f Andy Grover 2014-10-01 458 DEFINE_WAIT(__wait);
> 7c9e7a6f Andy Grover 2014-10-01 459
> 7c9e7a6f Andy Grover 2014-10-01 460 prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
> 7c9e7a6f Andy Grover 2014-10-01 461
> 7c9e7a6f Andy Grover 2014-10-01 462 pr_debug("sleeping for ring space\n");
> 7c9e7a6f Andy Grover 2014-10-01 463 spin_unlock_irq(&udev->cmdr_lock);
> 7c9e7a6f Andy Grover 2014-10-01 464 ret = schedule_timeout(msecs_to_jiffies(TCMU_TIME_OUT));
> 7c9e7a6f Andy Grover 2014-10-01 465 finish_wait(&udev->wait_cmdr, &__wait);
> 7c9e7a6f Andy Grover 2014-10-01 466 if (!ret) {
> 7c9e7a6f Andy Grover 2014-10-01 467 pr_warn("tcmu: command timed out\n");
> 02eb924f Andy Grover 2016-10-06 468 return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
> 7c9e7a6f Andy Grover 2014-10-01 469 }
> 7c9e7a6f Andy Grover 2014-10-01 470
> 7c9e7a6f Andy Grover 2014-10-01 471 spin_lock_irq(&udev->cmdr_lock);
> 7c9e7a6f Andy Grover 2014-10-01 472
> 7c9e7a6f Andy Grover 2014-10-01 473 /* We dropped cmdr_lock, cmd_head is stale */
> 7c9e7a6f Andy Grover 2014-10-01 474 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
> 7c9e7a6f Andy Grover 2014-10-01 475 }
> 7c9e7a6f Andy Grover 2014-10-01 476
> f56574a2 Andy Grover 2014-10-02 477 /* Insert a PAD if end-of-ring space is too small */
> f56574a2 Andy Grover 2014-10-02 478 if (head_to_end(cmd_head, udev->cmdr_size) < command_size) {
> f56574a2 Andy Grover 2014-10-02 479 size_t pad_size = head_to_end(cmd_head, udev->cmdr_size);
> f56574a2 Andy Grover 2014-10-02 480
> 7c9e7a6f Andy Grover 2014-10-01 481 entry = (void *) mb + CMDR_OFF + cmd_head;
> 7c9e7a6f Andy Grover 2014-10-01 482 tcmu_flush_dcache_range(entry, sizeof(*entry));
> 0ad46af8 Andy Grover 2015-04-14 483 tcmu_hdr_set_op(&entry->hdr.len_op, TCMU_OP_PAD);
> 0ad46af8 Andy Grover 2015-04-14 484 tcmu_hdr_set_len(&entry->hdr.len_op, pad_size);
> 0ad46af8 Andy Grover 2015-04-14 485 entry->hdr.cmd_id = 0; /* not used for PAD */
> 0ad46af8 Andy Grover 2015-04-14 486 entry->hdr.kflags = 0;
> 0ad46af8 Andy Grover 2015-04-14 487 entry->hdr.uflags = 0;
> 7c9e7a6f Andy Grover 2014-10-01 488
> 7c9e7a6f Andy Grover 2014-10-01 489 UPDATE_HEAD(mb->cmd_head, pad_size, udev->cmdr_size);
> 7c9e7a6f Andy Grover 2014-10-01 490
> 7c9e7a6f Andy Grover 2014-10-01 491 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
> 7c9e7a6f Andy Grover 2014-10-01 492 WARN_ON(cmd_head != 0);
> 7c9e7a6f Andy Grover 2014-10-01 493 }
> 7c9e7a6f Andy Grover 2014-10-01 494
> 7c9e7a6f Andy Grover 2014-10-01 495 entry = (void *) mb + CMDR_OFF + cmd_head;
> 7c9e7a6f Andy Grover 2014-10-01 496 tcmu_flush_dcache_range(entry, sizeof(*entry));
> 0ad46af8 Andy Grover 2015-04-14 497 tcmu_hdr_set_op(&entry->hdr.len_op, TCMU_OP_CMD);
> 0ad46af8 Andy Grover 2015-04-14 498 tcmu_hdr_set_len(&entry->hdr.len_op, command_size);
> 0ad46af8 Andy Grover 2015-04-14 499 entry->hdr.cmd_id = tcmu_cmd->cmd_id;
> 0ad46af8 Andy Grover 2015-04-14 500 entry->hdr.kflags = 0;
> 0ad46af8 Andy Grover 2015-04-14 501 entry->hdr.uflags = 0;
> 7c9e7a6f Andy Grover 2014-10-01 502
> 26418649 Sheng Yang 2016-02-26 503 bitmap_copy(old_bitmap, udev->data_bitmap, DATA_BLOCK_BITS);
> 26418649 Sheng Yang 2016-02-26 504
> 3d9b9555 Andy Grover 2016-08-25 505 /* Handle allocating space from the data area */
> 7c9e7a6f Andy Grover 2014-10-01 506 iov = &entry->req.iov[0];
> f97ec7db Ilias Tsitsimpis 2015-04-23 507 iov_cnt = 0;
> e4648b01 Ilias Tsitsimpis 2015-04-23 508 copy_to_data_area = (se_cmd->data_direction == DMA_TO_DEVICE
> e4648b01 Ilias Tsitsimpis 2015-04-23 509 || se_cmd->se_cmd_flags & SCF_BIDI);
> 78082134 Logan Gunthorpe 2017-04-13 510 if (alloc_and_scatter_data_area(udev, se_cmd->t_data_sg,
> 78082134 Logan Gunthorpe 2017-04-13 511 se_cmd->t_data_nents, &iov, &iov_cnt, copy_to_data_area))
> 78082134 Logan Gunthorpe 2017-04-13 @512 return TCM_OUT_OF_RESOURCES;
> 78082134 Logan Gunthorpe 2017-04-13 513
> 7c9e7a6f Andy Grover 2014-10-01 514 entry->req.iov_cnt = iov_cnt;
> 0ad46af8 Andy Grover 2015-04-14 515 entry->req.iov_dif_cnt = 0;
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* RE: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function
From: Kershner, David A @ 2017-04-14 16:07 UTC (permalink / raw)
To: Logan Gunthorpe, Christoph Hellwig, Martin K. Petersen,
Sagi Grimberg, Jens Axboe, Tejun Heo, Greg Kroah-Hartman,
Dan Williams, Ross Zwisler, Matthew Wilcox, Sumit Semwal,
Ming Lin, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-raid-u79uwXL29TY76Z2rM5mHXA
Cc: Steve Wise
In-Reply-To: <1492121135-4437-11-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
> -----Original Message-----
> From: Logan Gunthorpe [mailto:logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org]
...
> Subject: [PATCH 10/22] staging: unisys: visorbus: Make use of the new
> sg_map helper function
>
> Straightforward conversion to the new function.
>
> Signed-off-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
Can you add Acked-by for this patch?
Acked-by: David Kershner <david.kershner-GLv8BlqOqDDQT0dZR+AlfA@public.gmane.org>
Tested on s-Par and no problems.
Thanks,
David Kershner
> ---
> drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
> b/drivers/staging/unisys/visorhba/visorhba_main.c
> index 0ce92c8..2d8c8bc 100644
> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
> @@ -842,7 +842,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
> scsi_cmnd *scsicmd)
> struct scatterlist *sg;
> unsigned int i;
> char *this_page;
> - char *this_page_orig;
> int bufind = 0;
> struct visordisk_info *vdisk;
> struct visorhba_devdata *devdata;
> @@ -869,11 +868,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp,
> struct scsi_cmnd *scsicmd)
>
> sg = scsi_sglist(scsicmd);
> for (i = 0; i < scsi_sg_count(scsicmd); i++) {
> - this_page_orig = kmap_atomic(sg_page(sg + i));
> - this_page = (void *)((unsigned long)this_page_orig |
> - sg[i].offset);
> + this_page = sg_map(sg + i, SG_KMAP_ATOMIC);
> + if (IS_ERR(this_page)) {
> + scsicmd->result = DID_ERROR << 16;
> + return;
> + }
> +
> memcpy(this_page, buf + bufind, sg[i].length);
> - kunmap_atomic(this_page_orig);
> + sg_unmap(sg + i, this_page, SG_KMAP_ATOMIC);
> }
> } else {
> devdata = (struct visorhba_devdata *)scsidev->host-
> >hostdata;
> --
> 2.1.4
^ permalink raw reply
* Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites
From: Logan Gunthorpe @ 2017-04-14 16:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Steve Wise, linux-nvme, Stephen Bates, target-devel, Sumit Semwal,
devel, rds-devel, Sagi Grimberg, linux-scsi, Matthew Wilcox,
linux-rdma, fcoe-devel, Ross Zwisler, open-iscsi, linux-media,
Ming Lin, intel-gfx, sparmaintainer, linux-raid, dri-devel,
Dan Williams, megaraidlinux.pdl, Jens Axboe, linaro-mm-sig,
Martin K. Petersen, Greg Kroah-Hartman
In-Reply-To: <20170414083921.GC25471@lst.de>
On 14/04/17 02:39 AM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in all four spots.
>
> I think the right fix here is to switch dm-crypt to the ahash API
> that takes a scatterlist.
Hmm, well I'm not sure I understand the code enough to make that
conversion. But I was looking at it. One tricky bit seems to be that
crypt_iv_lmk_one adds a seed, skips the first 16 bytes in the page and
then hashes another 16 bytes from other data. What would you do
construct a new sgl for it and pass it to the ahash api?
The other thing is crypt_iv_lmk_post also seems to modify the page after
the hash with a crypto_xor so you'd still need at least one kmap in there.
Logan
^ permalink raw reply
* Re: Linux software raid troubles
From: Reindl Harald @ 2017-04-14 15:52 UTC (permalink / raw)
To: linuxknight, David C. Rankin; +Cc: mdraid
In-Reply-To: <CAAO=44YCU+OF-xBytuMCHEtV7WbHE6EVyJ_9ncGmM9VNWcj9MA@mail.gmail.com>
Am 14.04.2017 um 17:01 schrieb linuxknight:
> David thanks for this additional follow-up. I was mistaken about the
> LSI card, it was actually a SiL 3124. The OS didnt see the raid as
> one drive, so its another one of these fake raid cards. I did get a
> good image.so Im going to re-os this weekend and use the software raid
> method.
>
> One last question, is it acceptable to let graphical installers setup
> the software raid for me or should I use one disk and create a raid
> mirror later once the OS is setup?
the machine in front of me as installed 2011 with Fedora 9, is currently
on Fedora 25 and was installed with Anaconda since it works also as
desktop - for RAID1 a no-brainer if the installer supports it (the new
Fedora and RHEL Anaconda is horrible)
just disable any raid functionality on the mainboard so that the prots
are pure SATA ports (on HP ProLiant the controller at every reboot
whines that it is unconfigured when done right)
[root@srv-rhsoft:~]$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md0 : active raid1 sdd1[7] sdc1[4] sda1[6] sdb1[5]
511988 blocks super 1.0 [4/4] [UUUU]
md2 : active raid10 sdd3[7] sdc3[4] sdb3[5] sda3[6]
3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
md1 : active raid10 sdd2[7] sdc2[4] sda2[6] sdb2[5]
30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
unused devices: <none>
[root@srv-rhsoft:~]$ df
Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
/dev/md1 ext4 29G 6,9G 22G 24% /
/dev/md0 ext4 485M 34M 448M 7% /boot
/dev/md2 ext4 3,6T 2,3T 1,3T 64% /mnt/data
> On Fri, Apr 14, 2017 at 12:43 AM, David C. Rankin
> <drankinatty@suddenlinkmail.com> wrote:
>> On 04/12/2017 10:36 AM, linuxknight wrote:
>>> Thank you Reindl, Using your method would I be able to apply this IMG
>>> file to a fresh raid1 mirror and still have it be bootable?
>>>
>>> The reason I ask is I was looking at this guide,
>>> https://www.data-medics.com/forum/how-to-clone-a-hard-drive-with-bad-sectors-using-ddrescue-t133.html
>>> It has a method to transfer drive to drive. I was thinking I would
>>> create the fresh RAID mirror on the dedicated LSI card, then ddrescue
>>> possibly bad drive to the new raid mirror. Is this a bad idea?
>>
>> Take the dd advise, but... you initially indicated:
>>
>> <quote>
>> I was moving a server with a raid1 configuration,
>> controlled by a Intel Corporation 82801 SATA RAID Controller
>> </quote>
>>
>> Now you are saying
>>
>> <quote>
>>> It has a method to transfer drive to drive. I was thinking I would
>>> create the fresh RAID mirror on the dedicated LSI card
>> </quote>
>>
>> Note: the Intel and LSI cards may not have compatible RAID metadata. (That is
>> one of the major benefits of using linux-raid (software RAID) you are not
>> constrained by differing hardware RAID specifications.)
>>
>> You also mention "to a fresh raid1 mirror and still have it be bootable?" If
>> you image the drive with dd, the mbr or bootloader will still be present on in
>> the image and on the drive, so as long as you can tell the OS to boot from
>> that drive you should be fine (as long as the controller can access the
>> information)
>>
>> A good general howto on setting up linux-raid is
>> https://wiki.archlinux.org/index.php/RAID
^ permalink raw reply
* Re: GET_ARRAY_INFO assumptions?
From: Jes Sorensen @ 2017-04-14 15:48 UTC (permalink / raw)
To: Shaohua Li; +Cc: NeilBrown, linux-raid
In-Reply-To: <0c3633e4-df8c-c59a-17d4-917495931ba1@gmail.com>
On 04/13/2017 05:06 PM, Jes Sorensen wrote:
> On 04/13/2017 04:37 PM, Shaohua Li wrote:
>> On Thu, Apr 13, 2017 at 01:50:06PM -0400, Jes Sorensen wrote:
>>> Hi Neil,
>>>
>>> Looking at trying to phase out the ioctl usage, I am trying to
>>> introduce a
>>> helper for the 'is the array valid' situation.
>>>
>>> Now looking at places like Incremental.c (around like 557 in my current
>>> tree):
>>> /* 7b/ if yes, */
>>> /* - if number of OK devices match expected, or -R and there */
>>> /* are enough, */
>>> /* + add any bitmap file */
>>> /* + start the array (auto-readonly). */
>>>
>>> if (md_get_array_info(mdfd, &ainf) == 0) {
>>> if (c->export) {
>>> printf("MD_STARTED=already\n");
>>> } else if (c->verbose >= 0)
>>> pr_err("%s attached to %s which is already active.\n",
>>> devname, chosen_name);
>>> rv = 0;
>>> goto out_unlock;
>>> }
>>>
>>> I am wondering if there are any side effects/assumptions about
>>> GET_ARRAY_INFO that I am not considering? Basically I am making the
>>> assumption that if /sys/block/md<X>/md exists, the array is valid.
>>
>> what does 'valid' really mean? md<x>/md exists after a md device is
>> allocated,
>> the md device might not have any under layer disks bound yet.
>>
>>> The code in Incremental.c already deals with sysfs higher up in the
>>> code, so
>>> I guess the question is if the above test is even relevant anymore?
>>>
>>> Alternative, do we need export a new state in sysfs 'running'?
>>
>> I'd assume 'running' means the md device has a personality attached. See
>> array_state_show(), !running == 'clear' or 'inactive'.
>
> Good point, I guess what I am trying to figure out is what is assumed
> when ioctl(GET_ARRAY_INFO) returns 0 and how do we map it to sysfs?
Looking some more at this, it may be simpler than I thought. How about
this approach (only compile tested):
int md_array_active(int fd)
{
struct mdinfo *sra;
struct mdu_array_info_s array;
int ret;
sra = sysfs_read(fd, NULL, GET_VERSION | GET_DISKS);
if (sra) {
if (!sra->array.raid_disks &&
!(sra->array.major_version == -1 &&
sra->array.minor_version == -2))
ret = -ENODEV;
else
ret = 0;
free(sra);
} else {
ret = ioctl(fd, GET_ARRAY_INFO, &array);
}
return !ret;
}
Note 'major = -1 && minor = -2' is sysfs_read's way of saying 'external'.
This pretty much mimics what the kernel does in the ioctl handler for
GET_ARRAY_INFO:
case GET_ARRAY_INFO:
if (!mddev->raid_disks && !mddev->external)
err = -ENODEV;
else
err = get_array_info(mddev, argp);
goto out;
What do you think?
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function
From: Logan Gunthorpe @ 2017-04-14 15:37 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo
In-Reply-To: <20170414083607.GB25471-jcswGhMUV9g@public.gmane.org>
On 14/04/17 02:36 AM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote:
>> Convert the kmap and kmap_atomic uses to the sg_map function. We now
>> store the flags for the kmap instead of a boolean to indicate
>> atomicitiy. We also propogate a possible kmap error down and create
>> a new ISCSI_TCP_INTERNAL_ERR error type for this.
>
> Can you split out the new error handling into a separate prep patch
> which should go to the iscsi maintainers ASAP?
>
Yes, I can do that. I'd just have thought they'd want to see the use
case for the new error before accepting a patch like that...
Logan
^ permalink raw reply
* Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions
From: Logan Gunthorpe @ 2017-04-14 15:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo
In-Reply-To: <20170414083518.GA25471-jcswGhMUV9g@public.gmane.org>
On 14/04/17 02:35 AM, Christoph Hellwig wrote:
>> +
>> static inline int is_dma_buf_file(struct file *);
>>
>> struct dma_buf_list {
>
> I think the right fix here is to rename the operation to unmap_atomic
> and send out a little patch for that ASAP.
Ok, I can do that next week.
> I'd rather have separate functions for kmap vs kmap_atomic instead of
> the flags parameter. And while you're at it just always pass the 0
> offset parameter instead of adding a wrapper..
>
> Otherwise this looks good to me.
I settled on the flags because I thought the interface could be expanded
to do more things like automatically copy iomem to a bounce buffer (with
a flag). It'd also be possible to add things like vmap and
physical_address to the interface which would cover even more sg_page
users. All the implementations would then share the common offset
calculations, and switching between them becomes a matter of changing a
couple flags.
If you're still not convinced by the above arguments then I'll change
it but I did have reasons for choosing to do it this way.
I am fine with removing the offset versions. I will make that change.
Thanks,
Logan
^ permalink raw reply
* Re: [PATCH 1/4] mdadm/util:integrate stat operations into one utility
From: Jes Sorensen @ 2017-04-14 15:20 UTC (permalink / raw)
To: Liu Zhilong; +Cc: linux-raid
In-Reply-To: <0f6a630a-c53a-090e-67c3-8132f6d7b08e@suse.com>
On 04/14/2017 06:14 AM, Liu Zhilong wrote:
>
>
> On 04/05/2017 11:42 PM, jes.sorensen@gmail.com wrote:
>> Zhilong Liu <zlliu@suse.com> writes:
[snip]
>> For a function like this, lets name it better md_is_blkdev()
>
> How about return the devid after checking? Because always need the
> stb.st_rdev to parse
> the major and minor number. Although "util.c" has "devnm2devid" to
> gather the devid via
> to devnm, but it's convenient to return devid when check the blkdev with
> absolute path.
> would you mind the function like this?
>
> // returns dev-id when success, return 0 when failure
> dev_t stat_md_is_blkdev(char *dev)
> {
> struct stat stb;
>
> if (stat(dev, &stb) != 0) {
> pr_err("stat failed for %s: %s\n", dev, strerror(errno));
> return 0;
> }
> if ((S_IFMT & stb.st_mode) != S_IFBLK) {
> pr_err("%s is not a block device.\n", dev);
> return 0;
> }
> return stb.st_rdev;
> }
I am generally wary of too many smart handlers, but I think it makes
some sense here to de-duplicate the repeated code.
That said, your function would ditch the error information, and the
caller wouldn't know why it failed. If you made it more like this and
return the error code, plus stick the major/minor number into rdev, if
one is provided:
int stat_md_is_blkdev(char *devname, *dev_t rdev)
{
}
Jes
^ permalink raw reply
* Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)
From: Julia Lawall @ 2017-04-14 15:19 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: kbuild-all, Steve Wise, linux-nvme, Stephen Bates, target-devel,
devel, rds-devel, Sagi Grimberg, linux-scsi, Matthew Wilcox,
linux-rdma, Christoph Hellwig, fcoe-devel, Ross Zwisler,
open-iscsi, linux-media, Ming Lin, intel-gfx, sparmaintainer,
linux-raid, dri-devel, Dan Williams, megaraidlinux.pdl,
Jens Axboe, linaro-mm-sig, Martin K. Petersen, Greg Kroah-Hartman
It looks like &udev->cmdr_lock should be released at line 512 if it has
not been released otherwise. The lock was taken at line 438.
julia
---------- Forwarded message ----------
Date: Fri, 14 Apr 2017 22:21:44 +0800
From: kbuild test robot <fengguang.wu@intel.com>
To: kbuild@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: [PATCH 04/22] target: Make use of the new sg_map function at 16
call sites
Hi Logan,
[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.11-rc6]
[cannot apply to next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
:::::: branch date: 8 hours ago
:::::: commit date: 8 hours ago
>> drivers/target/target_core_user.c:512:2-8: preceding lock on line 438
drivers/target/target_core_user.c:512:2-8: preceding lock on line 471
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 78082134e7afdc59d744eb8d2def5c588e89c378
vim +512 drivers/target/target_core_user.c
7c9e7a6f Andy Grover 2014-10-01 432 sizeof(struct tcmu_cmd_entry));
7c9e7a6f Andy Grover 2014-10-01 433 command_size = base_command_size
7c9e7a6f Andy Grover 2014-10-01 434 + round_up(scsi_command_size(se_cmd->t_task_cdb), TCMU_OP_ALIGN_SIZE);
7c9e7a6f Andy Grover 2014-10-01 435
7c9e7a6f Andy Grover 2014-10-01 436 WARN_ON(command_size & (TCMU_OP_ALIGN_SIZE-1));
7c9e7a6f Andy Grover 2014-10-01 437
7c9e7a6f Andy Grover 2014-10-01 @438 spin_lock_irq(&udev->cmdr_lock);
7c9e7a6f Andy Grover 2014-10-01 439
7c9e7a6f Andy Grover 2014-10-01 440 mb = udev->mb_addr;
7c9e7a6f Andy Grover 2014-10-01 441 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
26418649 Sheng Yang 2016-02-26 442 data_length = se_cmd->data_length;
26418649 Sheng Yang 2016-02-26 443 if (se_cmd->se_cmd_flags & SCF_BIDI) {
26418649 Sheng Yang 2016-02-26 444 BUG_ON(!(se_cmd->t_bidi_data_sg && se_cmd->t_bidi_data_nents));
26418649 Sheng Yang 2016-02-26 445 data_length += se_cmd->t_bidi_data_sg->length;
26418649 Sheng Yang 2016-02-26 446 }
554617b2 Andy Grover 2016-08-25 447 if ((command_size > (udev->cmdr_size / 2)) ||
554617b2 Andy Grover 2016-08-25 448 data_length > udev->data_size) {
554617b2 Andy Grover 2016-08-25 449 pr_warn("TCMU: Request of size %zu/%zu is too big for %u/%zu "
3d9b9555 Andy Grover 2016-08-25 450 "cmd ring/data area\n", command_size, data_length,
7c9e7a6f Andy Grover 2014-10-01 451 udev->cmdr_size, udev->data_size);
554617b2 Andy Grover 2016-08-25 452 spin_unlock_irq(&udev->cmdr_lock);
554617b2 Andy Grover 2016-08-25 453 return TCM_INVALID_CDB_FIELD;
554617b2 Andy Grover 2016-08-25 454 }
7c9e7a6f Andy Grover 2014-10-01 455
26418649 Sheng Yang 2016-02-26 456 while (!is_ring_space_avail(udev, command_size, data_length)) {
7c9e7a6f Andy Grover 2014-10-01 457 int ret;
7c9e7a6f Andy Grover 2014-10-01 458 DEFINE_WAIT(__wait);
7c9e7a6f Andy Grover 2014-10-01 459
7c9e7a6f Andy Grover 2014-10-01 460 prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
7c9e7a6f Andy Grover 2014-10-01 461
7c9e7a6f Andy Grover 2014-10-01 462 pr_debug("sleeping for ring space\n");
7c9e7a6f Andy Grover 2014-10-01 463 spin_unlock_irq(&udev->cmdr_lock);
7c9e7a6f Andy Grover 2014-10-01 464 ret = schedule_timeout(msecs_to_jiffies(TCMU_TIME_OUT));
7c9e7a6f Andy Grover 2014-10-01 465 finish_wait(&udev->wait_cmdr, &__wait);
7c9e7a6f Andy Grover 2014-10-01 466 if (!ret) {
7c9e7a6f Andy Grover 2014-10-01 467 pr_warn("tcmu: command timed out\n");
02eb924f Andy Grover 2016-10-06 468 return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
7c9e7a6f Andy Grover 2014-10-01 469 }
7c9e7a6f Andy Grover 2014-10-01 470
7c9e7a6f Andy Grover 2014-10-01 471 spin_lock_irq(&udev->cmdr_lock);
7c9e7a6f Andy Grover 2014-10-01 472
7c9e7a6f Andy Grover 2014-10-01 473 /* We dropped cmdr_lock, cmd_head is stale */
7c9e7a6f Andy Grover 2014-10-01 474 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
7c9e7a6f Andy Grover 2014-10-01 475 }
7c9e7a6f Andy Grover 2014-10-01 476
f56574a2 Andy Grover 2014-10-02 477 /* Insert a PAD if end-of-ring space is too small */
f56574a2 Andy Grover 2014-10-02 478 if (head_to_end(cmd_head, udev->cmdr_size) < command_size) {
f56574a2 Andy Grover 2014-10-02 479 size_t pad_size = head_to_end(cmd_head, udev->cmdr_size);
f56574a2 Andy Grover 2014-10-02 480
7c9e7a6f Andy Grover 2014-10-01 481 entry = (void *) mb + CMDR_OFF + cmd_head;
7c9e7a6f Andy Grover 2014-10-01 482 tcmu_flush_dcache_range(entry, sizeof(*entry));
0ad46af8 Andy Grover 2015-04-14 483 tcmu_hdr_set_op(&entry->hdr.len_op, TCMU_OP_PAD);
0ad46af8 Andy Grover 2015-04-14 484 tcmu_hdr_set_len(&entry->hdr.len_op, pad_size);
0ad46af8 Andy Grover 2015-04-14 485 entry->hdr.cmd_id = 0; /* not used for PAD */
0ad46af8 Andy Grover 2015-04-14 486 entry->hdr.kflags = 0;
0ad46af8 Andy Grover 2015-04-14 487 entry->hdr.uflags = 0;
7c9e7a6f Andy Grover 2014-10-01 488
7c9e7a6f Andy Grover 2014-10-01 489 UPDATE_HEAD(mb->cmd_head, pad_size, udev->cmdr_size);
7c9e7a6f Andy Grover 2014-10-01 490
7c9e7a6f Andy Grover 2014-10-01 491 cmd_head = mb->cmd_head % udev->cmdr_size; /* UAM */
7c9e7a6f Andy Grover 2014-10-01 492 WARN_ON(cmd_head != 0);
7c9e7a6f Andy Grover 2014-10-01 493 }
7c9e7a6f Andy Grover 2014-10-01 494
7c9e7a6f Andy Grover 2014-10-01 495 entry = (void *) mb + CMDR_OFF + cmd_head;
7c9e7a6f Andy Grover 2014-10-01 496 tcmu_flush_dcache_range(entry, sizeof(*entry));
0ad46af8 Andy Grover 2015-04-14 497 tcmu_hdr_set_op(&entry->hdr.len_op, TCMU_OP_CMD);
0ad46af8 Andy Grover 2015-04-14 498 tcmu_hdr_set_len(&entry->hdr.len_op, command_size);
0ad46af8 Andy Grover 2015-04-14 499 entry->hdr.cmd_id = tcmu_cmd->cmd_id;
0ad46af8 Andy Grover 2015-04-14 500 entry->hdr.kflags = 0;
0ad46af8 Andy Grover 2015-04-14 501 entry->hdr.uflags = 0;
7c9e7a6f Andy Grover 2014-10-01 502
26418649 Sheng Yang 2016-02-26 503 bitmap_copy(old_bitmap, udev->data_bitmap, DATA_BLOCK_BITS);
26418649 Sheng Yang 2016-02-26 504
3d9b9555 Andy Grover 2016-08-25 505 /* Handle allocating space from the data area */
7c9e7a6f Andy Grover 2014-10-01 506 iov = &entry->req.iov[0];
f97ec7db Ilias Tsitsimpis 2015-04-23 507 iov_cnt = 0;
e4648b01 Ilias Tsitsimpis 2015-04-23 508 copy_to_data_area = (se_cmd->data_direction == DMA_TO_DEVICE
e4648b01 Ilias Tsitsimpis 2015-04-23 509 || se_cmd->se_cmd_flags & SCF_BIDI);
78082134 Logan Gunthorpe 2017-04-13 510 if (alloc_and_scatter_data_area(udev, se_cmd->t_data_sg,
78082134 Logan Gunthorpe 2017-04-13 511 se_cmd->t_data_nents, &iov, &iov_cnt, copy_to_data_area))
78082134 Logan Gunthorpe 2017-04-13 @512 return TCM_OUT_OF_RESOURCES;
78082134 Logan Gunthorpe 2017-04-13 513
7c9e7a6f Andy Grover 2014-10-01 514 entry->req.iov_cnt = iov_cnt;
0ad46af8 Andy Grover 2015-04-14 515 entry->req.iov_dif_cnt = 0;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Linux software raid troubles
From: linuxknight @ 2017-04-14 15:01 UTC (permalink / raw)
To: David C. Rankin; +Cc: mdraid
In-Reply-To: <d1695ac6-5912-860a-0b70-e0d9a322002e@suddenlinkmail.com>
David thanks for this additional follow-up. I was mistaken about the
LSI card, it was actually a SiL 3124. The OS didnt see the raid as
one drive, so its another one of these fake raid cards. I did get a
good image.so Im going to re-os this weekend and use the software raid
method.
One last question, is it acceptable to let graphical installers setup
the software raid for me or should I use one disk and create a raid
mirror later once the OS is setup?
On Fri, Apr 14, 2017 at 12:43 AM, David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
> On 04/12/2017 10:36 AM, linuxknight wrote:
>> Thank you Reindl, Using your method would I be able to apply this IMG
>> file to a fresh raid1 mirror and still have it be bootable?
>>
>> The reason I ask is I was looking at this guide,
>> https://www.data-medics.com/forum/how-to-clone-a-hard-drive-with-bad-sectors-using-ddrescue-t133.html
>> It has a method to transfer drive to drive. I was thinking I would
>> create the fresh RAID mirror on the dedicated LSI card, then ddrescue
>> possibly bad drive to the new raid mirror. Is this a bad idea?
>
> Take the dd advise, but... you initially indicated:
>
> <quote>
> I was moving a server with a raid1 configuration,
> controlled by a Intel Corporation 82801 SATA RAID Controller
> </quote>
>
> Now you are saying
>
> <quote>
>> It has a method to transfer drive to drive. I was thinking I would
>> create the fresh RAID mirror on the dedicated LSI card
> </quote>
>
> Note: the Intel and LSI cards may not have compatible RAID metadata. (That is
> one of the major benefits of using linux-raid (software RAID) you are not
> constrained by differing hardware RAID specifications.)
>
> You also mention "to a fresh raid1 mirror and still have it be bootable?" If
> you image the drive with dd, the mbr or bootloader will still be present on in
> the image and on the drive, so as long as you can tell the OS to boot from
> that drive you should be fine (as long as the controller can access the
> information)
>
> A good general howto on setting up linux-raid is
> https://wiki.archlinux.org/index.php/RAID
>
> --
> David C. Rankin, J.D.,P.E.
> --
> 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: [PATCH 0/4] integrated stat and fstat into utility functions
From: Paul Menzel @ 2017-04-14 12:31 UTC (permalink / raw)
To: Zhilong Liu, Jes.Sorensen; +Cc: linux-raid
In-Reply-To: <20170401125145.14440-1-zlliu@suse.com>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Dear Zhilong,
Am Samstag, den 01.04.2017, 20:51 +0800 schrieb Zhilong Liu:
[…]
> Zhilong Liu (4):
> mdadm/util:integrate stat operations into one utility
> mdadm/util:integrate fstat operations into one utility function
> mdadm/Create:declaring an existing struct within same function
> mdadm/Monitor:check the block device when use waitclean parameter
Just a small wish, could you please add exactly one space between the
“subsystem prefix” and the summary?
Like *mdadm/util: Integrate stat …*. That’d be great.
[…]
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] mdadm/util:integrate stat operations into one utility
From: Liu Zhilong @ 2017-04-14 10:14 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid
In-Reply-To: <wrfj8tneeu8k.fsf@gmail.com>
On 04/05/2017 11:42 PM, jes.sorensen@gmail.com wrote:
> Zhilong Liu <zlliu@suse.com> writes:
>> mdadm/util: there are dupilicate codes about stat checking the
>> block device, move the operations into one utility function and
>> make it concise.
>>
>> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>> ---
>> Assemble.c | 5 ++---
>> Build.c | 21 +++------------------
>> Incremental.c | 12 +-----------
>> Manage.c | 10 ++--------
>> mdadm.h | 1 +
>> super-intel.c | 4 +---
>> util.c | 15 +++++++++++++++
>> 7 files changed, 25 insertions(+), 43 deletions(-)
>>
>> diff --git a/Assemble.c b/Assemble.c
>> index 672cd12..c6571e6 100644
>> --- a/Assemble.c
>> +++ b/Assemble.c
>> @@ -522,9 +522,8 @@ static int select_devices(struct mddev_dev *devlist,
>> struct stat stb;
>> if (tmpdev->used != 3)
>> continue;
>> - if (stat(tmpdev->devname, &stb)< 0) {
>> - pr_err("fstat failed for %s: %s\n",
>> - tmpdev->devname, strerror(errno));
>> + if (check_blkdev_via_stat(tmpdev->devname) &&
>> + stat(tmpdev->devname, &stb)) {
>> tmpdev->used = 2;
>> } else {
>> struct dev_policy *pol = devid_policy(stb.st_rdev);
> Sorry, but this change makes no sense. First calling a function using
> stat() to check, and then call stat() one more time to get the stat data
> anyway.
>
> In fact, looking through this patch, you are doing it all over the
> place.
>
> This makes things worse, not better!
>
>> diff --git a/Build.c b/Build.c
>> index 691dd6f..b500ad7 100644
>> --- a/Build.c
>> +++ b/Build.c
>> @@ -67,16 +67,8 @@ int Build(char *mddev, struct mddev_dev *devlist,
>> missing_disks++;
>> continue;
>> }
>> - if (stat(dv->devname, &stb)) {
>> - pr_err("Cannot find %s: %s\n",
>> - dv->devname, strerror(errno));
>> - return 1;
>> - }
>> - if ((stb.st_mode & S_IFMT) != S_IFBLK) {
>> - pr_err("%s is not a block device.\n",
>> - dv->devname);
>> + if (check_blkdev_via_stat(dv->devname))
>> return 1;
>> - }
>> }
>>
>> if (s->raiddisks != subdevs) {
>> @@ -171,16 +163,9 @@ int Build(char *mddev, struct mddev_dev *devlist,
>> int fd;
>> if (strcmp("missing", dv->devname) == 0)
>> continue;
>> - if (stat(dv->devname, &stb)) {
>> - pr_err("Weird: %s has disappeared.\n",
>> - dv->devname);
>> + if (check_blkdev_via_stat(dv->devname))
>> goto abort;
>> - }
>> - if ((stb.st_mode & S_IFMT)!= S_IFBLK) {
>> - pr_err("Weird: %s is no longer a block device.\n",
>> - dv->devname);
>> - goto abort;
>> - }
>> + stat(dv->devname, &stb);
>> fd = open(dv->devname, O_RDONLY|O_EXCL);
>> if (fd < 0) {
>> pr_err("Cannot open %s: %s\n",
>> diff --git a/Incremental.c b/Incremental.c
>> index 28f1f77..78adf18 100644
>> --- a/Incremental.c
>> +++ b/Incremental.c
>> @@ -108,18 +108,8 @@ int Incremental(struct mddev_dev *devlist, struct context *c,
>>
>> struct createinfo *ci = conf_get_create_info();
>>
>> - if (stat(devname, &stb) < 0) {
>> - if (c->verbose >= 0)
>> - pr_err("stat failed for %s: %s.\n",
>> - devname, strerror(errno));
>> + if (check_blkdev_via_stat(devname) && stat(devname, &stb))
>> return rv;
>> - }
>> - if ((stb.st_mode & S_IFMT) != S_IFBLK) {
>> - if (c->verbose >= 0)
>> - pr_err("%s is not a block device.\n",
>> - devname);
>> - return rv;
>> - }
>> dfd = dev_open(devname, O_RDONLY);
>> if (dfd < 0) {
>> if (c->verbose >= 0)
>> diff --git a/Manage.c b/Manage.c
>> index 618c98b..6aec65d 100644
>> --- a/Manage.c
>> +++ b/Manage.c
>> @@ -1544,17 +1544,11 @@ int Manage_subdevs(char *devname, int fd,
>> close(tfd);
>> } else {
>> int open_err = errno;
>> - if (stat(dv->devname, &stb) != 0) {
>> - pr_err("Cannot find %s: %s\n",
>> - dv->devname, strerror(errno));
>> - goto abort;
>> - }
>> - if ((stb.st_mode & S_IFMT) != S_IFBLK) {
>> + if (check_blkdev_via_stat(dv->devname) &&
>> + stat(dv->devname, &stb)) {
>> if (dv->disposition == 'M')
>> /* non-fatal. Also improbable */
>> continue;
>> - pr_err("%s is not a block device.\n",
>> - dv->devname);
>> goto abort;
>> }
>> if (dv->disposition == 'r')
>> diff --git a/mdadm.h b/mdadm.h
>> index 612bd86..0aea822 100644
>> --- a/mdadm.h
>> +++ b/mdadm.h
>> @@ -1422,6 +1422,7 @@ extern int check_raid(int fd, char *name);
>> extern int check_partitions(int fd, char *dname,
>> unsigned long long freesize,
>> unsigned long long size);
>> +extern int check_blkdev_via_stat(char *dev);
>>
>> extern int get_mdp_major(void);
>> extern int get_maj_min(char *dev, int *major, int *minor);
>> diff --git a/super-intel.c b/super-intel.c
>> index 84dfe2b..924ad8a 100644
>> --- a/super-intel.c
>> +++ b/super-intel.c
>> @@ -6953,9 +6953,7 @@ static int validate_geometry_imsm_volume(struct supertype *st, int level,
>> }
>>
>> /* This device must be a member of the set */
>> - if (stat(dev, &stb) < 0)
>> - return 0;
>> - if ((S_IFMT & stb.st_mode) != S_IFBLK)
>> + if (check_blkdev_via_stat(dev) && stat(dev, &stb))
>> return 0;
>> for (dl = super->disks ; dl ; dl = dl->next) {
>> if (dl->major == (int)major(stb.st_rdev) &&
>> diff --git a/util.c b/util.c
>> index 9fc7ba0..03d4256 100644
>> --- a/util.c
>> +++ b/util.c
>> @@ -774,6 +774,21 @@ int ask(char *mesg)
>> }
>> #endif /* MDASSEMBLE */
>>
>> +int check_blkdev_via_stat(char *dev)
>> +{
>> + struct stat stb;
>> +
>> + if (stat(dev, &stb) != 0) {
>> + pr_err("stat failed for %s: %s\n", dev, strerror(errno));
>> + return -1;
>> + }
>> + if ((S_IFMT & stb.st_mode) != S_IFBLK) {
>> + pr_err("%s is not a block device.\n", dev);
>> + return -1;
>> + }
>> + return 0;
>> +}
>> +
> For a function like this, lets name it better md_is_blkdev()
How about return the devid after checking? Because always need the
stb.st_rdev to parse
the major and minor number. Although "util.c" has "devnm2devid" to
gather the devid via
to devnm, but it's convenient to return devid when check the blkdev with
absolute path.
would you mind the function like this?
// returns dev-id when success, return 0 when failure
dev_t stat_md_is_blkdev(char *dev)
{
struct stat stb;
if (stat(dev, &stb) != 0) {
pr_err("stat failed for %s: %s\n", dev, strerror(errno));
return 0;
}
if ((S_IFMT & stb.st_mode) != S_IFBLK) {
pr_err("%s is not a block device.\n", dev);
return 0;
}
return stb.st_rdev;
}
Thanks,
-Zhilong
> Jes
>
^ permalink raw reply
* Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites
From: Christoph Hellwig @ 2017-04-14 8:39 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Christoph Hellwig, Martin K. Petersen, Sagi Grimberg, Jens Axboe,
Tejun Heo, Greg Kroah-Hartman, Dan Williams, Ross Zwisler,
Matthew Wilcox, Sumit Semwal, Ming Lin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA, devel
In-Reply-To: <1492121135-4437-10-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in all four spots.
I think the right fix here is to switch dm-crypt to the ahash API
that takes a scatterlist.
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function
From: Christoph Hellwig @ 2017-04-14 8:36 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, netdev@
In-Reply-To: <1492121135-4437-4-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote:
> Convert the kmap and kmap_atomic uses to the sg_map function. We now
> store the flags for the kmap instead of a boolean to indicate
> atomicitiy. We also propogate a possible kmap error down and create
> a new ISCSI_TCP_INTERNAL_ERR error type for this.
Can you split out the new error handling into a separate prep patch
which should go to the iscsi maintainers ASAP?
^ permalink raw reply
* Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions
From: Christoph Hellwig @ 2017-04-14 8:35 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Christoph Hellwig, Martin K. Petersen, Sagi Grimberg, Jens Axboe,
Tejun Heo, Greg Kroah-Hartman, Dan Williams, Ross Zwisler,
Matthew Wilcox, Sumit Semwal, Ming Lin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA, devel
In-Reply-To: <1492121135-4437-2-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..b95934b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -37,6 +37,9 @@
>
> #include <uapi/linux/dma-buf.h>
>
> +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */
> +#undef kunmap_atomic
> +
> static inline int is_dma_buf_file(struct file *);
>
> struct dma_buf_list {
I think the right fix here is to rename the operation to unmap_atomic
and send out a little patch for that ASAP.
> + * Flags can be any of:
> + * * SG_KMAP - Use kmap to create the mapping
> + * * SG_KMAP_ATOMIC - Use kmap_atomic to map the page atommically.
> + * Thus, the rules of that function apply: the cpu
> + * may not sleep until it is unmaped.
> + *
> + * Also, consider carefully whether this function is appropriate. It is
> + * largely not recommended for new code and if the sgl came from another
> + * subsystem and you don't know what kind of memory might be in the list
> + * then you definitely should not call it. Non-mappable memory may be in
> + * the sgl and thus this function may fail unexpectedly.
> + **/
> +static inline void *sg_map_offset(struct scatterlist *sg, size_t offset,
> + int flags)
I'd rather have separate functions for kmap vs kmap_atomic instead of
the flags parameter. And while you're at it just always pass the 0
offset parameter instead of adding a wrapper..
Otherwise this looks good to me.
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] md-cluster: Fix a memleak in an error handling path
From: Guoqing Jiang @ 2017-04-14 6:23 UTC (permalink / raw)
To: Christophe JAILLET, shli; +Cc: linux-raid, linux-kernel, kernel-janitors
In-Reply-To: <20170414060803.12472-1-christophe.jaillet@wanadoo.fr>
On 04/14/2017 02:08 PM, Christophe JAILLET wrote:
> We know that 'bm_lockres' is NULL here, so 'lockres_free(bm_lockres)' is a
> no-op. According to resource handling in case of error a few lines below,
> it is likely that 'bitmap_free(bitmap)' was expected instead.
>
> Fixes: b98938d16a10 ("md-cluster: introduce cluster_check_sync_size")
Reviewed-by: Guoqing Jiang <gqjiang@suse.com>
Thanks,
Guoqing
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/md/md-cluster.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
> index b21ef58819f6..7299ce2f08a8 100644
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -1127,7 +1127,7 @@ int cluster_check_sync_size(struct mddev *mddev)
> bm_lockres = lockres_init(mddev, str, NULL, 1);
> if (!bm_lockres) {
> pr_err("md-cluster: Cannot initialize %s\n", str);
> - lockres_free(bm_lockres);
> + bitmap_free(bitmap);
> return -1;
> }
> bm_lockres->flags |= DLM_LKF_NOQUEUE;
^ permalink raw reply
* [PATCH] md-cluster: Fix a memleak in an error handling path
From: Christophe JAILLET @ 2017-04-14 6:08 UTC (permalink / raw)
To: shli, gqjiang
Cc: linux-raid, linux-kernel, kernel-janitors, Christophe JAILLET
We know that 'bm_lockres' is NULL here, so 'lockres_free(bm_lockres)' is a
no-op. According to resource handling in case of error a few lines below,
it is likely that 'bitmap_free(bitmap)' was expected instead.
Fixes: b98938d16a10 ("md-cluster: introduce cluster_check_sync_size")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/md/md-cluster.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index b21ef58819f6..7299ce2f08a8 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -1127,7 +1127,7 @@ int cluster_check_sync_size(struct mddev *mddev)
bm_lockres = lockres_init(mddev, str, NULL, 1);
if (!bm_lockres) {
pr_err("md-cluster: Cannot initialize %s\n", str);
- lockres_free(bm_lockres);
+ bitmap_free(bitmap);
return -1;
}
bm_lockres->flags |= DLM_LKF_NOQUEUE;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function
From: Christoph Hellwig @ 2017-04-14 5:18 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, netdev@
In-Reply-To: <4df3e41b-591e-a500-a428-4bc529224030-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote:
> Or maybe I'll just send a patch for that
> separately seeing it doesn't depend on anything and is pretty simple. I
> can do that next week.
Yes, please just send that patch linux-nvme, we should be able to get
it into 4.12.
^ permalink raw reply
* Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-14 5:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo
In-Reply-To: <20170414045951.GA22206-jcswGhMUV9g@public.gmane.org>
On 13/04/17 10:59 PM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
>> This is a straight forward conversion in two places. Should kmap fail,
>> the code will return an INVALD_DATA error in the completion.
>
> It really should be using nvmet_copy_from_sgl to make things safer,
> as we don't want to rely on any particular SG list layout. In fact
> I'm pretty sure I did the conversion at some point, but it must never
> have made it upstream.
Ha, I did the conversion too a couple times for my RFC series. I can
change this patch to do that. Or maybe I'll just send a patch for that
separately seeing it doesn't depend on anything and is pretty simple. I
can do that next week.
Thanks,
Logan
^ permalink raw reply
* Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function
From: Christoph Hellwig @ 2017-04-14 4:59 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Steve Wise, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA, Ming Lin,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, Martin K. Petersen,
Greg Kroah-Hartman, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, netdev@
In-Reply-To: <1492121135-4437-3-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
> This is a straight forward conversion in two places. Should kmap fail,
> the code will return an INVALD_DATA error in the completion.
It really should be using nvmet_copy_from_sgl to make things safer,
as we don't want to rely on any particular SG list layout. In fact
I'm pretty sure I did the conversion at some point, but it must never
have made it upstream.
^ 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