Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
>
> On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
>
> >
> > Hi,
> >
> > (sorry for the long delay)
> >
> > On Wednesday 21 February 2007, Suleiman Souhlal wrote:
> >> IDE error recovery is using WIN_IDLEIMMEDIATE which was on
On Mar 8, 2007, at 12:34 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery is
Commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a added support for using the
ADMA notifier bits to determine which commands to check for completion.
However there have been reports that this causes command timeouts in certain
cases. This is still being investigated. In addition, apparently the noti
On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said:
> This is a request for comments for a new Integrity Based Access
> Control(IBAC) LSM module which bases access control decisions
> on the new integrity framework services.
>
> (Hopefully this will help clarify the interaction between an LSM
> m
Fix atomicity of TIF update in flush_thread() for x86_64
Race :
parent process executing :
sys_ptrace()
(lock_kernel())
(ptrace_get_task_struct(pid))
arch_ptrace()
ptrace_detach()
ptrace_disable(child);
clear_singlestep(child);
clear_tsk_thread_flag(child, TIF_SINGLESTE
Fix sparc TIF_USEDFPU flag atomicity
Non atomic update of TIF can be very dangerous, except at thread structure
creation time. Here I standardize the TIF_USEDFPU usage of the sparc arch.
Applies on 2.6.20.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/arch/sparc/kernel/process.c
++
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> s/do/will (smpboot.c)
Well the current Xen mechanism rather dodges all of that (for bits like
IPI apicid).
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Our code is in the tree now, and any attempts to break it using such
> justifications as easing maintenance for kernel developers in future
> releases are flat out false and improper.
That's not quite accurate. This is what Ingo was complaining abou
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the APIC.
While that's basically what we did in Xen, it would make more sense to
bui
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > Chris, would you like to work together on this? I don't know what
> > Xen's requirements are for the APIC interface. Do you think we
> > could come up with something that would fit both of our needs, and
> > maybe also be usable for some of the s
* Daniel Arai ([EMAIL PROTECTED]) wrote:
> Chris, would you like to work together on this? I don't know what Xen's
> requirements are for the APIC interface. Do you think we could come up
> with something that would fit both of our needs, and maybe also be usable
> for some of the subarch-spec
Chris Wright wrote:
> * Daniel Arai ([EMAIL PROTECTED]) wrote:
>
>> There's no good way to override __send_IPI_shortcut. I suppose we could add
>> paravirt ops for __send_IPI_shortcut and every other op that touches the
>> APIC.
>>
>
> While that's basically what we did in Xen, it would
Chris Wright wrote:
> I agree with that, but I think that's esp. for things like create and launch
> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> as well.
>
Well, native would fall back to using the existing arch/i386 versions of
those functions, so that's reason
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > While that's basically what we did in Xen, it would make more sense
> > to build it into genapic which would give us one common abstraction
> > to base from. We should avoid adding pv_ops when existing
> > infrastructure exists.
>
> I was
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > * Daniel Arai ([EMAIL PROTECTED]) wrote:
> >
> >> There's no good way to override __send_IPI_shortcut. I suppose we could
> >> add
> >> paravirt ops for __send_IPI_shortcut and every other op that touches the
> >> API
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > I agree with that, but I think that's esp. for things like create and launch
> > new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> > as well.
> >
>
> Well, native would fall back to using the e
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Chris Wright wrote:
>>
>>> I agree with that, but I think that's esp. for things like create and launch
>>> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
>>> as well.
>>>
>>>
>
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
>> that's a concern, but maybe we can tease it apart in a sensible way.
>>
>
> Yes, that's exactly what I'm saying. Same with above (the nati
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
> that's a concern, but maybe we can tease it apart in a sensible way.
Yes, that's exactly what I'm saying. Same with above (the native stuff), since
we don't want a bunch o
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Maybe hooking into genapic is the right way to mop up all the uses of
>> send_IPI and its variants. But from a quick grep it doesn't look like
>> they get called from too many places... Most of the callers seem to be
>
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
mo
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants. But from a quick grep it doesn't look like
> they get called from too many places... Most of the callers seem to be
> in arch/i386/kernek/smp.c, so
Zachary Amsden wrote:
> We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> > We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> > interrupt subsystem.
>
> Can you not just use the apic clock driver directly then? Do you need
> to do anything special?
exactly. There are only tw
On Thursday 08 March 2007 21:46, Zachary Amsden wrote:
> Thomas Gleixner wrote:
> > On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
> >
> The correct solution here is to properly separate the APIC, SMP, and
> timer code so the logic of it which we want to reuse is separated f
> what we do _NOT_ want is some mixture of 'simplified' and 'hardwired'
> native hardware access mixed with hypercalls that somehow ends up
> creating a Frankenstein mixture of 'virtual silicon', is specified
> nowhere else but in VMWare's proprietary hypervisor source code that we
> have no w
>
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants.
It is. More hooks in this are wouldn't be appreciated.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
The apic clock driver is going to program the apic,
Andi Kleen wrote:
At least in Linux we don't really work with deadlines; if there
are issues they need to be fixed even if it takes longer. I don't
expect the version in .21 to be really usable anyways; it is clearly
still in development.
It was working, and I expect to have it working ag
Ingo Molnar wrote:
> - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
>quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
lower-level ones, so that guests can meaningfully participate in their
own v
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as its
being used in a way that's consistent with its intended in
On Thu, 2007-03-08 at 15:39 -0800, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
> >quite advanced on this front.
>
> At last! Some love!
>
> The Xen approach has always been to prefer high-level interfaces over
Zachary Amsden wrote:
> For APICs, we have two operations - APICRead and APICWrite. It is
> nice and clean, and plugs in very easily to the APIC accessors
> available in Linux.
>
> Is this not clean?
Sure, that's clean, From that perspective the apic is a bunch of
registers backed by a state mach
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > No, but I'm not prejudiced against virtual hardware. If we have a piece
> > of code that thinks its talking to an apic, then I think its OK to use
> > that code whether its a real apic or a virtual one, _so l
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
>
> We just don't drive the local timer interrupts through the APIC, we make
> hypercalls to schedule local timer alarms. Which is something we must
> do for UP kernels as well, which use the PIT / PIC. So there is a need
> for having
[ I don't really want to be involved too much in this particular
discussion, but I'll pipe up quickly anyway.. ]
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > For APICs, we have two operations - APICRead and APICWrite. It is
> > nice and clean, and plugs in very
Thomas Gleixner wrote:
> Once you are there, you are near the point where you created a virtual
> architecture, which could run on any real architecture which gets
> supported by a hypervisor backend.
>
> I'd love that :)
>
Sure. But not even hypervisors. Once we sort out pv_ops's SMP support
On Mon, Feb 12, 2007 at 12:15:24AM -0800, [EMAIL PROTECTED] wrote:
> +static struct container_group *find_container_group(
> + struct container_group *oldcg, struct container *cont)
> +{
> + struct container_group *res;
> + struct container_subsys *ss;
> + int h = cont->hierarchy;
>
On Thu, Mar 08, 2007 at 01:10:24AM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > Please next time this kind of patch is posted add a description of
> > what is happening and why. I have yet to see people explain why
> > this is a good idea. Why the cu
On Thu, Mar 08, 2007 at 03:43:47PM +0530, Srivatsa Vaddagiri wrote:
> On Wed, Mar 07, 2007 at 08:12:00PM -0700, Eric W. Biederman wrote:
> > The review is still largely happening at the why level but no
> > one is addressing that yet. So please can we have a why.
>
> Here's a brief summary of wha
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
> "Paul Menage" <[EMAIL PROTECTED]> writes:
>
>> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>> But "namespace" has well-established historical semantics too - a way
>>> of changing the mappings of local * to global objects.
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Pretty much. For most of the other cases I think we are safe
>> referring to them as resource controls or resource limits. I know
>> that roughly covers what cpusets and beancou
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
> Matt Helsley <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
> >
> > +ADw-snip+AD4
> >
> > +AD4 Kirill, 06032418:36+-03:
> > +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> > +AD4 +
On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> > 7. resource namespaces
>
> It should be. Imagine giving 20% bandwidth to a user X. X wants to
> divide this bandwidth further between multi-media (10%), kernel
> co
Herbert wrote:
> why is the filesystem approach so favored for this
> kind of manipulations?
I don't have any clear sense of whether the additional uses of file
systems being considered here are a good idea or not, but the use of a
file system for cpusets has turned out quite well, in my (vain and
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local * to global objects. This
> accurately describes things liek resource controllers, cpusets, resource
> monitoring, etc.
No!
Cpusets don't rename or change the mapping of objects.
I suspect
> The real trick is that I believe these groupings are designed to be something
> you can setup on login and then not be able to switch out of. Which means
> we can't use sessions and process groups as the grouping entities as those
> have different semantics.
Not always on login. For big admin
Matt wrote:
> It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
Daniel Drake wrote:
> Andrew Johnson wrote:
> > When the console is in VT_AUTO/KD_GRAPHICS mode, switching to the
> > SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting
indefinately
> > or until the task is interrupted. The following patch tests if a
> > console switch can occur in set_co
On Thu, Mar 08, 2007 at 06:29:02PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > it tests whether the SA_RESTART flag works for the sem_wait operation.
> >
> > I see sem_wai
On Thursday 08 March 2007 13:54, Andrew Morton wrote:
> On Wed, 7 Mar 2007 17:43:45 -0800 Andrew Morton <[EMAIL PROTECTED]>
wrote:
> > On Wed, 7 Mar 2007 12:26:42 +1100
> >
> > Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > What follows is the same patch series that constitutes the RDSL
> > > "Rotat
On Fri, Mar 09, 2007 at 12:02:31AM +0100, Thomas Gleixner wrote:
> On Thu, 2007-03-08 at 18:29 +0100, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Ingo,
> > >
> > > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > > it tests whether the SA_
On Wed, Feb 21, 2007 at 02:36:40PM +0100, Stefan Richter wrote:
> Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.19.5 release.
> >
> > This will probably be the last release of the 2.6.19-stable series, so
> > if there are patches that you feel should be applied to tha
First off, let me say that I think your approach has great promise,
but I'm afraid it doesn't work so well here yet.
Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
test load.
With 2.6.21-rc2-mm2, I get slightly sluggish response for opening new
terminals, scrolling in Galeon
Michael K. Edwards a écrit :
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool
might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unles
__builtin_types_compatible_p() has been around since gcc 2.95, and we
don't use it anywhere. This patch quietly fixes that.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r f0ff8138f993 include/linux/kernel.h
--- a/include/linux/kernel.hFri Mar 09 16:40:25 2007 +1100
+++ b/include/li
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
-
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
Mockern a écrit :
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
Welcome Andy
Since your messages always make me wonder if you are some kind of robot, able
to post one "one line" message to lkml everyday, I have one suggestion :
Try next times to
On Fri, 09 Mar 2007 16:56:32 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
After staring at this for about 2 minutes, how about a commit message like:
Make ARRAY_SIZ
On Friday 09 March 2007 16:39, Matt Mackall wrote:
> First off, let me say that I think your approach has great promise,
> but I'm afraid it doesn't work so well here yet.
>
> Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
> test load.
>
> With 2.6.21-rc2-mm2, I get slightly s
On Thu, 8 Mar 2007, Bill Davidsen wrote:
>
> Please, could you now rethink plugable scheduler as well? Even if one had to
> be chosen at boot time and couldn't be change thereafter, it would still allow
> a few new thoughts to be included.
No. Really.
I absolutely *detest* pluggable schedulers.
On Fri, 9 Mar 2007, Rusty Russell wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
Whee.
Rusty, that's a work of art.
However, I would suggest that you never show it to anybody ever again. I'm
sure that i
On Wednesday 07 March 2007 3:48 pm, Chris Lesiak wrote:
> From: Chris Lesiak <[EMAIL PROTECTED]>
>
> This patch fixes a bug in the cleanup of an spi_bitbang bus.
It's nearly right, but see below.
> @@ -505,28 +499,10 @@ EXPORT_SYMBOL_GPL(spi_bitbang_start);
> */
> int spi_bitbang_stop(struc
Hi!
> Pavel, I tried with your .config, and indeed the system came back to life
> after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test that
On 068, 03 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95,
but it's not available in Intel C compiler IIRC :(
> and we don't use it anywhere. This patch quietly fixes that.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> That sounds like a rather fragile approach to avoiding a minimal amount of
> work. Debug exceptions don't occur very often, and when they do it won't
> matter too much if we go through some extra notifier-chain callouts.
When single-stepping occurs it happens repeatedly many times, and that
d
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> On Thu, 8 Mar 2007, Bill Davidsen wrote:
> > Please, could you now rethink plugable scheduler as well? Even if one had to
> > be chosen at boot time and couldn't be change thereafter, it would still
> > allow
> > a few new thoughts
On Friday, 9 March 2007 02:11, Len Brown wrote:
> On Wednesday 07 March 2007 18:13, Rafael J. Wysocki wrote:
> > On Wednesday, 7 March 2007 23:49, Andrew Morton wrote:
> > > On Wed, 7 Mar 2007 23:14:29 +0100
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday, 7 March 2
hello,
The manpage of "swapon" function since Linux 2.6.17 has some error.
The MAX_SWAPFILES should be 30 in the latest version. Swap migration uses
the two higest numbers of swap types (30 and 31).
Regards
Zhang Xiliang
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Description: Check the return value of kmalloc() in function
videocodec_build_table(), in file drivers/media/video/videocodec.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/videocodec.c b/drivers/media/video/videocodec.c
index 2ae3fb2..16fc1dd 100644
--- a/
Description: Check the return value of kmalloc() in function ch_readconfig(),
in file drivers/scsi/ch.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index f6caa43..fcd635b 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -324,7 +3
Description: Check the return value of kmalloc() in function cifs_readdir(), in
file fs/cifs/readdir.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index b5b0a2a..2d43b2a 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -1063,6 +1
Description: Check the return value of kmalloc() in function mos7840_get_reg(),
in file drivers/usb/serial/mos7840.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 021be39..91d474b 100644
--- a/drivers/usb/serial/
Description: Check the return value of kmalloc() in function
stv680_start_stream(), in file drivers/media/video/stv680.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/stv680.c b/drivers/media/video/stv680.c
index 6d1ef1e..a1ec3ac 100644
--- a/drivers/media/v
Description: Check the return value of kmalloc() in function
stv680_start_stream(), in file drivers/media/video/stv680.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/stv680.c b/drivers/media/video/stv680.c
index 6d1ef1e..f35c664 100644
--- a/drivers/media/v
Description: Check the return value of kmalloc() in function setup_cpu_cache(),
in file mm/slab.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/mm/slab.c b/mm/slab.c
index 84c631f..613ae61 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2021,6 +2021,7 @@ static int setup_cpu_cache(s
Description: Check the return value of kmalloc() in function i810_open(), in
file sound/oss/i810_audio.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/sound/oss/i810_audio.c b/sound/oss/i810_audio.c
index 240cc79..a415967 100644
--- a/sound/oss/i810_audio.c
+++ b/sound/oss/i810
Description: Change in error message in function fore200e_kmalloc(), in file
drivers/atm/fore200e.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 3a7b21f..1c7ea02 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200
Description: Check the return value of kmalloc() in function dbg_kmalloc(), in
file net/wanrouter/wanmain.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/net/wanrouter/wanmain.c b/net/wanrouter/wanmain.c
index 316211d..263450c 100644
--- a/net/wanrouter/wanmain.c
+++ b/net/wanr
Description: Check the return value of kmalloc() in function con_init(), in
file drivers/char/vt.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 87587b4..6aa08cb 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2640,6 +2640,
Description: Fix error-path leak in function jffs2_scan_medium(), in file
fs/jffs2/scan.c
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index e241346..cd9ed6e 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -130,6 +130,8 @@ #endif
Description: Check the return value of kmalloc() in function agp_sgi_init(), in
file drivers/char/agp/sgi-agp.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/char/agp/sgi-agp.c b/drivers/char/agp/sgi-agp.c
index d73be4c..5897e6c 100644
--- a/drivers/char/agp/sgi-agp.c
+
Description: Check the return value of kmalloc() in function
se401_start_stream(), in file drivers/media/video/se401.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 7aeec57..006c818 100644
--- a/drivers/media/video
From: Amit Choudhary <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 23:26:54 -0800
> Description: Check the return value of kmalloc() in function dbg_kmalloc(),
> in file net/wanrouter/wanmain.c.
>
> Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
There is no reason for any subsystem to implement
On Thu, 8 Mar 2007 22:21:37 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Fix avr32 TIF atomicity in do_debug_priv
>
> avr32 updates the thread flags 1 - non atomically and 2 - with the wrong value
> (for TIF_SINGLE_STEP) in this function.
>
> It applies to 2.6.20.
Thanks, but this has a
Hi!
> Prevent the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> from triggering by disabling nonboot CPUs before we finally enter the platform
> suspend.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> kernel/power/disk.c |1 +
> kernel/power/user.c |
I understand the NOMMU situation, and you are already screwed by
PTRACE_ATTACH. What I meant to suggest is that I would start from a
safety point of view with get_user_pages/access_process_vm refusing to
do force&&write to MAP_PRIVATE pages that are in fact being shared
(ETXTBSY or something). (W
On Fri, Mar 09, 2007 at 02:05:24PM +1100, Rusty Russell wrote:
> diff -r fdc8cbc1fd61 drivers/block/lguest_blk.c
> --- a/drivers/block/lguest_blk.c Thu Mar 08 13:35:39 2007 +1100
> +++ b/drivers/block/lguest_blk.c Thu Mar 08 15:51:55 2007 +1100
> @@ -45,6 +45,16 @@ struct blockdev
>
On Fri, Mar 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r f0ff8138f993 include/linux/kernel.h
> --
On Fri, Mar 09, 2007 at 09:50:56AM +0300, Andrey Panin wrote:
> On 068, 03 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> > __builtin_types_compatible_p() has been around since gcc 2.95,
>
> but it's not available in Intel C compiler IIRC :(
So what?
-
To unsubscribe from this list: send t
On Wednesday, 7 March 2007 22:07, Pavel Machek wrote:
> Hi!
>
> > Prevent the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> > from triggering by disabling nonboot CPUs before we finally enter the
> > platform
> > suspend.
> >
> > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTE
Hello,
On Thu, 08 Mar 2007 18:15:12 +0100, Patrick McHardy wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+ /* Equivalent to:
+* -A chaos -m statistic --mode random --probability \
+* $reject_percentage -j REJECT --reject-with host-unreach;
+* -A
On Wed, 7 Mar 2007, Pete Zaitcev wrote:
> On Wed, 7 Mar 2007 17:18:29 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > I've never heard of a process failing to show up in a SysRq-t listing. It
> > suggests something is wrong with the process management in the kernel you
> > were using.
Jan Engelhardt wrote:
[]
> The other thing is, the bitmap is supposed to be written out at intervals,
> not at every write, so the extra head movement for bitmap updates should
> be really low, and not making the tar -xjf process slower by half a minute.
> Is there a way to tweak the write-bitmap-t
--- Michael Tokarev <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> []
> > The other thing is, the bitmap is supposed to be
> written out at intervals,
> > not at every write, so the extra head movement for
> bitmap updates should
> > be really low, and not making the tar -xjf process
> slow
Andy Isaacson wrote:
When iterating through an array, one must be careful to test one's index
variable rather than another similarly-named variable.
The loop will read off the end of conf->disks[] in the following
(pathological) case:
% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
% for
On Thu, Mar 08, 2007 at 09:37:46PM -0500, Bill Davidsen wrote:
> Andy Isaacson wrote:
> >% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
> >% for i in 2 3 4; do dd if=/dev/zero of=d$i bs=1k count=$(($i+150)); done
[snip]
> >-for (j=i; i >+for (j=i; j >
On Monday 05 March 2007 05:35, Antonino A. Daplas wrote:
> On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> >
> > If you find your name in the Cc header, you are either su
Hi!
> Port (and memory) addresses can be dynamically generated by the AML code
> and thus, there is no way that the ACPI subsystem can statically predict
> any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
It would be nice if next version of acpi specs support
On Wed, 07 Mar 2007 06:09:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Adrian Bunk wrote:
> > Subject: AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter : Ash Milsted <[EMAIL PROTECTED]>
> > Status : unknown
>
>
> sounds like a B
301 - 400 of 539 matches
Mail list logo
