[PATCH 0/2] netlink: protection and workaround for too long mcast group name

[PATCH 0/2] netlink: protection and workaround for too long mcast group name

[Masatake YAMATO]

You will see garbage at the end of line in the output of following command line:

	$ genl ctrl show | grep thermal_mc_group
        #1:  ID-0x2  name: thermal_mc_group^B

The type of structure field for "name" is char[16]:

    #define GENL_NAMSIZ	16	/* length of family name */
    ...
    struct genl_multicast_group {
            ...
	    char		name[GENL_NAMSIZ];
            ...
    };

strlen("thermal_mc_group") == 16 is too long for the array size.

This patch series provid a protection(patch for genetlink) for this 
kind of bug and workaround(patch for thermal). 

Masatake YAMATO (2):
  genetlink: trigger BUG_ON if a group name is too long
  thermal: shorten too long mcast group name

 include/linux/thermal.h | 2 +-
 net/netlink/genetlink.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.7.11.7

[PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Masatake YAMATO]

Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
 net/netlink/genetlink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f2aabb6..5a55be3 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -142,6 +142,7 @@ int genl_register_mc_group(struct genl_family *family,
 	int err = 0;
 
 	BUG_ON(grp->name[0] == '\0');
+	BUG_ON(memchr(grp->name, '\0', GENL_NAMSIZ) == NULL);
 
 	genl_lock();
 
-- 
1.7.11.7

[PATCH 2/2] thermal: shorten too long mcast group name

[Masatake YAMATO]

The original name is too long.

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
 include/linux/thermal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f0bd7f9..e3c0ae9 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -44,7 +44,7 @@
 /* Adding event notification support elements */
 #define THERMAL_GENL_FAMILY_NAME                "thermal_event"
 #define THERMAL_GENL_VERSION                    0x01
-#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_group"
+#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_grp"
 
 /* Default Thermal Governor */
 #if defined(CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE)
-- 
1.7.11.7

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[David Miller]

From: Masatake YAMATO <yamato@redhat.com>
Date: Tue, 19 Mar 2013 20:47:27 +0900

> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
> 
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>

Applied, thanks.

Although I'm disappointed that the compiler doesn't say anything about
this in the assignment.

We're assigning "char[16] = STRING" and it doesn't say anything if the
final NULL char doesn't fit into the array.

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[David Miller]

From: Masatake YAMATO <yamato@redhat.com>
Date: Tue, 19 Mar 2013 20:47:28 +0900

> The original name is too long.
> 
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This change needs to go in via the Thermal driver maintainers.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Ben Hutchings]

On Wed, 2013-03-20 at 12:07 -0400, David Miller wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Tue, 19 Mar 2013 20:47:27 +0900
> 
> > Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
> > 
> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> 
> Applied, thanks.
> 
> Although I'm disappointed that the compiler doesn't say anything about
> this in the assignment.
> 
> We're assigning "char[16] = STRING" and it doesn't say anything if the
> final NULL char doesn't fit into the array.

Unfortunately the C standard says this is allowed.  (Though the C++
standard says it's not!)  That doesn't mean the compiler can't warn
about it, of course.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Yinghai Lu]

On Wed, Mar 20, 2013 at 9:07 AM, David Miller <davem@davemloft.net> wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Tue, 19 Mar 2013 20:47:27 +0900
>
>> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>>
>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>
> Applied, thanks.

catch one in

drivers/thermal/thermal_sys.c::genetlink_init

        result = genl_register_mc_group(&thermal_event_genl_family,
                                        &thermal_event_mcgrp);

and

static struct genl_multicast_group thermal_event_mcgrp = {
        .name = THERMAL_GENL_MCAST_GROUP_NAME,
};

#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_group"

that string len 16.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[David Miller]

From: Yinghai Lu <yinghai@kernel.org>
Date: Wed, 20 Mar 2013 14:01:09 -0700

> On Wed, Mar 20, 2013 at 9:07 AM, David Miller <davem@davemloft.net> wrote:
>> From: Masatake YAMATO <yamato@redhat.com>
>> Date: Tue, 19 Mar 2013 20:47:27 +0900
>>
>>> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>>>
>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>>
>> Applied, thanks.
> 
> catch one in

