Re: [PULL] modules-next

[Rusty Russell]

Rusty Russell  writes:
> Linus Torvalds  writes:
>> So this feels wrong to me, can you guys please explain:
...
>> I didn't actually pull the tree, I just reacted to the pull request itself.
...
> I can pull them out of modules-next if you'd prefer.

OK, removed that patch.  Here's the update pullreq:

The following changes since commit 3fc9d690936fb2e20e180710965ba2cc3a0881f8:

  Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block (2016-07-26 
15:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/modules-next-for-linus

for you to fetch changes up to 49aadcf1b6f4240751921dad52e86c760d70a5f1:

  extable.h: add stddef.h so "NULL" definition is not implicit (2016-08-04 
10:16:56 +0930)


Removed the MODULE_SIG_FORCE-means-no-MODULE_FORCE_LOAD patch.

Only interesting thing here is Jessica's patch to add ro_after_init support
to modules.  The rest are all trivia.

Cheers,
Rusty.


Ben Hutchings (2):
  module: Invalidate signatures on force-loaded modules
  Documentation/module-signing.txt: Note need for version info if reusing a 
key

Jessica Yu (1):
  modules: add ro_after_init support

Jiri Kosina (1):
  module: fix noreturn attribute for __module_put_and_exit()

Libor Pechacek (1):
  module: Issue warnings when tainting kernel

Paul Gortmaker (2):
  exceptions: fork exception table content from module.h into extable.h
  extable.h: add stddef.h so "NULL" definition is not implicit

Prarit Bhargava (1):
  modules: Add kernel parameter to blacklist modules

Rusty Russell (2):
  module: fix redundant test.
  jump_label: disable preemption around __module_text_address().

Steven Rostedt (1):
  module: Do a WARN_ON_ONCE() for assert module mutex not held

 Documentation/kernel-parameters.txt |   3 +
 Documentation/module-signing.txt|   6 ++
 include/linux/extable.h |  32 ++
 include/linux/module.h  |  37 +++
 include/uapi/linux/elf.h|   1 +
 kernel/jump_label.c |   5 +-
 kernel/livepatch/core.c |   2 +-
 kernel/module.c | 121 +---
 8 files changed, 155 insertions(+), 52 deletions(-)
 create mode 100644 include/linux/extable.h

Re: [PULL] modules-next

[Rusty Russell]

Rusty Russell  writes:
> Linus Torvalds  writes:
>> So this feels wrong to me, can you guys please explain:
...
>> I didn't actually pull the tree, I just reacted to the pull request itself.
...
> I can pull them out of modules-next if you'd prefer.

OK, removed that patch.  Here's the update pullreq:

The following changes since commit 3fc9d690936fb2e20e180710965ba2cc3a0881f8:

  Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block (2016-07-26 
15:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/modules-next-for-linus

for you to fetch changes up to 49aadcf1b6f4240751921dad52e86c760d70a5f1:

  extable.h: add stddef.h so "NULL" definition is not implicit (2016-08-04 
10:16:56 +0930)


Removed the MODULE_SIG_FORCE-means-no-MODULE_FORCE_LOAD patch.

Only interesting thing here is Jessica's patch to add ro_after_init support
to modules.  The rest are all trivia.

Cheers,
Rusty.


Ben Hutchings (2):
  module: Invalidate signatures on force-loaded modules
  Documentation/module-signing.txt: Note need for version info if reusing a 
key

Jessica Yu (1):
  modules: add ro_after_init support

Jiri Kosina (1):
  module: fix noreturn attribute for __module_put_and_exit()

Libor Pechacek (1):
  module: Issue warnings when tainting kernel

Paul Gortmaker (2):
  exceptions: fork exception table content from module.h into extable.h
  extable.h: add stddef.h so "NULL" definition is not implicit

Prarit Bhargava (1):
  modules: Add kernel parameter to blacklist modules

Rusty Russell (2):
  module: fix redundant test.
  jump_label: disable preemption around __module_text_address().

Steven Rostedt (1):
  module: Do a WARN_ON_ONCE() for assert module mutex not held

 Documentation/kernel-parameters.txt |   3 +
 Documentation/module-signing.txt|   6 ++
 include/linux/extable.h |  32 ++
 include/linux/module.h  |  37 +++
 include/uapi/linux/elf.h|   1 +
 kernel/jump_label.c |   5 +-
 kernel/livepatch/core.c |   2 +-
 kernel/module.c | 121 +---
 8 files changed, 155 insertions(+), 52 deletions(-)
 create mode 100644 include/linux/extable.h

Re: [PULL] modules-next

[Rusty Russell]

Linus Torvalds  writes:
> So this feels wrong to me, can you guys please explain:
>
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
>>
>> Ben Hutchings (3):
>>   module: Invalidate signatures on force-loaded modules
>>   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
>
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).
>
> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.
>
> I didn't actually pull the tree, I just reacted to the pull request itself.

Well, MODULE_FORCE_LOAD is really "I am a doing crazy shit", and
MODULE_SIG_FORCE is "Don't let me do crazy shit".

You have to contrive pretty hard to get a situation where the
combination makes sense, so I tend to let Ben worry about the module
signing stuff.

I can pull them out of modules-next if you'd prefer.

Cheers,
Rusty.

Re: [PULL] modules-next

[Rusty Russell]

Linus Torvalds  writes:
> So this feels wrong to me, can you guys please explain:
>
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
>>
>> Ben Hutchings (3):
>>   module: Invalidate signatures on force-loaded modules
>>   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
>
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).
>
> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.
>
> I didn't actually pull the tree, I just reacted to the pull request itself.

