the code to include , avoiding fragility.
>
> Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
> Cc: Trond Myklebust <trond.mykleb...@primarydata.com>
> Cc: Anna Schumaker <anna.schuma...@netapp.com>
> Cc: J. Bruce Fields <bfie...@fieldses.org>
> C
On Tue, 2017-10-24 at 15:12 -0500, Gustavo A. R. Silva wrote:
> Quoting "J. Bruce Fields" <bfie...@fieldses.org>:
>
> > On Tue, Oct 24, 2017 at 02:18:52PM -0400, Jeff Layton wrote:
> > > On Tue, 2017-10-24 at 13:53 -0400, J. Bruce Fields wrote:
> > &
09,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst
> > > > *rqstp)
> > > > BUG_ON(integ_len % 4);
> > > > *p++ = htonl(integ_len);
> > > > *p++ = htonl(gc->gc_seq);
> > > > - if (xdr_buf_subsegment(resbuf, _buf, integ_o
rpc/auth_gss/svcauth_gss.c | 4 ++--
> net/sunrpc/cache.c| 2 +-
> net/sunrpc/svcauth_unix.c | 4 ++--
> 7 files changed, 11 insertions(+), 11 deletions(-)
>
Looks pretty straightforward. You can add this to the set:
Reviewed-by: Jeff Layton <jlay...@redhat.com>
family,
> + const unsigned short port, int flags)
> {
> struct svc_xprt_class *xcl;
>
Reviewed-by: Jeff Layton <jlay...@poochiereds.net>
c struct kvec empty_iov = {.iov_base = NULL, .iov_len = 0};
> +static const struct kvec empty_iov = {.iov_base = NULL, .iov_len = 0};
>
> void
> xdr_buf_from_iov(struct kvec *iov, struct xdr_buf *buf)
Reviewed-by: Jeff Layton <jlay...@redhat.com>
054 08cd3dbc
> >
> > [ 6709.147653] fec0:
> > 81000689ff20
> > [ 6709.155471] fee0: 08085240 81000689ff20 08085244
> > 6145
> >
rr);
> }
>
> - inet->sk_user_data = svsk;
> svsk->sk_sock = sock;
> svsk->sk_sk = inet;
> svsk->sk_ostate = inet->sk_state_change;
> svsk->sk_odata = inet->sk_data_ready;
> svsk->sk_owspace = inet->sk_write_space;
> + /* this barrier is necessary in order to prevent race condition
> +with svc_data_ready(), svc_listen_data_ready()
> +and others when calling callbacks above */
> + wmb();
> + inet->sk_user_data = svsk;
>
> /* Initialize the socket */
> if (sock->type == SOCK_DGRAM)
Patch itself looks fine -- nice catch!
The comment format probably ought to be in kernel-standard style though.
What I'd probably do is have this longer comment next to the wmb() call
and then have smaller comments by the rmb() calls referring them to the
longer comment in svc_setup_socket().
Once you fix the comments, you can add:
Reviewed-by: Jeff Layton <jlay...@redhat.com>
On Fri, 2017-08-18 at 07:08 -0400, Vadim Lomovtsev wrote:
> Hi Jeff,
>
> On Fri, Aug 18, 2017 at 06:27:32AM -0400, Jeff Layton wrote:
> > On Fri, 2017-08-18 at 06:00 -0400, Vadim Lomovtsev wrote:
> > > While running nfs/connectathon tests kernel NULL-pointer exception
>
svc_xprt_enqueue(>sk_xprt);
> @@ -1381,12 +1392,13 @@ static struct svc_sock *svc_setup_socket(struct
> svc_serv *serv,
> return ERR_PTR(err);
> }
>
> - inet->sk_user_data = svsk;
> svsk->sk_sock = sock;
> svsk->sk_sk = inet;
> svsk->sk_ostate = inet->sk_state_change;
> svsk->sk_odata = inet->sk_data_ready;
> svsk->sk_owspace = inet->sk_write_space;
> + wmb();
> + inet->sk_user_data = svsk;
>
> /* Initialize the socket */
> if (sock->type == SOCK_DGRAM)
Since we always check whether svsk is NULL before calling the functions,
then the above hunk and maybe the rmb() calls might be all that's needed
here. I don't see how we'd ever get a sk_odata value (for instance)
that's NULL with the above change.
--
Jeff Layton <jlay...@redhat.com>
so much the better. Point to bugs
that this new infrastructure helped find.
Encourage people to adopt your new infrastructure as new refcounted
objects are introduced into the kernel. You might even consider a LWN
article about this.
Eventually we'll get around to changing existing code to use it, once
there is a sufficient advantage to doing so. Most likely when we're
reworking the code for other reasons, or when we're chasing some horrid
refcounting bug and think that this might help find it.
--
Jeff Layton <jlay...@poochiereds.net>
On Sat, 2017-02-11 at 09:01 -0500, David Windsor wrote:
> On Sat, Feb 11, 2017 at 7:31 AM, Jeff Layton <jlay...@poochiereds.net> wrote:
> > On Sat, 2017-02-11 at 01:42 -0500, David Windsor wrote:
> > >
> > >
> > > > Signed-off-by: David Windsor <
queue(>cl_cb_waitq);
> > --
> > 2.7.4
> >
The basic idea here is that nfsv4 sessions have a "resting state" of 0.
We want to keep them around, but if they go "dead" then we we'll tear
them down if they aren't actively in use at the time. So, we st
On Tue, 2016-11-08 at 06:53 -0500, Jeff Layton wrote:
> On Mon, 2016-11-07 at 22:42 -0700, Ross Zwisler wrote:
> >
> > I've got a virtual machine that has some NFS mounts, and with a newly
> > compiled
> > kernel based on v4.9-rc3 I see the following warning/info mess
ference(clnt->cl_xpi.xpi_xpswitch);
rcu_read_lock();
ret = rpc_xprt_switch_has_addr(xps, sap);
rcu_read_unlock();
return ret;
}
--8<--
Looks like the simple fix is to just move that rcu_dereference call
inside the rcu_read_lock there.
Cheers,
--
Jeff Layton <jlay...@redhat.com>
On Thu, 2016-08-04 at 12:55 +0200, Stanislav Kinsburskiy wrote:
>
> 03.08.2016 19:36, Jeff Layton пишет:
> >
> > On Wed, 2016-08-03 at 20:54 +0400, Stanislav Kinsburskiy wrote:
> > >
> > > Otherwise freezer cgroup state might never become "FROZEN"
r the kernel-userland boundary
as: "allow the process to be frozen, and then retry the call once it's
resumed".
With that, filesystems could return the error code when they want to
redrive the entire syscall from that level. That won't work for non-
idempotent requests though. We'd need to do something more elaborate
there.
--
Jeff Layton <jlay...@redhat.com>
uarantee
> or not?
>
> * I assume that wireless drivers aren't and can't be used in this
> fashion. Is that a correction assumption?
>
People do mount NFS over wireless interfaces. It's not terribly common
though, in my experience.
--
Jeff Layton <jlay...@poochiereds.net>
and that leaves
the port bound.
I'm travelling this weekend and am not set up to reproduce it to
confirm, but that does seem to be a plausible scenario.
--
Jeff Layton jlay...@poochiereds.net
--
To unsubscribe from this list: send the line unsubscribe netdev in
On Thu, 18 Jun 2015 21:08:43 -0400
Steven Rostedt rost...@goodmis.org wrote:
On Thu, 18 Jun 2015 18:50:51 -0400
Jeff Layton jlay...@poochiereds.net wrote:
The interesting bit here is that the sockets all seem to connect to port
55201 on the remote host, if I'm reading these traces
give some helpful info:
$ rpcinfo -p NFS servername
Also, what NFS version are you using to mount here? Your fstab entries
suggest that you're using the default version (for whatever distro this
is), but have you (e.g.) set up nfsmount.conf to default to v3 on this
box?
--
Jeff Layton jlay
From: Mel Gorman mgor...@suse.de
Jeff Layton reported the following;
[ 74.232485] [ cut here ]
[ 74.233354] WARNING: CPU: 2 PID: 754 at net/core/sock.c:364
sk_clear_memalloc+0x51/0x80()
[ 74.234790] Modules linked in: cts rpcsec_gss_krb5 nfsv4 dns_resolver nfs
From: Mel Gorman mgor...@suse.de
Jeff Layton reported the following;
[ 74.232485] [ cut here ]
[ 74.233354] WARNING: CPU: 2 PID: 754 at net/core/sock.c:364
sk_clear_memalloc+0x51/0x80()
[ 74.234790] Modules linked in: cts rpcsec_gss_krb5 nfsv4 dns_resolver nfs
performance reads in cifs aswell, but probably
not the demultiplexer thread, or they use MSG_DONTWAIT to avoid this problems
and deal with the blocking behaviour on a higher level.
--
Jeff Layton [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
On Tue, 26 Jun 2007 01:11:20 +0530
Satyam Sharma [EMAIL PROTECTED] wrote:
Hi,
On 6/9/07, Jeff Layton [EMAIL PROTECTED] wrote:
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Please cc networking patches to [EMAIL PROTECTED]
Jeff Layton [EMAIL PROTECTED
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Please cc networking patches to [EMAIL PROTECTED]
Jeff Layton [EMAIL PROTECTED] wrote:
The following patch is a first stab at removing this need. It makes it
so that in tcp_recvmsg() we also check
as expected. I'm
just not clear on whether it will have any adverse side-effects.
Obviously if this approach is OK then we'll probably also want to fix
up other recvmsg functions (udp_recvmsg, etc).
Anyone care to comment?
Thanks,
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp.c b
as of last night.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
--- linux-2.6/net/ipv4/udp.c.mcast-filter
+++ linux-2.6/net/ipv4/udp.c
@@ -286,6 +286,8 @@ static inline struct sock *udp_v4_mcast_
struct hlist_node *node;
struct sock *s = sk;
unsigned short hnum = ntohs
On Wed, 2006-09-13 at 07:32 -0700, David Stevens wrote:
[EMAIL PROTECTED] wrote on 09/13/2006 07:13:55 AM:
This is not true on any OS I'm aware of, including the
original sockets multicast implementation on early BSD.
The current Linux behavior does seem to be consistent with the
29 matches
Mail list logo
