> +static int bus_notify(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + struct device *dev = data;
> +
> + printk("bus notify called\n");
> +
> + /* We are only intereted in device addition */
> + if (action != BUS_NOTIFY_ADD_DEVICE)
> +
On Sun, Jun 24, 2007 at 07:54:39PM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any
Al Viro wrote:
> Joy. OK, folks, disregard 16/16 in the current form; everything prior
> to it stands on its own.
Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
soon, and ignore 16.
Do you have those patches in public git somewhere, or would you like me to
just apply
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote:
> On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote:
> > On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> > > Hi Linus,
> > > hi LKML,
> > >
> > > i would like to thank LKML and especially Eric (thanks for
On Sat, Jun 09, 2007 at 10:25:16AM +0100, Richard Purdie wrote:
> Anyhow, time to stop pretending I have any choice in this ;-). I will
> have the LED class use random numbers for busids and add a name
> attribute unless anyone else voices an opinion.
Thank you, I really appreciate it, and so
On Sun, Jun 24, 2007 at 06:33:15PM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 24 Jun 2007, Arjan van de Ven wrote:
>
> >On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >>>
> >>>on a system level, size can help performance because you have more
> >>>memory available for other things.
So i choice to use switch_root which is already inside the busybox but with a
bit(?) of unluck cause it still wont run.
It hangs on !S_ISREG(st1.st_mode)
Can you explain to me how to interpret it?
Regards
S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Robert Iakobashvili wrote:
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones <[EMAIL PROTECTED]>
wrote:
> I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
> But I am hitting a max limit of 4000 IP address . Seems like there
is a
> limiting variable in linux kernel
On Sun, 24 Jun 2007, Petr Vandrovec wrote:
> > -module_param(debug, bool, 0600);
> > -MODULE_PARM_DESC(debug, "Debug enabled or not");
> > +static int __init root_plug_debug(char *str)
> > +{
> > + debug = simple_strtol(str, NULL, 0);
> > + return 1;
> > +}
> > +__setup("root_plug_debug=",
Quoting Chris Wright ([EMAIL PROTECTED]):
> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> > Sigh, as much as I would *like* to stay out of this (I don't
> > use modules at all on any system where I can avoid it), won't
> > it make development - and especially testing - of new lsms
> > much more
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote:
> On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> > Hi Linus,
> > hi LKML,
> >
> > i would like to thank LKML and especially Eric (thanks for the per_cpu
> > macro tips and design guidelines!) and the other contributors
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Needlessly exported LSM symbols have been unexported, to help reduce API
abuse.
Parameters for the capability and
Petr Vandrovec wrote:
>>> Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
>>> output, and I think I verified the patch with the reporter. Hmm... Can
>>> anyone verify these module strings?
>>
>> Could well be that they've started attaching Hitachi to the ID strings
>> now..
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Sigh, as much as I would *like* to stay out of this (I don't
> use modules at all on any system where I can avoid it), won't
> it make development - and especially testing - of new lsms
> much more painful and therefore less likely?
Dev, hopefully
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist []
Mark Lord wrote:
> Robert de Rooy wrote:
>
>>
>> I did another try with libata pcmcia support using 2.6.22-rc5 which
>> already includes the nodata polling fix, in combination with
>> disable-dev_init_param-and-setxfermode-for-CFA.patch and the
>> timing-debug.patch
>
> ...
>
>> Jun 22 13:19:44
Arnd Hannemann wrote:
> Jan Engelhardt schrieb:
>> On Jun 24 2007 23:27, Salvatore De Paolis wrote:
>>> i built the kernel with a busybox initramfs which runs from a usb stick.
>>> While
>>> i boot i need to mount the real root and i'm using pivot_root.
>>> Pivot_root . old-root return to me an
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> Just hoping to avoid a change collision. If I have to deal
> with this today it's easy, if it doesn't show up anywhere
> until 2.6.28 I'm breezing, but if it all hits in two weeks I
> have some scrambling and yet another delay to deal with. Not
> your
Quoting James Morris ([EMAIL PROTECTED]):
> Convert LSM into a static interface, as the ability to unload a security
> module is not required by in-tree users and potentially complicates the
> overall security architecture.
>
> Needlessly exported LSM symbols have been unexported, to help
On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> Hi Linus,
> hi LKML,
>
> i would like to thank LKML and especially Eric (thanks for the per_cpu
> macro tips and design guidelines!) and the other contributors to this idea.
>
> This time the patch is rather big because it also
Hi,
I reconfig my kernel, boot and oops, EIP in __change_page_attr:166, I
tried 2.6.22-rc4-mm2 and 2.6.22-rc5 , same result.
Anyone has some clues?
here is my config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc5
# Mon Jun 25 11:11:05 2007
#
I sent a patch to the ALSA developers 4 years ago.
It was never included in the kernel :/
ALSA maintainers are very open to patches. try sending this again
Here's the comment from a script that I once wrote to
make some closed-source dinosar code run (speech recognition)
on modern linux:
#
--- Chris Wright <[EMAIL PROTECTED]> wrote:
> * Casey Schaufler ([EMAIL PROTECTED]) wrote:
> > So, for planning purposes, when ought I expect to have to start
> > dealing with this?
>
> What is your specific concern or use case?
Just hoping to avoid a change collision. If I have to deal
with
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
On Jun 22, 2007, at 18:51:10, C. Scott Ananian wrote:
Back to kernel-land: in an IPv6 only world, it might make sense to
export a /proc file compatible with the format of /etc/resolv.conf,
with one DNS server address per line. If glibc uses/used inotify
on /etc/resolv.conf, then symlinking
On Thursday 10 May 2007, Hans-Jürgen Koch wrote:
> Am Donnerstag 10 Mai 2007 22:07 schrieb David Brownell:
> > On Friday 27 April 2007, David Brownell wrote:
> > > On Friday 27 April 2007, Hans-Jürgen Koch wrote:
> > >
> > > > >the m25p80 driver
> > > > > was pretty close to working with
Robert Hancock wrote:
> Tejun Heo wrote:
>> Another member of HTS5416* family doing spurious NCQ completion.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> Cc: Enrico Sardi <[EMAIL PROTECTED]>
>> ---
>> drivers/ata/libata-core.c |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c
On Mon, Jun 25, 2007 at 03:35:56AM +0200, Arnd Bergmann wrote:
> On Monday 25 June 2007, Olof Johansson wrote:
> > ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> > MMIO addresses, and remapped at an offset that's well above 16 bits in
> > some cases.
> >
> > While the
Enrico Sardi wrote:
> This is the result of hdparm -I /dev/sda:
>
> /dev/sda:
>
> ATA device, with non-removable media
>Model Number: Hitachi HTS541616J9SA00
Just in case, you didn't add "Hitachi " in the front of Model Number
string, right? It looks a bit odd because all other
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index
On Mon, 25 Jun 2007, Adrian Bunk wrote:
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations,
Andrew Morton wrote:
> That great spew of "set_level status: 0" is fairly annoying and useless.
I don't know where those are coming from. It's not from libata.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Robert Hancock wrote:
> Andrew Morton wrote:
>> On Sun, 24 Jun 2007 14:32:22 +0200 Enrico Sardi <[EMAIL PROTECTED]>
>> wrote:
>>> [ 61.176000] ata1.00: exception Emask 0x2 SAct 0x2 SErr 0x0 action
>>> 0x2 frozen
>>> [ 61.176000] ata1.00: (spurious completions during NCQ issue=0x0
>>> SAct=0x2
On Sun, Jun 24, 2007 at 05:22:30PM -0700, Yinghai Lu wrote:
> On 6/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >> void __init gart_iommu_init(void)
> >> {
> >> struct agp_kern_info info;
> >> diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
> >> index
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> The interesting questions are:
>> Does -Os still sometimes generate faster code with gcc 4.2?
>> If yes, why?
>
> Smaller code can mean fewer page faults, fewer cache invalidations, etc.
>
> It's not just a matter
On 06/25/2007 03:33 AM, [EMAIL PROTECTED] wrote:
is the list of what's included in -O2 vs -Os different for different
CPU's? what about within a single family of processors? (even in the x86
family the costs of jumps, loops, and cache misses varies drasticly)
At least not in the example
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> So, for planning purposes, when ought I expect to have to start
> dealing with this?
What is your specific concern or use case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* James Morris ([EMAIL PROTECTED]) wrote:
> On Sun, 24 Jun 2007, Chris Wright wrote:
>
> > * James Morris ([EMAIL PROTECTED]) wrote:
> > > -module_param_named(disable, capability_disable, int, 0);
> > > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> > > 1");
> > > +
>
On Monday 25 June 2007, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platforms
> with
On 06/25/2007 03:23 AM, Rene Herman wrote:
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the
compiler version. That is, I'd
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations, etc.
It's not just a matter of compiler code generation, gotta look at the
whole picture.
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
on a system level, size can help performance because you have more
memory available for other things. It also reduces download size and
gives you more space on the live CD
if you
On Sun, Jun 24, 2007 at 05:58:46PM -0700, Arjan van de Ven wrote:
>
> > I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> > CONFIG_EMBEDDED, but as long as it's available as a general purpose
> > option we have to consider it's performance.
>
> I think you are missing the point.
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the compiler
version. That is, I'd expect my Duron with it's "puny" 64K L1 to
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >
> > on a system level, size can help performance because you have more
> > memory available for other things. It also reduces download size and
> > gives you more space on the live CD
> >
> > if you want to make things bigger
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
CONFIG_EMBEDDED, but as long as it's available as a general purpose
option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
On 2007.06.23 11:50:49 +, Andrew Morton wrote:
> On Sat, 23 Jun 2007 14:42:21 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > > I probably _could_ work this out, and kinda did with a bit of
> > list-trolling
> > > (verdict: needed in 2.6.22) but please, take care to describe the
> > >
> I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> CONFIG_EMBEDDED, but as long as it's available as a general purpose
> option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
OPTIMIZE_FOR_SIZE. *over performance*. Sure.
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
MMIO addresses, and remapped at an offset that's well above 16 bits in
some cases.
While the type is exported to userspace, there hasn't been any platforms
with PCMCIA on 64-bit powerpc until now, so changing it won't
On Sun, Jun 24, 2007 at 05:23:42PM -0700, Arjan van de Ven wrote:
> On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> > On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > > if you care about the last cycle, don't specify -Os but -O2.
> > > simple as that... you get
On Mon, Jun 25, 2007 at 12:07:23AM +0200, Carlo Wood wrote:
> On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote:
> > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed
> > per various bonnie++ tests.
>
> There is more going on than a bad NCQ implementation of
On Sun, 24 Jun 2007, Russell King wrote:
> On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
> > On Sun, 24 Jun 2007, Russell King wrote:
> > > On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > >
> > > Please forward the original problem report.
> >
> > Done.
>
>
On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > if you care about the last cycle, don't specify -Os but -O2.
> > simple as that... you get what you tell the compiler you want.
>
> Certain distros are shipping
On 6/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> void __init gart_iommu_init(void)
> {
> struct agp_kern_info info;
> diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
> index 9f80aad..64f2ab3 100644
> --- a/arch/x86_64/kernel/pci-dma.c
> +++
On 6/23/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
So my suggestion would be:
(1) implement sysfs platform device based shutdown hooks (preferable
before PCI shutdown)
BTW, it would be better if DMA ram range was registered there too.
(2) make sure GART is never enabled in kernels that are
On Sun, 2007-06-24 at 09:40 -0700, Linus Torvalds wrote:
>
> On Sat, 23 Jun 2007, Peter Zijlstra wrote:
>
> > On Thu, 2007-06-21 at 16:08 -0700, Linus Torvalds wrote:
> > >
> > > The vm_dirty_ratio thing is a global value, and I think we need that
> > > regardless (for the independent issue of
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
> Would it make sense to define a new entity called "configmenu" (or something
> else) that is equivalent to menuconfig with the following changes?
>
> * it creates a CM_ variable instead of a CONFIG_ one
> * the CM_ symbols are not available to
On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> if you care about the last cycle, don't specify -Os but -O2.
> simple as that... you get what you tell the compiler you want.
Certain distros are shipping kernels compiled with -Os. And it's more
than just a couple of cycles.
On Sun, 2007-06-24 at 19:23 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> > we should just alias our memset to the __builtin one, and then provide a
> > generic one from lib/ for the cases gcc needs to do a fallback.
>
> The last time I
Carlo Wood wrote:
The following can be observed:
1) There is hardly any difference between the two schedulers (noop
is a little faster for the bonny test).
2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s),
the NCQ depth of 2 is by far the slowest for the RAID5
--- Chris Wright <[EMAIL PROTECTED]> wrote:
> * James Morris ([EMAIL PROTECTED]) wrote:
> > -module_param_named(disable, capability_disable, int, 0);
> > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> 1");
> > +
> > +static int __init capability_disable_setup(char
On Sat, 2007-06-23 at 23:07 -0700, David Miller wrote:
The original version of this fix have made it to the 2.6.22-rc5 already
and should be replaced with this one, however the two can coexist in the
same code for a while.
> > --- linux-2.6.21.3/drivers/net/ppp_generic.c.orig 2007-06-20
> >
On Jun 24, 2007, at 17:27:34, Salvatore De Paolis wrote:
i built the kernel with a busybox initramfs which runs from a usb
stick. While i boot i need to mount the real root and i'm using
pivot_root. Pivot_root . old-root return to me an "Invalid
argument" error and googling i found here
On Sat, Jun 23, 2007 at 12:53:11AM +0200, Michal Piotrowski wrote:
> Hi Oliver,
>
> On 22/06/07, Oliver Pinter <[EMAIL PROTECTED]> wrote:
> >Hi all!
> >
> >I found this info:
> >
> >=== [ INFO: possible
> >circular locking dependency detected ]
On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> we should just alias our memset to the __builtin one, and then provide a
> generic one from lib/ for the cases gcc needs to do a fallback.
The last time I checked, gcc generated horrible badly performing code for
builtin
On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
>
> > > I think all these benefits are the gcc's __builtin_memset optimization
> > > than the explicit call to memset.
> >
> > ... or from complex memset() implementation (some chips even didn't do
> > `rep' fast enough somehow).
Hi.
On Monday 25 June 2007 07:03:20 Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
> > Hi.
> >
> > I have recently begun to try and use suspend to ram more, and have an
> > intermittent problem. Actually, it's a couple of (possibly related)
> >
On Mon, Jun 25, 2007 at 12:48:45AM +0200, Jesper Juhl wrote:
> Did you try resending it?
> Sometimes patches get missed, overlooked, dropped on the floor by mistake
> etc.
...
> When it comes to getting patches into mainline, asking twice (or more)
> is sometimes required, and it's considered
On 25/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> > > + if (!file || !e)
> > > + exit(1);
> > >*e = '\0';
> > >cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > >
On Mon, Jun 25, 2007 at 06:42:53AM +0900, Neil Booth wrote:
> > such a big deal... Parser would need to accept
> > ident ( \[ expr \] | . ident )*
>
> don't forget -> if you're going to accept extra stuff. GCC forgot ->
> with the parser rewrite, yes I filed a PR.
In offsetof() second
If we fail to allocate an skb in
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it
is better to print a error message and just return rather than
bring down the whole kernel.
Sure,
On Sunday June 24, [EMAIL PROTECTED] wrote:
>
> +#define PG_blocks20 /* Page has block mappings */
> +
I've only had a very quick look, but this line looks *very* wrong.
You should be using PG_private.
There should never be any confusion about whether ->private has
buffers or
On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> > > + if (!file || !e)
> > > + exit(1);
> > >*e = '\0';
> > >cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > >cur_line = atoi(yytext+2);
> >
> > I don't think the bug which
On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Alexander, Johannes,
>
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses public key cryptosystems for the key management,
> which is decidedly
On 22/06/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
[snip]
Step 1: run fsck on the filesystem.
I agree that running fsck on the filesystem is a good idea, but still,
even a corrupt filesystem should never be able to cause an Oops. In
fact, nothing done from userspace should be able to cause
On 25/06/07, Carlo Wood <[EMAIL PROTECTED]> wrote:
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better
On Sun, 24 Jun 2007, Chris Wright wrote:
> * James Morris ([EMAIL PROTECTED]) wrote:
> > -module_param_named(disable, capability_disable, int, 0);
> > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> > 1");
> > +
> > +static int __init capability_disable_setup(char
In drivers/isdn/capi/kcapi.c::old_capi_manufacturer(), if the call
to get_capi_ctr_by_nr(ldef.contr); in line 823 returns NULL, then
we'll be dereferencing a NULL pointer in the very next line.
(Found by Coverity checker as bug #402)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
On Sun, 24 Jun 2007, Andrew Morton wrote:
> On Sun, 24 Jun 2007 15:21:37 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
>
> > arch/i386/kernel/irq.c |8 ++--
> > arch/sh/kernel/irq.c |8 ++--
>
> These two files are maintained by different developers who run
>
> > I think all these benefits are the gcc's __builtin_memset optimization
> > than the explicit call to memset.
>
> ... or from complex memset() implementation (some chips even didn't do
> `rep' fast enough somehow). Maybe code like below will be acceptable for
> both optimizers and
On Sun, Jun 24, 2007 at 08:58:10PM +0800, rae l wrote:
> On 6/23/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> >Why not just show actual objdump output on code (maybe with different
> >oxygen atoms used in gcc), rather than *talking* about optimization and
> >standards, hm?
> here is the objdump
* James Morris ([EMAIL PROTECTED]) wrote:
> -module_param_named(disable, capability_disable, int, 0);
> -MODULE_PARM_DESC(disable, "To disable capabilities module set disable = 1");
> +
> +static int __init capability_disable_setup(char *str)
> +{
> + capability_disable = simple_strtol(str,
On Sun, 24 Jun 2007 23:39:25 +0200
Arnd Hannemann <[EMAIL PROTECTED]> wrote:
> use run-init from klibc?
> However be aware of the limitation of run-init:
> It only works for direct childs of root directory
> /mnt/newroot won't work
> /newroot should work ;-)
>
> Good luck,
> Arnd
Thank you
On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote:
> Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed
> per various bonnie++ tests.
There is more going on than a bad NCQ implementation of the drive imho.
I did a long test over night (and still only got two
On 16/06/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > > On 6/15/07, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > >
On 24/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Sun, 24 Jun 2007 23:40:03 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote:
> strchr() returns NULL in case the string is not found and if that
> happens we risk dereferencing a NULL pointer. It never hurts to
> check for that condition and
On Sun, 24 Jun 2007 23:40:03 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote:
> strchr() returns NULL in case the string is not found and if that
> happens we risk dereferencing a NULL pointer. It never hurts to
> check for that condition and exit normally with an error rather
> than crashing.
>
Jan Engelhardt schrieb:
> On Jun 24 2007 23:27, Salvatore De Paolis wrote:
>> i built the kernel with a busybox initramfs which runs from a usb stick.
>> While
>> i boot i need to mount the real root and i'm using pivot_root.
>> Pivot_root . old-root return to me an "Invalid argument" error and
On Sun, 24 Jun 2007, David Wagner wrote:
Argument 3. AA isn't complete until it mediates network and IPC.
Let me comment on these one-by-one.
3. This one I agree with. If you want to sandbox network daemons that
you're concerned might get hacked, then you really want your sandbox to
mediate
On Jun 24, 2007, at 15:58:54, Jan Engelhardt wrote:
On Jun 24 2007 15:08, Kyle Moffett wrote:
Do you really need that many IP addresses? When somebody finally
gets around to implementing REDIRECT support for ip6tables then
you could just redirect them all to the same port on the local
James Morris wrote:
>A. Pathname labeling - applying access control to pathnames to objects,
>rather than labeling the objects themselves.
>
>Think of this as, say, securing your house by putting a gate in the street
>in front of the house, regardless of how many other possible paths there
Al Viro wrote:-
> > See gcc.gnu.org/PR456 for more discussion. Yes it's an old
> > bug...
>
> Humm... Right, so __builtin_offsetof() needs special treatment too.
> Oh, bugger. Is
> offsetof(struct foo, a.x[n])
> a documented extension? I _know_ that it's not promised by 7.17,
> but gcc
1 - 100 of 474 matches
Mail list logo
