Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (06/30/17 19:18), Tetsuo Handa wrote: > > > I'm still thinking about Steven's proposals; but we will need offloading > > > anyways, so the bits we are talking about here are important regardless > > > the direction pr

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (06/30/17 19:18), Tetsuo Handa wrote: > > > I'm still thinking about Steven's proposals; but we will need offloading > > > anyways, so the bits we are talking about here are important regardless > > > the direction pr

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > if (!alloc_cpumask_var(_allowed, GFP_KERNEL)) { > wake_up_process(printk_kthread); > return true; > } Please avoid memory allocations when trying to print something. __GFP_DIRECT_RECLAIM allocations (e.g. GFP_KERNEL) can

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > if (!alloc_cpumask_var(_allowed, GFP_KERNEL)) { > wake_up_process(printk_kthread); > return true; > } Please avoid memory allocations when trying to print something. __GFP_DIRECT_RECLAIM allocations (e.g. GFP_KERNEL) can

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 09-03-17 13:05:40, Johannes Weiner wrote: > > > On Tue, Mar 07, 2017 at 02:52:36PM -0500, Rik van Riel wrote: > > > > It only does this to some extent. If reclaim made > > > > no progress, for exam

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 09-03-17 13:05:40, Johannes Weiner wrote: > > > On Tue, Mar 07, 2017 at 02:52:36PM -0500, Rik van Riel wrote: > > > > It only does this to some extent. If reclaim made > > > > no progress, for exam

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Fri, Jun 23, 2017 at 06:52:20AM +0900, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > Oops, I misinterpreted. This is where a multithreaded OOM victim with or > > without > > the OOM reaper can get stuck forever. Think about a pr

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Fri, Jun 23, 2017 at 06:52:20AM +0900, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > Oops, I misinterpreted. This is where a multithreaded OOM victim with or > > without > > the OOM reaper can get stuck forever. Think about a pr

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (06/28/17 14:19), Petr Mladek wrote: > > Our two proposals are very close after all. I suggest to make > > the following changes in your patch: > > > > + Remove the waiting for another console_lock owner. It is > > too tricky. > > we lose the printing

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Sergey Senozhatsky wrote: > On (06/28/17 14:19), Petr Mladek wrote: > > Our two proposals are very close after all. I suggest to make > > the following changes in your patch: > > > > + Remove the waiting for another console_lock owner. It is > > too tricky. > > we lose the printing

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > On Tue 27-06-17 22:31:58, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 27-06-17 20:39:28, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > > I wonder why you prefer timeout based approach. Your p

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > On Tue 27-06-17 22:31:58, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 27-06-17 20:39:28, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > > I wonder why you prefer timeout based approach. Your p

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > On Tue 27-06-17 20:39:28, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > > I wonder why you prefer timeout based approach. Your patch will after > > > > all > > > > set MMF_OOM_SKIP if operations between down_write() and

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > On Tue 27-06-17 20:39:28, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > > I wonder why you prefer timeout based approach. Your patch will after > > > > all > > > > set MMF_OOM_SKIP if operations between down_write() and

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > > I wonder why you prefer timeout based approach. Your patch will after all > > set MMF_OOM_SKIP if operations between down_write() and up_write() took > > more than one second. > > if we reach down_write then we have unmapped the address space in > exit_mmap and oom reaper

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > > I wonder why you prefer timeout based approach. Your patch will after all > > set MMF_OOM_SKIP if operations between down_write() and up_write() took > > more than one second. > > if we reach down_write then we have unmapped the address space in > exit_mmap and oom reaper

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > From: Michal Hocko > > David has noticed that the oom killer might kill additional tasks while > the existing victim hasn't terminated yet because the oom_reaper marks > the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down > to 0. The

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

