Re: [PATCH 0/4] v6 Improve task->comm locking situation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 17, 2011 at 6:41 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>
> While this was brought up at the time, it was not considered
> problematic, as the comm writing was done in such a way that
> only null or incomplete comms could be read. However, recently
> folks have made it clear they want to see this issue resolved.

What folks?

I don't think a new lock (or any lock) is at all appropriate.

There's just no point. Just guarantee that the last byte is always
zero, and you're done.

If you just guarantee that, THERE IS NO RACE. The last byte never
changes. You may get odd half-way strings, but you've trivially
guaranteed that they are C NUL-terminated, with no locking, no memory
ordering, no nothing.

Anybody who asks for any locking is just being a silly git. Tell them
to man the f*ck up.

So I'm not going to apply anything like this for 2.6.39, but I'm also
not going to apply it for 40 or 41 or anything else.

I refuse to accept just stupid unnecessary crap.

                      Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]