Well, MODULE_FORCE_LOAD is really "I am a doing crazy shit", and
MODULE_SIG_FORCE is "Don't let me do crazy shit".

You have to contrive pretty hard to get a situation where the
combination makes sense, so I tend to let Ben worry about the module
signing stuff.

I can pull them out of modules-next if you'd prefer.

Cheers,
Rusty.

Re: [PULL] modules-next

[Ben Hutchings]

On Sun, 2016-07-31 at 21:44 -0400, Linus Torvalds wrote:
> So this feels wrong to me, can you guys please explain:
> 
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
> > 
> > Ben Hutchings (3):
> >   module: Invalidate signatures on force-loaded modules
> >   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
> 
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).

We discussed this before and I thought you were happy with this
version.  If the use case you describe is at all common, it could
perhaps be handled by having a tool that patches the version
information and re-signs the module with a different trusted key.

> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.

As I understand it:
- module signature enforcement means that root is not trusted to load
  arbitrary code into the kernel; instead the code has to be approved
  by one of the signing key holders
- force-loading a module means "I promise that this module is ABI
  compatible, even though it doesn't appear to be"

No-one signs that promise, and if it's false, the ABI differences could
mean that an otherwise benign module would compromise the kernel.  So
as I see it, the kernel should not trust a force-loaded signed module
any more than an unsigned module.

If you still think that module signature enforcement is compatible with
force-loading, I would like to know what you consider the purpose of
enforcement to be.

Ben.

> I didn't actually pull the tree, I just reacted to the pull request itself.
> 
>  Linus
-- 

Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

Re: [PULL] modules-next

[Ben Hutchings]

On Sun, 2016-07-31 at 21:44 -0400, Linus Torvalds wrote:
> So this feels wrong to me, can you guys please explain:
> 
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
> > 
> > Ben Hutchings (3):
> >   module: Invalidate signatures on force-loaded modules
> >   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
> 
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).

We discussed this before and I thought you were happy with this
version.  If the use case you describe is at all common, it could
perhaps be handled by having a tool that patches the version
information and re-signs the module with a different trusted key.

> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.

As I understand it:
- module signature enforcement means that root is not trusted to load
  arbitrary code into the kernel; instead the code has to be approved
  by one of the signing key holders
- force-loading a module means "I promise that this module is ABI
  compatible, even though it doesn't appear to be"

No-one signs that promise, and if it's false, the ABI differences could
mean that an otherwise benign module would compromise the kernel.  So
as I see it, the kernel should not trust a force-loaded signed module
any more than an unsigned module.

If you still think that module signature enforcement is compatible with
force-loading, I would like to know what you consider the purpose of
enforcement to be.

Ben.

> I didn't actually pull the tree, I just reacted to the pull request itself.
> 
>  Linus
-- 

Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

