Cannot allocate memory error on mount

Cannot allocate memory error on mount

[joe hefner]

On a recent Fedora (13), I am seeing a mount failure message that I can not explain. I have a Windows Server 2003 a with a share set up for access only for a specific username (say userfoo). If I try to mount it from Linux, using userfoo and the correct password all is well. If I try with a bad password or with some other username (userbar), it fails with "Permission denied" as expected. If I try to mount as username = administrator, and give the correct administrator password, I would also expect "Permission denied", but I see "Cannot allocate memory" instead.
 
dmesg and /var/log/messages show an odd entry about failure to get root inode. Setting cifsFYI shows that errno 13 is being seen on the client side, but then this inode error occurs.
 
Has anyone seen this? Any ideas what is happening?
 
Thanks, Joe H.
 
 fs/cifs/netmisc.c: Mapping smb error code 5 to POSIX err -13
 fs/cifs/cifssmb.c: Send error in QPathInfo = -13
 CIFS VFS: cifs_read_super: get root inode failed
 fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 44322319 with uid: 0
 fs/cifs/cifssmb.c: In tree disconnect
 fs/cifs/transport.c: For smb_command 113
 fs/cifs/transport.c: Sending smb:  total_len 39
 fs/cifs/connect.c: rfc1002 length 0x27
 fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 44322320 with uid: 0
 fs/cifs/cifssmb.c: In SMBLogoff for session disconnect
 fs/cifs/transport.c: For smb_command 116
 fs/cifs/transport.c: Sending smb:  total_len 43
 fs/cifs/connect.c: rfc1002 length 0x2b




      

Re: Cannot allocate memory error on mount

[Suresh Jayaraman]

On 08/26/2010 01:56 AM, joe hefner wrote:
> On a recent Fedora (13), I am seeing a mount failure message that I can not explain. I have a Windows Server 2003ýa with a share set up for access only for a specific username (say userfoo). If I try to mount it from Linux,ýusing userfoo and the correct password all is well. If I try with a bad password or with some other username (userbar), it fails with "Permission denied" as expected. If I try to mount as username = administrator, and give the correct administrator password, I would also expect "Permission denied", but I see "Cannot allocate memory" instead.
> ý
> dmesg and /var/log/messages show an oddýentry about failure to get root inode. Setting cifsFYI shows that errno 13 is being seen on the client side, but then thisýinode error occurs.
> ý
> Has anyone seen this? Any ideas what is happening?
> ý
> Thanks, Joe H.
> ý
> ýfs/cifs/netmisc.c: Mapping smb error code 5 to POSIX err -13
> ýfs/cifs/cifssmb.c: Send error in QPathInfo = -13
> ýCIFS VFS: cifs_read_super: get root inode failed
> ýfs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 44322319 with uid: 0
> ýfs/cifs/cifssmb.c: In tree disconnect
> ýfs/cifs/transport.c: For smb_command 113
> ýfs/cifs/transport.c: Sending smb:ý total_len 39
> ýfs/cifs/connect.c: rfc1002 length 0x27
> ýfs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 44322320 with uid: 0
> ýfs/cifs/cifssmb.c: In SMBLogoff for session disconnect
> ýfs/cifs/transport.c: For smb_command 116
> ýfs/cifs/transport.c: Sending smb:ý total_len 43
> ýfs/cifs/connect.c: rfc1002 length 0x2b
> 

Looks like the commit 0b8f18e3 assumed that cifs_get_inode_info() and
friends fail only due to memory allocation error when the inode is NULL
which is not the case if CIFSSMBQPathInfo() fails and returns an error.
Fix this by propagating the actual error code back.

Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
---
 fs/cifs/inode.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 4bc47e5..86a164f 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -834,7 +834,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
 						xid, NULL);
 
 	if (!inode)
-		return ERR_PTR(-ENOMEM);
+		return ERR_PTR(rc);
 
 #ifdef CONFIG_CIFS_FSCACHE
 	/* populate tcon->resource_id */

Re: Cannot allocate memory error on mount

[Jeff Layton]

On Thu, 26 Aug 2010 14:46:09 +0530
Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:

> On 08/26/2010 01:56 AM, joe hefner wrote:
> > On a recent Fedora (13), I am seeing a mount failure message that I can not explain. I have a Windows Server 2003ýa with a share set up for access only for a specific username (say userfoo). If I try to mount it from Linux,ýusing userfoo and the correct password all is well. If I try with a bad password or with some other username (userbar), it fails with "Permission denied" as expected. If I try to mount as username = administrator, and give the correct administrator password, I would also expect "Permission denied", but I see "Cannot allocate memory" instead.
> > ý
> > dmesg and /var/log/messages show an oddýentry about failure to get root inode. Setting cifsFYI shows that errno 13 is being seen on the client side, but then thisýinode error occurs.
> > ý
> > Has anyone seen this? Any ideas what is happening?
> > ý
> > Thanks, Joe H.
> > ý
> > ýfs/cifs/netmisc.c: Mapping smb error code 5 to POSIX err -13
> > ýfs/cifs/cifssmb.c: Send error in QPathInfo = -13
> > ýCIFS VFS: cifs_read_super: get root inode failed
> > ýfs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 44322319 with uid: 0
> > ýfs/cifs/cifssmb.c: In tree disconnect
> > ýfs/cifs/transport.c: For smb_command 113
> > ýfs/cifs/transport.c: Sending smb:ý total_len 39
> > ýfs/cifs/connect.c: rfc1002 length 0x27
> > ýfs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 44322320 with uid: 0
> > ýfs/cifs/cifssmb.c: In SMBLogoff for session disconnect
> > ýfs/cifs/transport.c: For smb_command 116
> > ýfs/cifs/transport.c: Sending smb:ý total_len 43
> > ýfs/cifs/connect.c: rfc1002 length 0x2b
> > 
> 
> Looks like the commit 0b8f18e3 assumed that cifs_get_inode_info() and
> friends fail only due to memory allocation error when the inode is NULL
> which is not the case if CIFSSMBQPathInfo() fails and returns an error.
> Fix this by propagating the actual error code back.
> 
> Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
> ---
>  fs/cifs/inode.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index 4bc47e5..86a164f 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -834,7 +834,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
>  						xid, NULL);
>  
>  	if (!inode)
> -		return ERR_PTR(-ENOMEM);
> +		return ERR_PTR(rc);
>  
>  #ifdef CONFIG_CIFS_FSCACHE
>  	/* populate tcon->resource_id */

Good catch.

Acked-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: Cannot allocate memory error on mount

[Steve French]

This is a good one to go upstream soon - if others critical to go
upstream soon let me know.

On Thu, Aug 26, 2010 at 7:23 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 26 Aug 2010 14:46:09 +0530
> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>
>> On 08/26/2010 01:56 AM, joe hefner wrote:
>> > On a recent Fedora (13), I am seeing a mount failure message that I can not explain. I have a Windows Server 2003ýa with a share set up for access only for a specific username (say userfoo). If I try to mount it from Linux,ýusing userfoo and the correct password all is well. If I try with a bad password or with some other username (userbar), it fails with "Permission denied" as expected. If I try to mount as username = administrator, and give the correct administrator password, I would also expect "Permission denied", but I see "Cannot allocate memory" instead.
>> > ý
>> > dmesg and /var/log/messages show an oddýentry about failure to get root inode. Setting cifsFYI shows that errno 13 is being seen on the client side, but then thisýinode error occurs.
>> > ý
>> > Has anyone seen this? Any ideas what is happening?
>> > ý
>> > Thanks, Joe H.
>> > ý
>> > ýfs/cifs/netmisc.c: Mapping smb error code 5 to POSIX err -13
>> > ýfs/cifs/cifssmb.c: Send error in QPathInfo = -13
>> > ýCIFS VFS: cifs_read_super: get root inode failed
>> > ýfs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 44322319 with uid: 0
>> > ýfs/cifs/cifssmb.c: In tree disconnect
>> > ýfs/cifs/transport.c: For smb_command 113
>> > ýfs/cifs/transport.c: Sending smb:ý total_len 39
>> > ýfs/cifs/connect.c: rfc1002 length 0x27
>> > ýfs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 44322320 with uid: 0
>> > ýfs/cifs/cifssmb.c: In SMBLogoff for session disconnect
>> > ýfs/cifs/transport.c: For smb_command 116
>> > ýfs/cifs/transport.c: Sending smb:ý total_len 43
>> > ýfs/cifs/connect.c: rfc1002 length 0x2b
>> >
>>
>> Looks like the commit 0b8f18e3 assumed that cifs_get_inode_info() and
>> friends fail only due to memory allocation error when the inode is NULL
>> which is not the case if CIFSSMBQPathInfo() fails and returns an error.
>> Fix this by propagating the actual error code back.
>>
>> Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>> ---
>>  fs/cifs/inode.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>> index 4bc47e5..86a164f 100644
>> --- a/fs/cifs/inode.c
>> +++ b/fs/cifs/inode.c
>> @@ -834,7 +834,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
>>                                               xid, NULL);
>>
>>       if (!inode)
>> -             return ERR_PTR(-ENOMEM);
>> +             return ERR_PTR(rc);
>>
>>  #ifdef CONFIG_CIFS_FSCACHE
>>       /* populate tcon->resource_id */
>
> Good catch.
>
> Acked-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>



