On Thu, Aug 10, 2017 at 3:02 AM, Michal Hocko wrote:
> On Tue 08-08-17 09:34:15, Paul Moore wrote:
>> On Mon, Aug 7, 2017 at 2:58 AM, Michal Hocko wrote:
>> > On Fri 04-08-17 13:12:04, Paul Moore wrote:
>> >> On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote:
>> > [...]
>> >> > Btw. Should I re
On Tue 08-08-17 09:34:15, Paul Moore wrote:
> On Mon, Aug 7, 2017 at 2:58 AM, Michal Hocko wrote:
> > On Fri 04-08-17 13:12:04, Paul Moore wrote:
> >> On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote:
> > [...]
> >> > Btw. Should I resend the patch or somebody will take it from this email
> >>
On Mon, Aug 7, 2017 at 2:58 AM, Michal Hocko wrote:
> On Fri 04-08-17 13:12:04, Paul Moore wrote:
>> On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote:
> [...]
>> > Btw. Should I resend the patch or somebody will take it from this email
>> > thread?
>>
>> No, unless your mailer mangled the patch
On Fri 04-08-17 13:12:04, Paul Moore wrote:
> On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote:
[...]
> > Btw. Should I resend the patch or somebody will take it from this email
> > thread?
>
> No, unless your mailer mangled the patch I should be able to pull it
> from this thread. However, I'
On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote:
> On Thu 03-08-17 14:17:26, Paul Moore wrote:
>> On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote:
>> > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote:
> [...]
>> >> When allocating thread is selected as an OOM victim, it gets TIF_MEMDIE.
>> >>
On Thu 03-08-17 14:17:26, Paul Moore wrote:
> On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote:
> > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote:
[...]
> >> When allocating thread is selected as an OOM victim, it gets TIF_MEMDIE.
> >> Since that function might be called from !in_interrupt() cont
On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote:
> On Thu 03-08-17 19:44:46, Tetsuo Handa wrote:
>> Michal Hocko wrote:
>> > On Thu 03-08-17 19:02:57, Tetsuo Handa wrote:
>> > > On 2017/08/03 17:11, Michal Hocko wrote:
>> > > > [CC Mel]
>> > > >
>> > > > On Wed 02-08-17 17:45:56, Paul Moore wro
On Thu 03-08-17 19:44:46, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Thu 03-08-17 19:02:57, Tetsuo Handa wrote:
> > > On 2017/08/03 17:11, Michal Hocko wrote:
> > > > [CC Mel]
> > > >
> > > > On Wed 02-08-17 17:45:56, Paul Moore wrote:
> > > >> On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko w
Michal Hocko wrote:
> On Thu 03-08-17 19:02:57, Tetsuo Handa wrote:
> > On 2017/08/03 17:11, Michal Hocko wrote:
> > > [CC Mel]
> > >
> > > On Wed 02-08-17 17:45:56, Paul Moore wrote:
> > >> On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko wrote:
> > >>> Hi,
> > >>> while doing something completely u
On Thu 03-08-17 19:02:57, Tetsuo Handa wrote:
> On 2017/08/03 17:11, Michal Hocko wrote:
> > [CC Mel]
> >
> > On Wed 02-08-17 17:45:56, Paul Moore wrote:
> >> On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko wrote:
> >>> Hi,
> >>> while doing something completely unrelated to selinux I've noticed a
>
On 2017/08/03 17:11, Michal Hocko wrote:
> [CC Mel]
>
> On Wed 02-08-17 17:45:56, Paul Moore wrote:
>> On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko wrote:
>>> Hi,
>>> while doing something completely unrelated to selinux I've noticed a
>>> really strange __GFP_NOMEMALLOC usage pattern in selinux,
On Thu, Aug 03, 2017 at 10:11:52AM +0200, Michal Hocko wrote:
> > The GFP_ATOMIC|__GFP_NOMEMALLOC use in SELinux appears to be limited
> > to security/selinux/avc.c, and digging a bit, I'm guessing commit
> > fa1aa143ac4a copied the combination from 6290c2c43973 ("selinux: tag
> > avc cache alloc a
[CC Mel]
On Wed 02-08-17 17:45:56, Paul Moore wrote:
> On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko wrote:
> > Hi,
> > while doing something completely unrelated to selinux I've noticed a
> > really strange __GFP_NOMEMALLOC usage pattern in selinux, especially
> > GFP_ATOMIC | __GFP_NOMEMALLOC do
On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko wrote:
> Hi,
> while doing something completely unrelated to selinux I've noticed a
> really strange __GFP_NOMEMALLOC usage pattern in selinux, especially
> GFP_ATOMIC | __GFP_NOMEMALLOC doesn't make much sense to me. GFP_ATOMIC
> on its own allows to a
Hi,
while doing something completely unrelated to selinux I've noticed a
really strange __GFP_NOMEMALLOC usage pattern in selinux, especially
GFP_ATOMIC | __GFP_NOMEMALLOC doesn't make much sense to me. GFP_ATOMIC
on its own allows to access memory reserves while the later flag tells
we cannot use
15 matches
Mail list logo