Re: [PULL] modules-next

[Linus Torvalds]

So this feels wrong to me, can you guys please explain:

On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
>
> Ben Hutchings (3):
>   module: Invalidate signatures on force-loaded modules
>   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled

forcing a load and SIG_FORCE are entirely independent issues, afaik. I
think requiring signed modules is just a good idea. But that doesn't
necessarily mean that you don't have a signed module that is signed
with a key you trust, but you still want to force-load it for the
wrong kernel version (ie maybe you have a binary-only module from your
IT department (and your IT department is evil,but at least they sign
it to show that the module is trust-worthy as coming from them, even
if they have some dubious behavior), but you did some kernel updates
that still allow the module to work but the version doesn't match any
more).

Am I missing something? What's the connection between
MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
are independent and that the above changes are very very dubious.

I didn't actually pull the tree, I just reacted to the pull request itself.

 Linus

Re: [PULL] modules-next

[Linus Torvalds]

So this feels wrong to me, can you guys please explain:

On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell  wrote:
>
> Ben Hutchings (3):
>   module: Invalidate signatures on force-loaded modules
>   module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled

forcing a load and SIG_FORCE are entirely independent issues, afaik. I
think requiring signed modules is just a good idea. But that doesn't
necessarily mean that you don't have a signed module that is signed
with a key you trust, but you still want to force-load it for the
wrong kernel version (ie maybe you have a binary-only module from your
IT department (and your IT department is evil,but at least they sign
it to show that the module is trust-worthy as coming from them, even
if they have some dubious behavior), but you did some kernel updates
that still allow the module to work but the version doesn't match any
more).

Am I missing something? What's the connection between
MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
are independent and that the above changes are very very dubious.

I didn't actually pull the tree, I just reacted to the pull request itself.

 Linus

Re: [PULL] modules-next

[Rusty Russell]

Linus Torvalds  writes:
> On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell  wrote:
>>
>> The exciting thing here is the getting rid of stop_machine on module
>> removal.  This is possible by using a simple atomic_t for the counter,
>> rather than our fancy per-cpu counter: it turns out that no one is doing
>> a module increment per net packet, so the slowdown should be in the noise.
>
> Famous last words. It may not happen per-packet, but I see
> module_get() in various block drivers and in netfilter code etc, and
> some of them may be pretty bad.
>
> Let's see how it all works out.

Indeed.  The general pattern is "get on open/init"; get-on-every-use was
most useful combined with blocking rmmod, which we removed a few kernels
ago (because no one used it).

I did a random audit until I got bored, and I put a printk-on-module-get
in my kernels for a while, and none of my usecases flood my logs.  But
it's definitely a risk...

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Rusty Russell]

Linus Torvalds torva...@linux-foundation.org writes:
 On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell ru...@rustcorp.com.au wrote:

 The exciting thing here is the getting rid of stop_machine on module
 removal.  This is possible by using a simple atomic_t for the counter,
 rather than our fancy per-cpu counter: it turns out that no one is doing
 a module increment per net packet, so the slowdown should be in the noise.

 Famous last words. It may not happen per-packet, but I see
 module_get() in various block drivers and in netfilter code etc, and
 some of them may be pretty bad.

 Let's see how it all works out.

Indeed.  The general pattern is get on open/init; get-on-every-use was
most useful combined with blocking rmmod, which we removed a few kernels
ago (because no one used it).

I did a random audit until I got bored, and I put a printk-on-module-get
in my kernels for a while, and none of my usecases flood my logs.  But
it's definitely a risk...

Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Linus Torvalds]

On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell  wrote:
>
> The exciting thing here is the getting rid of stop_machine on module
> removal.  This is possible by using a simple atomic_t for the counter,
> rather than our fancy per-cpu counter: it turns out that no one is doing
> a module increment per net packet, so the slowdown should be in the noise.

Famous last words. It may not happen per-packet, but I see
module_get() in various block drivers and in netfilter code etc, and
some of them may be pretty bad.

Let's see how it all works out.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Linus Torvalds]

On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell ru...@rustcorp.com.au wrote:

 The exciting thing here is the getting rid of stop_machine on module
 removal.  This is possible by using a simple atomic_t for the counter,
 rather than our fancy per-cpu counter: it turns out that no one is doing
 a module increment per net packet, so the slowdown should be in the noise.

