linux-kernel - Re: How to check whether executing in atomic context?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f22d86810910150131l303200bfq952f479b3fbff563@mail.gmail.com>
Date:	Thu, 15 Oct 2009 01:31:30 -0700
From:	"Leonidas ." <leonidas137@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Gleb Natapov <gleb@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: How to check whether executing in atomic context?

On Wed, Oct 14, 2009 at 12:24 PM, Leonidas . <leonidas137@...il.com> wrote:
> On Thu, Oct 15, 2009 at 12:45 AM, Stefan Richter
> <stefanr@...6.in-berlin.de> wrote:
>> Leonidas . wrote:
>>> On Wed, Oct 14, 2009 at 11:09 PM, Stefan Richter
>>> <stefanr@...6.in-berlin.de> wrote:
>>>> let the caller of your routine tell it whether it's atomic context
>>>> or not.
>> [...]
>>> What makes it more complicated is this, the user might achieve the
>>> functionality via instrumenting his source code, i.e. something like
>>> using -finstrument flag of gcc. As per above inferences about
>>> in_atomic(), in case of instrumentation there is no choice other than
>>> providing all apis as atomic apis, this might not be the right thing
>>> to do under all circumstances. Especially, for my code since I do lot
>>> of allocations for book keeping.
>>>
>>> I am not aware of any Linux kernel module which can comply to this
>>> kind of use case, what would be the most optimal thing to do here?
>>
>> And preallocation is not feasible either?
>> --
>> Stefan Richter
>> -=====-==--= =-=- -===-
>> http://arcgraph.de/sr/
>>
>
> Yes, I preallocate a buffer at module init time. But assume that, I am
> profiling kmalloc(),
> and number of kmallocs() done over time increases rapidly, I need to allocate
> on demand as well depending on the load. (Actually, I am not profiling kmalloc,
> it just makes a good example in this case). Currently, I preallocate a
> large buffer
> and as I reach the threshold, I try to grab small buffers as needed.
> Obvious solution
> here would be to grab a larger buffer, the only issue here would be it
> might be just wasteful.
>
> So, knowing the running context and allocating sounded like a better idea to me.
>
> -Leo.
>

>Or deferring work to a kernel thread.

You mean, have a kernel thread periodically check the memory
requirements and do allocations in
kernel thread context? So basically, insuring that all the allocations
are done outside atomic context
i.e. either preallocate or use kernel thread.

-Leo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/