* Re: [PATCH] Add error check to hex2bin().
From: Geert Uytterhoeven @ 2011-07-18 20:49 UTC (permalink / raw)
To: Tetsuo Handa
Cc: linux-security-module, andriy.shevchenko, netdev, linux-kernel
In-Reply-To: <201107182148.AGD21306.FOLtJVMSOOFQHF@I-love.SAKURA.ne.jp>
On Mon, Jul 18, 2011 at 14:48, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Currently, security/keys/ is the only user of hex2bin().
> Should I keep hex2bin() unmodified in case of bad input?
> If so, I'd like to make it as hex2bin_safe().
> ----------------------------------------
> [PATCH] Add error check to hex2bin().
>
> Since converting 2 hexadecimal letters into a byte with error checks is
> commonly used, we can replace multiple hex_to_bin() calls with single hex2bin()
> call by changing hex2bin() to do error checks.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I=love.SAKURA.ne.jp>
> ---
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 953352a..186e9fc 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -374,7 +374,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
> }
>
> extern int hex_to_bin(char ch);
> -extern void hex2bin(u8 *dst, const char *src, size_t count);
> +extern bool hex2bin(u8 *dst, const char *src, size_t count);
>
> /*
> * General tracing related utility functions - trace_printk(),
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index f5fe6ba..1524002 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -38,14 +38,22 @@ EXPORT_SYMBOL(hex_to_bin);
> * @dst: binary result
> * @src: ascii hexadecimal string
> * @count: result length
> + *
> + * Returns true on success, false in case of bad input.
What about making it return the number of unprocessed bytes left instead?
Then the caller knows where the problem lies. And zero would mean success.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ping6
From: eric @ 2011-07-18 20:23 UTC (permalink / raw)
To: netdev
Hi,
I've found what I think is a bug in the ping6 tool. Without the -n option,
it puts the hostname inside the parenthesis instead of the resolved ip
address as demonstrated below:
ericat@hydra:~/iputils-s20101006$ ping6 ipv6.he.net
PING ipv6.he.net(ipv6.he.net) 56 data bytes
64 bytes from ipv6.he.net: icmp_seq=1 ttl=58 time=186 ms
I expect output like this:
ericat@hydra:~/iputils-s20101006$ sudo ./ping6 ipv6.he.net
Password:
PING ipv6.he.net(2001:470:0:64::2) 56 data bytes
64 bytes from ipv6.he.net: icmp_seq=1 ttl=58 time=187 ms
Here's a very simple patch to ping6.c for proper behaviour:
ericat@hydra:~/iputils-s20101006$ diff ping6.c.orig ping6.c
979c979
< printf("PING %s(%s) ", hostname, pr_addr(&whereto.sin6_addr));
---
> printf("PING %s(%s) ", hostname, pr_addr_n(&whereto.sin6_addr));
Cheers,
Eric Atkin
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-07-18 20:18 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
A few last-minute stragglers. The Tulip debug message thing, in
particular, is a really annoying regression for people who have
that hardware.
1) pr_*() conversion of tulip driver turned some commented out messages
into pr_debug() which spams the log, just kill them off. From Joe
Perches.
2) PPPOE connections are keyed on MAC address, so we have to flush all
connections on a device when the MAC address changes since until we
renegotiate with the new MAC address the remote end won't see any
of our packets.
3) linux/sdla.h has a kernel function declaration in the userspace
visible area. In fact this function hasn't been in the kernel for
years so just remove it outright. From WANG Cong.
Please pull, thanks a lot.
The following changes since commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6:
si4713-i2c: avoid potential buffer overflow on si4713 (2011-07-18 09:12:21 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
David S. Miller (1):
pppoe: Must flush connections when MAC address changes too.
Joe Perches (1):
tulip: dmfe: Remove old log spamming pr_debugs
WANG Cong (1):
include/linux/sdla.h: remove the prototype of sdla()
drivers/net/pppoe.c | 3 ++-
drivers/net/tulip/dmfe.c | 4 ----
include/linux/sdla.h | 6 +-----
3 files changed, 3 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: filter: BPF 'JIT' compiler for PPC64
From: Eric Dumazet @ 2011-07-18 20:05 UTC (permalink / raw)
To: David Miller; +Cc: matt, netdev, linuxppc-dev
In-Reply-To: <20110718.124248.1462465498024218250.davem@davemloft.net>
Le lundi 18 juillet 2011 à 12:42 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 18 Jul 2011 10:39:35 +0200
>
> > So in PPC SEEN_XREG only is to be set of X is read, not if written.
> >
> > So you dont have to set SEEN_XREG bit in this part :
>
> Matt, do you want to integrate changes based upon Eric's feedback
> here or do you want me to apply your patch as-is for now?
>
This was a really minor point, so Matt feel free to ask an immediate
inclusion ;)
^ permalink raw reply
* Re: [PATCH] net: filter: BPF 'JIT' compiler for PPC64
From: David Miller @ 2011-07-18 19:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: matt, netdev, linuxppc-dev
In-Reply-To: <1310978375.5756.7.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 18 Jul 2011 10:39:35 +0200
> So in PPC SEEN_XREG only is to be set of X is read, not if written.
>
> So you dont have to set SEEN_XREG bit in this part :
Matt, do you want to integrate changes based upon Eric's feedback
here or do you want me to apply your patch as-is for now?
Thanks.
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Andy Shevchenko @ 2011-07-18 19:44 UTC (permalink / raw)
To: Mimi Zohar
Cc: Tetsuo Handa, linux-security-module, andriy.shevchenko, netdev,
linux-kernel
In-Reply-To: <1311016856.3648.15.camel@localhost.localdomain>
On Mon, Jul 18, 2011 at 10:20 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> > We probably don't need to define a separate 'safe' function.
>> There is an opponent on any approach. Although, small and fast error
>> route could be good.
> As nothing but trusted/encrypted keys is using hex2bin, it shouldn't be
> a problem. :-)
The key word "until now". But people will start to use anything which
has public API, won't they?
> I'll update trusted/encrypted keys to check the return
> code.
Actually another question shall we add __must_check to the prototype or not?
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] connector: add an event for monitoring process tracers
From: Oleg Nesterov @ 2011-07-18 19:39 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: netdev, Evgeniy Polyakov, David S. Miller
In-Reply-To: <CAMW3pwYvXqi4=e24kvQRdsHsFa5o1KL9PrekK0RCVyWTvhNx4A@mail.gmail.com>
On 07/18, Vladimir Zapolskiy wrote:
>
> On Mon, Jul 18, 2011 at 8:54 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> > "which_id" doesn't match "ptrace_id" used elsewhere. And PTRACE_ATTACH
> > instead of simple boolean looks as if you are going to add more ptrace
> > events, but I guess this won't happen.
> >
>^
> I'd like to preserve that variant, in my opinion its just a bit more
> undisguised version rather than bare true/false.
OK. Although this "else return" in proc_ptrace_connector() looks like
the "hide the potentional error" to me.
> >> - if (!retval)
> >> + if (!retval) {
> >> wait_on_bit(&task->jobctl, JOBCTL_TRAPPING_BIT,
> >> ptrace_trapping_sleep_fn, TASK_UNINTERRUPTIBLE);
> >> + proc_ptrace_connector(task, PTRACE_ATTACH);
> >> + }
> >
> > OK, but it is a bit strange we are waiting for STOPPED/TRACED transition
> > before we report PROC_EVENT_PTRACE. Perhaps it makes more sense to
> > call proc_ptrace_connector() first, this also decreases the probability
> > PTRACE_ATTACH will be reported after PROC_EVENT_EXIT.
> >
> Yes, there is a difference. But as far as there is no guaranteed
> serialization in proc connector event reports, user-space process
> trackers should be designed to operate correctly having in mind
> possible event reordering.
Yes, but I didn't really mean the correctness. I meant, this looks
confusing, as if this wait_on_bit() has something to do with attach.
Likewise I do not understand why proc_exec_connector() is called
after ptrace_event() which can sleep unpredictably long.
Nevermind, applied.
Oleg.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with Linus' tree
From: David Miller @ 2011-07-18 19:33 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, iliak, padovan, luiz.von.dentz
In-Reply-To: <20110718144138.d57ab0a2a806e06fabbcfc9b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Jul 2011 14:41:38 +1000
> Today's linux-next merge of the net tree got a conflict in
> net/bluetooth/l2cap_core.c between commit 9191e6ad897a ("Bluetooth: Fix
> regression in L2CAP connection procedure") from Linus' tree and commit
> e2fd318e3a92 ("Bluetooth: Fixes l2cap "command reject" reply according to
> spec") from the net tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks Stephen, I'll sort this out next time I do a merge between
net-2.6 and net-next-2.6.
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Mimi Zohar @ 2011-07-18 19:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tetsuo Handa, linux-security-module, andriy.shevchenko, netdev,
linux-kernel
In-Reply-To: <CAHp75VcXNQKej_n4cOB8-gYDSL8MuGrv=Fs8=zdEKGp53DCtSA@mail.gmail.com>
On Mon, 2011-07-18 at 21:57 +0300, Andy Shevchenko wrote:
> On Mon, Jul 18, 2011 at 9:03 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mon, 2011-07-18 at 21:48 +0900, Tetsuo Handa wrote:
> >> Currently, security/keys/ is the only user of hex2bin().
> >> Should I keep hex2bin() unmodified in case of bad input?
> >> If so, I'd like to make it as hex2bin_safe().
> >
> >> ----------------------------------------
> >> [PATCH] Add error check to hex2bin().
> >>
> >> Since converting 2 hexadecimal letters into a byte with error checks is
> >> commonly used, we can replace multiple hex_to_bin() calls with single hex2bin()
> >> call by changing hex2bin() to do error checks.
> >>
> >> Signed-off-by: Tetsuo Handa <penguin-kernel@I=love.SAKURA.ne.jp>
> >> ---
> >> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> >> index 953352a..186e9fc 100644
> >> --- a/include/linux/kernel.h
> >> +++ b/include/linux/kernel.h
> >> @@ -374,7 +374,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
> >> }
> >>
> >> extern int hex_to_bin(char ch);
> >> -extern void hex2bin(u8 *dst, const char *src, size_t count);
> >> +extern bool hex2bin(u8 *dst, const char *src, size_t count);
> >>
> >> /*
> >> * General tracing related utility functions - trace_printk(),
> >> diff --git a/lib/hexdump.c b/lib/hexdump.c
> >> index f5fe6ba..1524002 100644
> >> --- a/lib/hexdump.c
> >> +++ b/lib/hexdump.c
> >> @@ -38,14 +38,22 @@ EXPORT_SYMBOL(hex_to_bin);
> >> * @dst: binary result
> >> * @src: ascii hexadecimal string
> >> * @count: result length
> >> + *
> >> + * Returns true on success, false in case of bad input.
> >> */
> >> -void hex2bin(u8 *dst, const char *src, size_t count)
> >> +bool hex2bin(u8 *dst, const char *src, size_t count)
> >> {
> >> while (count--) {
> >> - *dst = hex_to_bin(*src++) << 4;
> >> - *dst += hex_to_bin(*src++);
> >> - dst++;
> >> + int c = hex_to_bin(*src++);
> >> + int d;
> >
> > Missing blank line here.
> >
> >> + if (c < 0)
> >> + return false;
> >> + d = hex_to_bin(*src++);
> >> + if (d < 0)
> >> + return false;
> >> + *dst++ = (c << 4) | d;
> >> }
> >> + return true;
> >> }
> >> EXPORT_SYMBOL(hex2bin);
> >
> > We probably don't need to define a separate 'safe' function.
> There is an opponent on any approach. Although, small and fast error
> route could be good.
As nothing but trusted/encrypted keys is using hex2bin, it shouldn't be
a problem. :-) I'll update trusted/encrypted keys to check the return
code.
thanks,
Mimi
> > Instead of changing the existing code to short circuit out and return a
> > value, does only adding the return value work? Something like:
> >
> > bool ret = true;
> > int c, d;
> >
> > while (count--) {
> > c = hex_to_bin(*src++);
> > d = hex_to_bin(*src++);
> Here is a performance issue, yeah. The user prefers to know about an
> error as soon as possible.
ok
> > *dst++ = (c << 4) | d;
> >
> > if (c < 0 || d < 0)
> > ret = false;
> The ret value is redundant, and here you continue to fill the result
> array by something arbitrary (might be wrong data).
>
> > }
> > return ret;
> >
^ permalink raw reply
* Re: [PATCH v2] connector: add an event for monitoring process tracers
From: Vladimir Zapolskiy @ 2011-07-18 18:57 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: netdev, Evgeniy Polyakov, David S. Miller
In-Reply-To: <20110718175458.GA12840@redhat.com>
On Mon, Jul 18, 2011 at 8:54 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 07/15, Vladimir Zapolskiy wrote:
>>
>> Such an event allows to create a simple automated userspace mechanism
>> to be aware about processes connecting to others, therefore predefined
>> process policies can be applied to them if needed.
>
> I'd wish I could understand this ;) IOW, I still do not understand why
> this is useful, but this doesn't matter. Since Evgeniy acked this patch,
> I'll apply it to ptrace tree.
>
Originally the idea comes from a desire to classify development tools
like strace or gdb in the same way as a tracee process, for instance
put them to a tracee's current cgroup partition, which might be done
automatically in user-space by some process "track and manage" daemon.
>
> Can't resist, a couple of very minor/cosmetics nits. Just because I am
> blighter ;)
>
>> +void proc_ptrace_connector(struct task_struct *task, int which_id);
>
> "which_id" doesn't match "ptrace_id" used elsewhere. And PTRACE_ATTACH
> instead of simple boolean looks as if you are going to add more ptrace
> events, but I guess this won't happen.
>
I'd like to preserve that variant, in my opinion its just a bit more
undisguised version rather than bare true/false.
>> - if (!retval)
>> + if (!retval) {
>> wait_on_bit(&task->jobctl, JOBCTL_TRAPPING_BIT,
>> ptrace_trapping_sleep_fn, TASK_UNINTERRUPTIBLE);
>> + proc_ptrace_connector(task, PTRACE_ATTACH);
>> + }
>
> OK, but it is a bit strange we are waiting for STOPPED/TRACED transition
> before we report PROC_EVENT_PTRACE. Perhaps it makes more sense to
> call proc_ptrace_connector() first, this also decreases the probability
> PTRACE_ATTACH will be reported after PROC_EVENT_EXIT.
>
Yes, there is a difference. But as far as there is no guaranteed
serialization in proc connector event reports, user-space process
trackers should be designed to operate correctly having in mind
possible event reordering.
>
> But once again, this is very minor and cosmetic. I am going to apply
> the patch as is unless you send v3 quickly.
>
Thank you a lot, especially for comments, but I think this v2 is good
enough to be applied :) And if there are more users of that proc
connector extension in future, it might be needed to cut some sharp
corners later, and may be even add implicit detach reporting :)
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Andy Shevchenko @ 2011-07-18 18:57 UTC (permalink / raw)
To: Mimi Zohar
Cc: Tetsuo Handa, linux-security-module, andriy.shevchenko, netdev,
linux-kernel
In-Reply-To: <1311012230.3193.35.camel@localhost.localdomain>
On Mon, Jul 18, 2011 at 9:03 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mon, 2011-07-18 at 21:48 +0900, Tetsuo Handa wrote:
>> Currently, security/keys/ is the only user of hex2bin().
>> Should I keep hex2bin() unmodified in case of bad input?
>> If so, I'd like to make it as hex2bin_safe().
>
>> ----------------------------------------
>> [PATCH] Add error check to hex2bin().
>>
>> Since converting 2 hexadecimal letters into a byte with error checks is
>> commonly used, we can replace multiple hex_to_bin() calls with single hex2bin()
>> call by changing hex2bin() to do error checks.
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I=love.SAKURA.ne.jp>
>> ---
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 953352a..186e9fc 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -374,7 +374,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
>> }
>>
>> extern int hex_to_bin(char ch);
>> -extern void hex2bin(u8 *dst, const char *src, size_t count);
>> +extern bool hex2bin(u8 *dst, const char *src, size_t count);
>>
>> /*
>> * General tracing related utility functions - trace_printk(),
>> diff --git a/lib/hexdump.c b/lib/hexdump.c
>> index f5fe6ba..1524002 100644
>> --- a/lib/hexdump.c
>> +++ b/lib/hexdump.c
>> @@ -38,14 +38,22 @@ EXPORT_SYMBOL(hex_to_bin);
>> * @dst: binary result
>> * @src: ascii hexadecimal string
>> * @count: result length
>> + *
>> + * Returns true on success, false in case of bad input.
>> */
>> -void hex2bin(u8 *dst, const char *src, size_t count)
>> +bool hex2bin(u8 *dst, const char *src, size_t count)
>> {
>> while (count--) {
>> - *dst = hex_to_bin(*src++) << 4;
>> - *dst += hex_to_bin(*src++);
>> - dst++;
>> + int c = hex_to_bin(*src++);
>> + int d;
>
> Missing blank line here.
>
>> + if (c < 0)
>> + return false;
>> + d = hex_to_bin(*src++);
>> + if (d < 0)
>> + return false;
>> + *dst++ = (c << 4) | d;
>> }
>> + return true;
>> }
>> EXPORT_SYMBOL(hex2bin);
>
> We probably don't need to define a separate 'safe' function.
There is an opponent on any approach. Although, small and fast error
route could be good.
>
> Instead of changing the existing code to short circuit out and return a
> value, does only adding the return value work? Something like:
>
> bool ret = true;
> int c, d;
>
> while (count--) {
> c = hex_to_bin(*src++);
> d = hex_to_bin(*src++);
Here is a performance issue, yeah. The user prefers to know about an
error as soon as possible.
> *dst++ = (c << 4) | d;
>
> if (c < 0 || d < 0)
> ret = false;
The ret value is redundant, and here you continue to fill the result
array by something arbitrary (might be wrong data).
> }
> return ret;
>
> thanks,
>
> Mimi
>
>> In message "Re: [PATCH] net: can: remove custom hex_to_bin()",
>> Andy Shevchenko wrote:
>> > On Mon, 2011-07-18 at 20:41 +0900, Tetsuo Handa wrote:
>> > > Andy Shevchenko wrote:
>> > > > for (i = 0, dlc_pos++; i < cf.can_dlc; i++) {
>> > > > -
>> > > > - tmp = asc2nibble(sl->rbuff[dlc_pos++]);
>> > > > - if (tmp > 0x0F)
>> > > > + tmp = hex_to_bin(sl->rbuff[dlc_pos++]);
>> > > > + if (tmp < 0)
>> > > > return;
>> > > > cf.data[i] = (tmp << 4);
>> > > > - tmp = asc2nibble(sl->rbuff[dlc_pos++]);
>> > > > - if (tmp > 0x0F)
>> > > > + tmp = hex_to_bin(sl->rbuff[dlc_pos++]);
>> > > > + if (tmp < 0)
>> > > > return;
>> > > > cf.data[i] |= tmp;
>> > > > }
>> > >
>> > > What about changing
>> > >
>> > > void hex2bin(u8 *dst, const char *src, size_t count)
>> > >
>> > > to
>> > >
>> > > bool hex2bin(u8 *dst, const char *src, size_t count)
>> > >
>> > > in order to do error checks like
>> > >
>> > > bool hex2bin_with_validation(u8 *dst, const char *src, size_t count)
>> > > {
>> > > while (count--) {
>> > > int c = hex_to_bin(*src++);
>> > > int d;
>> > > if (c < 0)
>> > > return false;
>> > > d = hex_to_bin(*src++)
>> > > if (d < 0)
>> > > return false;
>> > > *dst++ = (c << 4) | d;
>> > > }
>> > > return true;
>> > > }
>> > >
>> > > and use hex2bin() rather than hex_to_bin()?
>> > Perhaps, good idea. Could you submit a patch?
>> >
>> > --
>> > Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> > Intel Finland Oy
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> 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/
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [Bugme-new] [Bug 39252] New: [r8169] PPPoE connections don't work if a custom MAC address is assigned
From: David Miller @ 2011-07-18 18:50 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugme-daemon, t.artem, mostrows
In-Reply-To: <20110713161345.82e254de.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Wed, 13 Jul 2011 16:13:45 -0700
>> https://bugzilla.kernel.org/show_bug.cgi?id=39252
>>
>> Summary: [r8169] PPPoE connections don't work if a custom MAC
>> address is assigned
...
>> Description of problem: if I assign a custom MAC address to my onboard NIC,
>> then I cannot establish PPPoE connections, and even `pppoe -A` command doesn't
>> return any PPPoE access concentrators.
Since you seem to be creating your PPPoE connections _after_ changing
the MAC, the following shouldn't matter, but for the cases where
PPPoE connections already exist we do need this kind of change.
Again, I don't expect this to fix the bug, and I believe that it's
some r8169 specific issue. Although, it might.
--------------------
pppoe: Must flush connections when MAC address changes too.
Kernel bugzilla: 39252
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/pppoe.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 718879b..bc9a4bb 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -348,8 +348,9 @@ static int pppoe_device_event(struct notifier_block *this,
/* Only look at sockets that are using this specific device. */
switch (event) {
+ case NETDEV_CHANGEADDR:
case NETDEV_CHANGEMTU:
- /* A change in mtu is a bad thing, requiring
+ /* A change in mtu or address is a bad thing, requiring
* LCP re-negotiation.
*/
--
1.7.6
^ permalink raw reply related
* Re: [RFC PATCH] net: vlan: 802.1ad S-VLAN support
From: David Miller @ 2011-07-18 18:37 UTC (permalink / raw)
To: equinox; +Cc: netdev, kaber
In-Reply-To: <1310936105-3494206-1-git-send-email-equinox@diac24.net>
From: David Lamparter <equinox@diac24.net>
Date: Sun, 17 Jul 2011 22:55:05 +0200
> - int vlan_pidx(u16 protocol)
> do i do this with a table? that wastes a cacheline... as code it's
> around 32 bytes on x86_64. it's not called for regular 802.1Q frames
> from any hot paths btw, so maybe i shouldn't care?
Don't worry about something you haven't seen on profiling output yet,
unless it's something painfully obvious (f.e. using linked list of
thousands of entries for lookups)
FWIW, the counter argument for your concern is that the function
version takes up an I-cache line.
Anyways, like I said, I'd just leave it alone and get rid of all of
that #if 0 stuff.
^ permalink raw reply
* Re: [PATCH] net: can: remove custom hex_to_bin()
From: David Miller @ 2011-07-18 18:33 UTC (permalink / raw)
To: socketcan; +Cc: andriy.shevchenko, netdev, linux-kernel, wg
In-Reply-To: <4E243D09.9020800@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Mon, 18 Jul 2011 16:02:49 +0200
> On 18.07.2011 10:26, Andy Shevchenko wrote:
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Cc: Wolfgang Grandegger <wg@grandegger.com>
>
> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [PATCH] tulip: dmfe: Remove old log spamming pr_debugs
From: David Miller @ 2011-07-18 18:11 UTC (permalink / raw)
To: joe; +Cc: jdelvare, grundler, netdev, linux-kernel
In-Reply-To: <1311012332.2286.110.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Mon, 18 Jul 2011 11:05:32 -0700
> On Mon, 2011-07-18 at 10:45 -0700, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Mon, 18 Jul 2011 07:50:33 -0700
>> > Commit 726b65ad444d ("tulip: Convert uses of KERN_DEBUG") enabled
>> > some old previously inactive uses of pr_debug converted by
>> > commit dde7c8ef1679 ("tulip/dmfe.c: Use dev_<level> and pr_<level>").
>> > Remove these pr_debugs.
>> > Signed-off-by: Joe Perches <joe@perches.com>
>> Applied.
>
> I believe this should go into current if you push
> one more to Linus or maybe stable for 3.0.
I know, that's why I added it to net-2.6
^ permalink raw reply
* Re: [Patch] include/linux/sdla.h: remove the prototype of sdla()
From: David Miller @ 2011-07-18 18:06 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: mmarek, akpm, linux-kernel, netdev
In-Reply-To: <CAM_iQpWDrhHw8-Hf4q1miHR+rT33wQb=ZSb=ffsxaSak=UHPMw@mail.gmail.com>
From: Américo Wang <xiyou.wangcong@gmail.com>
Date: Sun, 17 Jul 2011 16:22:20 +0800
> `make headers_check` complains that
>
> linux-2.6/usr/include/linux/sdla.h:116: userspace cannot reference
> function or variable defined in the kernel
>
> this is due to that there is no such a kernel function,
>
> void sdla(void *cfg_info, char *dev, struct frad_conf *conf, int quiet);
>
> I don't know why we have it in a kernel header, so remove it.
>
> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] tulip: dmfe: Remove old log spamming pr_debugs
From: Joe Perches @ 2011-07-18 18:05 UTC (permalink / raw)
To: David Miller; +Cc: jdelvare, grundler, netdev, linux-kernel
In-Reply-To: <20110718.104537.546991191560526229.davem@davemloft.net>
On Mon, 2011-07-18 at 10:45 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Mon, 18 Jul 2011 07:50:33 -0700
> > Commit 726b65ad444d ("tulip: Convert uses of KERN_DEBUG") enabled
> > some old previously inactive uses of pr_debug converted by
> > commit dde7c8ef1679 ("tulip/dmfe.c: Use dev_<level> and pr_<level>").
> > Remove these pr_debugs.
> > Signed-off-by: Joe Perches <joe@perches.com>
> Applied.
I believe this should go into current if you push
one more to Linus or maybe stable for 3.0.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Mimi Zohar @ 2011-07-18 18:03 UTC (permalink / raw)
To: Tetsuo Handa
Cc: linux-security-module, andriy.shevchenko, netdev, linux-kernel
In-Reply-To: <201107182148.AGD21306.FOLtJVMSOOFQHF@I-love.SAKURA.ne.jp>
On Mon, 2011-07-18 at 21:48 +0900, Tetsuo Handa wrote:
> Currently, security/keys/ is the only user of hex2bin().
> Should I keep hex2bin() unmodified in case of bad input?
> If so, I'd like to make it as hex2bin_safe().
> ----------------------------------------
> [PATCH] Add error check to hex2bin().
>
> Since converting 2 hexadecimal letters into a byte with error checks is
> commonly used, we can replace multiple hex_to_bin() calls with single hex2bin()
> call by changing hex2bin() to do error checks.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I=love.SAKURA.ne.jp>
> ---
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 953352a..186e9fc 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -374,7 +374,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
> }
>
> extern int hex_to_bin(char ch);
> -extern void hex2bin(u8 *dst, const char *src, size_t count);
> +extern bool hex2bin(u8 *dst, const char *src, size_t count);
>
> /*
> * General tracing related utility functions - trace_printk(),
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index f5fe6ba..1524002 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -38,14 +38,22 @@ EXPORT_SYMBOL(hex_to_bin);
> * @dst: binary result
> * @src: ascii hexadecimal string
> * @count: result length
> + *
> + * Returns true on success, false in case of bad input.
> */
> -void hex2bin(u8 *dst, const char *src, size_t count)
> +bool hex2bin(u8 *dst, const char *src, size_t count)
> {
> while (count--) {
> - *dst = hex_to_bin(*src++) << 4;
> - *dst += hex_to_bin(*src++);
> - dst++;
> + int c = hex_to_bin(*src++);
> + int d;
Missing blank line here.
> + if (c < 0)
> + return false;
> + d = hex_to_bin(*src++);
> + if (d < 0)
> + return false;
> + *dst++ = (c << 4) | d;
> }
> + return true;
> }
> EXPORT_SYMBOL(hex2bin);
We probably don't need to define a separate 'safe' function.
Instead of changing the existing code to short circuit out and return a
value, does only adding the return value work? Something like:
bool ret = true;
int c, d;
while (count--) {
c = hex_to_bin(*src++);
d = hex_to_bin(*src++);
*dst++ = (c << 4) | d;
if (c < 0 || d < 0)
ret = false;
}
return ret;
thanks,
Mimi
> In message "Re: [PATCH] net: can: remove custom hex_to_bin()",
> Andy Shevchenko wrote:
> > On Mon, 2011-07-18 at 20:41 +0900, Tetsuo Handa wrote:
> > > Andy Shevchenko wrote:
> > > > for (i = 0, dlc_pos++; i < cf.can_dlc; i++) {
> > > > -
> > > > - tmp = asc2nibble(sl->rbuff[dlc_pos++]);
> > > > - if (tmp > 0x0F)
> > > > + tmp = hex_to_bin(sl->rbuff[dlc_pos++]);
> > > > + if (tmp < 0)
> > > > return;
> > > > cf.data[i] = (tmp << 4);
> > > > - tmp = asc2nibble(sl->rbuff[dlc_pos++]);
> > > > - if (tmp > 0x0F)
> > > > + tmp = hex_to_bin(sl->rbuff[dlc_pos++]);
> > > > + if (tmp < 0)
> > > > return;
> > > > cf.data[i] |= tmp;
> > > > }
> > >
> > > What about changing
> > >
> > > void hex2bin(u8 *dst, const char *src, size_t count)
> > >
> > > to
> > >
> > > bool hex2bin(u8 *dst, const char *src, size_t count)
> > >
> > > in order to do error checks like
> > >
> > > bool hex2bin_with_validation(u8 *dst, const char *src, size_t count)
> > > {
> > > while (count--) {
> > > int c = hex_to_bin(*src++);
> > > int d;
> > > if (c < 0)
> > > return false;
> > > d = hex_to_bin(*src++)
> > > if (d < 0)
> > > return false;
> > > *dst++ = (c << 4) | d;
> > > }
> > > return true;
> > > }
> > >
> > > and use hex2bin() rather than hex_to_bin()?
> > Perhaps, good idea. Could you submit a patch?
> >
> > --
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Intel Finland Oy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2] connector: add an event for monitoring process tracers
From: Oleg Nesterov @ 2011-07-18 17:54 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: netdev, Evgeniy Polyakov, David S. Miller
In-Reply-To: <1310751918-31579-1-git-send-email-vzapolskiy@gmail.com>
On 07/15, Vladimir Zapolskiy wrote:
>
> Such an event allows to create a simple automated userspace mechanism
> to be aware about processes connecting to others, therefore predefined
> process policies can be applied to them if needed.
I'd wish I could understand this ;) IOW, I still do not understand why
this is useful, but this doesn't matter. Since Evgeniy acked this patch,
I'll apply it to ptrace tree.
Can't resist, a couple of very minor/cosmetics nits. Just because I am
blighter ;)
> +void proc_ptrace_connector(struct task_struct *task, int which_id);
"which_id" doesn't match "ptrace_id" used elsewhere. And PTRACE_ATTACH
instead of simple boolean looks as if you are going to add more ptrace
events, but I guess this won't happen.
> - if (!retval)
> + if (!retval) {
> wait_on_bit(&task->jobctl, JOBCTL_TRAPPING_BIT,
> ptrace_trapping_sleep_fn, TASK_UNINTERRUPTIBLE);
> + proc_ptrace_connector(task, PTRACE_ATTACH);
> + }
OK, but it is a bit strange we are waiting for STOPPED/TRACED transition
before we report PROC_EVENT_PTRACE. Perhaps it makes more sense to
call proc_ptrace_connector() first, this also decreases the probability
PTRACE_ATTACH will be reported after PROC_EVENT_EXIT.
But once again, this is very minor and cosmetic. I am going to apply
the patch as is unless you send v3 quickly.
Oleg.
^ permalink raw reply
* Re: [PATCH 2/2] stmmac: Allow SOCs to use Store forward mode eventhough tx_coe is 0. (V2)
From: David Miller @ 2011-07-18 17:47 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, srinivas.kandagatla
In-Reply-To: <1310972049-827-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 18 Jul 2011 08:54:09 +0200
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch adds new field 'force_sf_dma_mode' to plat_stmmacenet_data
> struct to allow users to specify if they want to use force store forward
> eventhough tx_coe is not available in hw.
> without this flag stmmac driver will use cut-thru mode not use
> store-forward mode.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] stmmac: add memory barriers at appropriate places
From: David Miller @ 2011-07-18 17:47 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, shiraz.hashim
In-Reply-To: <1310972049-827-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 18 Jul 2011 08:54:08 +0200
> From: Shiraz Hashim <shiraz.hashim@st.com>
>
> This patch, provided by ST SPEAr developers,
> has fixed a problem raised on ARM CA9 where
> happened that the dma_transmission was enabled before
> the dma descriptors were properly filled. To guarantee this
> data memory barriers have been explicity used in the driver.
>
> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tulip: dmfe: Remove old log spamming pr_debugs
From: David Miller @ 2011-07-18 17:45 UTC (permalink / raw)
To: joe; +Cc: jdelvare, grundler, netdev, linux-kernel
In-Reply-To: <0a5f6c4c4c948dd5ff827bb5c5517294c9410bfc.1311000440.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 18 Jul 2011 07:50:33 -0700
> Commit 726b65ad444d ("tulip: Convert uses of KERN_DEBUG") enabled
> some old previously inactive uses of pr_debug converted by
> commit dde7c8ef1679 ("tulip/dmfe.c: Use dev_<level> and pr_<level>").
>
> Remove these pr_debugs.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCHv11] vhost: vhost TX zero-copy support
From: David Miller @ 2011-07-18 17:43 UTC (permalink / raw)
To: mst; +Cc: mashirle, kvm, virtualization, netdev, linux-kernel, jj
In-Reply-To: <20110718134846.GA7107@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 18 Jul 2011 16:48:46 +0300
>>From: Shirley Ma <mashirle@us.ibm.com>
>
> This adds experimental zero copy support in vhost-net,
> disabled by default. To enable, set
> experimental_zcopytx module option to 1.
>
> This patch maintains the outstanding userspace buffers in the
> sequence it is delivered to vhost. The outstanding userspace buffers
> will be marked as done once the lower device buffers DMA has finished.
> This is monitored through last reference of kfree_skb callback. Two
> buffer indices are used for this purpose.
>
> The vhost-net device passes the userspace buffers info to lower device
> skb through message control. DMA done status check and guest
> notification are handled by handle_tx: in the worst case is all buffers
> in the vq are in pending/done status, so we need to notify guest to
> release DMA done buffers first before we get any new buffers from the
> vq.
>
> One known problem is that if the guest stops submitting
> buffers, buffers might never get used until some
> further action, e.g. device reset. This does not
> seem to affect linux guests.
>
> Signed-off-by: Shirley <xma@us.ibm.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: save cpu cycles from check_leaf()
From: David Miller @ 2011-07-18 17:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1310994993.5756.27.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 18 Jul 2011 15:16:33 +0200
> [PATCH net-next-2.6] ipv4: save cpu cycles from check_leaf()
>
> Compiler is not smart enough to avoid double BSWAP instructions in
> ntohl(inet_make_mask(plen)).
>
> Lets cache this value in struct leaf_info, (fill a hole on 64bit arches)
>
> With route cache disabled, this saves ~2% of cpu in udpflood bench on
> x86_64 machine.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] connector: add an event for monitoring process tracers
From: Oleg Nesterov @ 2011-07-18 17:14 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Vladimir Zapolskiy, netdev, David S. Miller
In-Reply-To: <20110718161558.GA366@ioremap.net>
On 07/18, Evgeniy Polyakov wrote:
>
> Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
OK, thanks, I am going to apply it then...
While we are here, a couple of questions. I've looked at connector
briefly, and some things do not look exactly right to me.
proc_fork_connector() reads task->real_parent lockless. In theory
this is not safe with CLONE_PTHREAD or CLONE_PARENT. Yes, this is
only theoretical, but afaics we need something like
--- x/drivers/connector/cn_proc.c
+++ x/drivers/connector/cn_proc.c
@@ -55,6 +55,7 @@ void proc_fork_connector(struct task_str
struct proc_event *ev;
__u8 buffer[CN_PROC_MSG_SIZE];
struct timespec ts;
+ struct task_struct *parent;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
@@ -65,8 +66,11 @@ void proc_fork_connector(struct task_str
ktime_get_ts(&ts); /* get high res monotonic timestamp */
put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
ev->what = PROC_EVENT_FORK;
- ev->event_data.fork.parent_pid = task->real_parent->pid;
- ev->event_data.fork.parent_tgid = task->real_parent->tgid;
+ rcu_read_lock();
+ parent = rcu_dereference(task->real_parent);
+ ev->event_data.fork.parent_pid = parent->pid;
+ ev->event_data.fork.parent_tgid = parent->tgid;
+ rcu_read_unlock();
ev->event_data.fork.child_pid = task->pid;
ev->event_data.fork.child_tgid = task->tgid;
Otherwise ->real_parent can point to the freed/reused and may be
unmapped memory.
But the actual question is, the usage of proc_exec_connector()
looks "obviously wrong", no? Don't we need
--- x/fs/exec.c
+++ x/fs/exec.c
@@ -1380,15 +1380,16 @@ int search_binary_handler(struct linux_b
*/
bprm->recursion_depth = depth;
if (retval >= 0) {
- if (depth == 0)
+ if (depth == 0) {
tracehook_report_exec(fmt, bprm, regs);
+ proc_exec_connector(current);
+ }
put_binfmt(fmt);
allow_write_access(bprm->file);
if (bprm->file)
fput(bprm->file);
bprm->file = NULL;
current->did_exec = 1;
- proc_exec_connector(current);
return retval;
}
read_lock(&binfmt_lock);
? Or do we really want to call proc_exec_connector() twice or
more in "#!whatever" case?
Oleg.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox