On Thu, 26 Mar 2015, David Rientjes wrote:
> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> hugetlb vma is long standing and there may be applications that break as a
> result of changing the behavior: a database that reserves all allocated
> hugetlb memory with
On Wed, 25 Mar 2015, David Rientjes wrote:
> I looked at this thread at http://marc.info/?t=14139250881 since I
> didn't have it in my mailbox, and I didn't get a chance to actually run
> your test code.
>
> In short, I think what you're saying is that
>
> ptr = mmap(..., 4KB, ...,
On Wed, 25 Mar 2015, David Rientjes wrote:
I looked at this thread at http://marc.info/?t=14139250881 since I
didn't have it in my mailbox, and I didn't get a chance to actually run
your test code.
In short, I think what you're saying is that
ptr = mmap(..., 4KB, ...,
On Thu, 26 Mar 2015, David Rientjes wrote:
Yes, this munmap() behavior of lengths = hugepage_size - PAGE_SIZE for a
hugetlb vma is long standing and there may be applications that break as a
result of changing the behavior: a database that reserves all allocated
hugetlb memory with mmap()
On Wed, 25 Mar 2015, Hugh Dickins wrote:
> When you say "tracking back to 3.2.x", I think you mean you've tried as
> far back as 3.2.x and found the same behaviour, but not tried further?
>
> From the source, it looks like this is unchanged since MAP_HUGETLB was
> introduced in 2.6.32. And is
On Wed, 25 Mar 2015, Hugh Dickins wrote:
When you say tracking back to 3.2.x, I think you mean you've tried as
far back as 3.2.x and found the same behaviour, but not tried further?
From the source, it looks like this is unchanged since MAP_HUGETLB was
introduced in 2.6.32. And is the same
tinkering).
Signed-Off-By: Davide Libenzi
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2528,10 +2528,6 @@ int do_munmap(struct mm_struct *mm, unsigned long start,
size_t len)
if ((start & ~PAGE_MASK) || s
tinkering).
Signed-Off-By: Davide Libenzi davi...@xmailserver.org
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2528,10 +2528,6 @@ int do_munmap(struct mm_struct *mm, unsigned long start,
size_t len)
if ((start
On Tue, 21 Oct 2014, Davide Libenzi wrote:
> Calling mmap with MAP_HUGETLB and a size which is not 2MB aligned, causes
> mmap to fail. Tested on 3.13.x but tracking back to 3.2.x.
A couple of "un" were found under my desk, as it's clearly munmap which is
failing.
- Davide
-
will result in EINVAL.
Tentative (untested) patch and test case attached (be sure you have a few
huge pages available via /proc/sys/vm/nr_hugepages tinkering).
Signed-Off-By: Davide Libenzi
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
will result in EINVAL.
Tentative (untested) patch and test case attached (be sure you have a few
huge pages available via /proc/sys/vm/nr_hugepages tinkering).
Signed-Off-By: Davide Libenzi davi...@xmailserver.org
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm
On Tue, 21 Oct 2014, Davide Libenzi wrote:
Calling mmap with MAP_HUGETLB and a size which is not 2MB aligned, causes
mmap to fail. Tested on 3.13.x but tracking back to 3.2.x.
A couple of un were found under my desk, as it's clearly munmap which is
failing.
- Davide
--
To unsubscribe
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Okay -- I'll look at it some more. I am however loathe to drop the
> term open file description, because POSIX uses, as well as a number of
> other Linux man pages by now.
Heh, POSIX. Now doesn't take a genius to see that "file description" and
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Following up after quite some time:
>
> Davide Libenzi wrote:
> > On Sat, 26 Jan 2008, Michael Kerrisk wrote:
> >
> >> On Jan 25, 2008 12:57 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> >>
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Davide Libenzi wrote:
> > On Sun, 28 Oct 2007, David Schwartz wrote:
> >
> >> Eric Dumazet wrote:
> >>
> >>> Events are not necessarly reported "by descriptors". epoll uses an opaque
> >&
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
Following up after quite some time:
Davide Libenzi wrote:
On Sat, 26 Jan 2008, Michael Kerrisk wrote:
On Jan 25, 2008 12:57 AM, Davide Libenzi [EMAIL PROTECTED] wrote:
On Thu, 24 Jan 2008, Pierre Habouzit wrote:
On Fri, Jan 18, 2008
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
Davide Libenzi wrote:
On Sun, 28 Oct 2007, David Schwartz wrote:
Eric Dumazet wrote:
Events are not necessarly reported by descriptors. epoll uses an opaque
field provided by the user.
It's up to the user to properly chose a tag
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
Okay -- I'll look at it some more. I am however loathe to drop the
term open file description, because POSIX uses, as well as a number of
other Linux man pages by now.
Heh, POSIX. Now doesn't take a genius to see that file description and
file
is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by simplifying the
code to get rid of a few lines that became superfluous after the previous
epoll changes.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
-
On Mon, 11 Feb 2008, Andrew Morton wrote:
> On Sun, 10 Feb 2008 13:32:01 -0800 (PST)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but
> > rb_set_parent() accesses node's pointer in its code.
is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by simplifying the
code to get rid of a few lines that became superfluous after the previous
epoll changes.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs
On Mon, 11 Feb 2008, Andrew Morton wrote:
On Sun, 10 Feb 2008 13:32:01 -0800 (PST)
Davide Libenzi [EMAIL PROTECTED] wrote:
Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but
rb_set_parent() accesses node's pointer in its code. This creates a
warning in kmemcheck
is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by properly
initializing the data.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/eventpoll.c |2 +-
include/linux/rbtree.h | 12
2
is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by properly
initializing the data.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/eventpoll.c |2 +-
include/linux/rbtree.h | 12
2 files
On Thu, 24 Jan 2008, Pierre Habouzit wrote:
> On Fri, Jan 18, 2008 at 09:10:18PM +0000, Davide Libenzi wrote:
> > On Fri, 18 Jan 2008, Pierre Habouzit wrote:
> >
> > > Hi,
> > >
> > > I just came across a strange behavior of epoll that seems t
On Thu, 24 Jan 2008, Pierre Habouzit wrote:
On Fri, Jan 18, 2008 at 09:10:18PM +, Davide Libenzi wrote:
On Fri, 18 Jan 2008, Pierre Habouzit wrote:
Hi,
I just came across a strange behavior of epoll that seems to
contradict the documentation. Here is what happens
inst Fedora's 2.6.23-0.222.rc9.git4.fc8, filed in
> > October: https://bugzilla.redhat.com/show_bug.cgi?id=323411
>
> Upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=9786
>
> Date: Sun, 13 Jan 2008 19:44:26 +0100
> From: Peter Zijlstra <[EMAIL PROTECTED]>
>
On Tue, 22 Jan 2008, Stefan Richter wrote:
> (adding Cc: Davide and akpm)
>
> On 22 Jan, Peter Zijlstra wrote:
> >
> > On Tue, 2008-01-22 at 17:23 +0100, Stefan Richter wrote:
> >> Denys Fedoryshchenko wrote:
> >> > No, i am using vanilla kernel. It is one of production machines, and as
> >> >
On Tue, 22 Jan 2008, Stefan Richter wrote:
(adding Cc: Davide and akpm)
On 22 Jan, Peter Zijlstra wrote:
On Tue, 2008-01-22 at 17:23 +0100, Stefan Richter wrote:
Denys Fedoryshchenko wrote:
No, i am using vanilla kernel. It is one of production machines, and as
i
know screen
in
October: https://bugzilla.redhat.com/show_bug.cgi?id=323411
Upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=9786
Date: Sun, 13 Jan 2008 19:44:26 +0100
From: Peter Zijlstra [EMAIL PROTECTED]
On Sat, 2008-01-05 at 13:35 -0800, Davide Libenzi wrote:
I remember I talked with Arjan
On Fri, 18 Jan 2008, Pierre Habouzit wrote:
> Hi,
>
> I just came across a strange behavior of epoll that seems to
> contradict the documentation. Here is what happens:
>
> * I have two processes P1 and P2, P1 accept()s connections, and send the
> resulting file descriptors to P2 through
On Fri, 18 Jan 2008, Pierre Habouzit wrote:
Hi,
I just came across a strange behavior of epoll that seems to
contradict the documentation. Here is what happens:
* I have two processes P1 and P2, P1 accept()s connections, and send the
resulting file descriptors to P2 through a unix
On Thu, 10 Jan 2008, Rusty Russell wrote:
> On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > > The latter. A ring is optimal for processing a huge number of requests,
> > > but if you're really going to be firing off syslet threads all over the
> > > place you're not going to be
On Thu, 10 Jan 2008, Rusty Russell wrote:
On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
The latter. A ring is optimal for processing a huge number of requests,
but if you're really going to be firing off syslet threads all over the
place you're not going to be optimal anyway.
On Tue, 8 Jan 2008, Eric Dumazet wrote:
> Changli Gao a écrit :
> > Replace the epitem rbtree with a dynamic array to get the constant
> > insertion/deletion/modification time of the file descriptors. Reuse the
> > size argument of epoll_create, however the size must be smaller than the
> >
On Tue, 8 Jan 2008, Eric Dumazet wrote:
Changli Gao a écrit :
Replace the epitem rbtree with a dynamic array to get the constant
insertion/deletion/modification time of the file descriptors. Reuse the
size argument of epoll_create, however the size must be smaller than the
max file
On Sun, 6 Jan 2008, Christian Kujau wrote:
> On Sat, 5 Jan 2008, Davide Libenzi wrote:
> > A solution may be to move the call to ep_poll_safewake() (that'd become a
> > simple wake_up()) inside a tasklet or whatever is today trendy for delayed
> > work. But his kinda scares m
On Sun, 6 Jan 2008, Christian Kujau wrote:
On Sat, 5 Jan 2008, Davide Libenzi wrote:
A solution may be to move the call to ep_poll_safewake() (that'd become a
simple wake_up()) inside a tasklet or whatever is today trendy for delayed
work. But his kinda scares me to be honest, since epoll
On Sat, 5 Jan 2008, Peter Zijlstra wrote:
>
> On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote:
> > On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote:
> > > On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > > > [ 1310.670986]
On Sat, 5 Jan 2008, Peter Zijlstra wrote:
On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote:
On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote:
On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
[ 1310.670986] =
Make the returned time to be the remaining time till the next expiration.
If the timer is already expired, and there's no next expiration, zero will
be returned.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
-
() ticks
calculation, ktime_divns(), was already having the result in u64 and it was
chopping it to unsigned long.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/timerfd.c|6 +++---
include
On Mon, 17 Dec 2007, Michael Kerrisk wrote:
> > Can you try the two patches below? I tried them on my 32 bit box (one of
> > the rare beasts still lingering around here) and it seems to be working
> > fine (those go on top of the previous ones).
>
> Against 2.6.24-rc5, I applied first your
On Mon, 17 Dec 2007, Michael Kerrisk wrote:
Can you try the two patches below? I tried them on my 32 bit box (one of
the rare beasts still lingering around here) and it seems to be working
fine (those go on top of the previous ones).
Against 2.6.24-rc5, I applied first your earlier
() ticks
calculation, ktime_divns(), was already having the result in u64 and it was
chopping it to unsigned long.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/timerfd.c|6 +++---
include/linux
Make the returned time to be the remaining time till the next expiration.
If the timer is already expired, and there's no next expiration, zero will
be returned.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs
On Fri, 14 Dec 2007, Michael Kerrisk wrote:
> You snipped my example that demonstrated the problem. Both of the
> following runs create a timer that expires 10 seconds from "now", but
> observe the difference in the value returned by timerfd_gettime():
>
> $ ./timerfd_test 10 # does not
On Fri, 14 Dec 2007, Michael Kerrisk wrote:
You snipped my example that demonstrated the problem. Both of the
following runs create a timer that expires 10 seconds from now, but
observe the difference in the value returned by timerfd_gettime():
$ ./timerfd_test 10 # does not use
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
> > > BUG 2:
> > > The last sentence does not match the implementation.
> > > (Nor is it consistent with the behavior of POSIX timers.
> > > And I *think* things did work correctly in the original
> > > timerfd() implementation, but I have not gone back
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
> Davide, Andrew,
>
> I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
> 2.4.24-rc3, and did various tests (all on x86). Several tests
> were done using the program at the foot of this mail. Various others
> were done by cobbling
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
Davide, Andrew,
I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
2.4.24-rc3, and did various tests (all on x86). Several tests
were done using the program at the foot of this mail. Various others
were done by cobbling together
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
BUG 2:
The last sentence does not match the implementation.
(Nor is it consistent with the behavior of POSIX timers.
And I *think* things did work correctly in the original
timerfd() implementation, but I have not gone back to check.)
On Thu, 6 Dec 2007, Oleg Nesterov wrote:
> The previous bugfix was not optimal, we shouldn't care about group stop when
> we are the only thread or the group stop is in progress. In that case nothing
> special is needed, just set PF_EXITING and return.
>
> Also, take the related "TIF_SIGPENDING
On Thu, 6 Dec 2007, Oleg Nesterov wrote:
The previous bugfix was not optimal, we shouldn't care about group stop when
we are the only thread or the group stop is in progress. In that case nothing
special is needed, just set PF_EXITING and return.
Also, take the related TIF_SIGPENDING
uch this change costs?
Anyway, looks sane to me...
Acked-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
--
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/
().
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
Looks OK for me, even though we're doing more work on the exit path. OTOH
I don't see a non-racy way of doing it w/out grabbing the lock. Did you
try to bench how much this change costs?
Anyway, looks sane to me...
Acked-by: Davide Libenzi
Update sys_ni.c with the new timerfd syscalls.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
kernel/sys_ni.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.mod/kernel/sy
On Wed, 28 Nov 2007, Andrew Morton wrote:
> On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > > Kernel build fails, with build error
> > >
> > > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > >
On Wed, 28 Nov 2007, Andrew Morton wrote:
On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann [EMAIL PROTECTED] wrote:
On Wednesday 28 November 2007, Kamalesh Babulal wrote:
Kernel build fails, with build error
CC arch/powerpc/platforms/cell/spu_callbacks.o
In file included
Update sys_ni.c with the new timerfd syscalls.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
kernel/sys_ni.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.mod/kernel/sys_ni.c
On Tue, 27 Nov 2007, Andrew Morton wrote:
> On Tue, 27 Nov 2007 12:47:46 -0800 (PST)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 27 Nov 2007, Andrew Morton wrote:
> >
> > > On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi <[EMAIL PROTECTED
On Tue, 27 Nov 2007, Andrew Morton wrote:
> On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > +static struct file *timerfd_fget(int fd)
> > +{
> > + struct file *file;
> > +
> > + file = fget(fd);
> > +
On Tue, 27 Nov 2007, Andrew Morton wrote:
On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi [EMAIL PROTECTED] wrote:
+static struct file *timerfd_fget(int fd)
+{
+ struct file *file;
+
+ file = fget(fd);
+ if (!file)
+ return ERR_PTR(-EBADF);
+ if (file-f_op
On Tue, 27 Nov 2007, Andrew Morton wrote:
On Tue, 27 Nov 2007 12:47:46 -0800 (PST)
Davide Libenzi [EMAIL PROTECTED] wrote:
On Tue, 27 Nov 2007, Andrew Morton wrote:
On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi [EMAIL PROTECTED]
wrote:
+static struct file *timerfd_fget
On Mon, 26 Nov 2007, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> >
> > So it's not like sys_indirect() would break some magic pristine state of a
> > flat parameter space - on the contrary, most of the nontrivial syscalls take
> > pointers to structures or pointers to streams of information.
On Mon, 26 Nov 2007, H. Peter Anvin wrote:
Ingo Molnar wrote:
So it's not like sys_indirect() would break some magic pristine state of a
flat parameter space - on the contrary, most of the nontrivial syscalls take
pointers to structures or pointers to streams of information. The
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unist
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
I think that advancing the timer against the timer's current "now" can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/linux/hrtimer.h |
been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
-
I think that advancing the timer against the timer's current now can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
include/linux/hrtimer.h |7 +++
1 file
implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/compat.c | 32 ++-
fs
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unistd_64.h
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.orig/init
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
> > +asmlinkage long sys_timerfd_create(int clockid, int flags)
> > {
> > - int error;
> > + int error, ufd;
> > struct timerfd_ctx *ctx;
> > struct file *file;
> > struct inode *inode;
> > - struct itimerspec ktmr;
> > -
> > - if
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
+asmlinkage long sys_timerfd_create(int clockid, int flags)
{
- int error;
+ int error, ufd;
struct timerfd_ctx *ctx;
struct file *file;
struct inode *inode;
- struct itimerspec ktmr;
-
- if (copy_from_user(ktmr,
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unist
I think that advancing the timer against the timer's current "now" can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/linux/hrtimer.h |
been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
-
On Fri, 23 Nov 2007, Ulrich Drepper wrote:
> On Nov 23, 2007 9:29 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > Yes, it's disabled, and yes, I'll repost today ...
>
> I haven't seen the patch and don't feel like searching. So I say it
> here: please mak sure y
On Fri, 23 Nov 2007, Andrew Morton wrote:
> > I suppose this means that timerfd will only go in for 2.6.25. I don't
> > have a problem with that, but we better make sure that the existing
> > timerfd in 2.6.24 is still disabled. (Andrew had a one liner for
> > that, but I haven't checked if
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.orig/init
I think that advancing the timer against the timer's current now can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
include/linux/hrtimer.h |7 +++
1 file
On Fri, 23 Nov 2007, Andrew Morton wrote:
I suppose this means that timerfd will only go in for 2.6.25. I don't
have a problem with that, but we better make sure that the existing
timerfd in 2.6.24 is still disabled. (Andrew had a one liner for
that, but I haven't checked if it's in
On Fri, 23 Nov 2007, Ulrich Drepper wrote:
On Nov 23, 2007 9:29 AM, Davide Libenzi [EMAIL PROTECTED] wrote:
Yes, it's disabled, and yes, I'll repost today ...
I haven't seen the patch and don't feel like searching. So I say it
here: please mak sure you add a flags parameter to the system
implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/compat.c | 32 ++-
fs
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unistd_64.h
On Thu, 22 Nov 2007, Andrew Morton wrote:
> On Thu, 22 Nov 2007 11:46:13 -0800 (PST) Davide Libenzi <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> >
> > > On Nov 22, 2007 6:34 PM, Davide Libenzi <[EMAIL PROTECTED]> w
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> On Nov 22, 2007 6:34 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> >
> > > Hey Davide,
> > >
> > > Where is the new timerfd API. In 2.6.24-rc3, I s
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> Hey Davide,
>
> Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
Maybe Andrew stuffed the turkey with it? :) It was there. I remeber it was
merged. Some screw up reverted it?
- Davide
-
To unsubscribe from this list: send
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
Hey Davide,
Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
Maybe Andrew stuffed the turkey with it? :) It was there. I remeber it was
merged. Some screw up reverted it?
- Davide
-
To unsubscribe from this list: send the
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
On Nov 22, 2007 6:34 PM, Davide Libenzi [EMAIL PROTECTED] wrote:
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
Hey Davide,
Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
Maybe Andrew stuffed the turkey
On Thu, 22 Nov 2007, Andrew Morton wrote:
On Thu, 22 Nov 2007 11:46:13 -0800 (PST) Davide Libenzi [EMAIL PROTECTED]
wrote:
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
On Nov 22, 2007 6:34 PM, Davide Libenzi [EMAIL PROTECTED] wrote:
On Thu, 22 Nov 2007, Michael Kerrisk wrote
On Tue, 20 Nov 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > It seems that you're doing the same thing in both cases, except you're
> > now extending it to include other random functionality, which means
> > other things than syslets are suddenly affected.
> >
>
On Tue, 20 Nov 2007, Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
It seems that you're doing the same thing in both cases, except you're
now extending it to include other random functionality, which means
other things than syslets are suddenly affected.
syslets are
On Sun, 28 Oct 2007, David Schwartz wrote:
>
> Eric Dumazet wrote:
>
> > Events are not necessarly reported "by descriptors". epoll uses an opaque
> > field provided by the user.
> >
> > It's up to the user to properly chose a tag that will makes sense
> > if the user
> > app is playing
On Sun, 28 Oct 2007, David Schwartz wrote:
Eric Dumazet wrote:
Events are not necessarly reported by descriptors. epoll uses an opaque
field provided by the user.
It's up to the user to properly chose a tag that will makes sense
if the user
app is playing dup()/close() games for
On Sat, 27 Oct 2007, David Schwartz wrote:
> I don't see how that can be. Suppose I add fd 8 to an epoll set.
> Suppose fd
> 5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set,
> since there no longer is an fd 8? Events on files registered for epoll
> notification
On Sat, 27 Oct 2007, David Schwartz wrote:
I don't see how that can be. Suppose I add fd 8 to an epoll set.
Suppose fd
5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set,
since there no longer is an fd 8? Events on files registered for epoll
notification are
1 - 100 of 1521 matches
Mail list logo