-- 
Thanks,

Steve

Re: Cannot allocate memory error on mount

[Suresh Jayaraman]

On 08/26/2010 09:55 PM, Steve French wrote:
> This is a good one to go upstream soon - if others critical to go
> upstream soon let me know.

Do we need to Cc -stable as well? I don't feel strongly that we should
include this fix. However, unrelated memory allocation errors during
mount in supported kernels sounds more than annoying..

Thoughts?


> On Thu, Aug 26, 2010 at 7:23 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Thu, 26 Aug 2010 14:46:09 +0530
>> Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>>
>>> On 08/26/2010 01:56 AM, joe hefner wrote:
>>>> On a recent Fedora (13), I am seeing a mount failure message that I can not explain. I have a Windows Server 2003�a with a share set up for access only for a specific username (say userfoo). If I try to mount it from Linux,�using userfoo and the correct password all is well. If I try with a bad password or with some other username (userbar), it fails with "Permission denied" as expected. If I try to mount as username = administrator, and give the correct administrator password, I would also expect "Permission denied", but I see "Cannot allocate memory" instead.
>>>> �
>>>> dmesg and /var/log/messages show an odd�entry about failure to get root inode. Setting cifsFYI shows that errno 13 is being seen on the client side, but then this�inode error occurs.
>>>> �
>>>> Has anyone seen this? Any ideas what is happening?
>>>> �
>>>> Thanks, Joe H.
>>>> �
>>>> �fs/cifs/netmisc.c: Mapping smb error code 5 to POSIX err -13
>>>> �fs/cifs/cifssmb.c: Send error in QPathInfo = -13
>>>> �CIFS VFS: cifs_read_super: get root inode failed
>>>> �fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 44322319 with uid: 0
>>>> �fs/cifs/cifssmb.c: In tree disconnect
>>>> �fs/cifs/transport.c: For smb_command 113
>>>> �fs/cifs/transport.c: Sending smb:� total_len 39
>>>> �fs/cifs/connect.c: rfc1002 length 0x27
>>>> �fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 44322320 with uid: 0
>>>> �fs/cifs/cifssmb.c: In SMBLogoff for session disconnect
>>>> �fs/cifs/transport.c: For smb_command 116
>>>> �fs/cifs/transport.c: Sending smb:� total_len 43
>>>> �fs/cifs/connect.c: rfc1002 length 0x2b
>>>>
>>>
>>> Looks like the commit 0b8f18e3 assumed that cifs_get_inode_info() and
>>> friends fail only due to memory allocation error when the inode is NULL
>>> which is not the case if CIFSSMBQPathInfo() fails and returns an error.
>>> Fix this by propagating the actual error code back.
>>>
>>> Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
>>> ---
>>> �fs/cifs/inode.c | � �2 +-
>>> �1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>>> index 4bc47e5..86a164f 100644
>>> --- a/fs/cifs/inode.c
>>> +++ b/fs/cifs/inode.c
>>> @@ -834,7 +834,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
>>> � � � � � � � � � � � � � � � � � � � � � � � xid, NULL);
>>>
>>> � � � if (!inode)
>>> - � � � � � � return ERR_PTR(-ENOMEM);
>>> + � � � � � � return ERR_PTR(rc);
>>>
>>> �#ifdef CONFIG_CIFS_FSCACHE
>>> � � � /* populate tcon->resource_id */
>>
>> Good catch.
>>
>> Acked-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>
> 
> 
> 


-- 
Suresh Jayaraman

Re: Cannot allocate memory error on mount

[Jeff Layton]

On Fri, 27 Aug 2010 11:54:03 +0530
Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:

> On 08/26/2010 09:55 PM, Steve French wrote:
> > This is a good one to go upstream soon - if others critical to go
> > upstream soon let me know.
> 
> Do we need to Cc -stable as well? I don't feel strongly that we should
> include this fix. However, unrelated memory allocation errors during
> mount in supported kernels sounds more than annoying..
> 
> Thoughts?
> 

It doesn't seem like stable material to me. It's an annoyance, but not a
security or stability fix as far as I can see...

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>