Hi...
I have a problem with nfs. It always worked, so I don't know what is
failing now.
I have a server running 2.6.11-rc3-mm2. I try to export a dir via nfs:
/etc/exports:
/raid belly.cps.unizar.es(ro,insecure,no_root_squash,no_subtree_check)
nada:/proc/fs/nfs# exportfs -v
On Thu, 2005-02-24 at 07:41 +0100, Guillaume Thouvenin wrote:
> On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > > Please assume that > > originally written for> will always be listening.
> > >
> > > > > What happened to the idea of sending an on/off message down the
> > > > > netli
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > Please assume that > originally written for> will always be listening.
> >
> > > > What happened to the idea of sending an on/off message down the netlink
> > > > socket?
> > ...
> > Arrange for the userspace daemon to send a message t
On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 23 Feb 2005 01:07:47 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Feb 2005 01:07:47 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > This patch replaces the relay_fork module and it implements a fork
> > > connector in
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > This patch replaces the relay_fork module and it implements a fork
> > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > in
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> This patch replaces the relay_fork module and it implements a fork
> connector in the kernel/fork.c:do_fork() routine. The connector sends
> information about parent PID and child PID over a netlink interface. It
> allows to several u
ux/connector.h |2 ++
kernel/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kc
Guillaume wrote:
>
> I understand your point of view but I'm using netlink interface
> because it's already in the kernel so my choice is to use something that
> is already in the kernel instead of adding dozens of new instructions
> and also to do things in user space.
All else equal, yes it is
On Monday 21 February 2005 15:43, Guillaume Thouvenin wrote:
>
> I also choose this implementation because Erich Focht wrote in the
> email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about
> the creation of processes "sounds very useful for a lot of interesting
> stuff". So I tho
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a netlink interface. It allows to several
> > user space applications
Thank-you for your quick answer.
Guillaume wrote:
>
> If a process belongs to several group of processes, an new integer in
> the task_struct is not enough, you need a list or something like this.
> If you're using a list you need to add function to manage this list in
> the kernel but we don't wa
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The problem is the following: I have a user space daemon that manages
> > group of processes. The main idea is, if a parent belongs to a group
> > then its child belongs to the same group. To achieve this I need to know
Guillaume wrote:
> The problem is the following: I have a user space daemon that manages
> group of processes. The main idea is, if a parent belongs to a group
> then its child belongs to the same group. To achieve this I need to know
> when a fork occurs and which processes are involved. I don't
On Mon, 2005-02-21 at 09:05 +0100, Guillaume Thouvenin wrote:
> On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> > >
> > > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
> >
> > I suspect CONFIG_FORK_CONNECTOR is enough.
>
> The problem here is that if connector is
listens, a message is send. I
> > > don't know how to avoid that. I added an option (FORK_CONNECTOR) to
> > > enable the fork connector (or disable) when compiling the kernel. To
> > > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> &
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> >
> > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
>
> I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
K_CONNECTOR) to
> > enable the fork connector (or disable) when compiling the kernel. To
> > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> > has been tested on a 2.6.11-rc3-mm2 kernel with two user space
> > applications connected.
>
> When running a Posix conformance test (from posixtestsuite), the kernel
> locks up with:
>
> BUG: soft lockup detected on CPU#0
>
> Pid: 1873, comm: 10-1.test
> EIP: 0060:[] CPU: 0
> EIP is at sys_timer_settime+0xfa+0x1f0
> EFLAGS: 00000282 Not tainted (2.6.11-r
2.6.11-rc3-mm2/arch/ppc/kernel/misc.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
--- linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 2005-02-20 12:39:29.0
+0100
+++
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
2005
perfctr-2.7.10 update, 3/4:
- Update x86_64 syscall table for perfctr-2.7.10 API changes.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
include/asm-x86_64/unistd.h |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/include/asm-
/linux/perfctr.h | 19 ++-
kernel/sys_ni.c |3
4 files changed, 159 insertions(+), 98 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
--- linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
de/asm-x86_64/ia32_unistd.h |7 +++
4 files changed, 8 insertions(+), 12 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S
--- linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S 2005-02-20
I found the following in my logs:
<-- snip -->
Feb 19 15:46:05 r063144 kernel: smb_get_length: Invalid NBT packet, code=86
Feb 19 15:46:35 r063144 kernel: smb_add_request: request [d5242d40, mid=50934]
timed out!
Feb 19 15:46:35 r063144 kernel: BUG: atomic counter underflow at:
Feb 19 15:46:35
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX: 0001 ECX
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:
> Fix the damn locking, already.
Fast as I can.
Robert Love
-
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
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
> inotify, bitches
/me does "pick a random function, find a race" again.
> +/*
> + * inode_add_watch - add a watch to the given inode
> + *
> + * Callers must hold dev->lock, because we call inode_find_dev().
> + */
> +static int inode
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
> Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
arch/sparc64/Kconfig | 13
dri
t. I added an option (FORK_CONNECTOR) to
> enable the fork connector (or disable) when compiling the kernel. To
> work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> has been tested on a 2.6.11-rc3-mm2 kernel with two user space
> applications connected.
>
>
main drawback is that even if nobody listens, a message is send. I
don't know how to avoid that. I added an option (FORK_CONNECTOR) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.
On Mon, Feb 14, 2005 at 09:26:49AM +0100, Guillaume Thouvenin wrote:
>
> I'm using kobject because it allows to notify user space application by
> sending an event and as I need to send a kernel event (fork event) to a
> user space application I thought about kobject. Do you think that it's
> not
version: 2.6.11-rc3-mm2
# Fri Feb 11 08:56:56 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
#
On Mon, 2005-02-14 at 13:01 +0100, Guillaume Thouvenin wrote:
> This patch removes unreachable code in cn_netlink_send() function.
The code can be reach via
nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
So the patch is wrong
Sorry for that
Guillaume
-
To unsubscribe from
This patch removes unreachable code in cn_netlink_send() function.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
--- drivers/connector/connector.c.orig 2005-02-14 12:52:32.0 +0100
+++ drivers/connector/connector.c 2005-02-14 12:52:44.0 +0100
@@ -119,11 +119,6 @@ vo
On Fri, 2005-02-11 at 11:11 -0800, Greg KH wrote:
> > + char *kobj_path = NULL;
> > + char *action_string = NULL;
> > + char **envp = NULL;
> > + char ppid_string[FORK_BUFFER_SIZE];
> > + char cpid_string[FORK_BUFFER_SIZE];
> > +
> > + if (!uevent_sock)
> > + return;
> > +
Ingo Molnar wrote:
> the pro applications will always want to have a 100% guarantee (it
> really sucks to generate a nasty audio click during a live performance)
... and the "generic kernels" distributions use will follow just
as swiftly, as soon as the feature appears stable enough. It even
makes
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>>
>> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>> It seems that nothing else is going to come along and this is completely
>> encapsulated.
>
> Ev
Hi,
Yuval Tanny wrote:
> Andrew Morton wrote:
>>cachefs-filesystem.patch
>> CacheFS filesystem
> ...
as you mention cachefs - know what's the status of supporting nfs?
Or is the project as dead as the mailing-list?
Is there any whole-in-one patch relative to vanilla-sources,
at best including
On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > > Yes. There's also the whole soft limit thing.
> > >
> > > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > > jackd installed and runs it from X unprivileg
On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote:
> On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> > >RT-LSM introduces architectural problems in the form of bogus API. And
> >
> > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> > introduce *any* API wha
On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> >RT-LSM introduces architectural problems in the form of bogus API. And
>
> that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> introduce *any* API whatsoever - it simply allows software to call
> various existing AP
On Fri, Feb 11, 2005 at 04:08:40PM +0100, Guillaume Thouvenin wrote:
> +void kobject_fork(struct kobject *kobj, pid_t parent, pid_t child)
> +{
> +#ifdef CONFIG_KOBJECT_UEVENT
No, provide two different functions. In a header file make it a static
inline function that does nothing if this option i
On Fri, Feb 11, 2005 at 10:53:27AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> > >
> > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > > destroys the careful balance of prior
>RT-LSM introduces architectural problems in the form of bogus API. And
that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
introduce *any* API whatsoever - it simply allows software to call
various existing APIs (mostly from POSIX) and have them not fail as
result of not being r
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > > Yes. There's also the whole soft limit thing.
> >
> > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > jackd installed and runs it from X unprivileged, how does it get the
> > elevated rlimit?
>
> It needs a setuid launche
>introduced. See devfs. And I think the adoption barrier thing is a red
>herring as well: the current users are by and large compiling their
>own RT-tuned kernels.
not true. most people are using kernels built for specialized distros
or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic.
--p
-
In fs/Kconfig,
See "Documentation/filesystems/fscache.txt for more information." and
"See Documentation/filesystems/cachefs.txt for more information."
Should be changed to:
"See Documentation/filesystems/caching/fscache.txt for more
information." and "See Documentation/filesystems/caching/cachef
On Fri, 2005-02-11 at 00:54 -0800, Andrew Morton wrote:
> > I tested this patch on a 2.6.11-rc3-mm2 kernel and there is a little
> > overhead when I compile a Linux kernel:
> >
> >#time sh -c 'make O=/home/guill/build/k2610 bzImage &&
> >
This patch adds the output interface control to VR41xx SIU driver.
And obsolete function for VR41xx SIU is removed.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/casio-e55/setup.c
a/arch/mips/vr41xx/casio-e55/setup.c
--- a-orig/arch/mips/vr
On Fri, 2005-02-11 at 00:54 -0800, Andrew Morton wrote:
> > I tested this patch on a 2.6.11-rc3-mm2 kernel and there is a little
> > overhead when I compile a Linux kernel:
> >
> >#time sh -c 'make O=/home/guill/build/k2610 bzImage &&
> >
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> >
> > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> > can be useful if you _need_ a sched
On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
>
> think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> can be useful if you _need_ a scheduling guarantee due to physical
> constraints, and it
On Fri, Feb 11, 2005 at 10:04:19AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > So the comparison boils down to putting a magic gid in a sysfs
> > file/module parameter or setting an rlimit with standard tools (PAM,
> > etc). I'm really boggled that anyone could p
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> So the comparison boils down to putting a magic gid in a sysfs
> file/module parameter or setting an rlimit with standard tools (PAM,
> etc). I'm really boggled that anyone could prefer the former,
> especially since we had almost this exact debate over
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Read more closely: there are two independent limits in the patch,
> RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
> without SCHED_FIFO.
ok, indeed.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > i disagree that desktop performance tomorrow will necessarily have to
> > utilize SCHED_FIFO. Today's desktop audio applications perform quite
> > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
> > interactivity/latency fixes su
On Fri, Feb 11, 2005 at 09:48:43AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Here's Chris' patch for reference:
> >
> > http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
>
> how does this patch solve the separation of 'negative nice values
gt; awkward. Why not just feed that kobject you have there into
> > kobject_uevent()?
>
> Like Andrew suggested, I wrote a new patch (tested on 2.6.11-rc3-mm2)
> that notifies to user space application the creation of a new process
> when kernel forks by using the kob
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Here's Chris' patch for reference:
>
> http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
how does this patch solve the separation of 'negative nice values' and
'RT priority rlimits'? In one piece of code it handles the rlimit value
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
>
> > I think it's important to recognize that we're trying to address an
> > issue that has a much wider potential audience than pro audio users,
> > and not very far off - what is high end audio performance today will
> > be expected d
On Fri, Feb 11, 2005 at 08:54:17AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Eh? Chris Wright's original rlimits patch was very straightforward
> > [...]
>
> the problem is that it didnt solve the problem (unprivileged user can
> lock up the system) in any way
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
> an "RT priorities rlimit" is still not adequate as a desktop solution,
> because it still allows the box to be locked up. Also, if it turns out
> to be a mistake then it's already codified into the ABI, while RT-LSM is
> much less 'pers
s), which could thus make the RT-LSM
solution pretty safe. Right now Jack has its own watchdog thread which
should solve most of the lockup situations. Lets not overdesign the
solution, especially when we dont yet know how the problem really looks
like.
or an even simpler solution for the lockup pro
inimal way of doing this, although I
> wonder what the limitations are.
>
> Implementation-wise: there's a lot of code there and the interface is a bit
> awkward. Why not just feed that kobject you have there into
> kobject_uevent()?
Like Andrew suggested, I wrote a new patc
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Eh? Chris Wright's original rlimits patch was very straightforward
> [...]
the problem is that it didnt solve the problem (unprivileged user can
lock up the system) in any way. So after it became visible that all the
existing 'dont allow users to lock
On Thu, Feb 10, 2005 at 10:41:28PM -0500, Paul Davis wrote:
> [ the best solution is ]
>
> [ my preferred solution is ... ]
>
> [ it would be better if ... ]
>
> [ this is a kludge and it should be done instead like ... ]
>
> did nobody read what andrew wrote and what JOQ pointed o
On Fri, 2005-02-11 at 17:34 +1100, Peter Williams wrote:
> Nick Piggin wrote:
> > I can't say much about it because I'm not putting my hand up to
> > do anything. Just mentioning that rlimit would be better if not
> > for the userspace side of the equation. I think most were already
> > agreed on
Nick Piggin wrote:
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
[ the best solution is ]
[ my preferred solution is ... ]
[ it would be better if ... ]
[ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after week
)
--- --
2.6.11-rc3-mm2 14w/0e 0w/0e 192w/0e6w/0e 19w/0e172w/0e
2.6.11-rc3-mm1 13w/10e0w/7e 196w/12e 6w/0e 18w/12e 177w/0e
2.6.11-rc2-mm2 15w/0e 0w/0e 201w/0e6w/0e 18w/0e182w/0e
2.6.11-rc2-mm1 15w/0e
Paul Davis wrote:
[ the best solution is ]
[ my preferred solution is ... ]
[ it would be better if ... ]
[ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution e
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
> [ the best solution is ]
>
> [ my preferred solution is ... ]
>
> [ it would be better if ... ]
>
> [ this is a kludge and it should be done instead like ... ]
>
> did nobody read what andrew wrote and what JOQ pointed out?
>
[ the best solution is ]
[ my preferred solution is ... ]
[ it would be better if ... ]
[ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that d
Nick Piggin wrote:
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
What happened to the RT rlimit code from Chris?
I still have it, but I had the impression Ingo didn't like it as a long
t
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
> On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> > * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > > What happened to the RT rlimit code from Chris?
> >
> > I still have it, but I had the impression Ingo didn't like it as a long
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > What happened to the RT rlimit code from Chris?
>
> I still have it, but I had the impression Ingo didn't like it as a long
> term solution/hack (albeit small) to the scheduler. Whereas t
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> What happened to the RT rlimit code from Chris?
I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm
patch is wholly self-contained.
thanks,
-chris
--
Linux Secu
Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > > >
> > > >
> > > > - Added the mlock and !SCHED_OTH
> > Without the aty128fb and radeonfb updates, current 2.6.11 is a
> > regression on pmac as it breaks sleep support on previously working
> > laptops.
>
> Is that worse than the risk of the large patch?
Well, it used to work upstream fine for some time now... The large patch
isn't risky imho, at
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>...
> - Various other stuff. If anyone has a patch in here which they think
> should be in 2.6.11, please let me know. I'm intending to merge the
> following into 2.6.11:
>
> alpha-add-missing-dma_mapping_error.patch
>
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> >
> >
> > - Added the mlock and !SCHED_OTHE
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
>
>
> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> It seems that nothing else is going to c
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
It seems that nothing else is going to come along and this is completely
encapsulated.
- Various other stuff
rg/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > >
> > >
> > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio
> > > guys.
> > > It seems that nothing else is going to come along and this is completel
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> >
> >
> > - Added the mloc
rian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-mm2-full/drivers/char/mxser.c.old 2005-02-10
19:58:36.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/char/mxser.c 2005-02-10
19:58:56.0 +0100
@@ -548,7 +548,6 @@
static int mxser_initbrd(int board, struct mxser_
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> -inotify.patch
> -inotify-fix_find_inode.patch
>
> I think my version is old, and it oopses.
It is old. I have sent you multiple updates. ;-)
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
This
This patch removes TANBAC_TB0219 doubly registered in kernel config.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/Kconfig a/arch/mips/Kconfig
--- a-orig/arch/mips/KconfigThu Feb 10 21:13:55 2005
+++ a/arch/mips/Kconfig Thu Feb 10 22:16:12 2005
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
>
>
> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> It seems that nothing else i
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
It seems that nothing else is going to come along and this is completely
encapsulated.
- Various other stuff. If anyone
89 matches
Mail list logo
