net/9p/client.c: fix misuse of spin_lock_irqsave for p9_client lock
PATCH 1/1 net/9p/client.c: fix misuse of spin_lock_irqsave for p9_client lock
In p9_read_work(), we use spin_lock for client->lock, but misuse spin_lock_irqsave for it in p9_fid_create(). As p9_client lock won't be locked in irq context, so spin_lock is enough. And that will improve the performance.
--- net/9p/client.c | 17 +++++++---------- net/9p/trans_fd.c | 7 +++---- 2 files changed, 10 insertions(+), 14 deletions(-)
net/9p/client.c +7 -10
@@ -260,7 +260,6 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize)static struct p9_req_t *p9_tag_alloc (struct p9_client *c,u16 tag,unsigned int max_size) { -unsigned long flags;int row, col;struct p9_req_t *req;int alloc_msize =min (c->msize, max_size);
@@ -270,7 +269,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) tag++;if (tag >= c->max_tag) { -spin_lock_irqsave (&c->lock, flags); +spin_lock (&c->lock);/* check again since original check was outside of lock */ while (tag >= c->max_tag) { row = (tag /P9_ROW_MAXTAG );
@@ -279,7 +278,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize)if (!c->reqs[row]) {pr_err ("Couldn't grow tag array\n" ); -spin_unlock_irqrestore (&c->lock, flags); +spin_unlock (&c->lock);return ERR_PTR (-ENOMEM ); }for (col =0 ; col <P9_ROW_MAXTAG ; col++) {
@@ -288,7 +287,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) } c->max_tag +=P9_ROW_MAXTAG ; } -spin_unlock_irqrestore (&c->lock, flags); +spin_unlock (&c->lock); } row = tag /P9_ROW_MAXTAG ; col = tag %P9_ROW_MAXTAG ;
@@ -909,7 +908,6 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt) {int ret;struct p9_fid *fid; -unsigned long flags;p9_debug (P9_DEBUG_FID ,"clnt %p\n" , clnt); fid =kmalloc (sizeof (struct p9_fid ),GFP_KERNEL );
@@ -928,9 +926,9 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt) fid->uid =current_fsuid (); fid->clnt = clnt; fid->rdir =NULL ; -spin_lock_irqsave (&clnt->lock, flags); +spin_lock (&clnt->lock);list_add (&fid->flist, &clnt->fidlist); -spin_unlock_irqrestore (&clnt->lock, flags); +spin_unlock (&clnt->lock);return fid;
@@ -942,14 +940,13 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt)static void p9_fid_destroy (struct p9_fid *fid) {struct p9_client *clnt; -unsigned long flags;p9_debug (P9_DEBUG_FID ,"fid %d\n" , fid->fid); clnt = fid->clnt;p9_idpool_put (fid->fid, clnt->fidpool); -spin_lock_irqsave (&clnt->lock, flags); +spin_lock (&clnt->lock);list_del (&fid->flist); -spin_unlock_irqrestore (&clnt->lock, flags); +spin_unlock (&clnt->lock);kfree (fid->rdir);kfree (fid); }
net/9p/trans_fd.c +3 -4
@@ -197,15 +197,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)static void p9_conn_cancel (struct p9_conn *m,int err) {struct p9_req_t *req, *rtmp; -unsigned long flags;LIST_HEAD (cancel_list);p9_debug (P9_DEBUG_ERROR ,"mux %p err %d\n" , m, err); -spin_lock_irqsave (&m->client->lock, flags); +spin_lock (&m->client->lock);if (m->err) { -spin_unlock_irqrestore (&m->client->lock, flags); +spin_unlock (&m->client->lock);return ; }
@@ -217,7 +216,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)list_for_each_entry_safe (req, rtmp, &m->unsent_req_list, req_list) {list_move (&req->req_list, &cancel_list); } -spin_unlock_irqrestore (&m->client->lock, flags); +spin_unlock (&m->client->lock);list_for_each_entry_safe (req, rtmp, &cancel_list, req_list) {p9_debug (P9_DEBUG_ERROR ,"call back req %p\n" , req);
Dominique Martinet
maintainerpiaojun wrote on Thu, Jul 12, 2018:
Quoted 4 lines
In
p9_read_work(), we usespin_lockforclient->lock, but misusespin_lock_irqsavefor it inp9_fid_create(). Asp9_clientlock won't be locked in irq context, sospin_lockis enough. And that will improve the performance.
Agreed on principle, see remark below
Quoted 19 lines
Signed-off-by Jun Piao <[email protected]>--- net/9p/client.c | 17 +++++++---------- net/9p/trans_fd.c | 7 +++---- 2 files changed, 10 insertions(+), 14 deletions(-)net/9p/client.c +0
-1@@ -260,7 +260,6 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize)static struct p9_req_t *p9_tag_alloc (struct p9_client *c,u16 tag,unsigned int max_size) { -unsigned long flags;int row, col;struct p9_req_t *req;int alloc_msize =min (c->msize, max_size);
net/9p/client.c static struct p9_fcall *p9_fcall_alloc(int alloc_msize) · line 272
Quoted 5 lines
net/9p/client.c +1
-1@@ -270,7 +269,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) tag++;if (tag >= c->max_tag) { -spin_lock_irqsave (&c->lock, flags); +spin_lock (&c->lock);
This code doesn't exist anymore with Matthew's idr rework, could you submit that patch based on top of my 9p-next branch? (unless you really want Andrew to take this for the next 4.18-rc, but I'm not convinced this qualifies)
Please see my "Current 9P patches - test branch" for details:
https://sourceforge.net/p/v9fs/mailman/message/36365359/
Signature · 1 line
Dominique Martinet
Hi Dominique,
Quoted 29 lines · Dominique Martinet
piaojun wrote on Thu, Jul 12, 2018:
Quoted 4 lines
In
p9_read_work(), we usespin_lockforclient->lock, but misusespin_lock_irqsavefor it inp9_fid_create(). Asp9_clientlock won't be locked in irq context, sospin_lockis enough. And that will improve the performance.Agreed on principle, see remark below
Quoted 21 lines
Signed-off-by Jun Piao <[email protected]>--- net/9p/client.c | 17 +++++++---------- net/9p/trans_fd.c | 7 +++---- 2 files changed, 10 insertions(+), 14 deletions(-)net/9p/client.c +0
-1@@ -260,7 +260,6 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize)static struct p9_req_t *p9_tag_alloc (struct p9_client *c,u16 tag,unsigned int max_size) { -unsigned long flags;int row, col;struct p9_req_t *req;int alloc_msize =min (c->msize, max_size);@@ -270,7 +269,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) tag++;
Quoted 8 lines
net/9p/client.c static struct p9_fcall *p9_fcall_alloc(int alloc_msize) · line 272
Quoted 3 lines
net/9p/client.c +1
-1if (tag >= c->max_tag) { -spin_lock_irqsave (&c->lock, flags); +spin_lock (&c->lock);This code doesn't exist anymore with Matthew's idr rework, could you submit that patch based on top of my 9p-next branch? (unless you really want Andrew to take this for the next 4.18-rc, but I'm not convinced this qualifies)
OK, I will rebase my patch and resend later.
Thanks,
Jun
Quoted 4 lines
Please see my "Current 9P patches - test branch" for details:
https://sourceforge.net/p/v9fs/mailman/message/36365359/