Received: by 10.192.165.148 with SMTP id m20csp4908834imm; Tue, 24 Apr 2018 10:20:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqop0UB+Kj8lXRUb6gJG9cxoEJpmW/mezE2h6YlW7fRpil6N8P0Dny5ogj3MqpwVqxLB4ft X-Received: by 10.101.99.90 with SMTP id p26mr142279pgv.163.1524590451936; Tue, 24 Apr 2018 10:20:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524590451; cv=none; d=google.com; s=arc-20160816; b=x1oG+VGq1SL5LV5MTsFduMzDhLSWDxIEwHJeIO/8onjXAoiRCBzEPDqszq8wismeER RZNEiE+NAda/bp5rLEVb2WzN7sXspg8qkN5yPkXUckZmiozIPYh9cEPbnaeUHLTjbVUN +q7+BWEZ80HDSi0oTaYGmjICole8E0N44qTMhGWDkEoBizMtOK/yilTc2tKNDl2cgnDB tMCUX2Cn1BD+xPIVv7P2NNW674aerQbwpvjvCI6M43iAxMuJbelrzecOAXz2f0tq7BLF B+TzpzJx2uQbIaKq5pH8Cr0yZ/wmVqkvYiy0CTss4q6A4cJ5ka1lXDDVEhT+Xe9vpRnA qGaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=bNr1iTSJZ+G39MK0NvSwGxOVC1VUo9IfgtM5tOUR64U=; b=zVo1VyWrR2jru5hJHEjjzFzitc5lF97jeUwZ5FJBPWZxzx5CVH+y9BPeeL32RC8h/0 Oas0ySxJRYopNs9Owc3zAmXVtGw2W4HV3gOO3sVevqvbZGvVfakdg9R1SD4ro099svET A/81avkUG10SDTlyqgr0WncLK4rlPHAeH9rybQhZ86EjtIgvBn3MSMIlnJsV+pAhe1eC JoxM7JZAFhDrVCod547cHjZLHSALT4n8Xr1DYgR5gsGoPx0yw9rpl/85xIoZIjBV2P53 ewo9sweSZntqqCXn/nOkY8enqR2xcXfcfqbCvxne+gv9S4u+fD0UvQAo09JI9kEcpAVP xsVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l4si11929342pgc.374.2018.04.24.10.20.37; Tue, 24 Apr 2018 10:20:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752485AbeDXRTO (ORCPT + 99 others); Tue, 24 Apr 2018 13:19:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:44944 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752262AbeDXRTF (ORCPT ); Tue, 24 Apr 2018 13:19:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2F2F4AC64; Tue, 24 Apr 2018 17:19:04 +0000 (UTC) Date: Tue, 24 Apr 2018 19:19:02 +0200 From: Libor Pechacek To: Joe Lawrence Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, live-patching@vger.kernel.org, Jiri Kosina , Artem Savkov , Josh Poimboeuf , Petr Mladek , Miroslav Benes , Nicolai Stange Subject: Re: [PATCH v3] selftests/livepatch: introduce tests Message-ID: <20180424171902.z4ymubblh2dtcp4h@fmn.suse.cz> References: <1523544871-29444-1-git-send-email-joe.lawrence@redhat.com> <1523544871-29444-2-git-send-email-joe.lawrence@redhat.com> <20180420125605.e4eye7ncukyivleh@fm.suse.cz> <20180423144317.too6ucui37m7oj7y@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 24-04-18 11:50:28, Joe Lawrence wrote: > On 04/23/2018 10:43 AM, Joe Lawrence wrote: > > On Fri, Apr 20, 2018 at 02:56:05PM +0200, Libor Pechacek wrote: > >> On Thu 12-04-18 10:54:31, Joe Lawrence wrote: > >>> + fi > >>> + echo "$ret" > /dev/kmsg > >>> +} > >>> + > >>> +# unload_mod(modname) - unload a kernel module > >>> +# modname - module name to unload > >>> +function unload_mod() { > >>> + local mod="$1" > >>> + > >>> + # Wait for module reference count to clear ... > >>> + local i=0 > >>> + while [[ $(cat /sys/module/"$mod"/refcnt) != "0" ]]; do > >>> + i=$((i+1)) > >>> + if [[ $i -eq $MAX_RETRIES ]]; then > >>> + die "failed to unload module $mod (refcnt)" > >>> + fi > >>> + sleep $RETRY_INTERVAL > >>> + done > >> > >> The repeating pattern of "while ; do ; if >> retries>; then ..." seems to ask for encapsulation. > >> > > > > Yeah I definitely agree. I think at some point I had acquired > > bash-fatigue; I wasn't sure how to cleanly wrap around that > > extra logic. In C, I could do something clever with macros or a > > callback function. My bash scripting isn't great, so I copied and > > pasted my way through it. Suggestions welcome. > > > > Okay, here's what I came up with... first off, do you prefer this kind > of transition check vs. looking only at a specific module? > > # check_transition() - verify that no livepatch transition in effect > function check_transition() { > grep -q '^1$' /sys/kernel/livepatch/*/transition 2>/dev/null > } Elegant! > then wrap the retry/timeout logic like: > > # retry_cmd(cmd) - loop a command until it is successful or > # $MAX_RETRIES, sleeping $RETRY_INTERVAL in > # between tries > # cmd - command and its arguments to run > function retry_cmd() { > local cmd="$*" > local i=0 > while eval "$cmd"; do > i=$((i+1)) > [[ $i -eq $MAX_RETRIES ]] && return 1 > sleep $RETRY_INTERVAL > done > return 0 > } > > and the callers to something like: > > # wait_for_transition() - wait until all livepatch transitions clear > function wait_for_transition() { > retry_cmd check_transition || > die "failed to complete transition" > } My idea was to make the die() part of the retry loop. This implementation is, however, more flexible. > I can create similar check() functions to eval for sysfs file existence, > file content, reference count, etc. to remove all the other > retry/timeout loops. I think check_*() functions can be avoided for trivial tests. retry_cmd() can be passed a more complex command string than a single function name. Regarding naming, I'd say wait_false() or similar would better describe what retry_cmd() does. Libor -- Libor Pechacek SUSE Labs