From: Eric W. Biederman [EMAIL PROTECTED]
Modify zfcperp%s to be started with kthread_run not
a combination of kernel_thread, daemonize and siginitsetinv
making the code slightly simpler and more maintainable.
Cc: Swen Schillig [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED
From: Eric W. Biederman [EMAIL PROTECTED]
This patch changes cpqphp to use kthread_run and not
kernel_thread and daemonize to startup and setup
the cpqphp thread.
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/pci/hotplug/cpqphp_ctrl.c
From: Eric W. Biederman [EMAIL PROTECTED]
thread_run is used intead of kernel_thread, daemonize, and mucking
around blocking signals directly.
CC: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/mtd/mtd_blkdevs.c | 19 +--
1
From: Eric W. Biederman [EMAIL PROTECTED]
It is my goal to replace all kernel code that handles signals
from user space, calls kernel_thread or calls daemonize. All
of which the kthread_api makes unncessary. Handling signals
from user space is a maintenance problem becuase using a
kernel thread
From: Eric W. Biederman [EMAIL PROTECTED]
This patch is a minimal transformation to use the kthread API
doing it's best to preserve the existing logic.
Instead of starting kdvb-ca by calling kernel_thread,
daemonize and sigfillset we kthread_run is used.
Instead of tracking the pid
From: Eric W. Biederman [EMAIL PROTECTED]
Use kthread_run to start the lcs kernel threads not a
combination of kernel_thread and daemonize. This makes
the code slightly simpler and more maintainable.
Cc: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of kadbprobe to use
kthread_run instead of scheduling a work event which
later calls kernel_thread and in the thread calls
daemonize and blocks signals. kthread_run is simpler
and more maintainable.
The variable pid_t
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the sas scsi host thread startup
to use kthread_run not kernel_thread and deamonize.
kthread_run is slightly simpler and more maintainable.
Cc: Darrick J. Wong [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off
From: Eric W. Biederman [EMAIL PROTECTED]
kthread_run replaces the kernel_thread and daemonize calls
during thread startup.
Calls to signal_pending were also removed as it is currently
impossible for the cpci_hotplug thread to receive signals.
CC: Scott Murray [EMAIL PROTECTED]
Signed-off
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies startup of the kfand to use kthread_run
not a combination of kernel_thread and daemonize, making
the code a little simpler and more maintaintable.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED]
This patch starts the xpc kernel threads using kthread_run
not a combination of kernel_thread and daemonize. Resuling
in slightly simpler and more maintainable code.
Cc: Jes Sorensen [EMAIL PROTECTED]
Cc: Tony Luck [EMAIL PROTECTED]
Signed-off-by: Eric
From: Eric W. Biederman [EMAIL PROTECTED]
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.
In addition since by default all signals are ignored when
From: Eric W. Biederman [EMAIL PROTECTED]
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.
In addition since by default all signals are ignored
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the kcmptd_ctr_%d daemon using kthread_run
instead of a combination of kernel_thread and daemonize making
the code a little simpler and more maintainable.
Cc: Marcel Holtmann [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of the media_bay_task
to use kthread_run and not a combination of kernel_thread,
deamonize and sigfillset.
In addition since we now always want to ignore signals
the MB_IGNORE_SIGNALS define is removed along with the
test
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of rtasd to use kthread_run instaed of
a combination of kernel_thread and daemonize. Making the code a little
simpler and more maintainble.
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED]
This patch starts kbenpd using kthread_run replacing
a combination of kernel_thread and daemonize. Making
the code a little simpler and more maintainable.
Cc: Marcel Holtmann [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of kecardd to use
kthread_run not a kernel_thread combination of kernel_thread
and daemonize. Making the code slightly simpler and more
maintainable.
Cc: Russell King [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman
From: Eric W. Biederman [EMAIL PROTECTED]
Start the g4fand using kthread_run not a combination
of kernel_thread and deamonize. This makes the code
a little simpler and more maintainable.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers
From: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/smbfs/smbiod.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/smbfs/smbiod.c b/fs/smbfs/smbiod.c
index 3e61b44..67176af 100644
--- a/fs/smbfs/smbiod.c
+++ b/fs/smbfs
-
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/
From: Eric W. Biederman [EMAIL PROTECTED]
To start the nfsv4-delegreturn thread this patch uses
kthread_run instead of a combination of kernel_thread
and daemonize.
In addition allow_signal(SIGKILL) is removed from
the expire delegations thread.
Cc: Neil Brown [EMAIL PROTECTED]
Cc: Trond
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a maintenance problem to handle
signals in kernel threads.
Cc: Neil
From: Eric W. Biederman [EMAIL PROTECTED]
Currently md_thread calls allow_signal so it can receive a
SIGKILL but then does nothing with it except flush the
sigkill so that it not can use an interruptible sleep.
This whole dance is silly so remove the unnecessary
and broken signal handling logic
From: Eric W. Biederman [EMAIL PROTECTED]
Modify startup of ipvs sync threads to use kthread_run
instead of a weird combination of calling kernel_thread
to start a fork_sync_thread whose hole purpose in life was
to call kernel_thread again starting the actually sync thread
which called daemonize
From: Eric W. Biederman [EMAIL PROTECTED]
Cc: Neil Brown [EMAIL PROTECTED]
Cc: Trond Myklebust [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/nfs/nfs4state.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs
David Howells [EMAIL PROTECTED] writes:
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
David Howells [EMAIL PROTECTED] writes:
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.
Ok. I
Christoph Hellwig [EMAIL PROTECTED] writes:
On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
thread_run is used intead of kernel_thread, daemonize, and mucking
around blocking signals directly.
Please don't do
David Howells [EMAIL PROTECTED] writes:
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?
That is my goal
Trond Myklebust [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
This patchset has now been bared to the lowest common denominator
that everybody can agree on. Or at least there weren't any objections
to this proposal.
Andrew, please consider it for -mm.
Thanks,
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;
+}
Yes, this seems very wrong. I'd have
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 mount will be
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,
presumably to
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 owned by
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 unbindable
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.
-
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 been designed
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 unprivileged
Jan Engelhardt [EMAIL PROTECTED] writes:
On Apr 21 2007 08:10, Eric W. Biederman 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
Dave Hansen [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
With pid namespaces all kernel threads will disappear so how do
we cope with the problem when the sysadmin can not see the kernel
threads?
Do they actually always disappear, or do we keep them
Trond Myklebust [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
Using signals to communicate with kernel threads is fairly unpleasant, IMO.
We have much simpler, faster and more idiomatic ways of communicating
between threads in-kernel and there are better
Robin Holt [EMAIL PROTECTED] writes:
I think this was originally coded with daemonize to avoid issues with
reaping children. Dean Nelson can correct me if I am wrong. I assume
this patch is going in as part of the set which will make these threads
clear themselves from the children list and
Jan Engelhardt [EMAIL PROTECTED] writes:
On Apr 21 2007 10:57, Eric W. Biederman wrote:
tmpfs!
tmpfs is a possible problem because it can consume lots of ram/swap.
Which is why it has limits on the amount of space it can consume.
Users can gobble up all RAM and swap already today. (Unless
Andi Kleen [EMAIL PROTECTED] writes:
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.
Miklos Szeredi [EMAIL PROTECTED] writes:
Does this mean, that containers will need this? Or that you don't
know yet?
The uid namespace is something we have to handle carefully and we
have not decided on the final design.
What is clear is that all permission checks will need to become
either
Miklos Szeredi [EMAIL PROTECTED] writes:
The MNT_USER flag is not copied on any kind of mount cloning:
namespace creation, binding or propagation.
I half agree, and as an initial approximation this works.
Ultimately we should be at the point that for mount propagation
that we copy the
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
James Bottomley [EMAIL PROTECTED] writes:
Changelog and cc to linux-scsi, and I think it can go in ... not that it
matters; nothing ever activates this code inside libsas anyway ...
Should we just remove the relevant code then?
Eric
-
To unsubscribe from this list: send the line unsubscribe
-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/kthread.h | 23 +++
kernel/kthread.c| 18 ++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index a8ea31d..4f1eff1 100644
CONFIG_PHYSICAL_START
on x86_64.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/x86_64/Kconfig |4 +++
arch/x86_64/Makefile | 10 +++
scripts/Makefile | 11 ---
scripts/mketrel.c| 70 ++
4 files changed, 90
to be conditional and can
be removed.
The big win of this patch (besides Kconfig simplicity) is that the
nasty BUILD_BUG_ON test for people misaligning their kernel when using
CONFIG_PHYSICAL_START can be removed as this case can only happen with
CONFIG_PHYSICAL_START selected.
Signed-off-by: Eric W
Vivek Goyal [EMAIL PROTECTED] writes:
On Sun, Apr 22, 2007 at 11:15:48PM -0600, Eric W. Biederman wrote:
+++ b/arch/x86_64/Kconfig
@@ -565,62 +565,9 @@ config CRASH_DUMP
which are loaded in the main kernel with kexec-tools into
a specially reserved region and then later
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Chuck Ebbert wrote:
H. Peter Anvin wrote:
Andi Kleen wrote:
Then we would have seen reports surely?
Yes, I would have thought so. It surprised me that such an obvious bug
could be there, apparently for a long time. But it's
H. Peter Anvin [EMAIL PROTECTED] writes:
Since we allocate the maximum possible memory statically, I fail to see how
holes could make the situation any worse, or better.
Consider a memory hole of size 8M immediately after our bootmem bitmap.
head.S which knows nothing of holes will map the
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Since we allocate the maximum possible memory statically, I fail to
see how holes could make the situation any worse, or better.
No, we map enough space to map 4G (~4 pages), but we don't actually map
4G. If a hole
Jes Sorensen [EMAIL PROTECTED] writes:
Like with the previous patch from Eric, I'm CC'ing the correct people
for this patch (forwarded it in a seperate email). CC'ing irrelevant
lists such as containers@ and not linux-ia64@ makes it somewhat
difficult to get proper reviews of these things.
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/23, Christoph Hellwig wrote:
On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
This patch implements the kthread helper functions kthread_start
and kthread_end which make it simple to support a kernel thread
that may
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
- I know of one system that had BIOS tables at 16MB I believe (and
thus had a fairly low hole).
Please name names, otherwise this is just rumouring. Seriously. We have
enough
cargo-cult programming
H. Peter Anvin [EMAIL PROTECTED] writes:
Agreed. However, saying that your patch shouldn't go into the mainline kernel
until that has been fixed is spurious and wrong. It fixes a real problem with
minimal risk.
For a stable and frozen kernel it is probably the best we can do.
However the
Simon Horman [EMAIL PROTECTED] writes:
Update the list information for kexec and kdump
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Is it too early for this change?
It looks like the new list is working, and isn't likely to get overwhelmed
with spam. I don't know if everyone has
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Consider a memory hole of size 8M immediately after our bootmem bitmap.
head.S which knows nothing of holes will map the pages of the hole
into the initial page tables assuming that is where the page tables
will live
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
It would be *trivial* to make a certain number of page table slots
available at the end of the head.S-generated map.
Or you could use a fixmap.
That certain number of page table slots should be the fixmap slots.
If you do
Simon Horman [EMAIL PROTECTED] writes:
On Mon, Apr 23, 2007 at 12:04:01PM -0600, Eric W. Biederman wrote:
Simon Horman [EMAIL PROTECTED] writes:
Update the list information for kexec and kdump
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Is it too early for this change
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Not sure... I can see places where I might want to spawn an arbitrary
number of these without having to preallocate structures... and if I
allocate on the fly, then I need a way to free that structure when the
kthread is reaped which I don't
Paul Mackerras [EMAIL PROTECTED] writes:
Eric W. Biederman writes:
Well the basic problem is that for any piece of code that can be modular
we need a way to ensure all threads it has running are shutdown when we
remove the module.
The EEH code can't be modular, and wouldn't make any sense
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead
Vivek Goyal [EMAIL PROTECTED] writes:
On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START. So this patch adds a small
c program to do what we cannot do
Andrew Morton [EMAIL PROTECTED] writes:
On Fri, 13 Apr 2007 21:13:13 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
wrote:
This patch reworks kthread_stop so it is more flexible and it causes
the target kthread to abort interruptible sleeps. Allowing a larger
class of kernel threads to use
Andrew Morton [EMAIL PROTECTED] writes:
Yes, it was fairly early in boot. I didn't check what we're oopsing on.
Thanks.
It was definitely vfork_done == NULL from what I can read of the Oops and
the code.
That was on a Fedora Core 3 machine. One of those older distros I keep
around to
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/24, Oleg Nesterov wrote:
Hm, mm_release() clears -vfork_done before complete().
Duh. Yes somehow I had a blind spot there. I clearly
need to handle that case.
mm_release:
struct completion *vfork_done = tsk-vfork_done;
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/24, Eric W. Biederman wrote:
I don't know if this is the problem but it certainly needs to be fixed.
I guess you will re-submit these patches soon. May I suggest you to put
this
+spin_lock_irq(tsk-sighand-siglock);
+signal_wake_up
Karel Zak [EMAIL PROTECTED] writes:
On Fri, Apr 20, 2007 at 12:25:32PM +0200, Miklos Szeredi wrote:
The following extra security measures are taken for unprivileged
mounts:
- usermounts are limited by a sysctl tunable
- force nosuid,nodev mount options on the created mount
The
Adrian Bunk [EMAIL PROTECTED] writes:
On Tue, Apr 24, 2007 at 05:51:11PM -0700, Greg KH wrote:
On Wed, Apr 25, 2007 at 02:29:58AM +0200, Adrian Bunk wrote:
On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
On Mon,
Jeff Garzik [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Until I get the best scenario I can come up with is a tg3 hardware bug
that doesn't renable the pci-X capability after a restore of power state.
Speaking of tg3, make sure you are aware that the number of calls to
save-state
Catalin Marinas [EMAIL PROTECTED] writes:
Hi Eric,
I'm trying to track down a kmemleak report (on an ARM platform) which
seems to have appeared with commit
ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
TTY layer at all, is it possible that the above commit missed a
Well this is clearly a weird tangent from the topic of this thread but
it looks to have found some real bugs even if they aren't the ones we
are looking for.
In short pci_save_state and pci_restore_state are used to two primary
was: As a pair called from the suspend and restore routines. One
then.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/pci/msi.c| 150 --
drivers/pci/pci.c|2 -
drivers/pci/pci.h|2 -
include/linux/msi.h |8 +--
include/linux/pci_regs.h |1 +
5 files
-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/pci/pci.c | 12 ++--
include/linux/pci.h |5 -
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6fb78df..b292c9a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
I have never have figured out how to get suspend/resume actually
working on any of my machines [...]
ouch! Are you interested in getting it work?
I haven't even seriously tried. I don't yet have a laptop
Catalin Marinas [EMAIL PROTECTED] writes:
On 08/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Catalin Marinas [EMAIL PROTECTED] writes:
I think it's only the pid_chain and rcu member that could be placed in
a list and kmemleak scans the memory for these two offsets as well.
I'll check
Chuck Ebbert [EMAIL PROTECTED] writes:
[sorry for the dup: this time to the right recipient]
So far I've tried the simple survive having no handler
for a vector patch and the preliminary 3-patch series
that was in -mm for a while, and neither work on the
Dell PowerEdge 29xx and 19xx
(tasklist_lock);
+ put_pid(tty-session);
+ put_pid(tty-pgrp);
+
tty-flags = 0;
tty-session = NULL;
tty-pgrp = NULL;
On 08/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Catalin Marinas [EMAIL PROTECTED] writes:
The /sbin/init application calls sys_clone() a few times
Chuck Ebbert [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Chuck Ebbert [EMAIL PROTECTED] writes:
So far I've tried the simple survive having no handler
for a vector patch and the preliminary 3-patch series
that was in -mm for a while, and neither work on the
Dell PowerEdge 29xx
Kok, Auke [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
[CHOP]
Below is an additional set of warnings that should help debug this.
The old code just got lucky that it triggered a warning when this happens.
I'm trying this patch together with the other 2 that you sent out a few days
Andrew Morton [EMAIL PROTECTED] writes:
On Fri, 9 Mar 2007 01:13:14 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
I get the following traces from 2.6.21-rc3-mm2 during the resume phase
of testing with 'echo test /sys/power/disk echo disk
/sys/power/state':
acpi thermal:00:
Michael S. Tsirkin [EMAIL PROTECTED] writes:
The only case I can see which might trigger this is if we saved
pci-X state and then didn't restore it because we could not find
the capability on restore.
Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
regular devices and
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman [EMAIL PROTECTED]:
Subject: Re: SATA resume slowness, e1000 MSI warning
Michael S. Tsirkin [EMAIL PROTECTED] writes:
The only case I can see which might trigger this is if we saved
pci-X state and then didn't
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Rumor has it that some pci devices can't tolerate 32bit accesses.
Although I have never met one.
hopefully not bridge devices?
The two factors together suggest that
for generic code it probably makes sense to operate on 32bit
quantities, and
Herbert Poetzl [EMAIL PROTECTED] writes:
Linux-VServer does the accounting with atomic counters,
so that works quite fine, just do the checks at the
beginning of whatever resource allocation and the
accounting once the resource is acquired ...
Atomic operations versus locks is only a
Pavel Emelianov [EMAIL PROTECTED] writes:
Adds needed pointers to mm_struct and page struct,
places hooks to core code for mm_struct initialization
and hooks in container_init_early() to preinitialize
RSS accounting subsystem.
An extra pointer in struct page is unlikely to fly.
Both because
Pavel Emelianov [EMAIL PROTECTED] writes:
Pages are charged to their first touchers which are
determined using pages' mapcount manipulations in
rmap calls.
NAK pages should be charged to every rss group whose mm_struct they
are mapped into.
Eric
-
To unsubscribe from this list: send the line
Andrew Morton [EMAIL PROTECTED] writes:
Yep. Straightforward machine partitioning. An attractive thing is that it
100% reuses existing page reclaim, unaltered.
And misses every resource sharing opportunity in sight. Except for
filtering the which pages are eligible for reclaim an RSS limit
Michael S. Tsirkin [EMAIL PROTECTED] writes:
OK I guess. I gather we assume writing read-only registers has no side
effects?
Are there rumors circulating wrt to these?
I haven't heard anything about that, and if we are writing the same value back
it should be pretty safe.
I have heard it
Catalin Marinas [EMAIL PROTECTED] writes:
On 09/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
If I can manage to focus on this, it looks like the information I need to
start fixing this.
I had a look at the second leak reported it seems to be caused by the
same proc_set_tty() call
Dave Jones [EMAIL PROTECTED] writes:
I spent considerable time over the last day or so bisecting to
find out why an X60 stopped resuming somewhen between 2.6.20 and current -git.
(Total lockup, black screen of death).
The bisect log looked like this.
git-bisect start
# bad:
Herbert Poetzl [EMAIL PROTECTED] writes:
On Sun, Mar 11, 2007 at 01:00:15PM -0600, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
Linux-VServer does the accounting with atomic counters,
so that works quite fine, just do the checks at the
beginning of whatever
201 - 300 of 10702 matches
Mail list logo
