Strictly speaking, these patches streamline the code at both
compile-time and run-time, and seem to face no technical
objection of note.
The strongest objection was a dubious *potential* refactoring of
similar code, a refactoring which is clearly vaporware, and which
I myself would have tried to complete if only this initial foray
had been applied.
If this is considered "new" code (it isn't) and if this email is
received outside of an appropriate merge window, then save this
email for later consideration---this isn't a real-time conversation;
this is email, so it doesn't matter when you receive it.
Sincerely,
Michael Witten
On Sun, 01 Oct 2017 22:19:02 -0000, Michael Witten wrote:
> The following patch series is an ad hoc "cleanup" that I made
> while perusing the code (I'm not well versed in this code, so I
> would not be surprised if there were objections to the changes):
>
> [1] net: __sock_cmsg_send(): Remove unused parameter `msg'
> [2] net: inet_recvmsg(): Remove unnecessary bitwise operation
> [3] net: skb_queue_purge(): lock/unlock the queue only once
>
> Each patch will be sent as an individual reply to this email;
> the total diff is appended below for your convenience.
>
> You may also fetch these patches from GitHub:
>
> git checkout --detach 5969d1bb3082b41eba8fd2c826559abe38ccb6df
> git pull https://github.com/mfwitten/linux.git net/tcp-ip/01-cleanup/02
>
> Overall:
>
> include/net/sock.h | 2 +-
> net/core/skbuff.c | 26 ++++++++++++++++++--------
> net/core/sock.c | 4 ++--
> net/ipv4/af_inet.c | 2 +-
> net/ipv4/ip_sockglue.c | 2 +-
> net/ipv6/datagram.c | 2 +-
> 6 files changed, 24 insertions(+), 14 deletions(-)
>
> Sincerly,
> Michael Witten
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 03a362568357..83373d7148a9 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1562,7 +1562,7 @@ struct sockcm_cookie {
> u16 tsflags;
> };
>
> -int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
> +int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
> struct sockcm_cookie *sockc);
> int sock_cmsg_send(struct sock *sk, struct msghdr *msg,
> struct sockcm_cookie *sockc);
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 9b7b6bbb2a23..425e03fe1c56 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2091,7 +2091,7 @@ struct sk_buff *sock_alloc_send_skb(struct sock *sk, unsigned long size,
> }
> EXPORT_SYMBOL(sock_alloc_send_skb);
>
> -int __sock_cmsg_send(struct sock *sk, struct msghdr *msg, struct cmsghdr *cmsg,
> +int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
> struct sockcm_cookie *sockc)
> {
> u32 tsflags;
> @@ -2137,7 +2137,7 @@ int sock_cmsg_send(struct sock *sk, struct msghdr *msg,
> return -EINVAL;
> if (cmsg->cmsg_level != SOL_SOCKET)
> continue;
> - ret = __sock_cmsg_send(sk, msg, cmsg, sockc);
> + ret = __sock_cmsg_send(sk, cmsg, sockc);
> if (ret)
> return ret;
> }
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index e558e4f9597b..c79b7822b0b9 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -263,7 +263,7 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
> }
> #endif
> if (cmsg->cmsg_level == SOL_SOCKET) {
> - err = __sock_cmsg_send(sk, msg, cmsg, &ipc->sockc);
> + err = __sock_cmsg_send(sk, cmsg, &ipc->sockc);
> if (err)
> return err;
> continue;
> diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
> index a1f918713006..1d1926a4cbe2 100644
> --- a/net/ipv6/datagram.c
> +++ b/net/ipv6/datagram.c
> @@ -756,7 +756,7 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
> }
>
> if (cmsg->cmsg_level == SOL_SOCKET) {
> - err = __sock_cmsg_send(sk, msg, cmsg, sockc);
> + err = __sock_cmsg_send(sk, cmsg, sockc);
> if (err)
> return err;
> continue;
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index e31108e5ef79..2dbed042a412 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -791,7 +791,7 @@ int inet_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
> sock_rps_record_flow(sk);
>
> err = sk->sk_prot->recvmsg(sk, msg, size, flags & MSG_DONTWAIT,
> - flags & ~MSG_DONTWAIT, &addr_len);
> + flags, &addr_len);
> if (err >= 0)
> msg->msg_namelen = addr_len;
> return err;
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 68065d7d383f..bd26b0bde784 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2825,18 +2825,28 @@
> EXPORT_SYMBOL(skb_dequeue_tail);
>
> /**
> - * skb_queue_purge - empty a list
> - * @list: list to empty
> + * skb_queue_purge - empty a queue
> + * @q: the queue to empty
> *
> - * Delete all buffers on an &sk_buff list. Each buffer is removed from
> - * the list and one reference dropped. This function takes the list
> - * lock and is atomic with respect to other list locking functions.
> + * Dequeue and free each socket buffer that is in @q.
> + *
> + * This function is atomic with respect to other queue-locking functions.
> */
> -void skb_queue_purge(struct sk_buff_head *list)
> +void skb_queue_purge(struct sk_buff_head *q)
> {
> - struct sk_buff *skb;
> - while ((skb = skb_dequeue(list)) != NULL)
> + unsigned long flags;
> + struct sk_buff *skb, *next, *head = (struct sk_buff *)q;
> +
> + spin_lock_irqsave(&q->lock, flags);
> + skb = q->next;
> + __skb_queue_head_init(q);
> + spin_unlock_irqrestore(&q->lock, flags);
> +
> + while (skb != head) {
> + next = skb->next;
> kfree_skb(skb);
> + skb = next;
> + }
> }
> EXPORT_SYMBOL(skb_queue_purge);
>
> --
> 2.14.1
>
From: Michael Witten <[email protected]>
Date: Tue, 06 Feb 2018 00:54:35 -0000
> If this is considered "new" code (it isn't) and if this email is
> received outside of an appropriate merge window, then save this
> email for later consideration---this isn't a real-time conversation;
> this is email, so it doesn't matter when you receive it.
Sorry, things don't work that way.
You must submit your changes at the appropriate time.
Please learn how the community works, and how to interact with
developers and maintainers in that community appropriately.
Thank you.
On Mon, 05 Feb 2018 20:12:11 -0500 (EST), David Miller wrote:
>> If this is considered "new" code (it isn't) and if this email is
>> received outside of an appropriate merge window, then save this
>> email for later consideration---this isn't a real-time conversation;
>> this is email, so it doesn't matter when you receive it.
>
> Sorry, things don't work that way.
>
> You must submit your changes at the appropriate time.
>
> Please learn how the community works, and how to interact with
> developers and maintainers in that community appropriately.
I already tried that.
If you're unwilling to be an effective maintainer, then please hand
off the responsibiilty to someone else.
Sincerely,
Michael Witten
> > Please learn how the community works, and how to interact with
> > developers and maintainers in that community appropriately.
>
> I already tried that.
>
> If you're unwilling to be an effective maintainer, then please hand
> off the responsibiilty to someone else.
Could i suggest you read:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
And in particular, the bit about netdev being closed.
I suggest you wait a week for netdev to open, and then submit the
patches again. Actual patches, which cleanly apply to net-next.
Andrew
On Tue, 6 Feb 2018 02:42:17 +0100, Andrew Lunn wrote:
>>> Please learn how the community works, and how to interact with
>>> developers and maintainers in that community appropriately.
>>
>> I already tried that.
>>
>> If you're unwilling to be an effective maintainer, then please hand
>> off the responsibiilty to someone else.
>
> Could i suggest you read:
>
> https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
>
> And in particular, the bit about netdev being closed.
>
> I suggest you wait a week for netdev to open, and then submit the
> patches again. Actual patches, which cleanly apply to net-next.
Thank you kindly for the suggestion.
However, I'm fully versed on the scripture.
I'm glad to report that the patches apply cleanly to `net-next'; the
actual patches are, of course, still available in my previous emails.
Also, as already described, they can be easily fetched from GitHub.
Sincerely,
Michael Witten
> However, I'm fully versed on the scripture.
>
> I'm glad to report that the patches apply cleanly to `net-next'; the
> actual patches are, of course, still available in my previous emails.
> Also, as already described, they can be easily fetched from GitHub.
>
> Sincerely,
> Michael Witten
Hi Michael
If you were fully versed in the scriptures, you would know none of
these methods for submitting patches are applicable for netdev. Please
follow the process, repost the patches in a weeks time.
Andrew