> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue
>
> On Mon, Nov 11, 2019 at 04:34:52PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > swap_activate() and swap_deactivate() have nothing to do with address
> > spaces. We want to eventually make the address space operations
> > dynamic to switch inode flags on the fly. So to simp
>
> On Mon, 11 Nov 2019 16:34:52 -0800 ira.we...@intel.com wrote:
>
> > From: Ira Weiny
> >
> > swap_activate() and swap_deactivate() have nothing to do with address
> > spaces. We want to eventually make the address space operations
> > dynamic to switch inode flags on the fly.
>
> What does
> Subject: [PATCH v1] libnvdimm: fix kernel-doc notation
>
> Fix kernel-doc notation in drivers/nvdimm/namespace_devs.c.
>
> Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace
> instantiation.")
> Signed-off-by: Liguang Zhang
Reviewed-by: Ira Weiny
> ---
> drivers/nvdimm/namespac
> Fix kernel-doc notation in drivers/nvdimm/namespace_devs.c.
>
> Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace
> instantiation.")
> Signed-off-by: Liguang Zhang
> ---
> drivers/nvdimm/namespace_devs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dri
> On 25/09/2019 20:49, Ira Weiny wrote:
> >>>
> >>> Signed-off-by: Ira Weiny
> >>> ---
> >>> drivers/nvdimm/namespace_devs.c | 19 +--
> >>> 1 file changed, 9 insertions(+), 10 deletions(-)
> >>
> >> One minor nit below, but otherwise it looks good to me:
> >> Reviewed-by: Vishal
>
> On Wed, 2019-09-25 at 14:00 +0300, Dan Carpenter wrote:
> > The "ndns->claim_class" variable is an enum but in this case GCC will
> > treat it as an unsigned int so the error handling is never triggered.
> >
> > Fixes: 14e494542636 ("libnvdimm, btt: BTT updates for UEFI 2.7
> > format")
> > Si
> On Fri, Sep 20, 2019 at 04:28:48PM -0700, Andrew Morton wrote:
> > On Tue, 23 Jul 2019 09:02:48 -0700 Matthew Wilcox
> wrote:
> >
> > > On Mon, Jul 22, 2019 at 05:43:07PM -0700, Ira Weiny wrote:
> > > > > diff --git a/drivers/crypto/chelsio/chtls/chtls_io.c
> > > > > b/drivers/crypto/chelsio/cht
>
> On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > > So I think your debug option and my suggested renaming serve a bit
> > > > different purposes (and thus both make sense). If you do the
> > > > renaming, you can just grep to se
>
> On 8/8/19 4:41 PM, Ira Weiny wrote:
> > On Thu, Aug 08, 2019 at 03:59:15PM -0700, John Hubbard wrote:
> >> On 8/8/19 12:20 PM, John Hubbard wrote:
> >>> On 8/8/19 4:09 AM, Vlastimil Babka wrote:
> On 8/8/19 8:21 AM, Michal Hocko wrote:
> > On Wed 07-08-19 16:32:08, John Hubbard wrote:
> On Fri 09-08-19 15:58:13, Jan Kara wrote:
> > On Fri 09-08-19 10:23:07, Michal Hocko wrote:
> > > On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
> > > > On 8/9/19 12:59 AM, John Hubbard wrote:
> > > > >>> That's true. However, I'm not sure munlocking is where the
> > > > >>> put_user_page() mac
>
> On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > > So I think your debug option and my suggested renaming serve a bit
> > > > different purposes (and thus both make sense). If you do the
> > > > renaming, you can just grep to se
>
> On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > > So I think your debug option and my suggested renaming serve a bit
> > > > different purposes (and thus both make sense). If you do the
> > > > renaming, you can just grep to se
>
> On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > > So I think your debug option and my suggested renaming serve a bit
> > > > different purposes (and thus both make sense). If you do the
> > > > renaming, you can just grep to se
>
> On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > > So I think your debug option and my suggested renaming serve a bit
> > > > different purposes (and thus both make sense). If you do the
> > > > renaming, you can just grep to se
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/
>
> On 7/22/19 4:08 AM, Matthew Wilcox wrote:
> > On Sun, Jul 21, 2019 at 10:13:45PM -0700, Ira Weiny wrote:
> >> On Sun, Jul 21, 2019 at 09:02:04AM -0700, Matthew Wilcox wrote:
> >>> On Fri, Jul 19, 2019 at 12:29:53PM -0700, Ralph Campbell wrote:
> Struct page for ZONE_DEVICE private pages u
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this has
> > all the right patches, it also has the extra patches already in the
> > hmm tree, and four extra patches I wanted to send once this series is
> > me
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this has
> > all the right patches, it also has the extra patches already in the
> > hmm tree, and four extra patches I wanted to send once this series is
> > me
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this has
> > all the right patches, it also has the extra patches already in the
> > hmm tree, and four extra patches I wanted to send once this series is
> > me
>
> On Fri, May 24, 2019 at 12:33 PM wrote:
> >
> > From: Ira Weiny
> >
> > RFC I have no idea if this is correct or not. But looking at
> > release_pages() I see a call to both __ClearPageActive() and
> > __ClearPageWaiters() while in __page_cache_release() I do not.
> >
> > Is this a bug whic
> On Wed, Apr 10, 2019 at 04:41:57PM -0700, Ira Weiny wrote:
> > On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote:
> > > From: Jérôme Glisse
> > >
> > > CPU page table update can happens for many reasons, not only as a
> > > result of a syscall (munmap(), mprotect(), mremap(), madvise
> On Tue, Apr 09, 2019 at 11:04:18AM +0800, Huang Shijie wrote:
> > On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> > > On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > > > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > > > On Mon, Apr 08, 2
> > On Apr 4, 2019, at 1:23 AM, Huang Shijie wrote:
> >
> >
> > + * This function is different from the get_user_pages_unlocked():
> > + * The @pages may has different page order with the result
> > + * got by get_user_pages_unlocked().
> > + *
>
> I suggest a slight rewrite of the comm
> Subject: Re: [PATCH v3 1/1] mm: introduce put_user_page*(), placeholder
> versions
>
> On 3/7/19 6:58 PM, Christopher Lameter wrote:
> > On Wed, 6 Mar 2019, john.hubb...@gmail.com wrote:
> >
> >> Dave Chinner's description of this is very clear:
> >>
> >> "The fundamental issue is that ->pag
> -Original Message-
> From: Davidlohr Bueso [mailto:d...@stgolabs.net]
> Sent: Wednesday, February 06, 2019 5:32 PM
> To: j...@ziepe.ca; a...@linux-foundation.org
> Cc: dledf...@redhat.com; j...@mellanox.com; j...@suse.cz;
> wi...@infradead.org; Weiny, Ira ; linux-
>
>
> On Mon, Feb 11, 2019 at 2:07 PM Jason Gunthorpe wrote:
> >
> > On Mon, Feb 11, 2019 at 01:52:38PM -0800, Ira Weiny wrote:
> > > On Mon, Feb 11, 2019 at 01:39:12PM -0800, John Hubbard wrote:
> > > > On 2/11/19 1:26 PM, Ira Weiny wrote:
> > > > > On Mon, Feb 11, 2019 at 01:13:56PM -0800, John H
>
> On Mon, Feb 11, 2019 at 2:07 PM Jason Gunthorpe wrote:
> >
> > On Mon, Feb 11, 2019 at 01:52:38PM -0800, Ira Weiny wrote:
> > > On Mon, Feb 11, 2019 at 01:39:12PM -0800, John Hubbard wrote:
> > > > On 2/11/19 1:26 PM, Ira Weiny wrote:
> > > > > On Mon, Feb 11, 2019 at 01:13:56PM -0800, John H
> On Mon, Feb 11, 2019 at 01:42:57PM -0800, Ira Weiny wrote:
> > On Mon, Feb 11, 2019 at 01:47:10PM -0700, Jason Gunthorpe wrote:
> > > On Mon, Feb 11, 2019 at 12:34:17PM -0800, Davidlohr Bueso wrote:
> > > > On Mon, 11 Feb 2019, ira.we...@intel.com wrote:
> > > > > Ira Weiny (3):
> > > > > mm/gup
> On Mon, Feb 11, 2019 at 01:42:57PM -0800, Ira Weiny wrote:
> > On Mon, Feb 11, 2019 at 01:47:10PM -0700, Jason Gunthorpe wrote:
> > > On Mon, Feb 11, 2019 at 12:34:17PM -0800, Davidlohr Bueso wrote:
> > > > On Mon, 11 Feb 2019, ira.we...@intel.com wrote:
> > > > > Ira Weiny (3):
> > > > > mm/gup
>
> On Mon, Feb 11, 2019 at 12:16:40PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > NOTE: This series depends on my clean up patch to remove the write
> > parameter from gup_fast_permitted()[1]
> >
> > HFI1 uses get_user_pages_fast() due to it performance advantages.
> > Like RDM
>
> On Mon, Feb 11, 2019 at 12:16:40PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > NOTE: This series depends on my clean up patch to remove the write
> > parameter from gup_fast_permitted()[1]
> >
> > HFI1 uses get_user_pages_fast() due to it performance advantages.
> > Like RDM
> > >> ---
> > >> net/xdp/xdp_umem.c | 6 ++
> > >> 1 file changed, 2 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c index
> > >> 5ab236c5c9a5..25e1e76654a8 100644
> > >> --- a/net/xdp/xdp_umem.c
> > >> +++ b/net/xdp/xdp_umem.c
> > >> @@ -265,1
> > >> ---
> > >> net/xdp/xdp_umem.c | 6 ++
> > >> 1 file changed, 2 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c index
> > >> 5ab236c5c9a5..25e1e76654a8 100644
> > >> --- a/net/xdp/xdp_umem.c
> > >> +++ b/net/xdp/xdp_umem.c
> > >> @@ -265,1
>
> On Tue, Jan 29, 2019 at 10:50:05AM -0800, Ira Weiny wrote:
> > > .. and I'm looking at some of the other conversions here.. *most
> > > likely* any caller that is manipulating rlimit for get_user_pages
> > > should really be calling get_user_pages_longterm, so they should not
> > > be converte
>
> On May 29, 2018, at 1:01 PM, Hefty, Sean wrote:
> >
> >> Should we indicate the transport layer here? (Ethernet, IB,
> >> Omnipath, GNI, ...etc.)
> >
> > I don't even know what transport protocol means anymore, and I'm not
> entirely joking. RoCE is IB transport over UDP, which is also a tr
> > On May 24, 2018, at 8:49 PM, Hefty, Sean wrote:
> >
> > This is an initial proposal:
> >
> > The device attributes are per fi_info structure (which includes the network
> address, domain, and ep attributes). The app does not need to open any
> resources to obtain the data.
> >
> >
> > When fi
Looks fine to me.
> -Original Message-
> From: Doug Ledford [mailto:dledf...@redhat.com]
> Sent: Monday, April 30, 2018 10:11 AM
> To: Jason Gunthorpe ; jackm
> Cc: Håkon Bugge ; Hiatt, Don
> ; Dasaratharaman Chandramouli
> ; Weiny, Ira ;
> Hefty, Sea
>
> Two kernel threads may get the same value for agent.hi_tid, if the agents are
> registered for different ports. As of now, this works, as the agent list is
> per port.
>
> It is however confusing and not future robust. Hence, making it atomic.
>
> Signed-off-by: Håkon Bugge
> Reviewed-by:
>
> On Wed, Jun 07, 2017 at 10:47:50AM -0600, Jason Gunthorpe wrote:
> > On Wed, Jun 07, 2017 at 07:43:44PM +0300, Leon Romanovsky wrote:
> > > On Wed, Jun 7, 2017 at 7:37 PM, Jason Gunthorpe
> > > wrote:
> > > > On Wed, Jun 07, 2017 at 07:19:01PM +0300, Leon Romanovsky wrote:
> > > >> It makes
>
> aarch64-linux-gcc-7 complains about code it doesn't fully understand:
>
> drivers/infiniband/hw/qib/qib_iba7322.c: In function
> 'qib_7322_txchk_change':
> include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used
> uninitialized in this function [-Werror=maybe-uninitialized
>
> On Tue, 2017-02-07 at 16:54 -0800, Vishwanathapura, Niranjana wrote:
> > On Tue, Feb 07, 2017 at 09:58:50PM +, Bart Van Assche wrote:
> > > On Tue, 2017-02-07 at 21:44 +, Hefty, Sean wrote:
> > > > This is Ethernet - not IP - encapsulation over a non-InfiniBand
> device/protocol.
> > >
Consider me trained...
Sorry,
Ira
> -Original Message-
> From: Paul Grun [mailto:g...@cray.com]
> Sent: Wednesday, January 25, 2017 7:58 AM
> To: Jeff Squyres (jsquyres) ; Weiny, Ira
>
> Cc: Ben Turrubiates (bturrubi) ; OFIWG Mailing list
>
> Subject: RE: [ofiw
Thanks!
From: Ben Turrubiates (bturrubi) [mailto:bturr...@cisco.com]
Sent: Tuesday, January 24, 2017 10:33 AM
To: Paul Grun ; Weiny, Ira ;
'ofiwg@lists.openfabrics.org'
Subject: Re: [ofiwg] DS/DA Agenda for 1/24/17
This information may change in the future. It’s recommended that yo
Is there a new access code? It says mine: 201 212 241 is not valid?
From: ofiwg [mailto:ofiwg-boun...@lists.openfabrics.org] On Behalf Of Paul Grun
Sent: Monday, January 23, 2017 3:41 PM
To: 'ofiwg@lists.openfabrics.org'
Subject: [ofiwg] DS/DA Agenda for 1/24/17
- Continue the discussi
I would encourage this group to attend the OFVWG meeting tomorrow.
Tomorrow may not be the best discussion as I think we will be talking about the
uAPI rather than kernel APIs which I think this group is probably more
concerned about.
Ira
From: ofiwg [mailto:ofiwg-boun...@lists.openfabrics.org
>
> On Fri, 11 Dec 2015, ira.weiny wrote:
>
> > I think I would rather see this called something like
> >
> > ipoib_add_to_list_sendonly
> >
> > Or something...
> >
> > Calling it iboib_check* sounds like it should return a bool.
>
> Hmm... It only adds the multicast group if the check was succe
>
>
> Receipt of CM MAD with other than the Send method for an attribute other
> than the ClassPortInfo attribute is invalid.
>
> CM attributes other than ClassPortInfo only use the send method.
>
> The SRP initiator does not maintain a timeout policy for CM connect requests
> relies on the CM
>
> On Tue, Oct 27, 2015 at 06:56:50PM +, Wan, Kaike wrote:
>
> > > I do wonder if it is a good idea to call ib_nl_send_msg with a
> > > spinlock held though.. Would be nice to see that go away.
> >
> > We have to hold the lock to protect against a race condition that a
> > quick response wil
>
> On Tue, Oct 27, 2015 at 06:56:50PM +, Wan, Kaike wrote:
>
> > > I do wonder if it is a good idea to call ib_nl_send_msg with a
> > > spinlock held though.. Would be nice to see that go away.
> >
> > We have to hold the lock to protect against a race condition that a
> > quick response wil
>
> On Mon, Oct 19, 2015 at 10:11:22PM -0400, ira.we...@intel.com wrote:
> > From: Niranjana Vishwanathapura
> >
> > Use NULL instead of 0 for pointer argument to fix the sparse error.
> >
> > Reviewed-by: Mike Marciniszyn
> > Reviewed-by: Mitko Haralanov
> > Reviewed-by: Dennis Dalessandro
>
>
> On Mon, Oct 19, 2015 at 10:11:22PM -0400, ira.we...@intel.com wrote:
> > From: Niranjana Vishwanathapura
> >
> > Use NULL instead of 0 for pointer argument to fix the sparse error.
> >
> > Reviewed-by: Mike Marciniszyn
> > Reviewed-by: Mitko Haralanov
> > Reviewed-by: Dennis Dalessandro
>
>
> On Mon, Oct 19, 2015 at 12:43:24PM -0400, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The following series has bug fixes and updates to the staging hfi1 driver.
>
> Why are you adding new functionality to this driver before it is moved out of
> drivers/staging/ ? I _REALLY_ don't
>
> On Mon, Oct 19, 2015 at 12:43:24PM -0400, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The following series has bug fixes and updates to the staging hfi1 driver.
>
> Why are you adding new functionality to this driver before it is moved out of
> drivers/staging/ ? I _REALLY_ don't
I was writing my own objection to this but Jason beat me too it. More comments
below.
>
> On Wed, Oct 14, 2015 at 11:29:42AM +0300, Haggai Eran wrote:
> > respect the pkey_index in ib_send_wr.ud for GSI packets. Apparently
> > having the pkey_index in a work request isn't required by the IBA
>
>
> > I have a series of about 5 patches which implement tracing in the MAD
> > stack which I was working through and was going to submit
>
> Does your MAD stack tracing include the dumping and decode of sent and
> received MADs ?
>
Yes with a bit more details in some places and probably less i
>
> > I have a series of about 5 patches which implement tracing in the MAD
> > stack which I was working through and was going to submit
>
> Does your MAD stack tracing include the dumping and decode of sent and
> received MADs ?
>
Yes with a bit more details in some places and probably less i
>
> On 9/30/2015 2:01 AM, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > This interface has no current users and is obsolete.
>
> There are no in tree users of this but there is Sean's madeye tool (which is
> out
> of tree). This is still a useful debug tool for MADs.
Where is that? I
>
> On 9/30/2015 2:01 AM, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > This interface has no current users and is obsolete.
>
> There are no in tree users of this but there is Sean's madeye tool (which is
> out
> of tree). This is still a useful debug tool for MADs.
Where is that? I
>
> This removes the definitions and declarations of the functions
> ib_register_mad_snoop and register_snoop_agent in the file mad.c due to have
> no more callers and thus can be removed to reduce code size of this particular
> file.
I don't disagree with removing the snoop code, however, I don'
>
> This removes the definitions and declarations of the functions
> ib_register_mad_snoop and register_snoop_agent in the file mad.c due to have
> no more callers and thus can be removed to reduce code size of this particular
> file.
I don't disagree with removing the snoop code, however, I don'
> >
> > What is being done in the parent directory has a bug, you're right
> > that far, but this is the wrong fix. If you check the 0day failures,
> > it isn't because the InfiniBand core isn't enabled, it's because the
> > current menuconfig setup allows the IB core to be a module and the
> > s
>
> What is being done in the parent directory has a bug, you're right that far,
> but
> this is the wrong fix. If you check the 0day failures, it isn't because the
> InfiniBand core isn't enabled, it's because the current menuconfig setup
> allows
> the IB core to be a module and the staging dr
>
> > Christoph,
> >
> > We had a smaller volume move to cache the device attributes on the IB
> > device structure, and I just realized it was dropped on the floor.
> > Ira, that was a reviewer comment you got when worked on OPA and I
> > missed the fact it didn't reach to acceptance
> > http://m
>
> On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> > On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> > > __get_txreq() returns an ERR_PTR() but this checks for NULL so it
> > > would oops on failure.
> > >
> > > Signed-off-by: Dan Carpenter
> >
> > Thanks, applied.
>
> Applied to
>
> On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> > On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> > > __get_txreq() returns an ERR_PTR() but this checks for NULL so it
> > > would oops on failure.
> > >
> > > Signed-off-by: Dan Carpenter
> >
> > Thanks, applied.
>
> Applied to
>
> On Thu, Sep 17, 2015 at 06:18:15PM +0200, Michal Schmidt wrote:
> > On 09/16/2015 11:41 PM, ira.we...@intel.com wrote:
> > > @@ -125,7 +151,20 @@ int __init dev_init(void)
> > > ret = PTR_ERR(class);
> > > pr_err("Could not create device class (err %d)\n", -ret);
> > >
Is there a URL for the github mentioned in the slides?
Ira
From: ofiwg-boun...@lists.openfabrics.org
[mailto:ofiwg-boun...@lists.openfabrics.org] On Behalf Of Paul Grun
Sent: Wednesday, September 09, 2015 1:24 AM
To: ofiwg@lists.openfabrics.org
Subject: [ofiwg] DS/DA - Current version of kfi sl
>
> On 09/03/2015 04:26 PM, Kyle McMartin wrote:
> > On Wed, Sep 02, 2015 at 10:15:15PM +0000, Weiny, Ira wrote:
> >>>
> >>> On 08/24/2015 11:28 AM, ira.weiny wrote:
> >>>> git://github.com/weiny2/linux-firmware.git master-hfi1-firmware-v2
>
> On 08/24/2015 11:28 AM, ira.weiny wrote:
> > git://github.com/weiny2/linux-firmware.git master-hfi1-firmware-v2
>
> Should this go through me or though the linux-firmware tree?
I don't know. My apologizes for being ignorant in this case.
I was thinking that as the rdma kernel maintainer y
>
> On 08/30/2015 02:12 AM, Or Gerlitz wrote:
> > On Thu, Aug 27, 2015 at 5:55 AM, Haggai Eran
> wrote:
> >> When no matching listening ID is found for a given request, the
> >> net_dev that was used to find the request isn't released.
> >>
> >> Fixes: 20c36836ecad ("IB/cma: Use found net_dev for
> This patch fixes -Wformat-security warnings, that in Debian (and Ubuntu) are
> enabled by default:
>
> src/rdma-ndd.c: In function 'update_node_desc':
> src/rdma-ndd.c:149:3: error: format not a string literal and no format
> arguments [-Werror=format-security]
>fprintf(f, new_nd);
>^
>
>
> Additional file descriptor for SMP MADs should be closed before running
> ibnd_discover_fabric() to avoid parallel usage of two SMP file descriptors
>
> Signed-off-by: Vladimir Koushnir
> Signed-off-by: Hal Rosenstock
Thanks applied,
Ira
--
To unsubscribe from this list: send the line
> On 07/17/2015 02:14 AM, Greg Kroah-Hartman (gre...@linuxfoundation.org)
> wrote:
> >
> > It's up to the IB maintainer if they are willing to let it be in
> > stable as-is.
>
> I wouldn't call it stable as-is. However, that doesn't mean I think it
> *must* go to staging. It's a first cut at a t
>
> Christoph,
>
>
> Apologies, I misspoke in my response to you. There was a study of the code
> and
> we thought it was reasonable to post. However, in retrospect we should have
> used more due diligence. We're going back to seek explicit consent from key
> contributors.
I'm no legal expe
> On 6/25/2015 4:52 PM, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > We recently added BUG_ON's which were inappropriate for a condition
> > which should never happen. Change these to be WARN_ON_ONCE as a
> debugging aid.
> >
> > Fixes: 4cd7c9479aff ('IB/mad: Add support for additional MA
> >
> > Please accept my apologies. The original patch used WARN_ON but I was
> advised to use BUG_ON in a review and I should have thought about it more
> rather than blindly make the change.
>
>
> Ira,
>
> Can you please point me to the review thread where this advise was made? I
> can't trac
Linus,
>
> On the *other* side of the same conflict, I find an even more offensive
> commit,
> namely commit 4cd7c9479aff ("IB/mad: Add support for additional MAD info
> to/from drivers") which adds a BUG_ON() for a sanity check, rather than just
> returning -EINVAL or something sane like that.
Linus,
>
> On the *other* side of the same conflict, I find an even more offensive
> commit,
> namely commit 4cd7c9479aff ("IB/mad: Add support for additional MAD info
> to/from drivers") which adds a BUG_ON() for a sanity check, rather than just
> returning -EINVAL or something sane like that.
>
> On 6/18/2015 4:25 PM, Jason Gunthorpe wrote:
> > Ira had patch that made some functions related to this public, not
> > sure if it is applied yet..
>
> Which patch from Ira are you referring to ?
This patch which is in Dougs for 4.2 tree:
commit ca0369e31d1794a4f4e39c52fe39b0406617e2b4
Au
>
> ib_verbs define an *extensive* direct HW access API, which is constantly
> evolving.
This is the problem with verbs...
> You cannot describe the intricate object relations and semantics through an
> API.
> In addition, you can't abstract anything or fix stuff in SW.
> The only way to *truly*
>
> On Fri, Jun 12, 2015 at 05:24:32AM +, Weiny, Ira wrote:
> >
> > PATH_USE_* is a better name. But I think the defines should be:
> >
> > PATH_USE_ANY (or ALL?)
>
> How about PATH_USE_CONNECTED?
I don't want to bikeshed this too much as I&#x
>
> > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > Sent: Thursday, June 11, 2015 8:22 PM
> > To: Wan, Kaike
> > Cc: linux-rdma@vger.kernel.org; Fleck, John; Weiny, Ira
> > Subject: Re: [PATCH v5 1/4] IB/netlink: Add defines for local ser
>
> > Is QP type definition already exported to user space?
>
> QP Type could be a bad name, open to ideas
I think the name "QP Type" is bad...
I want to say "transport type" but I don't think that really communicates what
we want here.
>
> > I see IBV_QPT_RC/UC/UD/RAW_PACKET/XRC_SEND/XRC_R
>
> On Thu, Jun 11, 2015 at 08:16:41PM +, Weiny, Ira wrote:
> > > For instance if we add SL it would be mandatory, but policy
> > > information like requesting net_device would be optional.
> >
> > Why would SL be mandatory?
>
> If the kernel a
> On Thu, Jun 11, 2015 at 01:04:25PM -0400, kaike@intel.com wrote:
> > +static int acm_nl_parse_path_attr(struct nlattr *attr,
> > + struct acm_ep_addr_data *data)
>
> > + switch (attr->nla_type & NLA_TYPE_MASK) {
> > + default:
> > + acm_log(1, "WARN
1 - 100 of 279 matches
Mail list logo
