From: Vlad Yasevich <vyasevich@gmail.com> To: Geir Ola Vaagland <geirola@gmail.com>, netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org Subject: Re: [PATCH net-next 2/6] Support for SCTP_RCVINFO ancillary data Date: Tue, 17 Jun 2014 10:07:42 -0400 [thread overview] Message-ID: <53A04BAE.8090709@gmail.com> (raw) In-Reply-To: <1403006273-27859-3-git-send-email-geirola@gmail.com> On 06/17/2014 07:57 AM, Geir Ola Vaagland wrote: > CC: Vlad Yasevich <vyasevich@gmail.com> > Signed-off-by: Geir Ola Vaagland <geirola@gmail.com> > --- > include/net/sctp/ulpevent.h | 2 + > include/uapi/linux/sctp.h | 23 ++++++++++++ > net/sctp/socket.c | 6 +++ > net/sctp/ulpevent.c | 91 +++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 122 insertions(+) > > diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h > index 27b9f5c..2f42831 100644 > --- a/include/net/sctp/ulpevent.h > +++ b/include/net/sctp/ulpevent.h > @@ -131,6 +131,8 @@ struct sctp_ulpevent *sctp_ulpevent_make_sender_dry_event( > > void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, > struct msghdr *); > +void sctp_ulpevent_read_rcvinfo(const struct sctp_ulpevent *event, > + struct msghdr *); Gah... This whole file doesn't conform to coding style. :( Please make this change conform to style standards, and we can clean up the file later. > __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event); > > /* Is this event type enabled? */ > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h > index a7db3b3..7e8736b 100644 > --- a/include/uapi/linux/sctp.h > +++ b/include/uapi/linux/sctp.h > @@ -158,6 +158,27 @@ struct sctp_sndrcvinfo { > }; > > /* > + * 5.3.5 SCTP Receive Information Structure (SCTP_RCVINFO) > + * > + * This cmsghdr structure specifies SCTP options for sendmsg(). > + * > + * cmsg_level cmsg_type cmsg_data[] > + * ------------ ------------ ------------------- > + * IPPROTO_SCTP SCTP_RCVINFO struct sctp_rcvinfo > + * > + */ > +struct sctp_rcvinfo { > + __u16 rcv_sid; > + __u16 rcv_ssn; > + __u16 rcv_flags; > + __u32 rcv_ppid; > + __u32 rcv_tsn; > + __u32 rcv_cumtsn; > + __u32 rcv_context; > + sctp_assoc_t rcv_assoc_id; > +}; > + > +/* > * sinfo_flags: 16 bits (unsigned integer) > * > * This field may contain any of the following flags and is composed of > @@ -184,6 +205,8 @@ typedef enum sctp_cmsg_type { > #define SCTP_INIT SCTP_INIT > SCTP_SNDRCV, /* 5.2.2 SCTP Header Information Structure */ > #define SCTP_SNDRCV SCTP_SNDRCV > + SCTP_RCVINFO, > +#define SCTP_RCVINFO SCTP_RCVINFO > } sctp_cmsg_t; > > /* > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > index 1f3281b..aee161b 100644 > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -2094,6 +2094,12 @@ static int sctp_recvmsg(struct kiocb *iocb, struct sock *sk, > sp->pf->skb_msgname(skb, msg->msg_name, addr_len); > } > > + > + /* Check if SCTP_RCVINFO should be included */ > + if(sp->recvrcvinfo){ > + sctp_ulpevent_read_rcvinfo(event, msg); > + } > + > /* Check if we allow SCTP_SNDRCVINFO. */ > if (sp->subscribe.sctp_data_io_event) > sctp_ulpevent_read_sndrcvinfo(event, msg); > diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c > index 81089ed..d1b9a02 100644 > --- a/net/sctp/ulpevent.c > +++ b/net/sctp/ulpevent.c > @@ -900,6 +900,97 @@ __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event) > return notification->sn_header.sn_type; > } > > +void sctp_ulpevent_read_rcvinfo(const struct sctp_ulpevent *event, > + struct msghdr *msghdr) > +{ > + struct sctp_rcvinfo rinfo; > + > + if (sctp_ulpevent_is_notification(event)){ > + return; > + } > + As David Laight mentioned, the spec defines sctp_rcvinfo with a hole in it. To prevent passing kernel stack data to user space, you need to zero-out the data first. -vlad > + /* Sockets API Extensions for SCTP > + * Section 5.3.5 SCTP Receive Information Structure (SCTP_SNDRCV) > + * > + * rcv_sid: 16 bits (unsigned integer) > + * > + * The SCTP stack places the message's stream number in this > + * value. > + */ > + rinfo.rcv_sid = event->stream; > + > + /* rcv_ssn: 16 bits (unsigned integer) > + * This value contains the stream sequence number that the > + * remote endpoint placed in the DATA chunk. For fragmented > + * messages, this is the same number for all deliveries of the > + * message (if more than one recvmsg() is needed to read > + * the message) > + */ > + rinfo.rcv_ssn = event->ssn; > + > + > + /* rcv_ppid: 32 bits (unsigned integer) > + * > + * This value is the same information that was passed by the > + * upper layer in the peer application. Please note that the SCTP > + * stack performs no byte order modification of this field. > + * For example, if the DATA chunk has to contain a given > + * value in network byte order, the SCTP user has to perform the > + * ntohl() computation. > + */ > + rinfo.rcv_ppid = event->ppid; > + > + /* rcv_flags: 16 bits (unsigned integer) > + * > + * This field may contain any of the following flags and is composed of > + * a bitwise OR of these values. > + * > + * recvmsg() flags: > + * > + * SCTP_UNORDERED - This flag is present when the message was sent > + * non-ordered. > + */ > + > + rinfo.rcv_flags = event->flags; > + > + /* rcv_tsn: 32 bits (unsigned integer) > + * > + * This field holds a TSN that was assigned to one of the SCTP > + * DATA chunks. > + */ > + rinfo.rcv_tsn = event->tsn; > + > + /* rcv_cumtsn: 32 bits (unsigned integer) > + * > + * This field will hold the current cumulative TSN as known > + * by the underlying SCTP layer. > + */ > + rinfo.rcv_cumtsn = event->cumtsn; > + > + /* rcv_assoc_id: sizeof (sctp_assoc_t) > + * > + * The association handle field, sinfo_assoc_id, holds the identifier > + * for the association announced in the COMMUNICATION_UP notification. > + * All notifications for a given association have the same identifier. > + * Ignored for one-to-one style sockets. > + */ > + rinfo.rcv_assoc_id = sctp_assoc2id(event->asoc); > + > + /* rcv_context: 32 bits (unsigned integer) > + * > + * This value is an opaque 32-bit context datum that was > + * set by the user with the SCTP_CONTEXT socket option. This > + * value is passed back to the upper layer if an error occurs on > + * the send of a message and is retrieved with each undelivered > + * message. > + */ > + rinfo.rcv_context = event->asoc->default_rcv_context; > + > + put_cmsg(msghdr, IPPROTO_SCTP, SCTP_RCVINFO, > + sizeof(struct sctp_rcvinfo), (void *)&rinfo); > +} > + > + > /* Copy out the sndrcvinfo into a msghdr. */ > void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, > struct msghdr *msghdr) >
WARNING: multiple messages have this Message-ID (diff)
From: Vlad Yasevich <vyasevich@gmail.com> To: Geir Ola Vaagland <geirola@gmail.com>, netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org Subject: Re: [PATCH net-next 2/6] Support for SCTP_RCVINFO ancillary data Date: Tue, 17 Jun 2014 14:07:42 +0000 [thread overview] Message-ID: <53A04BAE.8090709@gmail.com> (raw) In-Reply-To: <1403006273-27859-3-git-send-email-geirola@gmail.com> On 06/17/2014 07:57 AM, Geir Ola Vaagland wrote: > CC: Vlad Yasevich <vyasevich@gmail.com> > Signed-off-by: Geir Ola Vaagland <geirola@gmail.com> > --- > include/net/sctp/ulpevent.h | 2 + > include/uapi/linux/sctp.h | 23 ++++++++++++ > net/sctp/socket.c | 6 +++ > net/sctp/ulpevent.c | 91 +++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 122 insertions(+) > > diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h > index 27b9f5c..2f42831 100644 > --- a/include/net/sctp/ulpevent.h > +++ b/include/net/sctp/ulpevent.h > @@ -131,6 +131,8 @@ struct sctp_ulpevent *sctp_ulpevent_make_sender_dry_event( > > void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, > struct msghdr *); > +void sctp_ulpevent_read_rcvinfo(const struct sctp_ulpevent *event, > + struct msghdr *); Gah... This whole file doesn't conform to coding style. :( Please make this change conform to style standards, and we can clean up the file later. > __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event); > > /* Is this event type enabled? */ > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h > index a7db3b3..7e8736b 100644 > --- a/include/uapi/linux/sctp.h > +++ b/include/uapi/linux/sctp.h > @@ -158,6 +158,27 @@ struct sctp_sndrcvinfo { > }; > > /* > + * 5.3.5 SCTP Receive Information Structure (SCTP_RCVINFO) > + * > + * This cmsghdr structure specifies SCTP options for sendmsg(). > + * > + * cmsg_level cmsg_type cmsg_data[] > + * ------------ ------------ ------------------- > + * IPPROTO_SCTP SCTP_RCVINFO struct sctp_rcvinfo > + * > + */ > +struct sctp_rcvinfo { > + __u16 rcv_sid; > + __u16 rcv_ssn; > + __u16 rcv_flags; > + __u32 rcv_ppid; > + __u32 rcv_tsn; > + __u32 rcv_cumtsn; > + __u32 rcv_context; > + sctp_assoc_t rcv_assoc_id; > +}; > + > +/* > * sinfo_flags: 16 bits (unsigned integer) > * > * This field may contain any of the following flags and is composed of > @@ -184,6 +205,8 @@ typedef enum sctp_cmsg_type { > #define SCTP_INIT SCTP_INIT > SCTP_SNDRCV, /* 5.2.2 SCTP Header Information Structure */ > #define SCTP_SNDRCV SCTP_SNDRCV > + SCTP_RCVINFO, > +#define SCTP_RCVINFO SCTP_RCVINFO > } sctp_cmsg_t; > > /* > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > index 1f3281b..aee161b 100644 > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -2094,6 +2094,12 @@ static int sctp_recvmsg(struct kiocb *iocb, struct sock *sk, > sp->pf->skb_msgname(skb, msg->msg_name, addr_len); > } > > + > + /* Check if SCTP_RCVINFO should be included */ > + if(sp->recvrcvinfo){ > + sctp_ulpevent_read_rcvinfo(event, msg); > + } > + > /* Check if we allow SCTP_SNDRCVINFO. */ > if (sp->subscribe.sctp_data_io_event) > sctp_ulpevent_read_sndrcvinfo(event, msg); > diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c > index 81089ed..d1b9a02 100644 > --- a/net/sctp/ulpevent.c > +++ b/net/sctp/ulpevent.c > @@ -900,6 +900,97 @@ __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event) > return notification->sn_header.sn_type; > } > > +void sctp_ulpevent_read_rcvinfo(const struct sctp_ulpevent *event, > + struct msghdr *msghdr) > +{ > + struct sctp_rcvinfo rinfo; > + > + if (sctp_ulpevent_is_notification(event)){ > + return; > + } > + As David Laight mentioned, the spec defines sctp_rcvinfo with a hole in it. To prevent passing kernel stack data to user space, you need to zero-out the data first. -vlad > + /* Sockets API Extensions for SCTP > + * Section 5.3.5 SCTP Receive Information Structure (SCTP_SNDRCV) > + * > + * rcv_sid: 16 bits (unsigned integer) > + * > + * The SCTP stack places the message's stream number in this > + * value. > + */ > + rinfo.rcv_sid = event->stream; > + > + /* rcv_ssn: 16 bits (unsigned integer) > + * This value contains the stream sequence number that the > + * remote endpoint placed in the DATA chunk. For fragmented > + * messages, this is the same number for all deliveries of the > + * message (if more than one recvmsg() is needed to read > + * the message) > + */ > + rinfo.rcv_ssn = event->ssn; > + > + > + /* rcv_ppid: 32 bits (unsigned integer) > + * > + * This value is the same information that was passed by the > + * upper layer in the peer application. Please note that the SCTP > + * stack performs no byte order modification of this field. > + * For example, if the DATA chunk has to contain a given > + * value in network byte order, the SCTP user has to perform the > + * ntohl() computation. > + */ > + rinfo.rcv_ppid = event->ppid; > + > + /* rcv_flags: 16 bits (unsigned integer) > + * > + * This field may contain any of the following flags and is composed of > + * a bitwise OR of these values. > + * > + * recvmsg() flags: > + * > + * SCTP_UNORDERED - This flag is present when the message was sent > + * non-ordered. > + */ > + > + rinfo.rcv_flags = event->flags; > + > + /* rcv_tsn: 32 bits (unsigned integer) > + * > + * This field holds a TSN that was assigned to one of the SCTP > + * DATA chunks. > + */ > + rinfo.rcv_tsn = event->tsn; > + > + /* rcv_cumtsn: 32 bits (unsigned integer) > + * > + * This field will hold the current cumulative TSN as known > + * by the underlying SCTP layer. > + */ > + rinfo.rcv_cumtsn = event->cumtsn; > + > + /* rcv_assoc_id: sizeof (sctp_assoc_t) > + * > + * The association handle field, sinfo_assoc_id, holds the identifier > + * for the association announced in the COMMUNICATION_UP notification. > + * All notifications for a given association have the same identifier. > + * Ignored for one-to-one style sockets. > + */ > + rinfo.rcv_assoc_id = sctp_assoc2id(event->asoc); > + > + /* rcv_context: 32 bits (unsigned integer) > + * > + * This value is an opaque 32-bit context datum that was > + * set by the user with the SCTP_CONTEXT socket option. This > + * value is passed back to the upper layer if an error occurs on > + * the send of a message and is retrieved with each undelivered > + * message. > + */ > + rinfo.rcv_context = event->asoc->default_rcv_context; > + > + put_cmsg(msghdr, IPPROTO_SCTP, SCTP_RCVINFO, > + sizeof(struct sctp_rcvinfo), (void *)&rinfo); > +} > + > + > /* Copy out the sndrcvinfo into a msghdr. */ > void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, > struct msghdr *msghdr) >
next prev parent reply other threads:[~2014-06-17 14:07 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-17 11:57 [PATCH net-next 0/6] A step closer to RFC 6458 compliancy Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 11:57 ` [PATCH net-next 1/6] Support for SCTP_RECVRCVINFO socket option Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 12:35 ` David Laight 2014-06-17 12:35 ` David Laight 2014-06-17 13:57 ` Vlad Yasevich 2014-06-17 13:57 ` Vlad Yasevich 2014-06-17 11:57 ` [PATCH net-next 2/6] Support for SCTP_RCVINFO ancillary data Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 12:36 ` David Laight 2014-06-17 14:07 ` Vlad Yasevich [this message] 2014-06-17 14:07 ` Vlad Yasevich 2014-06-17 11:57 ` [PATCH net-next 3/6] Support for SCTP_SNDINFO " Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 12:38 ` David Laight 2014-06-17 14:29 ` Vlad Yasevich 2014-06-17 14:29 ` Vlad Yasevich 2014-06-17 14:42 ` David Laight 2014-06-17 11:57 ` [PATCH net-next 4/6] Support for SCTP_NXTINFO socket option Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 11:57 ` [PATCH net-next 5/6] Support for receiving SCTP_NXTINFO ancillary data Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 11:57 ` [PATCH net-next 6/6] Support for SCTP_DEFAULT_SNDINFO socket option Geir Ola Vaagland 2014-06-17 11:57 ` Geir Ola Vaagland 2014-06-17 12:32 ` [PATCH net-next 0/6] A step closer to RFC 6458 compliancy David Laight 2014-06-17 13:40 ` Vlad Yasevich 2014-06-17 13:40 ` Vlad Yasevich 2014-06-17 15:01 Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-17 15:01 ` [PATCH net-next 1/6] Support for SCTP_RECVRCVINFO socket option Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-18 23:30 ` David Miller 2014-06-18 23:30 ` David Miller 2014-06-17 15:01 ` [PATCH net-next 2/6] Support for SCTP_RCVINFO ancillary data Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-18 23:30 ` David Miller 2014-06-18 23:30 ` David Miller 2014-06-17 15:01 ` [PATCH net-next 3/6] Support for SCTP_SNDINFO " Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-17 15:01 ` [PATCH net-next 4/6] Support for SCTP_NXTINFO socket option Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-17 15:01 ` [PATCH net-next 5/6] Support for receiving SCTP_NXTINFO ancillary data Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-17 15:01 ` [PATCH net-next 6/6] Support for SCTP_DEFAULT_SNDINFO socket option Geir Ola Vaagland 2014-06-17 15:01 ` Geir Ola Vaagland 2014-06-18 23:33 ` David Miller 2014-06-18 23:33 ` David Miller 2014-06-17 15:14 ` [PATCH net-next 0/6] A step closer to RFC 6458 compliancy David Laight 2014-06-17 15:36 ` David Laight 2014-06-17 18:42 ` Vlad Yasevich 2014-06-17 18:42 ` Vlad Yasevich 2014-06-18 8:42 ` David Laight 2014-06-18 12:43 ` Michael Tuexen 2014-06-18 12:43 ` Michael Tuexen 2014-06-18 13:16 ` David Laight 2014-06-18 13:24 ` Michael Tuexen 2014-06-18 13:24 ` Michael Tuexen 2014-06-18 13:25 ` Vlad Yasevich 2014-06-18 13:25 ` Vlad Yasevich 2014-06-18 13:29 ` Michael Tuexen 2014-06-18 13:29 ` Michael Tuexen 2014-06-18 13:53 ` David Laight
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=53A04BAE.8090709@gmail.com \ --to=vyasevich@gmail.com \ --cc=geirola@gmail.com \ --cc=linux-sctp@vger.kernel.org \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.