+ while (!list_empty(&list)) {
Maybe do a list_first_entry_or_null here if you're touching the list
iteration anyway?
I can do that.
+ local_irq_disable();
+ list_splice_tail_init(iop_list, &list);
+ list_splice(&list, iop_list);
+
if (rearm)
_
Are they really that unlikely? I don't like these annotations unless
it's clearly an error path or they have a high, demonstrable benefit.
IRQ_POLL_F_DISABLE is set when disabling the iop (in the end of the
world). IRQ_POLL_F_SCHED is set on irq_poll_sched() itself so this cond
would match only
On Fri, Nov 11 2016, Christoph Hellwig wrote:
>
> Another not quite as urgent issue is how the RAID5 code abuses
> ->bi_phys_segments as and outstanding I/O counter, and I have no
> really good answer to that either.
I would suggest adding a "bi_dev_private" field to the bio which is for
use by th
On Sun, Nov 13 2016, Christoph Hellwig wrote:
> On Fri, Nov 11, 2016 at 11:02:23AM -0800, Shaohua Li wrote:
>> > It's mostly about the RAID1 and RAID10 code which does a lot of funny
>> > things with the bi_iov_vec and bi_vcnt fields, which we'd prefer that
>> > drivers don't touch. One example i
> + while (!list_empty(&list)) {
Maybe do a list_first_entry_or_null here if you're touching the list
iteration anyway?
> + local_irq_disable();
> + list_splice_tail_init(iop_list, &list);
> + list_splice(&list, iop_list);
> +
> if (rearm)
> __raise_softirq_irq
Are they really that unlikely? I don't like these annotations unless
it's clearly an error path or they have a high, demonstrable benefit.
--
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://
Looks fine,
Reviewed-by: Christoph Hellwig
--
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