Famous last words. It may not happen per-packet, but I see
module_get() in various block drivers and in netfilter code etc, and
some of them may be pretty bad.

Let's see how it all works out.

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Geert Uytterhoeven]

Hi Mark,

On Fri, Jun 13, 2014 at 11:24 AM, Mark Brown  wrote:
> On Fri, Jun 13, 2014 at 10:33:20AM +0930, Rusty Russell wrote:
>> So, did you queue a patch to fix your email address in
>> drivers/regulator/virtual.c?
>
> No, that's more about giving credit to Wolfson for funding the code I
> guess - it's very rare for anyone to update the author information (and
> becoming more common for people to not put them in the file at all).
> Everyone uses get_maintainers.pl these days, it'll do a reasonable first
> pass at figuring out who's been working on the code and who the
> subsystem maintainers are.

Still, obsolete email address are regularly updated or removed.
You can give credits in the comments. The file already has

Copyright 2008 Wolfson Microelectronics PLC.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Mark Brown]

On Fri, Jun 13, 2014 at 10:33:20AM +0930, Rusty Russell wrote:

> So, did you queue a patch to fix your email address in
> drivers/regulator/virtual.c?

No, that's more about giving credit to Wolfson for funding the code I
guess - it's very rare for anyone to update the author information (and
becoming more common for people to not put them in the file at all).
Everyone uses get_maintainers.pl these days, it'll do a reasonable first
pass at figuring out who's been working on the code and who the
subsystem maintainers are.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Mark Brown]

On Fri, Jun 13, 2014 at 10:33:20AM +0930, Rusty Russell wrote:

 So, did you queue a patch to fix your email address in
 drivers/regulator/virtual.c?

No, that's more about giving credit to Wolfson for funding the code I
guess - it's very rare for anyone to update the author information (and
becoming more common for people to not put them in the file at all).
Everyone uses get_maintainers.pl these days, it'll do a reasonable first
pass at figuring out who's been working on the code and who the
subsystem maintainers are.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Geert Uytterhoeven]

Hi Mark,

On Fri, Jun 13, 2014 at 11:24 AM, Mark Brown broo...@kernel.org wrote:
 On Fri, Jun 13, 2014 at 10:33:20AM +0930, Rusty Russell wrote:
 So, did you queue a patch to fix your email address in
 drivers/regulator/virtual.c?

 No, that's more about giving credit to Wolfson for funding the code I
 guess - it's very rare for anyone to update the author information (and
 becoming more common for people to not put them in the file at all).
 Everyone uses get_maintainers.pl these days, it'll do a reasonable first
 pass at figuring out who's been working on the code and who the
 subsystem maintainers are.

Still, obsolete email address are regularly updated or removed.
You can give credits in the comments. The file already has

Copyright 2008 Wolfson Microelectronics PLC.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Rusty Russell]

Mark Brown  writes:
> On Thu, Jun 12, 2014 at 10:55:00AM +0930, Rusty Russell wrote:
>> Mark Brown  writes:
>
>> > if you need to respin - please do send patches to maintainers.
>
>> If the address in drivers/regulator/virtual.c is incorrect, please
>> update it:
>
>>  Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
>> files.
>>  To: linux-kernel@vger.kernel.org
>>  Cc: Rusty Russell , Mark Brown 
>> 
>>  Date: Tue, 22 Apr 2014 13:03:28 +0930

> The main people to hit are subsystem maintainers - driver authors have
> often vanished or don't really respond to upstream e-mail, though of
> course they should also be included.

Fair enough.  There's a limited amount of effort I go to in a sweep like
this, unless I'm really worried about a particular patch.  lkml (used to
have?) a limit on how many people you could CC so I tend to trim.

So, did you queue a patch to fix your email address in
drivers/regulator/virtual.c?

Thanks.
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Mark Brown]

On Thu, Jun 12, 2014 at 10:55:00AM +0930, Rusty Russell wrote:
> Mark Brown  writes:

> > if you need to respin - please do send patches to maintainers.

> If the address in drivers/regulator/virtual.c is incorrect, please
> update it:

