From: "Cyrill Gorcunov" <gorcunov@gmail.com>
To: "Trond Myklebust" <trond.myklebust@fys.uio.no>
Cc: bfields@fieldses.org, neilb@suse.de, ibm-acpi@hmh.eng.br,
len.brown@intel.com, kkeil@suse.de, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 1/3] NFS: fix potential NULL pointer dereference
Date: Thu, 17 Apr 2008 08:25:32 +0400 [thread overview]
Message-ID: <aa79d98a0804162125u45bde1edq550acf51784a5b5@mail.gmail.com> (raw)
In-Reply-To: <1208378428.8598.12.camel@heimdal.trondhjem.org>
On Thu, Apr 17, 2008 at 12:40 AM, Trond Myklebust
<trond.myklebust@fys.uio.no> wrote:
>
> On Thu, 2008-04-17 at 00:19 +0400, Cyrill Gorcunov wrote:
> > Trond, I've just pointed the problem and its solution (which is seems
> > to be a bit ugly, according to the rest nfs coding principle). So if
> > you prefer to have such a check in 'walk_path' function - just say me
> > that. You choose :) Thanks for comments
>
>
> > > So? The defensive coding principle is that you perform validity checks
> > > when the pointer is created. Otherwise, we could equally well have added
> > > the NULL deref check to nfs4_path_walk()...
>
> No, your fix was correct, it was just incomplete.
>
> The point I was making above was that defensive programming means that
> _all_ these validity/NULL pointer checks should really be done in
> nfs4_validate_mount_data and nfs_validate_mount_data. We shouldn't rely
> on checks in other parts of the code.
>
> In fact, as an example: it looks to me as if the lack of a
> nfs_server.hostname, leads to a lack of nfs_client->cl_hostname, which
> will eventually cause an Oops if you 'cat /proc/fs/nfsfs/servers', or if
> you hit the printk in nfs_update_inode(), or various other dprintk()s.
>
> Trond
>
>
Thanks Trond, I'll remake it ASAP (but can't guarantie that it will be soon ;)
next prev parent reply other threads:[~2008-04-17 4:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080416174421.442716301@gmail.com>
2008-04-16 17:44 ` Cyrill Gorcunov
2008-04-16 18:11 ` Trond Myklebust
2008-04-16 18:13 ` Cyrill Gorcunov
2008-04-16 18:55 ` Trond Myklebust
2008-04-16 20:19 ` Cyrill Gorcunov
2008-04-16 20:40 ` Trond Myklebust
2008-04-17 4:25 ` Cyrill Gorcunov [this message]
2008-04-17 7:25 ` Cyrill Gorcunov
2008-04-16 20:24 ` Cyrill Gorcunov
2008-04-16 17:44 ` [patch 2/3] CAPIFS: fix memory leak on remount Cyrill Gorcunov
2008-04-16 17:44 ` [patch 3/3] ThinkPad ACPI: fix possible NULL pointer dereference Cyrill Gorcunov
2008-04-16 20:52 ` Henrique de Moraes Holschuh
2008-04-18 12:41 ` Pavel Machek
2008-04-18 12:55 ` Cyrill Gorcunov
2008-04-18 13:07 ` Cyrill Gorcunov
2008-04-19 4:10 ` Henrique de Moraes Holschuh
2008-04-18 13:53 ` Cyrill Gorcunov
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=aa79d98a0804162125u45bde1edq550acf51784a5b5@mail.gmail.com \
--to=gorcunov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=ibm-acpi@hmh.eng.br \
--cc=kkeil@suse.de \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trond.myklebust@fys.uio.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®