From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: workqueues and percpu (was: [PATCH] dm: remake of the verity target) Date: Fri, 9 Mar 2012 13:20:49 -0800 Message-ID: <20120309212049.GD24890@google.com> References: <1330648393-20692-1-git-send-email-msb@chromium.org> <20120306215947.GB27051@google.com> <20120308143909.bfc4cb4d.akpm@linux-foundation.org> <20120308231521.GA2968@htj.dyndns.org> <20120309211512.GL27051@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20120309211512.GL27051@google.com> Sender: linux-kernel-owner@vger.kernel.org To: Mandeep Singh Baines Cc: Andrew Morton , Mikulas Patocka , linux-kernel@vger.kernel.org, dm-devel@redhat.com, Alasdair G Kergon , Will Drewry , Elly Jones , Milan Broz , Olof Johansson , Steffen Klassert , Rusty Russell List-Id: dm-devel.ids 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? > 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. Thanks. -- tejun