RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Ren, Qiaowei
On 2014-07-24, Hansen, Dave wrote: > On 07/23/2014 05:49 PM, Ren, Qiaowei wrote: >> I can check a lot of debug information when one VMA and related >> bounds tables are allocated and freed through adding a lot of >> print() like log into kernel/runtime. Do you think this is enough? > > I

Re: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Dave Hansen
On 07/23/2014 05:49 PM, Ren, Qiaowei wrote: > I can check a lot of debug information when one VMA and related > bounds tables are allocated and freed through adding a lot of print() > like log into kernel/runtime. Do you think this is enough? I thought the entire reason we grabbed a VM_ flag was

RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Ren, Qiaowei
On 2014-07-24, Hansen, Dave wrote: > On 07/20/2014 10:38 PM, Qiaowei Ren wrote: >> Since the kernel allocated those tables on-demand without userspace >> knowledge, it is also responsible for freeing them when the >> associated mappings go away. >> >> Here, the solution for this issue is to

Re: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Dave Hansen
On 07/20/2014 10:38 PM, Qiaowei Ren wrote: > Since the kernel allocated those tables on-demand without userspace > knowledge, it is also responsible for freeing them when the associated > mappings go away. > > Here, the solution for this issue is to hook do_munmap() to check > whether one process

Re: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Dave Hansen
On 07/20/2014 10:38 PM, Qiaowei Ren wrote: Since the kernel allocated those tables on-demand without userspace knowledge, it is also responsible for freeing them when the associated mappings go away. Here, the solution for this issue is to hook do_munmap() to check whether one process is

RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Ren, Qiaowei
On 2014-07-24, Hansen, Dave wrote: On 07/20/2014 10:38 PM, Qiaowei Ren wrote: Since the kernel allocated those tables on-demand without userspace knowledge, it is also responsible for freeing them when the associated mappings go away. Here, the solution for this issue is to hook

Re: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Dave Hansen
On 07/23/2014 05:49 PM, Ren, Qiaowei wrote: I can check a lot of debug information when one VMA and related bounds tables are allocated and freed through adding a lot of print() like log into kernel/runtime. Do you think this is enough? I thought the entire reason we grabbed a VM_ flag was to

RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-23 Thread Ren, Qiaowei
On 2014-07-24, Hansen, Dave wrote: On 07/23/2014 05:49 PM, Ren, Qiaowei wrote: I can check a lot of debug information when one VMA and related bounds tables are allocated and freed through adding a lot of print() like log into kernel/runtime. Do you think this is enough? I thought the

RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-21 Thread Zhang, Tianfei
> -Original Message- > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On > Behalf Of Qiaowei Ren > Sent: Monday, July 21, 2014 1:39 PM > To: H. Peter Anvin; Thomas Gleixner; Ingo Molnar; Hansen, Dave > Cc: x...@kernel.org; linux-kernel@vger.kernel.org;

RE: [PATCH v7 09/10] x86, mpx: cleanup unused bound tables

2014-07-21 Thread Zhang, Tianfei
-Original Message- From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of Qiaowei Ren Sent: Monday, July 21, 2014 1:39 PM To: H. Peter Anvin; Thomas Gleixner; Ingo Molnar; Hansen, Dave Cc: x...@kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org;