On Tue, 2014-06-10 at 22:35 +0300, Michael S. Tsirkin wrote: > On Tue, Jun 10, 2014 at 10:39:17AM -0700, Nicholas A. Bellinger wrote: > > On Tue, 2014-06-10 at 16:02 +0300, Michael S. Tsirkin wrote: > > > On Tue, Jun 10, 2014 at 09:52:17PM +1000, Stephen Rothwell wrote: > > > > Hi Michael, > > > > > > > > On Tue, 10 Jun 2014 12:42:54 +0300 "Michael S. Tsirkin" > > > > <m...@redhat.com> wrote: > > > > > > > > > > So I see two options: > > > > > - I go ahead with my changes and you with yours and let Linus resolve > > > > > the conflict. This means bisect build will be broken since the > > > > > breakage will likely not be noticed until after the merge. > > > > > > > > Well, since the resolution is known, the one who submits their tree > > > > later should tell Linus (as suggested by Nicholas). That is part of > > > > the point of the linux-next tree ... and therefore there would be no > > > > bisect problem. > > > > > > > > > > Stephen (CC'ed) has included a fix in today's linux-next for the > > > > > > merge > > > > > > conflict here: > > > > > > > > > > > > https://lkml.org/lkml/2014/6/10/3 > > > > > > > > > > > > Please confirm, as it will be a pointer to Linus within the > > > > > > target-pending/for-next PULL request. > > > > > > > > > > Yes but this does mean people trying to bisect will > > > > > hit build breakages, not nice. > > > > > > > > Not necessarily. > > > > > > > > -- > > > > Cheers, > > > > Stephen Rothwell s...@canb.auug.org.au > > > > > > > > > I don't see how that's possible. > > > Here's a point you might have missed. > > > Nicholas's patch isn't just introducing a merge conflict. > > > It is also buggy. > > > Replacing bit access with has_feature silently fixes the bug. > > > > > > So if we want to avoid bisect breakage target tree will > > > have to be rebased. > > > > > > And if doing that anyway, I don't see any reason not > > > to merge everything through the vhost tree, esp > > > since I already put the patches there. Less work for > > > everyone involved. > > > > > > > The problem is with Sagi's recent changes wrt to including T10 PI bytes > > into expected data transfer length in target-core, you'll end up > > introducing a different bug into your tree.. ;) > > I thought you wanted to fix it after -rc1 anyway? >
I've merged Sagi's patches and fixed up the resulting vhost-scsi breakage in target-pending/for-next here: https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=for-next&id=4101fc0abffeef604b14a707a3f9c9e2a8e39085 Only the qla2xxx target DIF related breakage remains, because those patches are going through the scsi/for-next tree and will need to be fixed in -rc2. > > Why don't I simply add Stephen's patch to use vhost_has_feature() in > > target-pending/for-next, and we just make sure that the vhost PULL > > request goes out after target-pending..? > > > > --nab > > I can drop the PI feature bit in rc1. You will apply Sagi's changes and > then enable the feature in rc2? That is not necessary. I'll just apply Stephen's patch to use vhost_has_feature(), and then we make sure that target-pending is merged before vhost to avoid the build breakage. I'll be sending out the target-pending PULL request tomorrow afternoon and will CC' you. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
