* [GIT PULL] please pull infiniband.git for-linus
@ 2007-10-13 21:17 Roland Dreier
0 siblings, 0 replies; 17+ messages in thread
From: Roland Dreier @ 2007-10-13 21:17 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, general
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This will get one bug fix for a problem that completely kills the mlx4 driver:
Roland Dreier (1):
mlx4_core: Fix infinite loop on device initialization
drivers/net/mlx4/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index e029b8a..89b3f0b 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -884,7 +884,7 @@ static int __devinit mlx4_init_one(struct pci_dev *pdev,
++mlx4_version_printed;
}
- return mlx4_init_one(pdev, id);
+ return __mlx4_init_one(pdev, id);
}
static void mlx4_remove_one(struct pci_dev *pdev)
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 23:11 ` Rik van Riel
@ 2008-01-03 23:18 ` Dave Dillow
0 siblings, 0 replies; 17+ messages in thread
From: Dave Dillow @ 2008-01-03 23:18 UTC (permalink / raw)
To: Rik van Riel; +Cc: Roland Dreier, general, linux-kernel
On Thu, 2008-01-03 at 18:11 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 15:20:09 -0500
> David Dillow <dillowda@ornl.gov> wrote:
>
> > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> > index 950228f..6e7e3c8 100644
> > --- a/drivers/infiniband/ulp/srp/ib_srp.c
> > +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> > @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
> > list_del(&target->list);
> > spin_unlock(&target->srp_host->target_lock);
> >
> > - srp_remove_host(target->scsi_host);
> > scsi_remove_host(target->scsi_host);
> > + srp_remove_host(target->scsi_host);
> > ib_destroy_cm_id(target->cm_id);
> > srp_free_target_ib(target);
> > scsi_host_put(target->scsi_host);
>
> These last two look suspicious. Are you freeing target before
> freeing target->scsi_host or does the code simply not do what
> it looks like it's doing? :)
>
> (no, I haven't looked at the IB code - I'm probably wrong)
srp_free_target_ib() just frees the buffers for the target, and
scsi_host_put() does the actual cleanup once the refcount drops to zero.
Dave
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 20:20 ` David Dillow
2008-01-03 21:34 ` Roland Dreier
@ 2008-01-03 23:11 ` Rik van Riel
2008-01-03 23:18 ` Dave Dillow
1 sibling, 1 reply; 17+ messages in thread
From: Rik van Riel @ 2008-01-03 23:11 UTC (permalink / raw)
To: David Dillow; +Cc: Roland Dreier, general, linux-kernel
On Thu, 03 Jan 2008 15:20:09 -0500
David Dillow <dillowda@ornl.gov> wrote:
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index 950228f..6e7e3c8 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
> list_del(&target->list);
> spin_unlock(&target->srp_host->target_lock);
>
> - srp_remove_host(target->scsi_host);
> scsi_remove_host(target->scsi_host);
> + srp_remove_host(target->scsi_host);
> ib_destroy_cm_id(target->cm_id);
> srp_free_target_ib(target);
> scsi_host_put(target->scsi_host);
These last two look suspicious. Are you freeing target before
freeing target->scsi_host or does the code simply not do what
it looks like it's doing? :)
(no, I haven't looked at the IB code - I'm probably wrong)
--
All Rights Reversed
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 20:20 ` David Dillow
@ 2008-01-03 21:34 ` Roland Dreier
2008-01-03 23:11 ` Rik van Riel
1 sibling, 0 replies; 17+ messages in thread
From: Roland Dreier @ 2008-01-03 21:34 UTC (permalink / raw)
To: David Dillow; +Cc: torvalds, general, linux-kernel
> @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
> list_del(&target->list);
> spin_unlock(&target->srp_host->target_lock);
>
> - srp_remove_host(target->scsi_host);
> scsi_remove_host(target->scsi_host);
> + srp_remove_host(target->scsi_host);
Thanks... I just confirmed (by crashing my system) that either this
change or the fix to the srp transport class is needed too. I think
we have time before 2.6.24 final to get the right fix in, so I'll wait
until tomorrow before asking Linus to pull this.
- R.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 20:13 ` David Dillow
@ 2008-01-03 20:20 ` David Dillow
2008-01-03 21:34 ` Roland Dreier
2008-01-03 23:11 ` Rik van Riel
0 siblings, 2 replies; 17+ messages in thread
From: David Dillow @ 2008-01-03 20:20 UTC (permalink / raw)
To: Roland Dreier; +Cc: torvalds, general, linux-kernel
Subject: IB/srp: Fix list corruption/oops on module reload
ib_srp doesn't clean up the transport attributes properly when
unloading, so it leaves references around to free'd memory.
The srp_remove_host() cannot go before the scsi_remove_host() call as
the documented call sequence suggests, as it will cause an oops when the
SRP transport code will free up an object that is not its own. So,
temporarily reorder the calls in srp_remove_work() to avoid the problem
as well until the transport code can be fixed.
Signed-off-by: David Dillow <dillowda@ornl.gov>
---
On Thu, 2008-01-03 at 15:13 -0500, David Dillow wrote:
> I'll send a new patch to you for just the ib_srp.c side.
Should've just sent it with the last email.
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..6e7e3c8 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
list_del(&target->list);
spin_unlock(&target->srp_host->target_lock);
- srp_remove_host(target->scsi_host);
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
scsi_host_put(target->scsi_host);
@@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
list_for_each_entry_safe(target, tmp_target,
&host->target_list, list) {
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 18:56 ` Roland Dreier
@ 2008-01-03 20:13 ` David Dillow
2008-01-03 20:20 ` David Dillow
0 siblings, 1 reply; 17+ messages in thread
From: David Dillow @ 2008-01-03 20:13 UTC (permalink / raw)
To: Roland Dreier; +Cc: torvalds, general, linux-kernel
On Thu, 2008-01-03 at 10:56 -0800, Roland Dreier wrote:
> > If we've got time before 2.6.24 final, I'd wait on this a bit.
> > ib_srp:srp_remove_work() has them reversed as well, and I'm currently
> > tracking down why it oopses when the srp_remove_host() happens before
> > the scsi_remove_host(), which is the documented call sequence.
>
> I think the best thing to do is to merge this (assuming that Linus
> gets to it), since it looks quite safe and definitely fixes a crash.
> Then if we get to the root cause we can change the order of the calls
> if it turns out a different fix is required.
I've made progress on the root cause (posted in another thread), but we
need to fix ib_srp.c:srp_remove_work() as well, as I think it will have
the same issue. It will only be hit if we cannot reconnect to the
target, so it probably doesn't see a lot of use.
I'll send a new patch to you for just the ib_srp.c side.
Dave
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 18:39 ` David Dillow
@ 2008-01-03 18:56 ` Roland Dreier
2008-01-03 20:13 ` David Dillow
0 siblings, 1 reply; 17+ messages in thread
From: Roland Dreier @ 2008-01-03 18:56 UTC (permalink / raw)
To: David Dillow; +Cc: torvalds, general, linux-kernel
> If we've got time before 2.6.24 final, I'd wait on this a bit.
> ib_srp:srp_remove_work() has them reversed as well, and I'm currently
> tracking down why it oopses when the srp_remove_host() happens before
> the scsi_remove_host(), which is the documented call sequence.
I think the best thing to do is to merge this (assuming that Linus
gets to it), since it looks quite safe and definitely fixes a crash.
Then if we get to the root cause we can change the order of the calls
if it turns out a different fix is required.
- R.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2008-01-03 18:29 Roland Dreier
@ 2008-01-03 18:39 ` David Dillow
2008-01-03 18:56 ` Roland Dreier
0 siblings, 1 reply; 17+ messages in thread
From: David Dillow @ 2008-01-03 18:39 UTC (permalink / raw)
To: Roland Dreier; +Cc: torvalds, general, linux-kernel
On Thu, 2008-01-03 at 10:29 -0800, Roland Dreier wrote:
> Linus, please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
>
> This will pull one fix for an oops caused by reloading the ib_srp module:
>
> David Dillow (1):
> IB/srp: Fix list corruption/oops on module reload
If we've got time before 2.6.24 final, I'd wait on this a bit.
ib_srp:srp_remove_work() has them reversed as well, and I'm currently
tracking down why it oopses when the srp_remove_host() happens before
the scsi_remove_host(), which is the documented call sequence.
This "fixes" the oops I see on unload, but I'm sure it is a correct fix.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [GIT PULL] please pull infiniband.git for-linus
@ 2008-01-03 18:29 Roland Dreier
2008-01-03 18:39 ` David Dillow
0 siblings, 1 reply; 17+ messages in thread
From: Roland Dreier @ 2008-01-03 18:29 UTC (permalink / raw)
To: torvalds; +Cc: general, linux-kernel
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This will pull one fix for an oops caused by reloading the ib_srp module:
David Dillow (1):
IB/srp: Fix list corruption/oops on module reload
drivers/infiniband/ulp/srp/ib_srp.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..77e8b90 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
list_for_each_entry_safe(target, tmp_target,
&host->target_list, list) {
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 1:17 ` David Miller
2007-10-12 2:58 ` Linus Torvalds
@ 2007-10-13 1:10 ` Andrew Morton
1 sibling, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2007-10-13 1:10 UTC (permalink / raw)
To: David Miller; +Cc: rdreier, torvalds, general, linux-kernel, jeff
On Thu, 11 Oct 2007 18:17:19 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Roland Dreier <rdreier@cisco.com>
> Date: Thu, 11 Oct 2007 18:08:52 -0700
>
> > This will get the batch of changes queued up for the 2.6.24 merge
> > window (although I still have a few more things to merge later, once
> > Dave Miller's networking tree has landed too):
>
> Roland are you absolutely sure this won't create merge conflicts with
> my 8MB net-2.6 merge, inside of which there are many infiniband
> driver changes?
I'd have told him if there were any such problems.
There might of course be runtime problems, but I'm sure the infiniband
developers are testing -mm kernels so that any such problems will be
picked up beforehand (heh, I kill me).
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 2:58 ` Linus Torvalds
2007-10-12 3:28 ` David Miller
2007-10-12 3:52 ` Greg KH
@ 2007-10-12 12:58 ` Jeff Garzik
2 siblings, 0 replies; 17+ messages in thread
From: Jeff Garzik @ 2007-10-12 12:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, rdreier, general, Linux Kernel Mailing List,
Greg Kroah-Hartman
Linus Torvalds wrote:
> Oh, and obviously, the NAPI changes may well have resulted in a merge that
> had no actual *conflicts* in it, but whether the end result works or not
> (and whether any IB drivers need updating due to the NAPI changes), I
> cannot tell. I've pushed out my tree, so people who are competent or just
> morbidly curious should start looking at it: it's got the following things
> merged now:
>
> - x86 merge
> - mmc
> - v4l-dvb
> - blackfin
> - avr32
> - block layer updates
> - Jeff's dmi-const
> - Purdie's blacklight and led trees
> - ide
> - mips
> - net
> - infiniband
>
> and it all builds for me, but hey, I don't use half of it.
works here on intel x86-64, amd64, and 32-bit pentium4.
and without disk corruption, so I may now attend to the libata merge :)
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 3:52 ` Greg KH
@ 2007-10-12 4:03 ` Linus Torvalds
0 siblings, 0 replies; 17+ messages in thread
From: Linus Torvalds @ 2007-10-12 4:03 UTC (permalink / raw)
To: Greg KH; +Cc: David Miller, rdreier, general, Linux Kernel Mailing List, jeff
On Thu, 11 Oct 2007, Greg KH wrote:
> On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote:
> >
> > So I merged it all, and I don't expect any problems, but I'm hoping
> > somebody is thinking about that mod_devicetable.h/file2alias.c mess.
> >
> > I'm not entirely sure who to blame on that thing. I'm adding Greg to the
> > Cc, on the assumption that blaming him is usually the right thing to do ;)
>
> Hey, it wasn't me this time, I haven't even built my trees for you to
> pull from and break everything yet :)
No, I meant more in the "who the hell is responsible for designing those
*files*" rather than who is responsible for the particular merge mess
that happened to involve them this time around.
> But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
> good idea, I'll see what I can come up with tomorrow.
I don't think it's a huge issue, but I wanted to bring it up because these
days we're normally so good with these kinds of things that it actually
stood out a bit. I used to do these kinds of nasty merges all the time
with init/main.c and the configuration files, until we split them up.
So I'm certainly perfectly able and used to doing them, it's just that I
also think that we have generally learnt to do so much better.
In other words: no hurry or pressure, I just wanted to bring it up, since
during the merge I got flashbacks to various "bad old times" that I had
hoped we had mostly left behind.
Those files were originally designed/set up by Rusty. I could have blamed
him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I
think this kind of smells like a "device model"ish thing...
Hmm?
Linus
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 2:58 ` Linus Torvalds
2007-10-12 3:28 ` David Miller
@ 2007-10-12 3:52 ` Greg KH
2007-10-12 4:03 ` Linus Torvalds
2007-10-12 12:58 ` Jeff Garzik
2 siblings, 1 reply; 17+ messages in thread
From: Greg KH @ 2007-10-12 3:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, rdreier, general, Linux Kernel Mailing List, jeff
On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote:
>
> So I merged it all, and I don't expect any problems, but I'm hoping
> somebody is thinking about that mod_devicetable.h/file2alias.c mess.
>
> I'm not entirely sure who to blame on that thing. I'm adding Greg to the
> Cc, on the assumption that blaming him is usually the right thing to do ;)
Hey, it wasn't me this time, I haven't even built my trees for you to
pull from and break everything yet :)
But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
good idea, I'll see what I can come up with tomorrow.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 2:58 ` Linus Torvalds
@ 2007-10-12 3:28 ` David Miller
2007-10-12 3:52 ` Greg KH
2007-10-12 12:58 ` Jeff Garzik
2 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2007-10-12 3:28 UTC (permalink / raw)
To: torvalds; +Cc: rdreier, general, linux-kernel, jeff, gregkh
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 11 Oct 2007 19:58:04 -0700 (PDT)
>
>
> On Thu, 11 Oct 2007, David Miller wrote:
> >
> > Even if you're confident there won't be merge issues, could you just
> > wait for the net-2.6 stuff to go in first?
>
> I pulled the net stuff first, and merged the IB stuff afterwards. No
> conflicts in IB, but there *were* conflicts with the networking pull for
> other reasons.
>
> That horrid, horrid mess that is called include/linux/mod_devicetable.h
> and scripts/mod/file2alias.c must go at some point. The thing is
> unmaintainable. Different maintainers add their own structures to both,
> and functions to both, and it's just messy. That's not how maintainable
> and modularized code should be written.
>
> Now it broke on sdio vs ssb, but there was actually a conflict earlier
> with the Kbuild merge (which I aborted for other reasons), so this file
> really is starting to be a problem.
>
> The merge was fairly straightforward and stupid - it's not like the code
> added is *complicated*, but all those small functions and structrues are
> set up to be a maze of very similar lines, so the merge is actually much
> worse than it should be - because there is inherent similarity, some lines
> are automatically auto-merged, making the result just harder to visualize.
>
> So I merged it all, and I don't expect any problems, but I'm hoping
> somebody is thinking about that mod_devicetable.h/file2alias.c mess.
It all looks good from here.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 1:17 ` David Miller
@ 2007-10-12 2:58 ` Linus Torvalds
2007-10-12 3:28 ` David Miller
` (2 more replies)
2007-10-13 1:10 ` Andrew Morton
1 sibling, 3 replies; 17+ messages in thread
From: Linus Torvalds @ 2007-10-12 2:58 UTC (permalink / raw)
To: David Miller
Cc: rdreier, general, Linux Kernel Mailing List, jeff, Greg Kroah-Hartman
On Thu, 11 Oct 2007, David Miller wrote:
>
> Even if you're confident there won't be merge issues, could you just
> wait for the net-2.6 stuff to go in first?
I pulled the net stuff first, and merged the IB stuff afterwards. No
conflicts in IB, but there *were* conflicts with the networking pull for
other reasons.
That horrid, horrid mess that is called include/linux/mod_devicetable.h
and scripts/mod/file2alias.c must go at some point. The thing is
unmaintainable. Different maintainers add their own structures to both,
and functions to both, and it's just messy. That's not how maintainable
and modularized code should be written.
Now it broke on sdio vs ssb, but there was actually a conflict earlier
with the Kbuild merge (which I aborted for other reasons), so this file
really is starting to be a problem.
The merge was fairly straightforward and stupid - it's not like the code
added is *complicated*, but all those small functions and structrues are
set up to be a maze of very similar lines, so the merge is actually much
worse than it should be - because there is inherent similarity, some lines
are automatically auto-merged, making the result just harder to visualize.
So I merged it all, and I don't expect any problems, but I'm hoping
somebody is thinking about that mod_devicetable.h/file2alias.c mess.
I'm not entirely sure who to blame on that thing. I'm adding Greg to the
Cc, on the assumption that blaming him is usually the right thing to do ;)
Oh, and obviously, the NAPI changes may well have resulted in a merge that
had no actual *conflicts* in it, but whether the end result works or not
(and whether any IB drivers need updating due to the NAPI changes), I
cannot tell. I've pushed out my tree, so people who are competent or just
morbidly curious should start looking at it: it's got the following things
merged now:
- x86 merge
- mmc
- v4l-dvb
- blackfin
- avr32
- block layer updates
- Jeff's dmi-const
- Purdie's blacklight and led trees
- ide
- mips
- net
- infiniband
and it all builds for me, but hey, I don't use half of it.
Oh, btw, one final note: because of just a *ton* of renames, if you
actually want git to do rename-detection for you and do automatic merges
across those x86 renames, you should likely add
[diff]
renamelimit=0
to your .gitconfig file. Otherwise, the rename detection heuristics may
end up saying "I'm not going to even bother finding renames in that mess".
(That final note really shouldn't affect any normal users, but I thought
I'd mention it in case somebody is going to want git to merge things
across the x86 merge, and gets stuck not realizing why some versions of
git might not notice the renames).
Linus
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] please pull infiniband.git for-linus
2007-10-12 1:08 Roland Dreier
@ 2007-10-12 1:17 ` David Miller
2007-10-12 2:58 ` Linus Torvalds
2007-10-13 1:10 ` Andrew Morton
0 siblings, 2 replies; 17+ messages in thread
From: David Miller @ 2007-10-12 1:17 UTC (permalink / raw)
To: rdreier; +Cc: torvalds, general, linux-kernel, jeff
From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 11 Oct 2007 18:08:52 -0700
> This will get the batch of changes queued up for the 2.6.24 merge
> window (although I still have a few more things to merge later, once
> Dave Miller's networking tree has landed too):
Roland are you absolutely sure this won't create merge conflicts with
my 8MB net-2.6 merge, inside of which there are many infiniband
driver changes?
I really wish you would submit your inifiniband work through normal
network driver channels, such as Jeff Garzik. Jeff has been syncing
on almost a daily basis with me so that I wouldn't have to worry about
changes coming out of left field and adding additional merge issues
for an already difficult merge.
Even if you're confident there won't be merge issues, could you just
wait for the net-2.6 stuff to go in first?
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [GIT PULL] please pull infiniband.git for-linus
@ 2007-10-12 1:08 Roland Dreier
2007-10-12 1:17 ` David Miller
0 siblings, 1 reply; 17+ messages in thread
From: Roland Dreier @ 2007-10-12 1:08 UTC (permalink / raw)
To: torvalds; +Cc: general, linux-kernel
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This will get the batch of changes queued up for the 2.6.24 merge
window (although I still have a few more things to merge later, once
Dave Miller's networking tree has landed too):
Ali Ayoub (1):
IB/sa: Error handling thinko fix
Anton Blanchard (3):
IB/fmr_pool: Clean up some error messages in fmr_pool.c
IB/ehca: Make output clearer by removing some debug messages
IB/ehca: Export module parameters in sysfs
Arthur Jones (4):
IB/ipath: iba6110 rev4 GPIO counters support
IB/ipath: Use counters in ipath_poll and cleanup interrupts in ipath_close
IB/ipath: iba6110 rev4 no longer needs recv header overrun workaround
IB/ipath: Indicate a couple of chip bugs to userspace
Dave Olson (5):
IB/ipath: Verify host bus bandwidth to chip will not limit performance
IB/ipath: Correctly describe workaround for TID write chip bug
IB/ipath: Future proof eeprom checksum code (contents reading)
IB/ipath: Fix QHT7040 serial number check
IB/ipath: Minor fix to ordering of freeing and zeroing of tid pages.
Dotan Barak (2):
mlx4_core: Use enum value GO_BIT_TIMEOUT_MSECS
IPoIB/cm: Clean up initialization of QP attr in ipoib_cm_create_tx_qp()
Eli Cohen (3):
IPoIB: Fix typo to end statement with ';' instead of ','
IPoIB: Fix error path memory leak
IB/mthca: Mark error paths as unlikely() in post_srq_recv functions
Hoang-Nam Nguyen (4):
IB/ehca: Use remap_4k_pfn() to map firmware contexts to user space
IB/ehca: Fix large page HW cap defines
IB/ehca: Fix mem leak of firmware ctrlblock in ehca_create_srq()
IB/ehca: Adjust 64-bit alignment of create QP response for userspace
Jack Morgenstein (5):
IB/mlx4: Display misc device information under /sys/class/infiniband/
mlx4_core: Support ICM tables in coherent memory
mlx4_core: Write MTTs from CPU instead with of WRITE_MTT FW command
IB/mlx4: Implement FMRs
mlx4_core: Increase max number of QPs per multicast group to 56
Joachim Fenkes (11):
IB/ehca: Refactor hvcall tracing
IB/ehca: Print return codes as signed decimal integers
IB/ehca: ehca_gen_warn() should always print
IB/ehca: Add check for max #SGE to create_qp()
IB/ehca: Path migration support
IB/ehca: Serialize MR alloc and MR free hvCalls
IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id()
IB/ehca: Bump version number and change its format
IB/umem: Add hugetlb flag to struct ib_umem
IB/ehca: Only use MR large pages for hugetlb regions
IB/ehca: Return srq_attr->max_sge in ehca_query_srq()
Michael Albaugh (2):
IB/ipath: Maintain active time on all chips
IB/ipath: Better handling of unexpected GPIO interrupts
Michael S. Tsirkin (2):
mlx4_core: Enable MSI-X by default
IB/mthca: Enable MSI-X by default
Or Gerlitz (1):
IPoIB: Allow setting policy to ignore multicast groups
Peter Oruba (1):
IB/mthca: Use PCI-X/PCI-Express read control interfaces
Ralph Campbell (13):
IB/core: Fix handling of multicast response failures
IB/ipath: Performance optimization for CPU differences
IB/ipath: Change UD to queue work requests like RC & UC
IB/ipath: Remove unneeded code for ipathfs
IB/ipath: UC RDMA WRITE with IMMEDIATE doesn't send the immediate
IB/ipath: Remove redundant code
IB/ipath: Generate flush CQE when QP is in error state
IB/ipath: Implement IB_EVENT_QP_LAST_WQE_REACHED
IB/ipath: Optimize completion queue entry insertion and polling
IB/ipath: Add ability to set the LMC via the sysfs debugging interface
IB/ipath: Remove duplicate copy of LMC
IB/ipath: Fix IB_EVENT_PORT_ERR event
IB/ipath: Remove redundant link state checks
Roland Dreier (18):
IPoIB: Make sure no receives are handled when stopping device
IB: find_first_zero_bit() takes unsigned pointer
mlx4_core: Don't free special QPs in QP number bitmap
IB/mlx4: Use __set_data_seg() in mlx4_ib_post_recv()
IB/ehca: Include <linux/mutex.h> from ehca_classes.h
IB/mlx4: Fix up SRQ limit_watermark endianness
IB/iser: Remove unnecessary includes
mlx4_core: Change capability decoding: SRC->XRC
IB/umad: Add P_Key index support
IB/umad: Fix bit ordering and 32-on-64 problems on big endian systems
IB/uverbs: Make ib_uverbs_release_event_file() static
mlx4_core: Reserve the correct number of MTT segments
mlx4_core: Fix meaning of dev->caps.reserved_mtts
IB/mthca: Increase max number of QPs per multicast group to 56
IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up
mlx4_core: Use mmiowb() to avoid firmware commands getting jumbled up
IB/ehca: Fix clipping of device limits to INT_MAX
mlx4_core: Fix section mismatches
Satyam Sharma (1):
IB/ehca: Misc cpuinit section annotations and #ifdef cleanups
Sean Hefty (7):
IPoIB: Specify Traffic Class with path record queries for QoS support
IB/sa: Add new QoS fields to path record
RDMA/cma: Add ability to specify type of service
RDMA/ucma: Allow user space to set service type
IB/srp: Add QoS support through service ID
IB/cm: Modify interface to send MRAs in response to duplicate messages
RDMA/cma: Queue IB CM MRAs to avoid unnecessary remote retries
Stefan Roscher (2):
IB/ehca: Small QP userspace support
IB/ehca: Support more than 4k QPs for userspace and kernelspace
Steve Wise (2):
RDMA/cxgb3: Make the iw_cxgb3 module parameters writable
RDMA/cma: Use neigh_event_send() to start neighbour discovery
Documentation/infiniband/user_mad.txt | 14 +
drivers/infiniband/core/addr.c | 3 +-
drivers/infiniband/core/cm.c | 51 ++--
drivers/infiniband/core/cma.c | 46 +++-
drivers/infiniband/core/device.c | 4 +-
drivers/infiniband/core/fmr_pool.c | 22 +-
drivers/infiniband/core/multicast.c | 2 +-
drivers/infiniband/core/sa_query.c | 12 +-
drivers/infiniband/core/ucma.c | 74 +++++-
drivers/infiniband/core/umem.c | 20 ++-
drivers/infiniband/core/user_mad.c | 151 +++++++---
drivers/infiniband/core/uverbs.h | 1 -
drivers/infiniband/core/uverbs_main.c | 16 +-
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16 +-
drivers/infiniband/hw/ehca/ehca_classes.h | 14 +-
drivers/infiniband/hw/ehca/ehca_cq.c | 23 +-
drivers/infiniband/hw/ehca/ehca_hca.c | 34 +-
drivers/infiniband/hw/ehca/ehca_irq.c | 33 +--
drivers/infiniband/hw/ehca/ehca_main.c | 52 ++--
drivers/infiniband/hw/ehca/ehca_mcast.c | 4 +-
drivers/infiniband/hw/ehca/ehca_mrmw.c | 102 ++++----
drivers/infiniband/hw/ehca/ehca_qp.c | 169 +++++++----
drivers/infiniband/hw/ehca/ehca_reqs.c | 2 +-
drivers/infiniband/hw/ehca/ehca_sqp.c | 2 +-
drivers/infiniband/hw/ehca/ehca_tools.h | 19 +-
drivers/infiniband/hw/ehca/ehca_uverbs.c | 46 ++--
drivers/infiniband/hw/ehca/hcp_if.c | 105 ++++---
drivers/infiniband/hw/ehca/ipz_pt_fn.c | 1 +
drivers/infiniband/hw/ipath/ipath_common.h | 4 +-
drivers/infiniband/hw/ipath/ipath_cq.c | 94 +++---
drivers/infiniband/hw/ipath/ipath_diag.c | 22 +-
drivers/infiniband/hw/ipath/ipath_driver.c | 93 ++++++-
drivers/infiniband/hw/ipath/ipath_eeprom.c | 10 +-
drivers/infiniband/hw/ipath/ipath_file_ops.c | 74 +++--
drivers/infiniband/hw/ipath/ipath_fs.c | 187 ------------
drivers/infiniband/hw/ipath/ipath_iba6110.c | 57 ++--
drivers/infiniband/hw/ipath/ipath_iba6120.c | 18 +-
drivers/infiniband/hw/ipath/ipath_intr.c | 64 +++--
drivers/infiniband/hw/ipath/ipath_kernel.h | 12 +-
drivers/infiniband/hw/ipath/ipath_mad.c | 53 ++--
drivers/infiniband/hw/ipath/ipath_qp.c | 31 ++-
drivers/infiniband/hw/ipath/ipath_rc.c | 73 ++++--
drivers/infiniband/hw/ipath/ipath_ruc.c | 308 +++++++-------------
drivers/infiniband/hw/ipath/ipath_stats.c | 17 +-
drivers/infiniband/hw/ipath/ipath_sysfs.c | 40 +++-
drivers/infiniband/hw/ipath/ipath_uc.c | 98 +++----
drivers/infiniband/hw/ipath/ipath_ud.c | 382 ++++++++----------------
drivers/infiniband/hw/ipath/ipath_verbs.c | 329 ++++++++++++++-------
drivers/infiniband/hw/ipath/ipath_verbs.h | 45 ++-
drivers/infiniband/hw/mlx4/main.c | 50 +++
drivers/infiniband/hw/mlx4/mlx4_ib.h | 16 +
drivers/infiniband/hw/mlx4/mr.c | 100 ++++++-
drivers/infiniband/hw/mlx4/qp.c | 14 +-
drivers/infiniband/hw/mlx4/srq.c | 2 +-
drivers/infiniband/hw/mthca/mthca_cmd.c | 6 +
drivers/infiniband/hw/mthca/mthca_dev.h | 2 +-
drivers/infiniband/hw/mthca/mthca_main.c | 110 ++++----
drivers/infiniband/hw/mthca/mthca_srq.c | 8 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 24 ++-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 18 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 8 +
drivers/infiniband/ulp/ipoib/ipoib_main.c | 45 +++-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 31 +--
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 2 +
drivers/infiniband/ulp/iser/iser_initiator.c | 2 -
drivers/infiniband/ulp/iser/iser_memory.c | 2 -
drivers/infiniband/ulp/iser/iser_verbs.c | 1 -
drivers/infiniband/ulp/srp/ib_srp.c | 2 +
drivers/net/mlx4/cmd.c | 11 +-
drivers/net/mlx4/cq.c | 2 +-
drivers/net/mlx4/eq.c | 13 +-
drivers/net/mlx4/fw.c | 2 +-
drivers/net/mlx4/icm.c | 134 +++++++--
drivers/net/mlx4/icm.h | 9 +-
drivers/net/mlx4/main.c | 130 +++++----
drivers/net/mlx4/mcg.c | 2 +-
drivers/net/mlx4/mlx4.h | 10 +-
drivers/net/mlx4/mr.c | 242 +++++++++++++---
drivers/net/mlx4/pd.c | 2 +-
drivers/net/mlx4/qp.c | 5 +-
drivers/net/mlx4/srq.c | 4 +-
include/linux/mlx4/device.h | 27 ++
include/rdma/ib_cm.h | 7 +-
include/rdma/ib_sa.h | 11 +-
include/rdma/ib_umem.h | 1 +
include/rdma/ib_user_mad.h | 70 +++++-
include/rdma/rdma_cm.h | 14 +
include/rdma/rdma_user_cm.h | 18 ++
89 files changed, 2498 insertions(+), 1710 deletions(-)
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-01-03 23:25 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-13 21:17 [GIT PULL] please pull infiniband.git for-linus Roland Dreier
-- strict thread matches above, loose matches on Subject: below --
2008-01-03 18:29 Roland Dreier
2008-01-03 18:39 ` David Dillow
2008-01-03 18:56 ` Roland Dreier
2008-01-03 20:13 ` David Dillow
2008-01-03 20:20 ` David Dillow
2008-01-03 21:34 ` Roland Dreier
2008-01-03 23:11 ` Rik van Riel
2008-01-03 23:18 ` Dave Dillow
2007-10-12 1:08 Roland Dreier
2007-10-12 1:17 ` David Miller
2007-10-12 2:58 ` Linus Torvalds
2007-10-12 3:28 ` David Miller
2007-10-12 3:52 ` Greg KH
2007-10-12 4:03 ` Linus Torvalds
2007-10-12 12:58 ` Jeff Garzik
2007-10-13 1:10 ` Andrew Morton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.