linux-kernel - Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

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: <20070321184258.758a5a29.randy.dunlap@oracle.com>
Date:	Wed, 21 Mar 2007 18:42:58 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	g3vbv@...eyonder.co.uk
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Adrian Bunk <bunk@...sta.de>, linux-kernel@...r.kernel.org,
	auxsvr@...il.com
Subject: Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

On Thu, 22 Mar 2007 01:32:36 +0000 Sid Boyce wrote:

> Eric W. Biederman wrote:
> > Adrian Bunk <bunk@...sta.de> writes:
> >
> >   
> >> On Wed, Mar 21, 2007 at 05:43:11PM +0000, Sid Boyce wrote:
> >>     
> >>> Sid Boyce wrote:
> >>>       
> >>>> Andrew Morton wrote:
> >>>>         
> >>>>> (cc restored.  Please always do reply-to-all)
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> On Wed, 28 Feb 2007 18:05:13 +0200 auxsvr@...il.com wrote:
> >>>>>> On Wednesday 28 February 2007 17:19, Sid Boyce wrote:
> >>>>>>   
> >>>>>>             
> >>>>>>> openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to
> >>>>>>> require a password to unlock, but it asks for password. When the screen
> >>>>>>> unlocks, kwin is gone with no errors logged in /var/log/kdm or
> >>>>>>> /var/log/messages. No problems with 2.6.20.
> >>>>>>>
> >>>>>>> Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2.
> >>>>>>> Regards
> >>>>>>> Sid.
> >>>>>>>      
> >>>>>>>               
> >>>>>> This is the linux kernel mailing list. Perhaps you should post your 
> >>>>>> problem to the opensuse mailing list.
> >>>>>>    
> >>>>>>             
> >>>>> 2.6.20 worked.
> >>>>>
> >>>>> 2.6.20-rc2 did not.
> >>>>>
> >>>>> Working theory: the kernel broke.
> >>>>>
> >>>>> Sid, the chances that anyone can work out what caused this are pretty 
> >>>>> low. It would be great if you could perform a git bisection search 
> >>>>> sometime in
> >>>>> the next few weeks, work out which commit caused this.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>>
> >>>>>
> >>>>>  
> >>>>>           
> >>>> I shall go back to 2.6.20-git3 and work forward. Up to 2.6.20-git2 was OK.
> >>>> Regards
> >>>> Sid.
> >>>>
> >>>>         
> >>> I tracked the problem down to 2.6.20-git11. Up to 2.6.20-git10 is OK, 
> >>> but from 2.6.20-git11 up to current 2.6.21-rc4-git2 all exhibit the problem.
> >>>       
> >> Thanks for this search.
> >>
> >> Looking at the changes between 2.6.20-git10 and 2.6.20-git11, the only 
> >> suspicious changes are the 60 sysctl patches by Eric.
> >>
> >> Eric, can you look at this issue?
> >>     
> >
> > git bisect between git10 (ac98695d6c1508b724f246f38ce57fb4e3cec356)
> > and git11 (86a71dbd3e81e8870d0f0e56b87875f57e58222b) is likely the most
> > productive thing that can be done right now.  
> >
> > I can't think of anything in my sysctl patches that would kill an
> > application.  My sysctl work is right on the border with user space
> > so it is a good candidate but at the same time there should have
> > been no user visible changes.  There were a few places where
> > I removed sys_sysctl support (but not /proc/sys support) but I don't
> > think any of those were on x86, and they were is such a messed up
> > state I don't think anyone could have reasonably used them anyway.
> >
> > So I think either we poke blindly making random guess by hand or
> > we let git-bisect do it.
> >
> > Sid do you think you can figure out git-bisect?
> > git-bisect start
> > git-bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> > git-bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
> >
> > It should narrow the problem down to a single commit in 6-8 tries
> > after which point we should have enough information to start
> > making intelligent guesses. 
> >
> > Eric
> >
> >
> >   
> Reading the manpage doesn't help, so I shall have to delve  into the 
> docs or  futher help is needed.

There's not a lot of docs out there.

The man-page:  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

Linus's email doc:
http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt

I worked on something over last weekend, but it doesn't really add
much to the references above.

> :/usr/src/linux-2.6.20-git11 # git-bisect good 
> ac98695d6c1508b724f246f38ce57fb4e3cec356
> No revs to be shown.

Did you tell git where to begin with good and bad?  I.e., you have
to tell it the bracketing of where to do the binary search.

> :/usr/src/linux-2.6.20-git11 # ls .git/refs/bisect/
> bad                                            
> good-ac98695d6c1508b724f246f38ce57fb4e3cec356
> 
> :/usr/src/linux-2.6.20-git11 # less 
> .git/refs/bisect/good-ac98695d6c1508b724f246f38ce57fb4e3cec356
> ac98695d6c1508b724f246f38ce57fb4e3cec356
> 
> :/usr/src/linux-2.6.20-git11 # less .git/refs/bisect/bad
> 86a71dbd3e81e8870d0f0e56b87875f57e58222b


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/