Messages in this thread | | | Date | Mon, 12 Jan 2004 14:39:43 -0800 | From | "Randy.Dunlap" <> | Subject | Re: [PATCH(s)][RFC] variable size and signedness issues in ldt.c - potential problem? |
| |
On Mon, 12 Jan 2004 23:20:23 +0100 (CET) Jesper Juhl <juhl-lkml@dif.dk> wrote:
| | On Mon, 12 Jan 2004, Andrew Morton wrote: | | > Jesper Juhl <juhl-lkml@dif.dk> wrote: | > > | > > | > > > | > > > -static int read_ldt(void __user * ptr, unsigned long bytecount) | > > > +static int read_ldt(void __user *ptr, unsigned long bytecount) | > > > { | > > > int err, i; | > > > unsigned long size; | > > > + unsigned long bytes; | > > > struct mm_struct * mm = current->mm; | > > > | > > > if (!mm->context.size) | > > > @@ -144,7 +145,7 @@ static int read_ldt(void __user * ptr, u | > > > __flush_tlb_global(); | > > > | > > > for (i = 0; i < size; i += PAGE_SIZE) { | > > > - int nr = i / PAGE_SIZE, bytes; | > > > + int nr = i / PAGE_SIZE; | > > > char *kaddr = kmap(mm->context.ldt_pages[nr]); | > > > | > > > bytes = size - i; | > > > | > | > There is no additional overhead with the original code and it has the | > advantage that the scope of `bytes' covers the minimum amount of code. I | > see no need to change this. | > | > Well. There is a little bit of overhead of the code does: | > | > foo() | > { | > ... | > { | > int i; | > ... | > } | > ... | > { | > int i; | > ... | > } | > ... | > } | > | > because the compiler (some versions, at least) will use eight bytes of | > stack rather than four. But this is rarely a problem. | > | | Ok, I'll let it go :-) | | | > > After creating the initial cleanup patch I've noticed several more | > > instances of this 'bad style'. If there's any interrest in cleaning them | > > up I'll be happy to create a patch. Is this wanted? | > | > I'd say that this and the whitespace adjustments are far too trivial to be | > raising patches at this time. | > | You are right, it /is/ trivial - I'll leave it alone for now. Maybe later | create a patch that does a more thorough cleanup and send it to the | trivial patch monkey. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Or I can put it into the KJ patchset and just never send it onward. That will at least get it some usage time.
BTW, if you want to stick with trivial_Rusty, that's OK with me too. Rusty does a fine job and I'm not trying to compete with him.
-- ~Randy http://janitor.kernelnewbies.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |