From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E6891292FF for ; Mon, 3 Jun 2024 15:33:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717428837; cv=none; b=MqwxEDPPgIEUtq0cMADyyTMG6dLJeIOtEHSzHHmbFCRdm9V06ifnrU5Y1Q8A77wc0qxrrMcI2UtvkTAvywRBHrnmi69TKU8/iH6/t9FlvAuYsaZN00ZZyll5QeQwgo2tA7YMJCN/5vj2ocQHhNgQjja2Ikyg9nBFmDTBopVl0Uc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717428837; c=relaxed/simple; bh=RWgQzSiKwz+soRrVxETfYHRexxx/WGvMka/7e/m21FA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B0CKuMWWgKeKKIJczM+yfeKwACwtU8jFnzbzE/qqRuAhJHfk6RlEn1YYsYgzvcONy+L5uxe/R10KeEwBFATBC1AWksCC8hXnVn4bHmyNOCLRu8kxx3UtyzWoalFD+gAfgIoEwCM4QLl3aDDP4k0yX75IP8I+BzF8XXQ+Tk95yVw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ImVQK+zW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ImVQK+zW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CBA9C2BD10; Mon, 3 Jun 2024 15:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717428836; bh=RWgQzSiKwz+soRrVxETfYHRexxx/WGvMka/7e/m21FA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ImVQK+zW0ctIl9A/pUTNffkfSV5RQyJKvgt5F6QjKpSDj4dMR2snaR64YNKOK+XLR l5Q4OaWWMTHqBmMluB0TbI6/P1p/hHomWXwc3PMG3dYtndrHsX5SHgMTKZH8cVQJkn 53dzdnYIaxfMCwpSqow5JhrI/KJe5SRir0eOsPeTKB+aGVahsC8aIQ44ZSv/IQ1t9C QX5DqJ+xz27gozNLggfBZ4kvHUas6JhUvxJ1W9lpp7Dhj12/8QyXceCNXo8aUe2w2a klg7qtW1ryQO5ZzJbqcU4QlmSDtOdmrrhCu3Ixx3VcxQG1zdffR0LBlhNdSQBYPWff TUYToXQIigKIg== Message-ID: <7fb14a5e-0283-4551-a284-98f6d9ce02fb@kernel.org> Date: Mon, 3 Jun 2024 09:33:55 -0600 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] inet: bring NLM_DONE out to a separate recv() in inet_dump_ifaddr() Content-Language: en-US To: Jamal Hadi Salim Cc: Jakub Kicinski , Stephen Hemminger , davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com, Jaroslav Pulchart References: <20240601212517.644844-1-kuba@kernel.org> <20240601161013.10d5e52c@hermes.local> <20240601164814.3c34c807@kernel.org> From: David Ahern In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/3/24 8:05 AM, Jamal Hadi Salim wrote: > > Sorry, being a little lazy so asking instead: > NLMSG_DONE is traditionally the "EOT" (end of transaction) signal, if > you get rid of it - how does the user know there are more msgs coming > or the dump transaction is over? In addition to the user->kernel "I am > modern", perhaps set the nlmsg_flag in the reverse path to either say > "there's more coming" which you dont set on the last message or "we > are doing this the new way". Backward compat is very important - there > are dinosaur apps out there that will break otherwise. > NLM_DONE is not getting removed. The recent changes allow the end message signal without a separate system call.