Seriously?

That's what his second patch in this series fixes, we know about it
already.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Yinghai Lu]

On Wed, Mar 20, 2013 at 2:05 PM, David Miller <davem@davemloft.net> wrote:
> From: Yinghai Lu <yinghai@kernel.org>
> Date: Wed, 20 Mar 2013 14:01:09 -0700
>
>> On Wed, Mar 20, 2013 at 9:07 AM, David Miller <davem@davemloft.net> wrote:
>>> From: Masatake YAMATO <yamato@redhat.com>
>>> Date: Tue, 19 Mar 2013 20:47:27 +0900
>>>
>>>> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>>>>
>>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>>>
>>> Applied, thanks.
>>
>> catch one in
>
> Seriously?
>
> That's what his second patch in this series fixes, we know about it
> already.

[    6.047966] ------------[ cut here ]------------
[    6.048944] kernel BUG at net/netlink/genetlink.c:145!
[    6.049204] invalid opcode: 0000 [#1] SMP
[    6.049501] Modules linked in:
[    6.049728] CPU 2
[    6.050003] Pid: 1, comm: swapper/0 Not tainted
3.9.0-rc3-yh-00486-gb6d1e23-dirty #1371 Bochs Bochs
[    6.050299] RIP: 0010:[<ffffffff81f0f968>]  [<ffffffff81f0f968>]
genl_register_mc_group+0x38/0x270
[    6.050593] RSP: 0000:ffff880119e63dd8  EFLAGS: 00000246
[    6.050804] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff82b667c8
[    6.050931] RDX: ffffffff82b667c8 RSI: 0000000000000000 RDI: ffffffff82b667b8
[    6.050931] RBP: ffff880119e63e28 R08: 0000000000000000 R09: 0000000000000000
[    6.050931] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff82b667a0
[    6.050931] R13: ffffffff82b66720 R14: 00000001683fe47c R15: 0000000000000000
[    6.050931] FS:  0000000000000000(0000) GS:ffff88019f600000(0000)
knlGS:0000000000000000
[    6.050931] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    6.050931] CR2: 0000000000000000 CR3: 0000000002a14000 CR4: 00000000000006e0
[    6.050931] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.050931] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
[    6.050931] Process swapper/0 (pid: 1, threadinfo ffff880119e62000,
task ffff880119e68000)
[    6.050931] Stack:
[    6.050931]  ffff880119e63de8 ffffffff82b66720 ffffffff82dcb082
0000000000000000
[    6.050931]  ffff880119e63e28 ffffffff81f0f901 0000000000000000
ffffffff82dcb082
[    6.050931]  0000000000000000 00000001683fe47c ffff880119e63e48
ffffffff82dcb0f8
[    6.050931] Call Trace:
[    6.050931]  [<ffffffff82dcb082>] ? smsc47b397_init+0x19d/0x19d
[    6.050931]  [<ffffffff81f0f901>] ? genl_register_family+0x1b1/0x1e0
[    6.050931]  [<ffffffff82dcb082>] ? smsc47b397_init+0x19d/0x19d
[    6.050931]  [<ffffffff82dcb0f8>] thermal_init+0x76/0x8e
[    6.050931]  [<ffffffff81000254>] do_one_initcall+0x64/0x160
[    6.050931]  [<ffffffff82d8a321>] kernel_init_freeable+0x1bf/0x251
[    6.050931]  [<ffffffff82d89a71>] ? loglevel+0x31/0x31
[    6.050931]  [<ffffffff81ff0740>] ? rest_init+0xc0/0xc0
[    6.050931]  [<ffffffff81ff074e>] kernel_init+0xe/0xf0
[    6.050931]  [<ffffffff8202999c>] ret_from_fork+0x7c/0xb0
[    6.050931]  [<ffffffff81ff0740>] ? rest_init+0xc0/0xc0
[    6.050931] Code: 41 54 49 89 f4 53 48 83 ec 30 80 7e 18 00 75 03
0f 0b 90 49 89 fd 48 8d 7e 18 ba 10 00 00 00 31 f6 e8 3d 01 5e ff 48
85 c0 75 08 <0f> 0b 66 0f 1f 44 00 00 e8 7b f3 ff ff 49 81 fc a0 20 b8
82 74
[    6.050931] RIP  [<ffffffff81f0f968>] genl_register_mc_group+0x38/0x270
[    6.050931]  RSP <ffff880119e63dd8>
[    6.063404] ---[ end trace 60aaac53e4d8e418 ]---

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[David Miller]

From: Yinghai Lu <yinghai@kernel.org>
Date: Wed, 20 Mar 2013 14:06:06 -0700

> On Wed, Mar 20, 2013 at 2:05 PM, David Miller <davem@davemloft.net> wrote:
>> From: Yinghai Lu <yinghai@kernel.org>
>> Date: Wed, 20 Mar 2013 14:01:09 -0700
>>
>>> On Wed, Mar 20, 2013 at 9:07 AM, David Miller <davem@davemloft.net> wrote:
>>>> From: Masatake YAMATO <yamato@redhat.com>
>>>> Date: Tue, 19 Mar 2013 20:47:27 +0900
>>>>
>>>>> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>>>>>
>>>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>>>>
>>>> Applied, thanks.
>>>
>>> catch one in
>>
>> Seriously?
>>
>> That's what his second patch in this series fixes, we know about it
>> already.
> 
> [    6.047966] ------------[ cut here ]------------
> [    6.048944] kernel BUG at net/netlink/genetlink.c:145!

For the second time, we know about this bug.

His second patch fixes the themal layer bug.

But I told him to send it to the thermal maintainers so that they
can integrate it.

Why are you posting what we know already over and over?

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Yinghai Lu]

On Wed, Mar 20, 2013 at 2:13 PM, David Miller <davem@davemloft.net> wrote:
>>
>> [    6.047966] ------------[ cut here ]------------
>> [    6.048944] kernel BUG at net/netlink/genetlink.c:145!
>
> For the second time, we know about this bug.
>
> His second patch fixes the themal layer bug.
>
> But I told him to send it to the thermal maintainers so that they
> can integrate it.
>
> Why are you posting what we know already over and over?

so bisecting will be broken?

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[David Miller]

From: Yinghai Lu <yinghai@kernel.org>
Date: Wed, 20 Mar 2013 14:16:22 -0700

> On Wed, Mar 20, 2013 at 2:13 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> [    6.047966] ------------[ cut here ]------------
>>> [    6.048944] kernel BUG at net/netlink/genetlink.c:145!
>>
>> For the second time, we know about this bug.
>>
>> His second patch fixes the themal layer bug.
>>
>> But I told him to send it to the thermal maintainers so that they
>> can integrate it.
>>
>> Why are you posting what we know already over and over?
> 
> so bisecting will be broken?

Good point, so I'll apply the thermal patch to my tree to minimize
the failure range.

Thanks.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Yinghai Lu]

On Wed, Mar 20, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:

>> so bisecting will be broken?
>
> Good point, so I'll apply the thermal patch to my tree to minimize
> the failure range.

yes, that "second" patch should be applied before this one.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[David Miller]

From: Yinghai Lu <yinghai@kernel.org>
Date: Wed, 20 Mar 2013 15:17:13 -0700

> On Wed, Mar 20, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:
> 
>>> so bisecting will be broken?
>>
>> Good point, so I'll apply the thermal patch to my tree to minimize
>> the failure range.
> 
> yes, that "second" patch should be applied before this one.

But it's too late as the first one is already commited to my public
GIT tree on kernel.org and I never rebase my tree, ever.

So this is the only option to minimize the damage at this point.

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[Masatake YAMATO]

> From: Masatake YAMATO <yamato@redhat.com>
> Date: Tue, 19 Mar 2013 20:47:28 +0900
> 
>> The original name is too long.
>> 
>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> 
> This change needs to go in via the Thermal driver maintainers.

Thanks. I've submitted the patch to linux-acpi ML.

Masatake YAMATO

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Masatake YAMATO]

I will look at sparse whether it can capture this kind of mistake.

