0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:idr_remove+0x22/0x50 lib/idr.c:154
Code: 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 48 89 f3 e8 13 1e c6 fd 48 8d 7d
50 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04
+static void *idr_throbber(void *arg)
+{
+ time_t start = time(NULL);
+ int id = *(int *)arg;
+
+ rcu_register_thread();
+ do {
+ idr_alloc(&find_idr, xa_mk_value(id), id, id + 1, GFP_KERNEL);
+ idr_remove(&find_idr, id);
+
int id = *(int *)arg;
+
+ rcu_register_thread();
+ do {
+ idr_alloc(&find_idr, xa_mk_value(id), id, id + 1, GFP_KERNEL);
+ idr_remove(&find_idr, id);
+ } while (time(NULL) < start + 10);
+ rcu_unregister_thread();
+
+ return NU
oogle Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:idr_remove+0x28/0x60 lib/idr.c:153
Code: 40 00 55 48 89 e5 41 54 49 89 fc 53 48 89 f3 e8 9e a5 6f fa 49 8d 7c
24 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 04 3c 03 7e 1a 41
call idr_remove() to remove its handle from IDR.
Fixes: e7614370d6f0 ("net_sched: use idr to allocate u32 filter
handles")
Reported-by: Marcin Kabiesz
Tested-by: Marcin Kabiesz
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/sched
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Cong Wang
[ Upstream commit f12c643209db0626f2f54780d86bb93bfa7a9c2d ]
When we delete a u32 key via u32_delete_key(), we forget to
call idr_remove() to remove its handle from IDR.
Fixes
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Cong Wang
[ Upstream commit f12c643209db0626f2f54780d86bb93bfa7a9c2d ]
When we delete a u32 key via u32_delete_key(), we forget to
call idr_remove() to remove its handle from IDR.
Fixes
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr
On Sun, Aug 28, 2016 at 04:32:55PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program causes a WARNING in idr_remove:
Again under the assumption that you're running this with the vgem driver:
linux-next has it fixed.
-Daniel
>
> [ cut here ]---
Hello,
The following program causes a WARNING in idr_remove:
[ cut here ]
WARNING: CPU: 3 PID: 26766 at lib/idr.c:505
idr_remove called for id=1 which is not allocated.
CPU: 3 PID: 26766 Comm: syz-executor Not tainted 4.8.0-rc3+ #33
Hardware name: QEMU Standard PC (i440FX
Hello, Greg.
On Thu, Jul 14, 2016 at 08:02:26AM +0900, Greg KH wrote:
> On Wed, Jul 13, 2016 at 04:14:17PM -0400, Tejun Heo wrote:
> > On Wed, Jul 13, 2016 at 01:10:05PM -0700, John Garcia wrote:
> > > Hi Tejun, thanks for the response!
> > >
> > > It sounds like everything is good then, is it li
On Wed, Jul 13, 2016 at 04:14:17PM -0400, Tejun Heo wrote:
> On Wed, Jul 13, 2016 at 01:10:05PM -0700, John Garcia wrote:
> > Hi Tejun, thanks for the response!
> >
> > It sounds like everything is good then, is it likely this will get
> > backported to the next LTS 4.4 kernel?
>
> Yeah, it shoul
by the memcg struct keeping pinning memcg id which is a pretty
> limited resource. The above patch fixes the issue by the lifetime of
> decoupling memcg id from that of memcg struct.
>
>> send echo 1 > /proc/sys/vm/drop_caches
>> to the kernel. The title of this message is th
On Wed, Jul 13, 2016 at 01:10:05PM -0700, John Garcia wrote:
> Hi Tejun, thanks for the response!
>
> It sounds like everything is good then, is it likely this will get
> backported to the next LTS 4.4 kernel?
Yeah, it should.
Thanks!
--
tejun
ly see in machines that have breached the limit, and are trying
> in vain to remove a cgroup beyond the 65536 ceiling.
The idr_remove message is from a bug in creation failure path. It is
harmless and removed by b00c52dae6d9 ("cgroup: remove redundant
cleanup in css_create").
>
Hi esteemed kernel devs! Please be sure to CC answers to me personally
so they're flagged for my attention.
I've filed https://bugzilla.kernel.org/show_bug.cgi?id=124641 in
Bugzilla, so I'll try not to repeat too many key details here; GKH has
asked that I bring the conversation to email, LKML, an
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jerome Marchand
commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream.
The use of idr_remove() is forbidden in the callback functions of
idr_for_each(). It is therefore unsafe to call
4.3-stable review patch. If anyone has any objections, please let me know.
--
From: Jerome Marchand
commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream.
The use of idr_remove() is forbidden in the callback functions of
idr_for_each(). It is therefore unsafe to call
4.2.8-ckt3 -stable review patch. If anyone has any objections, please let me
know.
---8<
From: Jerome Marchand
commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream.
The use of idr_remove() is forbidden in the callback functi
If unallocated_id = (ANY * idr_max(idp->layers) + existing_id) is passed
to idr_remove(). The existing_id will be removed unexpectedly.
The following test shows this unexpected id-removal:
static void test4(void)
{
int id;
DEFINE_IDR(test_idr);
printk(KERN_INFO &qu
After idr subsystem is changed to RCU-awared, the free layer will not go to
the free list. The free list will not be filled up when idr_remove().
So we don't need to shink it too.
Signed-off-by: Lai Jiangshan
Acked-by: Tejun Heo
---
lib/idr.c | 16
1 files chang
After idr subsystem is changed to RCU-awared, the free layer will not go to
the free list. The free list will not be filled up when idr_remove().
So we don't need to shink it too.
Signed-off-by: Lai Jiangshan
Acked-by: Tejun Heo
---
lib/idr.c | 16
1 files chang
If unallocated_id = (ANY * idr_max(idp->layers) + existing_id) is passed
to idr_remove(). The existing_id will be removed unexpectedly.
The following test shows this unexpected id-removal:
static void test4(void)
{
int id;
DEFINE_IDR(test_idr);
printk(KERN_INFO &qu
On Fri, Apr 18, 2014 at 08:49:54PM +0800, Lai Jiangshan wrote:
> After idr subsystem is changed to RCU-awared, the free layer will not go to
> the free list. The free list will not be filled up when idr_remove().
> So we don't need to shink it too.
>
> "#ifndef TEST&q
On Fri, Apr 18, 2014 at 08:49:49PM +0800, Lai Jiangshan wrote:
> If unallocated_id = (ANY * idr_max(idp->layers) + existed_id) is passed
existing_id
> to idr_remove(). The existed_id will be removed unexpected.
If unallocated_id = (ANY * idr_max(idp->layers) + existed_id) is passed
to idr_remove(). The existed_id will be removed unexpected.
The following test shows this unexpected id-removal:
static void test4(void)
{
int id;
DEFINE_IDR(test_idr);
printk(KERN_INFO "Sta
After idr subsystem is changed to RCU-awared, the free layer will not go to
the free list. The free list will not be filled up when idr_remove().
So we don't need to shink it too.
"#ifndef TEST" can't work for user space test now, just remove it.
Signed-off-by: Lai Jiang
Hello,
Saw this WARNING a few times while fuzzing the kernel with Trinity in
a qemu virtual machine:
[ 22.883257] idr_remove called for id=4096 which is not allocated.
[ 22.884487] Pid: 2303, comm: trinity-child1 Not tainted 3.8.0+ #87
[ 22.885601] Call Trace:
[ 22.886080] [] idr_remove
On Fri, Jul 29, 2005 at 05:03:19PM -0700, Andrew Morton wrote:
>
> (The IDR problem is fixed in Linus's current tree)
yep, enabled PM and running rc4-git3, everything seems normal now.
--
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sat, Jul 30, 2005 at 08:27:24PM +0100, Hugh Dickins wrote:
> On Fri, 29 Jul 2005, Frank van Maarseveen wrote:
> > 2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
>
> I think your problem is this: HT has depended on CONFIG_ACPI for
> some while, and now in 2.6.13-rc CONFIG_ACPI dep
On Fri, 29 Jul 2005, Frank van Maarseveen wrote:
> 2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
I think your problem is this: HT has depended on CONFIG_ACPI for
some while, and now in 2.6.13-rc CONFIG_ACPI depends on CONFIG_PM.
You don't have CONFIG_PM set in your .config (nor had
On Fri, Jul 29, 2005 at 06:22:47PM -0600, Eric W. Biederman wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > Frank van Maarseveen <[EMAIL PROTECTED]> wrote:
> >>
> >> 2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
> >
> > OK, we seem to have broken your APIC code.
>
> There
Andrew Morton <[EMAIL PROTECTED]> writes:
> Frank van Maarseveen <[EMAIL PROTECTED]> wrote:
>>
>> 2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
>
> OK, we seem to have broken your APIC code.
There is a big difference here in that one kernel is using
the ACPI MADT tables and the ot
Frank van Maarseveen <[EMAIL PROTECTED]> wrote:
>
> 2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
OK, we seem to have broken your APIC code.
@@ -21,36 +21,26 @@
896MB LOWMEM available.
found SMP MP-table at 000fe710
DMI 2.3 present.
-ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] en
This is a /var/log/messages snippet from 2.6.12 where HT was working:
Jul 29 18:57:05 kotka syslogd 1.4.1#17: restart.
klogd 1.4.1#17, log source = /proc/kmsg started.
Inspecting /boot/System.map-2.6.12.2-y115
Loaded 38335 symbols from /boot/System.map-2.6.12.2-y115.
Symbols match kernel version 2
In addition, /proc/bus/usb got mounted but /proc/bus seems have changed into a
file:
$ df
df: `/proc/bus/usb': Not a directory
...
$ grep usb /proc/mounts
usbfs /proc/bus/usb usbfs rw 0 0
$ ls -l /proc/bus
-r--r--r-- 1 root root 0 Jul 29 17:54 /proc/bus
$ cat /proc/bus
Inter-| Receive
= 4) is a 16550A
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
idr_remove called for id=34 which is not allocated.
[dump_stack+23/32] dump_stack+0x17/0x20
[idr_remove_warning+22/32] idr_remove_warning+0x16/0x20
[sub_remove+252/256] sub_remove+0xfc/0x100
[idr_r
On Tue, 2005-02-22 at 13:22 -0500, Jim Houston wrote:
> I spent time looking at the pty and selinux code yesterday.
> I had little luck finding where the selinux code hooks into
> the pty code.
The call to lookup_one_len() by fs/devpts/inode.c:get_node() ultimately
calls permission(...,MAY_EXEC,.
On Sat, 2005-02-19 at 07:32, Russell Coker wrote:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
>
> I am getting messages "idr_remove called for id=0 which is not allocated"
> when
> SE Linux denies search access to /dev/pts.
>
>
El sáb, 19-02-2005 a las 23:32 +1100, Russell Coker escribió:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
>
> I am getting messages "idr_remove called for id=0 which is not allocated"
> when
> SE Linux denies search access to /dev/pts
http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
I am getting messages "idr_remove called for id=0 which is not allocated" when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case b
44 matches
Mail list logo
