Hi Greg,
On Tue, 18 Sep 2007, Greg KH wrote:
>
> On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
> >
> > But wait ... isn't that a statically-allocated kobject, which were
> > supposed to be "naughty" in the first place?
>
> Yes
> -static volatile int kgdb_hwbreak_sstep[NR_CPUS];
> +volatile int kgdb_hwbreak_sstep[NR_CPUS];
That looks fishy to me. Why is it volatile-qualified? And does that
actually want to be a per-cpu var?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
drivers/net/iseries_veth.c: In function 'veth_transmit_to_many':
drivers/net/iseries_veth.c:1174: warning: unused variable 'port'
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/iseries_veth.c |1 -
1 file changed, 1 deletion(-)
diff -ruNp a/drivers/net/iseries_ve
Of ethtool_ops->get_stats_count and ethtool_ops->get_ethtool_stats.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/mv643xx_eth.c |2 --
1 file changed, 2 deletions(-)
diff -ruNp a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643x
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/pasemi_mac.c
[PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
Unbreak the following:
drivers/net/
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/md/raid6int8.c
This turned out to be a gcc bug -- I was using an old cross-compiler.
-
To unsubscribe from this list: s
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/ata/pata_scc.c
http://lkml.org/lkml/2007/9/21/557
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Thu, 20 Sep 2007, Satyam Sharma wrote:
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/ata/pata_scc.c
http://lkml.org/lkml/2007/9/21/557
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, 20 Sep 2007, Satyam Sharma wrote:
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/md/raid6int8.c
This turned out to be a gcc bug -- I was using an old cross-compiler.
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 20 Sep 2007, Satyam Sharma wrote:
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c
On Thu, 20 Sep 2007, Satyam Sharma wrote:
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm
On Thu, 20 Sep 2007, Satyam Sharma wrote:
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/net/pasemi_mac.c
[PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
Unbreak the following:
drivers/net/pasemi_mac.c
Of ethtool_ops-get_stats_count and ethtool_ops-get_ethtool_stats.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/net/mv643xx_eth.c |2 --
1 file changed, 2 deletions(-)
diff -ruNp a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643xx_eth.c 2007-09
drivers/net/iseries_veth.c: In function 'veth_transmit_to_many':
drivers/net/iseries_veth.c:1174: warning: unused variable 'port'
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/net/iseries_veth.c |1 -
1 file changed, 1 deletion(-)
diff -ruNp a/drivers/net/iseries_veth.c b
-static volatile int kgdb_hwbreak_sstep[NR_CPUS];
+volatile int kgdb_hwbreak_sstep[NR_CPUS];
That looks fishy to me. Why is it volatile-qualified? And does that
actually want to be a per-cpu var?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Hi Greg,
On Tue, 18 Sep 2007, Greg KH wrote:
On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
But wait ... isn't that a statically-allocated kobject, which were
supposed to be naughty in the first place?
Yes it is, if you want to dynamically create it, please do
Hi,
On Sat, 22 Sep 2007, Andi Kleen wrote:
>
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
>
> These build warnings:
>
> In file included from include/asm/thread_info.h:16,
> from include/linux/thread_info.h:21,
> from include/linux/preempt.h:9,
> from
On Fri, 21 Sep 2007, Andrew Morton wrote:
>
> On Fri, 21 Sep 2007 13:39:06 +0400
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > Quite a few fields are zeroed during user_struct creation, so use
> > kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
> > #ifdef
8: warning: passing arg 5 of 'ata_bmdma_drive_eh' from
incompatible pointer type
make[2]: *** [drivers/ata/pata_scc.o] Error 1
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Mel Gorman <[EMAIL PROTECTED]>
---
Andrew, this includes (supercedes
type
make[2]: *** [drivers/ata/pata_scc.o] Error 1
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Mel Gorman [EMAIL PROTECTED]
---
Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
drivers/ata/pata_scc.c | 21 -
1
On Fri, 21 Sep 2007, Andrew Morton wrote:
On Fri, 21 Sep 2007 13:39:06 +0400
Alexey Dobriyan [EMAIL PROTECTED] wrote:
Quite a few fields are zeroed during user_struct creation, so use
kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
#ifdef
Hi,
On Sat, 22 Sep 2007, Andi Kleen wrote:
From: Satyam Sharma [EMAIL PROTECTED]
These build warnings:
In file included from include/asm/thread_info.h:16,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from include/linux
On Thu, 20 Sep 2007, Charles N Wyble wrote:
>
> Satyam Sharma wrote:
> >
> > On Tue, 18 Sep 2007, Charles N Wyble wrote:
> >> Andi Kleen wrote:
> >>> Besides it's bad taste and taste is very important.
> >> Well it's bad taste for you (on
On Tue, 18 Sep 2007, Charles N Wyble wrote:
>
> Andi Kleen wrote:
> >
> > Besides it's bad taste and taste is very important.
>
> Well it's bad taste for you (one person).
FWIW, my opinion is the same as Andi's here. Please, let's avoid this
disease -- unless *absolutely* required, stuff
On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
>
> Perhaps preinitialising to an error value such as -EINVAL would be of
> more sense. This way any error paths lacking initialisation are still
> reported as errors, even though the classification might be wrong.
Eeee ... at least I wouldn't
in 4.1.2 either?)
Satyam
> Satyam Sharma wrote:
> > Hi Maciej,
> >
> >
> > On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
> > >
> > > On Wed, 19 Sep 2007, Andrew Morton wrote:
> > > >
> > > > This initialisation to zero is not go
On Thu, 20 Sep 2007, Tetsuo Handa wrote:
>
> I checked my patch using checkpatch.pl version 0.10
> and I got the following error.
>
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #2334: FILE: security/tomoyo/common.c:2306:
> +static unsigned int tmy_poll(struct file *file,
Hi Maciej,
On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
>
> On Wed, 19 Sep 2007, Andrew Morton wrote:
>
> > > patch-mips-2.6.23-rc5-20070904-pmag-ba-err-2
> > > diff -up --recursive --new-file
> > > linux-mips-2.6.23-rc5-20070904.macro/drivers/video/pmag-ba-fb.c
> > >
On Thu, 20 Sep 2007, Mel Gorman wrote:
>
> allmodconfig on ppc64 fails to build with the following error
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/ata/pata_scc.c
drivers/md/raid6int8.c
drivers/net/spider_net.c
On Wed, 19 Sep 2007, Leonid Kalev wrote:
>
> ufs_get_fs_state() needs the file system type to read the state from the
> correct place in the superblock. It takes the type from UFS_SB(sb)->s_flags,
> but that value is stored after the first call to ufs_get_fs_state(). The patch
> below moves the
On Thu, 20 Sep 2007, Ken'ichi Ohmichi wrote:
>
> [PATCH 6/4] [-mm patch] use the existing offsetof().
> It is better that offsetof() is used for VMCOREINFO_OFFSET().
> This idea is Joe Perches's.
>
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Hi,
On Thu, 20 Sep 2007, Ken'ichi Ohmichi wrote:
>
> [PATCH 5/4] [-mm patch] Rename macros returning the size.
> The #define SIZE() should be renamed STRUCT_SIZE() since it's always
> returning the size of the struct with a given name. This would allow
> TYPEDEF_SIZE() to simply become
Hi Valdis,
On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote:
>
> On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:
>
> > I am assuming that if the laptop has sufficiently important data on
> > it to warrant the above steps then I am also clueful enough to:
> >(A) Not carry the laptop
On Wed, 19 Sep 2007, J. Bruce Fields wrote:
>
> Uh, is there somebody else that feels they're being enlightened by this
> discussion?
Ok, probably I got a bit too harsh with Kyle there. But what I don't
understand is why is it so hard for someone to accept they're wrong
on this list, thank the
On Wed, 19 Sep 2007, J. Bruce Fields wrote:
Uh, is there somebody else that feels they're being enlightened by this
discussion?
Ok, probably I got a bit too harsh with Kyle there. But what I don't
understand is why is it so hard for someone to accept they're wrong
on this list, thank the
Hi Valdis,
On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:
I am assuming that if the laptop has sufficiently important data on
it to warrant the above steps then I am also clueful enough to:
(A) Not carry the laptop around
Hi,
On Thu, 20 Sep 2007, Ken'ichi Ohmichi wrote:
[PATCH 5/4] [-mm patch] Rename macros returning the size.
The #define SIZE() should be renamed STRUCT_SIZE() since it's always
returning the size of the struct with a given name. This would allow
TYPEDEF_SIZE() to simply become SIZE()
On Thu, 20 Sep 2007, Ken'ichi Ohmichi wrote:
[PATCH 6/4] [-mm patch] use the existing offsetof().
It is better that offsetof() is used for VMCOREINFO_OFFSET().
This idea is Joe Perches's.
Thanks
Ken'ichi Ohmichi
---
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Same deal here
On Wed, 19 Sep 2007, Leonid Kalev wrote:
ufs_get_fs_state() needs the file system type to read the state from the
correct place in the superblock. It takes the type from UFS_SB(sb)-s_flags,
but that value is stored after the first call to ufs_get_fs_state(). The patch
below moves the
Hi Maciej,
On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, Andrew Morton wrote:
patch-mips-2.6.23-rc5-20070904-pmag-ba-err-2
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/drivers/video/pmag-ba-fb.c
On Thu, 20 Sep 2007, Tetsuo Handa wrote:
I checked my patch using checkpatch.pl version 0.10
and I got the following error.
ERROR: need consistent spacing around '*' (ctx:WxV)
#2334: FILE: security/tomoyo/common.c:2306:
+static unsigned int tmy_poll(struct file *file, poll_table
On Thu, 20 Sep 2007, Mel Gorman wrote:
allmodconfig on ppc64 fails to build with the following error
BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
IIRC I got build failures in:
drivers/ata/pata_scc.c
drivers/md/raid6int8.c
drivers/net/spider_net.c
drivers/net/pasemi_mac.c
?)
Satyam
Satyam Sharma wrote:
Hi Maciej,
On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, Andrew Morton wrote:
This initialisation to zero is not good.
Because if some error-path code forgot to do `err = -EFOO' then
probe() will return zero
On Thu, 20 Sep 2007, Maciej W. Rozycki wrote:
Perhaps preinitialising to an error value such as -EINVAL would be of
more sense. This way any error paths lacking initialisation are still
reported as errors, even though the classification might be wrong.
Eeee ... at least I wouldn't prefer
On Tue, 18 Sep 2007, Charles N Wyble wrote:
Andi Kleen wrote:
Besides it's bad taste and taste is very important.
Well it's bad taste for you (one person).
FWIW, my opinion is the same as Andi's here. Please, let's avoid this
disease -- unless *absolutely* required, stuff shouldn't
On Thu, 20 Sep 2007, Charles N Wyble wrote:
Satyam Sharma wrote:
On Tue, 18 Sep 2007, Charles N Wyble wrote:
Andi Kleen wrote:
Besides it's bad taste and taste is very important.
Well it's bad taste for you (one person).
FWIW, my opinion is the same as Andi's here. Please
t;[EMAIL PROTECTED]>
> Cc: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Thanks, Borislav.
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
On Wed, 19 Sep 2007, Kyle Moffett wrote:
>
> > [all sorts of crap about spies in washington needing stronger protection
> > than your average consumer]
>
> [snip]
>
> [...] all the bullcrap about foreign intelligence
Hehe, again, *you* started all the "bullcrap" about foreign "governments"
> On Mon, 17 Sep 2007 18:37:49 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
> >
> > > Untested (not even compile-tested) patch.
> > > Could someone point me to ppc32/64 cro
On Wed, 19 Sep 2007, Kyle Moffett wrote:
>
> On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
> >
> > The whole *point* here is to secure against physical access -- then how can
^^^
> > you assume "bar
On Wed, 19 Sep 2007, Kyle Moffett wrote:
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
The whole *point* here is to secure against physical access -- then how can
^^^
you assume barring disassembling the system? If you're
On Mon, 17 Sep 2007 18:37:49 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
OSDL had some, but those are gone now
On Wed, 19 Sep 2007, Kyle Moffett wrote:
[all sorts of crap about spies in washington needing stronger protection
than your average consumer]
[snip]
[...] all the bullcrap about foreign intelligence
Hehe, again, *you* started all the bullcrap about foreign governments
in the first
]
Thanks, Borislav.
Reviewed-by: Satyam Sharma [EMAIL PROTECTED]
-
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/
Hi Andries,
On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
>
> On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
>
> > > > On the other hand, this filesystem announces itself as UDF
> > > > ("CD-RTOS" "CD-BRIDGE" "CDUDF Fi
Hi Gilboa,
On Sat, 15 Sep 2007, Gilboa Davara wrote:
>
> This is my second stab at solving the "stack over flow due to
> dump_strace when close to stack-overflow is detected by do_IRQ" problem.
> (Hopefully) this patch is creates less noise then the previous one.
>
> [snip]
> > I'll try and
Hi,
On Tue, 18 Sep 2007, Jan Kara wrote:
>
> > Today I got a CD. MacOS does not mount it and Linux does not
> > mount it without an explicit filesystemtype option.
> > That is,
> > # mount /dev/hdc /dir -t iso9660
> > works fine, but
> > # mount /dev/hdc /dir
> > mount: you didn't
On Fri, 7 Sep 2007, Kyle Moffett wrote:
>
> So you can't draw any relationships between "Protect the end-user" with
> "Protect the device FROM the end-user", the former can be done very reliably
^^^ *attacker*
> to whatever level of risk-reduction you need and the
On Thu, 6 Sep 2007, Kyle Moffett wrote:
>
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> >
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> > >
> > > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > > > The question of how to protect against someone with
On Fri, 7 Sep 2007, J. Bruce Fields wrote:
>
> On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
> > Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
> > but you get the gist
> >
> > The point is that it is easy to subvert userspace if you have enough
On Thu, 6 Sep 2007, J. Bruce Fields wrote:
>
> On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > Oh and btw, note that we're talking of the (lack of) security of a
> > "running kernel" here -- because across reboots, there is /really/
&g
On Tue, 18 Sep 2007, Andrew Morton wrote:
> On Tue, 18 Sep 2007 14:43:48 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> > >
> > > 2.6.23-rc6-mm1 is a 29MB diff against
On Tue, 18 Sep 2007, Borislav Petkov wrote:
> These patches remove redundant DMA_..BIT_MASK definitions across
> two drivers. In this version of the patches, the computation
> of the majority of the bitmasks is done by the compiler.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> Cc:
Hi Borislav,
On Tue, 18 Sep 2007, Borislav Petkov wrote:
> On Mon, Sep 17, 2007 at 11:01:21PM -0700, Jeremy Fitzhardinge wrote:
> > Muli Ben-Yehuda wrote:
> > >> +#define DMA_64BIT_MASK DMA_BIT_MASK(64)
> > >>
> > >
> > > This one does not do what you mean. You need an explicit mask or a
Hi Borislav,
On Tue, 18 Sep 2007, Borislav Petkov wrote:
On Mon, Sep 17, 2007 at 11:01:21PM -0700, Jeremy Fitzhardinge wrote:
Muli Ben-Yehuda wrote:
+#define DMA_64BIT_MASK DMA_BIT_MASK(64)
This one does not do what you mean. You need an explicit mask or a
~0ULL here.
On Tue, 18 Sep 2007, Borislav Petkov wrote:
These patches remove redundant DMA_..BIT_MASK definitions across
two drivers. In this version of the patches, the computation
of the majority of the bitmasks is done by the compiler.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
Cc: Jeremy
On Tue, 18 Sep 2007, Andrew Morton wrote:
On Tue, 18 Sep 2007 14:43:48 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
On Fri, 7 Sep 2007, J. Bruce Fields wrote:
On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
but you get the gist
The point is that it is easy to subvert userspace if you have enough
On Thu, 6 Sep 2007, J. Bruce Fields wrote:
On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
Oh and btw, note that we're talking of the (lack of) security of a
running kernel here -- because across reboots, there is /really/
*absolutely* no such thing as kernelspace
On Thu, 6 Sep 2007, Kyle Moffett wrote:
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
The question of how to protect against someone with *physical*
On Fri, 7 Sep 2007, Kyle Moffett wrote:
So you can't draw any relationships between Protect the end-user with
Protect the device FROM the end-user, the former can be done very reliably
^^^ *attacker*
to whatever level of risk-reduction you need and the latter
Hi Gilboa,
On Sat, 15 Sep 2007, Gilboa Davara wrote:
This is my second stab at solving the stack over flow due to
dump_strace when close to stack-overflow is detected by do_IRQ problem.
(Hopefully) this patch is creates less noise then the previous one.
[snip]
I'll try and create an
Hi,
On Tue, 18 Sep 2007, Jan Kara wrote:
Today I got a CD. MacOS does not mount it and Linux does not
mount it without an explicit filesystemtype option.
That is,
# mount /dev/hdc /dir -t iso9660
works fine, but
# mount /dev/hdc /dir
mount: you didn't specify a
Hi Andries,
On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
On the other hand, this filesystem announces itself as UDF
(CD-RTOS CD-BRIDGE CDUDF File System - Adaptec Inc),
perhaps the kernel code should be more robust
On Tue, 18 Sep 2007, Satyam Sharma wrote:
>
> > [ cut here ]
> > Badness at arch/powerpc/kernel/smp.c:202
>
> comes when smp_call_function_map() has been called with irqs disabled,
> which is illegal. However, there is a special case, the panic(
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
> Dhaval Giani wrote:
> > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> >> EIP: [] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated, but
nition
of __smp_call_function().
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
arch/powerpc/kernel/smp.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
On Sun, 16 Sep 2007, Andrew Morton wrote:
> On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
>
> > On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm getting this:
> > >
> >
On Sun, 16 Sep 2007, Andrew Morton wrote:
On Mon, 17 Sep 2007 05:54:45 +0530 Satyam Sharma [EMAIL PROTECTED] wrote:
On 9/17/07, Andrew Morton [EMAIL PROTECTED] wrote:
I'm getting this:
rusb2/pvrusb2: struct usb_device_id is 20 bytes. The last of 3 is:
0x03 0x00 0x00 0x00
of __smp_call_function().
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
arch/powerpc/kernel/smp.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
Dhaval Giani wrote:
On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
EIP: [c037d81b] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated,
On Tue, 18 Sep 2007, Satyam Sharma wrote:
[ cut here ]
Badness at arch/powerpc/kernel/smp.c:202
comes when smp_call_function_map() has been called with irqs disabled,
which is illegal. However, there is a special case, the panic() codepath,
when we do not want
On 9/17/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Sep 2007 00:58:54 +0530
> "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
>
> > Hi Jeff,
> >
> > I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and
> > in
Hi Kees,
On 9/13/07, Kees Cook <[EMAIL PROTECTED]> wrote:
>
> This patch against 2.6.23-rc6 will cause modpost to fail if any device
> id lists are incorrectly terminated, after reporting the offender.
>
> Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
Nice! :-)
BTW a very similar idea (but for
On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Sep 2007 17:49:37 -0700 Kees Cook <[EMAIL PROTECTED]> wrote:
>
> > This patch against 2.6.23-rc6 will cause modpost to fail if any device
> > id lists are incorrectly terminated, after reporting the offender.
>
> I'm getting this:
>
Hi Jeff,
I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and
introduced a regression.
The "relevant" changelog [*] of that patch says:
> on filesystems w/o permanent inode numbers, i_ino values can be larger
> than 32 bits, which can cause problems for some 32 bit
Ok, opened up: http://bugzilla.kernel.org/show_bug.cgi?id=9026
and brought it up to date with the discussion and David's comments on this
thread. Timo, please feel free to revisit this later and update us when you find
the time to do so.
[ BTW I think the "add CC:" thing in bugzilla is broken, I
On 9/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Timo,
>
>
> On 7/15/07, Timo Lindemann <[EMAIL PROTECTED]> wrote:
> > To sum this up:
> >
> > the userspace 2.6.20.6 (the "good" kernel) and 2.6.22 (the "bad" kernel)
>
Hi Timo,
On 7/15/07, Timo Lindemann <[EMAIL PROTECTED]> wrote:
> To sum this up:
>
> the userspace 2.6.20.6 (the "good" kernel) and 2.6.22 (the "bad" kernel)
> were compiled in is exactly the same setup. I recompiled "good" to check
> for that, earlier, but "good" also works then.
>
> "good"
Hi Timo,
On 7/15/07, Timo Lindemann [EMAIL PROTECTED] wrote:
To sum this up:
the userspace 2.6.20.6 (the good kernel) and 2.6.22 (the bad kernel)
were compiled in is exactly the same setup. I recompiled good to check
for that, earlier, but good also works then.
good does not exhibit the
On 9/16/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Timo,
On 7/15/07, Timo Lindemann [EMAIL PROTECTED] wrote:
To sum this up:
the userspace 2.6.20.6 (the good kernel) and 2.6.22 (the bad kernel)
were compiled in is exactly the same setup. I recompiled good to check
Ok, opened up: http://bugzilla.kernel.org/show_bug.cgi?id=9026
and brought it up to date with the discussion and David's comments on this
thread. Timo, please feel free to revisit this later and update us when you find
the time to do so.
[ BTW I think the add CC: thing in bugzilla is broken, I
Hi Jeff,
I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and
introduced a regression.
The relevant changelog [*] of that patch says:
on filesystems w/o permanent inode numbers, i_ino values can be larger
than 32 bits, which can cause problems for some 32 bit userspace
On 9/17/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 12 Sep 2007 17:49:37 -0700 Kees Cook [EMAIL PROTECTED] wrote:
This patch against 2.6.23-rc6 will cause modpost to fail if any device
id lists are incorrectly terminated, after reporting the offender.
I'm getting this:
Hi Kees,
On 9/13/07, Kees Cook [EMAIL PROTECTED] wrote:
This patch against 2.6.23-rc6 will cause modpost to fail if any device
id lists are incorrectly terminated, after reporting the offender.
Signed-off-by: Kees Cook [EMAIL PROTECTED]
Nice! :-)
BTW a very similar idea (but for a
On 9/17/07, Jeff Layton [EMAIL PROTECTED] wrote:
On Mon, 17 Sep 2007 00:58:54 +0530
Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Jeff,
I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and
introduced a regression.
The relevant changelog [*] of that patch says
Hi,
On 9/15/07, Gilboa Davara <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
> out a possible stack overflow... when CONFIG_DEBUG_STACKOVERFLOW is
> enabled. (Though not limited to it)
Yeah, I have experienced this
Hi,
On 9/15/07, Gilboa Davara [EMAIL PROTECTED] wrote:
Hello all,
In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
out a possible stack overflow... when CONFIG_DEBUG_STACKOVERFLOW is
enabled. (Though not limited to it)
Yeah, I have experienced this phenomenon/problem
1 - 100 of 1619 matches
Mail list logo
