16:22 2001
@@ -0,0 +1,129 @@
+/* taskornament.h: task ornaments
+ *
+ * (c) Copyright 2001 David Howells ([EMAIL PROTECTED])
+ */
+
+#ifndef _H_F92CE22E_93FF_11D4_8781_C0005742
+#define _H_F92CE22E_93FF_11D4_8781_C0005742
+
+#ifdef __KERNEL__
+
+#include linux/spinlock.h
+#include linux/list.h
...
+ spin_lock(mm-page_table_lock);
mm-rss++;
+ spin_unlock(mm-page_table_lock);
...
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give you fewer atomic memory access
cycles).
David
-
To unsubscribe
Hi Andrea:
Here you go:
/usr/local/bin/gcc -D__KERNEL__ -I/inst-kernels/linux-2.4.5-pre2-aa/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c
sys.c: In function `sys_gethostname':
The compiler should be now fixed in this respect, for both my stuff that's in
the kernel and Andrea's desired replacement. The problem appears to have been
triggered by having two input+output constraints (eg: +r, +m). However,
I can't test this because the head of the CVS trunk doesn't seem to
__asm__(and 1 %%esp.%0; :=r (current) : 0 (~8191UL));
This doesn't look right... Where did you get this from.
Taking the one in include/asm-i386/current.h as an example:
| __asm__(
This signifies a piece of inline assembly that the compiler must insert into
it's output code. The __asm__ is
Okay,
current is a macro on i386 that expands to get_current(). This gets the
task_struct for the task currently running on the CPU executing the code.
It does this by masking out the bottom bits of its kernel stack pointer.
For example, assuming that some running process has the following
The bug in gcc 3.0 that stopped the inline asm constraints being interpreted
properly, and thus prevented linux from compiling is now fixed.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I was running something on my Dell dual p3 box (optiplex gx300). my kernel
is linux-2.4.3-ac14. I got the following message:
How often did this message occur?
__rwsem_do_wake(): wait_list unexpectedly empty
[4191] c5966f60 = { 0001 })
kenel BUG at rwsem.c:99!
invalid operand:
to use PVCS
(a horrible java-based version control system for windows only) at work whilst
running Linux. It also allows me to run MSDEV without having to reboot.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Tigran Aivazian [EMAIL PROTECTED] wrote:
how about the classical standard way of "getting to kernel space", i.e.
plain system calls? Unless you really need a huge number of new system
calls,
Just the one... this'll take a parameter specifying the Win32 call to make:
int win32(int fd,
space object
handles issued by userspace DLL's.
However... for instance, the way I'm planning on implementing the registry
through this module is to have a cut down RPC server (using the RPC mechanism
available in that module) that gets invoked implicitly by RegOpenKey, et al.
David Howells
-
esses (not threads) * ~1020" what I
actually meant is "number of interested processed...", since any process not
interested can't actually issue the Win32 calls anyway.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Horst von Brand [EMAIL PROTECTED] wrote:
Lost me there. If after releasing the mutex it is free, the release was
sucessful AFAIAC. If two threads try to do it at the same time, so what?
Releasing an already free mutex is broken, OK. But two threads owning the
mutex at the same time is much
, this incurs a penalty
because of the the number of standard ioctl()'s the system checks for first,
before passing the command to my handler.
What Robert suggested was to use write() to do the deed, which I don't think
is a good idea.
David Howells
-
To unsubscribe from this list: send the line
way to grab an unused syscall, whether a
random one or a pre-determined one.
(2) The syscall table is not exported...
(3) Even if it was... just filling in the syscall slot from a module means
that it is possible for the module to be unloaded whilst the syscall is in
use.
David Howells
knfsd. It faces the same problem.
Of course it takes a small stub that's always in kernel, but so what.
Interesting idea... I'll take a look. Maybe it'll be possible to share
something.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
tting libc in the kernel. You
can make exceptions for calls that need the greatest performance and/or
don't translate well.
Also agreed, particularly when GDI calls are considered. Though this also
applies to the Native API.
David Howells
-
To unsubscribe from this list: send the line "unsubscri
) code? Or am I misunderstanding what you mean?
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
the syscall can't be entered
whilst the module is being unloaded.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
(for which this wine stuff is) rebooting seems
appropriate here, too.
It's not all that hard to do... and it does mean you can have demand-loadable
and -unloadable modules. Also I am writing/debugging it at the moment, and so
I like being able to unload and reload the module.
David Howells
-
To u
for Solaris/x86 syscalls (lcall 0x27). Pick another
number, and possibly reassign those two to 1 and 2 respectively because it's
cleaner like that.
But where do I get the other argument (struct pt_regs *) from? A normal Linux
syscall does not appear to have access to such a beast...
David Howells
though...
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
the struct file from the fd increments the usage count on
the struct file. The VFS automatically maintains the module count pointed to
by the file_operations structure based on the existence of the struct file.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
personalities, but I still need to maintain the refcount on the handle
map fd.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Could you please apply this little patch to export access_process_vm()?
Cheers,
David Howells
=
diff -uNr linux-2.4.0-test8-orig/kernel/ksyms.c linux-2.4.0-test8/kernel/ksyms.c
--- linux-2.4.0-test8-orig/kernel/ksyms.c Fri Sep 15 00:04:36 2000
+++ linux-2.4.0-test8/kernel
[EMAIL PROTECTED] (Linus Torvalds) wrote:
David Howells [EMAIL PROTECTED] wrote:
Oliver Neukum [EMAIL PROTECTED] wrote:
(3) Even if it was... just filling in the syscall slot from a module means
that it is possible for the module to be unloaded whilst the syscall is in
use
that is _only_ good for Win32.
I don't see much reason to have a nasty add-on that can't be
used by regular Linux programs.
Agreed.
The question is, how much will Linux go for?
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
VFS layer if I'm not mistaken.
No I won't. I wasn't really thinking in terms of having a process handles map
as a directory full of fd's, more like a flat file with a list in it.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
cup mat *grin*.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
is dictated to you. Yes... I'm implementing
some of the Windows system APIs because I'd like to have that functionality
available under Linux running as fast as possible, not because it's the only
one worth using:-)
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-k
use of it
if it was stored on the inode. You could then use sys_CreateFileA() to
actually use it fully.
However, it won't work over NFS...
David Howells
good reasons to use W32 interfaces internally,
but pushing them to Linux kernel seems bad for me.
Don't use it then... it'll not be mandatory. Wine has also to support OS's
that can't or won't add Win32 support in the kernel.
David Howells
-
To unsubscribe from this list: send the line "unsubs
the lines of GDI being implemented in
userspace by the client process, eg: wine.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
to a client's VM.
* Some bug fixes.
It can be downloaded from:
ftp://ftp.infradead.org/pub/people/dwh/wineservmod-2915.tar.bz2
[Thanks to David Woodhouse for this]
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
y requires that system calls be available on
all Linux systems.
Also true. You should be able to compile the module I currently have on all
Linux systems. Unfortunately, I can't test this at the moment.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
re-investigate tonight and see if I can
come back with some benchmarks/code-snippets tomorrow.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
in the same way. This would allow me to implement a lot of the NT Native
API.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
, though.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
with a non-fd approach.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[EMAIL PROTECTED] wrote:
hey, I hear that wine ( windows emulator ) can port into kernel and make
it running faster, How can I do it?
or anyone can make a patch to add wine code into kernel?
waiting for answer, Thanks
I've been writing one to provide all the Windows kernel objects in
Linus Torvalds [EMAIL PROTECTED] wrote:
Also note that the merging tests were not free, so at least under my set of
normal load the non-merging code is actually _faster_ than the clever
optimized merging. That was what clinched it for me: I absolutely hate to
see complexity that doesn't
Dec 8 06:05:29 agate kernel: hdc: packet command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 8 06:05:29 agate kernel: hdc: packet command error: error=0x50
Dec 8 06:05:29 agate kernel: ATAPI device hdc:
Dec 8 06:05:29 agate kernel: Error: Illegal request -- (Sense
here is my first shot for cleaning up the shm handling. It did survive
some basic testing but is not ready for inclusion.
Can you help me with an SHM related problem?
I'm currently writing a Win32 emulation kernel module to help speed Wine up,
and I'm writing the file mapping support stuff
I'm currently writing a Win32 emulation kernel module to help speed Wine up,
^
fd = shm_open ("xxx",...)
ptr = mmap (NULL, size, ..., fd, offset);
I am doing this from within kernel space. I'd like to avoid doing the full
open and mmap if
If you want to change the vma ops table you can replace the f_ops
table with your own one. SYSV ipc uses this also to be able to catch
unmaps.
I'd thought of that, but that means I need to concoct an f_ops table of my own
for every f_ops table I might have to override. All I want to do is
Linus Torvalds [EMAIL PROTECTED] wrote:
I think Andrea is right. Although this file seems to be entirely
old-fashioned and should never be used, right?
I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of times),
About the benchmark you wrote it looks good measure to me, thanks.
As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I've attached two slightly different bits of i386 assembly that achieve the
same end, but in slightly different ways. Can some one tell me why Case 1 is
faster than Case 2? Case 1 involves an extra CALL instruction.
* Case 1 has a little wrapper function that saves ECX and EDX before
David S. Miller [EMAIL PROTECTED] wrote:
D.W.Howells writes:
This patch (made against linux-2.4.4-pre4) gets rid of some warnings obtained
when using the generic rwsem implementation.
Have a look at pre5, this is already fixed.
Not entirely so...
There's also a missing "struct
David Woodhouse [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] said:
[BTW, another solution is to truly support opaque handles to kernel
objects; I believe David Howells is already working on something like
this for Wine?
Yes. However, it uses a different system call set to use them
Alon Ziv [EMAIL PROTECTED] wrote:
Obviously... since they're handles, not FDs...
[BTW, are you using Windows' idea of storing the objects in process space,
in a page that's inaccessible to the app itself, and passing pointers into
this page as the handles?]
No... I grab a page in kernel
Ok I finished now my asm optimized rwsemaphores and I improved a little my
spinlock based one but without touching the icache usage.
And I can break it. There's a very good reason the I changed __up_write() to
use CMPXCHG instead of SUBL. I found a sequence of operations that locked up
on
/include/linux/rwsem-spinlock.hTue Apr 24 08:40:20 2001
@@ -1,6 +1,8 @@
/* rwsem-spinlock.h: fallback C implementation
*
* Copyright (c) 2001 David Howells ([EMAIL PROTECTED]).
+ * - Derived partially from ideas by Andrea Arcangeli [EMAIL PROTECTED]
+ * - Derived also from comments
I'd love to hear this sequence. Certainly regression testing never generated
this sequence yet but yes that doesn't mean anything. Note that your slow
path is very different than mine.
One of my testcases fell over on it...
I don't feel the need of any xchg to enforce additional
I see what you meant here and no, I'm not lucky, I thought about that. gcc x
2.95.* seems smart enough to produce (%%eax) that you hardcoded when the
sem is not a constant (I'm not clobbering another register, if it does it's
stupid and I consider this a compiler mistake).
It is a compiler
so you reproduced a deadlock with my patch applied, or you are saying
you discovered that case with one of you testcases?
It was my implementation that triggered it (I haven't tried it with yours),
but the bug occurred because the SUBL happened to make the change outside of
the spinlocked
Linus Torvalds [EMAIL PROTECTED] wrote:
- nobody will look up the list because we do have the spinlock at this
point, so a destroyed list doesn't actually _matter_ to anybody
I suppose that it'll be okay, provided I take care not to access a block for a
task I've just woken up.
-
Andrea Arcangeli [EMAIL PROTECTED] wrote:
It seems more similar to my code btw (you finally killed the useless
chmxchg ;).
CMPXCHG ought to make things better by avoiding the XADD(+1)/XADD(-1) loop,
however, I tried various combinations and XADD beats CMPXCHG significantly.
Here's a quote
Cheers,
David Howells
-
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/
Hello Ivan,
One reason I picked signed long as the count type in the lib/rwsem.c is that
this would be 64 bits on a 64-bit arch such as the alpha.
So I've taken your idea for include/asm-alpha/rwsem.h and modified it a
little. You'll find it attached at the bottom.
I don't know whether it will
What arch are you compiling for? i386?
When I compiled bzImage (using .config from 2.2.3) I got the following
errors:
Did you run one of the make config commands before building the kernel? You
may need to do this to flush the changes from arch/*/config.in into .config.
David
-
To
I have an idea for getting around this problem, but it's only half implemented
at the moment (I use it for implementing a Wine server in the kernel). It
involves having a list things called task ornaments attached to each
process. Each ornament has a table of event notification methods (so it can
be greatly appreciated.
The example code I've written can be downloaded from:
ftp://infradead.org/pub/people/dwh/ioaccess.tar.bz2
Cheers,
David Howells
[EMAIL PROTECTED]
___
I/O ACCESS
Run the following script (It's been tried on linux-2.2.x and linux-2.4.x):
#!/bin/sh
cd /tmp
mkdir x
cd x
mkdir x y z
strace -etrace=rename,mkdir,rmdir,chmod mv x z
echo -
chmod -w y
strace -etrace=rename,mkdir,rmdir,chmod mv y z
The output:
rename("x", "z/x") = 0
More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1
source tree.
Linus Torvalds [EMAIL PROTECTED] wrote:
Actually, I'd rather leave it in, but speed it up with the saner and
faster
if (bh-b_size (correct_size-1)) {
I presume that correct_size will always be a power of 2...
David
-
To unsubscribe from this list: send the line "unsubscribe
I had problems with XFree86 4.0 and 4.0.1 locking solidly up under Linux 2.4.x
after about 10mins until I upgraded to XFree86 4.0.2. Now it seems rock solid.
XFree86 3.3.x was always okay.
I've got a Dual-PII machine and an NVidia GeForce.
David
-
To unsubscribe from this list: send the line
How this for a laugh:
http://www.microsoft.com/WINDOWS2000/hpc/indstand.asp
David
-
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
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented and seems
to change almost on a week-by-week basis anyway. I've done my share of chasing
the current kernel revision with drivers that aren't part of
I've found a bug in the write path of the read/write semaphore stuff (at least
for the i386 arch). The attached kernel module (rwsem.c) and driver program
(driver.c) demonstrate it.
What happens is that once the driver finishes, you end up with a whole load of
processes forked off of driver that
Since you're willing to use CMPXCHG in your suggested implementation, would it
make it make life easier if you were willing to use XADD too?
Plus, are you really willing to limit the number of readers or writers to be
32767? If so, I think I can suggest a way that limits it to ~65535 apiece
as well as write locks and a revised driver program (driver.c) that
can use rwsem.c. Try the following tests:
driver -200 driver 200 # fork 200 writers and then 200 readers
driver 200 driver -200 # fork 200 readers and then 200 writers
David Howells
diff -uNr linux-2.4.3/arch
Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
David
-
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/
readers
+just woken,
+* less one for the activity decrement we've already done
+*/
+ woken = wake_up_ctx(sem-wait,65535,-RWSEM_WAITING_FOR_READ);
+ if (woken0) {
+ woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS;
+ woken -= RWSEM_ACTIVE_BIA
I'd like you to look over it. It seems newer GCC's (snapshots and the
upcoming 3.0) will be more strict when modifying some values through
assembler-passed pointers - in this case, the passed semaphore structure got
freed too early, causing massive stack corruption on early bootup.
The
I've been discussing it with some other kernel and GCC people, and they think
that only "memory" is required.
What are the reasons against mentioning sem-count directly as a "=m"
reference? This makes the whole thing less fragile and no more dependent
on the memory layout of the structure.
already done
+*/
+ woken = wake_up_ctx(sem-wait,65535,-RWSEM_WAITING_FOR_READ);
+ if (woken0) {
+ woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS;
+ woken -= RWSEM_ACTIVE_BIAS;
+ rwsem_atomic_update(woken,sem);
+ }
+ else {
Andrew Morton wrote:
I think that's a very good approach. Sure, it's suboptimal when there
are three or more waiters (and they're the right type and order). But
that never happens. Nice design idea.
Cheers.
These numbers are infinity :)
I know, but I think Linus may be happy with the
You need sterner testing stuff :) I hit the BUG at the end of rwsem_wake()
in about a second running rwsem-4. Removed the BUG and everything stops
in D state.
Grab rwsem-4 from
http://www.uow.edu.au/~andrewm/linux/rwsem.tar.gz
It's very simple. But running fully in-kernel
CTIVE_BIAS-RWSEM_WAITING_BIAS;
+ woken -= RWSEM_ACTIVE_BIAS;
+ rwsem_atomic_update(woken,sem);
-struct rw_semaphore *rwsem_wake_writer(struct rw_semaphore *sem)
-{
- if (xchg(sem-write_bias_granted, 1))
- BUG();
- wake_up(sem-write_bias_wait);
+ out:
+ rwsemd
goto try_again;
- goto out;
-}
-
/*
* rw spinlock fallbacks
*/
diff -uNr linux-2.4.4-pre2/arch/i386/lib/Makefile linux/arch/i386/lib/Makefile
--- linux-2.4.4-pre2/arch/i386/lib/Makefile Thu Apr 12 08:57:23 2001
+++ linux/arch/i386/lib/MakefileThu Apr 1
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
(the generic rwsemaphores in those kernels is broken, try to use them in
other archs or x86 and you will notice) and I
Robin Getz [EMAIL PROTECTED] wrote:
David - Does this give you what you need?
Possibly. I'll have a look at it tomorrow.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
-mode.
David
---
[PATCH] NOMMU: Support mmap() on AF_PACKET sockets
From: David Howells [EMAIL PROTECTED]
Support mmap() on AF_PACKET sockets in NOMMU-mode kernels.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/net.h|7 +++
include/net/sock.h |8 +++
net/core
Eric W. Biederman [EMAIL PROTECTED] wrote:
This patch modifies the startup of kafscmd, kafsasyncd, and kafstimod
to use kthread_run instead of a combination of kernel_thread and
daemonize making the code slightly simpler and more maintainable.
Please drop this patch for the moment as I have
Eric W. Biederman [EMAIL PROTECTED] wrote:
This patch modifies the startup of krxtimod, krxiod, and krxsecd
to use kthread_run instead of a combination of kernel_thread
and daemonize making the code slightly simpler and more maintainable.
Again, please drop in favour of my RxRPC patches.
Aubrey Li [EMAIL PROTECTED] wrote:
Yes, it's reasonable for me, as long as your
host IP is 192.168.2.128
and
target IP is 192.168.2.141
That is correct, yes:-)
I expect it's an NFS packet as my board is using an NFS root at the moment.
David
-
To unsubscribe from this list:
Eric W. Biederman [EMAIL PROTECTED] wrote:
What is the ETA on your patches?
That depends on Dave Miller now, I think. I'm assuming they need to go
through the network GIT tree to get to Linus. Certainly Andrew Morton seems
to think so.
David
-
To unsubscribe from this list: send the line
Eric W. Biederman [EMAIL PROTECTED] wrote:
Ok. I don't see any patches in -mm so I was assuming these patches have
not been queued up anywhere.
They haven't been quite yet. Is it your intention to kill these features in
2.6.22?
David
-
To unsubscribe from this list: send the line
Andrew Morton [EMAIL PROTECTED] wrote:
Do those patches convert all this code over to full use of the kthread
API? Because it seems that a conversion would be straightforward, and
is needed.
No. They delete all that code entirely and use workqueues instead. So, I
suppose merging Eric's
Aubrey Li [EMAIL PROTECTED] wrote:
The patch works properly on my side. But
1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't
the current implement work for NOMMU? I know you want to allocate the
entire data buffer as one contiguous lump, but is it really necessary?
Yes.
David Miller [EMAIL PROTECTED] wrote:
I applied already the patches I thought were appropriate,
you had some crypto layer changes that you need to work
out with Herbert Xu before the rest can be applied.
Should the rest of it go via Andrew's tree then?
David
-
To unsubscribe from this list:
Aubrey Li [EMAIL PROTECTED] wrote:
as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE,
packet_set_ring
if (unlikely(req-tp_block_size (PAGE_SIZE - 1)))
So why not use __get_free_pages rather than kmalloc,
Because
David Miller [EMAIL PROTECTED] wrote:
Now that Herbert cleared up the crypto layer issues
the only problem left is that there are generic changes
in there which are not strictly networking but which
your subsequent networking changes depend upon.
This is a mess, and makes merging your work
Eric Dumazet [EMAIL PROTECTED] wrote:
Is it really possible to allocate an order-10 page, then release part of it
(say an order-8 subpage) ?
Yes.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
We only care when del_timer() returns true. In that case, if the timer
function still runs (possible for single-threaded wqs), it has already
passed __queue_work().
Why do you assume that?
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Oleg Nesterov [EMAIL PROTECTED] wrote:
We only care when del_timer() returns true. In that case, if the timer
function still runs (possible for single-threaded wqs), it has already
passed __queue_work().
Why do you assume that?
Sorry, I should have been more clear. I meant the
Oleg Nesterov [EMAIL PROTECTED] wrote:
Let's look at (2). cancel_delayed_work() (on top of del_timer()) returns 0,
and this is correct, we failed to cancel the timer, and we don't know whether
work-func() finished, or not.
Yes.
The current code uses del_timer_sync(). It will also return 0.
Oleg Nesterov [EMAIL PROTECTED] wrote:
The current code uses del_timer_sync(). It will also return 0. However,
it will spin waiting for timer-function() to complete. So we are just
wasting CPU.
That's my objection to using cancel_delayed_work() as it stands, although in
most cases
Oleg Nesterov [EMAIL PROTECTED] wrote:
Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
this change should be completely transparent for all users. Otherwise, it
is buggy.
I guess you will have to make sure that cancel_delayed_work() is always
followed by a flush of
1 - 100 of 13793 matches
Mail list logo
