[PATCH v2 00/11] w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi,

This is my first series of patches for the Linux kernel.
I started by familiarizing myself with coding style and
satisfying my inner OCD by cleaning the 1-wire subsystem.

Cheers,
Steffen

---

Changes since v1:
  - addressed comments from Joe Perches:
  - re-ran checkpatch.pl in --strict mode
  - fixed commit messages to reflect more precisly
the checkpatch warnings

Steffen Vogel (12):
  w1: add SPDX identifiers
  w1: improve code-style by adhering tp 80 columns per line limit
  w1: add newlines after declarations
  w1: cleanup whitespaces according to coding style document
  w1: use octal numbers instead of macros for file mode
  w1: do not log errors about failed memory allocations
  w1: use __func__ for logging the function name
  w1: improve code-style of struct declarations
  w1: using linux instead of asm prefix for includes
  w1: use pointers instead of types to determine size of allocs
  w1: replace non-standard %LX format-string by %llX
  w1: fix typo in comment

 drivers/w1/masters/ds1wm.c |   5 +-
 drivers/w1/masters/ds2482.c|   7 +-
 drivers/w1/masters/ds2490.c|  16 +--
 drivers/w1/masters/matrox_w1.c |  16 +--
 drivers/w1/masters/mxc_w1.c|  10 +-
 drivers/w1/masters/omap_hdq.c  |   7 +-
 drivers/w1/masters/w1-gpio.c   |   5 +-
 drivers/w1/slaves/w1_ds2405.c  |  12 +-
 drivers/w1/slaves/w1_ds2406.c  |   4 +-
 drivers/w1/slaves/w1_ds2408.c  |   4 +-
 drivers/w1/slaves/w1_ds2413.c  |   4 +-
 drivers/w1/slaves/w1_ds2423.c  |  15 +--
 drivers/w1/slaves/w1_ds2431.c  |   4 +-
 drivers/w1/slaves/w1_ds2433.c  |   4 +-
 drivers/w1/slaves/w1_ds2438.c  |   4 +-
 drivers/w1/slaves/w1_ds2780.c  |   6 +-
 drivers/w1/slaves/w1_ds2781.c  |   6 +-
 drivers/w1/slaves/w1_ds2805.c  |   4 +-
 drivers/w1/slaves/w1_ds28e04.c |   4 +-
 drivers/w1/slaves/w1_ds28e17.c |   4 +-
 drivers/w1/slaves/w1_smem.c|  16 +--
 drivers/w1/slaves/w1_therm.c   |  16 +--
 drivers/w1/w1.c| 272 +++--
 drivers/w1/w1_family.c |  15 +--
 drivers/w1/w1_int.c|  34 ++
 drivers/w1/w1_internal.h   |  11 +-
 drivers/w1/w1_io.c |  86 ++---
 drivers/w1/w1_netlink.c|  64 +-
 drivers/w1/w1_netlink.h|  39 +++---
 29 files changed, 283 insertions(+), 411 deletions(-)

-- 
2.11.0



[PATCH v2 00/11] w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi,

This is my first series of patches for the Linux kernel.
I started by familiarizing myself with coding style and
satisfying my inner OCD by cleaning the 1-wire subsystem.

Cheers,
Steffen

---

Changes since v1:
  - addressed comments from Joe Perches:
  - re-ran checkpatch.pl in --strict mode
  - fixed commit messages to reflect more precisly
the checkpatch warnings

