D'oh, looks like if power management is disabled, pmdev is NULL (I get
that message when I load the module), but we try to derefence it anyways.
The fix is obvious:
duh, yeah, I'll send out a proper patch that handles the pm_register
failure too.
thanks.
--
zach
-
To unsubscribe from this
On Thu, Jan 18, 2001 at 08:49:38AM -0800, Linus Torvalds wrote:
That has its advantages: it's a very local thing, and doesn't need any
state. However, the fact is that you _need_ the persistency of a socket
option if you want to take advantage of external programs etc getting good
behaviour
have this problem (or a similar one, anyway -- sometimes the sound becomes
distorted or comes only through one speaker) under both Linux 2.2 and
Win2K. If it was just Linux, I'd assume it was a driver problem, but the
This is a long-standing bug with the maestro2 driver.
My current
@@ -28,6 +28,9 @@
* Shouts go out to Mike "DJ XPCom" Ang.
*
* History
+ * v1.20 - Jan 30 2001 - Zach Brown [EMAIL PROTECTED]
+ * get rid of pm callback and use pci_dev suspend/resume instead
+ * m3_probe cleanups, including pm oops think-o
* v1.10 - Jan 6 2001 - Zach Br
- ported to Linux 2.4 PCI API, PCI module based, cleaned up
return values. (taking into account all the hints Jeff has given
me ;)
cool :)
- did NOT change any power management support, since I don't know
anything about power management.
someone else
/drivers/sound/maestro3.c.dmaWed Feb 28 09:22:18 2001
+++ linux-2.4.2/drivers/sound/maestro3.cWed Feb 28 10:10:07 2001
@@ -28,6 +28,9 @@
* Shouts go out to Mike "DJ XPCom" Ang.
*
* History
+ * v1.22 - Feb 28 2001 - Zach Brown [EMAIL PROTECTED]
+ * allocate mem at in
This patch really has two parts. Most of it adds a helper function that
does the
if(pci_dma_supported()) { -dma_mask = mask }
code path. I was using the api today and didn't realize that I had to
set the mask myself, I assumed the _supported call would do it. If
people prefer the
pci_dma_supported has a boolean return, but the kernel norm is to return
zero on success, and -EFOO on error. I like your proposal with the
*nod* I just followed pci_dma_supported().
extremely minor nit that I think pci_set_dma_mask should return ENODEV
or EIO or something on error, and
please feel free to flame or apply, I'm not sure I'm really fond of the
code example..
- z
--- linux-2.4.2/include/linux/pci.h.dmasup Wed Feb 28 10:26:14 2001
+++ linux-2.4.2/include/linux/pci.h Wed Feb 28 10:30:12 2001
@@ -527,6 +527,7 @@
int pci_enable_device(struct pci_dev *dev);
I finally spent some time fixing up the maestro driver. lots of
feature additions had backed up, and the source was rotting. Its still
gross, but at least its cleaned up a bit. "It works for me" on my
pentium with an ESS maestro2 engineering board, but laptops will be
another story entirely.
I can't find the chip's datasheet. CMD only gives it to direct customers.
I do have the datasheet for the CMD-646U, a prior UDMA supporting chip.
Have you tried mailing them?. I sent mail to something silly like
support@cmd. After they found the right person for me to talk to, I
mentioned
Fantastic!
I was not aware of it, sorry... where can I find some doc?
There are some patches in the apache source rpms in
http://www.zabbo.net/phhttpd/ that shows how apache can connect to
another daemon and get its incoming connections sockets from it.
phhttpd itself is pretty hairy code
Unrelated to your change: the maestro reboot notifier shouldn't need to
unregister all that stuff. Who cares if the sound devices are freed,
since we are rebooting. free_irq+maestro_power seems sufficient. or
maybe stop_dma+free_irq+poweroff.
its only the power stuff that matters. some
one big lock.
As far as I can tell, I agree with you, but I do not think
that is related to the move to the new PCI interface.
*nod*
I also agree that the ioctl patch is kind of a bandaid over
the problems that you described, and, while Zach Brown can speak
The biggest problem
On Thu, Nov 16, 2000 at 04:22:36AM -0800, David S. Miller wrote:
Sure, that sounds nice.
Actually, one of the possible "grand plans" for 2.5 is a unified
"struct device". I don't know what will actually happen here.
apologies for pointing out the potentially obvoius, but people might
want
On Thu, Nov 02, 2000 at 12:03:41PM +, Mo McKinlay wrote:
I recently obtained an HP Omnibook XE2 laptop. It's a reasonably
As people have mentioned, there is an alpha free driver near
http://www.zabbo.net/maestro3/. Its not quite up to par yet.
maybe the web page should talk a bit more
http://www.zabbo.net/maestro3/
contains a driver for the maestro3 and allegro chipsets that I'm fairly
happy with.
its 2.2 only for now, play with 2.4 at your own risk. for now it
includes its own ac97_codec.c that is backported from 2.2.
I expect playback to work as well as ac97 mixing. apm
The maestro3 driver has a error cleanup bug that would leave its reboot
notifier registerd after exiting init_module with an error. Bayad.
It also had a minor bug where it didn't explicitly set the codec-id
before probing..
this patch vs 2.4.4-pre5 (I hope, its really vs jeff's cvs :)) fixes
i think Zach's phhttpd is an important milestone as well, it's the first
userspace webserver that shows how to use event-based, sigio-based async
networking IO and sendfile() under Linux. (I believe it had some
*blush*
performance problems related to sigio queue overflow, these issues might
On Wed, May 09, 2001 at 05:08:15PM -0400, Jeff Garzik wrote:
Why does maestro.c not use my suggestion? Because it doesn't use struct
pci_driver.
I finally found an able hacker with maestro hardware with power
management. He not only fixed the nasty pm races that were causing
channel
this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2.
It enables the hardware volume control feature of the maestro.
cool. I had support for this in the mega-patch I posted long ago, but
I never seperated and submitted those changes 'cause I'm a moron.
By giving hwv=0 to
below is the version with the suggested fixes, and with s/hwv/hwvol/ for
hwv_input also.
fantastic, thanks lukas.
alan, can you throw this in -ac? I don't think it will cause problems
for people with nonstandard wiring on the hw vol pins (read: dell
lattitudes), but if it does we can
I now have a patch that will output the hwv buttons pressed (up,
down, mute) to a new dynamically allocated misc device as letters
u, d, m, instead of directly modifying the mixer. Anyone want
that? It's more flexible than either the patch that's currently
in -ac or Lukas's patch, but you
The attached patch-in-progress removes the per-cpu statistics from
struct kernel_stat and puts them in a cpu_stat structure, one per cpu,
cacheline padded. The data is still coolated and presented through
/proc/stat, but another file /proc/cpustat is also added. The locking
is as nonexistant as
Currently struct kernel_stat has a few pre cpu arrays. This creates
cacheline exchange noise as the cpus update their entries in each array.
This patch creates an array of per cpu structs. The structure is padded
to the length of a cacheline. The meat of the patch against 2.4.6-pre8
is
This patch does the following:
- creates a cacheline aligned/padded struct cpu_stat[NR_CPUS].
- moves the [NR_CPUS] members of kernel_stat into cpu_stat
This moves the stat data that a cpu will update into a contiguous region.
Previous users of kernel_stat would compete for an array's
duh. I sent this to rutgers originally..
---
Date: Mon, 5 Feb 2001 07:42:25 -0500
From: Zach Brown [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PATCH] maestro3 2.4.1-ac2 shutdown fix
Its a wonder that anyone lets me write code.
The following fixes a goofy shutdown problem with the 2.4
001 - Zach Brown [EMAIL PROTECTED]
+ * fix up really dumb notifier - suspend oops
* v1.20 - Jan 30 2001 - Zach Brown [EMAIL PROTECTED]
* get rid of pm callback and use pci_dev suspend/resume instead
* m3_probe cleanups, including pm oops think-o
@@ -147,7 +149,7 @@
#define M_DEBUG 1
Zach, have you ever noticed such a performance bottleneck in your phhttpd?
yup, this is definitely something you don't want to be doing in the fast
path :)
Any thoughts?
Sorry I don't remember the start of this thread, but I'll ask anyway;
have you looked at Ingo Molnar's Tux server? Its
On Tue, Apr 17, 2007 at 03:18:56PM +0400, Pavel Emelianov wrote:
There are many places in the kernel where the construction like
foo = list_entry(head-next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head,
invalidation to fail, panicing the box. The test can be found in
the 'aio_dio_bugs' test group in test.kernel.org/autotest. After this patch
the test passes.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
mm/filemap.c | 48
1 file changed, 36 insertions
I'm finally back from my travel and conference hiatus.. you guys have
been busy! :)
On Feb 13, 2007, at 6:20 AM, Ingo Molnar wrote:
I'm pleased to announce the first release of the Syslet kernel
feature
and kernel subsystem, which provides generic asynchrous system call
support:
But the whole point is that the notion of a register is wrong in
the
first place. [...]
forget about it then. The thing we register is dead-simple:
struct async_head_user {
struct syslet_uatom __user **completion_ring;
unsigned long
+static void
+__mark_async_thread_ready(struct async_thread *at, struct
async_head *ah)
+{
+ list_del(at-entry);
+ list_add_tail(at-entry, ah-ready_async_threads);
+__mark_async_thread_busy(struct async_thread *at, struct
async_head *ah)
+{
+ list_del(at-entry);
+
If invalidate_inode_pages2_range() will return EIOCBRETRY as the patch
aio: fix kernel bug when page is temporally busy
Sorry Leonid, this patch is not safe.
It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be
called. This can lead to operations hanging, both AIO and calls
2) On the client facing side (port 53), I'd very much hope for a
way to
do 'recvv' on datagram sockets, so I can retrieve a whole bunch of
UDP datagrams with only one kernel transition.
I want to highlight this point that Bert is making.
Whenever we talk about AIO and kernel
On Feb 15, 2007, at 11:11 AM, Ananiev, Leonid I wrote:
It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be
called. This can lead to operations hanging
If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.
Only if kick_iocb() is called. It won't
On Feb 15, 2007, at 3:32 PM, Ananiev, Leonid I wrote:
If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.
Only if kick_iocb() is called. It won't be called if i_i_p2_r() was
the only thing to return -EIOCBRETRY.
It is not need to call kick_iocb()
for
and bio
completion both called aio_complete(). With this patch aio-stress sees -EIO.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
fs/aio.c| 109 ++
include/linux/aio.h | 30 +++
mm/filemap.c|4 -
3 files changed, 91
I
*think* the patch is right, but picking the changes to the code and
watching
its movement at the same time is making my head spin.
Really? The only things that changed are the assignment from iocb-
res (after testing pending_err) instead of the 'res' argument and
the dprintk.
b551e6cbf434 fs/aio.c
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
fs/aio.c | 77 +
1 file changed, 43 insertions(+), 34 deletions(-)
--- a/fs/aio.c Mon Feb 19 13:09:01 2007 -0800
+++ b/fs/aio.c Mon Feb 19 13:12:04 2007 -0800
@@ -192,6
and bio
completion both called aio_complete(). With this patch aio-stress sees -EIO.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
fs/aio.c| 49 +-
include/linux/aio.h | 30 +
mm/filemap.c|4 +--
3
Zach So this patch introduces a helper, aio_propogate_error(),
...which is spelled incorrectly: aio_propagate_error.
Man, I am batting 1000! Randy also made fun of my 'intead'.
Zach which queues post-submission errors in the iocb so that they are
Zach given to the user completion event
I would argue that one common cause of the EIO is userland
error (mmap concurrent with O_DIRECT), and EIO is the correct answer.
I disagree. That means that using the pagecache to synchronize
things like
the proposed online defragmentation will occasionally make O_DIRECT
users
fail.
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout svn://test.kernel.org/autotest/trunk/client autotest
cd autotest
Sorry I wasn't thorough enough. And partially because I was worried
about changing structure type for user space facing struct aio_ring.
Now that I looked through all arches, it looks safe as all arch's
atomic_t has the same size as int.
Here is the updated patch.
@@ -144,7 +144,7 @@
Ken uses the other (superior!) way of implementing ringbuffers: the head
and tail pointers (the naming of which AIO appears to have reversed) are
not constrained to the ringsize - they are simply allowed to wrap through
0xfff.
A-ha! That sure sounds great.
I'd be happy to see the kernel
I have mixed feelings. I think the userspace getevents support was
poorly designed and the simple fact that we've gone this long without it
says just how desperately the feature isn't needed.
I kept on getting requests from application developers who want that
feature. My initial patch
I kept on getting requests from application developers who want that
feature. My initial patch was dated back May 2004.
The right way to do it involves synchronization between the kernel side
io_getevents() and the userspace code pulling events out of the ring.
Alan Cox suggested
On Feb 20, 2007, at 9:33 AM, Ananiev, Leonid I wrote:
There is change in the patch which is uncommented in preface.
Now aio_ring_insert_entry() is not called if req-ki_users=1.
Before was called.
Could you comment it?
It is described in the patch description, though perhaps not
explicitly
There are some strange O_DIRECT corner cases in here such that the
'last
writer' may actually be a 'last reader' and winning can mean have
a copy
of the page in page cache older than the copy on disk.
As long as it is marked dirty so that it eventually gets synced to
disk,
it shouldn't
On Feb 21, 2007, at 12:35 AM, Ken Chen wrote:
On 2/20/07, Ananiev, Leonid [EMAIL PROTECTED] wrote:
1) mem=1G in kernel boot param if you have more
2) unmount; mk2fs; mount
3) dd if=/dev/zero of=test_file bs=1M count=1200
4) aiostress -s 1200m -O -o 2 -i 1 -r 16k test_file
5) if i++50 goto 2).
This is an interesting trick, but I'd like to consider hard whether
the added
complexity is worth it. Could you list the various other cases you
have in mind
which would want to use it ?
I'm happy to report that the sync case and the
invalidate_inode_pages2_range() case are the only two
Plus there's the fundamental killer that KAIO is a /lot/ harder to
implement (and to maintain) on the kernel side: it has to be
implemented
for every IO discipline, and even for the IO disciplines it
supports at
the moment, it is not truly asynchronous for things like metadata
blocking or
The more I think about it, a reasonable solution might actually be to
use threadlets for disk I/O and pure event based processing for
networking. It is two different handling paths and non-unified,
but that might be the price for good performance :-)
I generally agree, with some comments.
If
direct-io.c is evil. Ridiculously.
You will have a hard time finding someone to defend it, I predict :).
There is good news on that front, too. Chris (Mason) is making
progress on getting rid of the worst of the Magical Locking that
makes buffered races with O_DIRECT ops so awful.
I'm
On Feb 23, 2007, at 7:37 AM, Nick Piggin wrote:
The dentry hash uses up 8MB for 1 million entries on my 4GB system
is one
of the biggest wasters of memory for me. Because I rarely have more
than one or
two hundred thousand dentries. And that's with several kernel trees
worth of
entries.
On Mar 7, 2007, at 2:14 PM, Andrew Morton wrote:
On Mon, 05 Mar 2007 17:23:33 +0300
Leonid Ananiev [EMAIL PROTECTED] wrote:
From Leonid Ananiev
The patch fixes oops because of extra IO control block freeing.
IO is retried if page could not be invalidated.
This patch is incorrect and
this printk all, just remove it.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
fs/aio.c |1 -
1 file changed, 1 deletion(-)
--- a/fs/aio.c Tue Mar 27 14:56:08 2007 -0700
+++ b/fs/aio.c Tue Mar 27 14:56:49 2007 -0700
@@ -136,7 +136,6 @@ static int aio_setup_ring(struct kioctx
We don't need this printk all, just remove it.
(at all. Sigh.)
- z
-
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
+#define pipe_kmap_atomic(page, type) pipe_kmap(page)
+#define pipe_kunmap(page) do { } while (0)
+#define pipe_kunmap_atomic(page, type) do { } while (0)
Please don't drop arguments in stubs. It can let completely broken
code compile, like:
Does this look OK?
Almost...
#ifdef CONFIG_HIGHMEM
static inline void pipe_kunmap_atomic(void *addr, enum km_type type)
#else /* CONFIG_HIGHMEM */
static inline void pipe_kunmap_atomic(struct page *page, enum
km_type type)
- z
-
To unsubscribe from this list: send the line unsubscribe
Firstly, why not just specify an address for the return value and be done
with it? This infrastructure seems overkill, and you can always extend later
if required.
Sorry, which infrastructure?
Providing the function and stack to return to? Sure, I could certainly
entertain the idea
Or do you mean the syscall return value ending up in the userspace
completion event ring? That's mostly about being able to wait for
pending syslets to complete.
The latter. A ring is optimal for processing a huge number of requests, but
if you're really going to be firing off syslet
Linus Torvalds wrote:
On Thu, 10 Jan 2008, Rusty Russell wrote:
I'd have to read his original statement, but eventfd doesn't build up state,
so I think it qualifies.
How about you guys battle it out by giving an example program usign the
interface?
Here's a favourite really simple
I'm no expert, but I happened to notice this go by.
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
That doesn't seem too critical.
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
Ulrich Drepper wrote:
The following patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
I might quarrel with some details, but
BTW, I've botched the x86-on-x86_64 support. I have a patch but need to
patch it before I'll submit v3 of the patch set. If you want to work on
the patch and get syslet support going, let me know, I'll send the
latest version.
I probably won't come around to trying sys_indirect with
Report counts may be too high due to duplicate recognition of the very
same report.ยน
this is true however it's .. a hard issue. It's really hard to
distinguish a duplicate report from
two reports of the same bug.
Can we hack some data in to oops output to help? Say a giant per-boot
We could check ctx-reqs_active before scheduling to determine whether
or not we are waiting for I/O, but this would require taking the
context lock in order to be accurate. Given that the test would be
only for the sake of book keeping, it might be okay to do it outside
of the lock.
call_indirect() was using the wrong calling convention for the system call
handlers. system call handlers would get mixed up arguments.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
diff --git a/include/asm-x86/indirect_32.h b/include/asm-x86/indirect_32.h
index a1b72ac..e3dea8e 100644
The following patches are a substantial refactoring of the syslet code. I'm
branding them as the v7 release of the syslet infrastructure, though they
represent a signifiant change in focus.
My current focus is to see the most fundamental functionality brought to
maturity. To me, this means
-off-by: Zach Brown [EMAIL PROTECTED]
diff --git a/include/asm-generic/syslet-abi.h b/include/asm-generic/syslet-abi.h
new file mode 100644
index 000..5d19971
--- /dev/null
+++ b/include/asm-generic/syslet-abi.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_GENERIC_SYSLET_ABI_H
+#define
This patch adds the architecture independent structures of the
syslet ABI.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
diff --git a/include/linux/syslet-abi.h b/include/linux/syslet-abi.h
new file mode 100644
index 000..a8bc1a3
--- /dev/null
+++ b/include/linux/syslet-abi.h
@@ -0,0 +1,34
turn indirect_params into a struct that contains a union for
arguments which can never be used concurrently. This needs wider discussion.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
diff --git a/include/linux/indirect.h b/include/linux/indirect.h
index 97f9ac4..5d5abd7 100644
--- a/include/linux
which was built around 'uatoms'. Enough code has changed that
it wasn't appropriate to bring the previous Signed-off-by lines forward.
Signed-off-by: Zach Brown [EMAIL PROTECTED];
diff --git a/fs/exec.c b/fs/exec.c
index 282240a..942262f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -51,6 +51,7
juggle pointers to transfer the fpu state.
The syslets infrastructure needs to work with ptregs for the task which
is in sys_indirect(). So we add a PTREGSCALL stub around sys_indirect()
in x86_64.
Finally, we wire up sys_syslet_ring_wait().
Signed-off-by: Zach Brown [EMAIL PROTECTED]
diff --git
+/*
+ * syslet_ring doesn't have any kernel-side storage. Userspace allocates
them
+ * in their address space and initializes their fields and then passes them
to
+ * the kernel.
+ *
+ * These hashes provide the kernel-side storage for the wait queues which
+ * sys_syslet_ring_wait()
David Miller wrote:
From: Ulrich Drepper [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 01:53:14 -0500
FWIW, I think this indirect syscall stuff is the most ugly interface
I've ever seen proposed for the kernel.
Well, there's no XML in /proc :) :).
But, yes, I agree that the internal code needs
+union indirect_params {
+ struct {
+int flags;
+ } file_flags;
+};
Have you given thought to having to perform compat translation on this?
Today it's only copied directly from the user pointer into the union
in the task_struct.
I'd love if we could only use fixed-width fields in
Ingo Molnar wrote:
cool patchset. Small nit, the series is not bisectable:
Yeah, in a few places.
Uli, this is super easy to test if you maintain the patches with guilt.
With some easy scripting around guilt push you can verify that the
series builds as each patch is applied.
- z
-
To
Since there is no legacy interface to worry about all members added to
the structure can and should be neutral of the word size.
OK, perhaps add a giant comment warning about that. History tells us
that people will get it wrong.
We've done
this with some syscalls already (like pread64)
This was mentioned in one of my mails. I added the parameter to
accommodate Linus's and Zack's idea to use the functionality for syslets
as well. Not really a multiplexer, it is meant to be a execute
synchronously or asynchronously flag. In the latter case an additional
parameter might be
That's only because you're being, deliberately or accidentally, vague
about what your actual (as opposed to imagined) requirements are.
Maybe I can help by summarizing how syslets fit in to this.
Currently the syslet patches add a single submission call which includes
an argument which is a
Where does this INDIRECT_PARAM() macro get defined? I do not
see it being defined anywhere in these patches.
Defined in linux/indirect.h:
+#define INDIRECT_PARAM(set, name) current-indirect_params.set.name
Not my idea, I was following one review comment.
This was not in the patches you
The patch given below replaces the goto-loop by a while-based one.
That certainly looks fine. I would also replace the 'return' with
'break', but I guess that's more of a question of personal preference.
Besides, it removes the export for the same routine, because there are
no users for it
This doesn't look fine. Did you test this?
Oops, my fault. Of course, I tested the patch, but kernel modules are
disabled in my test setup, so I missed the error.
:)
Enclosed to this message is a new patch, which replaces the goto-loop by
the while-based one, but leaves the
+extern asmlinkage long (*sys_call_table[])(long, long, long,
This should be something like below instead, otherwise gcc wont parse
asmlinkage as being an attribute of the function signature.
extern long (asmlinkage *sys_call_table[])(long, long, long,
Yeah, thanks for pointing
I pulled from your tree to look over the patches, and noticed that it
looks like several commits were merged improperly. It looks like they
were auto merged or something from an email, and the commit message
contains the email headers, rather than just the commit message in the
body. This
Note that the sys_indirect system call takes an additional parameter which
is for now forced to be zero. This parameter is meant to enable the use
of sys_indirect to create syslets, asynchronously executed system calls.
This syslet approach is also the main reason for the interface in the
Hisashi Hifumi wrote:
Hi.
Current dio has some problems:
1, In ext3 ordered, dio write can return with EIO because of the race
between invalidation of
a page and jbd. jbd pins the bhs while committing journal so
try_to_release_page fails when jbd
is committing the transaction.
Yeah. It
in
invalidate_inode_pages2_range(). Later do_launder_page() calls could overwrite
errors generated by earlier calls. Fix this by storing do_launder_page in a
temporary variable which is only promoted to the function's return code if it
hadn't already generated an error.
Signed-off-by: Zach Brown
If anyone has a testcase - I can take a look at the problem again.
I can try and throw something together..
- z
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Erez Zadok wrote:
Setting: ltp-full-20071031, dio01 test on ext3 with Linus's latest tree.
Kernel w/ SMP, preemption, and lockdep configured.
This is a real lock ordering problem. Thanks for reporting it.
The updating of atime inside sys_mmap() orders the mmap_sem in the vfs
outside of the
Rusty Russell wrote:
When an AIO write gets an error after writing some data (eg. ENOSPC),
it should return the amount written already, not the error. Just like
write() is supposed to.
Andrew, please don't queue this fix. I think the bug is valid but the
patch is subtly dangerous.
diff -r
Rusty Russell wrote:
An AIO read or write should return -EINVAL if the offset is negative.
This check matches the one in pread and pwrite.
This was found by the libaio test suite.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
This looks fine to me.
Signed-off-by: Zach Brown [EMAIL
[EMAIL PROTECTED]
This looks good, feel free to push this from your tree.
Acked-By: Zach Brown [EMAIL PROTECTED]
- z
--
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
Matthew Wilcox wrote:
Use TASK_KILLABLE to allow wait_on_retry_sync_kiocb to return -EINTR.
All callers then check the return value and break out of their loops.
This won't work because sync kiocbs are a nasty hack that don't follow
the (also nasty) refcounting patterns of the aio core.
+ * ERR_CAST - Explicitly cast an error-valued pointer to another pointer type
+ * @ptr: The pointer to cast.
+ *
+ * Explicitly cast an error-valued pointer to another pointer type in such a
+ * way as to make it clear that's what's going on.
+ */
+static inline void *ERR_CAST(const void
Roland Dreier wrote:
+static inline void *ERR_CAST(const void *ptr)
+{
+return (void *) ptr;
+}
Just to nit, surely you don't need the cast inside the function. The
casting happens at the call site between the argument and returned pointer.
The way it's
1 - 100 of 1040 matches
Mail list logo
