From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahide NAKAMURA Subject: Re: [PATCH 36/44] [XFRM]: Introduce XFRM_MSG_REPORT. Date: Thu, 24 Aug 2006 15:48:10 +0900 Message-ID: <44ED4BAA.1040106@linux-ipv6.org> References: <1156345367208-git-send-email-yoshfuji@linux-ipv6.org> <11563453673786-git-send-email-yoshfuji@linux-ipv6.org> <11563453672531-git-send-email-yoshfuji@linux-ipv6.org> <20060823.204352.123974654.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yoshfuji@linux-ipv6.org, anttit@tcs.hut.fi, vnuorval@tcs.hut.fi, netdev@vger.kernel.org, usagi-core@linux-ipv6.org Return-path: Received: from [203.178.140.9] ([203.178.140.9]:16588 "EHLO mail.gomagoma.org") by vger.kernel.org with ESMTP id S1030358AbWHXGrv (ORCPT ); Thu, 24 Aug 2006 02:47:51 -0400 To: David Miller In-Reply-To: <20060823.204352.123974654.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org David Miller wrote: > From: YOSHIFUJI Hideaki > Date: Thu, 24 Aug 2006 00:02:37 +0900 > >> XFRM_MSG_REPORT is a message as notification of state protocol and selector >> from kernel to user-space. >> Mobile IPv6 will use it when inbound reject is occurred at route optimization >> to make user-space know a binding error requirement. >> Based on MIPL2 kernel patch. >> >> Signed-off-by: Masahide NAKAMURA >> Signed-off-by: YOSHIFUJI Hideaki > > Applied to net-2.6.19, but... > > Please check whether this XFRM_MSG_REPORT functionality can be > provided via XFRM_MSG_*AE. It seems to me that AEVENTS can be > used to report these rejection situations too. But you might > have a good reason why not do merge the functionality. > > Just let me know. Thank you for pointing it. Now I've checked AEVENT briefly and I feel it is a smarter design to implement this rejection on AEVENT. However it would make us have more lines than XFRM_MSG_REPORT. AEVENT is designed to manage for each existing XFRM state. OTOH XFRM_MSG_REPORT's requirement is to manage unexpected packet then no matching state is there. We would need to add such code as "XFRM state generated by kernel for REPORT" like ACQUIRE to use AEVENT. It might make us define one more status XFRM_STATE_XXX (or adding xfrm_state.km.XXX used with XFRM_STATE_ACQ), too. It is good that AEVENT has a reducing mechanism for message passing between kernel and user-space in receiving packet. For REPORT purpose, we would need to modify to specify thresh e.g. dividing sysctl per XFRM protocol (i.e. ESP, AH, IPComp and DSTOPTS) to specify REPORT state. Should I start to design it? -- Masahide NAKAMURA