linux-kernel - Re: [RFC][PATCH] kmap_atomic

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:	Thu, 8 Oct 2009 09:50:49 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"hugh.dickins" <hugh.dickins@...cali.co.uk>,
	David Howells <dhowells@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC][PATCH] kmap_atomic_push

On Thu, 8 Oct 2009, Peter Zijlstra wrote:
> 
> Right, so I did that full rename just so that people wouldn't get
> confused or something, but if both you and Linus think it should remain:
> kmap_atomic() and kunmap_atomic(), I can certainly undo that part.

I think the renaming probably helps find all the places (simple "grep -w" 
shows the difference, and no fear of confusion with comma-expressions and 
multi-line arguments etc). But once they've all been converted, you might 
as well then do a search-and-replace-back on the patch, and make the end 
result look like you just removed the (now pointless) argument.

In fact, I'd personally be inclined to split the patch into two patches:

 - one that just ignores the now redundant argument (but still keeps it), 
   and fixes the cases that didn't nest

 - one that then removes the argument.

Why? The _bugs_ are going to be shown by the first patch, and it would be 
nice to keep that patch small. When a bug shows up, it would be either 
because there's something wrong in that (much smaller) patch, or because 
some not-properly-nested casel wasn't fixed.

In contrast, the second patch would be large, but if done right, you could 
then prove that it has no actual semantic changes (ie "binary is same 
before and after"). That just sounds _much_ nicer from a debug standpoint. 
Developers would look at the small and concentrated "real changes" patch, 
rather than be distracted by all the trivial noise.

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