From: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb
Date: Mon, 06 Dec 2010 22:39:37 +0100 [thread overview]
Message-ID: <4CFD5819.60609@exx.nl> (raw)
In-Reply-To: <20101206143423.74d8e236-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
Hey Jeff,
This patch fixes the oops, and the remote DFS link is readable. Great!
Thanks!
Robbert
Op 6-12-2010 20:34, Jeff Layton schreef:
> On Mon, 06 Dec 2010 20:12:34 +0100
> Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
>
>> Hi Jeff,
>>
>> Op 6-12-2010 13:15, Jeff Layton schreef:
>>> It's possible that cifs_mount will call cifs_build_path_to_root on a
>>> newly instantiated cifs_sb. In that case, it's likely that the
>>> master_tlink pointer has not yet been instantiated.
>>>
>>> Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
>>> as well, and have the caller pass that in.
>>
>> I still get an oops on 2.6.37-rc4-git5 with the patch applied:
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0000001c
>> IP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs]
>> *pde = 00000000
>> Oops: 0000 [#1] SMP
>> last sysfs file: /sys/devices/virtual/bdi/cifs-2/uevent
>> Modules linked in: hmac nls_utf8 cifs nls_base xfs exportfs loop
>> snd_pcm parport_pc parport tpm_tis tpm tpm_bios snd_timer snd soundcore
>> snd_page_alloc psmouse evdev pcspkr serio_raw i2c_piix4 i2c_core shpchp
>> container pci_hotplug processor thermal_sys ac button ext3 jbd mbcache
>> sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
>> e1000 mptspi mptscsih mptbase scsi_transport_spi scsi_mod piix ide_core
>> [last unloaded: scsi_wait_scan]
>>
>> Pid: 1362, comm: ls Not tainted 2.6.37-rc4-git5 #2 440BX Desktop
>> Reference Platform/VMware Virtual Platform
>> EIP: 0060:[<f8fd533b>] EFLAGS: 00010286 CPU: 0
>> EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
>> EAX: 00000000 EBX: f7156800 ECX: 40000040 EDX: 00000002
>> ESI: f7156800 EDI: f7156a00 EBP: 00000000 ESP: f72fddb0
>> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> Process ls (pid: 1362, ti=f72fc000 task=f71379e0 task.ti=f72fc000)
>> Stack:
>> f8fe14f3 002c80d0 00000000 f7156a00 f7156800 00000000 00000000 f8fcc96b
>> 0000007f f7156838 f5073d80 f50ac840 f8ff9f30 f8fcc7fd f522b000 c10b8301
>> f50ac900 f5073d80 00000000 f50ac900 f50ac900 f72fded4 00000000 f8febc6f
>> Call Trace:
>> [<f8fe14f3>] ? cifs_root_iget+0x1e/0x13f [cifs]
>> [<f8fcc96b>] ? cifs_do_mount+0x16e/0x247 [cifs]
>> [<f8fcc7fd>] ? cifs_do_mount+0x0/0x247 [cifs]
>> [<c10b8301>] ? vfs_kern_mount+0x9f/0x185
>> [<f8febc6f>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
>> [<c10bec73>] ? do_follow_link+0xb6/0x1b1
>> [<c10bf000>] ? link_path_walk+0x292/0x372
>> [<c10bf1a2>] ? path_walk+0x4f/0xae
>> [<c10bf2d3>] ? do_path_lookup+0x1f/0x69
>> [<c10bfb70>] ? user_path_at+0x37/0x5f
>> [<c1098af9>] ? vma_prio_tree_insert+0x17/0x2d
>> [<c10b9981>] ? vfs_fstatat+0x2a/0x50
>> [<c10b99e8>] ? vfs_lstat+0x13/0x15
>> [<c10b99f9>] ? sys_lstat64+0xf/0x23
>> [<c1052a04>] ? sys_futex+0xfe/0x112
>> [<c10b500c>] ? filp_close+0x4e/0x54
>> [<c127f54f>] ? do_page_fault+0x0/0x36b
>> [<c1002f9f>] ? sysenter_do_call+0x12/0x28
>> Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
>> 74 05 e8 ef 9b 05 c8 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40
>> 1c c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
>> EIP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f72fddb0
>> CR2: 000000000000001c
>> ---[ end trace 61b6103d05293c43 ]---
>>
>> Regards,
>> Robbert
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Interesting...does this (untested) patch fix it? It may have to be "wiggled" into
> place depending on your tree. If so, I'm surprised no one has tripped
> over this before...
>
> ----------------[snip]--------------------
>
> cifs: fix check of error return from is_path_accessable
>
> This function will return 0 if everything went ok.
>
> Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> fs/cifs/connect.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index bee397f..9fbe7c5 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -2836,7 +2836,7 @@ remote_path_check:
> goto mount_fail_check;
> }
> rc = is_path_accessible(xid, tcon, cifs_sb, full_path);
> - if (rc != -EREMOTE) {
> + if (rc != 0 && rc != -EREMOTE) {
> kfree(full_path);
> goto mount_fail_check;
> }
next prev parent reply other threads:[~2010-12-06 21:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 11:58 Kernel oops on 2.6.37-rc3, accessing remote DFS links Robbert Kouprie
[not found] ` <alpine.DEB.2.00.1012061247180.31332-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-12-06 12:08 ` Jeff Layton
[not found] ` <20101206070846.1f2c35d4-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-12-06 12:15 ` [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb Jeff Layton
[not found] ` <1291637703-10989-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-12-06 19:12 ` Robbert Kouprie
[not found] ` <4CFD35A2.7080407-C1IQQP51G3M@public.gmane.org>
2010-12-06 19:34 ` Jeff Layton
[not found] ` <20101206143423.74d8e236-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-12-06 21:39 ` Robbert Kouprie [this message]
2010-12-06 12:35 ` Kernel oops on 2.6.37-rc3, accessing remote DFS links Robbert Kouprie
[not found] ` <1291637583-10934-1-git-send-email-jlayton@redhat.com>
[not found] ` <4D5B8941.8040800@computer.org>
[not found] ` <4D5B8941.8040800-bdq14YP6qtRg9hUCZPvPmw@public.gmane.org>
2011-02-16 12:25 ` [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb Jeff Layton
-- strict thread matches above, loose matches on Subject: below --
2010-12-07 2:07 Jeff Layton
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=4CFD5819.60609@exx.nl \
--to=robbert-c1iqqp51g3m@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.