>  Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
> files.
>  To: linux-kernel@vger.kernel.org
>  Cc: Rusty Russell , Mark Brown 
> 
>  Date: Tue, 22 Apr 2014 13:03:28 +0930

The main people to hit are subsystem maintainers - driver authors have
often vanished or don't really respond to upstream e-mail, though of
course they should also be included.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Mark Brown]

On Thu, Jun 12, 2014 at 10:55:00AM +0930, Rusty Russell wrote:
 Mark Brown broo...@kernel.org writes:

  if you need to respin - please do send patches to maintainers.

 If the address in drivers/regulator/virtual.c is incorrect, please
 update it:

  Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
 files.
  To: linux-kernel@vger.kernel.org
  Cc: Rusty Russell ru...@rustcorp.com.au, Mark Brown 
 broo...@opensource.wolfsonmicro.com
  Date: Tue, 22 Apr 2014 13:03:28 +0930

The main people to hit are subsystem maintainers - driver authors have
often vanished or don't really respond to upstream e-mail, though of
course they should also be included.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Rusty Russell]

Mark Brown broo...@kernel.org writes:
 On Thu, Jun 12, 2014 at 10:55:00AM +0930, Rusty Russell wrote:
 Mark Brown broo...@kernel.org writes:

  if you need to respin - please do send patches to maintainers.

 If the address in drivers/regulator/virtual.c is incorrect, please
 update it:

  Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
 files.
  To: linux-kernel@vger.kernel.org
  Cc: Rusty Russell ru...@rustcorp.com.au, Mark Brown 
 broo...@opensource.wolfsonmicro.com
  Date: Tue, 22 Apr 2014 13:03:28 +0930

 The main people to hit are subsystem maintainers - driver authors have
 often vanished or don't really respond to upstream e-mail, though of
 course they should also be included.

Fair enough.  There's a limited amount of effort I go to in a sweep like
this, unless I'm really worried about a particular patch.  lkml (used to
have?) a limit on how many people you could CC so I tend to trim.

So, did you queue a patch to fix your email address in
drivers/regulator/virtual.c?

Thanks.
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Rusty Russell]

Mark Brown  writes:
> On Wed, Jun 11, 2014 at 03:03:47PM +0930, Rusty Russell wrote:
>
>>   drivers/regulator/virtual: avoid world-writable sysfs files.
>
> Acked-by: Mark Brown 
>
> if you need to respin - please do send patches to maintainers.

If the address in drivers/regulator/virtual.c is incorrect, please
update it:

 Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
files.
 To: linux-kernel@vger.kernel.org
 Cc: Rusty Russell , Mark Brown 

 Date: Tue, 22 Apr 2014 13:03:28 +0930

 In line with practice for module parameters, we're adding a build-time
 check that sysfs files aren't world-writable.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] modules-next

[Mark Brown]

On Wed, Jun 11, 2014 at 03:03:47PM +0930, Rusty Russell wrote:

>   drivers/regulator/virtual: avoid world-writable sysfs files.

Acked-by: Mark Brown 

if you need to respin - please do send patches to maintainers.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Mark Brown]

On Wed, Jun 11, 2014 at 03:03:47PM +0930, Rusty Russell wrote:

   drivers/regulator/virtual: avoid world-writable sysfs files.

Acked-by: Mark Brown broo...@linaro.org

if you need to respin - please do send patches to maintainers.


signature.asc
Description: Digital signature

Re: [PULL] modules-next

[Rusty Russell]

Mark Brown broo...@kernel.org writes:
 On Wed, Jun 11, 2014 at 03:03:47PM +0930, Rusty Russell wrote:

   drivers/regulator/virtual: avoid world-writable sysfs files.

 Acked-by: Mark Brown broo...@linaro.org

 if you need to respin - please do send patches to maintainers.

If the address in drivers/regulator/virtual.c is incorrect, please
update it:

 Subject: [PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs 
files.
 To: linux-kernel@vger.kernel.org
 Cc: Rusty Russell ru...@rustcorp.com.au, Mark Brown 
broo...@opensource.wolfsonmicro.com
 Date: Tue, 22 Apr 2014 13:03:28 +0930

 In line with practice for module parameters, we're adding a build-time
 check that sysfs files aren't world-writable.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/