From: Jan Kara <jack@suse.cz>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Hans de Goede <hdegoede@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: Warning when calling radix_tree_insert on 3.12-rc4
Date: Mon, 14 Oct 2013 14:30:34 +0200 [thread overview]
Message-ID: <20131014123034.GF19604@quack.suse.cz> (raw)
In-Reply-To: <20131011221315.GE7094@xanatos>
Hello Sarah,
On Fri 11-10-13 15:13:15, Sarah Sharp wrote:
> I'm testing out some changes to the xHCI USB host controller driver
> (which uses a radix tree when a UAS device is attached to the host), and
> I noticed the following warning:
>
> Oct 11 14:42:08 xanatos kernel: [18165.819014] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
> Oct 11 14:42:08 xanatos kernel: [18165.836264] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa
> Oct 11 14:42:08 xanatos kernel: [18165.836271] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
> Oct 11 14:42:08 xanatos kernel: [18165.836275] usb 2-2: Product: Plugable USB3-SATA-UASP1
> Oct 11 14:42:08 xanatos kernel: [18165.836279] usb 2-2: Manufacturer: ASM1053E
> Oct 11 14:42:08 xanatos kernel: [18165.836291] usb 2-2: SerialNumber: 123456789045
> Oct 11 14:42:08 xanatos kernel: [18165.847661] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/8759
> Oct 11 14:42:08 xanatos kernel: [18165.847667] caller is radix_tree_node_alloc+0x5c/0xa0
Well, this warning seems to come from the __get_cpu_var() function. I don't
see how my commit could have caused what you observe. It seems you are
calling radix_tree_insert() for a radix tree which has atomic gfp mask set
and you don't do radix_tree_preload() / radix_tree_preload_end() around
that? That was always problematic and could lead to the above warning.
I'm not sure in which contexts xhci_update_stream_ring() can be called. But
if you are guaranteed non-atomic context, then using radix_tree_preload()
with a more relaxed gfp mask is good (lowers pressure on atomic allocations).
If the context depends on the caller, things are more complex. Generally,
you can use radix_tree_maybe_preload() but you have to set gfp mask
argument according to the context. The function then figures out whether
it's worth it to do a preload or not (but it always does preempt_disable()
which will silence the warning).
Honza
> Oct 11 14:42:08 xanatos kernel: [18165.847670] CPU: 1 PID: 8759 Comm: modprobe Not tainted 3.12.0-rc4+ #94
> Oct 11 14:42:08 xanatos kernel: [18165.847671] Hardware name: LENOVO 2325AP7/2325AP7, BIOS G2ET82WW (2.02 ) 09/11/2012
> Oct 11 14:42:08 xanatos kernel: [18165.847673] ffff88010c1d3fd8 ffff88010c1d38e8 ffffffff816081b9 0000000000000007
> Oct 11 14:42:08 xanatos kernel: [18165.847677] 0000000000000001 ffff88010c1d3918 ffffffff812e3ffc ffff88010c26c988
> Oct 11 14:42:08 xanatos kernel: [18165.847679] 0000000000000020 00000000000240b1 0000000000000003 ffff88010c1d3938
> Oct 11 14:42:08 xanatos kernel: [18165.847682] Call Trace:
> Oct 11 14:42:08 xanatos kernel: [18165.847686] [<ffffffff816081b9>] dump_stack+0x4f/0x84
> Oct 11 14:42:08 xanatos kernel: [18165.847689] [<ffffffff812e3ffc>] debug_smp_processor_id+0xdc/0x100
> Oct 11 14:42:08 xanatos kernel: [18165.847692] [<ffffffff812d47fc>] radix_tree_node_alloc+0x5c/0xa0
> Oct 11 14:42:08 xanatos kernel: [18165.847695] [<ffffffff812d48d5>] radix_tree_insert+0x95/0x260
> Oct 11 14:42:08 xanatos kernel: [18165.847702] [<ffffffffa008446f>] xhci_update_stream_ring+0x8f/0xc0 [xhci_hcd]
> Oct 11 14:42:08 xanatos kernel: [18165.847708] [<ffffffffa00860f0>] xhci_alloc_stream_info+0x190/0x410 [xhci_hcd]
> Oct 11 14:42:08 xanatos kernel: [18165.847713] [<ffffffffa00802ef>] xhci_alloc_streams+0x36f/0x750 [xhci_hcd]
> Oct 11 14:42:08 xanatos kernel: [18165.847716] [<ffffffff8108678f>] ? ttwu_stat+0xef/0x160
> Oct 11 14:42:08 xanatos kernel: [18165.847720] [<ffffffff810c8e93>] ? is_module_address+0x33/0x60
> Oct 11 14:42:08 xanatos kernel: [18165.847729] [<ffffffffa0036e35>] usb_alloc_streams+0x95/0xb0 [usbcore]
> Oct 11 14:42:08 xanatos kernel: [18165.847732] [<ffffffffa01eb874>] uas_configure_endpoints+0x154/0x210 [uas]
> Oct 11 14:42:08 xanatos kernel: [18165.847735] [<ffffffffa01ec367>] uas_probe+0x2d7/0x390 [uas]
> Oct 11 14:42:08 xanatos kernel: [18165.847743] [<ffffffffa0040053>] usb_probe_interface+0x1c3/0x2f0 [usbcore]
> Oct 11 14:42:08 xanatos kernel: [18165.847746] [<ffffffff813ba421>] driver_probe_device+0x91/0x3c0
> Oct 11 14:42:08 xanatos kernel: [18165.847749] [<ffffffff813ba7fb>] __driver_attach+0xab/0xb0
> Oct 11 14:42:08 xanatos kernel: [18165.847751] [<ffffffff813ba750>] ? driver_probe_device+0x3c0/0x3c0
> Oct 11 14:42:08 xanatos kernel: [18165.847753] [<ffffffff813b835e>] bus_for_each_dev+0x5e/0x90
> Oct 11 14:42:08 xanatos kernel: [18165.847756] [<ffffffff813b9e6e>] driver_attach+0x1e/0x20
> Oct 11 14:42:08 xanatos kernel: [18165.847758] [<ffffffff813b988f>] bus_add_driver+0x10f/0x2d0
> Oct 11 14:42:08 xanatos kernel: [18165.847760] [<ffffffff813baf24>] driver_register+0x64/0xf0
> Oct 11 14:42:08 xanatos kernel: [18165.847767] [<ffffffffa003ec34>] usb_register_driver+0xc4/0x180 [usbcore]
> Oct 11 14:42:08 xanatos kernel: [18165.847770] [<ffffffffa01f0000>] ? 0xffffffffa01effff
> Oct 11 14:42:08 xanatos kernel: [18165.847773] [<ffffffffa01f001e>] uas_driver_init+0x1e/0x20 [uas]
> Oct 11 14:42:08 xanatos kernel: [18165.847775] [<ffffffff8100210a>] do_one_initcall+0xda/0x180
> Oct 11 14:42:08 xanatos kernel: [18165.847778] [<ffffffff81080313>] ? __blocking_notifier_call_chain+0x63/0x80
> Oct 11 14:42:08 xanatos kernel: [18165.847782] [<ffffffff810c7e42>] load_module+0x14b2/0x1ad0
> Oct 11 14:42:08 xanatos kernel: [18165.847784] [<ffffffff810c4680>] ? show_initstate+0x50/0x50
> Oct 11 14:42:08 xanatos kernel: [18165.847788] [<ffffffff810c8532>] SyS_init_module+0xd2/0x120
> Oct 11 14:42:08 xanatos kernel: [18165.847791] [<ffffffff816183a9>] system_call_fastpath+0x16/0x1b
>
> This looks possibly related to commit
> 5e4c0d974139a98741b829b27cf38dc8f9284490 "lib/radix-tree.c: make
> radix_tree_node_alloc() work correctly within interrupt". I'll revert
> the commit, and see if the warning disappears. In the meantime, can you
> look into fixing this?
>
> Thanks,
> Sarah Sharp
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-10-14 12:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 22:13 Warning when calling radix_tree_insert on 3.12-rc4 Sarah Sharp
2013-10-14 12:30 ` Jan Kara [this message]
2013-10-14 18:17 ` Sarah Sharp
2013-10-14 18:39 ` Jan Kara
2013-10-15 1:54 ` [PATCH v2] xhci: fix usb3 streams Gerd Hoffmann
2013-10-15 6:13 ` Hans de Goede
2013-10-15 14:53 ` Alan Stern
2013-10-16 23:43 ` Sarah Sharp
2013-10-17 14:30 ` Alan Stern
2013-10-17 18:40 ` Sarah Sharp
2013-10-17 19:44 ` [PATCH] xhci: Remove segments from radix tree on failed insert Sarah Sharp
2013-10-17 21:12 ` Hans de Goede
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=20131014123034.GF19604@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hdegoede@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
/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.