Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp684997pxu; Mon, 23 Nov 2020 01:05:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJx50UUrWS/+lyugbMwcFvAnbdk/eyax5qByMk5yXB0tHc8Xj26qo0XZd2bSjH2Wb159+S2S X-Received: by 2002:a05:6402:d08:: with SMTP id eb8mr15471282edb.271.1606122325738; Mon, 23 Nov 2020 01:05:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606122325; cv=none; d=google.com; s=arc-20160816; b=Zty54g1qdDsRONHMSIXwdb2Q6IRni1ieT3H7nQHc654iByDVZGOVRUalpxYVeQnpgy xJDa9h5V8Ypej6iWN56lax7TgL8f2Co8ih3uPzuClZMPMS73wYBZ4QhKO+rteKKExMM7 1XyQ4+Sl5Z1x3adBZwGPkC++4gAfQnR59AtJy16Vkwd3Kgnk4O6fv1SkrygJxRovy7yv PIjhX4yOB4OZH/8pvMjNVskgzRf+8j7x68iq41KCRbwV1WFO+O63spMMlxqxWOzIvHh6 vuhPRZ3y+gs7UlNU1ZWZS2YAbEcXcz6MHQl9Ej3nBELLobEaSDVoF3UOGHn3oJlM6t6z FyGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :organization:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=amwbS5dONY+S0BYGTsuScecfsaHlsllNB1FenaT05xI=; b=NjJ36rLJSZQM8ExA+phj6PdkmtFGgk8iEtEunts7UEeft7akCQQ5tX3x2E2MJbeyzk xnE7Fooei6hwzc628IKwFC52rK4y4AYFsGpj2vSPFwS8OQxe+a4QCqkDerbPbgExhCwG 5Zc9zIo/toJp22NvMlsOAm1Ro+4CKoNrljZUwHIAJn1QGr7T72abGxbClOtGGrj+A9GA SaDDCMf6pGpLf+lgk2xOgLcrSAtCu9ow89MEnc6GiO7RGVu5NRhzc4BmjxewcfvZTQaT G6iJXIMliAL/EIKpDNkOaRU8n3dR9P0vz3RJZ0WeFJZAcuTXs6++3FGpuGBDDpEzQ8EV 8+MA== 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 t12si8207648edc.298.2020.11.23.01.05.03; Mon, 23 Nov 2020 01:05:25 -0800 (PST) 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 S1726260AbgKWJAQ (ORCPT + 99 others); Mon, 23 Nov 2020 04:00:16 -0500 Received: from mxout70.expurgate.net ([194.37.255.70]:54335 "EHLO mxout70.expurgate.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725275AbgKWJAQ (ORCPT ); Mon, 23 Nov 2020 04:00:16 -0500 Received: from [127.0.0.1] (helo=localhost) by relay.expurgate.net with smtp (Exim 4.90) (envelope-from ) id 1kh7he-0007dS-1W; Mon, 23 Nov 2020 10:00:06 +0100 Received: from [195.243.126.94] (helo=securemail.tdt.de) by relay.expurgate.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90) (envelope-from ) id 1kh7hc-00079Z-Vb; Mon, 23 Nov 2020 10:00:05 +0100 Received: from securemail.tdt.de (localhost [127.0.0.1]) by securemail.tdt.de (Postfix) with ESMTP id 55B8A240041; Mon, 23 Nov 2020 10:00:04 +0100 (CET) Received: from mail.dev.tdt.de (unknown [10.2.4.42]) by securemail.tdt.de (Postfix) with ESMTP id C8593240040; Mon, 23 Nov 2020 10:00:03 +0100 (CET) Received: from mail.dev.tdt.de (localhost [IPv6:::1]) by mail.dev.tdt.de (Postfix) with ESMTP id 8512B203C7; Mon, 23 Nov 2020 10:00:02 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Nov 2020 10:00:02 +0100 From: Martin Schiller To: Xie He Cc: Andrew Hendry , "David S. Miller" , Jakub Kicinski , Linux X25 , Linux Kernel Network Developers , LKML Subject: Re: [PATCH net-next v4 2/5] net/lapb: support netdev events Organization: TDT AG In-Reply-To: References: <20201120054036.15199-1-ms@dev.tdt.de> <20201120054036.15199-3-ms@dev.tdt.de> <87a620b6a55ea8386bffefca0a1f8b77@dev.tdt.de> Message-ID: X-Sender: ms@dev.tdt.de User-Agent: Roundcube Webmail/1.3.15 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.dev.tdt.de X-purgate: clean X-purgate-ID: 151534::1606122005-000064E4-D07DD3F9/0/0 X-purgate-type: clean Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-11-23 09:31, Xie He wrote: > On Sun, Nov 22, 2020 at 10:55 PM Martin Schiller wrote: >> >> No, they aren't independent. The carrier can only be up if the device >> / >> interface is UP. And as far as I can see a NETDEV_CHANGE event will >> also >> only be generated on interfaces that are UP. >> >> So you can be sure, that if there is a NETDEV_CHANGE event then the >> device is UP. > > OK. Thanks for your explanation! > >> I removed the NETDEV_UP handling because I don't think it makes sense >> to implicitly try to establish layer2 (LAPB) if there is no carrier. > > As I understand, when the device goes up, the carrier can be either > down or up. Right? > > If this is true, when a device goes up and the carrier then goes up > after that, L2 will automatically connect, but if a device goes up and > the carrier is already up, L2 will not automatically connect. I think > it might be better to eliminate this difference in handling. It might > be better to make it automatically connect in both situations, or in > neither situations. AFAIK the carrier can't be up before the device is up. Therefore, there will be a NETDEV_CHANGE event after the NETDEV_UP event. This is what I can see in my tests (with the HDLC interface). Is the behaviour different for e.g. lapbether? > > If you want to go with the second way (auto connect in neither > situations), the next (3rd) patch of this series might be also not > needed. > > I just want to make the behavior of LAPB more consistent. I think we > should either make LAPB auto-connect in all situations, or make LAPB > wait for L3's instruction to connect in all situations. > >> And with the first X.25 connection request on that interface, it will >> be established anyway by x25_transmit_link(). >> >> I've tested it here with an HDLC WAN Adapter and it works as expected. >> >> These are also the ideal conditions for the already mentioned "on >> demand" scenario. The only necessary change would be to call >> x25_terminate_link() on an interface after clearing the last X.25 >> session. >> >> > On NETDEV_GOING_DOWN, we can also check the carrier status first and >> > if it is down, we don't need to call lapb_disconnect_request. >> >> This is not necessary because lapb_disconnect_request() checks the >> current state. And if the carrier is DOWN then the state should also >> be >> LAPB_STATE_0 and so lapb_disconnect_request() does nothing. > > Yes, I understand. I just thought adding this check might make the > code cleaner. But you are right.