linux-kernel - Re: [FOR REVIEW, PATCH 2/2] introduce "struct wait_opts" to simplify do

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: <20090507075417.GA9836@elte.hu>
Date:	Thu, 7 May 2009 09:54:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Roland McGrath <roland@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [FOR REVIEW, PATCH 2/2] introduce "struct wait_opts" to
	simplify do_wait() pathes


* Oleg Nesterov <oleg@...hat.com> wrote:

> On 05/06, Ingo Molnar wrote:
> >
> > One small nit with the definition above: when using vertical spacing
> > (which really looks nice) we tend to put the asterix to the type
> > itself, not to the variable. I.e.:
> >
> > 	enum pid_type		wtype;
> > 	struct pid *		wpid;
> > 	int			wflags;
> >
> > ( This is done to separate the field name from the type - the
> >   pointer nature of the field is part of the type, not part of the
> >   name. )
> 
> Indeed, I like this more too. But checkpatch.pl disagrees!

That's probably a checkpatch bug mistaking * for multiplication - 
ignore checkpatch in that case and please report it to Andy 
Withcroft as well as well.

> > Regarding the patch itself: i guess we could do it as-is - but 
> > if you think there's regression risks, a safer approach would be 
> > to create 5-6 patches to build up all the structure parameters 
> > one by one.
> 
> Oh, I tried to do it this way first. But I got lost and decided to 
> make a single patch. Besides, if I make 6 patches I should try to 
> test each one...

One way to do it is to build-test them on a common config (say 
64-bit defconfig), and then boot test the final result. That makes 
it fully bisectable in 90% of the cases.

But ... it's really up to you. I'd be cautious out of box, as the 
quirk density in exit.c is still enormous and it's very easy to have 
some unintended side-effect.

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