Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Adam Nielsen <a.nielsen-HxjuLhO6/OPR7s880joybQ@public.gmane.org>
To: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: OOPS in cifs_write_end (3.0-rc5) - NULL pointer dereference
Date: Fri, 08 Jul 2011 13:55:54 +1000	[thread overview]
Message-ID: <4E167FCA.50808@shikadi.net> (raw)
In-Reply-To: <20110707083922.57003501-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>

Thanks for the quick reply!

> Interesting. I don't seem to be able to reproduce this on a -rc6
> kernel, and I don't recall seeing it happen in any interim kernels
> either. You may want to patch up to the latest kernel and see if the
> problem goes away.

I just compiled 3.0-rc6 (with cifs as a module instead) and I can still 
reproduce it.  Once the copy operation sat there for about five seconds 
before the oops, but all the other times it has oopsed immediately.  I 
am however getting the oops in a different function with -rc6, but still 
via CIFS.  Apart from CIFS I only have local and NFS mounts and they all 
seem to work fine.

> It looks like it hit a NULL pointer reference down in the bowels of the
> generic inode dirtying code. I sort of doubt this is a bug in cifs
> per-se, but it's hard to know without more detail.
>
> It may be helpful to follow the directions here and see if you can get
> a listing of where it oopsed:

Here is the new oops, followed by the gdb output:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff8112d3ae>] __mark_inode_dirty+0x16e/0x250
PGD 126cd4067 PUD 11e26a067 PMD 0
Oops: 0002 [#1] PREEMPT SMP
CPU 0
Modules linked in: cifs coretemp ipt_MASQUERADE iptable_nat nf_nat 
xt_tcpudp xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_state 
iptable_filter iptable_mangle xt_DSCP xt_dscp xt_string xt_owner 
xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_conntrack 
xt_connmark ip_tables x_tables ext4 mbcache jbd2 crc16 nf_conntrack_ftp 
nf_conntrack snd_hda_codec_analog snd_hda_intel snd_hda_codec tg3 
firewire_ohci tpm_tis ppdev tpm firewire_core tpm_bios i2c_i801 
parport_pc iTCO_wdt libphy snd_hwdep parport crc_itu_t

Pid: 2851, comm: cp Tainted: G        W   3.0.0-rc6 #2 Dell Inc. 
Precision WorkStation T3400  /0TP412
RIP: 0010:[<ffffffff8112d3ae>]  [<ffffffff8112d3ae>] 
__mark_inode_dirty+0x16e/0x250
RSP: 0018:ffff88011e10bc28  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880124b86850 RCX: ffff88011a16cb38
RDX: ffff88011a16cb38 RSI: 0000000000000000 RDI: ffffffff817e8300
RBP: ffff88011a16cad0 R08: 0000000000000000 R09: 0000000000000004
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff88011a16caf0
R13: ffff880124b869a8 R14: 0000000000000000 R15: ffff880124b86800
FS:  00007f4415492700(0000) GS:ffff88012bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 0000000114178000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process cp (pid: 2851, threadinfo ffff88011e10a000, task ffff8801140d2720)
Stack:
  0000000000000000 ffff8801259cd0c0 ffff88011e10bd08 ffff880124266280
  ffff88011a16cad0 ffffffffa01ff5ea ffff88011e10bcf6 ffff88011b06a700
  0000003914052dc0 ffff88011e10bd08 000000000000a068 0000000000000000
Call Trace:
  [<ffffffffa01ff5ea>] ? cifs_setattr+0x51a/0x780 [cifs]
  [<ffffffff81121783>] ? notify_change+0x113/0x300
  [<ffffffff81106de7>] ? do_truncate+0x57/0x80
  [<ffffffff81114f7f>] ? do_last+0x59f/0x780
  [<ffffffff81290d5f>] ? __percpu_counter_add+0x6f/0xc0
  [<ffffffff81116ca9>] ? path_openat+0xd9/0x410
  [<ffffffff8159018f>] ? _raw_spin_lock_irqsave+0x1f/0x50
  [<ffffffff8111711c>] ? do_filp_open+0x4c/0xc0
  [<ffffffff810368a9>] ? get_parent_ip+0x9/0x20
  [<ffffffff81593297>] ? sub_preempt_count+0x87/0xc0
  [<ffffffff8158fe80>] ? _raw_spin_unlock+0x10/0x40
  [<ffffffff81122792>] ? alloc_fd+0x122/0x150
  [<ffffffff81105cc9>] ? do_sys_open+0x169/0x200
  [<ffffffff81596afb>] ? system_call_fastpath+0x16/0x1b
Code: 8b 05 f7 78 73 00 48 8b 55 68 48 89 45 50 48 8d 4d 68 48 8b 45 70 
48 c7 c7 00 83 7e 81 48 89 42 08 48 89 10 48 8b 83 58 01 00 00
  89 48 08 48 89 45 68 4c 89 6d 70 48 89 8b 58 01 00 00 e8 aa
RIP  [<ffffffff8112d3ae>] __mark_inode_dirty+0x16e/0x250
  RSP <ffff88011e10bc28>
CR2: 0000000000000008
---[ end trace e10f67c8a11411b7 ]---
note: cp[2851] exited with preempt_count 1


(gdb) list *(cifs_setattr+0x51a)
0x1a61a is in cifs_setattr (fs/cifs/inode.c:2096).
2091               of the fs types (eg ext3, fat) do not have fine enough
2092               time granularity to match protocol, and we do not have a
2093               a way (yet) to query the server fs's time granularity 
(and
2094               whether it rounds times down).
2095            */
2096            if (attrs->ia_valid & (ATTR_MTIME | ATTR_CTIME))
2097                    cifsInode->time = 0;
2098    out:
2099            kfree(args);
2100            kfree(full_path);

The previous source line to 2096 (ignoring comments) is a call to 
mark_inode_dirty().

(gdb) list *(__mark_inode_dirty+0x16e)
0xffffffff8112d3ae is in __mark_inode_dirty (include/linux/list.h:41).
36      #ifndef CONFIG_DEBUG_LIST
37      static inline void __list_add(struct list_head *new,
38                                    struct list_head *prev,
39                                    struct list_head *next)
40      {
41              next->prev = new;
42              new->next = next;
43              new->prev = prev;
44              prev->next = new;
45      }

Not sure that this is really that helpful, but happy to test further...

Cheers,
Adam.

      parent reply	other threads:[~2011-07-08  3:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07  3:58 OOPS in cifs_write_end (3.0-rc5) - NULL pointer dereference Adam Nielsen
     [not found] ` <4E152EF2.7030001-HxjuLhO6/OPR7s880joybQ@public.gmane.org>
2011-07-07 12:39   ` Jeff Layton
     [not found]     ` <20110707083922.57003501-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2011-07-08  3:55       ` Adam Nielsen [this message]

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=4E167FCA.50808@shikadi.net \
    --to=a.nielsen-hxjulho6/opr7s880joybq@public.gmane.org \
    --cc=jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox