Re: [PATCH 1/1] [NOMMU]: Dont use kobjsize on the area belonging to a VMA
Bryan Wu wrote: > On Jan 30, 2008 9:04 PM, Bernd Schmidt <[EMAIL PROTECTED]> wrote: >> Bryan Wu wrote: >>> From: Bernd Schmidt <[EMAIL PROTECTED]> >>> >>> Dont use kobjsize on the area belonging to a VMA, as it's allocated with >>> get_free_pages. >> As far as I remember, that's the case only in our tree with the patches >> in nommu.c. So this patch probably shouldn't go upstream yet. >> > > Oh, I picked up a wrong one. Could you please tell me which nommu.c > pathes does this one depends on? > I am sorting out all our nommu changes and try to send them out. Leave them out for now. I think David half-nacked them last time I posted them, so we'll need to work something out. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [PATCH 1/1] [NOMMU]: Dont use kobjsize on the area belonging to a VMA
Bryan Wu wrote: > From: Bernd Schmidt <[EMAIL PROTECTED]> > > Dont use kobjsize on the area belonging to a VMA, as it's allocated with > get_free_pages. As far as I remember, that's the case only in our tree with the patches in nommu.c. So this patch probably shouldn't go upstream yet. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [PATCH 1/1] [NOMMU]: Dont use kobjsize on the area belonging to a VMA
Bryan Wu wrote: From: Bernd Schmidt [EMAIL PROTECTED] Dont use kobjsize on the area belonging to a VMA, as it's allocated with get_free_pages. As far as I remember, that's the case only in our tree with the patches in nommu.c. So this patch probably shouldn't go upstream yet. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [PATCH 1/1] [NOMMU]: Dont use kobjsize on the area belonging to a VMA
Bryan Wu wrote: On Jan 30, 2008 9:04 PM, Bernd Schmidt [EMAIL PROTECTED] wrote: Bryan Wu wrote: From: Bernd Schmidt [EMAIL PROTECTED] Dont use kobjsize on the area belonging to a VMA, as it's allocated with get_free_pages. As far as I remember, that's the case only in our tree with the patches in nommu.c. So this patch probably shouldn't go upstream yet. Oh, I picked up a wrong one. Could you please tell me which nommu.c pathes does this one depends on? I am sorting out all our nommu changes and try to send them out. Leave them out for now. I think David half-nacked them last time I posted them, so we'll need to work something out. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [PATCH] Add EXPORT_SYMBOL(ksize);
A couple of Cc:s added. Adrian Bunk wrote: > On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote: >> On Sun, 2 Dec 2007 14:48:42 +0100 >> Adrian Bunk <[EMAIL PROTECTED]> wrote: >> >>> On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote: mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why. ... >>> That's due to the fact that my patch to remove this unused export from >>> slub was not yet applied... >>> >>> Where is the modular in-kernel user? >>> >> binfmt_flat.c, binfmt_elf_fdpic.c. > > I could have sworn I had checked that both are bools, but BINFMT_FLAT is > actually a tristate. > > Is anyone actually using binfmt_flat modular (considering it's only > available for !MMU embedded systems)? If yes, then only exporting > ksize() will not be enough for getting it working modular... We're not using modular binfmt_flat on the Blackfin, but I can't speak for other architectures. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [PATCH] Add EXPORT_SYMBOL(ksize);
A couple of Cc:s added. Adrian Bunk wrote: On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote: On Sun, 2 Dec 2007 14:48:42 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote: mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why. ... That's due to the fact that my patch to remove this unused export from slub was not yet applied... Where is the modular in-kernel user? binfmt_flat.c, binfmt_elf_fdpic.c. I could have sworn I had checked that both are bools, but BINFMT_FLAT is actually a tristate. Is anyone actually using binfmt_flat modular (considering it's only available for !MMU embedded systems)? If yes, then only exporting ksize() will not be enough for getting it working modular... We're not using modular binfmt_flat on the Blackfin, but I can't speak for other architectures. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/
Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS
Adrian Bunk wrote:
> It can be a performance regression, but there are also cases where it
> can improve performance. If gcc produces lower performance code that
> would be a bug in gcc that should be reported, but using a division is
> not generally wrong.
>
> A more clearer example might be:
>
> <-- snip -->
>
> void foo(u64 ns)
> {
> if (ns < 1)
> return;
>
> while(ns >= 3) {
> ns -= 3;
> #ifdef DEBUG
> bar(ns);
> #endif
> }
> }
>
> <-- snip -->
>
> With DEBUG not defined you can hardly argue gcc should be fixed to not
> use a division for performance reasons.
Absent any clear information about the possible values of ns, IMO this
is a case where the compiler should just assume that the programmer
knows best whether to use a loop or a division. Principle of least
surprise, and all that...
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS
Adrian Bunk wrote:
> The gcc from svn that will become gcc 4.3 generates libgcc calls in
> cases like the following (on 32bit architectures):
>
> <-- snip -->
>
> static inline void timespec_add_ns(struct timespec *a, u64 ns)
> {
> ...
> while(ns >= NSEC_PER_SEC) {
> ns -= NSEC_PER_SEC;
> a->tv_sec++;
> }
> ...
>
> <-- snip -->
>
> It can make sense to emit assembler code doing division for such C code -
> that doesn't seem to be something that would generally be wrong.
It can be a pretty huge performance regression, so gcc ought to be fixed.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS
Adrian Bunk wrote:
The gcc from svn that will become gcc 4.3 generates libgcc calls in
cases like the following (on 32bit architectures):
-- snip --
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
...
while(ns = NSEC_PER_SEC) {
ns -= NSEC_PER_SEC;
a-tv_sec++;
}
...
-- snip --
It can make sense to emit assembler code doing division for such C code -
that doesn't seem to be something that would generally be wrong.
It can be a pretty huge performance regression, so gcc ought to be fixed.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS
Adrian Bunk wrote:
It can be a performance regression, but there are also cases where it
can improve performance. If gcc produces lower performance code that
would be a bug in gcc that should be reported, but using a division is
not generally wrong.
A more clearer example might be:
-- snip --
void foo(u64 ns)
{
if (ns 1)
return;
while(ns = 3) {
ns -= 3;
#ifdef DEBUG
bar(ns);
#endif
}
}
-- snip --
With DEBUG not defined you can hardly argue gcc should be fixed to not
use a division for performance reasons.
Absent any clear information about the possible values of ns, IMO this
is a case where the compiler should just assume that the programmer
knows best whether to use a loop or a division. Principle of least
surprise, and all that...
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] binfmt_flat: minimum support for the Blackfin relocations
Andrew Morton wrote:
if (rev > OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
`persistent' here only has meaning inside the next nesting level, so should
be moved down into that scope for readability reasons.
See below.
+ if (flat_set_persistent (relval, ))
+ continue;
If this correct? flat_set_persistent() returns zero if it didn't write
anything to `persistent'. It seems strange that in the case where
flat_set_persistent() _does_ write something to `persistent', we just throw
it away by doing `continue'.
Either that, or I've misread the code and you really did mean to put
`persistent' in the outer scope, and its value is supposed to propagate
over into the next iteration of the loop. If so, that's all a bit too
tricky for it to be implemented with zero code comments, dontcha think?
The latter. We need to be able to use more data than we can fit into a
single reloc, so we store a value with one reloc and reuse it with the
next. There'd be no point in having this function otherwise since you
could perform whatever needs to be done in flat_get_relocate_addr.
This seemed fairly obvious at the time... when you're familiar with the
flat format, the loop isn't all that hard to understand. I'll add
comments in the next version.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] binfmt_flat: minimum support for the Blackfin relocations
Andrew Morton wrote:
if (rev OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
`persistent' here only has meaning inside the next nesting level, so should
be moved down into that scope for readability reasons.
See below.
+ if (flat_set_persistent (relval, persistent))
+ continue;
If this correct? flat_set_persistent() returns zero if it didn't write
anything to `persistent'. It seems strange that in the case where
flat_set_persistent() _does_ write something to `persistent', we just throw
it away by doing `continue'.
Either that, or I've misread the code and you really did mean to put
`persistent' in the outer scope, and its value is supposed to propagate
over into the next iteration of the loop. If so, that's all a bit too
tricky for it to be implemented with zero code comments, dontcha think?
The latter. We need to be able to use more data than we can fit into a
single reloc, so we store a value with one reloc and reuse it with the
next. There'd be no point in having this function otherwise since you
could perform whatever needs to be done in flat_get_relocate_addr.
This seemed fairly obvious at the time... when you're familiar with the
flat format, the loop isn't all that hard to understand. I'll add
comments in the next version.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
3030 3030 3030 305f 5f5f 5f5f
5f5f 5f5f 5f30 5f41 0003 3e00 0004 5247
4c31 3033 3634 436f 6e66 6967 2020 4469
736b 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8001
2f00 4000 0200 0007 3fff 0010
003f fc10 00fb 0101 0280 0407
0003 0078 0078 0078 0078
0201
007e 001b 0068 5060 4000 1000 4000
407f fffe c0fe
0001
0001
0017 2040
baa5
Since about 2.6.17 or 2.6.18, it has been causing long delays while booting:
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5)
ata2: port is slow to respond, please be patient (Status 0x80)
ata2: COMRESET failed (errno=-16)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133
ata2.00: 640 sectors, multi 1: LBA
ata2.00: configured for UDMA/133
Bernd
-
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/
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
3030 3030 3030 305f 5f5f 5f5f
5f5f 5f5f 5f30 5f41 0003 3e00 0004 5247
4c31 3033 3634 436f 6e66 6967 2020 4469
736b 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8001
2f00 4000 0200 0007 3fff 0010
003f fc10 00fb 0101 0280 0407
0003 0078 0078 0078 0078
0201
007e 001b 0068 5060 4000 1000 4000
407f fffe c0fe
0001
0001
0017 2040
baa5
Since about 2.6.17 or 2.6.18, it has been causing long delays while booting:
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5)
ata2: port is slow to respond, please be patient (Status 0x80)
ata2: COMRESET failed (errno=-16)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133
ata2.00: 640 sectors, multi 1: LBA
ata2.00: configured for UDMA/133
Bernd
-
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/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Paul Mundt wrote: This is making API changes where it's convenient for your platform to use this value, and there's no reason to change the API here at all. Your proposed addition of flat_validate_relval is an API change, and very similar in nature to what I've done. A local variable here is the most natural way to store this information. What do you suggest we use, a global? A member in the task struct? Why should all architectures have to change their APIs (not just adding new things mind you, also changing existing definitions) to accomodate something that can trivially be kept in the blackfin code? I don't see how there's a burden given that we've provided patches, and most maintainers have already said their fine with it. It seems to me that it's a natural and common thing for many architectures to be updated when new things are added to core code. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Paul Mundt wrote:
I find it a bit disconcerting that blackfin already depends on this
in-tree without there being any earlier discussion on making these
changes.
Parts of the initial submission were picked up (the include/asm
directory), other's weren't. Little we can do about that.
*/
if (rev > OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
for (i=0; i < relocs; i++) {
unsigned long addr, relval;
@@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
relocated (of course, the address has to be
relocated first). */
relval = ntohl(reloc[i]);
+ if (flat_set_persistent (relval, ))
+ continue;
addr = flat_get_relocate_addr(relval);
rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
if (rp == (unsigned long *)RELOC_FAILED) {
I don't much care for this API. It's shuffling around a temporary
variable for the architecture code that's set for certain relocations
that are otherwise unhandled.
Since all the architecture is interested in is the relval that has
associated "persistent" data encoded in it, why don't we just have a stub
to give the architecture a chance to validate the relval before the
flat_get_relocate_addr() and move this stuff there instead? ie, blackfin
takes this out-of-line and manages its persistent value there.
What is flat_set_persistent other than a stub to validate the relval?
I'm not at all sure what you're proposing or how it would be different.
load_flat_file() is ugly enough without dumping more architecture
callback abuses in it.
The other maintainers who have spoken up didn't seem to think this was
ugly, or an abuse. I'm surprised to hear language like that when
discussing a patch that adds an if statement, a local variable and one
parameter in a function call.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Paul Mundt wrote:
I find it a bit disconcerting that blackfin already depends on this
in-tree without there being any earlier discussion on making these
changes.
Parts of the initial submission were picked up (the include/asm
directory), other's weren't. Little we can do about that.
*/
if (rev OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
for (i=0; i relocs; i++) {
unsigned long addr, relval;
@@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
relocated (of course, the address has to be
relocated first). */
relval = ntohl(reloc[i]);
+ if (flat_set_persistent (relval, persistent))
+ continue;
addr = flat_get_relocate_addr(relval);
rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
if (rp == (unsigned long *)RELOC_FAILED) {
I don't much care for this API. It's shuffling around a temporary
variable for the architecture code that's set for certain relocations
that are otherwise unhandled.
Since all the architecture is interested in is the relval that has
associated persistent data encoded in it, why don't we just have a stub
to give the architecture a chance to validate the relval before the
flat_get_relocate_addr() and move this stuff there instead? ie, blackfin
takes this out-of-line and manages its persistent value there.
What is flat_set_persistent other than a stub to validate the relval?
I'm not at all sure what you're proposing or how it would be different.
load_flat_file() is ugly enough without dumping more architecture
callback abuses in it.
The other maintainers who have spoken up didn't seem to think this was
ugly, or an abuse. I'm surprised to hear language like that when
discussing a patch that adds an if statement, a local variable and one
parameter in a function call.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Paul Mundt wrote: This is making API changes where it's convenient for your platform to use this value, and there's no reason to change the API here at all. Your proposed addition of flat_validate_relval is an API change, and very similar in nature to what I've done. A local variable here is the most natural way to store this information. What do you suggest we use, a global? A member in the task struct? Why should all architectures have to change their APIs (not just adding new things mind you, also changing existing definitions) to accomodate something that can trivially be kept in the blackfin code? I don't see how there's a burden given that we've provided patches, and most maintainers have already said their fine with it. It seems to me that it's a natural and common thing for many architectures to be updated when new things are added to core code. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
Christoph Lameter wrote: True. That is why we want to limit the number of unmovable allocations and that is why ZONE_MOVABLE exists to limit those. However, unmovable allocations are already rare today. The overwhelming majority of allocations are movable and reclaimable. You can see that f.e. by looking at /proc/meminfo and see how high SUnreclaim: is (does not catch everything but its a good indicator). Just to inject another factor into the discussion, please remember that Linux also runs on nommu systems, where things like user space allocations are neither movable nor reclaimable. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
Christoph Lameter wrote: True. That is why we want to limit the number of unmovable allocations and that is why ZONE_MOVABLE exists to limit those. However, unmovable allocations are already rare today. The overwhelming majority of allocations are movable and reclaimable. You can see that f.e. by looking at /proc/meminfo and see how high SUnreclaim: is (does not catch everything but its a good indicator). Just to inject another factor into the discussion, please remember that Linux also runs on nommu systems, where things like user space allocations are neither movable nor reclaimable. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [GIT PULL] Blackfin arch bug fixing for 2.6.23-rc6
Bryan Wu wrote: This is because a binfmt_flat hacking patch for Blackfin arch is not accept by the mainline. Did you see someone reject it, or did it just get lost? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [Uclinux-dist-devel] Re: [PATCH] Blackfin arch: add some missing syscall
Bryan Wu wrote: but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu? you're right we want mremap, my fault Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd? There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [Uclinux-dist-devel] Re: [PATCH] Blackfin arch: add some missing syscall
Bryan Wu wrote: but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu? you're right we want mremap, my fault Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd? There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [GIT PULL] Blackfin arch bug fixing for 2.6.23-rc6
Bryan Wu wrote: This is because a binfmt_flat hacking patch for Blackfin arch is not accept by the mainline. Did you see someone reject it, or did it just get lost? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote: Bernd Schmidt <[EMAIL PROTECTED]> wrote: In do_mmap_private, I've commented out the logic to free excess pages, as it fragments terribly I wonder if there's a good heuristic for this. The problem is that whilst not releasing excess pages _may_ seem like a good idea, if your system is something like a single persistent app, then it really is not. For instance, if such an app allocates a byte over 16MB (perhaps implicitly in the binfmt driver), then you'd completely waste a large chunk of RAM. In the 16MB+1 case, the wastage would be a byte less than 16MB. I think it would be good to have a mechanism to group free pages by purpose - so that if we break up a high-order page in order to allocate memory for process A, then the remaining pages remain in a special pool that the allocator will prefer to hand out only to process A. Also, I think you're freeing high-order pages unaligned to their order? Yeah, but some of the pages might still be in use when we want to release them. Not following you here. Is it valid to free an order-2 page that's not aligned at order-2? In do_munmap, we can deal with freeing more than one vma. I've not touched the rb-tree logic in the shared file case, as I have no idea what it's trying to do given that only exact matches are allowed. I'd generally rather not do this. You can't use MAP_FIXED to request adjacent regions, so why should you anticipate there would be any? Adjacent regions can happen by accident, and the uClibc malloc will try to merge free areas when they are adjacent - there's a lot of special-case code in there to prevent this on uClinux systems by essentially duplicating VMA tracking. That's something we want to avoid, because it eats performance (especially in threaded apps due to additional locking). Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote: Bernd Schmidt [EMAIL PROTECTED] wrote: In do_mmap_private, I've commented out the logic to free excess pages, as it fragments terribly I wonder if there's a good heuristic for this. The problem is that whilst not releasing excess pages _may_ seem like a good idea, if your system is something like a single persistent app, then it really is not. For instance, if such an app allocates a byte over 16MB (perhaps implicitly in the binfmt driver), then you'd completely waste a large chunk of RAM. In the 16MB+1 case, the wastage would be a byte less than 16MB. I think it would be good to have a mechanism to group free pages by purpose - so that if we break up a high-order page in order to allocate memory for process A, then the remaining pages remain in a special pool that the allocator will prefer to hand out only to process A. Also, I think you're freeing high-order pages unaligned to their order? Yeah, but some of the pages might still be in use when we want to release them. Not following you here. Is it valid to free an order-2 page that's not aligned at order-2? In do_munmap, we can deal with freeing more than one vma. I've not touched the rb-tree logic in the shared file case, as I have no idea what it's trying to do given that only exact matches are allowed. I'd generally rather not do this. You can't use MAP_FIXED to request adjacent regions, so why should you anticipate there would be any? Adjacent regions can happen by accident, and the uClibc malloc will try to merge free areas when they are adjacent - there's a lot of special-case code in there to prevent this on uClinux systems by essentially duplicating VMA tracking. That's something we want to avoid, because it eats performance (especially in threaded apps due to additional locking). Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote:
David Howells <[EMAIL PROTECTED]> wrote:
Yes. I found the major leak this morning. There may be a minor leak, but I'm
not convinced it's in the mmap stuff. See revised patch.
Oops. That was the old patch. Try this one instead.
Here are some changes to make it more stable on my system. In
do_mmap_private, I've commented out the logic to free excess pages, as
it fragments terribly and causes a simple
while true; do cat /proc/buddyinfo; done
loop to go oom. Also, I think you're freeing high-order pages unaligned
to their order?
In shrink_vma, we must save the mm across calls to remove_vma_from_mm
(oops when telnetting into the box).
In do_munmap, we can deal with freeing more than one vma. I've not
touched the rb-tree logic in the shared file case, as I have no idea
what it's trying to do given that only exact matches are allowed.
It still does not survive my mmap stress-tester, so I'll keep looking.
Why do we need vm_regions for anonymous memory? Wouldn't it be enough
to just have a VMA?
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
diff --width=180 -x '*~' -x '.*' -x 'Sys*' -dru
linux-2.6.x-daves-baseline/mm/nommu.c linux-2.6.x/mm/nommu.c
--- linux-2.6.x-daves-baseline/mm/nommu.c 2007-08-14 21:20:43.0
+0200
+++ linux-2.6.x/mm/nommu.c 2007-08-16 19:11:29.0 +0200
@@ -922,19 +931,23 @@
total = 1 << order;
atomic_add(total, _pages_allocated);
- point = len >> PAGE_SHIFT;
- while (point < total) {
- order = ilog2(total - point);
- _debug("shave %u/%lu", 1 << order, total - point);
- atomic_sub(1 << order, _pages_allocated);
- __free_pages(pages + point, order);
- point += 1 << order;
+ len = PAGE_SIZE << order;
+#if 0
+ while (total > (len >> PAGE_SHIFT)) {
+ unsigned long to_free;
+ order = ilog2(total - (len >> PAGE_SHIFT));
+ to_free = 1 << order;
+ _debug("shave %u/%lu", to_free, total - (len >> PAGE_SHIFT));
+ atomic_sub(to_free, _pages_allocated);
+ __free_pages(pages + total - to_free, order);
+ total -= to_free;
}
total = len >> PAGE_SHIFT;
for (point = 1; point < total; point++)
set_page_refcounted([point]);
-
+#endif
+ split_page(pages, order);
base = page_address(pages);
region->vm_start = vma->vm_start = (unsigned long) base;
region->vm_end = vma->vm_end = vma->vm_start + len;
@@ -1294,6 +1307,7 @@
unsigned long from, unsigned long to)
{
struct vm_region *region;
+ struct mm_struct *mm = vma->vm_mm;
_enter("");
@@ -1304,7 +1318,7 @@
vma->vm_end = from;
else
vma->vm_start = to;
- add_vma_to_mm(vma->vm_mm, vma);
+ add_vma_to_mm(mm, vma);
/* cut the region down to size */
region = vma->vm_region;
@@ -1337,44 +1351,59 @@
_enter(",%lx,%zx", start, len);
- /* find the first potentially overlapping VMA */
- vma = find_vma(mm, start);
- if (!vma) {
- _leave(" = -EINVAL [no]");
- return -EINVAL;
- }
-
- /* we're allowed to split an anonymous VMA but not a file-backed one */
- if (vma->vm_file) {
- do {
- if (start > vma->vm_start) {
- _leave(" = -EINVAL [miss]");
- return -EINVAL;
- }
- if (end == vma->vm_end)
- goto erase_whole_vma;
- rb = rb_next(>vm_rb);
- vma = rb_entry(rb, struct vm_area_struct, vm_rb);
- } while (rb);
- _leave(" = -EINVAL [split file]");
- return -EINVAL;
- } else {
- /* the region must be a subset of the VMA found */
- if (start == vma->vm_start && end == vma->vm_end)
- goto erase_whole_vma;
- if (start < vma->vm_start || end > vma->vm_end) {
+ while (start < end) {
+ unsigned long this_end;
+ /* find the first potentially overlapping VMA */
+ vma = find_vma(mm, start);
+ if (!vma) {
+ _leave(" = -EINVAL [no]");
+ return -EINVAL;
+ }
+ if (start < vma->vm_start) {
_leave(" = -EINVAL [superset]");
return -EINVAL;
}
- if (start != vma->vm_start && end != vma->vm_end) {
+
+
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote:
David Howells [EMAIL PROTECTED] wrote:
Yes. I found the major leak this morning. There may be a minor leak, but I'm
not convinced it's in the mmap stuff. See revised patch.
Oops. That was the old patch. Try this one instead.
Here are some changes to make it more stable on my system. In
do_mmap_private, I've commented out the logic to free excess pages, as
it fragments terribly and causes a simple
while true; do cat /proc/buddyinfo; done
loop to go oom. Also, I think you're freeing high-order pages unaligned
to their order?
In shrink_vma, we must save the mm across calls to remove_vma_from_mm
(oops when telnetting into the box).
In do_munmap, we can deal with freeing more than one vma. I've not
touched the rb-tree logic in the shared file case, as I have no idea
what it's trying to do given that only exact matches are allowed.
It still does not survive my mmap stress-tester, so I'll keep looking.
Why do we need vm_regions for anonymous memory? Wouldn't it be enough
to just have a VMA?
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
diff --width=180 -x '*~' -x '.*' -x 'Sys*' -dru
linux-2.6.x-daves-baseline/mm/nommu.c linux-2.6.x/mm/nommu.c
--- linux-2.6.x-daves-baseline/mm/nommu.c 2007-08-14 21:20:43.0
+0200
+++ linux-2.6.x/mm/nommu.c 2007-08-16 19:11:29.0 +0200
@@ -922,19 +931,23 @@
total = 1 order;
atomic_add(total, mmap_pages_allocated);
- point = len PAGE_SHIFT;
- while (point total) {
- order = ilog2(total - point);
- _debug(shave %u/%lu, 1 order, total - point);
- atomic_sub(1 order, mmap_pages_allocated);
- __free_pages(pages + point, order);
- point += 1 order;
+ len = PAGE_SIZE order;
+#if 0
+ while (total (len PAGE_SHIFT)) {
+ unsigned long to_free;
+ order = ilog2(total - (len PAGE_SHIFT));
+ to_free = 1 order;
+ _debug(shave %u/%lu, to_free, total - (len PAGE_SHIFT));
+ atomic_sub(to_free, mmap_pages_allocated);
+ __free_pages(pages + total - to_free, order);
+ total -= to_free;
}
total = len PAGE_SHIFT;
for (point = 1; point total; point++)
set_page_refcounted(pages[point]);
-
+#endif
+ split_page(pages, order);
base = page_address(pages);
region-vm_start = vma-vm_start = (unsigned long) base;
region-vm_end = vma-vm_end = vma-vm_start + len;
@@ -1294,6 +1307,7 @@
unsigned long from, unsigned long to)
{
struct vm_region *region;
+ struct mm_struct *mm = vma-vm_mm;
_enter();
@@ -1304,7 +1318,7 @@
vma-vm_end = from;
else
vma-vm_start = to;
- add_vma_to_mm(vma-vm_mm, vma);
+ add_vma_to_mm(mm, vma);
/* cut the region down to size */
region = vma-vm_region;
@@ -1337,44 +1351,59 @@
_enter(,%lx,%zx, start, len);
- /* find the first potentially overlapping VMA */
- vma = find_vma(mm, start);
- if (!vma) {
- _leave( = -EINVAL [no]);
- return -EINVAL;
- }
-
- /* we're allowed to split an anonymous VMA but not a file-backed one */
- if (vma-vm_file) {
- do {
- if (start vma-vm_start) {
- _leave( = -EINVAL [miss]);
- return -EINVAL;
- }
- if (end == vma-vm_end)
- goto erase_whole_vma;
- rb = rb_next(vma-vm_rb);
- vma = rb_entry(rb, struct vm_area_struct, vm_rb);
- } while (rb);
- _leave( = -EINVAL [split file]);
- return -EINVAL;
- } else {
- /* the region must be a subset of the VMA found */
- if (start == vma-vm_start end == vma-vm_end)
- goto erase_whole_vma;
- if (start vma-vm_start || end vma-vm_end) {
+ while (start end) {
+ unsigned long this_end;
+ /* find the first potentially overlapping VMA */
+ vma = find_vma(mm, start);
+ if (!vma) {
+ _leave( = -EINVAL [no]);
+ return -EINVAL;
+ }
+ if (start vma-vm_start) {
_leave( = -EINVAL [superset]);
return -EINVAL;
}
- if (start != vma-vm_start end != vma-vm_end) {
+
+ this_end = vma-vm_end;
+
+ /* See if we
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote: > Here's a preview of my patch to give each process a separate list of VMAs > under NOMMU mode, just as under MMU mode. Could you have a look over it > please? I've managed to apply it to our Blackfin tree and started looking at it. > Could you also see if you get a memory leak on the blackfin CPU? I see a leak > when I use this patch, but I'm not sure whether it's this patch, or whether > it's something else in the arch that is suppressed without this patch. > > As far as I can tell by page counting there shouldn't be a leak. There is a leak: root:~> while true; do > cat /proc/buddyinfo > sleep 1 > done Node 0, zone DMA 20 1 1 1 0 1 1 1 0 0 0 1 2 0 Node 0, zone DMA 32 1 1 0 0 0 1 0 0 0 0 1 2 0 Node 0, zone DMA 47 1 1 1 1 0 0 1 1 1 1 0 2 0 Node 0, zone DMA 62 1 1 0 1 1 1 1 0 1 1 0 2 0 Node 0, zone DMA 77 1 1 1 0 0 1 0 0 1 1 0 2 0 Node 0, zone DMA 92 1 1 0 0 1 0 1 1 0 1 0 2 0 Node 0, zone DMA107 1 1 1 1 1 1 1 0 0 1 0 2 0 Node 0, zone DMA122 1 1 0 1 0 1 0 0 0 1 0 2 0 Node 0, zone DMA137 1 1 1 0 1 0 1 1 1 0 0 2 0 ... and so on. It's a strange pattern of fragmentation, as if it keeps allocating 8k pages and freeing one half of them. Will play with this some more. Thanks! Bernd - 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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote:
> + /* we allocated a power-of-2 sized page set, so we need to trim off the
> + * excess */
> + total = 1 << order;
> + atomic_add(total, _pages_allocated);
> +
> + point = len >> PAGE_SHIFT;
> + while (point < total) {
> + order = ilog2(total - point);
> + _debug("shave %u/%lu", 1 << order, total - point);
> + atomic_sub(1 << order, _pages_allocated);
> + __free_pages(pages + point, order);
> + point += 1 << order;
> + }
Note that we've had a similar change in our kernel, and we've had to
revert it since the effect on fragmentation is just horrendous. Without
this, we could run a complete gcc testsuite on the board; with it we'd
run out of high-order pages somewhere in the middle.
This probably wants to be dependent on something like MAP_TRIM_EXCESS.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote:
+ /* we allocated a power-of-2 sized page set, so we need to trim off the
+ * excess */
+ total = 1 order;
+ atomic_add(total, mmap_pages_allocated);
+
+ point = len PAGE_SHIFT;
+ while (point total) {
+ order = ilog2(total - point);
+ _debug(shave %u/%lu, 1 order, total - point);
+ atomic_sub(1 order, mmap_pages_allocated);
+ __free_pages(pages + point, order);
+ point += 1 order;
+ }
Note that we've had a similar change in our kernel, and we've had to
revert it since the effect on fragmentation is just horrendous. Without
this, we could run a complete gcc testsuite on the board; with it we'd
run out of high-order pages somewhere in the middle.
This probably wants to be dependent on something like MAP_TRIM_EXCESS.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
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/
Re: [PATCH] NOMMU: Separate out VMAs
David Howells wrote: Here's a preview of my patch to give each process a separate list of VMAs under NOMMU mode, just as under MMU mode. Could you have a look over it please? I've managed to apply it to our Blackfin tree and started looking at it. Could you also see if you get a memory leak on the blackfin CPU? I see a leak when I use this patch, but I'm not sure whether it's this patch, or whether it's something else in the arch that is suppressed without this patch. As far as I can tell by page counting there shouldn't be a leak. There is a leak: root:~ while true; do cat /proc/buddyinfo sleep 1 done Node 0, zone DMA 20 1 1 1 0 1 1 1 0 0 0 1 2 0 Node 0, zone DMA 32 1 1 0 0 0 1 0 0 0 0 1 2 0 Node 0, zone DMA 47 1 1 1 1 0 0 1 1 1 1 0 2 0 Node 0, zone DMA 62 1 1 0 1 1 1 1 0 1 1 0 2 0 Node 0, zone DMA 77 1 1 1 0 0 1 0 0 1 1 0 2 0 Node 0, zone DMA 92 1 1 0 0 1 0 1 1 0 1 0 2 0 Node 0, zone DMA107 1 1 1 1 1 1 1 0 0 1 0 2 0 Node 0, zone DMA122 1 1 0 1 0 1 0 0 0 1 0 2 0 Node 0, zone DMA137 1 1 1 0 1 0 1 1 1 0 0 2 0 ... and so on. It's a strange pattern of fragmentation, as if it keeps allocating 8k pages and freeing one half of them. Will play with this some more. Thanks! Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Greg KH wrote: On Sun, Jun 17, 2007 at 02:56:24AM -0300, Alexandre Oliva wrote: If you want your opinions to stand a chance to make a difference, the right place to provide them is gplv3.fsf.org/comments, and time is running short. [...] So, why would we want to waste our time filling out web forms after that? In case anyone was wondering if the FSF is genuinely interested in feedback - I went and made some comments on the draft, and they appear to no longer be there a few days later. Thanks for the invitation Alex. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Greg KH wrote: On Sun, Jun 17, 2007 at 02:56:24AM -0300, Alexandre Oliva wrote: If you want your opinions to stand a chance to make a difference, the right place to provide them is gplv3.fsf.org/comments, and time is running short. [...] So, why would we want to waste our time filling out web forms after that? In case anyone was wondering if the FSF is genuinely interested in feedback - I went and made some comments on the draft, and they appear to no longer be there a few days later. Thanks for the invitation Alex. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: > On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: >> No. You've explained one thing only: that you cannot see that people don't >> *agree* on the "spirit". > > They don't have to. > > Just like nobody but you can tell why you chose the GPLv2, nobody but > RMS can tell why he wrote the GPL. And the intent behind writing the > GPL is what defines its spirit. Given that a number of people who don't buy into FSF ideology (let's call them "open source proponents" to contrast them with the "free software people") have concluded that the GPLv2 achieves their personal goals, and have chosen the GPLv2 as the license for their projects, I'd argue that the spirit that is embodied in the GPLv2 is actually a larger thing than what the FSF intended, and more inclusive. When these same people now disagree with the GPLv3, it indicates that something has been lost, and the spirit of the _license_ has changed. The _intention_ behind writing the license may or may not have been the same (who can tell, after 20-odd years?), but this is separate from the spirit embodied in the license itself - the latter has, in my mind anyway, clearly been changed. You might prefer to say "clarified", but it comes down to the same thing. But personally, I find the discussion about whether the spirit changed or not somewhat beside the point and not very interesting. What's really going to cause problems is the fact that the actual wording took a turn for the worse. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 17, 2007, Linus Torvalds [EMAIL PROTECTED] wrote: No. You've explained one thing only: that you cannot see that people don't *agree* on the spirit. They don't have to. Just like nobody but you can tell why you chose the GPLv2, nobody but RMS can tell why he wrote the GPL. And the intent behind writing the GPL is what defines its spirit. Given that a number of people who don't buy into FSF ideology (let's call them open source proponents to contrast them with the free software people) have concluded that the GPLv2 achieves their personal goals, and have chosen the GPLv2 as the license for their projects, I'd argue that the spirit that is embodied in the GPLv2 is actually a larger thing than what the FSF intended, and more inclusive. When these same people now disagree with the GPLv3, it indicates that something has been lost, and the spirit of the _license_ has changed. The _intention_ behind writing the license may or may not have been the same (who can tell, after 20-odd years?), but this is separate from the spirit embodied in the license itself - the latter has, in my mind anyway, clearly been changed. You might prefer to say clarified, but it comes down to the same thing. But personally, I find the discussion about whether the spirit changed or not somewhat beside the point and not very interesting. What's really going to cause problems is the fact that the actual wording took a turn for the worse. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: > On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > >> Alexandre Oliva wrote: >>> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: >>> >>>> What this means for the FSF goals if Tivo get up one morning and switch >>>> their system firmware to ROM however is interesting 8) >>> I'm not the FSF, and I don't speak for it, but it seems to me that >>> this would be "mission accomplished". > >> This is insane. You start with a lofty ideal involving "freedom", and >> when you end up with a meaningless technicality (and in technical terms >> a change for the worse) you consider it a victory? > > It accomplishes the mission in that everyone is on the same grounds. > Same freedom for everyone. See, that's the problem I have with your arguments. "Same freedom for everyone" is a political slogan. It is not a reasoned thought. "We must stop terrorists" is also a political slogan, and the consequence "Tivo should install ROMs so they don't have more rights than users" is about equivalent as a victory for freedom as disallowing liquids in hand luggage is a victory against terrorism. Both are nonsensical consequences of a political agenda that is applied without thought. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: > On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: > >> What this means for the FSF goals if Tivo get up one morning and switch >> their system firmware to ROM however is interesting 8) > > I'm not the FSF, and I don't speak for it, but it seems to me that > this would be "mission accomplished". This is insane. You start with a lofty ideal involving "freedom", and when you end up with a meaningless technicality (and in technical terms a change for the worse) you consider it a victory? Yes, I know that this is what happens in politics (look here, our laws had an effect!), but I have more respect for you than to think you fall for these kinds of games. I do not wish to revise my opinion. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 15, 2007, Alan Cox [EMAIL PROTECTED] wrote: What this means for the FSF goals if Tivo get up one morning and switch their system firmware to ROM however is interesting 8) I'm not the FSF, and I don't speak for it, but it seems to me that this would be mission accomplished. This is insane. You start with a lofty ideal involving freedom, and when you end up with a meaningless technicality (and in technical terms a change for the worse) you consider it a victory? Yes, I know that this is what happens in politics (look here, our laws had an effect!), but I have more respect for you than to think you fall for these kinds of games. I do not wish to revise my opinion. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 16, 2007, Bernd Schmidt [EMAIL PROTECTED] wrote: Alexandre Oliva wrote: On Jun 15, 2007, Alan Cox [EMAIL PROTECTED] wrote: What this means for the FSF goals if Tivo get up one morning and switch their system firmware to ROM however is interesting 8) I'm not the FSF, and I don't speak for it, but it seems to me that this would be mission accomplished. This is insane. You start with a lofty ideal involving freedom, and when you end up with a meaningless technicality (and in technical terms a change for the worse) you consider it a victory? It accomplishes the mission in that everyone is on the same grounds. Same freedom for everyone. See, that's the problem I have with your arguments. Same freedom for everyone is a political slogan. It is not a reasoned thought. We must stop terrorists is also a political slogan, and the consequence Tivo should install ROMs so they don't have more rights than users is about equivalent as a victory for freedom as disallowing liquids in hand luggage is a victory against terrorism. Both are nonsensical consequences of a political agenda that is applied without thought. Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: > On Jun 14, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > >> Tivo gets sick of the endless flamewars on lkml, signs a copy >> of QNX, pushes it out to the hardware. No more Linux on Tivo. > > What do we lose? > > Do we actually get any benefit whatsoever from TiVO's choice of Linux > as the kernel for its device? Do they contribute back any code that makes Linux better? If Tivo doesn't, what about other vendors who may be in a similar situation? Bernd - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: On Jun 14, 2007, Bron Gondwana [EMAIL PROTECTED] wrote: Tivo gets sick of the endless flamewars on lkml, signs a copy of QNX, pushes it out to the hardware. No more Linux on Tivo. What do we lose? Do we actually get any benefit whatsoever from TiVO's choice of Linux as the kernel for its device? Do they contribute back any code that makes Linux better? If Tivo doesn't, what about other vendors who may be in a similar situation? Bernd - 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/
Re: [PATCH, RFD]: Unbreak no-mmu mmap
Mike Frysinger wrote: > On 6/9/07, Matt Mackall <[EMAIL PROTECTED]> wrote: >> On Fri, Jun 08, 2007 at 03:53:49PM +0200, Bernd Schmidt wrote: >> > 2. It is no longer possible to get blocks smaller than a page through >> >mmap. This behaviour was used by simplemalloc, which is an insane >> >way of implementing malloc on nommu systems and hopefully not used >> >by anyone anymore. >> >> That's worrisome. Breaking existing apps/libraries seems like a bad >> idea. > > it isnt breaking anything ... simplemalloc() will continue to execute > in newer kernels While that's true, it'll have an even bigger memory overhead than it already does (simplemalloc, by trapping into the kernel and creating vm_area/vm_list structures for every malloc call, has huge overheads in both time and space). I've posted this as an RFD to get a feeling for whether we can change behaviour here - I do expect that nommu embedded systems are less constrained by backwards compatibility considerations, but I'd like to hear from other embedded users whether this is a change they'd welcome. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH, RFD]: Unbreak no-mmu mmap
Mike Frysinger wrote: On 6/9/07, Matt Mackall [EMAIL PROTECTED] wrote: On Fri, Jun 08, 2007 at 03:53:49PM +0200, Bernd Schmidt wrote: 2. It is no longer possible to get blocks smaller than a page through mmap. This behaviour was used by simplemalloc, which is an insane way of implementing malloc on nommu systems and hopefully not used by anyone anymore. That's worrisome. Breaking existing apps/libraries seems like a bad idea. it isnt breaking anything ... simplemalloc() will continue to execute in newer kernels While that's true, it'll have an even bigger memory overhead than it already does (simplemalloc, by trapping into the kernel and creating vm_area/vm_list structures for every malloc call, has huge overheads in both time and space). I've posted this as an RFD to get a feeling for whether we can change behaviour here - I do expect that nommu embedded systems are less constrained by backwards compatibility considerations, but I'd like to hear from other embedded users whether this is a change they'd welcome. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
[PATCH, RFD]: Unbreak no-mmu mmap
Here's a patch to move nommu mmap/munmap ever so slightly closer to mmu
behaviour. The motivation for this is to be able to deselect uClibc's
UCLIBC_UCLINUX_BROKEN_MUNMAP config option, which speeds up malloc a
fair bit. I'm interested in comments whether this is a good direction
to go. The patch is against Linus' tree as of a few minutes ago.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
This changes nommu mmap/munmap in the following ways:
1. munmap can now unmap subparts of previously allocated blocks. This
makes behaviour more consistent with mmu Linux, and allows us to
simplify and speed up the uClibc malloc implementation.
2. It is no longer possible to get blocks smaller than a page through
mmap. This behaviour was used by simplemalloc, which is an insane
way of implementing malloc on nommu systems and hopefully not used
by anyone anymore.
3. mmap can now be asked not to round up the allocation to the next
power of 2 page size. Excess pages will be freed if MAP_SPLIT_PAGES
is passed to mmap.
The latter is done for binfmt_flat and binfmt_elf_fdpic to save
memory when loading executables.
If this flag is used, more memory is kept available, but fragmentation
may (or may not) be higher.
Every VMA can be in two states: either it manages a power-of-2 sized compound
page, or (if VM_SPLIT_PAGES) is set, a set of single pages exactly covering
the area between vm_start and vm_end.
Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]>
fs/binfmt_elf_fdpic.c | 17 +-
fs/binfmt_flat.c| 40 ++---
fs/proc/task_nommu.c| 14 +-
include/asm-blackfin/mman.h |1 +
include/linux/mm.h |2 +
mm/nommu.c | 294 ---
mm/page_alloc.c | 10 +
7 files changed, 263 insertions(+), 115 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9d62fba..4449412 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -167,9 +167,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
struct elf_fdpic_params exec_params, interp_params;
struct elf_phdr *phdr;
unsigned long stack_size, entryaddr;
-#ifndef CONFIG_MMU
- unsigned long fullsize;
-#endif
#ifdef ELF_FDPIC_PLAT_INIT
unsigned long dynaddr;
#endif
@@ -373,8 +370,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
down_write(>mm->mmap_sem);
current->mm->start_brk = do_mmap(NULL, 0, stack_size,
PROT_READ | PROT_WRITE | PROT_EXEC,
-MAP_PRIVATE | MAP_ANONYMOUS |
MAP_GROWSDOWN,
-0);
+MAP_PRIVATE | MAP_ANONYMOUS
+| MAP_GROWSDOWN | MAP_SPLIT_PAGES, 0);
if (IS_ERR_VALUE(current->mm->start_brk)) {
up_write(>mm->mmap_sem);
@@ -383,11 +380,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
goto error_kill;
}
- /* expand the stack mapping to use up the entire allocation granule */
- fullsize = ksize((char *) current->mm->start_brk);
- if (!IS_ERR_VALUE(do_mremap(current->mm->start_brk, stack_size,
- fullsize, 0, 0)))
- stack_size = fullsize;
up_write(>mm->mmap_sem);
current->mm->brk = current->mm->start_brk;
@@ -906,7 +898,8 @@ static int elf_fdpic_map_file_constdisp_on_uclinux(
down_write(>mmap_sem);
maddr = do_mmap(NULL, load_addr, top - base,
- PROT_READ | PROT_WRITE | PROT_EXEC, mflags, 0);
+ PROT_READ | PROT_WRITE | PROT_EXEC,
+ mflags | MAP_SPLIT_PAGES, 0);
up_write(>mmap_sem);
if (IS_ERR_VALUE(maddr))
return (int) maddr;
@@ -1006,7 +999,7 @@ static int elf_fdpic_map_file_by_direct_mmap(struct
elf_fdpic_params *params,
if (phdr->p_flags & PF_W) prot |= PROT_WRITE;
if (phdr->p_flags & PF_X) prot |= PROT_EXEC;
- flags = MAP_PRIVATE | MAP_DENYWRITE;
+ flags = MAP_PRIVATE | MAP_DENYWRITE | MAP_SPLIT_PAGES;
if (params->flags & ELF_FDPIC_FLAG_EXECUTABLE)
flags |= MAP_EXECUTABLE;
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 7b0265d..b77f765 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -419,8 +419,8 @@ static int load_flat_file(struct linux_binpr
[PATCH, RFD]: Unbreak no-mmu mmap
Here's a patch to move nommu mmap/munmap ever so slightly closer to mmu
behaviour. The motivation for this is to be able to deselect uClibc's
UCLIBC_UCLINUX_BROKEN_MUNMAP config option, which speeds up malloc a
fair bit. I'm interested in comments whether this is a good direction
to go. The patch is against Linus' tree as of a few minutes ago.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
This changes nommu mmap/munmap in the following ways:
1. munmap can now unmap subparts of previously allocated blocks. This
makes behaviour more consistent with mmu Linux, and allows us to
simplify and speed up the uClibc malloc implementation.
2. It is no longer possible to get blocks smaller than a page through
mmap. This behaviour was used by simplemalloc, which is an insane
way of implementing malloc on nommu systems and hopefully not used
by anyone anymore.
3. mmap can now be asked not to round up the allocation to the next
power of 2 page size. Excess pages will be freed if MAP_SPLIT_PAGES
is passed to mmap.
The latter is done for binfmt_flat and binfmt_elf_fdpic to save
memory when loading executables.
If this flag is used, more memory is kept available, but fragmentation
may (or may not) be higher.
Every VMA can be in two states: either it manages a power-of-2 sized compound
page, or (if VM_SPLIT_PAGES) is set, a set of single pages exactly covering
the area between vm_start and vm_end.
Signed-off-by: Bernd Schmidt [EMAIL PROTECTED]
fs/binfmt_elf_fdpic.c | 17 +-
fs/binfmt_flat.c| 40 ++---
fs/proc/task_nommu.c| 14 +-
include/asm-blackfin/mman.h |1 +
include/linux/mm.h |2 +
mm/nommu.c | 294 ---
mm/page_alloc.c | 10 +
7 files changed, 263 insertions(+), 115 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9d62fba..4449412 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -167,9 +167,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
struct elf_fdpic_params exec_params, interp_params;
struct elf_phdr *phdr;
unsigned long stack_size, entryaddr;
-#ifndef CONFIG_MMU
- unsigned long fullsize;
-#endif
#ifdef ELF_FDPIC_PLAT_INIT
unsigned long dynaddr;
#endif
@@ -373,8 +370,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
down_write(current-mm-mmap_sem);
current-mm-start_brk = do_mmap(NULL, 0, stack_size,
PROT_READ | PROT_WRITE | PROT_EXEC,
-MAP_PRIVATE | MAP_ANONYMOUS |
MAP_GROWSDOWN,
-0);
+MAP_PRIVATE | MAP_ANONYMOUS
+| MAP_GROWSDOWN | MAP_SPLIT_PAGES, 0);
if (IS_ERR_VALUE(current-mm-start_brk)) {
up_write(current-mm-mmap_sem);
@@ -383,11 +380,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
goto error_kill;
}
- /* expand the stack mapping to use up the entire allocation granule */
- fullsize = ksize((char *) current-mm-start_brk);
- if (!IS_ERR_VALUE(do_mremap(current-mm-start_brk, stack_size,
- fullsize, 0, 0)))
- stack_size = fullsize;
up_write(current-mm-mmap_sem);
current-mm-brk = current-mm-start_brk;
@@ -906,7 +898,8 @@ static int elf_fdpic_map_file_constdisp_on_uclinux(
down_write(mm-mmap_sem);
maddr = do_mmap(NULL, load_addr, top - base,
- PROT_READ | PROT_WRITE | PROT_EXEC, mflags, 0);
+ PROT_READ | PROT_WRITE | PROT_EXEC,
+ mflags | MAP_SPLIT_PAGES, 0);
up_write(mm-mmap_sem);
if (IS_ERR_VALUE(maddr))
return (int) maddr;
@@ -1006,7 +999,7 @@ static int elf_fdpic_map_file_by_direct_mmap(struct
elf_fdpic_params *params,
if (phdr-p_flags PF_W) prot |= PROT_WRITE;
if (phdr-p_flags PF_X) prot |= PROT_EXEC;
- flags = MAP_PRIVATE | MAP_DENYWRITE;
+ flags = MAP_PRIVATE | MAP_DENYWRITE | MAP_SPLIT_PAGES;
if (params-flags ELF_FDPIC_FLAG_EXECUTABLE)
flags |= MAP_EXECUTABLE;
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 7b0265d..b77f765 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -419,8 +419,8 @@ static int load_flat_file(struct linux_binprm * bprm,
unsigned long textpos = 0, datapos = 0, result;
unsigned long
Re: [PATCH 00/20] Blackfin update for 2.6.22-rc3
Linus Torvalds wrote: > > On Mon, 28 May 2007, Bryan Wu wrote: >> - Blackfin arch update including BF54x initial supporting >> - Blackfin driver update: serial/spi/rtc >> - Provide new Blackfin watchdog driver >> - binfmt_flat.c for Blackfin arch modification > > I realize that this all just touches blackfin-specific stuff, but after > -rc3 I really prefer not to bother with these things.. > > Also, for stuff that is really just an architecture that I can't even > test, and where there is a clear maintainership thing, I'd actually prefer > to just do a git merge, if possible. It's not like I will likely start > looking at some blackfin-specific patches. Judging from the diffs, you do > actually use git, do you have a place where you could export these kinds > of patch-series as a git tree instead? The binfmt_flat patch also touches other nommu architectures. Do you want these kinds of patches (which aren't just Blackfin-specific) separately as they come up? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH 00/20] Blackfin update for 2.6.22-rc3
Linus Torvalds wrote: On Mon, 28 May 2007, Bryan Wu wrote: - Blackfin arch update including BF54x initial supporting - Blackfin driver update: serial/spi/rtc - Provide new Blackfin watchdog driver - binfmt_flat.c for Blackfin arch modification I realize that this all just touches blackfin-specific stuff, but after -rc3 I really prefer not to bother with these things.. Also, for stuff that is really just an architecture that I can't even test, and where there is a clear maintainership thing, I'd actually prefer to just do a git merge, if possible. It's not like I will likely start looking at some blackfin-specific patches. Judging from the diffs, you do actually use git, do you have a place where you could export these kinds of patch-series as a git tree instead? The binfmt_flat patch also touches other nommu architectures. Do you want these kinds of patches (which aren't just Blackfin-specific) separately as they come up? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - 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/
Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update
Paul Mundt wrote: +comment "Memory Optimizations" + +config I_ENTRY_L1 + bool "Locate interrupt entry code in L1 Memory" + default y + help + If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked + into L1 instruction memory.(less latency) + Wow, this is really crying out for a special linker section with slightly more intelligent relocation logic. You should flag the performance critical parts to be located in L1 memory directly with a section attribute, rather than making everything selectable. If you overflow you can simply spill in to main memory. This is done intentionally, because it's also possible for user code to be loaded into L1 memory. We want to give users the option to avoid filling it all up with kernel code. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough - 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/
Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update
Paul Mundt wrote: +comment Memory Optimizations + +config I_ENTRY_L1 + bool Locate interrupt entry code in L1 Memory + default y + help + If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked + into L1 instruction memory.(less latency) + Wow, this is really crying out for a special linker section with slightly more intelligent relocation logic. You should flag the performance critical parts to be located in L1 memory directly with a section attribute, rather than making everything selectable. If you overflow you can simply spill in to main memory. This is done intentionally, because it's also possible for user code to be loaded into L1 memory. We want to give users the option to avoid filling it all up with kernel code. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough - 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/
Re: PROBLEM:Illegal instruction when mount nfs file systems using
On Fri, 29 Jun 2001, Alan Cox wrote: > > Here I have to disagree with you Alan. When you pass "-march=i686" to > > gcc, you are _not_ saying "generate code for a CPUID family 6 CPU". > > "-march=i686" actually means "target an Intel P6 family chip, given > > what we currently know about them". The gcc info pages don't talk > > Which is fine. The Pentium Pro manual explicitly states that cmov may go > away. So it is not based on what we know about the CPU, its based on not > reading the documentation. > > It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...' > It happens to work because the error in reading the docs was never triggered > by intel removing cmov from a cpu as the reserved the right to do Pedantically you may be right, but it's not a very useful interpretation of the situation. Would it make you happier if -march=i686 was documented as generating cmov instructions? IMO it's only a manual bug if at all. Bernd - 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/
Re: PROBLEM:Illegal instruction when mount nfs file systems using
On Fri, 29 Jun 2001, Alan Cox wrote: Here I have to disagree with you Alan. When you pass -march=i686 to gcc, you are _not_ saying generate code for a CPUID family 6 CPU. -march=i686 actually means target an Intel P6 family chip, given what we currently know about them. The gcc info pages don't talk Which is fine. The Pentium Pro manual explicitly states that cmov may go away. So it is not based on what we know about the CPU, its based on not reading the documentation. It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...' It happens to work because the error in reading the docs was never triggered by intel removing cmov from a cpu as the reserved the right to do Pedantically you may be right, but it's not a very useful interpretation of the situation. Would it make you happier if -march=i686 was documented as generating cmov instructions? IMO it's only a manual bug if at all. Bernd - 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/
Re: PROBLEM:Illegal instruction when mount nfs file systems usingcyr ixIII
On Wed, 27 Jun 2001, Alan Cox wrote: > > The problem is that VIA Cyrix III announces itself (via CPUID) > > as a "family 6" processor, i.e. i686 compatible. This is not > > completely accurate, since it doesn't implement the conditional > > move instruction. [Yeah, I know there's a CPUID feature flag for > > Intel specifically state that you cannot use CMOV without checking > for it. Its actually a gcc/binutils tool bug. The CPU is right. How is that a gcc bug? You tell the compiler to generate cmov, you run it on a CPU that doesn't have it, you get what you deserve. There's really nothing the tools can do about that. Bernd - 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/
Re: PROBLEM:Illegal instruction when mount nfs file systems usingcyr ixIII
On Wed, 27 Jun 2001, Alan Cox wrote: The problem is that VIA Cyrix III announces itself (via CPUID) as a family 6 processor, i.e. i686 compatible. This is not completely accurate, since it doesn't implement the conditional move instruction. [Yeah, I know there's a CPUID feature flag for Intel specifically state that you cannot use CMOV without checking for it. Its actually a gcc/binutils tool bug. The CPU is right. How is that a gcc bug? You tell the compiler to generate cmov, you run it on a CPU that doesn't have it, you get what you deserve. There's really nothing the tools can do about that. Bernd - 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/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Andreas Franck wrote: > Hello David, > > > I've been discussing it with some other kernel and GCC people, and they > > think > > that only "memory" is required. > > Hmm.. I just looked at my GCC problem report from December, perhaps you're > interested, too: > > http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html > > The example in there compiles out-of-the box and is much easier to > experiment on than the whole kernel :-) That example seems to fail because a "memory" clobber only tells the compiler that memory is written, not that it is read. Bernd - 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/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Andreas Franck wrote: Hello David, I've been discussing it with some other kernel and GCC people, and they think that only "memory" is required. Hmm.. I just looked at my GCC problem report from December, perhaps you're interested, too: http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html The example in there compiles out-of-the box and is much easier to experiment on than the whole kernel :-) That example seems to fail because a "memory" clobber only tells the compiler that memory is written, not that it is read. Bernd - 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/
Re: Proper OOPS report
On Mon, 22 Jan 2001, Henrik Stokseth wrote: > you were the one with the gcc 2.95.3 compiler right? even though this > compiler is a prerelease of a stable branch i have confirmed errors in the > optimalization passes. Details please. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proper OOPS report
On Mon, 22 Jan 2001, Henrik Stokseth wrote: you were the one with the gcc 2.95.3 compiler right? even though this compiler is a prerelease of a stable branch i have confirmed errors in the optimalization passes. Details please. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] performance enhancement for simple_strtoul
On Thu, 21 Dec 2000, Matthias Andree wrote: > > x * 10 can be written as: > > (x << 2 + x) << 1 = (4x+x) * 2 > (x << 3) + (x << 1) = 8x + 2x Or as "x * 10". Which has the advantage of actually being readable, and letting the compiler optimize it into one of the other forms if that's profitable on the machine you are compiling for. Why do you guys bother making strtoul run fast anyway? Surely it's not on any critical path in the kernel? Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] performance enhancement for simple_strtoul
On Thu, 21 Dec 2000, Matthias Andree wrote: x * 10 can be written as: (x 2 + x) 1 = (4x+x) * 2 (x 3) + (x 1) = 8x + 2x Or as "x * 10". Which has the advantage of actually being readable, and letting the compiler optimize it into one of the other forms if that's profitable on the machine you are compiling for. Why do you guys bother making strtoul run fast anyway? Surely it's not on any critical path in the kernel? Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc 2.95.2 is buggy
On Fri, 24 Nov 2000, Tom Rini wrote: > Well, now that there is a testcase, has anyone sent this on to the relevant > gcc lists? (The CCs I saw haven't) Yes. I've just sent a fix to gcc-patches. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc 2.95.2 is buggy
On Fri, 24 Nov 2000, Tom Rini wrote: Well, now that there is a testcase, has anyone sent this on to the relevant gcc lists? (The CCs I saw haven't) Yes. I've just sent a fix to gcc-patches. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Tue, 17 Oct 2000, Horst von Brand wrote: > Richard Guenther <[EMAIL PROTECTED]> said: > > The following one is wrong, tho - should be rather > > str[i] = dn[i]; i++; > > > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe > > d/drivers/isdn/sc/debug.c > > > --- linux-2.4/drivers/isdn/sc/debug.c Thu Apr 2 01:21:04 1998 > > > +++ linux-2.4-fixed/drivers/isdn/sc/debug.c Mon Oct 16 14:53:49 2000 > > > @@ -70,6 +70,6 @@ > > > int i = 0; > > > > > > while(dn[i] != ',') > > > - str[i] = dn[i++]; > > > + str[i] = dn[i], i++; > > > str[i] = 0x0; > > What is wrong with plain and simple: > >for(i = 0; dn[i] != ','; i++) > str[i] = dn[i]; >str[i] = '\0'; Nothing. Feel free to submit a better patch. I was just trying to correct the code with the minimum set of modifications so as to avoid breaking anything by accident. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Tue, 17 Oct 2000, Richard Guenther wrote: > On Tue, 17 Oct 2000, Bernd Schmidt wrote: > > On Tue, 17 Oct 2000, Richard Guenther wrote: > > > The following one is wrong, tho - should be rather > > > str[i] = dn[i]; i++; > > > > Nope. (Well, at least you need to add extra braces.) The comma is a > > sequence point. > > Umm, I thought, dn[i], i++ evaluates to i and dn[i++] evaluates > to dn[i], so it should be either i++, dn[i-1] or the one I showed > above? According to operator precedence rules, str[i] = dn[i], i++; is equivalent to (str[i] = dn[i]), i++; Comma has the lowest precedence of all C operators. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
> Looking at the above code, I noticed that there are a lot of ++ > operations. I rewrote the code as: > > setup_from[0] = setup_from[1] = eaddrs[0]; > setup_from[2] = setup_from[3] = eaddrs[1]; > setup_from[4] = setup_from[5] = eaddrs[2]; > setup_from += 6; > > I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate > the assembler code. The old code is 17 instructions long and the new code > is 11 instructions. As well as being shorter, simple timing test indicate > that the new code is significantly quicker. This is something the compiler ought to know about. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Tue, 17 Oct 2000, Helge Hafting wrote: > Bernd Schmidt wrote: > > > > I've been playing with some gcc patches to detect code with undefined > > behaviour of the i = i++ variety. The patch below fixes all places in > > the kernel that I could find. Note that in some cases, it wasn't > > entirely clear what the code intended, so I had to guess. > > Please don't guess. Look at the generated assembly, then make the > unambigous code do whatever the old code did. Chances are high it > worked ok by luck, as misbehaving code tend to get noticed as > it fails. That does seem to be true for all parts except the tulip code. I did look at the assembly where I was in doubt. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Tue, 17 Oct 2000, Richard Guenther wrote: > On Mon, 16 Oct 2000, Bernd Schmidt wrote: > > > I've been playing with some gcc patches to detect code with undefined > > behaviour of the i = i++ variety. The patch below fixes all places in > > the kernel that I could find. Note that in some cases, it wasn't > > entirely clear what the code intended, so I had to guess. > > > > I haven't tested this patch at all other than to make sure it compiles. > > The following one is wrong, tho - should be rather > str[i] = dn[i]; i++; Nope. (Well, at least you need to add extra braces.) The comma is a sequence point. > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c >linux-2.4-fixed/drivers/isdn/sc/debug.c > > --- linux-2.4/drivers/isdn/sc/debug.c Thu Apr 2 01:21:04 1998 > > +++ linux-2.4-fixed/drivers/isdn/sc/debug.c Mon Oct 16 14:53:49 2000 > > @@ -70,6 +70,6 @@ > > int i = 0; > > > > while(dn[i] != ',') > > - str[i] = dn[i++]; > > + str[i] = dn[i], i++; > > str[i] = 0x0; > > } Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Tue, 17 Oct 2000, Horst von Brand wrote: Richard Guenther [EMAIL PROTECTED] said: The following one is wrong, tho - should be rather str[i] = dn[i]; i++; diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe d/drivers/isdn/sc/debug.c --- linux-2.4/drivers/isdn/sc/debug.c Thu Apr 2 01:21:04 1998 +++ linux-2.4-fixed/drivers/isdn/sc/debug.c Mon Oct 16 14:53:49 2000 @@ -70,6 +70,6 @@ int i = 0; while(dn[i] != ',') - str[i] = dn[i++]; + str[i] = dn[i], i++; str[i] = 0x0; What is wrong with plain and simple: for(i = 0; dn[i] != ','; i++) str[i] = dn[i]; str[i] = '\0'; Nothing. Feel free to submit a better patch. I was just trying to correct the code with the minimum set of modifications so as to avoid breaking anything by accident. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Mon, 16 Oct 2000, Jeff Garzik wrote: > > --- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000 > > +++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000 > > @@ -1280,7 +1280,8 @@ > > scsi_unregister(shpnt); > > registered_count--; > > release_region(shpnt->io_port, IO_RANGE); > > - aha152x_host[shpnt->irq - IRQ_MIN] = shpnt = 0; > > + aha152x_host[shpnt->irq - IRQ_MIN] = 0; > > + shpnt = 0; > > continue; > > } > > Why this change? aha152x_host[shpnt->irq - IRQ_MIN] = shpnt = 0; reference set Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch to remove undefined C code
I've been playing with some gcc patches to detect code with undefined
behaviour of the i = i++ variety. The patch below fixes all places in
the kernel that I could find. Note that in some cases, it wasn't
entirely clear what the code intended, so I had to guess.
I haven't tested this patch at all other than to make sure it compiles.
Bernd
diff -x log.build -x .* -dru linux-2.4/drivers/i2o/i2o_core.c
linux-2.4-fixed/drivers/i2o/i2o_core.c
--- linux-2.4/drivers/i2o/i2o_core.cMon Jun 19 21:30:56 2000
+++ linux-2.4-fixed/drivers/i2o/i2o_core.c Mon Oct 16 14:52:46 2000
@@ -183,7 +183,7 @@
static int evt_in = 0;
static int evt_out = 0;
static int evt_q_len = 0;
-#define MODINC(x,y) (x = x++ % y)
+#define MODINC(x,y) ((x) = ((x) + 1) % (y))
/*
* I2O configuration spinlock. This isnt a big deal for contention
diff -x log.build -x .* -dru linux-2.4/drivers/ide/alim15x3.c
linux-2.4-fixed/drivers/ide/alim15x3.c
--- linux-2.4/drivers/ide/alim15x3.cTue Jun 20 15:52:36 2000
+++ linux-2.4-fixed/drivers/ide/alim15x3.c Mon Oct 16 15:10:24 2000
@@ -171,11 +171,11 @@
((reg5yh & 0x30)>>4) + 12 );
}
} else {
- p += sprintf(p, q,
- (tmp = (reg5xh & 0x03)) ? (tmp << 3) : 4,
- (tmp = ((reg5xh & 0x30)>>4)) ? (tmp << 3) : 4,
- (tmp = (reg5yh & 0x03)) ? (tmp << 3) : 4,
- (tmp = ((reg5yh & 0x30)>>4)) ? (tmp << 3) : 4 );
+ int t1 = (tmp = (reg5xh & 0x03)) ? (tmp << 3) : 4;
+ int t2 = (tmp = ((reg5xh & 0x30)>>4)) ? (tmp << 3) : 4;
+ int t3 = (tmp = (reg5yh & 0x03)) ? (tmp << 3) : 4;
+ int t4 = (tmp = ((reg5yh & 0x30)>>4)) ? (tmp << 3) : 4;
+ p += sprintf(p, q, t1, t2, t3, t4);
}
#if 0
diff -x log.build -x .* -dru linux-2.4/drivers/ide/ide-disk.c
linux-2.4-fixed/drivers/ide/ide-disk.c
--- linux-2.4/drivers/ide/ide-disk.cTue Jun 20 15:52:36 2000
+++ linux-2.4-fixed/drivers/ide/ide-disk.c Mon Oct 16 14:48:49 2000
@@ -64,8 +64,8 @@
u16 *p = buffer;
while (wcount--) {
- *p++ = *p << 8 | *p >> 8;
- *p++ = *p << 8 | *p >> 8;
+ *p = *p << 8 | *p >> 8; p++;
+ *p = *p << 8 | *p >> 8; p++;
}
}
diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c
linux-2.4-fixed/drivers/isdn/sc/debug.c
--- linux-2.4/drivers/isdn/sc/debug.c Thu Apr 2 01:21:04 1998
+++ linux-2.4-fixed/drivers/isdn/sc/debug.c Mon Oct 16 14:53:49 2000
@@ -70,6 +70,6 @@
int i = 0;
while(dn[i] != ',')
- str[i] = dn[i++];
+ str[i] = dn[i], i++;
str[i] = 0x0;
}
diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
linux-2.4-fixed/drivers/net/tulip/tulip_core.c
--- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
+++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 15:40:12 2000
@@ -924,18 +924,20 @@
i++, mclist = mclist->next)
set_bit(ether_crc_le(ETH_ALEN, mclist->dmi_addr) &
0x1ff,
hash_table);
- for (i = 0; i < 32; i++)
- *setup_frm++ = *setup_frm++ = hash_table[i];
+ for (i = 0; i < 32; i++) {
+ *setup_frm++ = hash_table[i];
+ *setup_frm++ = hash_table[i];
+ }
setup_frm = >setup_frame[13*6];
} else {
/* We have <= 14 addresses so we can use the wonderful
16 address perfect filtering of the Tulip. */
for (i = 0, mclist = dev->mc_list; i < dev->mc_count;
i++, mclist = mclist->next) {
- eaddrs = (u16 *)mclist->dmi_addr;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
+ u16 *eaddrs = (u16 *)mclist->dmi_addr;
+ *setup_frm++ = eaddrs[0]; *setup_frm++ = eaddrs[0];
+ *setup_frm++ = eaddrs[1]; *setup_frm++ = eaddrs[1];
+ *setup_frm++ = eaddrs[2]; *setup_frm++ = eaddrs[2];
}
/* Fill the unused entries with the broadcast address. */
memset(setup_frm, 0xff, (15-i)*12);
@@ -944,9 +946,9 @@
/* Fill the final entry with our physical address. */
eaddrs = (u16 *)dev->dev_addr;
- *setup_frm++ = *setup_frm++ = eaddrs[0];
- *setup_frm++ = *setup_frm++ = eaddrs[1];
Patch to remove undefined C code
I've been playing with some gcc patches to detect code with undefined
behaviour of the i = i++ variety. The patch below fixes all places in
the kernel that I could find. Note that in some cases, it wasn't
entirely clear what the code intended, so I had to guess.
I haven't tested this patch at all other than to make sure it compiles.
Bernd
diff -x log.build -x .* -dru linux-2.4/drivers/i2o/i2o_core.c
linux-2.4-fixed/drivers/i2o/i2o_core.c
--- linux-2.4/drivers/i2o/i2o_core.cMon Jun 19 21:30:56 2000
+++ linux-2.4-fixed/drivers/i2o/i2o_core.c Mon Oct 16 14:52:46 2000
@@ -183,7 +183,7 @@
static int evt_in = 0;
static int evt_out = 0;
static int evt_q_len = 0;
-#define MODINC(x,y) (x = x++ % y)
+#define MODINC(x,y) ((x) = ((x) + 1) % (y))
/*
* I2O configuration spinlock. This isnt a big deal for contention
diff -x log.build -x .* -dru linux-2.4/drivers/ide/alim15x3.c
linux-2.4-fixed/drivers/ide/alim15x3.c
--- linux-2.4/drivers/ide/alim15x3.cTue Jun 20 15:52:36 2000
+++ linux-2.4-fixed/drivers/ide/alim15x3.c Mon Oct 16 15:10:24 2000
@@ -171,11 +171,11 @@
((reg5yh 0x30)4) + 12 );
}
} else {
- p += sprintf(p, q,
- (tmp = (reg5xh 0x03)) ? (tmp 3) : 4,
- (tmp = ((reg5xh 0x30)4)) ? (tmp 3) : 4,
- (tmp = (reg5yh 0x03)) ? (tmp 3) : 4,
- (tmp = ((reg5yh 0x30)4)) ? (tmp 3) : 4 );
+ int t1 = (tmp = (reg5xh 0x03)) ? (tmp 3) : 4;
+ int t2 = (tmp = ((reg5xh 0x30)4)) ? (tmp 3) : 4;
+ int t3 = (tmp = (reg5yh 0x03)) ? (tmp 3) : 4;
+ int t4 = (tmp = ((reg5yh 0x30)4)) ? (tmp 3) : 4;
+ p += sprintf(p, q, t1, t2, t3, t4);
}
#if 0
diff -x log.build -x .* -dru linux-2.4/drivers/ide/ide-disk.c
linux-2.4-fixed/drivers/ide/ide-disk.c
--- linux-2.4/drivers/ide/ide-disk.cTue Jun 20 15:52:36 2000
+++ linux-2.4-fixed/drivers/ide/ide-disk.c Mon Oct 16 14:48:49 2000
@@ -64,8 +64,8 @@
u16 *p = buffer;
while (wcount--) {
- *p++ = *p 8 | *p 8;
- *p++ = *p 8 | *p 8;
+ *p = *p 8 | *p 8; p++;
+ *p = *p 8 | *p 8; p++;
}
}
diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c
linux-2.4-fixed/drivers/isdn/sc/debug.c
--- linux-2.4/drivers/isdn/sc/debug.c Thu Apr 2 01:21:04 1998
+++ linux-2.4-fixed/drivers/isdn/sc/debug.c Mon Oct 16 14:53:49 2000
@@ -70,6 +70,6 @@
int i = 0;
while(dn[i] != ',')
- str[i] = dn[i++];
+ str[i] = dn[i], i++;
str[i] = 0x0;
}
diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
linux-2.4-fixed/drivers/net/tulip/tulip_core.c
--- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
+++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 15:40:12 2000
@@ -924,18 +924,20 @@
i++, mclist = mclist-next)
set_bit(ether_crc_le(ETH_ALEN, mclist-dmi_addr)
0x1ff,
hash_table);
- for (i = 0; i 32; i++)
- *setup_frm++ = *setup_frm++ = hash_table[i];
+ for (i = 0; i 32; i++) {
+ *setup_frm++ = hash_table[i];
+ *setup_frm++ = hash_table[i];
+ }
setup_frm = tp-setup_frame[13*6];
} else {
/* We have = 14 addresses so we can use the wonderful
16 address perfect filtering of the Tulip. */
for (i = 0, mclist = dev-mc_list; i dev-mc_count;
i++, mclist = mclist-next) {
- eaddrs = (u16 *)mclist-dmi_addr;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
- *setup_frm++ = *setup_frm++ = *eaddrs++;
+ u16 *eaddrs = (u16 *)mclist-dmi_addr;
+ *setup_frm++ = eaddrs[0]; *setup_frm++ = eaddrs[0];
+ *setup_frm++ = eaddrs[1]; *setup_frm++ = eaddrs[1];
+ *setup_frm++ = eaddrs[2]; *setup_frm++ = eaddrs[2];
}
/* Fill the unused entries with the broadcast address. */
memset(setup_frm, 0xff, (15-i)*12);
@@ -944,9 +946,9 @@
/* Fill the final entry with our physical address. */
eaddrs = (u16 *)dev-dev_addr;
- *setup_frm++ = *setup_frm++ = eaddrs[0];
- *setup_frm++ = *setup_frm++ = eaddrs[1];
- *setup_frm++ = *setup_frm++ = eaddrs[2];
+
Re: Patch to remove undefined C code
On Mon, 16 Oct 2000, Jeff Garzik wrote: --- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000 +++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000 @@ -1280,7 +1280,8 @@ scsi_unregister(shpnt); registered_count--; release_region(shpnt-io_port, IO_RANGE); - aha152x_host[shpnt-irq - IRQ_MIN] = shpnt = 0; + aha152x_host[shpnt-irq - IRQ_MIN] = 0; + shpnt = 0; continue; } Why this change? aha152x_host[shpnt-irq - IRQ_MIN] = shpnt = 0; reference set Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
