linux-kernel - Re: [PATCH] Fix direct mapping alias regressin in ioremap v2

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: <20080214213417.GA19473@one.firstfloor.org>
Date:	Thu, 14 Feb 2008 22:34:17 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <andi@...stfloor.org>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH] Fix direct mapping alias regressin in ioremap v2

On Thu, Feb 14, 2008 at 06:42:37PM +0100, Ingo Molnar wrote:
> 
> * Andi Kleen <andi@...stfloor.org> wrote:
> 
> >     Fix bug noticed by Ingo of __va() wrapping on 32bit
> 
> what you should realize is that had we applied your previous patch in a 
> rush, it would have introduced a far more serious regression than the 
> type of problem you are trying to solve. That's one of the reasons why 
> we disagree with your sense of urgency.

Sense of urgency in this case just means for 2.6.25 which
is still a few weeks away.

Sorry for not being a perfect being. Yes I did test the patch, but
no my testing did not catch the problem unfortunately. But I'm grateful
that your review caught the problem.

> 
> We've got the clean fixes queued up and it's all under testing. (going 
> fine so far)

Ok but will you push them to .25?

> 
> Also, you only appear to have resent your fix with the obvious bug 
> fixed, but it's still unclean and you do not seem to have replied to my 

First I disagree on you describing my change as unclean. There is nothing
particularly unclean about it. It's basically back to the same
code as it was in .24 for this case.

I think fixing this regression is important for 2.6.25
and I didn't think intrusive changes to pageattr.c are a good idea anymore 
for .25 at this stage so I did a simple fix.

I chose to fix this in the simplest way I could think of by
more or less going back to the old .24 code just adapted 
for the new interfaces.

Now if you decide you want to push the big changes in #mm that
make cpa work generally for ioremaps to .25 that would probably[1] fix the 
regression too and I wouldn't complain too loudly about that. 

But at least I personally think a as simple as possible fix is better at 
this stage.

[1] I reserve judgement at this stage because I have not reviewed the latest
code there in detail yet.

> > > Please have a look at how we solved the "secondary alias" 64-bit 
> > > problem in x86.git#mm and please resend against x86.git#mm if you 
> > > still think something is missing. Thanks,

I can send it against whatever tree contains the fixes going before
2.6.25 to Linus. Is that #mm now?  I thought it was git-x86#master
so far that I is why I sent it against mainline which is virtually
identical to git-x86#master in this area.

-Andi

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