* 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] 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: 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] 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: [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: [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: [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: [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: 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: 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 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: [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] 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] 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
* [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
* 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
* 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
* Re: [PATCH] Add error check to hex2bin().
From: Andy Shevchenko @ 2011-07-18 21:18 UTC (permalink / raw)
To: Geert Uytterhoeven, Mimi Zohar
Cc: Tetsuo Handa, linux-security-module, andriy.shevchenko, netdev,
linux-kernel
In-Reply-To: <CAMuHMdVxR7AC7H_Yys8SiaGqM2JsNXLsRpujqojMYd_CXWxcAw@mail.gmail.com>
On Mon, Jul 18, 2011 at 11:49 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> 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.
If I remember correctly it used to be src as return value in some
version of that patch. I don't know the details of that interim
solution. My current opinion is to return boolean and make an
additional parameter to return src value. However, it could make this
simple function fat.
P.S. Take into account that the user of it is only one so far, I would
like to hear a Mimi's opinion.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Mimi Zohar @ 2011-07-18 21:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tetsuo Handa, linux-security-module, andriy.shevchenko, netdev,
linux-kernel
In-Reply-To: <CAHp75VeQSSoW6u-LGdhoNf_mh7WP5076bpzygf710Ro8aj1+Cg@mail.gmail.com>
On Mon, 2011-07-18 at 22:44 +0300, Andy Shevchenko wrote:
> 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?
Someone with more experience than me needs to responds.
> > I'll update trusted/encrypted keys to check the return
> > code.
> Actually another question shall we add __must_check to the prototype or not?
Probably a good idea.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Mimi Zohar @ 2011-07-18 21:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Tetsuo Handa, linux-security-module,
andriy.shevchenko, netdev, linux-kernel
In-Reply-To: <CAHp75VdTiMtmXdVSMq=6bAH2+rmSBHPPE9hQOLQN+Y3qPBEVFg@mail.gmail.com>
On Tue, 2011-07-19 at 00:18 +0300, Andy Shevchenko wrote:
> On Mon, Jul 18, 2011 at 11:49 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > 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.
> If I remember correctly it used to be src as return value in some
> version of that patch. I don't know the details of that interim
> solution. My current opinion is to return boolean and make an
> additional parameter to return src value. However, it could make this
> simple function fat.
> P.S. Take into account that the user of it is only one so far, I would
> like to hear a Mimi's opinion.
Trusted/encrypted keys are not in a critical code path. They're used for
loading/storing key blobs from userspace. Once you change the API, short
circuiting out and adding an error return, from a trusted/encrypted key
perspective, it doesn't make a difference.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH net-next] bnx2: Close device if tx_timeout reset fails
From: Flavio Leitner @ 2011-07-18 23:24 UTC (permalink / raw)
To: Flavio Leitner; +Cc: Michael Chan, davem, netdev
In-Reply-To: <20110716001606.528a55c8@asterix.rh>
On Sat, 16 Jul 2011 00:16:06 -0300
Flavio Leitner <fbl@redhat.com> wrote:
> On Fri, 15 Jul 2011 09:53:58 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
> ...
> > To fix it, we call dev_close() if bnx2_init_nic() fails.
> > One minor wrinkle to deal with is the cancel_work_sync()
> > call in bnx2_close() to cancel bnx2_reset_task(). The
> > call will wait forever because it is trying to cancel
> > itself and the workqueue will be stuck.
> >
> > Since bnx2_reset_task() holds the rtnl_lock() and checks
> > for netif_running() before proceeding, there is no need
> > to cancel bnx2_reset_task() in bnx2_close() even if
> > bnx2_close() and bnx2_reset_task() are running concurrently.
> > The rtnl_lock() serializes the 2 calls.
> >
> > We need to move the cancel_work_sync() call to
> > bnx2_remove_one() to make sure it is canceled before freeing
> > the netdev struct.
>
> It looks good. I'm traveling now, so I'll test this on Monday.
>
I have patched the kernel to inject the error and it works as
expected.
thanks,
fbl
^ permalink raw reply
* Re: software iwarp stack update
From: Roland Dreier @ 2011-07-18 23:45 UTC (permalink / raw)
To: Bart Van Assche
Cc: Bernard Metzler, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <BANLkTi=L057TZug2=nrFZTYdNoHLMvmBRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> There seems to be disagreement about whether to return 0, -ENOSYS or
> -EOPNOTSUPP for not supported functionality. Does the patch below make sense ?
> Note: I don't have all the hardware necessary to test the patch below.
This makes sense to me, so I went ahead and applied it for 3.1 (minus
the siw part, of course).
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 00/45] Update bna driver version to 3.0.2.0
From: Rasesh Mody @ 2011-07-19 0:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20110718.012639.1253140864720328605.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, July 18, 2011 1:27 AM
>
>This is too many patche at once.
>
>You need to submit patches more often, and in significantly smaller
>sets at a time.
David,
This update to the BNA driver (release 3.0) is enabling new hardware with various virtualization and other capabilities e.g. new 1860 SRIOV capable Fabric Adapter (new ASIC), vNIC (PF based virtualization), architectural framework for SR-IOV, Multi-Tx priority queue support and iSCSI over DCB.
The driver had to go through significant changes to enable these capabilities thus resulting in large delta.
We explored options to submit smaller incremental patches in last few months but quickly ran into following issues ...
- The driver was not functional between patches because of large developmental changes
- There were iterative changes to many areas of code and that was resulting in many unnecessary patches.
We wanted to avoid submitting developing code that could break upstream driver due to partial changes.
Hence we ended up submitting this driver update patch with consolidated changes after elaborate QA testing.
We understand that it is still big and can think of following options to address the concern:
1. Break this submission into 3 batches and split it into: 2.3 fixes, new features (which is still a big patch set - due to all the code reorganization), and bug fixes and cleanup.
OR
2. Submit patches as a new driver and would need your support in replacing the existing upstream BNA driver with this one.
Please suggest on the next steps.
Thanks,
Rasesh
^ permalink raw reply
* Re: [PATCH] Add error check to hex2bin().
From: Mimi Zohar @ 2011-07-19 1:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Tetsuo Handa, linux-security-module,
andriy.shevchenko, netdev, linux-kernel
In-Reply-To: <CAHp75VdTiMtmXdVSMq=6bAH2+rmSBHPPE9hQOLQN+Y3qPBEVFg@mail.gmail.com>
(sorry for re-posting, but this doesn't seem to have been sent.)
On Tue, 2011-07-19 at 00:18 +0300, Andy Shevchenko wrote:
> On Mon, Jul 18, 2011 at 11:49 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > 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.
> If I remember correctly it used to be src as return value in some
> version of that patch. I don't know the details of that interim
> solution. My current opinion is to return boolean and make an
> additional parameter to return src value. However, it could make this
> simple function fat.
> P.S. Take into account that the user of it is only one so far, I would
> like to hear a Mimi's opinion.
>
Trusted/encrypted keys are not in a critical code path. They're used for
loading/storing key blobs from userspace. Once you change the API, short
circuiting out and adding an error return, from a trusted/encrypted key
perspective, it doesn't make a difference.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH] net: filter: BPF 'JIT' compiler for PPC64
From: Matt Evans @ 2011-07-19 1:21 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, linuxppc-dev
In-Reply-To: <20110718.124248.1462465498024218250.davem@davemloft.net>
On 19/07/11 05:42, David Miller wrote:
> 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, but no worries; I will send a v2 in a sec. Eric's comments are spot-on,
and there are a couple of other areas that the brainfart should really be
polished out of, too. :-)
Cheers,
Matt
^ 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