Hi Xin, On Thu, Apr 14, 2016 at 09:35 AM CEST, Xin Long <lucien.xin@xxxxxxxxx> wrote: > This one will implement all the interface of inet_diag, inet_diag_handler. > which includes sctp_diag_dump, sctp_diag_dump_one and sctp_diag_get_info. > > It will work as a module, and register inet_diag_handler when loading. > > v2->v3: > - fix the mistake in inet_assoc_attr_size(). > > - change inet_diag_msg_laddrs_fill() name to inet_diag_msg_sctpladdrs_fill. > > - change inet_diag_msg_paddrs_fill() name to inet_diag_msg_sctpaddrs_fill. > > - add inet_diag_msg_sctpinfo_fill() to make asoc/ep fill code clearer. > > - add inet_diag_msg_sctpasoc_fill() to make asoc fill code clearer. > > - merge inet_asoc_diag_fill() and inet_ep_diag_fill() to > inet_sctp_diag_fill(). > > - call sctp_diag_get_info() directly, instead by handler, cause the caller > is in the same file with it. > > - call lock_sock in sctp_tsp_dump_one() to make sure we call get sctp info > safely. > > - after lock_sock(sk), we should check sk != assoc->base.sk. > > - change mem[SK_MEMINFO_WMEM_ALLOC] to asoc->sndbuf_used for asoc dump when > asoc->ep->sndbuf_policy is set. don't use INET_DIAG_MEMINFO attr any more. > > Signed-off-by: Xin Long <lucien.xin@xxxxxxxxx> > --- [...] > diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c > new file mode 100644 > index 0000000..98ecd16 > --- /dev/null > +++ b/net/sctp/sctp_diag.c > @@ -0,0 +1,497 @@ [...] > +#define EXPIRES_IN_MS(tmo) DIV_ROUND_UP((tmo - jiffies) * 1000, HZ) > + r->idiag_expires = > + EXPIRES_IN_MS(asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX]); > +#undef EXPIRES_IN_MS How about using jiffies_to_msecs() here? It's already being used elsewhere in net/sctp. AFAICT EXPIRES_IN_MS macro comes from net/ipv4/inet_diag.c and dates back to before jiffies_to_msecs() has been introduced. Perhaps that's why it's still used in inet_diag.c. But this is new code. Thanks, Jakub -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html