Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752144AbaKJIem (ORCPT ); Mon, 10 Nov 2014 03:34:42 -0500 Received: from mga02.intel.com ([134.134.136.20]:15601 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861AbaKJIek (ORCPT ); Mon, 10 Nov 2014 03:34:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,351,1413270000"; d="scan'208";a="634323712" From: "Kweh, Hock Leong" To: Andy Lutomirski CC: Sam Protsenko , "linux-kernel@vger.kernel.org" , Greg KH , "Fleming, Matt" , "Ong, Boon Leong" , Ming Lei , "linux-efi@vger.kernel.org" Subject: RE: [PATCH v2 3/3] efi: Capsule update with user helper interface Thread-Topic: [PATCH v2 3/3] efi: Capsule update with user helper interface Thread-Index: AQHP9+iuHUs9oVBcgkKjHBOxgX5ANZxPaE0AgACL8cD//4fqAIAAgjoAgAAK9YCAAAv/gIAAD3kAgANofuD//8DLgIAGNTzQ Date: Mon, 10 Nov 2014 08:31:56 +0000 Message-ID: References: <1414984030-13859-1-git-send-email-hock.leong.kweh@intel.com> <1414984030-13859-4-git-send-email-hock.leong.kweh@intel.com> <20141104043247.GA23418@kroah.com> <1415110688.26277.36.camel@mfleming-mobl1.ger.corp.intel.com> <20141104154017.GA28113@kroah.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id sAA8YlaJ027460 > -----Original Message----- > From: Andy Lutomirski [mailto:luto@amacapital.net] > > #!/bin/sh > > > > old=$(cat > > /sys/devices/platform/efi_capsule_user_helper/capsule_loaded) > > > > for arg in "$@" > > do > > if [ -f $arg ] > > then > > echo 1 > /sys/class/firmware/efi-capsule-file/loading > > cat $arg > /sys/class/firmware/efi-capsule-file/data > > echo 0 > /sys/class/firmware/efi-capsule-file/loading > > I think you have a race. Try putting msleep(1000) after the > request_firmware_nowait call, and I bet this will fail on the second try. Sorry for the late response. I don't really catch the race condition that you are referring? Are you trying to tell that the user script could run faster before the previous callback function actually end? Will such scenario happen? In the callback function, after the request_firmware_nowait(), I don't have any codes will delay the callback function to end. Besides, there is a mutex_lock protecting the request_firmware_nowait() calling. Won't that take care of the issue? > > > > > oldtime=$(date +%S) > > oldtime=$(((time + 2) % 60)) > > until [ -f /sys/class/firmware/efi-capsule-file/loading ] > > do > > newtime=$(date +%S) > > if [ $newtime -eq $oldtime ] > > then > > break > > fi > > done > > > > old=$((old + 1)) > > new=$(cat > > /sys/devices/platform/efi_capsule_user_helper/capsule_loaded) > > I think that firmware_class doesn't call the callback until after loading is closed > for the second time. If so, then this is racy. Try inserting msleep(1000) at the > beginning of your callback and uploading a capsule that should load > successfully -- this will report failure, but a future upload may get very > confused. Also, what does the firmware class do when simultaneous > uploads of the same file with different contents are in flight? Is that possible? Sorry again, I can't really catch you on this race condition statement. Are you trying to tell if user is doing this: echo 1 > /sys/class/firmware/efi-capsule-file/loading cat capsule1 > /sys/class/firmware/efi-capsule-file/data cat capsule2 > /sys/class/firmware/efi-capsule-file/data echo 0 > /sys/class/firmware/efi-capsule-file/loading If so, capsule2 will be the one we will obtain in the callback function. Regards, Wilson ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?