Re: [PATCH] rxrpc: Fix uninitialized error code in rxrpc_send_data_packet()
From: David Howells Date: Fri, 31 May 2019 11:34:44 +0100 > Here's my take on the patch. I assume I'll see a final version of this under separate cover.
Re: [PATCH 13/19] net: split out functions related to registering inflight socket files
From: Jens Axboe Date: Fri, 8 Feb 2019 10:34:17 -0700 > We need this functionality for the io_uring file registration, but > we cannot rely on it since CONFIG_UNIX can be modular. Move the helpers > to a separate file, that's always builtin to the kernel if CONFIG_UNIX is > m/y. > > No functional changes in this patch, just moving code around. > > Cc: net...@vger.kernel.org > Cc: David S. Miller > Signed-off-by: Jens Axboe No objections on my end, feel free to merge this in with your series. Acked-by: David S. Miller
Re: [PATCH] block: sunvdc: don't run hw queue synchronously from irq context
From: Ming Lei
Date: Thu, 3 Jan 2019 09:19:48 +0800
> vdc_blk_queue_start() may be called from irq context, so we can't run
> queue via blk_mq_start_hw_queues() since we never allow to run queue
> from irq context. Use blk_mq_start_stopped_hw_queues(q, true) to fix
> this issue.
>
> Fixes: fa182a1fa97dff56cd ("sunvdc: convert to blk-mq")
> Reported-by: Anatoly Pugachev
> Tested-by: Anatoly Pugachev
> Cc: Anatoly Pugachev
> Cc: David Miller
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Ming Lei
Acked-by: David S. Miller
Re: [PATCH v4 00/13] TCP transport binding for NVMe over Fabrics
From: Sagi Grimberg Date: Thu, 29 Nov 2018 17:24:09 -0800 > >> What is the plan ahead here? I think the nvme code looks pretty >> reasonable now (I'll do another pass at nitpicking), but we need the >> networking stuff sorted out with at least ACKs, or a merge through >> the networking tree and then a shared branch we can pull in. > > I would think that having Dave ack patches 1-3 and taking it via the > nvme tree should be easier.. > > Dave? What would you prefer? No preference, if the nvme tree makes things easier for you then please do it that way. Acked-by: David S. Miller
Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver
From: Sagi Grimberg Date: Mon, 19 Nov 2018 15:24:13 -0800 > >>> Also, looking a bit closer there is a slight difference between the >>> copy vs. the copy_and_csum variants. copy allows for a short_copy if >>> we copy less than we expect while the csum faults it. I'm thinking >>> that the copy_and_hash variant should also fault? Although I'm not >>> sure I understand the fault entirely as csum is supposed to be >>> cumulative, any insight? >> When we are writing and signal an error, sockets have this recurring >> pattern where we return immediately the amount of bytes successfully >> transferred. Then on the next sendmsg() call we give the error. >> I don't know if that is what is influencing the behavior here or not >> but it could be. > > That makes sense... Does recvmsg() have the same semantics? this is > the > rx path where we copy fragments to an iter.. I just checked and TCP at the very least behaves this way on recvmsg() (report short length, then -EFAULT on next recvmsg() call). It maintains a local variable "copied" which is increased every time skb_copy_datagram_msg() is successful. If in a subsequent iteration of the loop skb_copy_datagram_msg() returns -EFAULT, it will instead return 'copied' from recvmsg() if non-zero else the -EFAULT.
Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver
From: Sagi Grimberg Date: Mon, 19 Nov 2018 15:14:44 -0800 > Also, looking a bit closer there is a slight difference between the > copy vs. the copy_and_csum variants. copy allows for a short_copy if > we copy less than we expect while the csum faults it. I'm thinking > that the copy_and_hash variant should also fault? Although I'm not > sure I understand the fault entirely as csum is supposed to be > cumulative, any insight? When we are writing and signal an error, sockets have this recurring pattern where we return immediately the amount of bytes successfully transferred. Then on the next sendmsg() call we give the error. I don't know if that is what is influencing the behavior here or not but it could be.
Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver
From: Sagi Grimberg
Date: Mon, 19 Nov 2018 13:26:12 -0800
> I would love you to look at skb_copy_and_hash_datagram_iter as these
> changes will require an ack from you.
My first impression is that we now have this kind of code pattern
in at least two main places and now this will be a third.
I know that nobody likes callbacks because of spectre, but all of
these cases could be done with something like:
int __skb_datagram_iter(const struct sk_buff *skb, int offset,
struct iov_iter *to, int len,
int (*cb)(void *, int, struct iov_iter *, void *),
void *data)
{
...
n = cb(skb->data + offset, copy, to, data);
...
}
You get the idea. Then we have one version of all the loops and
the different (copy, copy+csum, copy+hash) cases all can be
handled by __skb_datagram_iter() but just with a different 'cb'
and private 'data'.
Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver
From: Sagi Grimberg Date: Thu, 15 Nov 2018 09:16:22 -0800 > +static unsigned nvmet_tcp_recv_budget = 8; > +module_param_named(recv_budget, nvmet_tcp_recv_budget, int, S_IRUGO | > S_IWUSR); > +MODULE_PARM_DESC(recv_budget, "recvs budget"); > + > +static unsigned nvmet_tcp_send_budget = 8; > +module_param_named(send_budget, nvmet_tcp_send_budget, int, S_IRUGO | > S_IWUSR); > +MODULE_PARM_DESC(send_budget, "sends budget"); > + > +static unsigned nvmet_tcp_io_work_budget = 64; > +module_param_named(io_work_budget, nvmet_tcp_io_work_budget, int, S_IRUGO | > S_IWUSR); > +MODULE_PARM_DESC(io_work_budget, "io work budget"); I strongly suggest moving away from module parameters for this stuff. Create a genetlink socket family and allow run time configuration of these knobs by the user. Thanks.
Re: [PATCH] jsflash: fix compilation
From: Jens Axboe Date: Tue, 15 May 2018 13:00:36 -0600 > On 5/15/18 12:58 PM, David Miller wrote: >> From: Jens Axboe >> Date: Tue, 15 May 2018 12:51:20 -0600 >> >>> On 5/15/18 12:32 PM, Christoph Hellwig wrote: >>>> No bio in this whole function, use req->bio instead. >>> >>> Applied. >>> >>>> Looks like no one except for Guenters build bot cared. I wonder if we >>>> should just get rid of the driver given that it doesn't look in a good >>>> shape at all based on his build logs even with the fix.. >>> >>> Needs input from the folks that actually might use it. The driver looks >>> abandoned, it's only getting updates through API changes etc. >> >> I don't think anyone is using it. > > Are you fine with removing it then? Yes, I am: Acked-by: David S. Miller
Re: [PATCH] jsflash: fix compilation
From: Jens Axboe Date: Tue, 15 May 2018 12:51:20 -0600 > On 5/15/18 12:32 PM, Christoph Hellwig wrote: >> No bio in this whole function, use req->bio instead. > > Applied. > >> Looks like no one except for Guenters build bot cared. I wonder if we >> should just get rid of the driver given that it doesn't look in a good >> shape at all based on his build logs even with the fix.. > > Needs input from the folks that actually might use it. The driver looks > abandoned, it's only getting updates through API changes etc. I don't think anyone is using it.
Re: [PATCH 01/12] iommu-common: move to arch/sparc
From: Anshuman Khandual Date: Mon, 16 Apr 2018 14:26:07 +0530 > On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >> This code is only used by sparc, and all new iommu drivers should use the >> drivers/iommu/ framework. Also remove the unused exports. >> >> Signed-off-by: Christoph Hellwig > > Right, these functions are used only from SPARC architecture. Simple > git grep confirms it as well. Hence it makes sense to move them into > arch code instead. Well, we put these into a common location and used type friendly for powerpc because we hoped powerpc would convert over to using this common piece of code as well. But nobody did the powerpc work. If you look at the powerpc iommu support, it's the same code basically for entry allocation.
Re: [PATCH v6 7/9] ide, scsi: Tell the block layer at request allocation time about preempt requests
From: Bart Van Assche Date: Wed, 4 Oct 2017 17:01:08 -0700 > Convert blk_get_request(q, op, __GFP_RECLAIM) into blk_get_request(q, > op, BLK_MQ_PREEMPT). This patch does not change any functionality. > > Signed-off-by: Bart Van Assche > Cc: Martin K. Petersen > Cc: David S. Miller > Cc: Ming Lei > Cc: Christoph Hellwig > Cc: Hannes Reinecke > Cc: Johannes Thumshirn For IDE: Acked-by: David S. Miller
Re: [PATCH 4/6] qlogic: make device_attribute const
From: Bhumika Goyal Date: Mon, 21 Aug 2017 17:13:10 +0530 > Make these const as they are only passed as an argument to the > function device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal Applied. But I would seriously suggest that when you have to cross subsystems like this, just send the patches individually to the respective maintainers rather than trying to make a "series" out of it. Thanks.
Re: [PATCH 08/12] ide-floppy: Use blk_rq_is_scsi()
From: Bart Van Assche Date: Thu, 17 Aug 2017 16:23:07 -0700 > This patch does not change any functionality. > > Signed-off-by: Bart Van Assche Acked-by: David S. Miller
Re: [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset
From: Christoph Hellwig Date: Wed, 26 Apr 2017 09:34:22 +0200 > The caller only looks at the scsi_request result field anyway. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller
Re: [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all
From: Christoph Hellwig Date: Wed, 26 Apr 2017 09:34:21 +0200 > ide_pm_execute_rq exectures a PM request synchronously, and in the failure > case where it calls __blk_end_request_all it never checks the error field > passed to the end_io callback, so don't bother setting it. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller
Re: [PATCH 09/10] ide: don't abuse cmd_type
From: Christoph Hellwig Date: Tue, 31 Jan 2017 16:57:30 +0100 > Currently the legacy ide driver defines several request types of it's own, > which is in the way of removing that field entirely. > > Instead add a type field to struct ide_request and use that to distinguish > the different types of IDE-internal requests. > > It's a bit of a mess, but so is the surrounding code.. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
