* Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
[not found] ` <20070928013024.c7522542.akpm@linux-foundation.org>
@ 2007-09-28 16:21 ` Dave Hansen
2007-09-28 22:39 ` Edward Shishkin
0 siblings, 1 reply; 4+ messages in thread
From: Dave Hansen @ 2007-09-28 16:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Zan Lynx, Linux Kernel, reiserfs-devel, hch, reiserfs-dev
On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote:
> On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <zlynx@acm.org> wrote:
> > Near the end of my boot sequence, there is a kernel error. I am not
> > sure exactly what user-space is doing to make this happen, but I know
> > that a simple shell and some filesystem operations do not cause it.
> >
> > This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to
> > post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*,
> > and the error did not happen in rc6-mm1.
> >
> > console [netcon0] enabled
> > netconsole: network logging started
> > eth0: no IPv6 routers present
> > Unable to handle kernel NULL pointer dereference at 0000000000000053 RIP:
> > [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
> > PGD 0
> > Oops: 0000 [1] SMP
> > last sysfs file: /block/sr0/size
> > CPU 0
> > Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc
> > Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1
> > RIP: 0010:[<ffffffff802c96c0>] [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
> > RSP: 0018:ffff8100068b1b60 EFLAGS: 00010296
> > RAX: ffff810007108000 RBX: ffff81000261d8c0 RCX: ffffffff8093aca0
> > RDX: 0000000000000004 RSI: ffffffff8092e950 RDI: 0000000000000003
> > RBP: 0000000000000003 R08: 0000000000000003 R09: ffffffff8061f7cd
> > R10: 00000000b256aacb R11: 0000000000000000 R12: 00000000ffffffe2
> > R13: ffff8100068b1bd8 R14: ffff8100068b1ee8 R15: ffff81000655a910
> > FS: 00007f6f0930c6f0(0000) GS:ffffffff806ce000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 0000000000000053 CR3: 0000000007cb2000 CR4: 00000000000006e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process smbd (pid: 7291, threadinfo ffff8100068b0000, task ffff810007108000)
> > last branch before last exception/interrupt
> > from [<ffffffff802cc37a>] mnt_want_write+0x3a/0x90
> > to [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
> > Stack: ffffffff802cc37f ffff8100078cd9a0 ffff8100068b1bd8 ffff8100078cd9a0
> > ffffffff802c82bc ffff8100078cd780 0000000000000000 ffff8100078cd9a0
> > ffff8100068b1bd8 ffff8100068b1ee8 0000000000003000 0000000000000000
> > Call Trace:
> > [<ffffffff802cc37f>] mnt_want_write+0x3f/0x90
> > [<ffffffff802c82bc>] file_update_time+0x2c/0xe0
> > [<ffffffff803506a8>] truncate_file_body+0x148/0x3f0
> > [<ffffffff802647a3>] __lock_acquire+0x583/0x1180
> > [<ffffffff80537f17>] _spin_unlock+0x17/0x20
> > [<ffffffff80363822>] store_black_box+0x82/0x90
> > [<ffffffff8034a845>] safe_link_add+0x75/0xd0
> > [<ffffffff803521f7>] setattr_unix_file+0x207/0x220
> > [<ffffffff80538274>] _spin_unlock_irq+0x24/0x30
> > [<ffffffff805377f1>] __down_write_nested+0xa1/0xc0
> > [<ffffffff802c8857>] notify_change+0xf7/0x2c0
> > [<ffffffff802b051e>] do_truncate+0x5e/0x80
> > [<ffffffff802b0659>] sys_ftruncate+0x119/0x130
> > [<ffffffff8020c39e>] system_call+0x7e/0x83
>
> But you oopsed in a different place, via resier4. I don't know if Dave
> considers that part of his mandate - he could reasonably ask the reiser4
> guys to help fix things up.
First of all, thanks a bunch for the report. It really helps.
This could probably be considered a reiser4 bug, excited by the r/o bind
mount changes. See how that pointer is 0x...053? That's a weird offset
for a structure that should be mostly word-aligned.
I think that's because reiser4 stack-allocates a 'struct file', and then
only initializes parts of it, *not* including the vfsmount. The test in
file_update_time() is for f->f_vfsmnt == NULL, and I think we had
something like 0x1 in there.
I think that stack allocation is a pretty nasty trick for a structure
that's supposed to be pretty persistent and dynamically allocated, and
is certainly something that needs to get fixed up in a proper way.
This works around the problem for now, but this could potentially cause
more bugs any time we add some member to 'struct file' and depend on its
state being sane anywhere in the VFS. If there's a list anywhere of
merge-stopper reiser4 bugs around, this should probably go in there.
In general, I think reiser4 also lets the 'struct file' get way too deep
into its internals. For instance, I would expect reiser4_write_extent()
to take a plain inode, not a 'struct file'.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---
lxc-dave/fs/reiser4/plugin/file/file.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c
--- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.000000000 -0700
+++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.000000000 -0700
@@ -581,6 +581,7 @@ static int truncate_file_body(struct ino
file.private_data = NULL;
file.f_pos = new_size;
file.private_data = NULL;
+ file.f_vfsmnt = NULL;
uf_info = unix_file_inode_data(inode);
result = find_file_state(inode, uf_info);
if (result)
_
-- Dave
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
2007-09-28 16:21 ` 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate Dave Hansen
@ 2007-09-28 22:39 ` Edward Shishkin
2007-10-04 23:22 ` [patch] reiser4: do not allocate struct file on stack Edward Shishkin
0 siblings, 1 reply; 4+ messages in thread
From: Edward Shishkin @ 2007-09-28 22:39 UTC (permalink / raw)
To: Dave Hansen; +Cc: Andrew Morton, Zan Lynx, Linux Kernel, reiserfs-devel, hch
Dave Hansen wrote:
>On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote:
>
>
>>On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <zlynx@acm.org> wrote:
>>
>>
>>>Near the end of my boot sequence, there is a kernel error. I am not
>>>sure exactly what user-space is doing to make this happen, but I know
>>>that a simple shell and some filesystem operations do not cause it.
>>>
>>>This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to
>>>post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*,
>>>and the error did not happen in rc6-mm1.
>>>
>>>console [netcon0] enabled
>>>netconsole: network logging started
>>>eth0: no IPv6 routers present
>>>Unable to handle kernel NULL pointer dereference at 0000000000000053 RIP:
>>> [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
>>>PGD 0
>>>Oops: 0000 [1] SMP
>>>last sysfs file: /block/sr0/size
>>>CPU 0
>>>Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc
>>>Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1
>>>RIP: 0010:[<ffffffff802c96c0>] [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
>>>RSP: 0018:ffff8100068b1b60 EFLAGS: 00010296
>>>RAX: ffff810007108000 RBX: ffff81000261d8c0 RCX: ffffffff8093aca0
>>>RDX: 0000000000000004 RSI: ffffffff8092e950 RDI: 0000000000000003
>>>RBP: 0000000000000003 R08: 0000000000000003 R09: ffffffff8061f7cd
>>>R10: 00000000b256aacb R11: 0000000000000000 R12: 00000000ffffffe2
>>>R13: ffff8100068b1bd8 R14: ffff8100068b1ee8 R15: ffff81000655a910
>>>FS: 00007f6f0930c6f0(0000) GS:ffffffff806ce000(0000) knlGS:0000000000000000
>>>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>CR2: 0000000000000053 CR3: 0000000007cb2000 CR4: 00000000000006e0
>>>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>Process smbd (pid: 7291, threadinfo ffff8100068b0000, task ffff810007108000)
>>>last branch before last exception/interrupt
>>> from [<ffffffff802cc37a>] mnt_want_write+0x3a/0x90
>>> to [<ffffffff802c96c0>] __mnt_is_readonly+0x0/0x20
>>>Stack: ffffffff802cc37f ffff8100078cd9a0 ffff8100068b1bd8 ffff8100078cd9a0
>>> ffffffff802c82bc ffff8100078cd780 0000000000000000 ffff8100078cd9a0
>>> ffff8100068b1bd8 ffff8100068b1ee8 0000000000003000 0000000000000000
>>>Call Trace:
>>> [<ffffffff802cc37f>] mnt_want_write+0x3f/0x90
>>> [<ffffffff802c82bc>] file_update_time+0x2c/0xe0
>>> [<ffffffff803506a8>] truncate_file_body+0x148/0x3f0
>>> [<ffffffff802647a3>] __lock_acquire+0x583/0x1180
>>> [<ffffffff80537f17>] _spin_unlock+0x17/0x20
>>> [<ffffffff80363822>] store_black_box+0x82/0x90
>>> [<ffffffff8034a845>] safe_link_add+0x75/0xd0
>>> [<ffffffff803521f7>] setattr_unix_file+0x207/0x220
>>> [<ffffffff80538274>] _spin_unlock_irq+0x24/0x30
>>> [<ffffffff805377f1>] __down_write_nested+0xa1/0xc0
>>> [<ffffffff802c8857>] notify_change+0xf7/0x2c0
>>> [<ffffffff802b051e>] do_truncate+0x5e/0x80
>>> [<ffffffff802b0659>] sys_ftruncate+0x119/0x130
>>> [<ffffffff8020c39e>] system_call+0x7e/0x83
>>>
>>>
>>But you oopsed in a different place, via resier4. I don't know if Dave
>>considers that part of his mandate - he could reasonably ask the reiser4
>>guys to help fix things up.
>>
>>
>
>First of all, thanks a bunch for the report. It really helps.
>
>This could probably be considered a reiser4 bug, excited by the r/o bind
>mount changes. See how that pointer is 0x...053? That's a weird offset
>for a structure that should be mostly word-aligned.
>
>I think that's because reiser4 stack-allocates a 'struct file', and then
>only initializes parts of it, *not* including the vfsmount. The test in
>file_update_time() is for f->f_vfsmnt == NULL, and I think we had
>something like 0x1 in there.
>
>I think that stack allocation is a pretty nasty trick for a structure
>that's supposed to be pretty persistent and dynamically allocated, and
>is certainly something that needs to get fixed up in a proper way.
>
>
agreed.
>This works around the problem for now, but this could potentially cause
>more bugs any time we add some member to 'struct file' and depend on its
>state being sane anywhere in the VFS. If there's a list anywhere of
>merge-stopper reiser4 bugs around, this should probably go in there.
>
>
>
will be fixed.
>In general, I think reiser4 also lets the 'struct file' get way too deep
>into its internals. For instance, I would expect reiser4_write_extent()
>to take a plain inode, not a 'struct file'.
>
>
This uses struct file's private data for so-called hints (speedup
technique).
Why not plain inode? I think because this is remains of removed
file-as-directory stuff.
>Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
>
>---
>
> lxc-dave/fs/reiser4/plugin/file/file.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c
>--- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.000000000 -0700
>+++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.000000000 -0700
>@@ -581,6 +581,7 @@ static int truncate_file_body(struct ino
> file.private_data = NULL;
> file.f_pos = new_size;
> file.private_data = NULL;
>+ file.f_vfsmnt = NULL;
> uf_info = unix_file_inode_data(inode);
> result = find_file_state(inode, uf_info);
> if (result)
>_
>
>
>
>
Many thanks,
Edward.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [patch] reiser4: do not allocate struct file on stack
2007-09-28 22:39 ` Edward Shishkin
@ 2007-10-04 23:22 ` Edward Shishkin
2007-10-05 16:22 ` Zan Lynx
0 siblings, 1 reply; 4+ messages in thread
From: Edward Shishkin @ 2007-10-04 23:22 UTC (permalink / raw)
To: Andrew Morton, Vladimir V. Saveliev
Cc: Dave Hansen, Zan Lynx, Linux Kernel, reiserfs-devel, hch
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Edward Shishkin wrote:
> Dave Hansen wrote:
>
...
>>
>> I think that stack allocation is a pretty nasty trick for a structure
>> that's supposed to be pretty persistent and dynamically allocated, and
>> is certainly something that needs to get fixed up in a proper way.
>>
>>
>
> agreed.
>
>> This works around the problem for now, but this could potentially cause
>> more bugs any time we add some member to 'struct file' and depend on its
>> state being sane anywhere in the VFS. If there's a list anywhere of
>> merge-stopper reiser4 bugs around, this should probably go in there.
>>
>>
>
> will be fixed.
>
The promised fixup is attached.
Andrew, please apply.
Thanks,
Edward.
[-- Attachment #2: reiser4-fix-null-dereference-in-__mnt_is_readonly-in-ftruncate-2.patch --]
[-- Type: text/x-patch, Size: 5400 bytes --]
Do not allocate struct file on stack, pass the persistent one instead.
Signed-off-by: Edward Shishkin <edward@namesys.com>
---
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c | 35 ++++------
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h | 2
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c | 23 ++----
3 files changed, 26 insertions(+), 34 deletions(-)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c
@@ -566,23 +566,18 @@
* items or add them to represent a hole at the end of file. The caller has to
* obtain exclusive access to the file.
*/
-static int truncate_file_body(struct inode *inode, loff_t new_size)
+static int truncate_file_body(struct inode *inode, struct iattr *attr)
{
int result;
+ loff_t new_size = attr->ia_size;
if (inode->i_size < new_size) {
/* expanding truncate */
- struct dentry dentry;
- struct file file;
- struct unix_file_info *uf_info;
+ struct file * file = attr->ia_file;
+ struct unix_file_info *uf_info = unix_file_inode_data(inode);
+
+ assert("edward-1532", attr->ia_valid & ATTR_FILE);
- dentry.d_inode = inode;
- file.f_dentry = &dentry;
- file.private_data = NULL;
- file.f_pos = new_size;
- file.private_data = NULL;
- file.f_vfsmnt = NULL;
- uf_info = unix_file_inode_data(inode);
result = find_file_state(inode, uf_info);
if (result)
return result;
@@ -615,19 +610,19 @@
return result;
}
}
- result = reiser4_write_extent(&file, NULL, 0,
+ result = reiser4_write_extent(file, NULL, 0,
&new_size);
if (result)
return result;
uf_info->container = UF_CONTAINER_EXTENTS;
} else {
if (uf_info->container == UF_CONTAINER_EXTENTS) {
- result = reiser4_write_extent(&file, NULL, 0,
+ result = reiser4_write_extent(file, NULL, 0,
&new_size);
if (result)
return result;
} else {
- result = reiser4_write_tail(&file, NULL, 0,
+ result = reiser4_write_tail(file, NULL, 0,
&new_size);
if (result)
return result;
@@ -636,10 +631,10 @@
}
BUG_ON(result > 0);
INODE_SET_FIELD(inode, i_size, new_size);
- file_update_time(&file);
+ file_update_time(file);
result = reiser4_update_sd(inode);
BUG_ON(result != 0);
- reiser4_free_file_fsdata(&file);
+ reiser4_free_file_fsdata(file);
} else
result = shorten_file(inode, new_size);
return result;
@@ -2092,7 +2087,7 @@
* first item is formatting item, therefore there was
* incomplete extent2tail conversion. Complete it
*/
- result = extent2tail(unix_file_inode_data(inode));
+ result = extent2tail(file, unix_file_inode_data(inode));
else
result = -EIO;
@@ -2372,7 +2367,7 @@
uf_info->container == UF_CONTAINER_EXTENTS &&
!should_have_notail(uf_info, inode->i_size) &&
!rofs_inode(inode)) {
- result = extent2tail(uf_info);
+ result = extent2tail(file, uf_info);
if (result != 0) {
warning("nikita-3233",
"Failed (%d) to convert in %s (%llu)",
@@ -2638,7 +2633,7 @@
if (result == 0)
result = safe_link_add(inode, SAFE_TRUNCATE);
if (result == 0)
- result = truncate_file_body(inode, attr->ia_size);
+ result = truncate_file_body(inode, attr);
if (result)
warning("vs-1588", "truncate_file failed: oid %lli, "
"old size %lld, new size %lld, retval %d",
@@ -2724,7 +2719,7 @@
/* truncate file bogy first */
uf_info = unix_file_inode_data(inode);
get_exclusive_access(uf_info);
- result = truncate_file_body(inode, 0 /* size */ );
+ result = shorten_file(inode, 0 /* size */ );
drop_exclusive_access(uf_info);
if (result)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h
@@ -237,7 +237,7 @@
#define WRITE_GRANULARITY 32
int tail2extent(struct unix_file_info *);
-int extent2tail(struct unix_file_info *);
+int extent2tail(struct file *, struct unix_file_info *);
int goto_right_neighbor(coord_t *, lock_handle *);
int find_or_create_extent(struct page *);
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c
@@ -546,7 +546,7 @@
/* for every page of file: read page, cut part of extent pointing to this page,
put data of page tree by tail item */
-int extent2tail(struct unix_file_info *uf_info)
+int extent2tail(struct file * file, struct unix_file_info *uf_info)
{
int result;
struct inode *inode;
@@ -644,20 +644,17 @@
/* last page can be incompleted */
count = (inode->i_size & ~PAGE_CACHE_MASK);
while (count) {
- struct dentry dentry;
- struct file file;
- loff_t pos;
-
- dentry.d_inode = inode;
- file.f_dentry = &dentry;
- file.private_data = NULL;
- file.f_pos = start_byte;
- file.private_data = NULL;
- pos = start_byte;
- result = reiser4_write_tail(&file,
+ loff_t pos = start_byte;
+
+ assert("edward-1533",
+ file != NULL && file->f_dentry != NULL);
+ assert("edward-1534",
+ file->f_dentry->d_inode == inode);
+
+ result = reiser4_write_tail(file,
(char __user *)kmap(page),
count, &pos);
- reiser4_free_file_fsdata(&file);
+ reiser4_free_file_fsdata(file);
if (result <= 0) {
warning("", "reiser4_write_tail failed");
page_cache_release(page);
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] reiser4: do not allocate struct file on stack
2007-10-04 23:22 ` [patch] reiser4: do not allocate struct file on stack Edward Shishkin
@ 2007-10-05 16:22 ` Zan Lynx
0 siblings, 0 replies; 4+ messages in thread
From: Zan Lynx @ 2007-10-05 16:22 UTC (permalink / raw)
To: Edward Shishkin
Cc: Andrew Morton, Vladimir V. Saveliev, Dave Hansen, Linux Kernel,
reiserfs-devel, hch
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
On Fri, 2007-10-05 at 03:22 +0400, Edward Shishkin wrote:
> Edward Shishkin wrote:
>
> > Dave Hansen wrote:
> >
> ...
>
> >>
> >> I think that stack allocation is a pretty nasty trick for a structure
> >> that's supposed to be pretty persistent and dynamically allocated, and
> >> is certainly something that needs to get fixed up in a proper way.
> >>
> >>
> >
> > agreed.
> >
> >> This works around the problem for now, but this could potentially cause
> >> more bugs any time we add some member to 'struct file' and depend on its
> >> state being sane anywhere in the VFS. If there's a list anywhere of
> >> merge-stopper reiser4 bugs around, this should probably go in there.
> >>
> >>
> >
> > will be fixed.
> >
>
> The promised fixup is attached.
> Andrew, please apply.
>
> Thanks,
> Edward.
There were several copies of this email, so I picked one. :)
I had the crash with 2.6.23-rc8-mm2, so I applied this patch. Hunk #1
failed, the rest applied with fuzz. I manually applied hunk #1 and
recompiled.
I am now running with 2.6.23-rc8-mm2 + this patch and things seem good.
(Except for some issues with ACPI battery info moving out of proc and
confusing the heck out of HAL and the GNOME power management scripts).
--
Zan Lynx <zlynx@acm.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-10-05 16:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1190930060.7667.5.camel@localhost>
[not found] ` <20070928013024.c7522542.akpm@linux-foundation.org>
2007-09-28 16:21 ` 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate Dave Hansen
2007-09-28 22:39 ` Edward Shishkin
2007-10-04 23:22 ` [patch] reiser4: do not allocate struct file on stack Edward Shishkin
2007-10-05 16:22 ` Zan Lynx
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).