All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	ccaulfie@redhat.com, Helge Deller <deller@gmx.de>,
	Paul Mackerras <paulus@samba.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@twiddle.net>,
	cluster-devel <cluster-devel@redhat.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-alpha@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-mips@vger.kernel.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>
Subject: Re: [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes
Date: Tue, 8 Jan 2019 13:19:05 -0800	[thread overview]
Message-ID: <CABeXuvptd3G0kZ7K7j78cSGOnxBOkCoDe8Tzhfu4BQcYVtJNPg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2T=dWgD1mvi77fbdKEsm=ZUwsQENv-btjhECjf+Y5wcg@mail.gmail.com>

On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for new socket
> > timeout options with _NEW suffix that are y2038 safe.
> > Rename the existing options with _OLD suffix forms so that the
> > right option is enabled for userspace applications according
> > to the architecture and time_t definition of libc.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
>
> Looks good overall. A few minor concerns:
>
> The description above makes it sound like there is a bug with y2038-safety
> in this particular interface, which I think is just not what you meant,
> as the change is only needed for compatiblity with new C libraries
> that work around the y2038 problem in general by changing their
> timeval definition.

Right, there is y2038 safety issue, just the libc part that needs to be handled.
I will fix the commit text.

> > diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> > index 76976d6e50f9..c98ad9777ad9 100644
> > --- a/fs/dlm/lowcomms.c
> > +++ b/fs/dlm/lowcomms.c
> > @@ -1089,12 +1089,12 @@ static void sctp_connect_to_sock(struct connection *con)
> >          * since O_NONBLOCK argument in connect() function does not work here,
> >          * then, we should restore the default value of this attribute.
> >          */
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >         result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len,
> >                                    0);
> >         memset(&tv, 0, sizeof(tv));
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >
> >         if (result == -EINPROGRESS)
>
> It took me a bit to realize there that this is safe as well even if
> we don't use SO_SNDTIMEO_NEW, for the same reason.

Correct.

> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -378,7 +378,7 @@ static int compat_sock_setsockopt(struct socket *sock, int level, int optname,
> >                 return do_set_attach_filter(sock, level, optname,
> >                                             optval, optlen);
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_set_sock_timeout(sock, level, optname, optval, optlen);
> >
> >         return sock_setsockopt(sock, level, optname, optval, optlen);
> > @@ -450,7 +450,7 @@ static int compat_sock_getsockopt(struct socket *sock, int level, int optname,
> >                                 char __user *optval, int __user *optlen)
> >  {
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_get_sock_timeout(sock, level, optname, optval, optlen);
> >         return sock_getsockopt(sock, level, optname, optval, optlen);
> >  }
>
> I looked at the original code and noticed that it's horrible, which of course
> is not your fault, but I wonder if we should just fix it now to avoid that
> get_fs()/set_fs() hack, since that code mostly implements what you
> also have in your patch 3 (which is done more nicely).

I did think of getting rid of set_fs()/ get_fs() here.
But, I wasn't sure as the maintainers seemed to prefer to leave to the
old code as is in the other series for timestamps.

> I'll follow up with a patch to demonstrate what I mean here. Your third
> patch will then just have to add another code path so we can handle
> all of old_timespec32 (for existing 32-bit user space), __kernel_old_timespec
> (for sparc64) and __kernel_sock_timeval (for everything else).

Cool, I will rebase on top of your patch.

Thanks,
Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	ccaulfie@redhat.com, Helge Deller <deller@gmx.de>,
	Paul Mackerras <paulus@samba.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Richard Henderson <rth@twiddle.net>,
	cluster-devel <cluster-devel@redhat.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-alpha@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-mips@vger.kernel.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>
Subject: Re: [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes
Date: Tue, 08 Jan 2019 21:19:05 +0000	[thread overview]
Message-ID: <CABeXuvptd3G0kZ7K7j78cSGOnxBOkCoDe8Tzhfu4BQcYVtJNPg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2T=dWgD1mvi77fbdKEsm=ZUwsQENv-btjhECjf+Y5wcg@mail.gmail.com>

On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for new socket
> > timeout options with _NEW suffix that are y2038 safe.
> > Rename the existing options with _OLD suffix forms so that the
> > right option is enabled for userspace applications according
> > to the architecture and time_t definition of libc.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
>
> Looks good overall. A few minor concerns:
>
> The description above makes it sound like there is a bug with y2038-safety
> in this particular interface, which I think is just not what you meant,
> as the change is only needed for compatiblity with new C libraries
> that work around the y2038 problem in general by changing their
> timeval definition.

Right, there is y2038 safety issue, just the libc part that needs to be handled.
I will fix the commit text.

> > diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> > index 76976d6e50f9..c98ad9777ad9 100644
> > --- a/fs/dlm/lowcomms.c
> > +++ b/fs/dlm/lowcomms.c
> > @@ -1089,12 +1089,12 @@ static void sctp_connect_to_sock(struct connection *con)
> >          * since O_NONBLOCK argument in connect() function does not work here,
> >          * then, we should restore the default value of this attribute.
> >          */
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >         result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len,
> >                                    0);
> >         memset(&tv, 0, sizeof(tv));
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >
> >         if (result = -EINPROGRESS)
>
> It took me a bit to realize there that this is safe as well even if
> we don't use SO_SNDTIMEO_NEW, for the same reason.

Correct.

> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -378,7 +378,7 @@ static int compat_sock_setsockopt(struct socket *sock, int level, int optname,
> >                 return do_set_attach_filter(sock, level, optname,
> >                                             optval, optlen);
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname = SO_RCVTIMEO || optname = SO_SNDTIMEO))
> > +           (optname = SO_RCVTIMEO_OLD || optname = SO_SNDTIMEO_OLD))
> >                 return do_set_sock_timeout(sock, level, optname, optval, optlen);
> >
> >         return sock_setsockopt(sock, level, optname, optval, optlen);
> > @@ -450,7 +450,7 @@ static int compat_sock_getsockopt(struct socket *sock, int level, int optname,
> >                                 char __user *optval, int __user *optlen)
> >  {
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname = SO_RCVTIMEO || optname = SO_SNDTIMEO))
> > +           (optname = SO_RCVTIMEO_OLD || optname = SO_SNDTIMEO_OLD))
> >                 return do_get_sock_timeout(sock, level, optname, optval, optlen);
> >         return sock_getsockopt(sock, level, optname, optval, optlen);
> >  }
>
> I looked at the original code and noticed that it's horrible, which of course
> is not your fault, but I wonder if we should just fix it now to avoid that
> get_fs()/set_fs() hack, since that code mostly implements what you
> also have in your patch 3 (which is done more nicely).

I did think of getting rid of set_fs()/ get_fs() here.
But, I wasn't sure as the maintainers seemed to prefer to leave to the
old code as is in the other series for timestamps.

> I'll follow up with a patch to demonstrate what I mean here. Your third
> patch will then just have to add another code path so we can handle
> all of old_timespec32 (for existing 32-bit user space), __kernel_old_timespec
> (for sparc64) and __kernel_sock_timeval (for everything else).

Cool, I will rebase on top of your patch.

Thanks,
Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Networking <netdev@vger.kernel.org>, Helge Deller <deller@gmx.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@vger.kernel.org,
	cluster-devel <cluster-devel@redhat.com>,
	ccaulfie@redhat.com, Paul Mackerras <paulus@samba.org>,
	linux-alpha@vger.kernel.org,
	sparclinux <sparclinux@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	David Miller <davem@davemloft.net>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes
Date: Tue, 8 Jan 2019 13:19:05 -0800	[thread overview]
Message-ID: <CABeXuvptd3G0kZ7K7j78cSGOnxBOkCoDe8Tzhfu4BQcYVtJNPg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2T=dWgD1mvi77fbdKEsm=ZUwsQENv-btjhECjf+Y5wcg@mail.gmail.com>

On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for new socket
> > timeout options with _NEW suffix that are y2038 safe.
> > Rename the existing options with _OLD suffix forms so that the
> > right option is enabled for userspace applications according
> > to the architecture and time_t definition of libc.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
>
> Looks good overall. A few minor concerns:
>
> The description above makes it sound like there is a bug with y2038-safety
> in this particular interface, which I think is just not what you meant,
> as the change is only needed for compatiblity with new C libraries
> that work around the y2038 problem in general by changing their
> timeval definition.

Right, there is y2038 safety issue, just the libc part that needs to be handled.
I will fix the commit text.

> > diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> > index 76976d6e50f9..c98ad9777ad9 100644
> > --- a/fs/dlm/lowcomms.c
> > +++ b/fs/dlm/lowcomms.c
> > @@ -1089,12 +1089,12 @@ static void sctp_connect_to_sock(struct connection *con)
> >          * since O_NONBLOCK argument in connect() function does not work here,
> >          * then, we should restore the default value of this attribute.
> >          */
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >         result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len,
> >                                    0);
> >         memset(&tv, 0, sizeof(tv));
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >
> >         if (result == -EINPROGRESS)
>
> It took me a bit to realize there that this is safe as well even if
> we don't use SO_SNDTIMEO_NEW, for the same reason.

Correct.

> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -378,7 +378,7 @@ static int compat_sock_setsockopt(struct socket *sock, int level, int optname,
> >                 return do_set_attach_filter(sock, level, optname,
> >                                             optval, optlen);
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_set_sock_timeout(sock, level, optname, optval, optlen);
> >
> >         return sock_setsockopt(sock, level, optname, optval, optlen);
> > @@ -450,7 +450,7 @@ static int compat_sock_getsockopt(struct socket *sock, int level, int optname,
> >                                 char __user *optval, int __user *optlen)
> >  {
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_get_sock_timeout(sock, level, optname, optval, optlen);
> >         return sock_getsockopt(sock, level, optname, optval, optlen);
> >  }
>
> I looked at the original code and noticed that it's horrible, which of course
> is not your fault, but I wonder if we should just fix it now to avoid that
> get_fs()/set_fs() hack, since that code mostly implements what you
> also have in your patch 3 (which is done more nicely).

I did think of getting rid of set_fs()/ get_fs() here.
But, I wasn't sure as the maintainers seemed to prefer to leave to the
old code as is in the other series for timestamps.

> I'll follow up with a patch to demonstrate what I mean here. Your third
> patch will then just have to add another code path so we can handle
> all of old_timespec32 (for existing 32-bit user space), __kernel_old_timespec
> (for sparc64) and __kernel_sock_timeval (for everything else).

Cool, I will rebase on top of your patch.

Thanks,
Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes
Date: Tue, 8 Jan 2019 13:19:05 -0800	[thread overview]
Message-ID: <CABeXuvptd3G0kZ7K7j78cSGOnxBOkCoDe8Tzhfu4BQcYVtJNPg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2T=dWgD1mvi77fbdKEsm=ZUwsQENv-btjhECjf+Y5wcg@mail.gmail.com>

On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for new socket
> > timeout options with _NEW suffix that are y2038 safe.
> > Rename the existing options with _OLD suffix forms so that the
> > right option is enabled for userspace applications according
> > to the architecture and time_t definition of libc.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
>
> Looks good overall. A few minor concerns:
>
> The description above makes it sound like there is a bug with y2038-safety
> in this particular interface, which I think is just not what you meant,
> as the change is only needed for compatiblity with new C libraries
> that work around the y2038 problem in general by changing their
> timeval definition.

Right, there is y2038 safety issue, just the libc part that needs to be handled.
I will fix the commit text.

> > diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> > index 76976d6e50f9..c98ad9777ad9 100644
> > --- a/fs/dlm/lowcomms.c
> > +++ b/fs/dlm/lowcomms.c
> > @@ -1089,12 +1089,12 @@ static void sctp_connect_to_sock(struct connection *con)
> >          * since O_NONBLOCK argument in connect() function does not work here,
> >          * then, we should restore the default value of this attribute.
> >          */
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >         result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len,
> >                                    0);
> >         memset(&tv, 0, sizeof(tv));
> > -       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv,
> > +       kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *)&tv,
> >                           sizeof(tv));
> >
> >         if (result == -EINPROGRESS)
>
> It took me a bit to realize there that this is safe as well even if
> we don't use SO_SNDTIMEO_NEW, for the same reason.

