On Sat, 2 Jun 2007 10:34:03 +0400 Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> | That patch is DOA, methinks.
> |
>
> Andrew, what does it mean - "DOA"? Dead on arrival?
yes - I dropped it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
On Fri, Jun 01, 2007 at 06:59:25PM -0700, Venki Pallipadi wrote:
> Hmmm. How about having a new cpufreq_sysfs entry to say
> these CPUs are frequency dependent in hardware.
Wait, wasn't this the entire purpose of affected_cpus in the first
place? So we could see which CPUs would be affected by
[Andrew Morton - Fri, Jun 01, 2007 at 10:43:39PM -0700]
| On Sat, 02 Jun 2007 00:17:51 -0500 Eric Sandeen <[EMAIL PROTECTED]> wrote:
|
| > Andrew Morton wrote:
| > > On Fri, 01 Jun 2007 17:37:49 -0500
| > > Eric Sandeen <[EMAIL PROTECTED]> wrote:
| >
| > >> going for the inode_lock twice?
| > >>
On Sat, 02 Jun 2007 00:17:51 -0500 Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 01 Jun 2007 17:37:49 -0500
> > Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> >> going for the inode_lock twice?
> >>
> >
> > lockdep should catch that.
> >
>
> hey that's a good idea...!
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
This batch fixes two places where Linux currently fails to load tables
of the format that we expect OEM's to soon ship -- OEMx and
packages-as-method-arguments for _DSM. In both cases the
Andrew Morton wrote:
On Fri, 01 Jun 2007 17:37:49 -0500
Eric Sandeen <[EMAIL PROTECTED]> wrote:
going for the inode_lock twice?
lockdep should catch that.
hey that's a good idea...! *sigh* sometimes I worry about myself... but
hey at least I got it right. :)
=
On Thu, May 31, 2007 at 06:43:46PM -0400, Mark Lord wrote:
> Jeff Garzik wrote:
> >Mark Lord wrote:
> >>Some cards may perform better when their "memory" interface is used
> >>instead of the "I/O" interface, or vice-versa. I'm not sure which
> >>of the two methods was selected by libata (probably
On Fri, 1 Jun 2007 21:45:15 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Fri, 1 Jun 2007, Andrew Morton wrote:
>
> > They are different instances which happen to have the same length (zero).
>
> I guess one could use the slab allocators as a type of reservation
> ticket genera
Hi, I appear to be missing quite a bit of RAM on an x86_64 system. I
have 1GB installed, but 'free' only shows 878MB:
pokey$ free -m
total used free sharedbuffers cached
Mem: 878571306 0 52332
-/+ buffers/cache
On Fri, 1 Jun 2007, Andrew Morton wrote:
> They are different instances which happen to have the same length (zero).
I guess one could use the slab allocators as a type of reservation
ticket generator with zero sized objects. Hmmm But is that really a
useful thing to do?
> But the code wil
[EMAIL PROTECTED] writes:
>Experience over on the Windows side of the fence indicates that "remote bad
>guys get some local user first" is a *MAJOR* part of the current real-world
>threat model - the vast majority of successful attacks on end-user boxes these
>days start off with either "Get user t
Olaf Dietsche wrote:
> resume from suspend to ram doesn't work for my laptop and never
> has. So, this is not a regression.
>
> Hibernate (aka suspend to disk) works, however.
>
> When I resume, everything seems to come up (fan becomes busy, disk and
> dvd spin up for a short time), but the mach
On Fri, 1 Jun 2007 21:01:09 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Fri, 1 Jun 2007, Andrew Morton wrote:
>
> > > On Fri, 1 Jun 2007 18:37:46 -0700 (PDT) Christoph Lameter <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > +#define ZERO_SIZE_PTR ((void *)16)
> >
> > Jeremy's po
This introduces
CONFIG_DEVELKERNEL
If CONFIG_DEVELKERNEL is set then this is a development kernel.
Otherwise the kernel to be built is a a production kernel.
If CONFIG_DEVELKERNEL is set then the constant
DEVELKERNEL
is set to 1. Otherwise it is zero.
The following functions are defined in
Sorry if it was already reported.
MODPOST vmlinux
WARNING: arch/i386/kernel/built-in.o(.text+0x963a): Section mismatch:
reference to .init.text:amd_init_mtrr (between 'mtrr_bp_init'
and 'mtrr_attrib_to_str')
WARNING: arch/i386/kernel/built-in.o(.text+0x963f): Section mismatch:
reference to .i
On Fri, 1 Jun 2007, Andrew Morton wrote:
> > On Fri, 1 Jun 2007 18:37:46 -0700 (PDT) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> >
> > +#define ZERO_SIZE_PTR ((void *)16)
>
> Jeremy's point was a good one. The kernel _does_ use address-comparison
> to determine object-inequality in an un
"Darrick J. Wong" <[EMAIL PROTECTED]> writes:
> On Fri, Jun 01, 2007 at 06:18:32PM -0600, Eric W. Biederman wrote:
>
>> I doubt it. The practical problem is that cpu_down does not
>> and by design can not call the irq balancing part properly
>> and I haven't yet seen anything to suggest that we d
> On Fri, 1 Jun 2007 18:37:46 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
> wrote:
>
> +#define ZERO_SIZE_PTR ((void *)16)
Jeremy's point was a good one. The kernel _does_ use address-comparison
to determine object-inequality in an unknown but non-zero number of places.
It is of course un
On Fri, 01 Jun 2007, Jeff Garzik wrote:
> IIRC, Debian was the one OS that really did need a shutdown utility
> update, as the message says :)
Actually, editing /etc/init.d/halt is enough. Find the hddown="-h" and
change it to hddown="".
--
"One disk to rule them all, One disk to find them.
On Fri, 1 Jun 2007, Linus Torvalds wrote:
> So when I suggested the uglier
>
> if ((unsigned long)x <= 16)
> return;
>
> I really did mean to use that ugly cast.. Yours is prettier, but sadly,
> yours is simply not safe: a signed comparison might end up making _all_
> kerne
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> - if (!x)
> + if (x <= ZERO_SIZE_PTR)
> return;
Btw, this is _not_ safe.
A number of gcc versions have done signed arithmetic on pointers. It's
insane and stupid, but it happens, and it so happens to work on
architecture
On Friday June 1, [EMAIL PROTECTED] wrote:
> This is a debian stable system in production. Kernel 2.6.18.
> I upgraded the kernel from 2.6.8 to 2.6.18 about 2 weeks ago and saw no
> problems until today.
>
>
> May 30 12:58:00 bitc kernel: (scsi0:A:1:0): Unexpected busfree in
> Command phase
This
> > > + * The behavior for zero sized allocs changes. We no longer
> > > + * allocate memory but return ZERO_SIZE_PTR.
> > > + * WARN so that people can review and fix their code.
> >
> > I don't see why people have so much opposition to zero-size memory
> > allocations. There's all sorts of s
On Fri, Jun 01, 2007 at 06:18:32PM -0600, Eric W. Biederman wrote:
> I doubt it. The practical problem is that cpu_down does not
> and by design can not call the irq balancing part properly
> and I haven't yet seen anything to suggest that we don't migrate
> irq properly.
>
> So I'm guessing it
On Fri, 1 Jun 2007, John Anthony Kazos Jr. wrote:
> > +* The behavior for zero sized allocs changes. We no longer
> > +* allocate memory but return ZERO_SIZE_PTR.
> > +* WARN so that people can review and fix their code.
>
> I don't see why people have so much opposition to zero-size
This is a debian stable system in production. Kernel 2.6.18.
I upgraded the kernel from 2.6.8 to 2.6.18 about 2 weeks ago and saw no
problems until today.
May 30 12:58:00 bitc kernel: (scsi0:A:1:0): Unexpected busfree in
Command phase
May 30 12:58:00 bitc kernel: SEQADDR == 0x16c
May 30 12:58:00
> + * The behavior for zero sized allocs changes. We no longer
> + * allocate memory but return ZERO_SIZE_PTR.
> + * WARN so that people can review and fix their code.
I don't see why people have so much opposition to zero-size memory
allocations. There's all sorts of situations wh
they should merged into one
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
net/core/dst.c | 17 -
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 764bccb..c6a0587 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -111,1
>-Original Message-
>From: Darrick J. Wong [mailto:[EMAIL PROTECTED]
>Sent: Friday, June 01, 2007 11:44 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: Dependent CPU core speed reporting not updated
>with CPUFREQ_SHARED_TYPE_HW?
>
>On Thu, Mar 29, 2007 at 0
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>> But kernel threads also rely on userspace, due to e.g. fuse and usermode
>> helpers.
> Yes, I know that and I think these issues are solvable within the current
> approach.
It seems like it would be very hard to get writing of an image to a
fuse
On Fri, 01 Jun 2007 18:20:02 EDT, Andrey Vul said:
> I want to use the tickless timer features in 2.6.21, but
> unfortunately, the dependency for tickless timers is
> GENERIC_CLOCKEVENTS (and tickless is only in arch/i386).
>
> Any workarounds or solutions for non-x86 people?
>
> My CPU is AMD Tu
On Sat, 2 Jun 2007 02:59:33 +0200
Robert Gerlach <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have written a driver for the tablet buttons of (some?) Fujitsu Siemens
> tablet notebook. Can someone please review this (I'm a newbie here).
>
> Other questions, where should the modification button (fn) h
Please check with the server provider if multi-lun is supported with the
adapter you are using.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Reinaldo
Carvalho
Sent: Wednesday, May 30, 2007 4:10 PM
To: linux-kernel@vger.kernel.org
Subject: meg
I suspect the errors are coming because of bad disk(s).
Driver message indicates "reset" completed successfully.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jules Colding
Sent: Wednesday, May 30, 2007 4:00 AM
To: linux-kernel
Subject: LSI
Instead of returning the smallest available object return ZERO_SIZE_PTR.
A ZERO_SIZE_PTR can be legitimately used as an object pointer as long
as it is not deferenced. The dereference of ZERO_SIZE_PTR causes a
distinctive fault. kfree will handle a ZERO_SIZE_PTR in the same way as
NULL.
This ena
On Sat, 02 Jun 2007 00:10:46 +0200, Krzysztof Halasa said:
> "Scott Preece" <[EMAIL PROTECTED]> writes:
>
> > This is a question worth answering - is it rude to ack/nak a patch if
> > you're not a maintainer or otherwise known-to-be-trusted, or is it OK
> > for anyone to express an opinion? Andrew
On Fri, 1 Jun 2007, [EMAIL PROTECTED] wrote:
> On Fri, 01 Jun 2007 16:00:30 PDT, Linus Torvalds said:
>
> > #define BADPTR ((void *)16)
>
> > I bet you'd find *more* problems that way than by returning NULL, and
> > you'd also avoid the whole problem with "if (!ptr) return -ENOMEM".
>
> Hm
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>> It would have to, because of the way code32_start is defined to work.
>> We don't get control again after its use as a hook.
>>
>
> Who uses that hook? The impression I get is that the execution
> environment for jumpin
On Friday, June 1, 2007 6:05:39 Venki Pallipadi wrote:
> On Fri, Jun 01, 2007 at 02:41:57PM -0700, Jesse Barnes wrote:
> > On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
> > > And normally the MTRRs win, don't they (if I remember the table
> > > correctly) So if the MTRR says UC and PAT disagree
On Fri, Jun 01, 2007 at 02:41:57PM -0700, Jesse Barnes wrote:
> On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
> > And normally the MTRRs win, don't they (if I remember the table correctly)
> > So if the MTRR says UC and PAT disagrees it might not actually help
>
> I just checked, yes the MTRRs
H. Peter Anvin wrote:
> It would have to, because of the way code32_start is defined to work.
> We don't get control again after its use as a hook.
>
Who uses that hook? The impression I get is that the execution
environment for jumping to that pointer is not very well defined at present.
On Fri, 01 Jun 2007 16:00:30 PDT, Linus Torvalds said:
> #define BADPTR ((void *)16)
> I bet you'd find *more* problems that way than by returning NULL, and
> you'd also avoid the whole problem with "if (!ptr) return -ENOMEM".
Hmm.. this looks like a good contender for "first usage of #if
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> On Fri, 1 Jun 2007, Andrew Morton wrote:
>
> > I think it'd be better if we kept the WARN_ON_ONCE(size == 0) in there,
>
> The trouble with the WARN_ON is that it triggers even for code that is
> okay like noted by Jeremy.
Yes. Sometimes it's j
Jeremy Fitzhardinge wrote:
>
> Just to clarify:
>
> In my proposal is that we have bzImage structured something like (where
> "|" is concatenation, and "()" is a blob containing stuff):
>
> bzImage = 16-bit setup | ELF file (decompressor, compressed kernel)
>
>
> With the intention
Hi,
I have written a driver for the tablet buttons of (some?) Fujitsu Siemens
tablet notebook. Can someone please review this (I'm a newbie here).
Other questions, where should the modification button (fn) handled (kernel- or
userspace)? This button should work like stickykey's in gnome (for
o
Andrew Morton wrote:
> In some cases, sure, and we should remove the warning at some stage.
>
> But it has exposed a couple of bugs and a few weird things.
>
We just need to scatter better bug powder into the corners of the
allocations.
J
-
To unsubscribe from this list: send the line "unsubsc
H. Peter Anvin wrote:
> That's a method of defining the memory space.
>
> I think the current definition is suitable for entering at the 16-bit
> entry point.
I agree. I'm going to assume that if we're booting all the way up from
real mode, we're either on real hardware, or some environment that'
"John Anthony Kazos Jr." <[EMAIL PROTECTED]> writes:
> "Acked-by:" does not mean "I like this" but rather "I approve of this".
I'd say it means "I acknowledge it". If you want to express
approval, why not use some sort of "Approved-by"?
> If I put "Acked-by: John..." on a patch of any kind, even
On Fri, 01 Jun 2007 17:43:46 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> Andrew Morton wrote:
> > As I said, it's specific to the kmalloc(0) problem, and we're fixing that
> > by other means anyway.
> >
>
> I guess I'm not getting much traction in my campaign for equal rights
> for
This patch avoids holding the mmap semaphore while walking VMAs in response to
programs which read or follow the /proc//exe symlink. This also allows
us to merge mmu and nommu proc_exe_link() functions. The costs are holding the
task lock, a separate reference to the executable file stored in the t
> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So far, Hugh and Linus h
Linus Torvalds wrote:
> So for *both* of the above reasons, it's actually stupid to return NULL
> for a zero-sized allocation. It would be much better to return another
> pointer that will trap on access. A good candidate might be to return
>
> #define BADPTR ((void *)16)
>
I think this
Andrew Morton wrote:
> As I said, it's specific to the kmalloc(0) problem, and we're fixing that
> by other means anyway.
>
I guess I'm not getting much traction in my campaign for equal rights
for zero-sized allocations. They're perfectly reasonable things to have,
if that's the way the code f
On Fri, 2007-06-01 at 17:31 -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley ([EMAIL PROTECTED]):
> > On Wed, 2007-05-30 at 13:09 -0500, Serge E. Hallyn wrote:
> > > Quoting Matt Helsley ([EMAIL PROTECTED]):
> > > > This patch avoids holding the mmap semaphore while walking VMAs in
> > > > res
Jeremy Fitzhardinge wrote:
>
> Well, I think we can safely say that its something that's only
> meaningful in 32/64-bit mode, so we aren't constrained by the real-mode
> address space.
>
> One of my goals in this project is to make the boot image, in some way,
> completely define which memory it
Christoph Lameter wrote:
> Well there are architectural problems. We determine the power of two slab
> at compile time. The object size information is currently not available in
> the binary :=).
>
That only applies to allocations with constant sizes. One presumes
nobody is explicitly doing k
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make it possible to register hibernation and suspend notifiers, so that
subsystems can perform hibernation-related or suspend-related operations that
should not be carried out by device drivers' .suspend() and .resume() routines.
Signed-off-by: Rafael J
Hi,
This is the second revision of the patches that introduce hibernation and
suspend notifiers.
Generally, I have followed the Alan's suggestion to use a blocking notifier
chain and the Pavel's suggestion to limit the number of events. Also, I've
dropped the patch to disable the requesting of f
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the user mode helper before
a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/kmod.c | 33 +++--
1 fi
> > I think the comment had to do with the concept that ACK/NAK implies
> > authority. If you're not the maintainer, it's rude to imply that you
> > are. Obvious, test reports (good or bad!) are always welcome.
>
> Well, I understand a test is a different thing, an experiment to
> see if the pat
H. Peter Anvin wrote:
> Well, if we define is as a movable object then it has to be treated as
> such. It's a protocol definition issue. If we define it opaque, though
> -- of for that matter, if we don't -- we should define what memory it
> can live in, though. Right now, the only "available" m
On Saturday, 2 June 2007 01:54, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
>
> [snip]
>
> >> Just before jumping into the new kernel, with interrupts disabled, the
> >> old kernel could either
On Fri, 1 Jun 2007, Andrew Morton wrote:
> I think it'd be better if we kept the WARN_ON_ONCE(size == 0) in there,
The trouble with the WARN_ON is that it triggers even for code that is
okay like noted by Jeremy. My initial intend with NULL was to allow the
allocation of a zero sized pointer wi
> As a side note, on my very old SMP machine, 2.6.20 correctly
> load-balance IRQs across CPU but 2.6.21 not. I know that
> in-kernel IRQ load balancer is marked as deprecated and
> somewhat broken, but with your report it make me think it
> could be a bug in the IRQ rerouting part in my case too
This effectively makes channels a shared resource rather than tying them
to a specific client. dmaengine now assumes that clients will internally
track how many channels they need and dmaengine will learn if the client cares
about
a channel at dma_event_callback time. This also enables a client
In preparation for the async_tx (dmaengine client) API this patch:
1/ introduces struct dma_async_tx_descriptor as a common field for all
dmaengine software descriptors. The primary role of this structure
is to enable callbacks at transaction completion time, and support
transaction chain
Hello David,
The following two patches are part of the raid acceleration series I
would like to push for 2.6.23 consideration. I am sending these two
separately for your review for the following reasons: the 'dmaengine'
core initially came in through netdev, patch #2 makes changes to
net/dev/cor
On Fri, 1 Jun 2007 16:57:20 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Andrew, want to take this patch to -mm to see if it triggers anything?
spose so.
I think it'd be better if we kept the WARN_ON_ONCE(size == 0) in there,
because it is exposing some coding warts. But we should tu
On Fri, 1 Jun 2007, Linus Torvalds wrote:
> > A too large alloc is >32MB or MAX_ORDER << PAGE_SIZE. A BUG_ON in
> > kmalloc_slab() will trigger.
>
> Did we use to BUG_ON()? I think that's wrong. There are ways for users to
> potentially ask the kernel to do big allocations, and the correct resp
On Sat, June 2, 2007 00:17, Olaf Dietsche wrote:
> It doesn't work. I tried all options "s2ram -f (-s, -p, -m, -r, -a 1, -a 2,
> -a 3)" one after the other.
>
> Since the screen (or any other device) works without problems, when I
> skip acpi_enter_sleep_state(), I don't think it's screen related.
Jens Axboe wrote:
On Thu, May 31 2007, Phillip Susi wrote:
Jens Axboe wrote:
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violat
Robert Hancock wrote:
It's because you haven't done anything to handle the error which is
still persisting. Likely the only thing sane you can do in this case is
close the fd and try to reopen it later.
This seems to be true, but not for what you might think.
It appears that if u plug the U
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> A too large alloc is >32MB or MAX_ORDER << PAGE_SIZE. A BUG_ON in
> kmalloc_slab() will trigger.
Did we use to BUG_ON()? I think that's wrong. There are ways for users to
potentially ask the kernel to do big allocations, and the correct respons
Neil Brown wrote:
On Friday June 1, [EMAIL PROTECTED] wrote:
On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
[snip]
>> Just before jumping into the new kernel, with interrupts disabled, the
>> old kernel could either prepare a data structure that specifies what
>> pages are allocated, or alter
* Jesper Juhl ([EMAIL PROTECTED]) wrote:
> On 01/06/07, Piyush K <[EMAIL PROTECTED]> wrote:
> >Hi,
> >What is the kernel documentation mailing list where I can discuss
> >kernel documentation changes ?
> >Please cc to my email address too.
> >Thanks,
> >PYK
>
> As far as I know, there is no dedica
On Fri, 1 Jun 2007, Linus Torvalds wrote:
> I'm not seeing the path on the freeing side that silently accepts BADPTR.
>
> It is not ok to derefence BADPTR, but it's obviously ok to _free_ it.
Ok.
> Also, if I read the patch correctly, you _also_ return BADPTR for slabs
> that are too large. No
On Wed, 30 May 2007 20:09:44 -0300
"Reinaldo Carvalho" <[EMAIL PROTECTED]> wrote:
> Hi,
(cc's added) (CONFIG_SCSI_MULTI_LUN is set)
> I have a Dell PowerEdge Expandable RAID controller, with a hardware
> Raid-5 at Channel 01 running perfectly, and a nCipher Crypter at
> Channel 02.
>
> This con
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> Something like this? (Not tested yet just for review):
I'm not seeing the path on the freeing side that silently accepts BADPTR.
It is not ok to derefence BADPTR, but it's obviously ok to _free_ it.
Also, if I read the patch correctly, you _als
On Fri, 1 Jun 2007, Linus Torvalds wrote:
> No, I don't think you can do it this way.
Ultimately not. But its worth to see if this works.
> At a minimum, you'd need to test that the result is word-aligned.
> Preferably 8-byte aligned. We literally have stuff that knows about these
> things and
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> Hmmm... We are going rapidly here. This is a patch that I am testing right
> now. It right adjust the object and the patch is manageable:
No, I don't think you can do it this way.
At a minimum, you'd need to test that the result is word-aligned
Hi,
Can anyone please tell me who's administering the kernel bugzilla now?
I've tried to write to [EMAIL PROTECTED] , but this address seems
to point to nowhere.
The problem is that I'd like to have a new component called
"Hibernation-Suspend" in the kernel bugzilla's "Power Management" category
Hi.
On Sat, 2007-06-02 at 00:37 +0200, Rafael J. Wysocki wrote:
> On Saturday, 2 June 2007 00:17, Olaf Dietsche wrote:
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> >
> > > On Friday, 1 June 2007 23:12, Olaf Dietsche wrote:
> > >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> > >>
>
On Fri, 2007-06-01 at 14:02 -0700, Andrew Morton wrote:
>
>
> Yeah, allmodconfig tends to fall over in a heap on a lot of the
> less-lavishly-maintained architectures. If any of these are specific
> to
> -mm then I guess we should fix them up, prevent the kernel from
> actually
> going backwards
On Fri, 1 Jun 2007, Linus Torvalds wrote:
> So for *both* of the above reasons, it's actually stupid to return NULL
> for a zero-sized allocation. It would be much better to return another
> pointer that will trap on access. A good candidate might be to return
>
> #define BADPTR ((void *)
On Sat, Jun 02, 2007 at 12:18:40AM +0100, Russell King wrote:
> On Fri, Jun 01, 2007 at 04:10:53PM -0700, Deepak Saxena wrote:
> > The -rt patch adds a NR_syscalls symbol to the arm/unistd.h but
> > it is not the correct value as there are 348 syscalls on ARM
> > and the existing change sets the sy
On Fri, 1 Jun 2007, Andrew Morton wrote:
>
> We could store the size of the allocation in the allocated object? Just
> add four bytes to the user's request, then pick the appropriate cache based
> on that, then put the user's `size' at the tail of the resulting allocation?
It should be easy en
On Fri, 1 Jun 2007, Christoph Lameter wrote:
> Hmmm... We are going rapidly here. This is a patch that I am testing right
> now. It right adjust the object and the patch is manageable:
Does not boot sigh.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Ingo,
To prevent scheduling while irqs disabled, I added a force to the
do_page_fault to enable interrupts.
The thing is, if the user faults at an address above PAGE_OFFSET. My
stupid program that I attached to my last email did just that:
unsigned long *p = (void*)-1;
*p = 0xbed;
where (
On Fri, Jun 01, 2007 at 04:10:53PM -0700, Deepak Saxena wrote:
> The -rt patch adds a NR_syscalls symbol to the arm/unistd.h but
> it is not the correct value as there are 348 syscalls on ARM
> and the existing change sets the symbol to 322.
>
> Russell: Why isn't this in mainline? Other arches al
On 1 Jun, 19:40, "Lee Revell" <[EMAIL PROTECTED]> wrote:
On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> is it acceptable (although
> not nice) to simply fix it this way, by disabling irqs while it loads
> the firmware?
I would say to just disable IRQs while loading firmware. Almos
On Saturday, 2 June 2007 00:37, David Greaves wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 1 June 2007 23:23, David Greaves wrote:
> >> Not a regression though, it does it in 2.6.21
> >>
> >> If I cause the system to save state to disk then whilst off it no longer
> >> responds to g-wol.
> >
>
> So a kmalloc(62) would get upped to 66, so we allocate from size-128
> and put the number 62 at bytes 124-127 and we poison bytes 62-123?
Hmmm... We are going rapidly here. This is a patch that I am testing right
now. It right adjust the object and the patch is manageable:
SLUB mm-only: Righ
The -rt patch adds a NR_syscalls symbol to the arm/unistd.h but
it is not the correct value as there are 348 syscalls on ARM
and the existing change sets the symbol to 322.
Signed-off-by: Deepak Saxena <[EMAIL PROTECTED]>
---
Russell: Why isn't this in mainline? Other arches all seem to have
t
Andy Whitcroft wrote:
>
> I think that my debugging says that newsetup got the compressed kernel
> and decompressor into memory ok and execution passed to it normally.
> But I cannot figure out where the corruption is coming from. I tried
> annotating the gzip decompressor to see if the input and
> > This seems to be an interesting approach.
> >
> >
> Interesting but impossible to do for ioctl calls.
> When the application does a ioctl(fd_of_mnt_video0,VIDIOC_G_FMT,&arg)
> for example, there is no way for the userspace helper to catch this ioctl.
> The application could only open/read
On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Friday, 1 June 2007 22:39, Jeremy Maitin-Shepard wrote:
> >> I figured I'd throw this idea out, since although it is not perfect, it
> >> has the potential to elegantly solve a l
On Fri, 1 Jun 2007 15:41:48 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Jun 2007, Andrew Morton wrote:
>
> > > I should make SLUB put poisoning values in unused areas of a kmalloced
> > > object?
> >
> > hm, I hadn't thought of it that way actually. I was thinking it w
> >> + * Copyright (C) Nicolas VIVIEN
> >
> > It would be interesting to have Nicolas SOB as well, if possible.
>
> I don't think he ever knows about this version of the driver. I got his GPL
> driver, cleaned up -- coding style, v4l1 and v4l2 ioctl conversion to v4l2
> functions, some bug fixes
On Fri, 1 Jun 2007, Christoph Lameter wrote:
>
> Right it could catch a lot of other bugs as well.
I'd actually prefer "malloc(0)" to _not_ return NULL, but some known
(non-NULL) bogus pointer.
Why?
Because it's quite sane to have simple logic like
ptr = malloc(size);
if (!p
1 - 100 of 470 matches
Mail list logo
