From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932694Ab0EYKaA (ORCPT ); Tue, 25 May 2010 06:30:00 -0400 Received: from 27.mail-out.ovh.net ([91.121.30.210]:46847 "HELO 27.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932609Ab0EYK37 (ORCPT ); Tue, 25 May 2010 06:29:59 -0400 Message-ID: <4BFBA6A2.4070405@example.com> Date: Tue, 25 May 2010 12:29:54 +0200 From: Piotr Hosowicz Reply-To: piotr@hosowicz.com Organization: hosowicz.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: piotr@hosowicz.com CC: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Jens Axboe , Divyesh Shah , Andrew Morton Subject: Re: BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449 References: <4BF9EC69.5030709@example.com> <1274777422.5882.591.camel@twins> <20100525094347.GA7881@elte.hu> <4BFB9F0A.9040803@example.com> <1274781655.5882.765.camel@twins> <4BFBA0F8.9090908@example.com> In-Reply-To: <4BFBA0F8.9090908@example.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 12025455431085093234 X-Ovh-Remote: 83.6.191.44 (abbb44.neoplus.adsl.tpnet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25.05.2010 12:05, Piotr Hosowicz wrote: > On 25.05.2010 12:00, Peter Zijlstra wrote: >> On Tue, 2010-05-25 at 11:57 +0200, Piotr Hosowicz wrote: >>> On 25.05.2010 11:43, Ingo Molnar wrote: >>> >>>> This doesnt fix the whole issue. cpu_clock() is local, while the >>>> measurements >>>> done in the blk code are global ... >>>> >>>> While the warning is fixed this way, the far more serious issue is >>>> still >>>> there: time can go backwards if two points of time measurement are on >>>> different CPUs and can mess up the statistics with negative values, >>>> etc... >>> >>> How serious is this? Can it damage my data? I ask because the machine is >>> my private computer, not any test machine. >> >> I'm not sure, since I didn't really look what they use the timestamps >> for, but a guess would say your data is safe, it might schedule the io >> funny, but it should not compromise integrity. At best its used purely >> for statistics and not even behaviour is affected. > > Thanks. Seems to work like a charm. I ask my question anew - shall I have to apply the patch each time I update my kernel tree? Regards, Piotr Hosowicz -- Janusz Korwin-Mikke: "Idiota z dyplomem to taki sam idiota, jak przedtem - tylko z pretensjami." NP: Slash - Ghost (Feat. Ian Astbury) NB: 2.6.34-20100524-1752-patched