Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp715685ybz; Wed, 15 Apr 2020 17:21:54 -0700 (PDT) X-Google-Smtp-Source: APiQypKX8m9G7PBCeC/sWfk7Z5+2fnESjoBvXm6Rxcobtnfi3D1NlUUm3crerTvjoVl+om76YrwV X-Received: by 2002:a50:f61b:: with SMTP id c27mr11455976edn.256.1586996514132; Wed, 15 Apr 2020 17:21:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586996514; cv=none; d=google.com; s=arc-20160816; b=PwJw7BwqVK/wEoefNNh7xtA5xYxFNOUGOABlMjtBp6US1O+4WVo2ndRNwvyqAOus1+ oI6u/kp2Dxx/ZbNvw1SoDpMnUgWtuLTRtFFGJ8YoyRw8VTvIiVMeDhkpAQrqdPghRLM0 CrfQr/ZsD1t+LHgo/9j/xMCSQR56AY3BjU5wYMVNTPIckIfaAt/DB6GqMGh63QtMd5cW k6EFLbLk5vWTc7m+5I+QsiWoOlcfYEvvwFUvBMMVtpXXEgsVWeWEu0gzquZAymPnBBNv K0VQG4AthS0L7OWeBL1w4ahyhZtiCkgpTZE8xzt/5qAdMnbL0l9+g5zxeEXcqN5OCX45 q6aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=WQlnHZ7tXa7wmYqD68ZKVLl6dyUIMp2Iqk2iZzO4W9c=; b=IrHFQRUgo4G/31b5yo+lUY06PwBeK0vWqpYFJ8VnF3Cn4YMUGp5vzqsVrgOK4qA7bE rdQCUMPEtbCs1r6koCMVxopwwqGeFKkZGwDwTITCgq2rxZX6/JxRZPXwl34wokkhFbYB N4TVMxWCr8TCwhIeBl7qNxZTrSlPJ8Z5Hv7z3FoHSAB+JzQsziQRJjPAvd4ycDTh8Ujv o4uWOwAe2/+LQf5I2ImznnEmuzpvn3+9V/1BKYYlSKj5y9RoxMz3l+tzjGxxlrkAwF05 pG7Cqb2BXht4lUfXhCdFS9yrdkaiOOLGq4OnKiA4QtYl1wp+Cqz84QfM9IKCTeVLPgef FB8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by8si6966081ejb.525.2020.04.15.17.21.31; Wed, 15 Apr 2020 17:21:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1416157AbgDOQfI (ORCPT + 99 others); Wed, 15 Apr 2020 12:35:08 -0400 Received: from foss.arm.com ([217.140.110.172]:49794 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1416090AbgDOQfG (ORCPT ); Wed, 15 Apr 2020 12:35:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 725901FB; Wed, 15 Apr 2020 09:35:03 -0700 (PDT) Received: from [10.37.9.9] (unknown [10.37.9.9]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 430EC3F6C4; Wed, 15 Apr 2020 09:35:02 -0700 (PDT) Subject: Re: [PATCH v2 0/6] arm64: add the time namespace support To: Andrei Vagin Cc: linux-arm-kernel@lists.infradead.org, LKML , Thomas Gleixner , Dmitry Safonov References: <20200225073731.465270-1-avagin@gmail.com> <1c1ab662-5475-9d8b-038b-8411b060202a@arm.com> <1d9c4c56-af16-e54f-08ca-76c6570b2d53@arm.com> From: Vincenzo Frascino Message-ID: <5f60bff9-0fe1-7f1f-2dcc-2a7363801897@arm.com> Date: Wed, 15 Apr 2020 17:35:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrei, On 4/15/20 5:14 PM, Andrei Vagin wrote: > On Tue, Apr 14, 2020 at 2:02 AM Vincenzo Frascino > wrote: >> >> Hi Andrei, >> >> On 4/11/20 8:33 AM, Andrei Vagin wrote: >>> On Thu, Apr 9, 2020 at 6:23 AM Vincenzo Frascino >>> wrote: >>>> >>>> I have though a question on something I encountered during the testing of the >>>> patches: I noticed that all the tests related to CLOCK_BOOTTIME_ALARM fail on >>>> arm64 (please find the results below the scissors). Is this expected? >>> >>> static int alarm_clock_get_timespec(clockid_t which_clock, struct >>> timespec64 *tp) >>> { >>> struct alarm_base *base = &alarm_bases[clock2alarm(which_clock)]; >>> >>> if (!alarmtimer_get_rtcdev()) >>> return -EINVAL; >>> >>> It is probably that you get EINVAL from here ^^^. I will send a >>> separate patch to handle this case in tests properly. >>> >> >> This makes sense :) Please let me know when you post the fix so I can test it again. > > I have sent this fix: https://lkml.org/lkml/2020/4/15/72 > That's good, I will try it by the end of this week or beginning of next and let you know the results. >> >> Are you planning as well to rebase this set?> > What is the right tree to rebase on? > I guess master, I was asking because it would make easier my testing :) > Thanks, > Andrei > -- Regards, Vincenzo