Andi Kleen wrote:
It does seem risky. Perhaps it is a micro-optimisation which utilises
knowledge that this thread_struct cannot be looked up via any path in this
context.
Or perhaps it is a bug. Andi, can you please comment?
On flush_thread nobody else can mess with the thread, so yes
On Mon, 5 Mar 2007 15:40:33 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > It does seem risky. Perhaps it is a micro-optimisation which utilises
> > knowledge that this thread_struct cannot be looked up via any path in this
> > context.
> >
> > Or perhaps it is a bug. Andi, can you please comm
On Mar 01, 2007, at 17:41:38, Andrew Morton wrote:
Well, it's unusual for code to want to test multiple bitflags in
the same operation. Perhaps thread_info.flags is unusual in that
regard.
But one can still do
if (foo->flags & (1
> It does seem risky. Perhaps it is a micro-optimisation which utilises
> knowledge that this thread_struct cannot be looked up via any path in this
> context.
>
> Or perhaps it is a bug. Andi, can you please comment?
On flush_thread nobody else can mess with the thread, so yes it's a micro
opt
On Thu, 01 Mar 2007 11:59:07 -0800
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >>> On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> >>> wrote:
>
Andrew Morton wrote:
On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
No, I don't immediately see any
On Thu, 1 Mar 2007 11:14:47 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> On Thu, 1 Mar 2007 01:45:23 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > If there's a lesson here, it is "don't provide #defines in the header for
> > both versions".
>
> Yes, that's true. It looks like a
On Thu, 1 Mar 2007 01:45:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> If there's a lesson here, it is "don't provide #defines in the header for
> both versions".
Yes, that's true. It looks like all the other arches do the same thing
with the _TIF flags, however, so just ripping it out prob
On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> > On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > wrote:
>
> > > avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
> >
> > No, I don't immediately see anything in the flush
[trimming cc list since I'm only replying to the avr32 part]
On Wed, 28 Feb 2007 22:03:49 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
> > avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
>
> No,
On Wed, 28 Feb 2007 22:23:41 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> > That all looks rather deliberate.
> >
> > > powerpc/kernel/process.c: t->flags ^= (_TIF_ABI_PENDING |
> > > _TIF_32BIT);
> > >
> > > ia64/kernel/mca.c: ti->flags = _TIF_MCA_INIT;
> > >
> > > a
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 22:03:49 -0800
> On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > Other examples :
> >
> > sparc64/kernel/ptrace.c:if
> > ((task_thread_info(child)->flags & _TIF_32BIT) != 0) {
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Hi,
How come I'm the only person around here with a Reply button?
> Looking into the thread flags, I found out that some architecture
> specific kernel functions (in 2.6.20) sets the thread flags with non
> atomi
Hi,
Looking into the thread flags, I found out that some architecture
specific kernel functions (in 2.6.20) sets the thread flags with non
atomic operation.
A good way to list the most trivial : grep -r TIF_ * | grep =
Some examples follows. If, for instance,
x86_64/kernel/process.c:flush_t
14 matches
Mail list logo
