twitter: linux.kernel - 26 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Drop 80-character limit in checkpatch.pl - 6 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
* [RESEND] mm: Pass mm->flags as a coredump parameter for consistency - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/bbd6bd5c881a2306?hl=en
* s390 patches for 2.6.33-rc1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2fbdcb00e53d77d9?hl=en
* kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to 'rcu_
bootup_announce': function body not available - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/61416b53d6226fba?hl=en
* -tip: origin tree boot crash - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/2151dddd03ec78e5?hl=en
* [RFC][PATCH 0/11] mm accessor updates. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/cdcb6aebedcd9a6d?hl=en
* kmod: Fix resource leak in call_usermodehelper_pipe() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8f6341c4fe4cad9b?hl=en
* RFC: A proposal for power capping through forced idle in the Linux Kernel -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c7be9846260e0dd7?hl=en
* Driver core: Encourage use of const attributes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c6ac52dbf1bcc443?hl=en
* 2.6.31 -> 2.6.32 Sound and video regressions - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c29f86929a2f467e?hl=en
* anonfd: Make file read-only if fops->write is not set - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/73bcf73ccb2e0116?hl=en
* Kernel built for i586 chip crashes instantly at boot time (CMOV instructions)
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3a182b551e4de0e2?hl=en
* spinlock which can morph into a mutex - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ae771761b513bb03?hl=en
* Staging: vt665x depend on WIRELESS - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/346e4337e96055ec?hl=en
* intelligent CLS kills qemu's 8139cp - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/876a2b3a1ee38571?hl=en
* Security: Add prctl(PR_{GET,SET}_NETWORK) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a960a1b4696443c0?hl=en
* Async suspend-resume patch w/ completions (was: Re: Async suspend-resume
patch w/ rwsems) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en

==============================================================================
TOPIC: Drop 80-character limit in checkpatch.pl
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
==============================================================================

== 1 of 6 ==
Date: Fri, Dec 18 2009 8:50 am
From: Mikulas Patocka

> Note: I'm not specifically arguing for keeping the 80-column rule, the
> project I work on uses 100 columns, and that's quite workable, but I
> haven't had any problem working with 80 columns as a limit either. I
> do however think that just removing the limit without replacing it
> with something better is a bad idea.
>
> -Kevin Granade

But think what happens when someone views that 100-char code on 80-char
terminal (or for example 94-char, that I used for some times too) ---
every second line will be wasted with just 20 characters on the left. On
the other hand, if you have unlimited line length, it will look better on
80-char terminal.

Mikulas
--
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/

== 2 of 6 ==
Date: Fri, Dec 18 2009 9:00 am
From: Linus Torvalds

On Fri, 18 Dec 2009, Mikulas Patocka wrote:
>
> But think what happens when someone views that 100-char code on 80-char
> terminal (or for example 94-char, that I used for some times too) ---
> every second line will be wasted with just 20 characters on the left.

What kind of CRAZY crap argument is that?

The current rule is 80 characters - but how many lines are actually even
close to 80 characters long? Very few.