Steffen Vogel (12):
  w1: add SPDX identifiers
  w1: improve code-style by adhering tp 80 columns per line limit
  w1: add newlines after declarations
  w1: cleanup whitespaces according to coding style document
  w1: use octal numbers instead of macros for file mode
  w1: do not log errors about failed memory allocations
  w1: use __func__ for logging the function name
  w1: improve code-style of struct declarations
  w1: using linux instead of asm prefix for includes
  w1: use pointers instead of types to determine size of allocs
  w1: replace non-standard %LX format-string by %llX
  w1: fix typo in comment

 drivers/w1/masters/ds1wm.c |   5 +-
 drivers/w1/masters/ds2482.c|   7 +-
 drivers/w1/masters/ds2490.c|  16 +--
 drivers/w1/masters/matrox_w1.c |  16 +--
 drivers/w1/masters/mxc_w1.c|  10 +-
 drivers/w1/masters/omap_hdq.c  |   7 +-
 drivers/w1/masters/w1-gpio.c   |   5 +-
 drivers/w1/slaves/w1_ds2405.c  |  12 +-
 drivers/w1/slaves/w1_ds2406.c  |   4 +-
 drivers/w1/slaves/w1_ds2408.c  |   4 +-
 drivers/w1/slaves/w1_ds2413.c  |   4 +-
 drivers/w1/slaves/w1_ds2423.c  |  15 +--
 drivers/w1/slaves/w1_ds2431.c  |   4 +-
 drivers/w1/slaves/w1_ds2433.c  |   4 +-
 drivers/w1/slaves/w1_ds2438.c  |   4 +-
 drivers/w1/slaves/w1_ds2780.c  |   6 +-
 drivers/w1/slaves/w1_ds2781.c  |   6 +-
 drivers/w1/slaves/w1_ds2805.c  |   4 +-
 drivers/w1/slaves/w1_ds28e04.c |   4 +-
 drivers/w1/slaves/w1_ds28e17.c |   4 +-
 drivers/w1/slaves/w1_smem.c|  16 +--
 drivers/w1/slaves/w1_therm.c   |  16 +--
 drivers/w1/w1.c| 272 +++--
 drivers/w1/w1_family.c |  15 +--
 drivers/w1/w1_int.c|  34 ++
 drivers/w1/w1_internal.h   |  11 +-
 drivers/w1/w1_io.c |  86 ++---
 drivers/w1/w1_netlink.c|  64 +-
 drivers/w1/w1_netlink.h|  39 +++---
 29 files changed, 283 insertions(+), 411 deletions(-)

-- 
2.11.0



Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Linus Torvalds
On Sun, Oct 28, 2018 at 5:30 PM Steffen Vogel  wrote:
>
> For those who are interested. Rspamd, by default, includes the sender
> address into the list of signed headers:

Ugh. That's just broken.

> There is RFC6377 which discusses this problem. On possible solution is
> a mailing list service which understands DKIM and can check/sign the
> messages.

I think that is almost purely historical.

People figured it out. The actual solution was that mailing lists just
don't rewrite headers or bodies, but they do set that "sender" line
(and add various new ones, like "List-ID" etc unsubscribe
information).

And that was exactly so that dkim would just work, without the list
having to then add its own signing that just causes even more
problems.

[ And no, lkml isn't actually great at this - it will mess up
whitespace on headers, so it only works with a relaxed/relaxed dkim
signature.

  But honestly, if you use strict/strict, you're doing something
wrong. It's a bad idea. Smtp was never whitespace-strict ]

> This is actually according to RFC. Listing signed header-fields
> multiple times prohibits them from beeing modified and resigned my other
> MTAs.

Again, that is mostly historical baggage. I don't think anybody
actually does that.

So yes, you'll find a lot of "what ifs" from ten years ago when people
weren't actually using dkim and mailing lists didn't try to work with
it. Mostly theoretical "this is how it could work".

I've seen some truly horrendous suggestions for mailing lists, like
always rewriting "From" headers etc exactly so that you can then make
a new dkim signature. That would make for a really bad mailing list.

.. and yes, I'm sure such bad mailing lists exist.

Linus


Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Linus Torvalds
On Sun, Oct 28, 2018 at 5:30 PM Steffen Vogel  wrote:
>
> For those who are interested. Rspamd, by default, includes the sender
> address into the list of signed headers:

Ugh. That's just broken.

> There is RFC6377 which discusses this problem. On possible solution is
> a mailing list service which understands DKIM and can check/sign the
> messages.

I think that is almost purely historical.

People figured it out. The actual solution was that mailing lists just
don't rewrite headers or bodies, but they do set that "sender" line
(and add various new ones, like "List-ID" etc unsubscribe
information).

And that was exactly so that dkim would just work, without the list
having to then add its own signing that just causes even more
problems.

[ And no, lkml isn't actually great at this - it will mess up
whitespace on headers, so it only works with a relaxed/relaxed dkim
signature.

  But honestly, if you use strict/strict, you're doing something
wrong. It's a bad idea. Smtp was never whitespace-strict ]

> This is actually according to RFC. Listing signed header-fields
> multiple times prohibits them from beeing modified and resigned my other
> MTAs.

Again, that is mostly historical baggage. I don't think anybody
actually does that.

So yes, you'll find a lot of "what ifs" from ten years ago when people
weren't actually using dkim and mailing lists didn't try to work with
it. Mostly theoretical "this is how it could work".

I've seen some truly horrendous suggestions for mailing lists, like
always rewriting "From" headers etc exactly so that you can then make
a new dkim signature. That would make for a really bad mailing list.

.. and yes, I'm sure such bad mailing lists exist.

Linus


Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi Linus,

Thanks! Its hopefully fixed now.

For those who are interested. Rspamd, by default, includes the sender
address into the list of signed headers:
https://www.rspamd.com/doc/modules/dkim_signing.html#default-sign_headers-after-173

> End result: the DKIM signature is guaranteed to fail after the email
> has gone through a mailing list.

There is RFC6377 which discusses this problem. On possible solution is
a mailing list service which understands DKIM and can check/sign the
messages.

See: https://tools.ietf.org/html/rfc6377

> You do have a few other oddities in there (the duplication of the
> common fields), but they shouldn't matter.

This is actually according to RFC. Listing signed header-fields
multiple times prohibits them from beeing modified and resigned my other
MTAs.

Thanks again,
Steffen

On Sun, Oct 28, 2018 at 03:53:07PM -0700, Linus Torvalds wrote:
> [ This is not about your patch series per se, only about your email settings ]
> 
> On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel  wrote:
> >
> > This is my first series of patches for the Linux kernel.
> > I started by familiarizing myself with coding style and
> > satisfying my inner OCD by cleaning the 1-wire subsystem.
> 
> Sadly, your DKIM setup is wrong, causing all the emails to be marked
> as spam when they go through a mailing list.
> 
> Your DKIM header looks like this:
> 
>   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de;
>   s=2017; t=1540764601;
> h=from:from:sender:reply-to:subject:subject:date:date:
>   message-id:message-id:to:to:cc:cc:mime-version:mime-version:
>   content-type:content-transfer-encoding:content-transfer-encoding:
>   in-reply-to:in-reply-to:references:references;
> 
> and the problem with that is the "sender" field in there.
> 
> A good mailing list will not change the contents of your email, or
> most of the other headers, but it *will* set the sender field to the
> mailing list.
> 
> 
> In other words, putting the sender field as part of the DKIM-checked
> headers is just wrong. It's a somewhat common mistake, but it's still
> wrong. I wonder where people get their setups from, because I think
> there is some DKIM guide on the internet that is actively spreading
> this bad behavior.
> 
> 
>  Linus


Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi Linus,

Thanks! Its hopefully fixed now.

For those who are interested. Rspamd, by default, includes the sender
address into the list of signed headers:
https://www.rspamd.com/doc/modules/dkim_signing.html#default-sign_headers-after-173

> End result: the DKIM signature is guaranteed to fail after the email
> has gone through a mailing list.

There is RFC6377 which discusses this problem. On possible solution is
a mailing list service which understands DKIM and can check/sign the
messages.

See: https://tools.ietf.org/html/rfc6377

> You do have a few other oddities in there (the duplication of the
> common fields), but they shouldn't matter.

This is actually according to RFC. Listing signed header-fields
multiple times prohibits them from beeing modified and resigned my other
MTAs.

Thanks again,
Steffen

On Sun, Oct 28, 2018 at 03:53:07PM -0700, Linus Torvalds wrote:
> [ This is not about your patch series per se, only about your email settings ]
> 
> On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel  wrote:
> >
> > This is my first series of patches for the Linux kernel.
> > I started by familiarizing myself with coding style and
> > satisfying my inner OCD by cleaning the 1-wire subsystem.
> 
> Sadly, your DKIM setup is wrong, causing all the emails to be marked
> as spam when they go through a mailing list.
> 
> Your DKIM header looks like this:
> 
>   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de;
>   s=2017; t=1540764601;
> h=from:from:sender:reply-to:subject:subject:date:date:
>   message-id:message-id:to:to:cc:cc:mime-version:mime-version:
>   content-type:content-transfer-encoding:content-transfer-encoding:
>   in-reply-to:in-reply-to:references:references;
> 
> and the problem with that is the "sender" field in there.
> 
> A good mailing list will not change the contents of your email, or
> most of the other headers, but it *will* set the sender field to the
> mailing list.
> 
> 
> In other words, putting the sender field as part of the DKIM-checked
> headers is just wrong. It's a somewhat common mistake, but it's still
> wrong. I wonder where people get their setups from, because I think
> there is some DKIM guide on the internet that is actively spreading
> this bad behavior.
> 
> 
>  Linus


Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Linus Torvalds
[ This is not about your patch series per se, only about your email settings ]

On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel  wrote:
>
> This is my first series of patches for the Linux kernel.
> I started by familiarizing myself with coding style and
> satisfying my inner OCD by cleaning the 1-wire subsystem.

Sadly, your DKIM setup is wrong, causing all the emails to be marked
as spam when they go through a mailing list.

Your DKIM header looks like this:

  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de;
  s=2017; t=1540764601;
h=from:from:sender:reply-to:subject:subject:date:date:
  message-id:message-id:to:to:cc:cc:mime-version:mime-version:
  content-type:content-transfer-encoding:content-transfer-encoding:
  in-reply-to:in-reply-to:references:references;

and the problem with that is the "sender" field in there.

A good mailing list will not change the contents of your email, or
most of the other headers, but it *will* set the sender field to the
mailing list.

End result: the DKIM signature is guaranteed to fail after the email
has gone through a mailing list.

In other words, putting the sender field as part of the DKIM-checked
headers is just wrong. It's a somewhat common mistake, but it's still
wrong. I wonder where people get their setups from, because I think
there is some DKIM guide on the internet that is actively spreading
this bad behavior.

You do have a few other oddities in there (the duplication of the
common fields), but they shouldn't matter.

 Linus


Re: w1: coding style and checkpatch fixes

2018-10-28 Thread Linus Torvalds
[ This is not about your patch series per se, only about your email settings ]

On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel  wrote:
>
> This is my first series of patches for the Linux kernel.
> I started by familiarizing myself with coding style and
> satisfying my inner OCD by cleaning the 1-wire subsystem.

Sadly, your DKIM setup is wrong, causing all the emails to be marked
as spam when they go through a mailing list.

Your DKIM header looks like this:

  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de;
  s=2017; t=1540764601;
h=from:from:sender:reply-to:subject:subject:date:date:
  message-id:message-id:to:to:cc:cc:mime-version:mime-version:
  content-type:content-transfer-encoding:content-transfer-encoding:
  in-reply-to:in-reply-to:references:references;

and the problem with that is the "sender" field in there.

A good mailing list will not change the contents of your email, or
most of the other headers, but it *will* set the sender field to the
mailing list.

End result: the DKIM signature is guaranteed to fail after the email
has gone through a mailing list.

In other words, putting the sender field as part of the DKIM-checked
headers is just wrong. It's a somewhat common mistake, but it's still
wrong. I wonder where people get their setups from, because I think
there is some DKIM guide on the internet that is actively spreading
this bad behavior.

You do have a few other oddities in there (the duplication of the
common fields), but they shouldn't matter.

 Linus


w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi,

This is my first series of patches for the Linux kernel.
I started by familiarizing myself with coding style and
satisfying my inner OCD by cleaning the 1-wire subsystem.

Steffen


w1: coding style and checkpatch fixes

2018-10-28 Thread Steffen Vogel
Hi,

This is my first series of patches for the Linux kernel.
I started by familiarizing myself with coding style and
satisfying my inner OCD by cleaning the 1-wire subsystem.

Steffen