David Miller wrote:

From: YOSHIFUJI Hideaki <redacted>
Date: Thu, 24 Aug 2006 00:02:37 +0900

quoted

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 <redacted>
Signed-off-by: YOSHIFUJI Hideaki <redacted>

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