Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5953256imu; Tue, 13 Nov 2018 14:33:58 -0800 (PST) X-Google-Smtp-Source: AJdET5cf+NmpRn0sJzEMKNEqbUdS4y48lshtGJt9j4ag+80Psfke2occO3XKQsu5UU6uz1CgOwtp X-Received: by 2002:a17:902:66e5:: with SMTP id e92-v6mr6794272plk.92.1542148438901; Tue, 13 Nov 2018 14:33:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542148438; cv=none; d=google.com; s=arc-20160816; b=Qxq3Il984ne5gKoFwDsMZH5EzF/j44S0amqbtu1CmJjdWjtDw/HWOP/5GM12sDbTeR glb+22VGlFYUoJN8FgS4XZGiqkTLogymu5AomkAic04FnFQ+imJD+NAzTrQiUICElTCF kBMkAg1rgtUWUYKXQoL4NqUIqTh7B04UlYIbyIG/+n1wN2QhKy8PMyMe4XTIUF8wp6ce FdveIYaRTVJ+gn3t0FmeeQ1sCUD9+JO8helIm+soApnJ0ghyeUEbaLTATBzMzCCe+1L+ 5136l5vu7HlV/U8i3WocT81i1uhtq4D0ohtRv0XqdVKGnKl3VHhGdJeuNDg0kgmmu4mX 9x1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=vs/egSq44jhFebt4iZ6lnnWIa5kbB0ICiSn3tZiSeMw=; b=tGbK6iDy185x0zl+RV6VSKJXFtFgxa/vjZBoPO+twvgZIVxQLeq1KtNzXxUS5kQZo9 Lgys1uV2gE4EofxazCK+N7wh/Ip76OiAT820LIJ6kDw3OYdLZ5CFwpMaFEMWuWghLkll 6R1025vBmKuJIKO/q4iK/ENWyejoQdGr1zaoncEF1SoRWUOc7FfpJ7EAV2WJOZ6WMm/I /rGiTuouPIDHFLIF1em6bwOitr7KKwGAvzUaX0lwNWgsvlroYUAOpNIMGgpsL4+uN1Lv MbsOTKkU4AvIBE93aqA4szmFnf4DWGc9DRiKzFWTPZYDrE+PTGIPxK54WZnToDNrSqXa gtRw== 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 k68-v6si20636422pgk.294.2018.11.13.14.33.41; Tue, 13 Nov 2018 14:33:58 -0800 (PST) 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 S1731062AbeKNIdf (ORCPT + 99 others); Wed, 14 Nov 2018 03:33:35 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:40340 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbeKNIdf (ORCPT ); Wed, 14 Nov 2018 03:33:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 6611329EE8; Tue, 13 Nov 2018 17:33:15 -0500 (EST) Date: Wed, 14 Nov 2018 09:33:42 +1100 (AEDT) From: Finn Thain To: Thomas Gleixner cc: Geert Uytterhoeven , Arnd Bergmann , Stephen N Chivers , Daniel Lezcano , John Stultz , linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 13/13] m68k: mvme16x: Convert to clocksource APIy In-Reply-To: Message-ID: References: <2f4015ba435f6f06b874295d2a47319875474c7f.1541995959.git.fthain@telegraphics.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Nov 2018, Thomas Gleixner wrote: > On Wed, 14 Nov 2018, Finn Thain wrote: > > > > What I mean by that is, the interrupt level (IPL) prevents interrupt > > handlers from being re-entered. But a handler can still get > > interrupted by a higher priority interrupt request. In the past I've > > had to add defensive locking because of this. > > > > In these patches I've assumed it was possible for some higher priority > > interrupt handler to perform a clocksource read after the timer > > handler started executing. Hence the use of local_irq_save/restore. > > > > To be sure, I've just run a quick test and confirmed that the timer > > handler can indeed get interrupted by the ethernet interrupt handler. > > Urgh. Then you have more serious trouble. If the interrupting handler > calls any of the time accessor functions then you can actually live lock > when the interrupt happens in the middle of the write locked section of > the core timekeeping update. Does this apply to arch_gettimeoffset also? If so, that would mean another bug fix patch for -stable... > So you really want to disable interrupts across the whole timer > interrupt function or make sure that the timer interrupt is the highest > priority one on the system. > The timer interrupt priority isn't always what one would hope. But I can certainly disable interrupts for timer_interrupt() execution (that is, xtime_update() etc.) -- > Thanks, > > tglx >