On Fri, 13 Apr 2007 20:08:28 +0200 (CEST) Guennadi Liakhovetski <[EMAIL
PROTECTED]> wrote:
> Hi
>
> Either I've finally gone blind on this Friday 13th or... Looks like this
> almost 3 year old function has a bug. Patch below compile-tested... in a
> way.
>
> Thanks
> Guennadi
> ---
> Guennadi
On Fri, Apr 20, 2007 at 07:52:44PM -0400, Rik van Riel wrote:
> It turns out that Nick's patch does not improve peak
> performance much, but it does prevent the decline when
> running with 16 threads on my quad core CPU!
>
> We _definately_ want both patches, there's a huge benefit
> in having the
On Thu, 19 Apr 2007 09:19:32 +0200 Borislav Petkov <[EMAIL PROTECTED]> wrote:
> +# get kernel version
> +sub get_kernel_version() {
> +my $version;
> +open (FILE, $ENV{"SRCTREE"}."Makefile") || die "Can't open main kernel
> Makefile: $!";
> +
> +EOF: while (my $line = )
> +{
> +
On Thu, 19 Apr 2007 11:06:56 -0400 Josef Bacik <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
> > On Thu, 2007-04-19 at 09:25 -0400, Josef Bacik wrote:
> > > Looking through everything I came to the conclusion that we don't really
> > > need
> > > th
On Fri, 20 Apr 2007, Rik van Riel wrote:
> Andrew Morton wrote:
>
> > I do go on about that. But we're adding page flags at about one per
> > year, and when we run out we're screwed - we'll need to grow the
> > pageframe.
>
> If you want, I can take a look at folding this into the
> ->mapp
Peter Williams wrote:
William Lee Irwin III wrote:
William Lee Irwin III wrote:
On Sat, Apr 21, 2007 at 10:23:07AM +1000, Peter Williams wrote:
If some form of precise timer was used (instead) to trigger
pre-emption then, where there is more than one task with the same
expected "on CPU" time,
On Fri, 20 Apr 2007, Ulrich Drepper wrote:
>
> Just for reference: the MADV_CURRENT behavior is to throw away data in
> the range.
Not exactly. The Linux MADV_DONTNEED never throws away data from a
PROT_WRITE,MAP_SHARED mapping (or shm) - it propagates the dirty bit,
the page will eventually get
On Fri, Apr 20, 2007 at 04:47:27PM -0400, Bill Davidsen wrote:
> Ingo Molnar wrote:
>
> >( Lets be cautious though: the jury is still out whether people actually
> > like this more than the current approach. While CFS feedback looks
> > promising after a whopping 3 days of it being released [
While it annoys even me to keep posting fixes for SD, it is nice that fixing
these bugs improves the behaviour further. This change causes noticeable
improvements with loads that fork (ie make and friends).
Thanks Al!
Andrew please apply.
---
Management of time_slice sharing across fork was broke
* Peter Williams <[EMAIL PROTECTED]> wrote:
> I retract this suggestion as it's a very bad idea. It introduces the
> possibility of starvation via the poor sods at the bottom of the queue
> having their "on CPU" forever postponed and we all know that even the
> smallest possibility of starvat
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Any chance of supporting 2.6.20?
>
> okay, it seems it was less work to backport it to v2.6.20 than it was
> to answer all the "where's the v2.6.20 version?" emails ;-) You can
> download the v2.6.20.7 version of CFS from:
>
> http://redhat.com
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> +static bool permit_umount(struct vfsmount *mnt, int flags)
> +{
>
> ...
>
> + return mnt->mnt_uid == current->uid;
> +}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
would get us a he
On Fri, 20 Apr 2007 12:25:33 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add ownership information to mounts.
>
> A new mount flag, MS_SETUSER is used to make a mount owned by a user.
> If this flag is specified, then the owner will be set to th
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Define a new fs flag FS_SAFE, which denotes, that unprivileged
> mounting of this filesystem may not constitute a security problem.
>
> Since most filesystems haven't been designed with unprivileged
> mounting in mind,
On Fri, 20 Apr 2007 12:25:40 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged
> users. This has also been verified in practice over many years.
How does FUSE do this?
Th
Hi Vitaly,
On Fri, 20 Apr 2007 08:27:14 +0400, Vitaly Bordug wrote:
> Utilized devicetree to store I2C data, ported i2c-algo-8xx.c
> from 2.4 approach(which remains nearly intact), refined i2c-rpx.c.
> I2C functionality has been validated on mpc885ads with EEPROM access.
Thanks for working on thi
On Fri, 20 Apr 2007 12:25:35 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Add sysctl variables for accounting and limiting the number of user
> mounts.
>
> The maximum number of user mounts is set to 1024 by default. This
> won't in itself enable user mounts, setting a mount to be owned by
A significant bugfix for forking tasks was just posted, so here is an updated
version of the staircase deadline cpu scheduler. This may cause noticeable
behavioural improvements under certain workloads (such as compiling software
with make).
Thanks to Al Boldi for making me check the fork code!
Andrew Morton wrote:
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
+static bool permit_umount(struct vfsmount *mnt, int flags)
+{
...
+ return mnt->mnt_uid == current->uid;
+}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
wo
Peter Williams wrote:
Peter Williams wrote:
Ingo Molnar wrote:
your suggestion concentrates on the following scenario: if a task
happens to schedule in an 'unlucky' way and happens to hit a busy
period while there are many idle periods. Unless i misunderstood your
suggestion, that is the main
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add ownership information to mounts.
> >
> > A new mount flag, MS_SETUSER is used to make a mount owned by a user.
> > If this flag is specified, then the owner will be set to the current
> > real user id and the mount will be marked with the M
> > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > +{
> >
> > ...
> >
> > + return mnt->mnt_uid == current->uid;
> > +}
>
> Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
> would get us a heck of a lot closer to being able to support aliasing of
> UI
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > Define a new fs flag FS_SAFE, which denotes, that unprivileged
> > mounting of this filesystem may not constitute a security problem.
> >
> > Since most filesystems haven't been designed with unprivileged
> > mou
Christoph Lameter wrote:
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page->mapping is still
set after locking. Is there a reason for
> > Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
> >
> > FUSE was designed from the beginning to be safe for unprivileged
> > users. This has also been verified in practice over many years.
>
> How does FUSE do this?
>
> There are obvious cases like crafting a filesystem which has set
On Fri, 20 Apr 2007 16:04:04 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> Having selected an area at the end of the inactive list, reclaim is
> attempted for all LRU pages within that contiguous area. Currently,
> any pages in this area found to still be active or referenced are
> rotated
> >
> > > Define a new fs flag FS_SAFE, which denotes, that unprivileged
> > > mounting of this filesystem may not constitute a security problem.
> > >
> > > Since most filesystems haven't been designed with unprivileged
> > > mounting in mind, a thorough audit is needed before setting this flag.
On Fri, 20 Apr 2007 16:04:36 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> The memory allocator treats lower order (order <= 3) and higher order
> (order >= 4) allocations in slightly different ways. As lower orders
> are much more likely to be available and also more likely to be
> simply re
On Sat, 21 Apr 2007 01:28:43 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> It would have been better to have patched page_alloc.c independently, then
> to have used HIGH_ORDER in "lumpy: increase pressure at the end of the
> inactive
> list".
Actually that doesn't matter, because I plan on lu
On Sat, Apr 21, 2007 at 09:54:01AM +0200, Ingo Molnar wrote:
> In practice they can starve a bit when one renices thousands of tasks,
> so i was thinking about the following special-case: to at least make
> them easily killable: if a nice 0 task sends a SIGKILL to a nice 19 task
> then we could
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> All of my testing has been on desktop machines, although in most cases
> they were really loaded desktops which had load avg 10..100 from time
> to time, and none were low memory machines. Up to CFS v3 I thought
> nicksched was my winner, now CFSv3
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Instead of that one, i tried CFSv3 and i cannot reproduce the hang
> > anymore, Thanks!...
>
> And that explains why CFS-v3 on 21-rc7-git3 wouldn't show me the hang.
> As a matter of fact, nothing I did showed any bad behavior! Note that
> I was d
On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > > +{
> > >
> > > ...
> > >
> > > + return mnt->mnt_uid == current->uid;
> > > +}
> >
> > Yes, this seems very wrong. I'd have thought that comparing
On Sat 2007-04-21 00:23:19, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The task_lock() in include/linux/freezer.h:thaw_process() looks as though it
> were protecting p->flags, which is not the case. Add a comment that explains
> why it's there.
>
> Signed-off-by:
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> I suppose this is a special case of the dreaded priority inversion.
> What of, say, nice 19 tasks holding fs semaphores and/or mutexes that
> nice -19 tasks are waiting to acquire? Perhaps rt_mutex should be the
> default mutex implementatio
Hi!
> > Of course, running try_to_freeze() in kthread_stop() would be very wrong,
> > so we'd actually need to do it in callers, preferably via a new
> > kthread_stop_freezeable() wrapper.
> >
> Well, even then we'll need to ensure that a thread would not call
> kthread_stop_freezeable() with any
On Saturday, 21 April 2007 02:02, Jeremy Fitzhardinge wrote:
> Dave Jones wrote:
> > On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
> > > Dave Jones wrote:
> > > > > Andi, I think. I've got his firstfloor.org patches applied to this
> > kernel.
> > > >
> > > > Ah, I saw
On Saturday 21 April 2007 00:49:48 Chuck Ebbert wrote:
> x86 CPU feature flag setup has become impossible to debug.
> Every user just does set_bit()/clear_bit() or writes the
> entire set to change the flags, so there's no way to trace
> how they're being set.
Just use grep or printk? It is not *t
So, removing -d halt option solves this problem?
2007/4/20, Fabio Comolli <[EMAIL PROTECTED]>:
Bingo!
I switched from ata_piix.c to piix_ide.c and the "pop" disappeared.
I must say that the "pop" also disappeared after suspending to disk
using suspend2 (obviously without executing halt -n -h -p
On Saturday 21 April 2007 00:52:52 Chuck Ebbert wrote:
> /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
> 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
> - clear_bit(0*32+31, &c->x86_capability);
> + clear_bit(X86_FEATURE_PBE, &c->x86_capabili
> Lots of people want kgdb. One person is famously less keen on it, but
> we'll be able to talk him around, as long as the patches aren't daft.
The big question is if the kgdb developers seriously want mainline.
At least in the past this definitely wasn't the case.
If they're not open to change
Hi.
On 4/21/07, emisca <[EMAIL PROTECTED]> wrote:
So, removing -d halt option solves this problem?
According to the halt manpage, -n implies -d (in other words, -d is
not removed at all).
Regards,
Fabio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
> a) there have been rather a lot of underlying changes in Andi's devel tree and
>
> b) we still haven't heard from Andy?
c) my original review comments haven't been completely addressed.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, 20 Apr 2007 17:51:57 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> With the current logic the percpu_counter's accuracy delta is quadric
> wrt the number of cpus in the system, reduce this to O(n ln n).
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> include/linux/percp
On Fri, 20 Apr 2007 17:51:58 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Add percpu_counter_mod64() to allow large modifications.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> include/linux/percpu_counter.h |9 +
> lib/percpu_counter.c | 28 +
On Fri, 20 Apr 2007 17:52:01 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Count per BDI reclaimable pages; nr_reclaimable = nr_dirty + nr_unstable.
hm. Aggregating dirty and unstable at inc/dec time is a bit kludgy. If
later on we want to know just "dirty" then we're in trouble.
I can see
On Fri, 20 Apr 2007 17:52:04 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Scale writeback cache per backing device, proportional to its writeout speed.
>
> By decoupling the BDI dirty thresholds a number of problems we currently have
> will go away, namely:
>
> - mutual interference starva
On Fri, 20 Apr 2007 17:52:03 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Expose the per BDI stats in /sys/block//queue/*
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> block/ll_rw_blk.c | 32
> 1 file changed, 32 insertions(+)
>
> Index: l
On Fri, 20 Apr 2007 17:52:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Count per BDI writeback pages.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> include/linux/backing-dev.h |1 +
> mm/page-writeback.c | 12 ++--
> 2 files changed, 11 insertions(+)
On Fri, 20 Apr 2007 20:55:49 -0400 (EDT) "John Anthony Kazos Jr." <[EMAIL
PROTECTED]> wrote:
> +#define upper_32_bits(n) (sizeof(n) == 8 ? (u64)(n) >> 32 : 0)
It's very unclear what type this returns, in terms of both size and
signedness. Perhaps it always returns a u64, dunno. If it does, tha
On Fri, Apr 20, 2007 at 10:34:20PM -0700, Greg KH wrote:
> On Fri, Apr 20, 2007 at 11:30:59PM -0500, Marcos Pinto wrote:
> > Yes, I just tried 2.6.20.3 with ACPI enabled and it booted perfectly.
> > I'm hoping this means you know what's wrong? :-)
>
> Can you do a 'git bisect' on the versions be
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the queue
having their "on CPU" forever postponed and we all know that even the
smallest possibilit
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > The modified code is here :
> >
> > http://linux.1wt.eu/sched/orbitclock-0.2bench.tgz
> >
> > What is interesting to note is that it's easy to make X work a lot
> > (99%) by using 0 as the sleeping time, and it's easy to make the
> > process work
> On Fri, 20 Apr 2007 17:52:04 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Scale writeback cache per backing device, proportional to its writeout
> > speed.
> >
> > By decoupling the BDI dirty thresholds a number of problems we currently
> > have
> > will go away, namely:
> >
> > -
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> I hacked it a bit to make it accept two parameters :
> -R : time spent burning CPU cycles at each round
> -S : time spent getting a rest
>
> It now advances what it thinks is a second at each iteration, so that
> it makes it easy to compare its
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > It could become a useful scheduler benchmark !
>
> i just tried ocbench-0.3, and it is indeed very nice!
another thing i noticed: when using a -y larger then 1, then the window
title (at least on Metacity) overlaps and thus the ocbench tasks have
d
It took me several hours, but I just got done combing things over with
bisect as Greg requested. This is what git spit out as the problem
patch in the end:
7639e962234c76031d1ddf436def7fd9602be560 is first bad commit
commit 7639e962234c76031d1ddf436def7fd9602be560
Author: Jan Beulich <[EMAIL PRO
On Sat, 21 Apr 2007 12:38:45 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> The other deadlock, in throttle_vm_writeout() is still to be solved.
Let's go back to the original changelog:
Author: marcelo.tosatti
Date: Tue Mar 8 17:25:19 2005 +
[PATCH] vm: pageout throttling
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:51:57 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > With the current logic the percpu_counter's accuracy delta is quadric
> > wrt the number of cpus in the system, reduce this to O(n ln n).
> >
> > Signed-off
On Sat, 21 Apr 2007, Andrew Morton wrote:
> On Fri, 13 Apr 2007 20:08:28 +0200 (CEST) Guennadi Liakhovetski <[EMAIL
> PROTECTED]> wrote:
>
> > Hi
> >
> > Either I've finally gone blind on this Friday 13th or... Looks like this
> > almost 3 year old function has a bug. Patch below compile-teste
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:51:58 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Add percpu_counter_mod64() to allow large modifications.
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> > include/linux/percpu_counter
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:52:01 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Count per BDI reclaimable pages; nr_reclaimable = nr_dirty + nr_unstable.
>
> hm. Aggregating dirty and unstable at inc/dec time is a bit kludgy. If
> lat
Hi Ingo,
I'm replying to your 3 mails at once.
On Sat, Apr 21, 2007 at 12:45:22PM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > It could become a useful scheduler benchmark !
> >
> > i just tried ocbench-0.3, and it is indeed very nice!
So as you've noticed ju
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:52:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Count per BDI writeback pages.
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> > include/linux/backing-dev.h |1 +
> > mm/page-writ
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:52:03 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Expose the per BDI stats in /sys/block//queue/*
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> > block/ll_rw_blk.c | 32
Hi,
On 2007.04.21 13:07:48 +0200, Willy Tarreau wrote:
> > another thing i noticed: when using a -y larger then 1, then the window
> > title (at least on Metacity) overlaps and thus the ocbench tasks have
> > different X overhead and get scheduled a bit assymetrically as well. Is
> > there any
Hi Björn,
On Sat, Apr 21, 2007 at 01:29:41PM +0200, Björn Steinbrink wrote:
> Hi,
>
> On 2007.04.21 13:07:48 +0200, Willy Tarreau wrote:
> > > another thing i noticed: when using a -y larger then 1, then the window
> > > title (at least on Metacity) overlaps and thus the ocbench tasks have
> >
On Sat, 2007-04-21 at 02:55 -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2007 17:52:04 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Scale writeback cache per backing device, proportional to its writeout
> > speed.
> >
> > By decoupling the BDI dirty thresholds a number of problems we cu
Hi Ingo, Hi Con,
I promised to perform some tests on your code. I'm short in time right now,
but I observed behaviours that should be commented on.
1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either scheduler
Test: ./ocbench -R 25 -S 75 -x 8 -y 8
ocbench: http://
> > > +/*
> > > + * maximal error of a stat counter.
> > > + */
> > > +static inline unsigned long bdi_stat_delta(void)
> > > +{
> > > +#ifdef CONFIG_SMP
> > > + return NR_CPUS * FBC_BATCH;
> >
> > This is enormously wrong for CONFIG_NR_CPUS=1024 on a 2-way.
Right, I knew about that but, uhm.
I
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the
queue having their "on CPU" forever postponed and we all know that
even
Am 21.04.2007 01:19 schrieb Robert P. J. Day:
> [...] here's the short list of other stuff that is listed as on
> its way to being dead, based on the contents of Kconfig files. any of
> this stuff candidates for removal, if not scheduling for removal?
[...]
> config ISDN_I4L
> tristate "
On Saturday 21 April 2007, Adrian Bunk wrote:
> On Fri, Apr 20, 2007 at 10:34:20PM -0700, Greg KH wrote:
> > On Fri, Apr 20, 2007 at 11:30:59PM -0500, Marcos Pinto wrote:
> > > Yes, I just tried 2.6.20.3 with ACPI enabled and it booted perfectly.
> > > I'm hoping this means you know what's wrong
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
> Hi Ingo, Hi Con,
>
> I promised to perform some tests on your code. I'm short in time right now,
> but I observed behaviours that should be commented on.
>
> 1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either
> scheduler Tes
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
>> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
>> > > +{
>> > >
>> > > ...
>> > >
>> > > +return mnt->mnt_uid == current->uid;
>> > > +}
>> >
>> >
Andrew Morton wrote:
On Fri, 20 Apr 2007 22:13:41 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
We broke the the alignment of members of taskstats to the 8 byte boundary
with the CSA patches. In the current kernel, the taskstats structure is
not suitable for use by 32 bit applications in a 64 b
From: Tilman Schmidt <[EMAIL PROTECTED]>
The "obsolete" label on the ISDN_I4L Kconfig option is not, and
has never been, accurate. It has already prompted repeated attempts
to remove actively used functionality from the kernel without a
working replacement. This patch removes the incorrect label a
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Add helper functions "upper_32_bits" and "lower_32_bits" to
to allow 64-bit integers to be separated into
their 32-bit upper and lower halves without promoting integers, without
stretching sign bits, and without generating compiler warnings when
On Sat, Apr 21, 2007 at 10:40:18PM +1000, Con Kolivas wrote:
> On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
> > Hi Ingo, Hi Con,
> >
> > I promised to perform some tests on your code. I'm short in time right now,
> > but I observed behaviours that should be commented on.
> >
> > 1) machine
On Sat, 21 Apr 2007, Tilman Schmidt wrote:
> Am 21.04.2007 01:19 schrieb Robert P. J. Day:
> > [...] here's the short list of other stuff that is listed as on
> > its way to being dead, based on the contents of Kconfig files. any of
> > this stuff candidates for removal, if not scheduling for rem
When the kernel calls svc_reserve to downsize the expected size of an RPC
reply, it fails to account for the possibility of a checksum at the end of
the packet. If a client mounts a NFSv2/3 with sec=krb5i/p, and does I/O then
you'll generally see messages similar to this in the server's ring buffer
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add ownership information to mounts.
>
> A new mount flag, MS_SETUSER is used to make a mount owned by a user.
> If this flag is specified, then the owner will be set to the current
> real user id and the mou
Jeff Mahoney wrote:
> I have the patchset that I mentioned, but I'm not proposing it for 2.6.21.
> It's much too invasive to be introduced in an -rc7, but it does include
> locking changes that I believe avoid this bug.
>
> Vladimir was right in his analysis that sometimes get_xa_root() takes the
Hello.
I've just returned from ELC2007 and
I haven't read all posts in this thread yet,
but I want to comment to this function.
> In AppArmor, we are interested in pathnames relative to the namespace root.
> This is the same as d_path() except for the root where the search ends. Add
> a function
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> The owner doesn't need sysadmin capabilities to call umount().
>
> Similar behavior as umount(8) on mounts having "user=UID" option in
> /etc/mtab. The difference is that umount also checks /etc/fstab,
> pre
Matt Mackall wrote:
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
[2] It's trivial to construct two or more perfectly reasonable and
desirable definitions of fairness that are mutually incompatible.
Probably not if you use common sense, and in the context of a replacement
for t
Am 21.04.2007 15:11 schrieb Robert P. J. Day:
> On Sat, 21 Apr 2007, Tilman Schmidt wrote:
[...]
>> Removing isdn4linux would constitute a serious regression.
>
> i know. believe me, i *know that*, since i'm fairly sure it was my
> observation that initially started that discussion about isdn4lin
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add sysctl variables for accounting and limiting the number of user
> mounts.
>
> The maximum number of user mounts is set to 1024 by default. This
> won't in itself enable user mounts, setting a mount to be
Linus Torvalds wrote:
On Wed, 18 Apr 2007, Matt Mackall wrote:
Why is X special? Because it does work on behalf of other processes?
Lots of things do this. Perhaps a scheduler should focus entirely on
the implicit and directed wakeup matrix and optimizing that
instead[1].
I 100% agree - the p
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Allow clone_mnt() to return errors other than ENOMEM. This will be
> used for returning a different error value when the number of user
> mounts goes over the limit.
>
> Fix copy_tree() to return EPERM for u
Hello,
I am facing a strange problems with an old 1.2 GHz P-III machine with
a 10 GB disk (used as a dedicated web server, later retired out of
service!).
Out of interest to implement some wireless solution (experiment), I
did compile 2.6.20.7 for my requirement. Strangely, I did observe:-
hda:
On Sat, Apr 21, 2007 at 12:23:45AM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 11:06:56 -0400 Josef Bacik <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
> > > On Thu, 2007-04-19 at 09:25 -0400, Josef Bacik wrote:
> > > > Looking through ever
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Allow bind mounts to unprivileged users if the following conditions
> are met:
>
> - mountpoint is not a symlink or special file
Why? This sounds like a left over from when we were checking permissions.
Hello,
I did compile 2.6.21-rc7 for a P-III machine. Here is the ACPI part in
the dmesg:-
ACPI Error (psargs-0355): [PRSE] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.LNKE._PRS] (Node dfd63f40), AE_NOT_FOUND
ACPI Exception (pci_link-0180
Ingo Molnar wrote:
* Davide Libenzi <[EMAIL PROTECTED]> wrote:
The same user nicing two different multi-threaded processes would
expect a predictable CPU distribution too. [...]
i disagree that the user 'would expect' this. Some users might. Others
would say: 'my 10-thread rendering engine
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
>> Define a new fs flag FS_SAFE, which denotes, that unprivileged
>> mounting of this filesystem may not constitute a security problem.
>>
>> Since most filesystems haven't b
Recently I tried newer releases of Linux distributions, specifically
Sabayon Linux 3.3 and Ubuntu 7.04. Both suffer from problems with
rt2500/rt2570 modules not being able to associate with access points.
There are numerous problems reported Ubuntu Launchpad, Gentoo Forums
and Sabayon Forums.
Ple
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged
> users. This has also been verified in practice over many years. In
> addition un
Andrea Righi wrote:
> Jeff Mahoney wrote:
>> I have the patchset that I mentioned, but I'm not proposing it for 2.6.21.
>> It's much too invasive to be introduced in an -rc7, but it does include
>> locking changes that I believe avoid this bug.
>>
>> Vladimir was right in his analysis that sometime
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Mahoney wrote:
> Andrea Righi wrote:
>> Jeff Mahoney wrote:
>>> I have the patchset that I mentioned, but I'm not proposing it for 2.6.21.
>>> It's much too invasive to be introduced in an -rc7, but it does include
>>> locking changes that I belie
1 - 100 of 221 matches
Mail list logo
