linux-kernel - Re: [PATCH] rfkill-input doesn't work until 5 minutes after boot

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: <20081004153929.846a0bde.akpm@linux-foundation.org>
Date:	Sat, 4 Oct 2008 15:39:29 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	dmitry.torokhov@...il.com, IvDoorn@...il.com, hmh@....eng.br,
	sitsofe@...oo.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rfkill-input doesn't work until 5 minutes after boot

On Sat, 4 Oct 2008 21:43:43 +0100 Matthew Garrett <mjg59@...f.ucam.org> wrote:

> rfkill-input implements debounce as follows:
> 
>         if (time_after(jiffies, task->last + msecs_to_jiffies(200))) {
> 
> However, task->last is initialised to 0 while jiffies starts at -300*HZ. 
> Any input within 5 minutes of kernel start is therefore ignored. Fix by 
> initialising task->last correctly.
> 
> Signed-off-by: Matthew Garrett <mjg@...hat.com>
> 
> 
> diff --git a/net/rfkill/rfkill-input.c b/net/rfkill/rfkill-input.c
> index e5b6955..de75934 100644
> --- a/net/rfkill/rfkill-input.c
> +++ b/net/rfkill/rfkill-input.c
> @@ -101,6 +101,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task)
>  		.mutex = __MUTEX_INITIALIZER(n.mutex),		\
>  		.lock = __SPIN_LOCK_UNLOCKED(n.lock),		\
>  		.desired_state = RFKILL_STATE_UNBLOCKED,	\
> +		.last = INITIAL_JIFFIES,			\
>  	}
>  
>  static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN);
> 

That'll only work as intended if CONFIG_RFKILL_INPUT=y?  If the module
is loaded 10 minutes after boot, the timestamp is still wrong.  It might
happily happen to work, but will still fail after 2^31 jiffies (or something
like that).

Generally speaking, INITIAL_JIFFIES is a secret internal debugging
detail and its use out in general kernel code is a red flag.

I think this initialisation should be done at runtime somehow.

> .27 material?

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