Tejun Heo (tj@xxxxxxxxxx) wrote: > Hello, > > On Fri, Mar 09, 2012 at 01:15:12PM -0800, Mandeep Singh Baines wrote: > > In this case, I need the per-cpu data for the duration of calculating > > a cryptographics hash on a 4K page of data. That's a long time to disable > > pre-emption. > > How long are we talking about? Tens of microsecs, tens of millisecs? > It depends on the H/W. We are running on Atom w/ PREEMPT_DESKTOP so we aren't pre-emptible even now. But I think there is interest from other folks in embedded to use the work. So it potentially be millisecs on a slower few hundred MHZ embedded processor. > > I could fix the bug temporarily by adding get/put for the per_cpu data > > but would that be acceptable? I'm not sure what the OK limit is for how > > long one can disable preemption. An alternative fix would be not allow > > CONFIG_VERITY when CONFIG_HOTPLUG_CPU. Once workqueues are fixed, I could > > remove that restriction. > > I think the right thing to do for now is to add cpu hotplug notifier > and do flush_work_sync() on the work item. We can later move that > logic into workqueue and remove it from crypto. > That seems like the correct solution. I will implement that. Thanks, Mandeep > Thanks. > > -- > tejun -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