So that "every second line" statement is pure and utter idiocy. Instead,
what you get is totally the reverse: instead of wasting two lines _anyway_
due to a hard-newline, you often get a single line instead (since most of
us don't work in 24x80 windows to begin with).

Linus
--
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/

== 3 of 6 ==
Date: Fri, Dec 18 2009 9:00 am
From: Randy Dunlap

On Fri, 18 Dec 2009 15:12:41 +0000 Alasdair G Kergon wrote:

> On Fri, Dec 18, 2009 at 03:37:00PM +0100, Krzysztof Halasa wrote:
> > Not sure if that's long enough (maybe it is).
> > 132 looks like the next "natural" number.
>
> Well it's good that this thread has produced more examples where it's
> reasonable and acceptable to exceed 80 characters.
>
> What do people feel about files where the policy is to place all the
> parameters passed into a function on the same line, regardless of its
> consequent length?

Not good IMO. It's much easier to read something that is restricted in
width than to have to scroll/pan side to side.
(e.g., newspaper columns. Oops, what's a newspaper?)

> (What kicked this all off was a patch Mikulas submitted containing many
> long lines, one of which hits column 264. Personally, I dislike reading
> code with lines that wrap, but using a 132-column terminal width is
> fine.)

---
~Randy
--
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/

== 4 of 6 ==
Date: Fri, Dec 18 2009 9:20 am
From: Mikulas Patocka

On Fri, 18 Dec 2009, Linus Torvalds wrote:

> On Fri, 18 Dec 2009, Mikulas Patocka wrote:
> >
> > But think what happens when someone views that 100-char code on 80-char
> > terminal (or for example 94-char, that I used for some times too) ---
> > every second line will be wasted with just 20 characters on the left.
>
> What kind of CRAZY crap argument is that?
>
> The current rule is 80 characters - but how many lines are actually even
> close to 80 characters long? Very few.
>
> So that "every second line" statement is pure and utter idiocy. Instead,
> what you get is totally the reverse: instead of wasting two lines _anyway_
> due to a hard-newline, you often get a single line instead (since most of
> us don't work in 24x80 windows to begin with).
>
> Linus

Function declarations are often larger than 80 characters. And if you wrap
them at 100, you are wasting every second line on 80-character display.

If you make line length unlimited, the space will be used optimally on all
displays --- a function with 200 character declaration will use 3 lines on
80-character display and 2 lines on 100-character display.

And besides --- wrapping at 100 doesn't fix the initial problem (why I
posted this thread) --- that making any modification to the function
header or long expression requires the user to manually realign the
arguments.

== 5 of 6 ==
Date: Fri, Dec 18 2009 9:20 am
From: Mikulas Patocka

On Fri, 18 Dec 2009, Randy Dunlap wrote:

> On Fri, 18 Dec 2009 15:12:41 +0000 Alasdair G Kergon wrote:
>
> > On Fri, Dec 18, 2009 at 03:37:00PM +0100, Krzysztof Halasa wrote:
> > > Not sure if that's long enough (maybe it is).
> > > 132 looks like the next "natural" number.
> >
> > Well it's good that this thread has produced more examples where it's
> > reasonable and acceptable to exceed 80 characters.
> >
> > What do people feel about files where the policy is to place all the
> > parameters passed into a function on the same line, regardless of its
> > consequent length?
>
> Not good IMO. It's much easier to read something that is restricted in
> width than to have to scroll/pan side to side.
> (e.g., newspaper columns. Oops, what's a newspaper?)

I don't like scrolling too but most viewers and editors wrap it
automatically to screen width. For example, restrict your terminal to 50
columnts and try using "less".

== 6 of 6 ==
Date: Fri, Dec 18 2009 9:30 am
From: Linus Torvalds

On Fri, 18 Dec 2009, Mikulas Patocka wrote:
>
> Function declarations are often larger than 80 characters. And if you wrap
> them at 100, you are wasting every second line on 80-character display.

If you care so much, use a non-wrapping editor. That's what I do.

> If you make line length unlimited, the space will be used optimally on all
> displays --- a function with 200 character declaration will use 3 lines on
> 80-character display and 2 lines on 100-character display.

Yeah, and that's just crazy.

We all use good hardware these days, but we certainly don't have unlimited
line length. And wrapping is ugly. So sane people (definition: "me") use
editors that don't wrap (marking long lines at the end instead), and for
the very rare case when I use a small terminal, I'll need to go look if I
care (which is seldom).

> And besides --- wrapping at 100 doesn't fix the initial problem (why I
> posted this thread) --- that making any modification to the function
> header or long expression requires the user to manually realign the
> arguments.

Sure. Nothing fixes the problem that you need to _occasionally_ wrap.

But the real problem is that crazy people consider checkpatch.pl to be so
important that they wrap whether it makes sense or not.

Sense. It's what some people have. Too rare, though.

I'll happily remove the checkpatch.pl limit entirely, and ask people to
try to use common sense, though.

==============================================================================
TOPIC: [RESEND] mm: Pass mm->flags as a coredump parameter for consistency
http://groups.google.com/group/linux.kernel/t/bbd6bd5c881a2306?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 8:50 am
From: Masami Hiramatsu

Pass mm->flags as a coredump parameter for consistency.

---
1787 if (mm->core_state || !get_dumpable(mm)) { <- (1)
1788 up_write(&mm->mmap_sem);
1789 put_cred(cred);
1790 goto fail;
1791 }
1792
[...]
1798 if (get_dumpable(mm) == 2) { /* Setuid core dump mode */ <-(2)
1799 flag = O_EXCL; /* Stop rewrite attacks */
1800 cred->fsuid = 0; /* Dump root private */
1801 }
---

Since dumpable bits are not protected by lock, there is a
chance to change these bits between (1) and (2).

To solve this issue, this patch copies mm->flags to
coredump_params.mm_flags at the beginning of do_coredump() and uses it instead of get_dumpable() while dumping core.

This copy is also passed to binfmt->core_dump, since
elf*_core_dump() uses dump_filter bits in mm->flags.

Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---

fs/binfmt_elf.c | 12 ++----------
fs/binfmt_elf_fdpic.c | 12 ++----------
fs/exec.c | 20 ++++++++++++++++----
include/linux/binfmts.h | 1 +
4 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index edd90c4..3ebb534 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1911,7 +1911,6 @@ static int elf_core_dump(struct coredump_params *cprm)
struct vm_area_struct *vma, *gate_vma;
struct elfhdr *elf = NULL;
loff_t offset = 0, dataoff, foffset;
- unsigned long mm_flags;
struct elf_note_info info;

/*
@@ -1976,13 +1975,6 @@ static int elf_core_dump(struct coredump_params *cprm)

dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);

- /*
- * We must use the same mm->flags while dumping core to avoid
- * inconsistency between the program headers and bodies, otherwise an
- * unusable core file can be generated.
- */
- mm_flags = current->mm->flags;
-
/* Write program headers for segments dump */
for (vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
@@ -1992,7 +1984,7 @@ static int elf_core_dump(struct coredump_params *cprm)
phdr.p_offset = offset;
phdr.p_vaddr = vma->vm_start;
phdr.p_paddr = 0;
- phdr.p_filesz = vma_dump_size(vma, mm_flags);
+ phdr.p_filesz = vma_dump_size(vma, cprm->mm_flags);
phdr.p_memsz = vma->vm_end - vma->vm_start;
offset += phdr.p_filesz;
phdr.p_flags = vma->vm_flags & VM_READ ? PF_R : 0;
@@ -2025,7 +2017,7 @@ static int elf_core_dump(struct coredump_params *cprm)
unsigned long addr;
unsigned long end;

- end = vma->vm_start + vma_dump_size(vma, mm_flags);
+ end = vma->vm_start + vma_dump_size(vma, cprm->mm_flags);

for (addr = vma->vm_start; addr < end; addr += PAGE_SIZE) {
struct page *page;
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index c25256a..aadd7a3 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1606,7 +1606,6 @@ static int elf_fdpic_core_dump(struct coredump_params *cprm)

twitter

Friday, December 18, 2009

linux.kernel - 26 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts