On Sun, Nov 1, 2015 at 11:56 PM, Stephen Rothwell wrote:
> On Sun, 1 Nov 2015 17:00:22 +0200 Or Gerlitz wrote:
>> Stephen, is the framework for linux-next merge tests OK with this tag?
>> can you confirm that the-next bits of the rdma tree are covered fine?
> linux-next fetches the "for-next" t
On Mon, Nov 02, 2015 at 09:03:35PM -0500, Doug Ledford wrote:
> No, one kernel consumer that never worked on iWARP before now works on a
> different iWARP controller but doesn't work on the old iWARP controller.
> Hardly the end of the world.
NFS is gone/going as well, and that used to work. No
On Mon, Nov 02, 2015 at 10:14:06PM -0500, Doug Ledford wrote:
> On 11/02/2015 07:49 PM, Greg Kroah-Hartman wrote:
> > On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
> >>> so overall it still benifits being in the
> >>> staging tree, so a few minor breakages every once in a while shou
On Mon, Nov 02, 2015 at 09:03:35PM -0500, Doug Ledford wrote:
> On 11/02/2015 08:28 PM, Jason Gunthorpe wrote:
> > On Mon, Nov 02, 2015 at 07:52:05PM -0500, Doug Ledford wrote:
> >> It shouldn't be. I reviewed those changes and they looked right (given
> >> the limitations). All you needed was to
On 11/02/2015 07:49 PM, Greg Kroah-Hartman wrote:
> On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
>>> so overall it still benifits being in the
>>> staging tree, so a few minor breakages every once in a while should be
>>> easy for you to fix up, _if_ they happen.
>>>
>>> Again, I d
On 11/02/2015 08:28 PM, Jason Gunthorpe wrote:
> On Mon, Nov 02, 2015 at 07:52:05PM -0500, Doug Ledford wrote:
>> It shouldn't be. I reviewed those changes and they looked right (given
>> the limitations). All you needed was to boot with nopat on the kernel
>> command line to get the old kernel b
On Mon, Nov 02, 2015 at 07:52:05PM -0500, Doug Ledford wrote:
> It shouldn't be. I reviewed those changes and they looked right (given
> the limitations). All you needed was to boot with nopat on the kernel
> command line to get the old kernel behavior and it would continue to
> work as before, a
On 11/02/2015 07:18 PM, Jason Gunthorpe wrote:
> On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
>
>> Because they are *scheduled* for removal. If I simply didn't care if
>> they went away, then I wouldn't screw around with deprecating them or
>> tagging them to be removed, I'd just
On Mon, Nov 02, 2015 at 05:18:45PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
>
> > Because they are *scheduled* for removal. If I simply didn't care if
> > they went away, then I wouldn't screw around with deprecating them or
> > tagging them to
On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
> > so overall it still benifits being in the
> > staging tree, so a few minor breakages every once in a while should be
> > easy for you to fix up, _if_ they happen.
> >
> > Again, I don't know of any recent api change that has caused
On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote:
> Because they are *scheduled* for removal. If I simply didn't care if
> they went away, then I wouldn't screw around with deprecating them or
> tagging them to be removed, I'd just delete them. Breaking them before
> the scheduled re
On 11/02/2015 06:37 PM, Greg Kroah-Hartman wrote:
> On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote:
>> 1) Aging, but working, drivers that will be removed in the future.
>> Since we no longer have a deprecation mechanism, I was informed that the
>> normal procedure now is to move the
On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote:
> 1) Aging, but working, drivers that will be removed in the future.
> Since we no longer have a deprecation mechanism, I was informed that the
> normal procedure now is to move the driver to staging for a while and
> then remove it perm
On 11/01/2015 01:06 PM, Greg Kroah-Hartman wrote:
> On Sun, Nov 01, 2015 at 02:10:48PM +0200, Or Gerlitz wrote:
>> On 10/29/2015 1:51 PM, Christoph Hellwig wrote:
>>> On Wed, Oct 28, 2015 at 10:57:59PM -0400, Doug Ledford wrote:
>>> I had to do a minor hand merge to get this to apply, but it ha
On 11/02/2015 04:16 PM, Chuck Lever wrote:
>
>> On Nov 2, 2015, at 3:43 PM, Anna Schumaker wrote:
>>
>> Hi Chuck,
>>
>> Sorry for the delay in reviewing.
>>
>> On 10/24/2015 05:28 PM, Chuck Lever wrote:
>>> Forechannel transports get their own "bc_up" method to create an
>>> endpoint for the back
> On Nov 2, 2015, at 3:43 PM, Anna Schumaker wrote:
>
> Hi Chuck,
>
> Sorry for the delay in reviewing.
>
> On 10/24/2015 05:28 PM, Chuck Lever wrote:
>> Forechannel transports get their own "bc_up" method to create an
>> endpoint for the backchannel service.
>>
>> Signed-off-by: Chuck Lever
Hi Chuck,
Sorry for the delay in reviewing.
On 10/24/2015 05:28 PM, Chuck Lever wrote:
> Forechannel transports get their own "bc_up" method to create an
> endpoint for the backchannel service.
>
> Signed-off-by: Chuck Lever
> ---
> fs/nfs/callback.c | 40
> +++--
On Mon, Nov 02, 2015 at 12:13:25PM -0500, Mike Marciniszyn wrote:
> The current implementation gets a spin_lock, and at any scale with
> qib and hfi1 post send, the lock contention grows exponentially
> with the number of QPs.
>
> idr_find() is RCU compatibile, so read doesn't need the lock.
>
>
The current implementation gets a spin_lock, and at any scale with
qib and hfi1 post send, the lock contention grows exponentially
with the number of QPs.
idr_find() is RCU compatibile, so read doesn't need the lock.
Change to use rcu_read_lock() and rcu_read_unlock() in
__idr_get_uobj().
kfree_
From: Easwar Hariharan
Minor errors found via code inspection during future development.
SFF 8636 defines bit position 2 to hold the status indication of
QSFP memory paging. The mask used to test for the value was
incorrect and is fixed in this patch. Additionally, the dump
function had a mismatc
On Mon, Nov 02, 2015 at 03:46:52PM +0200, Moni Shoua wrote:
get_lid()
Provides the LID
LID is a special case of L2 address (MAC is another special case)
Maybe change this to het_l2()?
I'm not particularly tied to the name, we can certainly change it to
something else. I assume that's
On 10/24/2015 02:41 PM, Chuck Lever wrote:
>
>> On Oct 23, 2015, at 4:44 PM, Anna Schumaker
>> wrote:
>>
>> Hi Trond,
>>
>> The following changes since commit 7379047d5585187d1288486d4627873170d0005a:
>>
>> Linux 4.3-rc6 (2015-10-18 16:08:42 -0700)
>>
>> are available in the git repository at:
On Thu, Oct 29, 2015 at 9:41 PM, Dennis Dalessandro
wrote:
> Hi Folks,
>
> I had previously posted a notice about the very beginnings of the rdmavt
> driver which is the software verbs consolidation for multiple drivers [1].
> I have now pushed another set of updates to a GitHub repo [2] which
>
On 29/10/2015 20:46, Parav Pandit wrote:
> On Thu, Oct 29, 2015 at 8:27 PM, Haggai Eran wrote:
>> On 28/10/2015 10:29, Parav Pandit wrote:
>>> 3. Resources are not defined by the RDMA cgroup. Resources are defined
>>> by RDMA/IB subsystem and optionally by HCA vendor device drivers.
>>> Rationale:
On Wed, Oct 21, 2015 at 9:21 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The remove_keys() logic is performed as garbage collection task. Such
> task is intended to be run when no other active processes are running.
>
> The need_resched() will return TRUE if there are user tasks to be
On Sun, Nov 1, 2015 at 8:23 AM, Saurabh Sengar wrote:
> ipoib_mcast_alloc is called only in atomic context,
> hence removing the extra check.
>
> Signed-off-by: Saurabh Sengar
Acked-by: Erez Shitrit
> ---
> Hi,
> Even if in future, if there are some functions expected to call it in normal
> c
26 matches
Mail list logo
