Re: [patch] 2.4.4: mmap() fails for certain legal requests
Alan Cox writes: > And just how is he going to test it ? Considering he was just > asking if the concept was reasonable I think you are a little out > of order I can't test every platform when I have to make such changes. But it always serves to show the port maintainer "what" the change was. Yes, I am slightly out of order if the intent is just "does this idea look fine" (which it does btw, I can't find any problems with it). I apologize to Maciej, but I do deplore him to actually do the final bits for the other ports when he makes his final patch submission. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.4: mmap() fails for certain legal requests
On Tue, 8 May 2001, David S. Miller wrote:
> That's pretty arrogant that cut and pasting a few lines into some
> architecture specific files and reporting the updated patch is too
> much to ask.
I'm sorry if you find me arrogant -- that certainly was not my intent. I
did look at the files and changes are not as trivial as cut and paste.
> Perhaps reviewing your change is also, too much to ask. Perhaps
> we are too lazy and short on time to have a look at your change.
Well, I've been using similar changes since July. I may live with
patches forever and be fine. Still this is not the point with free
software. It would be malicious if I had a fix and I wouldn't share it.
Sooner or later someone would discover the problem again and would waste
time to track it down unnecessarily. And again, and again...
> I don't think it's asking a lot to provide a complete change.
It's not a lot, supposedly, but look at the case from my point of view.
It's a bugfix and not a new feature. I've invested a few hours in finding
the cause of a weird bug on a MIPS/Linux machine. I am providing a ready
solution that works for most architectures with the exception of a few
ones I'm not familiar with.
Well, it's great I have an opportunity to get better knowledge on these
architectures, but I cannot always afford it and I know there are people
who already have enough knowledge to be sure bits get written correctly
immediately. I never hesitate to do job myself in the areas I am familiar
with or when I have enough free time (and I do have, from time to time).
I don't have time currently, I am afraid (basically I am now stealing the
time I would otherwise spend sleeping for a task that was quite low on my
priority list) and I am sure someone familiar with the specific ports
would spend less time than I do. Finally I do consider my time equally
worth to anyone else's one, so why should I have to spend x units of time,
whilst some else would only spend x/2 or x/3 or whatever... Of course I
consider this rule working both ways.
> I'm sure the MIPS folks know all too well whats it's like when their
> port is crapped up because someone only made changes to x86 port
> portions. At least for me on after working on Sparc for some time,
> I'm adamant about providing complete changes so that this kind of
> grief is avoided for other port maintainers.
The port gets crapped from time to time, although Ralf is doing great job
to keep it fine, so it's more that specific MIPS hosts lag behind the rest
of the kernel. Still I consider it the specific maintainer's job to get
things synchronized. It just works better this way.
> In the time you used to compose your response to me, and now
> to read this email from me, you could have fixed up the patch
> perhaps 2 or 3 times. Just do it and get it over with ok?
I'm not so sure, I'm afraid, especially at this time of the day. Check
timestamps of mails if curious...
> Dziekuje.
Nie za ma co. ;-)
A patch follows. Architecture-specific changes are completely untested.
I hope I got things right, otherwise I'll consider my time wasted.
BTW, I've noticed the "if (flags & MAP_FIXED)" statements in
arch_get_unmapped_area() in arch/sparc*/kernel/sys_sparc.c are dead code
now, as get_unmapped_area() in mm/mmap.c never calls it if MAP_FIXED is
set in flags.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
diff -up --recursive --new-file linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c
linux-2.4.4/arch/ia64/kernel/sys_ia64.c
--- linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c Mon May 7 16:43:50 2001
+++ linux-2.4.4/arch/ia64/kernel/sys_ia64.c Tue May 8 23:25:49 2001
@@ -28,13 +28,22 @@ arch_get_unmapped_area (struct file *fil
if (len > RGN_MAP_LIMIT)
return -ENOMEM;
- if (!addr)
- addr = TASK_UNMAPPED_BASE;
+ if (addr) {
+ if (flags & MAP_SHARED)
+ addr = COLOR_ALIGN(addr);
+ else
+ addr = PAGE_ALIGN(addr);
+ vmm = find_vma(current->mm, addr);
+ if (TASK_SIZE - len >= addr &&
+ rgn_offset(addr) + len <= RGN_MAP_LIMIT) &&
+ (!vmm || addr + len <= vmm->vm_start))
+ return addr;
+ }
if (flags & MAP_SHARED)
- addr = COLOR_ALIGN(addr);
+ addr = COLOR_ALIGN(TASK_UNMAPPED_BASE);
else
- addr = PAGE_ALIGN(addr);
+ addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
/* At this point: (!vmm || addr < vmm->vm_end). */
diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c
linux-2.4.4/arch/sparc/kernel/sys_sparc.c
---
Re: [patch] 2.4.4: mmap() fails for certain legal requests
> > Thanks for your response, though -- maybe there is someone interested, > > after all. > > That's pretty arrogant that cut and pasting a few lines into some > architecture specific files and reporting the updated patch is too > much to ask. And just how is he going to test it ? Considering he was just asking if the concept was reasonable I think you are a little out of order - 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] 2.4.4: mmap() fails for certain legal requests
Czesc, Maciej W. Rozycki writes: > Yep, I know (ia64 and sparc*). But being lazy enough (and being short on > time) I won't do it until I know the idea of the change is accepted. I'm > sorry -- I sent previous versions of the patch twice since last Summer > with no response at all and doing bits no one is interested in is a waste > of time. > > Thanks for your response, though -- maybe there is someone interested, > after all. That's pretty arrogant that cut and pasting a few lines into some architecture specific files and reporting the updated patch is too much to ask. Perhaps reviewing your change is also, too much to ask. Perhaps we are too lazy and short on time to have a look at your change. I don't think it's asking a lot to provide a complete change. I'm sure the MIPS folks know all too well whats it's like when their port is crapped up because someone only made changes to x86 port portions. At least for me on after working on Sparc for some time, I'm adamant about providing complete changes so that this kind of grief is avoided for other port maintainers. In the time you used to compose your response to me, and now to read this email from me, you could have fixed up the patch perhaps 2 or 3 times. Just do it and get it over with ok? Dziekuje. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.4: mmap() fails for certain legal requests
On Tue, 8 May 2001, David S. Miller wrote: > There are several get_unmapped_area() implementations besides the > standard one (search for HAVE_ARCH_UNMAPPED_AREA). Please fix > them up too. Yep, I know (ia64 and sparc*). But being lazy enough (and being short on time) I won't do it until I know the idea of the change is accepted. I'm sorry -- I sent previous versions of the patch twice since last Summer with no response at all and doing bits no one is interested in is a waste of time. Thanks for your response, though -- maybe there is someone interested, after all. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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] 2.4.4: mmap() fails for certain legal requests
Alan Cox writes: And just how is he going to test it ? Considering he was just asking if the concept was reasonable I think you are a little out of order I can't test every platform when I have to make such changes. But it always serves to show the port maintainer what the change was. Yes, I am slightly out of order if the intent is just does this idea look fine (which it does btw, I can't find any problems with it). I apologize to Maciej, but I do deplore him to actually do the final bits for the other ports when he makes his final patch submission. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.4: mmap() fails for certain legal requests
On Tue, 8 May 2001, David S. Miller wrote:
That's pretty arrogant that cut and pasting a few lines into some
architecture specific files and reporting the updated patch is too
much to ask.
I'm sorry if you find me arrogant -- that certainly was not my intent. I
did look at the files and changes are not as trivial as cut and paste.
Perhaps reviewing your change is also, too much to ask. Perhaps
we are too lazy and short on time to have a look at your change.
Well, I've been using similar changes since July. I may live with
patches forever and be fine. Still this is not the point with free
software. It would be malicious if I had a fix and I wouldn't share it.
Sooner or later someone would discover the problem again and would waste
time to track it down unnecessarily. And again, and again...
I don't think it's asking a lot to provide a complete change.
It's not a lot, supposedly, but look at the case from my point of view.
It's a bugfix and not a new feature. I've invested a few hours in finding
the cause of a weird bug on a MIPS/Linux machine. I am providing a ready
solution that works for most architectures with the exception of a few
ones I'm not familiar with.
Well, it's great I have an opportunity to get better knowledge on these
architectures, but I cannot always afford it and I know there are people
who already have enough knowledge to be sure bits get written correctly
immediately. I never hesitate to do job myself in the areas I am familiar
with or when I have enough free time (and I do have, from time to time).
I don't have time currently, I am afraid (basically I am now stealing the
time I would otherwise spend sleeping for a task that was quite low on my
priority list) and I am sure someone familiar with the specific ports
would spend less time than I do. Finally I do consider my time equally
worth to anyone else's one, so why should I have to spend x units of time,
whilst some else would only spend x/2 or x/3 or whatever... Of course I
consider this rule working both ways.
I'm sure the MIPS folks know all too well whats it's like when their
port is crapped up because someone only made changes to x86 port
portions. At least for me on after working on Sparc for some time,
I'm adamant about providing complete changes so that this kind of
grief is avoided for other port maintainers.
The port gets crapped from time to time, although Ralf is doing great job
to keep it fine, so it's more that specific MIPS hosts lag behind the rest
of the kernel. Still I consider it the specific maintainer's job to get
things synchronized. It just works better this way.
In the time you used to compose your response to me, and now
to read this email from me, you could have fixed up the patch
perhaps 2 or 3 times. Just do it and get it over with ok?
I'm not so sure, I'm afraid, especially at this time of the day. Check
timestamps of mails if curious...
Dziekuje.
Nie za ma co. ;-)
A patch follows. Architecture-specific changes are completely untested.
I hope I got things right, otherwise I'll consider my time wasted.
BTW, I've noticed the if (flags MAP_FIXED) statements in
arch_get_unmapped_area() in arch/sparc*/kernel/sys_sparc.c are dead code
now, as get_unmapped_area() in mm/mmap.c never calls it if MAP_FIXED is
set in flags.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
diff -up --recursive --new-file linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c
linux-2.4.4/arch/ia64/kernel/sys_ia64.c
--- linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c Mon May 7 16:43:50 2001
+++ linux-2.4.4/arch/ia64/kernel/sys_ia64.c Tue May 8 23:25:49 2001
@@ -28,13 +28,22 @@ arch_get_unmapped_area (struct file *fil
if (len RGN_MAP_LIMIT)
return -ENOMEM;
- if (!addr)
- addr = TASK_UNMAPPED_BASE;
+ if (addr) {
+ if (flags MAP_SHARED)
+ addr = COLOR_ALIGN(addr);
+ else
+ addr = PAGE_ALIGN(addr);
+ vmm = find_vma(current-mm, addr);
+ if (TASK_SIZE - len = addr
+ rgn_offset(addr) + len = RGN_MAP_LIMIT)
+ (!vmm || addr + len = vmm-vm_start))
+ return addr;
+ }
if (flags MAP_SHARED)
- addr = COLOR_ALIGN(addr);
+ addr = COLOR_ALIGN(TASK_UNMAPPED_BASE);
else
- addr = PAGE_ALIGN(addr);
+ addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
for (vmm = find_vma(current-mm, addr); ; vmm = vmm-vm_next) {
/* At this point: (!vmm || addr vmm-vm_end). */
diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c
linux-2.4.4/arch/sparc/kernel/sys_sparc.c
---
Re: [patch] 2.4.4: mmap() fails for certain legal requests
On Tue, 8 May 2001, David S. Miller wrote: There are several get_unmapped_area() implementations besides the standard one (search for HAVE_ARCH_UNMAPPED_AREA). Please fix them up too. Yep, I know (ia64 and sparc*). But being lazy enough (and being short on time) I won't do it until I know the idea of the change is accepted. I'm sorry -- I sent previous versions of the patch twice since last Summer with no response at all and doing bits no one is interested in is a waste of time. Thanks for your response, though -- maybe there is someone interested, after all. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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] 2.4.4: mmap() fails for certain legal requests
Thanks for your response, though -- maybe there is someone interested, after all. That's pretty arrogant that cut and pasting a few lines into some architecture specific files and reporting the updated patch is too much to ask. And just how is he going to test it ? Considering he was just asking if the concept was reasonable I think you are a little out of order - 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] 2.4.4: mmap() fails for certain legal requests
Czesc, Maciej W. Rozycki writes: Yep, I know (ia64 and sparc*). But being lazy enough (and being short on time) I won't do it until I know the idea of the change is accepted. I'm sorry -- I sent previous versions of the patch twice since last Summer with no response at all and doing bits no one is interested in is a waste of time. Thanks for your response, though -- maybe there is someone interested, after all. That's pretty arrogant that cut and pasting a few lines into some architecture specific files and reporting the updated patch is too much to ask. Perhaps reviewing your change is also, too much to ask. Perhaps we are too lazy and short on time to have a look at your change. I don't think it's asking a lot to provide a complete change. I'm sure the MIPS folks know all too well whats it's like when their port is crapped up because someone only made changes to x86 port portions. At least for me on after working on Sparc for some time, I'm adamant about providing complete changes so that this kind of grief is avoided for other port maintainers. In the time you used to compose your response to me, and now to read this email from me, you could have fixed up the patch perhaps 2 or 3 times. Just do it and get it over with ok? Dziekuje. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
