sendpage_ok() does. This patch replace the
> open coded checks by sendpage_ok() as a code cleanup.
>
> Signed-off-by: Coly Li
> Cc: Ilya Dryomov
> Cc: Jeff Layton
> ---
> net/ceph/messenger.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
case CALC_TARGET_NEED_RESEND:
> cancel_linger_map_check(lreq);
> /*
> @@ -3891,7 +3891,7 @@ static void scan_requests(struct ceph_osd *osd,
>!force_resend_writes))
> break;
>
> - /* fall through */
> + fallthrough;
> case CALC_TARGET_NEED_RESEND:
> cancel_map_check(req);
> unlink_request(osd, req);
Looks sane. Merged into ceph-client/testing branch.
Thanks!
--
Jeff Layton
long with
> the addresses (if, for example, it accesses the DNS directly). The default
> is
> -600 seconds. The value must be in the range 1 to INT_MAX.
> +5 seconds. The value must be in the range 1 to INT_MAX.
> .P
> The file can also include comments beginning with a '#' character unless
> otherwise suppressed by being inside a quoted value or being escaped with a
>
This looks good to me.
Reviewed-by: Jeff Layton
Let's fix the code to include , avoiding fragility.
>
> Signed-off-by: Mark Rutland
> Cc: Trond Myklebust
> Cc: Anna Schumaker
> Cc: J. Bruce Fields
> Cc: Jeff Layton
> Cc: David S. Miller
> Cc: linux-...@vger.kernel.org
> Cc: netdev@vger.kernel.org
> --
On Tue, 2017-10-24 at 15:12 -0500, Gustavo A. R. Silva wrote:
> Quoting "J. Bruce Fields" :
>
> > 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:
> > > > On Tue, Oct 24, 2017
);
> > > > @@ -1611,8 +1609,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, &integ_buf, integ_offset,
> > > > integ_len))
> > > > - BUG();
> > > > + BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset,
> > > > integ_len));
> > > > if (resbuf->tail[0].iov_base == NULL) {
> > > > if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE >
> > > > PAGE_SIZE)
> > > > goto out_err;
> > > > --
> > > > 2.7.4
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Layton
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
struct net *net, const int family,
> - const unsigned short port, int flags)
> +static int _svc_create_xprt(struct svc_serv *serv, const char *xprt_name,
> + struct net *net, const int family,
> + const unsigned short port, int flags)
> {
> struct svc_xprt_class *xcl;
>
Reviewed-by: Jeff Layton
_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
0054 08cd3dbc
> >
> > [ 6709.147653] fec0: 0000
> > 81000689ff20
> > [ 6709.155471] fee0: 08085240 81000689ff20 08085244
> > 6145
>
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;
> + /* 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
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
>
vsk->sk_xprt.xpt_flags);
> svc_xprt_enqueue(&svsk->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
age 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
On Sat, 2017-02-11 at 09:01 -0500, David Windsor wrote:
> On Sat, Feb 11, 2017 at 7:31 AM, Jeff Layton wrote:
> > On Sat, 2017-02-11 at 01:42 -0500, David Windsor wrote:
> > >
> > >
> > > > Signed-off-by: David Windsor
> > > > ---
> > &g
then we we'll tear
them down if they aren't actively in use at the time. So, we still free
the thing when the refcount goes to zero, but we have an extra condition
before we free it on the put -- that the session is also "dead" (meaning
that the client asked us to destroy it).
Your patch doesn't look like it'll break anything, but I personally find
it harder to follow that way. The freeable reference state will be 1
instead of the normal 0.
--
Jeff Layton
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
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
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"
ry
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
e
> 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
the legwork and figured out that reverting
those commits fixes the issue, then I suspect that the real culprit is
caf4ccd4e88cf2.
The client is likely closing down the other end of the callback
socket when it goes idle. Before that commit, we probably did an
xs_close on it, but now we're doing a xs_tcp_shutdown 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
On Thu, 18 Jun 2015 21:08:43 -0400
Steven Rostedt wrote:
> On Thu, 18 Jun 2015 18:50:51 -0400
> Jeff Layton 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 correctly. Wh
And here's what's in my /etc/exports directory
>
> /home/upload wife(no_root_squash,no_all_squash,rw,sync,no_subtree_check)
> /home/gallery 192.168.23.0/24(ro,sync,no_subtree_check)
>
> Attached is my config.
>
The interesting bit here is that the sockets a
From: Mel Gorman
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
fscache xfs
From: Mel Gorman
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
fscache xfs
gt; threads do is they either use tcp_read_sock and hooks into the sk_ callbacks
> which would be nice for high 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.
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:
> >
> > > Pl
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
> >
t and it seems to work 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 PR
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 th
ee 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 h
32 matches
Mail list logo