Correct.

> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -378,7 +378,7 @@ static int compat_sock_setsockopt(struct socket *sock, int level, int optname,
> >                 return do_set_attach_filter(sock, level, optname,
> >                                             optval, optlen);
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_set_sock_timeout(sock, level, optname, optval, optlen);
> >
> >         return sock_setsockopt(sock, level, optname, optval, optlen);
> > @@ -450,7 +450,7 @@ static int compat_sock_getsockopt(struct socket *sock, int level, int optname,
> >                                 char __user *optval, int __user *optlen)
> >  {
> >         if (!COMPAT_USE_64BIT_TIME &&
> > -           (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> > +           (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> >                 return do_get_sock_timeout(sock, level, optname, optval, optlen);
> >         return sock_getsockopt(sock, level, optname, optval, optlen);
> >  }
>
> I looked at the original code and noticed that it's horrible, which of course
> is not your fault, but I wonder if we should just fix it now to avoid that
> get_fs()/set_fs() hack, since that code mostly implements what you
> also have in your patch 3 (which is done more nicely).

I did think of getting rid of set_fs()/ get_fs() here.
But, I wasn't sure as the maintainers seemed to prefer to leave to the
old code as is in the other series for timestamps.

> I'll follow up with a patch to demonstrate what I mean here. Your third
> patch will then just have to add another code path so we can handle
> all of old_timespec32 (for existing 32-bit user space), __kernel_old_timespec
> (for sparc64) and __kernel_sock_timeval (for everything else).

Cool, I will rebase on top of your patch.

Thanks,
Deepa



  parent reply	other threads:[~2019-01-08 21:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-08  5:22 [PATCH 0/3] net: y2038-safe socket timeout options Deepa Dinamani
2019-01-08  5:22 ` [Cluster-devel] " Deepa Dinamani
2019-01-08  5:22 ` Deepa Dinamani
2019-01-08  5:22 ` Deepa Dinamani
2019-01-08  5:22 ` [PATCH 1/3] socket: Use old_timeval types for socket timeouts Deepa Dinamani
2019-01-08  5:22 ` [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes Deepa Dinamani
2019-01-08  5:22   ` [Cluster-devel] " Deepa Dinamani
2019-01-08  5:22   ` Deepa Dinamani
2019-01-08  5:22   ` Deepa Dinamani
2019-01-08 20:03   ` Arnd Bergmann
2019-01-08 20:03     ` [Cluster-devel] " Arnd Bergmann
2019-01-08 20:03     ` Arnd Bergmann
2019-01-08 20:03     ` Arnd Bergmann
2019-01-08 20:09     ` [PATCH] socket: move compat timeout handling into sock.c Arnd Bergmann
2019-01-08 20:09       ` [Cluster-devel] " Arnd Bergmann
2019-01-08 20:09       ` Arnd Bergmann
2019-01-08 20:09       ` Arnd Bergmann
2019-01-08 20:09       ` Arnd Bergmann
2019-01-08 21:29       ` Deepa Dinamani
2019-01-08 21:29         ` [Cluster-devel] " Deepa Dinamani
2019-01-08 21:29         ` Deepa Dinamani
2019-01-08 21:29         ` Deepa Dinamani
2019-01-08 21:19     ` Deepa Dinamani [this message]
2019-01-08 21:19       ` [Cluster-devel] [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes Deepa Dinamani
2019-01-08 21:19       ` Deepa Dinamani
2019-01-08 21:19       ` Deepa Dinamani
2019-01-08  5:22 ` [PATCH 3/3] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW Deepa Dinamani
2019-01-08  5:22   ` [Cluster-devel] " Deepa Dinamani
2019-01-08  5:22   ` Deepa Dinamani
2019-01-08  5:22   ` Deepa Dinamani

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=CABeXuvptd3G0kZ7K7j78cSGOnxBOkCoDe8Tzhfu4BQcYVtJNPg@mail.gmail.com \
    --to=deepa.kernel@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ccaulfie@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=rth@twiddle.net \
    --cc=sparclinux@vger.kernel.org \
    --cc=y2038@lists.linaro.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: link
Be 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.