linux-kernel - Re: [rtc-linux] Re: [PATCH 3/9 v2] rtc: rtc-hid-sensor-time: delay registering as rtc into a work

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: <20130626220758.GA32461@kroah.com>
Date:	Wed, 26 Jun 2013 15:07:58 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Alexander Holler <holler@...oftware.de>
Cc:	rtc-linux@...glegroups.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [rtc-linux] Re: [PATCH 3/9 v2] rtc: rtc-hid-sensor-time: delay
 registering as rtc into a work

On Wed, Jun 26, 2013 at 11:34:35PM +0200, Alexander Holler wrote:
> >> +	/*
> >> +	 * The HID device has to be registered to read the clock.
> >> +	 * Because rtc_device_register() might read the time, we have to delay
> >> +	 * rtc_device_register() to a work in order to finish the probe before.
> >> +	 */
> >> +	time_state->workts = kmalloc(sizeof(struct hid_time_workts),
> >> +		GFP_KERNEL);
> >> +	if (time_state->workts == NULL) {
> >> +		sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
> >> +		return -ENOMEM;
> >>  	}
> >> +	time_state->workts->time_state = time_state;
> >> +	INIT_WORK(&time_state->workts->work,
> >> +			hid_time_register_rtc_work);
> >> +	schedule_work(&time_state->workts->work);
> > 
> > This seems unreliable.  The scheduled work can run one nanosecond
> > later, on this or a different CPU.  What guarantees that the HID device
> > will then be fully registered?
> 
> Nothing, but schedule_delayed_work() is as unreliable as without delay
> and I don't know of any callback after registration has happened. I have
> to dig through the hid-(sensor-)code, maybe I will find a callback I can
> (mis)use to register the rtc driver after the hid driver was registered.

Why not use the deferred_probe code, which is there just for this type
of thing (i.e. your other drivers/devices aren't present/initialized
yet.)?  Just return -EPROBE_DEFER from your probe function if you don't
find everything already set up properly, the driver core will call you
again later after it has initialized everything it has found.

Hope this helps,

greg k-h
--
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/