[GIT PULL] VFIO updates for v3.8

[GIT PULL] VFIO updates for v3.8

[Alex Williamson]

Hi Linus,

The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:

  Linux 3.7 (2012-12-10 19:30:57 -0800)

are available in the git repository at:

  git://github.com/awilliam/linux-vfio.git tags/vfio-for-v3.8

for you to fetch changes up to a9e3ccfa452c8c5bac49637fe6ece1ac3246d312:

  vfio-pci: Enable device before attempting reset (2012-12-11 11:25:37 -0700)

----------------------------------------------------------------
vfio pull for v3.8

----------------------------------------------------------------
Alex Williamson (2):
      vfio-pci: Re-order device reset
      vfio-pci: Enable device before attempting reset

Fengguang Wu (1):
      vfio: simplify kmalloc+copy_from_user to memdup_user

Jiang Liu (3):
      VFIO: unregister IOMMU notifier on error recovery path
      VFIO: use ACCESS_ONCE() to guard access to dev->driver
      VFIO: fix out of order labels for error recovery in vfio_pci_init()

 drivers/vfio/pci/vfio_pci.c | 83 +++++++++++++++++++++++++--------------------
 drivers/vfio/vfio.c         | 34 +++++++++----------
 2 files changed, 64 insertions(+), 53 deletions(-)

Re: [GIT PULL] VFIO updates for v3.8

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

Hi Linus,

On Tue, 11 Dec 2012 12:08:07 -0700 Alex Williamson <alex.williamson@redhat.com> wrote:
>
> The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
> 
>   Linux 3.7 (2012-12-10 19:30:57 -0800)
> 
> are available in the git repository at:
> 
>   git://github.com/awilliam/linux-vfio.git tags/vfio-for-v3.8
> 
> for you to fetch changes up to a9e3ccfa452c8c5bac49637fe6ece1ac3246d312:
> 
>   vfio-pci: Enable device before attempting reset (2012-12-11 11:25:37 -0700)

This has been rebased from what was in linux-next yesterday onto v3.7.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] VFIO updates for v3.8

[Alex Williamson]

On Wed, 2012-12-12 at 10:46 +1100, Stephen Rothwell wrote:
> Hi Linus,
> 
> On Tue, 11 Dec 2012 12:08:07 -0700 Alex Williamson <alex.williamson@redhat.com> wrote:
> >
> > The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
> > 
> >   Linux 3.7 (2012-12-10 19:30:57 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://github.com/awilliam/linux-vfio.git tags/vfio-for-v3.8
> > 
> > for you to fetch changes up to a9e3ccfa452c8c5bac49637fe6ece1ac3246d312:
> > 
> >   vfio-pci: Enable device before attempting reset (2012-12-11 11:25:37 -0700)
> 
> This has been rebased from what was in linux-next yesterday onto v3.7.

Is that a bad thing?  I can start tagging from my next branch if that's
preferred.  Thanks,

Alex

Re: [GIT PULL] VFIO updates for v3.8

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

Hi Alex,

On Tue, 11 Dec 2012 17:06:56 -0700 Alex Williamson <alex.williamson@redhat.com> wrote:
>
> Is that a bad thing?  I can start tagging from my next branch if that's
> preferred.  Thanks,

Linus has said many times to not rebase before sending a pull request.
When you rebase your tree you effectively throw away your testing (since
the thing you rebased on top of may have introduced semantic conflicts
with the work in your tree).  If you don't rebase your tested tree, any
conflicts are then restricted to the actual merge and can be fixed there
(or at least the diagnosis will lead there).

So, if I was a maintiner, at the start of the merge window (or just
before) I would create a test branch that contained my work plus a
*merge* with Linus' tree and do some testing on that and then ask Linus
to pull my tree (not the merged version).  It may prove that the test
merge with Linus' tree produces an "interesting" syntactic conflict - in
this case I would mention that to Linus and put the merged tree somewhere
public for him to use as a guide.  (Mind you, this conflict would already
have most likely been noted by the linux-next maintainer.)

Also, your testing may have brought to light a semantic conflict, in
which case the fix could be supplied to Linus with the pull request, or a
well changed logged back merge of Linus' tree containing the fix could be
done and Linus asked to pull the result.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] VFIO updates for v3.8

[Alex Williamson]

Hi Stephen,

On Wed, 2012-12-12 at 11:44 +1100, Stephen Rothwell wrote:
> Hi Alex,
> 
> On Tue, 11 Dec 2012 17:06:56 -0700 Alex Williamson <alex.williamson@redhat.com> wrote:
> >
> > Is that a bad thing?  I can start tagging from my next branch if that's
> > preferred.  Thanks,
> 
> Linus has said many times to not rebase before sending a pull request.
> When you rebase your tree you effectively throw away your testing (since
> the thing you rebased on top of may have introduced semantic conflicts
> with the work in your tree).  If you don't rebase your tested tree, any
> conflicts are then restricted to the actual merge and can be fixed there
> (or at least the diagnosis will lead there).
> 
> So, if I was a maintiner, at the start of the merge window (or just
> before) I would create a test branch that contained my work plus a
> *merge* with Linus' tree and do some testing on that and then ask Linus
> to pull my tree (not the merged version).  It may prove that the test
> merge with Linus' tree produces an "interesting" syntactic conflict - in
> this case I would mention that to Linus and put the merged tree somewhere
> public for him to use as a guide.  (Mind you, this conflict would already
> have most likely been noted by the linux-next maintainer.)
> 
> Also, your testing may have brought to light a semantic conflict, in
> which case the fix could be supplied to Linus with the pull request, or a
> well changed logged back merge of Linus' tree containing the fix could be
> done and Linus asked to pull the result.

Thanks for the tip.  I certainly retested after doing the rebase to
v3.7, but I can see the point.  I'll do as you suggest, a merge on a
separate branch for testing only and tag what I currently have in my
next branch.  v2 forthcoming.  Thanks,

Alex