Michal Hocko wrote: > From: Michal Hocko > > David has noticed that the oom killer might kill additional tasks while > the existing victim hasn't terminated yet because the oom_reaper marks > the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down > to 0. The race is as follows >

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Tetsuo Handa wrote: > Roman Gushchin wrote: > > On Thu, Jun 22, 2017 at 09:40:28AM +0900, Tetsuo Handa wrote: > > > Roman Gushchin wrote: > > > > --- a/mm/oom_kill.c > > > > +++ b/mm/oom_kill.c > > > > @@ -992,

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Tetsuo Handa wrote: > Roman Gushchin wrote: > > On Thu, Jun 22, 2017 at 09:40:28AM +0900, Tetsuo Handa wrote: > > > Roman Gushchin wrote: > > > > --- a/mm/oom_kill.c > > > > +++ b/mm/oom_kill.c > > > > @@ -992,

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Thu, Jun 22, 2017 at 09:40:28AM +0900, Tetsuo Handa wrote: > > Roman Gushchin wrote: > > > --- a/mm/oom_kill.c > > > +++ b/mm/oom_kill.c > > > @@ -992,6 +992,13 @@ bool out_of_memory(struct oom_control *oc) > > > if (oom_

Re: [v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Roman Gushchin wrote: > On Thu, Jun 22, 2017 at 09:40:28AM +0900, Tetsuo Handa wrote: > > Roman Gushchin wrote: > > > --- a/mm/oom_kill.c > > > +++ b/mm/oom_kill.c > > > @@ -992,6 +992,13 @@ bool out_of_memory(struct oom_control *oc) > > > if (oom_

Re: Bad page state freeing hugepages

FYI, I'm hitting this problem by doing just boot or shutdown sequence, and this problem is remaining as of next-20170622. localhost login: [ 37.010894] BUG: Bad page state in process gdbus pfn:11f001 [ 37.015328] page:c0ce447c0040 count:0 mapcount:1 mapping:dead

Re: Bad page state freeing hugepages

FYI, I'm hitting this problem by doing just boot or shutdown sequence, and this problem is remaining as of next-20170622. localhost login: [ 37.010894] BUG: Bad page state in process gdbus pfn:11f001 [ 37.015328] page:c0ce447c0040 count:0 mapcount:1 mapping:dead

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Fri 16-06-17 23:26:20, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 16-06-17 19:27:19, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > > > >

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Fri 16-06-17 23:26:20, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 16-06-17 19:27:19, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > > > >

[PATCH] mm,oom_kill: Close race window of needlessly selecting new victims.

Michal Hocko wrote: > On Fri 16-06-17 21:22:20, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > OK, could you play with the patch/idea suggested in > > > http://lkml.kernel.org/r/20170615122031.gl1...@dhcp22.suse.cz? > > > > I think we don't need to

[PATCH] mm,oom_kill: Close race window of needlessly selecting new victims.

Michal Hocko wrote: > On Fri 16-06-17 21:22:20, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > OK, could you play with the patch/idea suggested in > > > http://lkml.kernel.org/r/20170615122031.gl1...@dhcp22.suse.cz? > > > > I think we don't need to

Re: Re: [patch] mm, oom: prevent additional oom kills before memoryis freed

Michal Hocko wrote: > On Fri 16-06-17 19:27:19, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > > > [...] > > > > And the patch you proposed is broken. > > > > > > Thanks for your testi

Re: Re: [patch] mm, oom: prevent additional oom kills before memoryis freed

Michal Hocko wrote: > On Fri 16-06-17 19:27:19, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > > > [...] > > > > And the patch you proposed is broken. > > > > > > Thanks for your testi

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > OK, could you play with the patch/idea suggested in > http://lkml.kernel.org/r/20170615122031.gl1...@dhcp22.suse.cz? I think we don't need to worry about mmap_sem dependency inside __mmput(). Since the OOM killer checks for !MMF_OOM_SKIP mm rather than TIF_MEMDIE thread, we

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > OK, could you play with the patch/idea suggested in > http://lkml.kernel.org/r/20170615122031.gl1...@dhcp22.suse.cz? I think we don't need to worry about mmap_sem dependency inside __mmput(). Since the OOM killer checks for !MMF_OOM_SKIP mm rather than TIF_MEMDIE thread, we

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > [...] > > And the patch you proposed is broken. > > Thanks for your testing! > > > -- > > [ 161.846202] Out of memory: Kill process 6331 (a.out) score 999 or > > sacrifice

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Fri 16-06-17 09:54:34, Tetsuo Handa wrote: > [...] > > And the patch you proposed is broken. > > Thanks for your testing! > > > -- > > [ 161.846202] Out of memory: Kill process 6331 (a.out) score 999 or > > sacrifice

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Tetsuo Handa wrote: > and clarify in your patch that there is no possibility > of waiting for direct/indirect memory allocation inside free_pgtables(), > in addition to fixing the bug above. Oops, this part was wrong, for __oom_reap_task_mm() will give up after waiting for one secon

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Tetsuo Handa wrote: > and clarify in your patch that there is no possibility > of waiting for direct/indirect memory allocation inside free_pgtables(), > in addition to fixing the bug above. Oops, this part was wrong, for __oom_reap_task_mm() will give up after waiting for one secon

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 15:03:17, David Rientjes wrote: > > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > > > Yes, quite a bit in testing. > > > > > > > > One oom kill shows the system to be oom: > > > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > >

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 15:03:17, David Rientjes wrote: > > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > > > Yes, quite a bit in testing. > > > > > > > > One oom kill shows the system to be oom: > > > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > >

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 22:01:33, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Thu 15-06-17 14:03:35, Michal Hocko wrote: > > > > On Thu 15-06-17 20:32:39, Tetsuo Handa wrote: > > > > > @@ -556,25 +553,21 @@ static void oom

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 22:01:33, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Thu 15-06-17 14:03:35, Michal Hocko wrote: > > > > On Thu 15-06-17 20:32:39, Tetsuo Handa wrote: > > > > > @@ -556,25 +553,21 @@ static void oom

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 14:03:35, Michal Hocko wrote: > > On Thu 15-06-17 20:32:39, Tetsuo Handa wrote: > > > @@ -556,25 +553,21 @@ static void oom_reap_task(struct task_struct *tsk) > > > struct mm_struct *mm = tsk->signal->oom_mm; > > >

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 14:03:35, Michal Hocko wrote: > > On Thu 15-06-17 20:32:39, Tetsuo Handa wrote: > > > @@ -556,25 +553,21 @@ static void oom_reap_task(struct task_struct *tsk) > > > struct mm_struct *mm = tsk->signal->oom_mm; > > >

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 19:53:24, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Wed 14-06-17 16:43:03, David Rientjes wrote: > > > > If mm->mm_users is not incremented because it is already zero by the oom > > > > reaper, meaning th

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 19:53:24, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Wed 14-06-17 16:43:03, David Rientjes wrote: > > > > If mm->mm_users is not incremented because it is already zero by the oom > > > > reaper, meaning th

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Wed 14-06-17 16:43:03, David Rientjes wrote: > > If mm->mm_users is not incremented because it is already zero by the oom > > reaper, meaning the final refcount has been dropped, do not set > > MMF_OOM_SKIP prematurely. > > > > __mmput() may not have had a chance to do

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Wed 14-06-17 16:43:03, David Rientjes wrote: > > If mm->mm_users is not incremented because it is already zero by the oom > > reaper, meaning the final refcount has been dropped, do not set > > MMF_OOM_SKIP prematurely. > > > > __mmput() may not have had a chance to do

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

Michal Hocko wrote: > On Sat 10-06-17 20:57:46, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > And just to clarify a bit. The OOM killer should be invoked whenever > > > appropriate from the allocation context. If we decide to fail the > > > allocation in

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

Michal Hocko wrote: > On Sat 10-06-17 20:57:46, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > And just to clarify a bit. The OOM killer should be invoked whenever > > > appropriate from the allocation context. If we decide to fail the > > > allocation in

[PATCH] sendfile: Do not update file offset of non-lseek()able objects.

not update file offset if the file descriptor refers to an non-lseek()able object. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> --- fs/read_write.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index 47c1d44..1

[PATCH] sendfile: Do not update file offset of non-lseek()able objects.

not update file offset if the file descriptor refers to an non-lseek()able object. Signed-off-by: Tetsuo Handa --- fs/read_write.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index 47c1d44..17ea13c 100644 --- a/fs/read_write.c +++ b/fs

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the#PF

Michal Hocko wrote: > And just to clarify a bit. The OOM killer should be invoked whenever > appropriate from the allocation context. If we decide to fail the > allocation in the PF path then we can safely roll back and retry the > whole PF. This has an advantage that any locks held while doing

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the#PF

Michal Hocko wrote: > And just to clarify a bit. The OOM killer should be invoked whenever > appropriate from the allocation context. If we decide to fail the > allocation in the PF path then we can safely roll back and retry the > whole PF. This has an advantage that any locks held while doing

Re: 4.9.30 NULL pointer dereference in __remove_shared_vm_struct

Tommi Rantala wrote: > I have hit this kernel bug twice with 4.9.30 while running trinity, any > ideas? It's not easily reproducible. No idea. But if you can reproduce this problem, I think you can retry with the OOM reaper disabled (like shown below), for the latter report is 10 seconds after

Re: 4.9.30 NULL pointer dereference in __remove_shared_vm_struct

Tommi Rantala wrote: > I have hit this kernel bug twice with 4.9.30 while running trinity, any > ideas? It's not easily reproducible. No idea. But if you can reproduce this problem, I think you can retry with the OOM reaper disabled (like shown below), for the latter report is 10 seconds after

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > For the case at hand, would it work if there was a non-API call that you > could use until the API is properly expanded? Kernel command line switching (i.e. this patch) is fine for my use cases. SELinux folks might want -static int security_debug; +static int security_debug

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > For the case at hand, would it work if there was a non-API call that you > could use until the API is properly expanded? Kernel command line switching (i.e. this patch) is fine for my use cases. SELinux folks might want -static int security_debug; +static int security_debug

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > >> +struct pmalloc_node { > >> + struct hlist_node nodes_list; > >> + atomic_t used_words; > >> + unsigned int total_words; > >> + __PMALLOC_ALIGNED align_t data[]; > >> +}; > > > > Is this __PMALLOC_ALIGNED needed? Why not use "long" and "BITS_PER_LONG" ? > > In an

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > >> +struct pmalloc_node { > >> + struct hlist_node nodes_list; > >> + atomic_t used_words; > >> + unsigned int total_words; > >> + __PMALLOC_ALIGNED align_t data[]; > >> +}; > > > > Is this __PMALLOC_ALIGNED needed? Why not use "long" and "BITS_PER_LONG" ? > > In an

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > Who decides when enough is enough, meaning that all the needed modules > are loaded? > Should I provide an interface to user-space? A sysfs entry? No such interface is needed. Just an API for applying set_memory_rw() and set_memory_ro() on LSM hooks is enough.

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > Who decides when enough is enough, meaning that all the needed modules > are loaded? > Should I provide an interface to user-space? A sysfs entry? No such interface is needed. Just an API for applying set_memory_rw() and set_memory_ro() on LSM hooks is enough.

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > On 05/06/17 23:50, Tetsuo Handa wrote: > > Casey Schaufler wrote: > > [...] > > >> I don't care for calling this "security debug". Making > >> the lists writable after init isn't about development, > >> it's about (Te

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Igor Stoppa wrote: > On 05/06/17 23:50, Tetsuo Handa wrote: > > Casey Schaufler wrote: > > [...] > > >> I don't care for calling this "security debug". Making > >> the lists writable after init isn't about development, > >> it's about (Te

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > +int pmalloc_protect_pool(struct pmalloc_pool *pool) > +{ > + struct pmalloc_node *node; > + > + if (!pool) > + return -EINVAL; > + mutex_lock(>nodes_list_mutex); > + hlist_for_each_entry(node, >nodes_list_head, nodes_list) { > +

Re: [PATCH 2/5] Protectable Memory Allocator

Igor Stoppa wrote: > +int pmalloc_protect_pool(struct pmalloc_pool *pool) > +{ > + struct pmalloc_node *node; > + > + if (!pool) > + return -EINVAL; > + mutex_lock(>nodes_list_mutex); > + hlist_for_each_entry(node, >nodes_list_head, nodes_list) { > +

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Casey Schaufler wrote: > > @@ -33,8 +34,17 @@ > > /* Maximum number of letters for an LSM name string */ > > #define SECURITY_NAME_MAX 10 > > > > -static struct list_head hook_heads[LSM_MAX_HOOK_INDEX] > > - __lsm_ro_after_init; > > +static int security_debug; > > + > > +static __init int

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

Casey Schaufler wrote: > > @@ -33,8 +34,17 @@ > > /* Maximum number of letters for an LSM name string */ > > #define SECURITY_NAME_MAX 10 > > > > -static struct list_head hook_heads[LSM_MAX_HOOK_INDEX] > > - __lsm_ro_after_init; > > +static int security_debug; > > + > > +static __init int

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Alan Cox wrote: > > I saw several companies who ship their embedded devices with > > single-function LSM modules (e.g. restrict only mount operation and > > ptrace operation). What is unfortunate is that their LSM modules had > > never been proposed for upstream, and thus bugs remained unnoticed.

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Alan Cox wrote: > > I saw several companies who ship their embedded devices with > > single-function LSM modules (e.g. restrict only mount operation and > > ptrace operation). What is unfortunate is that their LSM modules had > > never been proposed for upstream, and thus bugs remained unnoticed.

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Wed, 31 May 2017, Tetsuo Handa wrote: > > > via lack of ability to use LKM-based LSM modules). My customers cannot > > afford > > enabling SELinux, but my customers cannot rebuild their kernels because > > rebuilding makes it even more diff

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Wed, 31 May 2017, Tetsuo Handa wrote: > > > via lack of ability to use LKM-based LSM modules). My customers cannot > > afford > > enabling SELinux, but my customers cannot rebuild their kernels because > > rebuilding makes it even more diff

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Tue, 30 May 2017, Alan Cox wrote: > > > On Tue, 30 May 2017 23:29:10 +0900 > > Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> wrote: > > > > > James Morris wrote: > > > > On Sun, 28 May 2017, Tetsuo Handa wrote: >

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Tue, 30 May 2017, Alan Cox wrote: > > > On Tue, 30 May 2017 23:29:10 +0900 > > Tetsuo Handa wrote: > > > > > James Morris wrote: > > > > On Sun, 28 May 2017, Tetsuo Handa wrote: > > > > > > > >

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Sun, 28 May 2017, Tetsuo Handa wrote: > > > can afford enabling". And we know that we cannot merge all security modules > > into mainline. Thus, allowing LKM-based LSM modules is inevitable. > > Nope, it's not inevitable. The LSM API

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

James Morris wrote: > On Sun, 28 May 2017, Tetsuo Handa wrote: > > > can afford enabling". And we know that we cannot merge all security modules > > into mainline. Thus, allowing LKM-based LSM modules is inevitable. > > Nope, it's not inevitable. The LSM API

Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events

Michal Hocko wrote: > On Tue 30-05-17 13:05:32, Roman Gushchin wrote: > > Add tracepoints to simplify the debugging of the oom reaper code. > > > > Trace the following events: > > 1) a process is marked as an oom victim, > > 2) a process is added to the oom reaper list, > > 3) the oom reaper

Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events

Michal Hocko wrote: > On Tue 30-05-17 13:05:32, Roman Gushchin wrote: > > Add tracepoints to simplify the debugging of the oom reaper code. > > > > Trace the following events: > > 1) a process is marked as an oom victim, > > 2) a process is added to the oom reaper list, > > 3) the oom reaper

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

