* linux-next: manual merge of the target-bva tree with the target-updates tree
@ 2017-06-01 4:10 Stephen Rothwell
2017-06-01 4:27 ` Nicholas A. Bellinger
2017-06-01 4:59 ` Bart Van Assche
0 siblings, 2 replies; 12+ messages in thread
From: Stephen Rothwell @ 2017-06-01 4:10 UTC (permalink / raw)
To: Bart Van Assche, Nicholas A. Bellinger
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi Bart,
Today's linux-next merge of the target-bva tree got a conflict in:
drivers/target/target_core_transport.c
between commit:
4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow data")
from the target-updates tree and commit:
2c66660df665 ("target: Fix overflow/underflow handling of commands with a Data-Out buffer")
from the target-bva tree.
I fixed it up (I think (guidance appreciated), see below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/target/target_core_transport.c
index 6025935036c9,6cd49fe578a7..000000000000
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@@ -1164,37 -1164,7 +1164,21 @@@ target_cmd_size_check(struct se_cmd *cm
" %u does not match SCSI CDB Length: %u for SAM Opcode:"
" 0x%02x\n", cmd->se_tfo->get_fabric_name(),
cmd->data_length, size, cmd->t_task_cdb[0]);
+
+ if (cmd->data_direction == DMA_TO_DEVICE) {
- if (cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) {
- pr_err_ratelimited("Rejecting underflow/overflow"
- " for WRITE data CDB\n");
- return TCM_INVALID_CDB_FIELD;
- }
+ /*
+ * Some fabric drivers like iscsi-target still expect to
+ * always reject overflow writes. Reject this case until
+ * full fabric driver level support for overflow writes
+ * is introduced tree-wide.
+ */
+ if (size > cmd->data_length) {
+ pr_err_ratelimited("Rejecting overflow for"
+ " WRITE control CDB\n");
+ return TCM_INVALID_CDB_FIELD;
+ }
+ }
/*
- * Reject READ_* or WRITE_* with overflow/underflow for
- * type SCF_SCSI_DATA_CDB.
- */
- if (dev->dev_attrib.block_size != 512) {
- pr_err("Failing OVERFLOW/UNDERFLOW for LBA op"
- " CDB on non 512-byte sector setup subsystem"
- " plugin: %s\n", dev->transport->name);
- /* Returns CHECK_CONDITION + INVALID_CDB_FIELD */
- return TCM_INVALID_CDB_FIELD;
- }
- /*
* For the overflow case keep the existing fabric provided
* ->data_length. Otherwise for the underflow case, reset
* ->data_length to the smaller SCSI expected data transfer
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 4:10 linux-next: manual merge of the target-bva tree with the target-updates tree Stephen Rothwell
@ 2017-06-01 4:27 ` Nicholas A. Bellinger
2017-06-01 5:05 ` Bart Van Assche
2017-06-01 4:59 ` Bart Van Assche
1 sibling, 1 reply; 12+ messages in thread
From: Nicholas A. Bellinger @ 2017-06-01 4:27 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Bart Van Assche, Linux-Next Mailing List,
Linux Kernel Mailing List
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
>
> Today's linux-next merge of the target-bva tree got a conflict in:
>
> drivers/target/target_core_transport.c
>
> between commit:
>
> 4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow data")
>
> from the target-updates tree and commit:
>
> 2c66660df665 ("target: Fix overflow/underflow handling of commands with a Data-Out buffer")
>
> from the target-bva tree.
>
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
Hi Bart,
The majority of this series hasn't been list reviewed, and shouldn't be
getting pushed in linux-next without some form of reviews.
I'll be getting back to v4.13 items now v4.12-rc fixes is out of the
way, but a weeks worth of list silence for your series doesn't mean
you're free to push un-reviewed stuff for drivers/target/ into
linux-next.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 4:27 ` Nicholas A. Bellinger
@ 2017-06-01 5:05 ` Bart Van Assche
2017-06-01 5:15 ` Nicholas A. Bellinger
0 siblings, 1 reply; 12+ messages in thread
From: Bart Van Assche @ 2017-06-01 5:05 UTC (permalink / raw)
To: sfr@canb•auug.org.au, nab@linux-iscsi•org
Cc: linux-kernel@vger•kernel.org, linux-next@vger•kernel.org
On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> but a weeks worth of list silence for your series doesn't mean
> you're free to push un-reviewed stuff for drivers/target/ into
> linux-next.
I think this is an example of the pot calling the kettle black.
Your patch "target: Re-add check to reject control WRITEs with
overflow data" has not been reviewed by anyone but was pushed
into linux-next and sent to Linus anyway.
Bart.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 5:05 ` Bart Van Assche
@ 2017-06-01 5:15 ` Nicholas A. Bellinger
0 siblings, 0 replies; 12+ messages in thread
From: Nicholas A. Bellinger @ 2017-06-01 5:15 UTC (permalink / raw)
To: Bart Van Assche
Cc: sfr@canb•auug.org.au, linux-kernel@vger•kernel.org,
linux-next@vger•kernel.org
On Thu, 2017-06-01 at 05:05 +0000, Bart Van Assche wrote:
> On Wed, 2017-05-31 at 21:27 -0700, Nicholas A. Bellinger wrote:
> > but a weeks worth of list silence for your series doesn't mean
> > you're free to push un-reviewed stuff for drivers/target/ into
> > linux-next.
>
> I think this is an example of the pot calling the kettle black.
> Your patch "target: Re-add check to reject control WRITEs with
> overflow data" has not been reviewed by anyone but was pushed
> into linux-next and sent to Linus anyway.
Heh, it fixed a regression you yourself pointed out. :)
If your going to report a bug and not review the patch to address the
regression, I'm not going to let that regression slide to restore
existing behavior, just because you didn't bother to review the patch in
three plus weeks for the bug you reported.
Anyways, I'll get to your patches, but please get reviews on the list by
sending series that people want to review, instead of large unwieldy
series that intermix new features and random bug-fixes without any
context.
No wonder why people don't send time reviewing them!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 4:10 linux-next: manual merge of the target-bva tree with the target-updates tree Stephen Rothwell
2017-06-01 4:27 ` Nicholas A. Bellinger
@ 2017-06-01 4:59 ` Bart Van Assche
2017-06-01 5:04 ` Nicholas A. Bellinger
1 sibling, 1 reply; 12+ messages in thread
From: Bart Van Assche @ 2017-06-01 4:59 UTC (permalink / raw)
To: sfr@canb•auug.org.au, nab@linux-iscsi•org
Cc: linux-kernel@vger•kernel.org, linux-next@vger•kernel.org
On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> Hi Bart,
>
> Today's linux-next merge of the target-bva tree got a conflict in:
>
> drivers/target/target_core_transport.c
>
> between commit:
>
> 4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow data")
>
> from the target-updates tree and commit:
>
> 2c66660df665 ("target: Fix overflow/underflow handling of commands with a Data-Out buffer")
>
> from the target-bva tree.
>
> I fixed it up (I think (guidance appreciated), see below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Hello Stephen,
Thanks for having fixed this up. I hadn't noticed that Nic had queued up patches
that conflict with my patches. I will rebase my tree.
Bart.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 4:59 ` Bart Van Assche
@ 2017-06-01 5:04 ` Nicholas A. Bellinger
2017-06-01 21:14 ` Bart Van Assche
0 siblings, 1 reply; 12+ messages in thread
From: Nicholas A. Bellinger @ 2017-06-01 5:04 UTC (permalink / raw)
To: Bart Van Assche
Cc: sfr@canb•auug.org.au, linux-kernel@vger•kernel.org,
linux-next@vger•kernel.org
On Thu, 2017-06-01 at 04:59 +0000, Bart Van Assche wrote:
> On Thu, 2017-06-01 at 14:10 +1000, Stephen Rothwell wrote:
> > Hi Bart,
> >
> > Today's linux-next merge of the target-bva tree got a conflict in:
> >
> > drivers/target/target_core_transport.c
> >
> > between commit:
> >
> > 4ff83daa0200 ("target: Re-add check to reject control WRITEs with overflow data")
> >
> > from the target-updates tree and commit:
> >
> > 2c66660df665 ("target: Fix overflow/underflow handling of commands with a Data-Out buffer")
> >
> > from the target-bva tree.
> >
> > I fixed it up (I think (guidance appreciated), see below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
>
> Hello Stephen,
>
> Thanks for having fixed this up. I hadn't noticed that Nic had queued up patches
> that conflict with my patches. I will rebase my tree.
>
Go ahead and get list review on drivers/target/ changes before pushing
them into linux-next, please.
Btw, I don't care if you queue up one's that do have at least two
Reviewed-bys into your tree, but everything that doesn't have
Reviewed-bys or Acked-by should not be going into linux-next.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 5:04 ` Nicholas A. Bellinger
@ 2017-06-01 21:14 ` Bart Van Assche
2017-06-01 23:28 ` Stephen Rothwell
2017-06-02 3:58 ` Nicholas A. Bellinger
0 siblings, 2 replies; 12+ messages in thread
From: Bart Van Assche @ 2017-06-01 21:14 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: sfr@canb•auug.org.au, linux-kernel@vger•kernel.org,
linux-next@vger•kernel.org
On 05/31/17 22:04, Nicholas A. Bellinger wrote:
> Go ahead and get list review on drivers/target/ changes before pushing
> them into linux-next, please.
>
> Btw, I don't care if you queue up one's that do have at least two
> Reviewed-bys into your tree, but everything that doesn't have
> Reviewed-bys or Acked-by should not be going into linux-next.
It is not your job to rewrite the rules for linux-next. I'm following
the guidelines I received from Stephen in December 2016. You were copied
on the e-mail with guidelines Stephen sent to me. See also
https://www.spinics.net/lists/linux-next/msg38488.html.
Stephen, if anything would have changed in the meantime that I'm not
aware of please let me know.
Bart.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 21:14 ` Bart Van Assche
@ 2017-06-01 23:28 ` Stephen Rothwell
2017-06-02 3:58 ` Nicholas A. Bellinger
1 sibling, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2017-06-01 23:28 UTC (permalink / raw)
To: Bart Van Assche
Cc: Nicholas A. Bellinger, linux-kernel@vger•kernel.org,
linux-next@vger•kernel.org
Hi Bart,
On Thu, 1 Jun 2017 14:14:06 -0700 Bart Van Assche <bart.vanassche@sandisk•com> wrote:
>
> On 05/31/17 22:04, Nicholas A. Bellinger wrote:
> > Go ahead and get list review on drivers/target/ changes before pushing
> > them into linux-next, please.
> >
> > Btw, I don't care if you queue up one's that do have at least two
> > Reviewed-bys into your tree, but everything that doesn't have
> > Reviewed-bys or Acked-by should not be going into linux-next.
>
> It is not your job to rewrite the rules for linux-next. I'm following
> the guidelines I received from Stephen in December 2016. You were copied
> on the e-mail with guidelines Stephen sent to me. See also
> https://www.spinics.net/lists/linux-next/msg38488.html.
>
> Stephen, if anything would have changed in the meantime that I'm not
> aware of please let me know.
This is what I tell everyone:
"You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary."
Which is just what was in that message you pointed to. Note the
"reviewed by you (or another maintainer of your subsystem tree)". This
is more meant for the top level maintainers, but implies that the
patches have been reviewed, tested and are as ready as possible for
merging into the next level up tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-01 21:14 ` Bart Van Assche
2017-06-01 23:28 ` Stephen Rothwell
@ 2017-06-02 3:58 ` Nicholas A. Bellinger
1 sibling, 0 replies; 12+ messages in thread
From: Nicholas A. Bellinger @ 2017-06-02 3:58 UTC (permalink / raw)
To: Bart Van Assche
Cc: sfr@canb•auug.org.au, linux-kernel@vger•kernel.org,
linux-next@vger•kernel.org
On Thu, 2017-06-01 at 14:14 -0700, Bart Van Assche wrote:
> On 05/31/17 22:04, Nicholas A. Bellinger wrote:
> > Go ahead and get list review on drivers/target/ changes before pushing
> > them into linux-next, please.
> >
> > Btw, I don't care if you queue up one's that do have at least two
> > Reviewed-bys into your tree, but everything that doesn't have
> > Reviewed-bys or Acked-by should not be going into linux-next.
>
> It is not your job to rewrite the rules for linux-next. I'm following
> the guidelines I received from Stephen in December 2016. You were copied
> on the e-mail with guidelines Stephen sent to me. See also
> https://www.spinics.net/lists/linux-next/msg38488.html.
>
> Stephen, if anything would have changed in the meantime that I'm not
> aware of please let me know.
>
The point is you're not sending PULL requests.
But like I said earlier, I really don't care if you put patches that
have been reviewed into your tree for linux-next before I get a chance
to review and pick them up for target-pending.
However, you putting random un-reviewed changes is where I have to draw
the line, especially considering what happened earlier in year where
what you had in linux-next close to the merge window was completely and
utterly broken.
Would you put un-reviewed block and scsi changes into linux-next..?
What would those subsystem maintainers say about that..?
Why is drivers/target any different..?
^ permalink raw reply [flat|nested] 12+ messages in thread
* linux-next: manual merge of the target-bva tree with the target-updates tree
@ 2017-06-02 4:05 Stephen Rothwell
2017-06-02 4:11 ` Stephen Rothwell
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2017-06-02 4:05 UTC (permalink / raw)
To: Bart Van Assche, Nicholas A. Bellinger
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi Bart,
Today's linux-next merge of the target-bva tree got a conflict in:
drivers/target/target_core_tpg.c
between commits:
06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic")
4f61e1e687c4 ("target: Avoid target_shutdown_sessions loop during queue_depth change")
from the target-updates tree and commits:
ba438d7c8d39 ("target: Avoid target_shutdown_sessions loop during queue_depth change")
b968ec8ff101 ("target/configfs: Kill se_lun->lun_link_magic")
from the target-bva tree.
I fixed it up (I used the version from the target-updates tree) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: linux-next: manual merge of the target-bva tree with the target-updates tree
2017-06-02 4:05 Stephen Rothwell
@ 2017-06-02 4:11 ` Stephen Rothwell
0 siblings, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2017-06-02 4:11 UTC (permalink / raw)
To: Bart Van Assche, Nicholas A. Bellinger
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi all,
On Fri, 2 Jun 2017 14:05:35 +1000 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next merge of the target-bva tree got a conflict in:
>
> drivers/target/target_core_tpg.c
>
> between commits:
>
> 06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic")
> 4f61e1e687c4 ("target: Avoid target_shutdown_sessions loop during queue_depth change")
>
> from the target-updates tree and commits:
>
> ba438d7c8d39 ("target: Avoid target_shutdown_sessions loop during queue_depth change")
> b968ec8ff101 ("target/configfs: Kill se_lun->lun_link_magic")
>
> from the target-bva tree.
>
> I fixed it up (I used the version from the target-updates tree) and can
Which turned out to be the wrong thing to do (or more was needed) as
the result does not build :-(.
I have just dropped the target-bva tree for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 12+ messages in thread
* linux-next: manual merge of the target-bva tree with the target-updates tree
@ 2017-02-20 2:51 Stephen Rothwell
0 siblings, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2017-02-20 2:51 UTC (permalink / raw)
To: Bart Van Assche, Nicholas A. Bellinger
Cc: linux-next, linux-kernel, Varun Prakash
Hi Bart,
Today's linux-next merge of the target-bva tree got conflicts in:
drivers/target/iscsi/cxgbit/cxgbit_target.c
drivers/target/iscsi/iscsi_target.c
include/target/iscsi/iscsi_transport.h
between commits:
9a584bf9bf0a ("target/iscsi: split iscsit_check_dataout_hdr()")
79e57cfe00f4 ("target/cxgbit: add T6 iSCSI DDP completion feature")
from the target-updates tree and commit:
b6f2cd5ab404 ("target/iscsi: split iscsit_check_dataout_hdr()")
b0d5eab94c37 ("target/cxgbit: add T6 iSCSI DDP completion feature")
from the target-bva tree.
I fixed it up (the target-update versions are updates from the others,
so I used those) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-06-02 4:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-01 4:10 linux-next: manual merge of the target-bva tree with the target-updates tree Stephen Rothwell
2017-06-01 4:27 ` Nicholas A. Bellinger
2017-06-01 5:05 ` Bart Van Assche
2017-06-01 5:15 ` Nicholas A. Bellinger
2017-06-01 4:59 ` Bart Van Assche
2017-06-01 5:04 ` Nicholas A. Bellinger
2017-06-01 21:14 ` Bart Van Assche
2017-06-01 23:28 ` Stephen Rothwell
2017-06-02 3:58 ` Nicholas A. Bellinger
-- strict thread matches above, loose matches on Subject: below --
2017-06-02 4:05 Stephen Rothwell
2017-06-02 4:11 ` Stephen Rothwell
2017-02-20 2:51 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox