On 6/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On 6/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> So it looks to me like we need to do three things:
>> - Fix the inode number
>> - Fix the name on the hugetlbfs dentry to hold the k
On Fri, 8 Jun 2007 08:40:42 +0200 Oleg Verych <[EMAIL PROTECTED]> wrote:
> After running this script with filename as parameter,
> look (with diff) for, what can be corrected.
Sorry, but "run it and see what it did" is pretty poor documentation.
> Only "*.diff" and "*.patch" files are handled as
On Fri, 8 Jun 2007 08:02:44 +0200 Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> Fix interchanged parameters to release_{evntsel,perfctr}_nmi.
>
> Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
> ---
> diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c
> b/arch/i386/kernel/cpu/perfctr-watc
[EMAIL PROTECTED] wrote:
> On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said:
>> [EMAIL PROTECTED] wrote:
>>> On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2
> .6.22-rc4-mm1/
>>> This one died a horrid death at b
On 6/7/07, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
[...]
Miles, could you try if this patch helps?
Björn
Stop destroying devices when all of their ifas are gone, as we no longer
recreate them when ifas are added.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
--
diff --git a/net/ipv4
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the problem. You can mmap a file
On Fri, 08 Jun 2007 06:23:23 +0200 Miloslav Trmac <[EMAIL PROTECTED]> wrote:
> From: Miloslav Trmac <[EMAIL PROTECTED]>
>
> Add TTY input auditing, used to audit system administrator's actions.
> TTY input auditing works on a higher level than auditing all system
> calls within the session, which
After running this script with filename as parameter,
look (with diff) for, what can be corrected.
Only "*.diff" and "*.patch" files are handled as patches.
Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
--
Two clean rules added, that can change look of damaged lines.
Yet script still fits one
On Fri, 08 Jun 2007 13:10:57 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
> The netfilter code had very good documentation: the Netfilter Hacking
> HOWTO. Noone ever read it.
>
> So this time I'm trying something different, using a bit of
> Knuthiness.
>
> Signed-off-by: Rusty Russell <[EMAIL
On Fri, 8 Jun 2007 12:48:48 +1000 Neil Brown <[EMAIL PROTECTED]> wrote:
> The following patch will remove the extra seqlock except when we
> actually need it and remove the extra arithmetic - but I haven't
> tested it or reviewed it properly. I can do that if you think it is
> the right direction
On 2007.06.03 15:02:46 +0200, Udo A. Steinberg wrote:
> On Tue, 29 May 2007 14:52:53 +0200 Michal Piotrowski (MP) wrote:
>
> MP> Here is a list of some known regressions in 2.6.22-rc3.
> MP>
> MP> Feel free to add new regressions/remove fixed etc.
> MP> http://kernelnewbies.org/known_regressions
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On 6/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> So it looks to me like we need to do three things:
>> - Fix the inode number
>> - Fix the name on the hugetlbfs dentry to hold the key
>> - Add a big fat comment that user space programs dep
On Wed, Jun 06, 2007 at 02:33:11AM -0400, Dave Jones wrote:
> We've had this printk in drivers/pci/probe.c asking people
> to report it if they see it to linux-kernel for a long time.
>
> google finds hundreds of instances of this being hit.
> There are a bunch in bugzilla too..
>
> http://bugzil
On Thu, 2007-06-07 at 20:18 -0700, Linus Torvalds wrote:
>
> > Oh and Roland patch doesn't prevent signalfd() from stealing synchronous
> > signals such as SIGSEGV etc... which I think would result in random
> > behaviour do you want a patch for that or we just consider it broken
> > API usage
On Jun 8 2007 01:06, Oleg Verych wrote:
>- empty lines in the end of file (patches can't be handled, or can? :).
Yes it can.
>Body -- is a commented sed script with shell variables for source/patch
>handling switch and compatibility with other versions of sed, not only GNU.
>If you like more t
On Fri, 8 Jun 2007, Eric Dumazet wrote:
> struct fd_map {
> /*
> * read mostly part
> */
> unsigned int base; /* 0x00 */
> unsigned int size; /* 0x04 */
> struct list_head slist; /* 0x08 */
> struct list_head *slots; /* 0x18 */
> unsigned long *map; /* 0x20 */
On Thursday 07 June 2007, Bjorn Helgaas wrote:
> In 2.6.21, smsc-ircc2 at least found the device. So we definitely have
> a problem because in 2.6.22-rc, we don't find the device.
>
> What laptop do you have? Maybe I can find one to play with.
>
This is Toshiba Portege 4000. The rest of your que
On Fri, 8 Jun 2007, Eric Dumazet wrote:
> Well, offsets are wrong but layout OK
>
> struct fd_map {
> /*
> * read mostly part
> */
> unsigned int base; /* 0x00 */
> unsigned int size; /* 0x04 */
> struct list_head slist; /* 0x08 */
> struct list_head *slots; /* 0
On Fri, 8 Jun 2007, Eric Dumazet wrote:
> Davide Libenzi a écrit :
> > On Thu, 7 Jun 2007, Eric Dumazet wrote:
> > > I am afraid randomization wont really work if /sbin/init or /bin/bash for
> > > example uses one (or more) unseq fd :
> > > The 'random base' will be propagated at fork()/exec() tim
On Thu, 7 Jun 2007, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Morton wrote:
> > Absolutely. Let's get them into their final form now, rather than letting
> > some intermediate interface escape out into a major kernel release.
>
> Even if Linus' redirecti
On Fri, 2007-06-08 at 02:04 +0200, Adrian Bunk wrote:
> The difference is that "ls" expects and handles such issues while
> "lsmod" (and most likely also other userspace working with kernel
> output) does not yet handle it resulting in problems if bytes are
> wrongly interpreted as control code
Eric Dumazet a écrit :
struct fd_map {
/*
* read mostly part
*/
unsigned int base; /* 0x00 */
unsigned int size; /* 0x04 */
struct list_head slist; /* 0x08 */
struct list_head *slots; /* 0x18 */
unsigned long *map; /* 0x28 */
void (*freecb)(void *, struc
Davide Libenzi a écrit :
+struct fd_map {
+ struct fd_map *next;
+ struct rcu_head rcu;
+ unsigned int base;
+ unsigned int size;
+ struct list_head slist;
+ struct list_head *slots;
+ unsigned int fdnext;
+ unsigned long *map;
+ void (*freecb
On Sun, Jun 03, 2007 at 10:54:04PM +0200, Adrian Bunk wrote:
> This patch makes the needlessly global dmi_id_init() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks, I've merged this with the original.
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Thu, Jun 07, 2007 at 05:31:35PM +0800, Zhang Rui wrote:
> From: Zhang Rui <[EMAIL PROTECTED]>
>
> Well, first of all, I don't want to change so many files either.
>
> What I do:
> Adding a new parameter "struct bin_attribute *" in the
> .read/.write methods for the sysfs binary attributes.
>
On 6/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
So it looks to me like we need to do three things:
- Fix the inode number
- Fix the name on the hugetlbfs dentry to hold the key
- Add a big fat comment that user space programs depend on this
behavior of both the dentry name and the inod
On Thu, Jun 07, 2007 at 11:59:16AM -0500, Matt Mackall wrote:
>On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote:
>> >Ketchup doesn't even look inside patches, and patch doesn't invent
>> >names, so something in the bzip2 -> patch(1) -> filesystem chain got
>> >corrupted. Probably not bzip2
Davide Libenzi a écrit :
On Thu, 7 Jun 2007, Eric Dumazet wrote:
I am afraid randomization wont really work if /sbin/init or /bin/bash for
example uses one (or more) unseq fd :
The 'random base' will be propagated at fork()/exec() time ?
As I said to Uli, we can't move the base while fds are i
From: Miloslav Trmac <[EMAIL PROTECTED]>
Add TTY input auditing, used to audit system administrator's actions.
TTY input auditing works on a higher level than auditing all system
calls within the session, which would produce an overwhelming amount of
mostly useless audit events.
Add an "audit_tty
On Thu, Jun 07, 2007 at 10:53:29AM -0400, Alan Stern wrote:
> To tell you the truth, I rather think there's not much point in keeping
> usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that
> it could catch ought to have shown up long ago. And it is now clear
> that bug 8561 has n
Thanks for the review.
Andrew Morton napsal(a):
> On Wed, 06 Jun 2007 12:10:28 +0200 Miloslav Trmac <[EMAIL PROTECTED]> wrote:
>> +/**
>> + * tty_audit_opening - A TTY is being opened.
>> + *
>> + * As a special hack, tasks that close all their TTYs and open new ones
>> + * are assum
On Thu, Jun 07, 2007 at 04:16:09PM -0400, Steven Rostedt wrote:
> On Thu, 2007-06-07 at 14:51 -0400, Steven Rostedt wrote:
>
> > There might still be an issue here. With the patch I'm getting a really
> > slow response time on networking. But that be because of other patches I
> > have applied.
>
Vivek Goyal wrote:
>
> One would not know highest used address until ELF headers have been
> parsed. May be it is two step movement. First decompress ELF.gz and
> ELF parser can be at the end of decompressed data. Then it can parse
> the ELF headers and move itself out of the ELF header destinat
William Lee Irwin III wrote:
>> Beg your pardon? Are you reading the patch description correctly?
On Thu, Jun 07, 2007 at 08:44:09PM -0700, H. Peter Anvin wrote:
> I mean, with your patch CONFIG_HIGHMEM4G versus CONFIG_HIGHMEM64G really
> don't make sense as separate selections anymore.
I thought
On 6/7/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
Masoud Asgharifard Sharbiani wrote:
> Hello,
> This patch makes the i386 behave the same way that x86_64 does when a
> segfault happens. A line gets printed to the kernel log so that tools
> that need to check for failures can behave more unifo
On Wed, Jun 06, 2007 at 05:42:35PM -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> > Certainly, but much harder to implement. The ELF parser needs to be
> > prepared to move itself around to get out of the way of the ELF file.
> > It's a fairly large change from how it works now.
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Ok, so IIUC the problem was that inode->i_ino was being set to the id,
> and the id can be the same for different things in two namespaces.
There is nothing preventing inode number collisions in this code even
without multiple namespaces, and even w
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
>>> !CONFIG_X86_PAE && CONFIG_HIGHMEM64G doesn't make sense and is not allowed
>>> by this patch. CONFIG_X86_PAE && !CONFIG_HIGHMEM64G works here.
>
>
> On Thu, Jun 07, 2007 at 08:38:22PM -0700, H. Peter Anvin wrote:
>> But what's the po
re-sending with a minor correction...
> >
> > @@ -5640,6 +5645,7 @@ int __init sbpcd_init(void)
> > int i=0, j=0;
> > int addr[2]={1, CDROM_PORT};
> > int port_index;
> > + int request_region_flag;
> >
> One could argue that it would be possible to just use the 'j' v
William Lee Irwin III wrote:
>> !CONFIG_X86_PAE && CONFIG_HIGHMEM64G doesn't make sense and is not allowed
>> by this patch. CONFIG_X86_PAE && !CONFIG_HIGHMEM64G works here.
On Thu, Jun 07, 2007 at 08:38:22PM -0700, H. Peter Anvin wrote:
> But what's the point?
> If you're going to divorce these,
William Lee Irwin III wrote:
>
> !CONFIG_X86_PAE && CONFIG_HIGHMEM64G doesn't make sense and is not allowed
> by this patch. CONFIG_X86_PAE && !CONFIG_HIGHMEM64G works here.
>
But what's the point?
If you're going to divorce these, at least do it in a way that makes
sense, specifically the two
Hi,
On Thursday 07 June 2007 13:17, Paul Albrecht wrote:
> Hi,
>
> I'm trying use the 2.6.20 kernel and have run into a problem using the
> ps/2 keyboard with console. When I type input in response to console
> output the characters aren't echo'ed and the console program doesn't
> receive the cha
On Fri, 8 Jun 2007, Benjamin Herrenschmidt wrote:
>
> Looks good to me. Do you think we need to do something about the DRM
> notifier thingy too ?
No. I think that anybody who uses that gets whatever he deserves. It's
designed for one particular usage scenario (where it should work fine), if
Documentation: The FIXMEs
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c | 12
drivers/char/hvc_lguest.c |3 +++
drivers/lguest/interrupts_and_traps.c | 14 ++
drivers/lguest/io.c | 10 +++
On Fri, 8 Jun 2007 05:06:29 +0200 Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> On 2007.05.26 21:10:15 +0200, Nicolas Mailhot wrote:
> > Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit :
> > > Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit :
> > >
> > > > Can you boot with "
Documentation: The Switcher
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/core.c | 51 +++-
drivers/lguest/switcher.S | 271 ++---
2 files changed, 276 insertions(+), 46 deletions(-)
Documentation: The Drivers
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/block/lguest_blk.c | 171 +++---
drivers/char/hvc_lguest.c | 77 +
drivers/lguest/lguest_bus.c | 72
drivers/net/lguest_net.c| 222
Documentation: The Guest
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/lguest.c | 456 ---
drivers/lguest/lguest_asm.S | 57 +++--
include/linux/lguest.h | 47 +++-
3 files changed, 510 insertions(+), 50 deletions(-)
===
The netfilter code had very good documentation: the Netfilter Hacking
HOWTO. Noone ever read it.
So this time I'm trying something different, using a bit of
Knuthiness.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/lguest/extract | 58
On Thursday June 7, [EMAIL PROTECTED] wrote:
>
> Is this really worth fixing?
Hard to say.
One could argue that a read should never return data that was never in
the file. One could also argue that you should always use locking...
But people often look for lock-less solutions.
>
> The code sti
From: Huang Ying <[EMAIL PROTECTED]>
This is another solution to implement multithreaded device matching
(probing). The device matching is delayed until all drivers are
registered. The driver registering is executed one by one, this
eliminates the potential of interdependency between driver. All d
Hi Linus,
At Thu, 7 Jun 2007 08:54:33 -0700 (PDT),
Linus Torvalds wrote:
>
>
>
> On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
> >
> > I tested your patch and my problem didn't occur again, so it seems to my
> > this case at least.
>
> Ok. I applied Roland's slightly bigger patch instead, since
On 2007.05.26 21:10:15 +0200, Nicolas Mailhot wrote:
> Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit :
> > Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit :
> >
> > > Can you boot with "kstack=32" so that we can see more of the stack?
> >
> > I can try. It's not triggering
On Thu, 7 Jun 2007 19:35:51 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> PAE is useful for more than supporting more than 4GB RAM. It supports
>> expanded swapspace and NX executable protections. Some users may want
>> NX or expanded swapspace support without the overhead or instabili
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
> Absolutely. Let's get them into their final form now, rather than letting
> some intermediate interface escape out into a major kernel release.
Even if Linus' redirection is adopted, these interfaces should still be
fixed up.
> >
> > @@ -5640,6 +5645,7 @@ int __init sbpcd_init(void)
> > int i=0, j=0;
> > int addr[2]={1, CDROM_PORT};
> > int port_index;
> > + int request_region_flag;
> >
> One could argue that it would be possible to just use the 'j' variable
> for this since it's not used
Andrew Morton wrote:
> On Fri, 08 Jun 2007 07:51:12 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> I'd have hoped to see containerstats.c in here.
>>>
>> The current statistics code is really small, so it fit into taskstats.c.
>> May be in the future, we could re-facto
On Thu, 7 Jun 2007 19:35:51 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
> PAE is useful for more than supporting more than 4GB RAM. It supports
> expanded swapspace and NX executable protections. Some users may want
> NX or expanded swapspace support without the overhead or instability
On Fri, 08 Jun 2007 07:51:12 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >
> > I'd have hoped to see containerstats.c in here.
> >
>
> The current statistics code is really small, so it fit into taskstats.c.
> May be in the future, we could re-factor it and move it ou
On Thu, 07 Jun 2007 20:04:41 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Masoud Asgharifard Sharbiani wrote:
> > Hello,
> > This patch makes the i386 behave the same way that x86_64 does when a
> > segfault happens. A line gets printed to the kernel log so that tools
> > that need to check f
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want
NX or expanded swapspace support without the overhead or instability
of highmem. For these reasons, the following patch divorces
CONFIG_X86_PAE from CONFIG_HIG
On Thu, 7 Jun 2007, Steven Rostedt wrote:
>
> I didn't realize that userspace was allowed to run with interrupts
> disabled.
It isn't, normally. You *can* try to do it by using iopl(), but it's not
practical. It's certainly not practical to expect a page fault to not
enable them again, since
On Thu, 7 Jun 2007, Andrew Morton wrote:
>
> Interrupts got disabled here because do_page_fault() is an
> interrupt-disabling trap, yes?
Yes - and it has to be: we want to disable preemption and interrupts that
can fault on the vmalloc space, until we've at least saved away %cr2. We
had bugs
On 6/7/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> this needs tasklist_lock?
>
rcu_read_lock() should be fine. From Eric's patch at
2.6.17-mm2 - proc-remove-tasklist_lock-from-proc_pid_readdir.patch
The patch mentions that "We don't need the tasklist_lock to safely
iterate through processes
On Thu, 7 Jun 2007, Matt Mackall wrote:
>
> First, how does this work in-kernel? Does it set a flag in the thread
> struct that magically gets used in the actual syscall? Or do we pass
> flags down to the sys_foo() function in some manner?
Set a flag in the thread-struct.
In fact, that's how "
Andrew Morton wrote:
>
> I'd have hoped to see containerstats.c in here.
>
The current statistics code is really small, so it fit into taskstats.c.
May be in the future, we could re-factor it and move it out.
>> +#ifndef _LINUX_CONTAINERSTATS_H
>> +#define _LINUX_CONTAINERSTATS_H
>> +
>> +#incl
Jeff> On Thu, Jun 07, 2007 at 09:56:06PM -0400, John Stoffel wrote:
>> Thinking about it more, I wonder if Krysztof is bitching more about
>> the tab width of 8 characters? I know that it ticks me off,
Jeff> Even if he is, _that_ is definitely not getting changed.
Oh sure... I know that part i
On Thu, Jun 07, 2007 at 09:56:06PM -0400, John Stoffel wrote:
> Thinking about it more, I wonder if Krysztof is bitching more about
> the tab width of 8 characters? I know that it ticks me off,
Even if he is, _that_ is definitely not getting changed.
That was the very first item Linus wrote in
On Thu, 2007-06-07 at 18:58 -0700, Andrew Morton wrote:
> On Wed, 06 Jun 2007 23:34:04 -0400
> Interrupts got disabled here because do_page_fault() is an
> interrupt-disabling trap, yes?
Correct.
>
> The patch looks reasonable to me: a slight reduction in interrupt-off
> latency when really wei
Masoud Asgharifard Sharbiani wrote:
Hello,
This patch makes the i386 behave the same way that x86_64 does when a
segfault happens. A line gets printed to the kernel log so that tools
that need to check for failures can behave more uniformly between
different kernels. Like x86_64, it can be disabl
On Wed, 06 Jun 2007 23:34:04 -0400
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> This is a minor fix, but what is currently there is essentially wrong.
> In do_page_fault, if the faulting address from user code happens to be
> in kernel address space (int *p = (int*)-1; p = 0xbed;) then the
> do_pa
Justin Piszcz wrote:
Note that your boot also mentions this:
[ 106.449661] mtrr: no more MTRRs available
which indicates that things like X may not be able to map the
framebuffer with the 'write-combine' attribute, which will hurt
performance. I've heard reports that turning of 'Intel QST fan
Jeff> On Thu, Jun 07, 2007 at 09:44:57PM -0400, John Stoffel wrote:
>> I don't. I use a pair of 80x48 xterms or emacs windows side by side
>> on my monitor with a nice big clear easy to read font. Itty bitty
Jeff> That's pretty much what I do. For me at least, it's a more
Jeff> efficient use o
On Thu, 07 Jun 2007, Mark Lord wrote:
> Henrique de Moraes Holschuh wrote:
> >On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> >>HDAPS support is available, revision is MB2IA60A.
> >
> >That would usually rule out the possibility of it being the firmware, but
> >we
> >have different disks, so differ
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 10:08:29 +0200
> There are races involving the garbage collector, that can throw away
> perfectly good packets with AF_UNIX sockets in them.
>
> The problems arise when a socket goes from installed to in-flight or
> vice versa during
On Thu, Jun 07, 2007 at 09:44:57PM -0400, John Stoffel wrote:
> I don't. I use a pair of 80x48 xterms or emacs windows side by side
> on my monitor with a nice big clear easy to read font. Itty bitty
That's pretty much what I do. For me at least, it's a more efficient
use of screen real estate,
Krzysztof> Perhaps we should drop that 80-column style and use some
Krzysztof> 120+? X or no X, almost all people now have more lines and
Krzysztof> columns on their displays than MDA 20 years ago.
I don't. I use a pair of 80x48 xterms or emacs windows side by side
on my monitor with a nice big
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 8 Jun 2007 08:54:52 +1000
> On Thu, Jun 07, 2007 at 03:06:53PM -0700, Andrew Morton wrote:
> >
> > > I'm not able to bring an ethernet interface down and back up again
> > > with this if avahi-autoipd is installed on my Ubuntu boxes. I've seen
>
On Thursday, June 7, 2007 5:20:50 Andrew Morton wrote:
> > -unsigned int *usage_table;
> > +unsigned int usage_table[NUM_VAR_RANGES];
> > static DEFINE_MUTEX(mtrr_mutex);
>
> didn't it feel all dirty when you had to do that?
Hey, this was already there... I didn't want to rewrite the whole thing
On Thu, Jun 07, 2007 at 06:08:32PM -0700, H. Peter Anvin wrote:
> My big concern with the 80-column rule is that it discourages commenting.
My concern with that logic is that encourages random, super-wide code
lines that varies with each coder. You are left to the mercy of he with
the widest text
On Thu, Jun 07, 2007 at 04:19:56PM -0700, H. Peter Anvin wrote:
> Oleg Verych wrote:
> >
> > Because of that, i think, following is redundant:
> >
> > - to check for binary files
>
> find . -type f | xargs cleanfile
What about patches?
Anyway, by agreement (with myself), i've stopped on having
On Thu, 7 Jun 2007 11:46:53 +1000
NeilBrown <[EMAIL PROTECTED]> wrote:
> do_generic_mapping_read currently samples the i_size at the start
> and doesn't do so again unless it needs to call ->readpage to load
> a page. After ->readpage it has to re-sample i_size as a truncate
> may have caused tha
Krzysztof Halasa wrote:
> Alistair John Strachan <[EMAIL PROTECTED]> writes:
>
>> I personally buy the argument that 80 cols helps remind people that they've
>> used too many indentation depths and should redesign their code.
>> I think it's
>> a good thing to stick to where possible, even if ju
On Wed, Jun 06, 2007 at 04:16:42PM -0700, Darrick J. Wong wrote:
> On Wed, Jun 06, 2007 at 12:35:14PM -0700, Siddha, Suresh B wrote:
>
> > Weird. Then the bug can only happen if for some reason, "mask = map"
> > didn't happen in fixup_irqs(). Can you send us the disassembly of the
> > fixup_irqs()
On Thu, Jun 07, 2007 at 01:10:23PM -0700, Linus Torvalds wrote:
> What do people think about that kind of approach? It has the advantage
> that it does *not* involve multiple kernel entries (just a single entry to
> a small wrapper that sets some process state temporarily), and that it
> doesn't
john stultz wrote: [Thu Jun 07 2007, 03:54:41PM EDT]
[snip]
john you are welcome.
We aren't sampling for holes in memory. Thus we encounter a section hole with
empty section map pointer for SPARSEMEM and OOPs for show_mem. This issue
has been seen in 2.6.21, current git and current mm. The pa
I am trying to create valid "struct page* (*get_xip_page)(struct
address_space *, sector_t, int)" to use the filemap_xip.c.
I've been trying to do it as follows:
virtual = ioremap(physical,size);
struct page* my_get_xip_page(struct address_space *mapping, sector_t
sector, int create)
{
unsigne
The recent PRIVATE and REQUEUE_PI changes to the futex code made it hard to
read.
Tidy it up.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
kernel/futex.c | 192
kernel/rtmutex-debug.c |6 -
kernel/rtmutex.c|6
On Thu, 7 Jun 2007 08:34:58 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I assume the above is your code - it's not in the tree?
>
Ah, that code was disappeared in -mm2.
But it informed me that I should consider memory unplug v.s. sys_mremap case...
Thanks, anyway.
-Kame
-
To unsubscr
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
1. New entries can be added to tsk->pi_state_list after task completed
exit_pi_state_list(). The result is memory leakage and deadlocks.
2. handle_mm_fault() is called under spinlock. The result is obvious.
3. results in self-inflicted deadlock insi
Alexey Kuznetsov found some problems in the pi-futex code.
One of the root causes is:
When a wakeup happens, we do not to stop the chain walk so
we follow a not longer relevant locking chain.
Drop out when this happens.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
kernel/rtmutex.c
Alexey Kuznetsov found some problems in the pi-futex code.
The major problem is a stale return value in rt_mutex_slowlock():
When the pi chain walk returns -EDEADLK, but the waiter was woken up
during the phases where the locks were dropped, the rtmutex could be
acquired, but due to the stale r
Andrew,
the following patch series solves the issues with pi-futexes which
were reported from Alexey.
While the first three patches should go mainline ASAP, the last patch
is not necessarily 2.6.22 material. I did this cleanup to make the
code more readable again.
@stable:
The rtmutex patches (
Am 08.06.2007 00:25 schrieb Lars K.W. Gohlke:
>>> a) With a line discipline, [...]
>>> b) With the "serio" interface, [...]
>>>
>> ok because I want to handle it in kernel space I will no take option a)
>
>> I will try it the way of b)
> I asked [EMAIL PROTECTED] as one of the driver developer
>
On Wed, 6 Jun 2007 12:29:23 -0700
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> --- a/arch/i386/kernel/cpu/mtrr/if.c
> +++ b/arch/i386/kernel/cpu/mtrr/if.c
> @@ -12,7 +12,7 @@
> #include "mtrr.h"
>
> /* RED-PEN: this is accessed without any locking */
> -extern unsigned int *usage_table;
> +extern
On Thu, 7 Jun 2007 18:16:21 -0500
Anton Blanchard <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > zap_other_threads() requires tasklist_lock.
> >
> > If we're going to do this then we should probably create some new function
> > (with a better name) which takes tasklsit_lock and then calls
> > zap_ot
On Fri, Jun 08, 2007 at 12:41:17AM +0100, Alan Cox wrote:
> > I added a MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>") into the "raw"
> > module:
> >
> > # echo $LANG
> > C
> > # modinfo --version
> > module-init-tools version 3.3-pre11
> > # modinfo raw
> > filename: /lib/modules/2.6.21.2/
On Thu, 7 Jun 2007, Linus Torvalds wrote:
>
>
> On Thu, 7 Jun 2007, Davide Libenzi wrote:
> >
> > We'd still need sys_nonseqfd() though, to move/dup legacy fds into the
> > non-sequential area.
>
> Umm. No we don't. Because it's no more than
>
> indirect_syscall(dup, FD_NONSEQ)
>
> i
On Wed, 06 Jun 2007 11:57:07 -0700
[EMAIL PROTECTED] wrote:
> +#ifdef CONFIG_DMAR_GFX_WA
> + iommu_prepare_gfx_mapping();
> +#endif
Please do
#ifndef CONFIG_DMAR_GFX_WA
static inline void iommu_prepare_gfx_mapping(void)
{
}
#endif
in the head file instead (whole patchset)
-
To unsubscribe f
On Wed, 06 Jun 2007 11:57:04 -0700
[EMAIL PROTECTED] wrote:
> Actual intel IOMMU driver. Hardware spec can be found at:
> http://www.intel.com/technology/virtualization
>
> This driver sets X86_64 'dma_ops', so hook into standard DMA APIs. In this
> way,
> PCI driver will get virtual DMA a
1 - 100 of 563 matches
Mail list logo
