RE: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

> 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

RE: [PATCH 1/3] mm/mlock.c: convert put_page() to put_user_page*()

> > 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

RE: [PATCH 1/3] mm/mlock.c: convert put_page() to put_user_page*()

> 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()

RE: [PATCH v2 1/3] mm: document zone device struct page field usage

> > 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

RE: [PATCH RFC] mm/swap: make release_pages() and put_pages() match

> > 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

RE: [PATCH 1/2] mm/gup.c: fix the wrong comments

> 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,

RE: [PATCH] mm/gup.c: fix the wrong comments

> > 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

RE: [PATCH v3 1/1] mm: introduce put_user_page*(), placeholder versions

> 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

RE: [PATCH 7/6] Documentation/infiniband: update from locked to pinned_vm

> -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- >

RE: [PATCH 2/3] mm/gup: Introduce get_user_pages_fast_longterm()

> > 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

RE: [PATCH 0/3] Add gup fast + longterm and use it in HFI1

> 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): > > > > >

RE: [PATCH 0/3] Add gup fast + longterm and use it in HFI1

> > 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

RE: [PATCH 1/2] xsk: do not use mmap_sem

> > >> --- > > >> 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 > > >> @@

RE: [PATCH 3/6] drivers/IB,qib: do not use mmap_sem

> > 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

RE: [PATCH] IB/core: Make ib_mad_client_id atomic

Hiatt, Don > <don.hi...@intel.com>; Dasaratharaman Chandramouli > <dasaratharaman.chandramo...@intel.com>; Weiny, Ira <ira.we...@intel.com>; > Hefty, Sean <sean.he...@intel.com>; OFED mailing list r...@vger.kernel.org>; linux-kernel@vger.kernel.org > Subject: Re: [PATCH

RE: [PATCH] IB/core: Make ib_mad_client_id atomic

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

RE: [PATCH] IB/core: Make ib_mad_client_id atomic

> > 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

RE: [PATCH] IB/core: Make ib_mad_client_id atomic

> > 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:

RE: [PATCH] IB/qib: fix false-postive maybe-uninitialized warning

> > 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

RE: [PATCH] IB/qib: fix false-postive maybe-uninitialized warning

> > 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

RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

> > 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

RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

> > 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

RE: [PATCH RFC] IB/mad: remove obsolete snoop interface

> > > 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

RE: [PATCH RFC] IB/mad: remove obsolete snoop interface

> > 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?

RE: [PATCH] infiniband:Remove unneeded function definitions and declarations in the file, mad.c

> > 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

RE: [PATCH RFC] IB/mad: remove obsolete snoop interface

> > > 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

RE: [PATCH] infiniband:Remove unneeded function definitions and declarations in the file, mad.c

> > 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

RE: [PATCH RFC] IB/mad: remove obsolete snoop interface

> > 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

RE: [GIT] Networking

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.

RE: [GIT] Networking

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. I'm

RE: [PATCH v7 00/23] IB/Verbs: IB Management Helpers

> > > Does anyone have a link to the emails which proposed bitmasks? I > > can't find them right now. > > I think converting the caps functions into bits is a good place to start. That is where I am starting... Ira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

RE: [PATCH v7 00/23] IB/Verbs: IB Management Helpers

Does anyone have a link to the emails which proposed bitmasks? I can't find them right now. I think converting the caps functions into bits is a good place to start. That is where I am starting... Ira -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

RE: [PATCH v4 10/27] IB/Verbs: Reform cm related part in IB-core cma/ucm

> > On 4/16/2015 11:58 AM, Jason Gunthorpe wrote: > > It also looks like hardwired 1 won't work on switch ports, so it is no-go. > > AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the current > code. There is no need for CM/RDMA CM on base switch port 0. I concur and I thought I

RE: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

> > On Wed, Apr 15, 2015 at 09:58:18AM +0200, Michael Wang wrote: > > > We can give client->add() callback a return value and make > > ib_register_device() return -ENOMEM when it failed, just wondering why > > we don't do this at first, any special reason? > > No idea, but having

RE: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

On Wed, Apr 15, 2015 at 09:58:18AM +0200, Michael Wang wrote: We can give client-add() callback a return value and make ib_register_device() return -ENOMEM when it failed, just wondering why we don't do this at first, any special reason? No idea, but having ib_register_device fail

RE: [PATCH v4 10/27] IB/Verbs: Reform cm related part in IB-core cma/ucm

On 4/16/2015 11:58 AM, Jason Gunthorpe wrote: It also looks like hardwired 1 won't work on switch ports, so it is no-go. AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the current code. There is no need for CM/RDMA CM on base switch port 0. I concur and I thought I

RE: [PATCH] IB/mad: fix ifnullfree.cocci warnings

> > > > drivers/infiniband/core/mad.c:2088:3-8: WARNING: NULL check before > > freeing functions like kfree, debugfs_remove, debugfs_remove_recursive > > or usb_free_urb is not needed. Maybe consider reorganizing relevant > > code to avoid passing NULL values. > > > > NULL check before some

RE: [PATCH] IB/mad: fix ifnullfree.cocci warnings

> -Original Message- > From: Wu, Fengguang > Sent: Tuesday, January 27, 2015 1:36 PM > To: Weiny, Ira > Cc: kbuild-...@01.org; Roland Dreier; Hefty, Sean; Hal Rosenstock; Or Gerlitz; > Yan Burman; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject

RE: [PATCH] IB/mad: fix ifnullfree.cocci warnings

drivers/infiniband/core/mad.c:2088:3-8: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. NULL check before some freeing functions

RE: [PATCH] IB/mad: fix ifnullfree.cocci warnings

-Original Message- From: Wu, Fengguang Sent: Tuesday, January 27, 2015 1:36 PM To: Weiny, Ira Cc: kbuild-...@01.org; Roland Dreier; Hefty, Sean; Hal Rosenstock; Or Gerlitz; Yan Burman; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: [PATCH] IB/mad: fix