Since 2.6.31-rc8 has been out more than a week already, it's probably
a good time to talk about 2.6.32 merge plans. All the pending things
that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As usual, when submitting a patch:
- Give a good changelog that explains what issue your patch
addresses, how you address the issue, how serious the issue is, and
any other information that would be useful to someone evaluating
your patch or reading it years from now.
- Please make sure that you include a "Signed-off-by:" line, and put
any extra junk that should not go into the final kernel log *after*
the "---" line so that git tools strip it off automatically. Make
the subject line be appropriate for inclusion in the kernel log as
well once the leading "[PATCH ...]" stuff is stripped off. I waste a
lot of time fixing patches by hand that could otherwise be spent
doing something productive like watching youtube.
- Run your patch through checkpatch.pl so I don't have to nag you to
fix trivial issues (or spend time fixing them myself).
- Read your patch over so I don't see a memory leak or deadlock as
soon as I look at it.
- Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
and make sure it doesn't introduce new warnings. (A big bonus in
goodwill for sending patches that fix old warnings)
- Test your patch on a kernel with things like slab debugging and
lockdep turned on.
And while you're waiting for me to get to your patch, I sure wouldn't
mind if you read and commented on someone else's patch. None of this
means you shouldn't remind me about pending patches, since I often
lose track of things and drop them accidentally.
Core:
- Userspace MMU notifiers ("ummunotify") -- my code looks great to
me, seems to have passed review on linux-kernel, and has spent time
in -mm and -next. Jeff Squyres has put together a proof-of-concept
implementation of Open MPI support, so I think all things are go
for asking that this be pulled into 2.6.32. I'll send Linus a
separate pull request for this once the merge window opens.
- Make queue sizes tunable in the MAD module.
- Various fixes and cleanups, including a fix for a lockdep issue in
the MAD module. This fix may evolve if the core kernel API grows
__cancel_delayed_work() to help with this.
ULPs:
- For IPoIB, I merged Jason's patch to check multicast addresses, and
further fixes in this area may be forthcoming.
HW specific:
- A couple of minor amso1100 cleanups/fixes.
- A bunch of fixes to the cxgb3 and nes iWARP drivers.
- A few ehca fixes.
- Some mlx4 and mthca fixes, including using the PCI device name in
interrupt names so multiple devices can be managed.
Here are a few topics that I believe will not be ready in time for the
2.6.32 window and will need to wait for 2.6.33 at least:
- Jack's XRC patch set. I still need time to work through and clean
up the code. (I actually did make some progress on this during
this cycle -- if you look closely you can see my xrc branch has
changed -- but not enough to actually finish unfortunately)
Here all the patches I already have in my for-next branch:
Alexander Schmidt (1):
IB/ehca: Make port autodetect mode the default
Arputham Benjamin (2):
mlx4_core: Distinguish multiple devices in /proc/interrupts
IB/mthca: Distinguish multiple devices in /proc/interrupts
Chien Tung (1):
RDMA/nes: Map MTU to IB_MTU_* and correctly report link state
Don Wood (10):
RDMA/nes: Update refcnt during disconnect
RDMA/nes: Allocate work item for disconnect event handling
RDMA/nes: Change memory allocation for cqp request to GFP_ATOMIC
RDMA/nes: Clean out CQ completions when QP is destroyed
RDMA/nes: Add CQ error handling
RDMA/nes: Implement Terminate Packet
RDMA/nes: Use flush mechanism to set status for wqe in error
RDMA/nes: Make poll_cq return correct number of wqes during flush
RDMA/nes: Use the flush code to fill in cqe error
RDMA/nes: Rework the disconn routine for terminate and flushing
Hal Rosenstock (1):
IB/mad: Allow tuning of QP0 and QP1 sizes
Jack Morgenstein (3):
IB/mthca: Don't allow userspace open while recovering from catastrophic error
IB/mlx4: Don't allow userspace open while recovering from catastrophic error
IB/uverbs: Return ENOSYS for unimplemented commands (not EINVAL)
Jason Gunthorpe (1):
IPoIB: Check multicast address format
Joachim Fenkes (2):
IB/ehca: Construct MAD redirect replies from request MAD
IB/ehca: Fix CQE flags reporting
Marcin Slusarz (1):
IB: Use printk_once() for driver versions
Roel Kluin (2):
IB/ipath: strncpy() doesn't always NUL-terminate
RDMA/amso1100: Check kmalloc() result in c2_register_device()
Roland Dreier (13):
IPoIB: Remove unused <rdma/ib_cache.h> includes
IB: Use DEFINE_SPINLOCK() for static spinlocks
mlx4_core: Use pci_request_regions()
mlx4_core: Remove unnecessary includes of <linux/init.h>
IB/mthca: Remove unnecessary include of <asm/page.h>
IB/mthca: Remove unnecessary include of <linux/init.h>
ummunotify: Userspace support for MMU notifications
IB/mad: Check hop count field in directed route MAD to avoid array overflow
IPoIB: Drop priv->lock before calling ipoib_send()
IB/mlx4: Annotate CQ locking
IB/mthca: Annotate CQ locking
IB/mad: Fix possible lock-lock-timer deadlock
mlx4_core: Allocate and map sufficient ICM memory for EQ context
Steve Wise (5):
RDMA/cxgb3: iwch_unregister_device leaks memory
RDMA/cxgb3: Set the appropriate IO channel in rdma_init work requests
RDMA/cxgb3: Handle port events properly
RDMA/cxgb3: Don't free endpoints early
RDMA/cxgb3: Wake up any waiters on peer close/abort
Tobias Klauser (1):
RDMA/amso1100: Use %pM conversion specifier
Yevgeny Petrilin (1):
mlx4_core: Avoid double free_icms
Yossi Etigin (1):
IB/core: Fix send multicast group leave retry
Roland Dreier wrote:
> Here are a few topics that I believe will not be ready in time for the
> 2.6.32 window and will need to wait for 2.6.33 at least:
>
> - Jack's XRC patch set. I still need time to work through and clean
> up the code. (I actually did make some progress on this during
> this cycle -- if you look closely you can see my xrc branch has
> changed -- but not enough to actually finish unfortunately)
>
>
What about RDMAoE?
Patches were sent few weeks ago and it seems you ignore them.
Tziporet
> What about RDMAoE?
> Patches were sent few weeks ago and it seems you ignore them.
Sorry, I should have mentioned that.
Yes, I have been ignoring the patches -- I want to get through XRC
first, and also I would like to see a real spec for IBoE (that resolves
issues like multicast interaction with IGMP, address resolution, etc) so
we can judge whether the current patches match the long-term direction
or are just a point-in-time hack.
- R.
Roland Dreier wrote:
> > What about RDMAoE?
> > Patches were sent few weeks ago and it seems you ignore them.
>
> Sorry, I should have mentioned that.
>
> Yes, I have been ignoring the patches -- I want to get through XRC
> first,
We can help with XRC if this will expedite the RDMAoE. Will it?
Tziporet
>
>