On Thu, 2013-03-21 at 09:15 +0800, fanchaoting wrote:
> Myklebust, Trond 写道:
> > On Wed, 2013-03-20 at 16:01 +0800, fanchaoting wrote:
> >> when pnfs block using device mapper,if umounting later,it maybe
> >> cause oops. we apply "1 + sizeof(bl_umount_request)" memory for
> >> msg->data, the memory maybe overflow when we do "memcpy(&dataptr
> >> [sizeof(bl_msg)], &bl_umount_request, sizeof(bl_umount_request))",
> >> because the size of bl_msg is more than 1 byte.
> >>
> >> Signed-off-by: fanchaoting<fanchaoting@xxxxxxxxxxxxxx>
> >>
> >> ---
> >> fs/nfs/blocklayout/blocklayoutdm.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/nfs/blocklayout/blocklayoutdm.c b/fs/nfs/blocklayout/blocklayoutdm.c
> >> index 737d839..8df9afa 100644
> >> --- a/fs/nfs/blocklayout/blocklayoutdm.c
> >> +++ b/fs/nfs/blocklayout/blocklayoutdm.c
> >> @@ -55,7 +55,7 @@ static void dev_remove(struct net *net, dev_t dev)
> >>
> >> bl_pipe_msg.bl_wq = &nn->bl_wq;
> >> memset(msg, 0, sizeof(*msg));
> >> - msg->data = kzalloc(1 + sizeof(bl_umount_request), GFP_NOFS);
> >> + msg->data = kzalloc(sizeof(bl_msg) + sizeof(bl_umount_request), GFP_NOFS);
> >> if (!msg->data)
> >> goto out;
> >>
> >
> > Why not just move the calculation of msg->len, and then use msg->len in
> > the above allocation?
> >
>
> yes, you are right, thanks for reviewing, here is the change patch.
>
>
> when pnfs block using device mapper,if umounting later,it maybe
> cause oops. we apply "1 + sizeof(bl_umount_request)" memory for
> msg->data, the memory maybe overflow when we do "memcpy(&dataptr
> [sizeof(bl_msg)], &bl_umount_request, sizeof(bl_umount_request))",
> because the size of bl_msg is more than 1 byte.
>
> Signed-off-by: fanchaoting<fanchaoting@xxxxxxxxxxxxxx>
> Reviewed-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
>
> ---
> fs/nfs/blocklayout/blocklayoutdm.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/blocklayout/blocklayoutdm.c b/fs/nfs/blocklayout/blocklayoutdm.c
> index 737d839..6fc7b5c 100644
> --- a/fs/nfs/blocklayout/blocklayoutdm.c
> +++ b/fs/nfs/blocklayout/blocklayoutdm.c
> @@ -55,7 +55,8 @@ static void dev_remove(struct net *net, dev_t dev)
>
> bl_pipe_msg.bl_wq = &nn->bl_wq;
> memset(msg, 0, sizeof(*msg));
> - msg->data = kzalloc(1 + sizeof(bl_umount_request), GFP_NOFS);
> + msg->len = sizeof(bl_msg) + bl_msg.totallen;
> + msg->data = kzalloc(msg->len, GFP_NOFS);
> if (!msg->data)
> goto out;
>
> @@ -66,7 +67,6 @@ static void dev_remove(struct net *net, dev_t dev)
> memcpy(msg->data, &bl_msg, sizeof(bl_msg));
> dataptr = (uint8_t *) msg->data;
> memcpy(&dataptr[sizeof(bl_msg)], &bl_umount_request, sizeof(bl_umount_request));
> - msg->len = sizeof(bl_msg) + bl_msg.totallen;
>
> add_wait_queue(&nn->bl_wq, &wq);
> if (rpc_queue_upcall(nn->bl_device_pipe, msg) < 0) {
Your email client appears to have replaced the tabs with space
characters. Please note that there are suggestions in
linux/Documentation/email-clients.txt for how to coerce Thunderbird to
cooperate when you are sending patches.
Anyhow, I've fixed up the whitespace damage, and have added a Cc:
stable@xxxxxxxxxxxxxxx before applying.
Thanks!
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