able. In order to pass 80 columns check by scripts/checkpatch.pl , rename security_hook_heads to hook_heads. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Kees Cook <keesc...@chromium.org> Cc: Paul Moore <p...@paul-moore.com> Cc: Stephen Smalley <s..

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

able. In order to pass 80 columns check by scripts/checkpatch.pl , rename security_hook_heads to hook_heads. Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Chris

Re: [PATCH v9] mm: Add memory allocation watchdog kernel thread.

Tetsuo Handa wrote: > Changes from v7 [11]: > > (1) Reflect review comments from Andrew Morton. (Convert "u8 type" to > "bool report", use CPUHP_PAGE_ALLOC_DEAD event and replace > for_each_possible_cpu() with for_each_online_cpu(), re

Re: [PATCH v9] mm: Add memory allocation watchdog kernel thread.

Tetsuo Handa wrote: > Changes from v7 [11]: > > (1) Reflect review comments from Andrew Morton. (Convert "u8 type" to > "bool report", use CPUHP_PAGE_ALLOC_DEAD event and replace > for_each_possible_cpu() with for_each_online_cpu(), re

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Kees Cook wrote: > On Sat, May 27, 2017 at 4:17 AM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon > > registration.") treats "struct security_hook_heads" as an implici

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Kees Cook wrote: > On Sat, May 27, 2017 at 4:17 AM, Tetsuo Handa > wrote: > > Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon > > registration.") treats "struct security_hook_heads" as an implicit array > > of "struct li

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Casey Schaufler wrote: > > But currently, LSM_HOOK_INIT() macro depends on the address of > > security_hook_heads being known at compile time. If we use an enum > > so that LSM_HOOK_INIT() macro does not need to know absolute address of > > security_hook_heads, it will help us to use that

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

Casey Schaufler wrote: > > But currently, LSM_HOOK_INIT() macro depends on the address of > > security_hook_heads being known at compile time. If we use an enum > > so that LSM_HOOK_INIT() macro does not need to know absolute address of > > security_hook_heads, it will help us to use that

Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast

Kees Cook wrote: > On Sat, May 27, 2017 at 1:41 AM, Christoph Hellwig wrote: > > On Fri, May 26, 2017 at 01:17:09PM -0700, Kees Cook wrote: > >> The LSM initialization routines walk security_hook_heads as an array > >> of struct list_head instead of via names to avoid a ton of

Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast

Kees Cook wrote: > On Sat, May 27, 2017 at 1:41 AM, Christoph Hellwig wrote: > > On Fri, May 26, 2017 at 01:17:09PM -0700, Kees Cook wrote: > >> The LSM initialization routines walk security_hook_heads as an array > >> of struct list_head instead of via names to avoid a ton of needless > >>

[PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

mes a local variable, making it easier to allocate security_hook_heads at run time. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Kees Cook <keesc...@chromium.org> Cc: Paul Moore <p...@paul-moore.com> Cc: Stephen Smalley <s...@tycho.nsa.gov>

[PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

mes a local variable, making it easier to allocate security_hook_heads at run time. Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Christoph Hellwig --- include/linux/lsm_hooks.h | 412 +

Re: [Question] Mlocked count will not be decreased

Kefeng Wang wrote: > Hi All, > > Mlocked in meminfo will be increasing with an small testcase, and never be > released in mainline, > here is a testcase[1] to reproduce the issue, but the centos7.2/7.3 will not > increase. > > Is it normal? I confirmed your problem also occurs in Linux 4.11

Re: [Question] Mlocked count will not be decreased

Kefeng Wang wrote: > Hi All, > > Mlocked in meminfo will be increasing with an small testcase, and never be > released in mainline, > here is a testcase[1] to reproduce the issue, but the centos7.2/7.3 will not > increase. > > Is it normal? I confirmed your problem also occurs in Linux 4.11

Re: [PATCH] mm/oom_kill: count global and memory cgroup oom kills

On 2017/05/23 20:05, Konstantin Khlebnikov wrote: > On 23.05.2017 10:27, Michal Hocko wrote: >> On Fri 19-05-17 17:22:30, Konstantin Khlebnikov wrote: >>> Show count of global oom killer invocations in /proc/vmstat and >>> count of oom kills inside memory cgroup in knob "memory.events" >>> (in

Re: [PATCH] mm/oom_kill: count global and memory cgroup oom kills

On 2017/05/23 20:05, Konstantin Khlebnikov wrote: > On 23.05.2017 10:27, Michal Hocko wrote: >> On Fri 19-05-17 17:22:30, Konstantin Khlebnikov wrote: >>> Show count of global oom killer invocations in /proc/vmstat and >>> count of oom kills inside memory cgroup in knob "memory.events" >>> (in

Re: [PATCH] LSM: Make security_hook_heads a local variable.

Casey Schaufler wrote: > On 5/22/2017 12:50 PM, Igor Stoppa wrote: > > On 22/05/17 18:09, Casey Schaufler wrote: > >> On 5/22/2017 7:03 AM, Christoph Hellwig wrote: > > [...] > > > >>> But even with those we can still chain > >>> them together with a list with external linkage. > >> I gave up that

Re: [PATCH] LSM: Make security_hook_heads a local variable.

Casey Schaufler wrote: > On 5/22/2017 12:50 PM, Igor Stoppa wrote: > > On 22/05/17 18:09, Casey Schaufler wrote: > >> On 5/22/2017 7:03 AM, Christoph Hellwig wrote: > > [...] > > > >>> But even with those we can still chain > >>> them together with a list with external linkage. > >> I gave up that

[PATCH] LSM: Make security_hook_heads a local variable.

l be able to allocate and copy "struct security_hook_list ...[]" using smalloc(). Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Kees Cook <keesc...@chromium.org> Cc: Paul Moore <p...@paul-moore.com> Cc: Stephen Smalley <s...@tycho.nsa.gov&g

[PATCH] LSM: Make security_hook_heads a local variable.

l be able to allocate and copy "struct security_hook_list ...[]" using smalloc(). Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Greg KH --- include/linux/lsm_hooks.h | 6 +++--- security/security.

Re: [PATCH 0/8] CaitSith LSM module

John Johansen wrote: > On 05/20/2017 09:59 PM, Tetsuo Handa wrote: > > John Johansen wrote: > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > >>> Tetsuo Handa wrote: > >>>> John Johansen wrote: > >>>>>> In order to minimi

Re: [PATCH 0/8] CaitSith LSM module

John Johansen wrote: > On 05/20/2017 09:59 PM, Tetsuo Handa wrote: > > John Johansen wrote: > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > >>> Tetsuo Handa wrote: > >>>> John Johansen wrote: > >>>>>> In order to minimi

Re: [PATCH 0/8] CaitSith LSM module

John Johansen wrote: > On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > >> John Johansen wrote: > >>>> In order to minimize the burden of reviewing, this patchset implements > >>>> only functionality of checking program exec

Re: [PATCH 0/8] CaitSith LSM module

John Johansen wrote: > On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > >> John Johansen wrote: > >>>> In order to minimize the burden of reviewing, this patchset implements > >>>> only functionality of checking program exec

<    15   16   17   18   19   20   21   22   23   24   >