linux-kernel - Re: [01/22] sched: Provide scheduler_ipi() callback in response to smp_send

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]

Date:	Mon, 14 Mar 2011 21:59:18 -0600
From:	Milton Miller <miltonm@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Chris Mason <chris.mason@...cle.com>,
	Frank Rowand <frank.rowand@...sony.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mike Galbraith <efault@....de>,
	Oleg Nesterov <oleg@...hat.com>, Paul Turner <pjt@...gle.com>,
	Jens Axboe <axboe@...nel.dk>,
	Yong Zhang <yong.zhang0@...il.com>,
	linux-kernel@...r.kernel.org,
	Russell King <rmk+kernel@....linux.org.uk>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Jesper Nilsson <jesper.nilsson@...s.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [01/22] sched: Provide scheduler_ipi() callback in response to
 smp_send_reschedule()

On Fri, 11 Mar 2011 16:27:27 +0100, Peter Zijlstra wrote:
> 
> On Fri, 2011-03-11 at 09:07 -0600, Milton Miller wrote:
> > >       case PPC_MSG_RESCHEDULE:
> > >               /* we notice need_resched on exit */
> > > +		    smp_reschedule_ipi()
> >
> > This comment should also be removed, as it was documenting the empty
> > action.
> 
> But its still true, TIF_NEED_RESCHED isn't going away and we still
> notice that on the interrupt return path.

Just because it is true does not mean it is useful.  Why is this site
different than the twenty odd other call sites that it needs to document
the behaivors requried upon exiting the kernel from interrupt deep in this
interrupt handling call path?  Why is it not placed after the call, where
it would talk about what happens next instead of what will happen later?
For that matter, what does on exit mean?

I went ahead and sent this when I saw the comments questioning the
sparc 32 part of the patch and thought you might respin.  But if this is
already committed then I will submit a followup patch for consideration
after this is merged.

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