| Message ID | 87iozujkdy.fsf@xmission.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Resending with Serge's current email address. Eric ebiederm@xmission.com (Eric W. Biederman) writes: > Oleg Nesterov <oleg@redhat.com> writes: > >> On 07/27, Toralf Förster wrote: >>> >>> I do have a user mode linux image (stable 32 bit Gentoo Linux ) which erratically crashes >>> while fuzz tested with trinity if the victim files are located on a NFS share. >>> >>> The back trace of the core dumps always looks like the attached. >>> >>> To bisect it is hard. However after few attempts in the last weeks the following >>> commit is either the first bad commit or at least the upper limit (less likely). >>> >>> >>> commit 8aac62706adaaf0fab02c4327761561c8bda9448 >>> Author: Oleg Nesterov <oleg@redhat.com> >>> Date: Fri Jun 14 21:09:49 2013 +0200 >>> >>> move exit_task_namespaces() outside of exit_notify() >>> >>> #15 nlmclnt_setlockargs (req=0x48e18860, fl=0x48f27c8c) at fs/lockd/clntproc.c:131 >> >> Thanks. >> >> So nlmclnt_setlockargs()->utsname() crashes and we probably need >> the patch below. >> >> But is it correct? I know _absolutely_ nothing about nfs/sunrpc/etc and >> I never looked into this code before, most probably I am wrong. >> >> But it seems that __nlm_async_call() relies on workqueues. >> nlmclnt_async_call() does rpc_wait_for_completion_task(), but what if >> the caller is killed? >> >> nlm_rqst can't go away, ->a_count was incremented. But can't the caller >> exit before call->name is used? In this case the memory it points to >> can be already freed. > > I don't think anyone has ever looked into that. This was a flyby > conversion by Serge in 2006 when he originally did the uts namespace. > > > from commit e9ff3990f08e9a0c2839cc22808b01732ea5b3e4 > [PATCH] namespaces: utsname: switch to using uts namespaces > > Replace references to system_utsname to the per-process uts namespace > where appropriate. This includes things like uname. > > Changes: Per Eric Biederman's comments, use the per-process uts namespace > for ELF_PLATFORM, sunrpc, and parts of net/ipv4/ipconfig.c > > Hmm. That credits with me with this mess. What was I thinking? > Perhaps I just said you missed a couple of spots. > > This untested patch should fix it without any need to worry about > dynamic behavior. Although I am wondering if we have a few other spots > where the dynamic behavior might be iffy. > > Serge do you remember any of this? > > On a good day I can follow the nfs code but it takes quite a while. I > feel the same way about filesystems locks so I am not really certain > what is going on. > > Eric > > diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c > index 9760ecb..6643cfc 100644 > --- a/fs/lockd/clntproc.c > +++ b/fs/lockd/clntproc.c > @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) > > nlmclnt_next_cookie(&argp->cookie); > memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); > - lock->caller = utsname()->nodename; > + lock->caller = init_utsname()->nodename; > lock->oh.data = req->a_owner; > lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", > (unsigned int)fl->fl_u.nfs_fl.owner->pid, > - utsname()->nodename); > + init_utsname()->nodename); > lock->svid = fl->fl_u.nfs_fl.owner->pid; > lock->fl.fl_start = fl->fl_start; > lock->fl.fl_end = fl->fl_end; > > Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/28, Eric W. Biederman wrote: > > > This untested patch should fix it without any need to worry about > > dynamic behavior. Yeees ;) I was thinking about this change too, but I have no idea what this ->nodename actually means for nfs. If you are going to send this patch - great! > Although I am wondering if we have a few other spots > > where the dynamic behavior might be iffy. Yes. And perhaps the patch which moves exit_task_namespaces() after exit_task_work() makes sense anyway (the patch I showed). (but if you change nlmclnt_setlockargs() then it is not 3.11 material). The original motivation for 8aac62706 was the leak reported by Andrey, but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() from exit_notify() to do_exit()" is still fine imho, the reason for exit_task_namespaces() from the middle of exit_notify() has gone away. But perhaps it would be better if work->func() could use ->nsproxy even if the task is PF_EXITING. > > Serge do you remember any of this? > > > > On a good day I can follow the nfs code but it takes quite a while. I > > feel the same way about filesystems locks so I am not really certain > > what is going on. > > > > Eric > > > > diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c > > index 9760ecb..6643cfc 100644 > > --- a/fs/lockd/clntproc.c > > +++ b/fs/lockd/clntproc.c > > @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) > > > > nlmclnt_next_cookie(&argp->cookie); > > memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); > > - lock->caller = utsname()->nodename; > > + lock->caller = init_utsname()->nodename; > > lock->oh.data = req->a_owner; > > lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", > > (unsigned int)fl->fl_u.nfs_fl.owner->pid, > > - utsname()->nodename); > > + init_utsname()->nodename); > > lock->svid = fl->fl_u.nfs_fl.owner->pid; > > lock->fl.fl_start = fl->fl_start; > > lock->fl.fl_end = fl->fl_end; > > > > Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adding some people who pay more attention to nfs in network namespaces than I usually do. Oleg Nesterov <oleg@redhat.com> writes: > On 07/28, Eric W. Biederman wrote: >> >> > This untested patch should fix it without any need to worry about >> > dynamic behavior. > > Yeees ;) I was thinking about this change too, but I have no idea > what this ->nodename actually means for nfs. > > If you are going to send this patch - great! Just batting it around for now, and hoping we have the right combination of eyeballs look at it. There are more places in nfs that have questionable uses of utsname() instead of init_utsname(). So I think we probably need a more comprehensive patch at the very least. nfsclnt_reclaim is never called from userspace. nfsclnt_cancel is called from a callback that seems to have no guarantee of an approprate userspace context. nfsclnt_proc is called from rpc_ops and I did not spend the time to see if that could be a userspace context. So I really don't think using utsname() aka current->nsproxy->uts_ns makes sense in nlmclnt_setlockargs. We most definitely have an inconsistency in nfs. I am a little hesitant to suggest my patch because it is likely to have strange effects on nfs in a network namespace. On the flip side the code is broken anyway, we might as well at least use a version that is guarnateed not to cause a null pointer dereference in the kernel. This is the first time someone has seen a problem since late 2006 since Serge updated most of the references to use system_utsname but I think we have just been lucky. >> Although I am wondering if we have a few other spots >> > where the dynamic behavior might be iffy. > > Yes. And perhaps the patch which moves exit_task_namespaces() after > exit_task_work() makes sense anyway (the patch I showed). > > (but if you change nlmclnt_setlockargs() then it is not 3.11 material). > > The original motivation for 8aac62706 was the leak reported by Andrey, > but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() > from exit_notify() to do_exit()" is still fine imho, the reason for > exit_task_namespaces() from the middle of exit_notify() has gone away. > > But perhaps it would be better if work->func() could use ->nsproxy even > if the task is PF_EXITING. So far there is nothing in the nfs code that would suggest allowing work->func() being able to use ->nsproxy would make this code any better. I think that would just paper over the problem we are seeing right now. >> > Serge do you remember any of this? >> > >> > On a good day I can follow the nfs code but it takes quite a while. I >> > feel the same way about filesystems locks so I am not really certain >> > what is going on. >> > >> > Eric >> > >> > diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c >> > index 9760ecb..6643cfc 100644 >> > --- a/fs/lockd/clntproc.c >> > +++ b/fs/lockd/clntproc.c >> > @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) >> > >> > nlmclnt_next_cookie(&argp->cookie); >> > memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); >> > - lock->caller = utsname()->nodename; >> > + lock->caller = init_utsname()->nodename; >> > lock->oh.data = req->a_owner; >> > lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", >> > (unsigned int)fl->fl_u.nfs_fl.owner->pid, >> > - utsname()->nodename); >> > + init_utsname()->nodename); >> > lock->svid = fl->fl_u.nfs_fl.owner->pid; >> > lock->fl.fl_start = fl->fl_start; >> > lock->fl.fl_end = fl->fl_end; >> > >> > Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/29, Eric W. Biederman wrote: > > So I really don't think using utsname() aka current->nsproxy->uts_ns > makes sense in nlmclnt_setlockargs. > > We most definitely have an inconsistency in nfs. I tend to agree, but can't really comment. > > Yes. And perhaps the patch which moves exit_task_namespaces() after > > exit_task_work() makes sense anyway (the patch I showed). > > > > (but if you change nlmclnt_setlockargs() then it is not 3.11 material). > > > > The original motivation for 8aac62706 was the leak reported by Andrey, > > but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() > > from exit_notify() to do_exit()" is still fine imho, the reason for > > exit_task_namespaces() from the middle of exit_notify() has gone away. > > > > But perhaps it would be better if work->func() could use ->nsproxy even > > if the task is PF_EXITING. > > So far there is nothing in the nfs code that would suggest allowing > work->func() being able to use ->nsproxy would make this code any > better. I think that would just paper over the problem we are seeing > right now. I think you misunderstood my point. I fully agree if you change nlmclnt_setlockargs(). I am suggesting to move exit_task_namespaces() down after exit_task_work() as a separate change which perhaps makes sense by itself. Not to fix this problem, not for nfs, not for fput(). Just to allow work->func() to play with ->nsproxy if needed. task_work has other users, not only fput(). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Oleg Nesterov <oleg@redhat.com> writes: > On 07/29, Eric W. Biederman wrote: >> >> So I really don't think using utsname() aka current->nsproxy->uts_ns >> makes sense in nlmclnt_setlockargs. >> >> We most definitely have an inconsistency in nfs. > > I tend to agree, but can't really comment. If I could justify another couple of hours I could write the patch and justify it. I have cgroups exploding around my ears however. >> > Yes. And perhaps the patch which moves exit_task_namespaces() after >> > exit_task_work() makes sense anyway (the patch I showed). >> > >> > (but if you change nlmclnt_setlockargs() then it is not 3.11 material). >> > >> > The original motivation for 8aac62706 was the leak reported by Andrey, >> > but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() >> > from exit_notify() to do_exit()" is still fine imho, the reason for >> > exit_task_namespaces() from the middle of exit_notify() has gone away. >> > >> > But perhaps it would be better if work->func() could use ->nsproxy even >> > if the task is PF_EXITING. >> >> So far there is nothing in the nfs code that would suggest allowing >> work->func() being able to use ->nsproxy would make this code any >> better. I think that would just paper over the problem we are seeing >> right now. > > I think you misunderstood my point. > > I fully agree if you change nlmclnt_setlockargs(). I am suggesting to > move exit_task_namespaces() down after exit_task_work() as a separate > change which perhaps makes sense by itself. Not to fix this problem, > not for nfs, not for fput(). > > Just to allow work->func() to play with ->nsproxy if needed. task_work > has other users, not only fput(). So to clarify I see little evidence either way on the question of should work->funk be able to use ->nsproxy if the task is PF_EXITING. What little evidence I see suggests that we are actually better off not being able to access ->nsproxy. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 29, 2013 at 10:42:57AM -0700, Eric W. Biederman wrote: > > Adding some people who pay more attention to nfs in network namespaces > than I usually do. > > Oleg Nesterov <oleg@redhat.com> writes: > > > On 07/28, Eric W. Biederman wrote: > >> > >> > This untested patch should fix it without any need to worry about > >> > dynamic behavior. > > > > Yeees ;) I was thinking about this change too, but I have no idea > > what this ->nodename actually means for nfs. > > > > If you are going to send this patch - great! > > Just batting it around for now, and hoping we have the right combination > of eyeballs look at it. There are more places in nfs that have > questionable uses of utsname() instead of init_utsname(). So I think we > probably need a more comprehensive patch at the very least. > > nfsclnt_reclaim is never called from userspace. So, looking just at this one.... Note I think you mean nlmclnt_reclaim. That's part of the client's handling of server reboots. The client knows that it should hold some file lock, but knows that the server has now forgotten that fact, and needs to send a "reclaim" to get the lock back. That reclaim will get kicked off when the client's notified that the server rebooted. So we're not in the context of whoever originally did the fcntl(.,F_SETLK,.), and trying to get the namespace out of current is clearly wrong. nlm_host currently has a "struct net *net" field. Maybe we also need to stash a "struct uts_namespace *", or just a copy of the nodename? --b. > nfsclnt_cancel is called from a callback that seems to have no guarantee > of an approprate userspace context. > nfsclnt_proc is called from rpc_ops and I did not spend the time to see > if that could be a userspace context. > > So I really don't think using utsname() aka current->nsproxy->uts_ns > makes sense in nlmclnt_setlockargs. > > We most definitely have an inconsistency in nfs. I am a little hesitant > to suggest my patch because it is likely to have strange effects on nfs > in a network namespace. On the flip side the code is broken anyway, we > might as well at least use a version that is guarnateed not to cause > a null pointer dereference in the kernel. > > This is the first time someone has seen a problem since late 2006 since > Serge updated most of the references to use system_utsname but I think > we have just been lucky. > > >> Although I am wondering if we have a few other spots > >> > where the dynamic behavior might be iffy. > > > > Yes. And perhaps the patch which moves exit_task_namespaces() after > > exit_task_work() makes sense anyway (the patch I showed). > > > > (but if you change nlmclnt_setlockargs() then it is not 3.11 material). > > > > The original motivation for 8aac62706 was the leak reported by Andrey, > > but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() > > from exit_notify() to do_exit()" is still fine imho, the reason for > > exit_task_namespaces() from the middle of exit_notify() has gone away. > > > > But perhaps it would be better if work->func() could use ->nsproxy even > > if the task is PF_EXITING. > > So far there is nothing in the nfs code that would suggest allowing > work->func() being able to use ->nsproxy would make this code any > better. I think that would just paper over the problem we are seeing > right now. > > >> > Serge do you remember any of this? > >> > > >> > On a good day I can follow the nfs code but it takes quite a while. I > >> > feel the same way about filesystems locks so I am not really certain > >> > what is going on. > >> > > >> > Eric > >> > > >> > diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c > >> > index 9760ecb..6643cfc 100644 > >> > --- a/fs/lockd/clntproc.c > >> > +++ b/fs/lockd/clntproc.c > >> > @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) > >> > > >> > nlmclnt_next_cookie(&argp->cookie); > >> > memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); > >> > - lock->caller = utsname()->nodename; > >> > + lock->caller = init_utsname()->nodename; > >> > lock->oh.data = req->a_owner; > >> > lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", > >> > (unsigned int)fl->fl_u.nfs_fl.owner->pid, > >> > - utsname()->nodename); > >> > + init_utsname()->nodename); > >> > lock->svid = fl->fl_u.nfs_fl.owner->pid; > >> > lock->fl.fl_start = fl->fl_start; > >> > lock->fl.fl_end = fl->fl_end; > >> > > >> > Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gVHVlLCAyMDEzLTA3LTMwIGF0IDE3OjEyIC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6 DQo+IE9uIE1vbiwgSnVsIDI5LCAyMDEzIGF0IDEwOjQyOjU3QU0gLTA3MDAsIEVyaWMgVy4gQmll ZGVybWFuIHdyb3RlOg0KPiA+IA0KPiA+IEFkZGluZyBzb21lIHBlb3BsZSB3aG8gcGF5IG1vcmUg YXR0ZW50aW9uIHRvIG5mcyBpbiBuZXR3b3JrIG5hbWVzcGFjZXMNCj4gPiB0aGFuIEkgdXN1YWxs eSBkby4NCj4gPiANCj4gPiBPbGVnIE5lc3Rlcm92IDxvbGVnQHJlZGhhdC5jb20+IHdyaXRlczoN Cj4gPiANCj4gPiA+IE9uIDA3LzI4LCBFcmljIFcuIEJpZWRlcm1hbiB3cm90ZToNCj4gPiA+Pg0K PiA+ID4+ID4gVGhpcyB1bnRlc3RlZCBwYXRjaCBzaG91bGQgZml4IGl0IHdpdGhvdXQgYW55IG5l ZWQgdG8gd29ycnkgYWJvdXQNCj4gPiA+PiA+IGR5bmFtaWMgYmVoYXZpb3IuDQo+ID4gPg0KPiA+ ID4gWWVlZXMgOykgSSB3YXMgdGhpbmtpbmcgYWJvdXQgdGhpcyBjaGFuZ2UgdG9vLCBidXQgSSBo YXZlIG5vIGlkZWENCj4gPiA+IHdoYXQgdGhpcyAtPm5vZGVuYW1lIGFjdHVhbGx5IG1lYW5zIGZv ciBuZnMuDQo+ID4gPg0KPiA+ID4gSWYgeW91IGFyZSBnb2luZyB0byBzZW5kIHRoaXMgcGF0Y2gg LSBncmVhdCENCj4gPiANCj4gPiBKdXN0IGJhdHRpbmcgaXQgYXJvdW5kIGZvciBub3csIGFuZCBo b3Bpbmcgd2UgaGF2ZSB0aGUgcmlnaHQgY29tYmluYXRpb24NCj4gPiBvZiBleWViYWxscyBsb29r IGF0IGl0LiAgVGhlcmUgYXJlIG1vcmUgcGxhY2VzIGluIG5mcyB0aGF0IGhhdmUNCj4gPiBxdWVz dGlvbmFibGUgdXNlcyBvZiB1dHNuYW1lKCkgaW5zdGVhZCBvZiBpbml0X3V0c25hbWUoKS4gIFNv IEkgdGhpbmsgd2UNCj4gPiBwcm9iYWJseSBuZWVkIGEgbW9yZSBjb21wcmVoZW5zaXZlIHBhdGNo IGF0IHRoZSB2ZXJ5IGxlYXN0Lg0KPiA+IA0KPiA+IG5mc2NsbnRfcmVjbGFpbSBpcyBuZXZlciBj YWxsZWQgZnJvbSB1c2Vyc3BhY2UuDQo+IA0KPiBTbywgbG9va2luZyBqdXN0IGF0IHRoaXMgb25l Li4uLg0KPiANCj4gTm90ZSBJIHRoaW5rIHlvdSBtZWFuIG5sbWNsbnRfcmVjbGFpbS4NCj4gDQo+ IFRoYXQncyBwYXJ0IG9mIHRoZSBjbGllbnQncyBoYW5kbGluZyBvZiBzZXJ2ZXIgcmVib290cy4g IFRoZSBjbGllbnQNCj4ga25vd3MgdGhhdCBpdCBzaG91bGQgaG9sZCBzb21lIGZpbGUgbG9jaywg YnV0IGtub3dzIHRoYXQgdGhlIHNlcnZlciBoYXMNCj4gbm93IGZvcmdvdHRlbiB0aGF0IGZhY3Qs IGFuZCBuZWVkcyB0byBzZW5kIGEgInJlY2xhaW0iIHRvIGdldCB0aGUgbG9jaw0KPiBiYWNrLg0K PiANCj4gVGhhdCByZWNsYWltIHdpbGwgZ2V0IGtpY2tlZCBvZmYgd2hlbiB0aGUgY2xpZW50J3Mg bm90aWZpZWQgdGhhdCB0aGUNCj4gc2VydmVyIHJlYm9vdGVkLg0KPiANCj4gU28gd2UncmUgbm90 IGluIHRoZSBjb250ZXh0IG9mIHdob2V2ZXIgb3JpZ2luYWxseSBkaWQgdGhlDQo+IGZjbnRsKC4s Rl9TRVRMSywuKSwgYW5kIHRyeWluZyB0byBnZXQgdGhlIG5hbWVzcGFjZSBvdXQgb2YgY3VycmVu dCBpcw0KPiBjbGVhcmx5IHdyb25nLg0KPiANCj4gbmxtX2hvc3QgY3VycmVudGx5IGhhcyBhICJz dHJ1Y3QgbmV0ICpuZXQiIGZpZWxkLiAgTWF5YmUgd2UgYWxzbyBuZWVkIHRvDQo+IHN0YXNoIGEg InN0cnVjdCB1dHNfbmFtZXNwYWNlICoiLCBvciBqdXN0IGEgY29weSBvZiB0aGUgbm9kZW5hbWU/ DQoNClRoZSBzdHJ1Y3QgcnBjX2NsbnQgYWxyZWFkeSBoYXMgdGhhdCBpbmZvcm1hdGlvbiBpbiB0 aGUgY2xfbm9kZW5hbWUNCmZpZWxkLg0KDQpDaGVlcnMNCiAgVHJvbmQNCg0KLS0gDQpUcm9uZCBN eWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15 a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c index 9760ecb..6643cfc 100644 --- a/fs/lockd/clntproc.c +++ b/fs/lockd/clntproc.c @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) nlmclnt_next_cookie(&argp->cookie); memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); - lock->caller = utsname()->nodename; + lock->caller = init_utsname()->nodename; lock->oh.data = req->a_owner; lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", (unsigned int)fl->fl_u.nfs_fl.owner->pid, - utsname()->nodename); + init_utsname()->nodename); lock->svid = fl->fl_u.nfs_fl.owner->pid; lock->fl.fl_start = fl->fl_start; lock->fl.fl_end = fl->fl_end;