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] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0810020111450.11373@gandalf.stny.rr.com>
Date:	Thu, 2 Oct 2008 01:20:08 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jon Masters <jonathan@...masters.org>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Veen <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Sven Dietrich <sdietrich@...e.de>
Subject: Re: [RFC patch 5/5] genirq: make irq threading robust


On Wed, 1 Oct 2008, Jon Masters wrote:

> On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> 
> > To make sure that a crashed irq thread does not cause more trouble
> > when the irq code tries to wake up a gone thread or the device code
> > calling free_irq and trying to kthread_stop the dead thread, we plug a
> > pointer to irqaction into task_struct, which is evaluated in
> > do_exit(). When the thread crashes the do_exit code marks the thread
> > as DIED in irqaction->flags to prevent further wakeups from the
> > interrupt handler code.
> 
> > @@ -1301,6 +1301,7 @@ struct task_struct {
> >  	int latency_record_count;
> >  	struct latency_record latency_record[LT_SAVECOUNT];
> >  #endif
> > +	struct irqaction *irqaction;
> >  };
> 
> Is that going to fly? For the vast majority of task_structs this is now
> a wasted 4/8 bytes that won't be used.

Perhaps we could convert parts of the task_struct into a union.
There is quite a lot of things that I'm not sure kernel threads use.

fpu_counter? well, it is only one byte.
binfmt?

Do kernel threads use group_leader?

What about the ptraced items?

group ids/info on kernel threads?

do kernel threads need robust futex info?

This was just a quick look at the task struct. Perhaps we could separate
out kernel only and user space only info and bring the total size down?

Although I'm not sure how much is there that is kernel_thread only :-/
Of course this irqaction will be.

-- Steve
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