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: <46094CA2.1050400@redhat.com>
Date:	Tue, 27 Mar 2007 12:56:02 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	clalance@...hat.com, mingo@...hat.com, davej@...hat.com,
	Thilo.Cestonaro.external@...itsu-siemens.com
Subject: Re: [PATCH]: Fix bogus softlockup warning with sysrq-t



Jeremy Fitzhardinge wrote:
> Prarit Bhargava wrote:
>   
>> I think that's a good idea -- I'll propose an add on patch to fix the
>> sysrq-t case ...
>>     
>
> I'm working on this patch at the moment.  I'm just wondering what
> happens if you do a global re-enable while a CPU is locally disabled.  I
> think it won't matter; it will end up in the "enabled but need to update
> timestamp" state, and the next time it gets a timer tick, it will simply
> update the timestamp and carry on.
>
> (This is relative to the other two softlockup patches, but modified
> since I posted them.)
>
>     J
>
> diff -r 4c81d8cafb67 drivers/char/sysrq.c
> --- a/drivers/char/sysrq.c	Tue Mar 27 01:16:07 2007 -0700
> +++ b/drivers/char/sysrq.c	Tue Mar 27 01:18:05 2007 -0700
> @@ -408,6 +408,8 @@ void __handle_sysrq(int key, struct tty_
>  	int i;
>  	unsigned long flags;
>  
> +	softlockup_global_disable();
> +
>  	spin_lock_irqsave(&sysrq_key_table_lock, flags);
>  	orig_log_level = console_loglevel;
>  	console_loglevel = 7;
> @@ -445,6 +447,8 @@ void __handle_sysrq(int key, struct tty_
>  		console_loglevel = orig_log_level;
>  	}
>  	spin_unlock_irqrestore(&sysrq_key_table_lock, flags);
> +
> +	softlockup_global_enable();
>   

I think that works -- I'll test it out on a big honkin' ia64 box ;)

Shouldn't you also do softlockup_disable/softlockup_enable instead of 
touch_softlockup_watchdog?  Why do we have both?  I can't see why we 
would have two exported methods to stop/reset the softlockup timer...

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