[BUG] sleeping function called from invalid context at kernel/sched.c
Hi, I am trying to do file write operations in a thread (filewrite()) initiated from a jprobe (fs_vfs_write()) set on kernel function (vfs_write()). Although the write operation succeed, I get this on my log: BUG: sleeping function called from invalid context at kernel/sched.c:3678 in_atomic():0, irqs_disabled():1 [] __might_sleep+0xa5/0xab [] wait_for_completion+0x1a/0xc9 [] __wake_up+0x32/0x43 [] __queue_work+0x42/0x4f [] kthread_create+0x9b/0xd3 [] keventd_create_kthread+0x0/0x52 [] filewrite+0x0/0xaf [fsTrace] [] do_page_fault+0x31f/0x5c5 [] fs_vfs_write+0x57/0x9e [fsTrace] [] filewrite+0x0/0xaf [fsTrace] [] sys_write+0x41/0x67 [] sysenter_past_esp+0x56/0x79 === $ uname -a Linux cluster3 2.6.19.1 #1 SMP Thu Dec 21 14:03:57 EST 2006 i686 athlon i386 GNU/Linux I remember seeing something similar here on LKML, but am unable to trace it right now. Any idea what's going wrong? Thanks, Sumit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/slab.h: new KFREE() macro.
Asking for KFREE is as silly as asking for a macro to check if kmalloc
succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
On 1/8/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
--- Pekka Enberg <[EMAIL PROTECTED]> wrote:
> On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> > > And as I explained, it can result in longer code too. So, why
> > > keep this value around. Why not re-initialize it to NULL.
> >
> > Because initialization increases code size.
>
> And it also effectively blocks the slab debugging code from doing its
> job detecting double-frees.
>
Man, so you do want someone to set 'x' to NULL after freeing it, so that the
slab debugging code
can catch double frees. If you set it to NULL then double free is harmless. So,
you want something
harmful in the system and then debug it with the slab debugging code. Man,
doesn't make sense to
me.
-Amit
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/slab.h: new KFREE() macro.
Asking for KFREE is as silly as asking for a macro to check if kmalloc
succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
On 1/8/07, Amit Choudhary [EMAIL PROTECTED] wrote:
--- Pekka Enberg [EMAIL PROTECTED] wrote:
On 1/8/07, Hua Zhong [EMAIL PROTECTED] wrote:
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it to NULL.
Because initialization increases code size.
And it also effectively blocks the slab debugging code from doing its
job detecting double-frees.
Man, so you do want someone to set 'x' to NULL after freeing it, so that the
slab debugging code
can catch double frees. If you set it to NULL then double free is harmless. So,
you want something
harmful in the system and then debug it with the slab debugging code. Man,
doesn't make sense to
me.
-Amit
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] sleeping function called from invalid context at kernel/sched.c
Hi, I am trying to do file write operations in a thread (filewrite()) initiated from a jprobe (fs_vfs_write()) set on kernel function (vfs_write()). Although the write operation succeed, I get this on my log: BUG: sleeping function called from invalid context at kernel/sched.c:3678 in_atomic():0, irqs_disabled():1 [c011a65b] __might_sleep+0xa5/0xab [c0343a00] wait_for_completion+0x1a/0xc9 [c0118480] __wake_up+0x32/0x43 [c012b33a] __queue_work+0x42/0x4f [c012e0f7] kthread_create+0x9b/0xd3 [c012e00a] keventd_create_kthread+0x0/0x52 [f8a560d4] filewrite+0x0/0xaf [fsTrace] [c03464b9] do_page_fault+0x31f/0x5c5 [f8a561da] fs_vfs_write+0x57/0x9e [fsTrace] [f8a560d4] filewrite+0x0/0xaf [fsTrace] [c015f396] sys_write+0x41/0x67 [c01034d1] sysenter_past_esp+0x56/0x79 === $ uname -a Linux cluster3 2.6.19.1 #1 SMP Thu Dec 21 14:03:57 EST 2006 i686 athlon i386 GNU/Linux I remember seeing something similar here on LKML, but am unable to trace it right now. Any idea what's going wrong? Thanks, Sumit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB IDE Connector
Well, basically I would like to test the file system. And since I travel I lot, I carry laptop and this external disk with me. So, was just wondering if I could somehow conduct a disk-level test. Thanks. On Fri, 25 Feb 2005 14:36:49 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Feb 25, 2005 at 10:30:27AM +0530, Sumit Narayan wrote: > > Hi, > > > > I have an external IDE connector through USB port. Where could I get > > the exact point inside the kernel, from where I would get information > > such as Block No., Request size, partition details for a particular > > request, _just_ before being sent to the disk. > > > > Like, for a normal IDE, I could gather these details from inside the > > function __ide_do_rw_disk from "struct request". Is there anyway for > > finding out the same for a USB mass storage device? > > Why would you want to know this information for a controller device that > acts like a scsi one, not an IDE one (that's what usb storage devices > do...) > > thanks, > > greg k-h > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB IDE Connector
Well, basically I would like to test the file system. And since I travel I lot, I carry laptop and this external disk with me. So, was just wondering if I could somehow conduct a disk-level test. Thanks. On Fri, 25 Feb 2005 14:36:49 -0800, Greg KH [EMAIL PROTECTED] wrote: On Fri, Feb 25, 2005 at 10:30:27AM +0530, Sumit Narayan wrote: Hi, I have an external IDE connector through USB port. Where could I get the exact point inside the kernel, from where I would get information such as Block No., Request size, partition details for a particular request, _just_ before being sent to the disk. Like, for a normal IDE, I could gather these details from inside the function __ide_do_rw_disk from struct request. Is there anyway for finding out the same for a USB mass storage device? Why would you want to know this information for a controller device that acts like a scsi one, not an IDE one (that's what usb storage devices do...) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE via USB
Hi, I have an external IDE connector through USB port. Where could I get the exact point inside the kernel, from where I would get information such as Block No., Request size, partition details for a particular request, _just_ before being sent to the disk. Like, for a normal IDE, I could gather these details from inside the function __ide_do_rw_disk from "struct request". Is there anyway for finding out the same for a USB mass storage device? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE via USB
Hi, I have an external IDE connector through USB port. Where could I get the exact point inside the kernel, from where I would get information such as Block No., Request size, partition details for a particular request, _just_ before being sent to the disk. Like, for a normal IDE, I could gather these details from inside the function __ide_do_rw_disk from struct request. Is there anyway for finding out the same for a USB mass storage device? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB IDE Connector
Hi, I have an external IDE connector through USB port. Where could I get the exact point inside the kernel, from where I would get information such as Block No., Request size, partition details for a particular request, _just_ before being sent to the disk. Like, for a normal IDE, I could gather these details from inside the function __ide_do_rw_disk from "struct request". Is there anyway for finding out the same for a USB mass storage device? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB IDE Connector
Hi, I have an external IDE connector through USB port. Where could I get the exact point inside the kernel, from where I would get information such as Block No., Request size, partition details for a particular request, _just_ before being sent to the disk. Like, for a normal IDE, I could gather these details from inside the function __ide_do_rw_disk from struct request. Is there anyway for finding out the same for a USB mass storage device? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