Masatake YAMATO

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 20 Mar 2013 17:32:59 +0000
> On Wed, 2013-03-20 at 12:07 -0400, David Miller wrote:
>> From: Masatake YAMATO <yamato@redhat.com>
>> Date: Tue, 19 Mar 2013 20:47:27 +0900
>> 
>> > Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>> > 
>> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>> 
>> Applied, thanks.
>> 
>> Although I'm disappointed that the compiler doesn't say anything about
>> this in the assignment.
>> 
>> We're assigning "char[16] = STRING" and it doesn't say anything if the
>> final NULL char doesn't fit into the array.
> 
> Unfortunately the C standard says this is allowed.  (Though the C++
> standard says it's not!)  That doesn't mean the compiler can't warn
> about it, of course.
> 
> Ben.
> 
> -- 
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
> 

[PATCH] thermal: shorten too long mcast group name

[Masatake YAMATO]

You will see garbage at the end of line in the output of following command line:

        $ genl ctrl show | grep thermal_mc_group
        #1:  ID-0x2  name: thermal_mc_group^B

The type of structure field for "name" is char[16] in the kernel:

    #define GENL_NAMSIZ 16      /* length of family name */
    ...
    struct genl_multicast_group {
            ...
            char                name[GENL_NAMSIZ];
            ...
    };

strlen("thermal_mc_group") == 16 is too long for the array size.

"thermal_mc_grp" is more readable than "thermal_mc_grou". However,
I choose latter; the patch for genl command side may truncate the
last char in the name:

     http://marc.info/?l=linux-netdev&m=136371412625262&w=2

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
 include/linux/thermal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f0bd7f9..a65dff3 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -44,7 +44,7 @@
 /* Adding event notification support elements */
 #define THERMAL_GENL_FAMILY_NAME                "thermal_event"
 #define THERMAL_GENL_VERSION                    0x01
-#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_group"
+#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_grou"
 
 /* Default Thermal Governor */
 #if defined(CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE)
-- 
1.7.11.7

RE: [PATCH] thermal: shorten too long mcast group name

[R, Durgadoss]

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Masatake YAMATO
> Sent: Thursday, March 21, 2013 3:38 PM
> To: linux-acpi@vger.kernel.org
> Cc: yamato@redhat.com
> Subject: [PATCH] thermal: shorten too long mcast group name
> 
> You will see garbage at the end of line in the output of following command
> line:
> 
>         $ genl ctrl show | grep thermal_mc_group
>         #1:  ID-0x2  name: thermal_mc_group^B

Agreed.

> 
> The type of structure field for "name" is char[16] in the kernel:
> 
>     #define GENL_NAMSIZ 16      /* length of family name */
>     ...
>     struct genl_multicast_group {
>             ...
>             char                name[GENL_NAMSIZ];
>             ...
>     };
> 
> strlen("thermal_mc_group") == 16 is too long for the array size.
> 
> "thermal_mc_grp" is more readable than "thermal_mc_grou". However,
> I choose latter; the patch for genl command side may truncate the
> last char in the name:

I prefer we use thermal_mc_grp.

+ Adding Rui & the Linux-pm list.

Thanks,
Durga
> 
>      http://marc.info/?l=linux-netdev&m=136371412625262&w=2
> 
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> ---
>  include/linux/thermal.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index f0bd7f9..a65dff3 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -44,7 +44,7 @@
>  /* Adding event notification support elements */
>  #define THERMAL_GENL_FAMILY_NAME                "thermal_event"
>  #define THERMAL_GENL_VERSION                    0x01
> -#define THERMAL_GENL_MCAST_GROUP_NAME
> "thermal_mc_group"
> +#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_grou"
> 
>  /* Default Thermal Governor */
>  #if defined(CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE)
> --
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[Thomas Graf]

On 03/19/13 at 08:47pm, Masatake YAMATO wrote:
> The original name is too long.
> 
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> ---
>  include/linux/thermal.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index f0bd7f9..e3c0ae9 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -44,7 +44,7 @@
>  /* Adding event notification support elements */
>  #define THERMAL_GENL_FAMILY_NAME                "thermal_event"
>  #define THERMAL_GENL_VERSION                    0x01
> -#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_group"
> +#define THERMAL_GENL_MCAST_GROUP_NAME           "thermal_mc_grp"

Just saying that this would not be OK in general as this would
break any application looking up the multicast group id by name
via genetlink but since it's broken anyway right now it's OK I guess.

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[David Miller]

From: Masatake YAMATO <yamato@redhat.com>
Date: Thu, 21 Mar 2013 16:46:23 +0900 (JST)

>> From: Masatake YAMATO <yamato@redhat.com>
>> Date: Tue, 19 Mar 2013 20:47:28 +0900
>> 
>>> The original name is too long.
>>> 
>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>> 
>> This change needs to go in via the Thermal driver maintainers.
> 
> Thanks. I've submitted the patch to linux-acpi ML.

I already applied the patch to my tree, didn't you read
the rest of this thread?

And in the future, order your patches such that you fix the bug before
adding the assertion.

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[Masatake YAMATO]

Sorry for cross posting to netdev and linux-acpi.

I submitted almost same patch about thermal subsystem both netdev list
and then linux-acpi list.

http://marc.info/?l=linux-netdev&m=136371412725264&w=2
http://marc.info/?l=linux-acpi&m=136386050309109&w=2

After submitting to linux-acpi list, I noticed the patch
is merged to a tree davem maintained.

What I should do?

The submitted pathes are bit different.
In netdev, I proposed changing "thermal_mc_group" to
"thermal_mc_grp". In linux-acpi I proposed changing 
"thermal_mc_group" to "thermal_mc_grou".

"thermal_mc_grp" is easier to read. However, when thinking
about compatibility, "thermal_mc_grou" is better.

I've already submitted another patch for genl command which 
truncates the C string returned from kernel.

http://marc.info/?l=linux-netdev&m=136371412625262&w=2

Consider a situation(A); using old kernel(without my patch submitted for linux-acpi)
and new genl command (with my patch for genl). You will get

   thermal_mc_grou

as output.


Consider anther situation(B); using new kernel(with my patch submitted for 
linux-acpi) and old genl command (without my patch for genl). You will get

   thermal_mc_grou

as output. In both situations(A and B) users can get the same output.
If you choose "thermal_mc_grp", users may see "thermal_mc_grp" or
"thermal_mc_grou".

>>> From: Masatake YAMATO <yamato@redhat.com>
>>> Date: Tue, 19 Mar 2013 20:47:28 +0900
>>> 
>>>> The original name is too long.
>>>> 
>>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>>> 
>>> This change needs to go in via the Thermal driver maintainers.
>> 
>> Thanks. I've submitted the patch to linux-acpi ML.
> 
> I already applied the patch to my tree, didn't you read
> the rest of this thread?

I read but I didn't understand the meaning of applying because
I cannot find my 2nd patch for thermal in net-next tree when I 
pulled.

What I should do? Should I withdraw the patch submitted to 
linux-acpi?

However, I slight modified the patch when I submitted it to 
linux-acpi.

> And in the future, order your patches such that you fix the bug before
> adding the assertion.

Sorry. I'll do so next time.

Masatake YAMATO

Re: [PATCH 2/2] thermal: shorten too long mcast group name

[David Miller]

From: Masatake YAMATO <yamato@redhat.com>
Date: Fri, 22 Mar 2013 12:43:06 +0900 (JST)

> I read but I didn't understand the meaning of applying because
> I cannot find my 2nd patch for thermal in net-next tree when I 
> pulled.

These are bug fixes, so they appear in the 'net' tree not 'net-next'.

Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long

[Masatake YAMATO]

From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long
Date: Wed, 20 Mar 2013 12:07:05 -0400 (EDT)
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Tue, 19 Mar 2013 20:47:27 +0900
> 
>> Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
>> 
>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> 
> Applied, thanks.
> 
> Although I'm disappointed that the compiler doesn't say anything about
> this in the assignment.
> 
> We're assigning "char[16] = STRING" and it doesn't say anything if the
> final NULL char doesn't fit into the array.

Now sparse with -Winit-cstring option can detect this kind assignment.

https://git.kernel.org/cgit/devel/sparse/chrisl/sparse.git/commit/?id=c3430e57bc57ff40d5ce95ef2d26b8d70346f58f

Masatake YAMATO