* Re: fanotify as syscalls
From: Davide Libenzi @ 2009-09-22 16:04 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Jamie Lokier, Eric Paris, Linus Torvalds, Evgeniy Polyakov,
David Miller, Linux Kernel Mailing List, linux-fsdevel, netdev,
viro, alan, hch
In-Reply-To: <200909221731.34717.agruen@suse.de>
On Tue, 22 Sep 2009, Andreas Gruenbacher wrote:
> The fatal flaw of syscall interception is race conditions: you look up a
> pathname in your interception layer; then when you call into the proper
> syscall, the kernel again looks up the same pathname. There is no way to
> guarantee that you end up at the same object in both lookups. The security
> and fsnotify hooks are placed in the appropriate spots to avoid exactly that.
Fatal? You mean, for this corner case that the anti-malware industry lived
with for so much time (in Linux and Windows), you're prepared in pushing
all the logic that is currently implemented into their modules, into the
kernel?
This includes process whitelisting, path whitelisting, caches, userspace
access API definition, and so on? On top of providing a generally more
limited interception.
Why don't we instead offer a lower and broader level of interception,
letting the users decide if such fatal flaw needs to be addressed or
not, in their modules?
They get a broader inteception layer, with the option to decide if or if
not address certain scenarios, and we get less code inside the kernel.
A win/win situation, if you ask me.
- Davide
^ permalink raw reply
* Re: fanotify as syscalls
From: Eric Paris @ 2009-09-22 16:11 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Davide Libenzi, Jamie Lokier, Linus Torvalds, Evgeniy Polyakov,
David Miller, Linux Kernel Mailing List, linux-fsdevel, netdev,
viro, alan, hch
In-Reply-To: <200909221731.34717.agruen@suse.de>
On Tue, 2009-09-22 at 17:31 +0200, Andreas Gruenbacher wrote:
> On Tuesday, 22 September 2009 16:51:39 Davide Libenzi wrote:
> > On Tue, 22 Sep 2009, Jamie Lokier wrote:
> > > I don't mind at all if fanotify is replaced by a general purpose "take
> > > over the system call table" solution ...
> >
> > That was not what I meant ;)
> > You'd register/unregister as syscall interceptor, receiving syscall number
> > and parameters, you'd be able to return status/error codes directly, and
> > you'd have the ability to eventually change the parameters. All this
> > should be pretty trivial code, and at the same time give full syscall
> > visibility to the modules.
>
> The fatal flaw of syscall interception is race conditions:
That's not the fatal flaw. The fatal flaw is that I am not going to
write 90% of a rootkit and make it easy to use. Not going to happen.
There's a reason we went to the trouble to mark the syscall call RO, we
don't export it, and we don't want people playing with it. It clearly
would have been the quickest, easiest, and fastest way to make
anti-virus companies happy, but it doesn't really solve a good problem
and it leaves all of us in a worse position than we are today. Easy !=
Good.
-Eric
^ permalink raw reply
* Re: fanotify as syscalls
From: Jamie Lokier @ 2009-09-22 16:27 UTC (permalink / raw)
To: Eric Paris
Cc: Andreas Gruenbacher, Davide Libenzi, Linus Torvalds,
Evgeniy Polyakov, David Miller, Linux Kernel Mailing List,
linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <1253635918.2747.5.camel@dhcp231-106.rdu.redhat.com>
Eric Paris wrote:
> That's not the fatal flaw. The fatal flaw is that I am not going to
> write 90% of a rootkit and make it easy to use.
I hate to point out the obvious, but fanotify's ability to intercept
every file access and rewrite the file before the access proceeds is
also 90% of a rootkit...
But fortunately both fanotify and syscall rewriting require root in
the first place.
I think that makes the rootkit argument moot. As long as fanotify
doesn't have a non-root flavour... which really would be handy for
rootkits :-)
> Easy != Good.
I agree.
-- Jamie
^ permalink raw reply
* Re: [PATCH] skge: request IRQ on activating the interface
From: Stephen Hemminger @ 2009-09-22 16:28 UTC (permalink / raw)
To: Michal Schmidt; +Cc: netdev
In-Reply-To: <20090922120127.14242.71353.stgit@localhost.localdomain>
On Tue, 22 Sep 2009 14:01:31 +0200
Michal Schmidt <mschmidt@redhat.com> wrote:
> skge requests IRQ in its probe function. This causes a problem in
> the following real-life scenario with two different NICs in the machine:
>
> 1. modprobe skge
> The card is detected as eth0 and requests IRQ 17. Directory
> /proc/irq/17/eth0 is created.
> 2. There is an udev rule which says this interface should be called
> eth1, so udev renames eth0 -> eth1.
> 3. modprobe 8139too
> The Realtek card is detected as eth0. It will be using IRQ 17 too.
> 4. ip link set eth0 up
> Now 8139too requests IRQ 17.
>
> The result is:
> WARNING: at fs/proc/generic.c:590 proc_register ...
> proc_dir_entry '17/eth0' already registered
> ...
>
> And "ls /proc/irq/17" shows two subdirectories, both called eth0.
>
> Fix it by requesting the IRQ in skge when the interface is activated.
> This works, because interfaces can be renamed only while they are down.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
No. because two port cards have a single IRQ for both ports.
The choice of ethX in irq name was done because irqbalance looks for this.
Probably better to change skge/sky2 and other devices with same issue
to use skge-N ... for request_irq, and teach irqbalance how to do deal
with it.
^ permalink raw reply
* Re: [RFC] Virtual Machine Device Queues(VMDq) support on KVM
From: Stephen Hemminger @ 2009-09-22 16:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael S. Tsirkin, Chris Wright, Rusty Russell, virtualization,
Xin, Xiaohui, kvm@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
mingo@elte.hu, akpm@linux-foundation.org
In-Reply-To: <200909221350.54847.arnd@arndb.de>
On Tue, 22 Sep 2009 13:50:54 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 22 September 2009, Michael S. Tsirkin wrote:
> > > > More importantly, when virtualizations is used with multi-queue
> > > > NIC's the virtio-net NIC is a single CPU bottleneck. The virtio-net
> > > > NIC should preserve the parallelism (lock free) using multiple
> > > > receive/transmit queues. The number of queues should equal the
> > > > number of CPUs.
> > >
> > > Yup, multiqueue virtio is on todo list ;-)
> > >
> >
> > Note we'll need multiqueue tap for that to help.
>
> My idea for that was to open multiple file descriptors to the same
> macvtap device and let the kernel figure out the right thing to
> do with that. You can do the same with raw packed sockets in case
> of vhost_net, but I wouldn't want to add more complexity to the
> tun/tap driver for this.
>
> Arnd <><
Or get tap out of the way entirely. The packets should not have
to go out to user space at all (see veth)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: Grant Likely @ 2009-09-22 16:53 UTC (permalink / raw)
To: John Linn; +Cc: Michal Simek, sadanand.mutyala, netdev, linuxppc-dev, davem
In-Reply-To: <fac40d47-5b19-4225-9fee-f7a058851fc0@SG2EHSMHS017.ehs.local>
On Tue, Sep 22, 2009 at 8:24 AM, John Linn <john.linn@xilinx.com> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> You can't ping the board or connect to it unless you send
> any packet out from board.
>
> Tested-by: John Williams <john.williams@petalogix.com>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> Acked-by: John Linn <john.linn@xilinx.com>
John, Since this patch is being *sent* by you, then you should use a
"signed-off-by" tag instead because it actually passed through your
hands.
Oh, and:
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/net/xilinx_emaclite.c | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index dc22782..83a044d 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -134,18 +134,15 @@ static void xemaclite_enable_interrupts(struct net_local *drvdata)
> }
>
> /* Enable the Rx interrupts for the first buffer */
> - reg_data = in_be32(drvdata->base_addr + XEL_RSR_OFFSET);
> out_be32(drvdata->base_addr + XEL_RSR_OFFSET,
> - reg_data | XEL_RSR_RECV_IE_MASK);
> + XEL_RSR_RECV_IE_MASK);
>
> /* Enable the Rx interrupts for the second Buffer if
> * configured in HW */
> if (drvdata->rx_ping_pong != 0) {
> - reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> - XEL_RSR_OFFSET);
> out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> XEL_RSR_OFFSET,
> - reg_data | XEL_RSR_RECV_IE_MASK);
> + XEL_RSR_RECV_IE_MASK);
> }
>
> /* Enable the Global Interrupt Enable */
> --
> 1.6.2.1
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: John Linn @ 2009-09-22 16:56 UTC (permalink / raw)
To: Grant Likely; +Cc: Michal Simek, linuxppc-dev, netdev, Sadanand Mutyala, davem
In-Reply-To: <fa686aa40909220953g708445d9s9c25bd839cc2dd2e@mail.gmail.com>
Thanks Grant, I wondered about that myself.
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> Sent: Tuesday, September 22, 2009 10:54 AM
> To: John Linn
> Cc: netdev@vger.kernel.org; davem@davemloft.net; linuxppc-dev@ozlabs.org; jwboyer@linux.vnet.ibm.com;
> Sadanand Mutyala; Michal Simek
> Subject: Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
>
> On Tue, Sep 22, 2009 at 8:24 AM, John Linn <john.linn@xilinx.com> wrote:
> > From: Michal Simek <monstr@monstr.eu>
> >
> > You can't ping the board or connect to it unless you send
> > any packet out from board.
> >
> > Tested-by: John Williams <john.williams@petalogix.com>
> > Signed-off-by: Michal Simek <monstr@monstr.eu>
> > Acked-by: John Linn <john.linn@xilinx.com>
>
> John, Since this patch is being *sent* by you, then you should use a
> "signed-off-by" tag instead because it actually passed through your
> hands.
>
> Oh, and:
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> > ---
> > drivers/net/xilinx_emaclite.c | 7 ++-----
> > 1 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> > index dc22782..83a044d 100644
> > --- a/drivers/net/xilinx_emaclite.c
> > +++ b/drivers/net/xilinx_emaclite.c
> > @@ -134,18 +134,15 @@ static void xemaclite_enable_interrupts(struct net_local *drvdata)
> > }
> >
> > /* Enable the Rx interrupts for the first buffer */
> > - reg_data = in_be32(drvdata->base_addr + XEL_RSR_OFFSET);
> > out_be32(drvdata->base_addr + XEL_RSR_OFFSET,
> > - reg_data | XEL_RSR_RECV_IE_MASK);
> > + XEL_RSR_RECV_IE_MASK);
> >
> > /* Enable the Rx interrupts for the second Buffer if
> > * configured in HW */
> > if (drvdata->rx_ping_pong != 0) {
> > - reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> > - XEL_RSR_OFFSET);
> > out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> > XEL_RSR_OFFSET,
> > - reg_data | XEL_RSR_RECV_IE_MASK);
> > + XEL_RSR_RECV_IE_MASK);
> > }
> >
> > /* Enable the Global Interrupt Enable */
> > --
> > 1.6.2.1
> >
> >
> >
> > This email and any attachments are intended for the sole use of the named recipient(s) and
> contain(s) confidential information that may be proprietary, privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any attachments immediately.
> >
> >
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [RFC] Virtual Machine Device Queues(VMDq) support on KVM
From: Arnd Bergmann @ 2009-09-22 18:34 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Michael S. Tsirkin, Chris Wright, Rusty Russell, virtualization,
Xin, Xiaohui, kvm@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
mingo@elte.hu, akpm@linux-foundation.org
In-Reply-To: <20090922092957.17e68cbc@s6510>
On Tuesday 22 September 2009, Stephen Hemminger wrote:
> > My idea for that was to open multiple file descriptors to the same
> > macvtap device and let the kernel figure out the right thing to
> > do with that. You can do the same with raw packed sockets in case
> > of vhost_net, but I wouldn't want to add more complexity to the
> > tun/tap driver for this.
> >
> Or get tap out of the way entirely. The packets should not have
> to go out to user space at all (see veth)
How does veth relate to that, do you mean vhost_net? With vhost_net,
you could still open multiple sockets, only the access is in the kernel.
Obviously, once it all is in the kernel, that could be done under the
covers, but I think it would be cleaner to treat vhost_net purely as
a way to bypass the syscalls for user space, with as little as possible
visible impact otherwise.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] ipv4: fix do_ip_setsockopt optlen check for IP_MULTICAST_IF
From: David Miller @ 2009-09-22 20:38 UTC (permalink / raw)
To: shanwei
Cc: dfeng, kaber, yoshfuji, jmorris, pekkas, kuznet, netdev,
linux-kernel
In-Reply-To: <4AB1FE2A.1060906@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Thu, 17 Sep 2009 17:15:22 +0800
> Xiaotian Feng wrote, at 09/17/2009 01:19 PM:
>> Due to man page of setsockopt, if optlen is not valid, kernel should return
>> -EINVAL. But a simple testcase as following, errno is 0, which means setsockopt
>> is successful.
>>
>> addr.s_addr = inet_addr("192.1.2.3");
>> setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, 1);
>> printf("errno is %d\n", errno);
>>
>> This patch fixes the optlen check part, with the patch, we got errno EINVAL.
>>
>
> I also think it's a bug, the freebsd also does the optlen check.
> But the style should be coincident with other option: firstly check the
> availability of optlen, then copy option value from user and deal with it.
>
> How about this one:
This definitely is better and cleaner, but please don't post such
things without proper signoffs and commit messages because now
I have to ask you to do that instead of me just applying your
patch :-/
^ permalink raw reply
* Re: Resend: [PATCH] TCP Early Retransmit: reduce required dupacks for triggering fast retrans
From: David Miller @ 2009-09-22 20:40 UTC (permalink / raw)
To: Christian.Samsel; +Cc: netdev
In-Reply-To: <fab65f44d75b.4ab891f2@rwth-aachen.de>
From: Christian Samsel <Christian.Samsel@rwth-aachen.de>
Date: Tue, 22 Sep 2009 08:59:30 +0000 (GMT)
> This patch implements draft-ietf-tcpm-early-rexmt. The early retransmit
> mechanism allows the transport to reduce the number of duplicate
> acknowledgments required to trigger a fast retransmission in case we
> don't expect enough dupacks, (e.g. because there are not enough
> packets inflight and nothing to send). This allows the transport to use
> fast retransmit to recover packet losses that would otherwise require
> a lengthy retransmission timeout.
>
> See: http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
>
> Signed-off-by: Christian Samsel <christian.samsel@rwth-aachen.de>
What changed from the previous version?
Nothing?
If you're resending just to get our attention, please don't do that.
It only creates confusion and makes it take longer for your patch to
get reviewed and applied.
^ permalink raw reply
* Re: Resend: [PATCH] TCP Early Retransmit: reduce required dupacks for triggering fast retrans
From: David Miller @ 2009-09-22 20:42 UTC (permalink / raw)
To: Christian.Samsel; +Cc: netdev
In-Reply-To: <20090922.134021.82409230.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 22 Sep 2009 13:40:21 -0700 (PDT)
> If you're resending just to get our attention, please don't do that.
>
> It only creates confusion and makes it take longer for your patch to
> get reviewed and applied.
Also I just checked and this patch is severely whitespace damaged
and we wouldn't be able to use it anyways. Your email client
truncated tabs and changed them into spaces, amongst other things.
You will need to fix this up before anyone can take your changes
seriously.
Thanks.
^ permalink raw reply
* Re: [PATCH][RESEND 2] IPv6: 6rd tunnel mode
From: David Miller @ 2009-09-22 20:45 UTC (permalink / raw)
To: acassen; +Cc: netdev
In-Reply-To: <20090922085105.GA20906@lnxos.staff.proxad.net>
From: Alexandre Cassen <acassen@freebox.fr>
Date: Tue, 22 Sep 2009 10:51:05 +0200
> IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
> to enable a service provider to rapidly deploy IPv6 unicast service
> to IPv4 sites to which it provides customer premise equipment. Like
I've read your explanation, but it is still presumptious to mention
an RFC number before it isn't really released yet.
Mention the drafts only, and when it achieves true RFC status
you can send another patch updating those references in the
code comments.
^ permalink raw reply
* Re: [PATCH][RESEND 2] IPv6: 6rd tunnel mode
From: Alexandre Cassen @ 2009-09-22 20:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090922.134543.158902222.davem@davemloft.net>
On Tue, 22 Sep 2009, David Miller wrote:
> From: Alexandre Cassen <acassen@freebox.fr>
> Date: Tue, 22 Sep 2009 10:51:05 +0200
>
>> IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
>> to enable a service provider to rapidly deploy IPv6 unicast service
>> to IPv4 sites to which it provides customer premise equipment. Like
>
> I've read your explanation, but it is still presumptious to mention
> an RFC number before it isn't really released yet.
>
> Mention the drafts only, and when it achieves true RFC status
> you can send another patch updating those references in the
> code comments.
ack. will fix this and resend.
^ permalink raw reply
* Re: fanotify as syscalls
From: Eric Paris @ 2009-09-22 21:06 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Jamie Lokier, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <200909212204.51077.agruen@suse.de>
On Mon, 2009-09-21 at 22:04 +0200, Andreas Gruenbacher wrote:
> On Saturday, 19 September 2009 5:04:31 Eric Paris wrote:
> > Let me start by saying I am agreeing I should pursue subtree
> > notification. It's what I think everyone really wants. It's a great
> > idea, and I think you might have a simple way to get close. Clearly
> > these are avenues I'm willing and hoping to pursue. Also I say it
> > again, I believe the interface as proposed (except maybe some of my
> > exclusion stuff) is flexible enough to implement any of these ideas.
> > Does anyone disagree?
>
> It does seem flexible enough. However, the current interface assumes "global"
> listeners (the mask argument of fanotify_init):
>
> int fanotify_init(int flags, int f_flags, __u64 mask,
> unsigned int priority);
>
> Once subtree support is added, this parameter becomes obsolete. That's pretty
> broken for a syscall yet to be introduced.
Absolutely not obsolete. Subtree notification cannot do fscking all
notification.
> > BUT to solve one of the main problems fanotify is intending to solve it
> > needs a way to be the 'fscking all notifier.' It needs to be the whole
> > damn system.
>
> Think of a system after boot, with a single global namespace. Whatever you
> access by filename is reachable from the namespace root. At this point,
> nothing more global exists. A listener can watch the mount points of
> interest, and everything's fine.
this is true, if there is only one namespace subtree notification works
the same as global notification.
> What's a bit more tricky is to ensure that this listener will continue to
> receive all events from whatever else is mounted anywhere, irrespective of
> namespaces. I think we can get there.
Lets say I want the subtree under / to get every event on the system. A
process comes along and clones the namespace. Then lets say that
process mounts something inside his new namespace. There is absolutely
no path between my / and that new mount. How can subtree checking
possibly find and indicate it wants notification about this mount? I
don't see how subtree checking could do it. There can be completely
disjoint trees with no overlap.
mount -t tmpfs none /to_umount
clone namespace
mount -t tmpfs none /to_umount/private
pivot_root /tmp_umount/private
Something else umounts /to_umount
That process is in an completely detached namespace? right?
Heck, there could be operations on files that aren't in ANY namespace.
a = open(/path/to/dir/);
umount -l /path/to/
openat(a, "filename");
I don't see how subtree notification can possibly solve the global
notification problem.
I've been thinking that checking CAP_SYS_RAWIO as well as CAP_SYS_ADMIN
might be reasonable when trying to use a global listener. If you can
CAP_SYS_RAWIO I sorta feel like you can break out of a namespace anyway,
right?
-Eric
^ permalink raw reply
* Re: [PATCH 1/2] netxen: fix minor tx timeout bug
From: David Miller @ 2009-09-22 21:14 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1253510439-28464-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 20 Sep 2009 22:20:38 -0700
> Fix minor bug in netdev tx timeout handling which could
> always lead to firmware reset instead of pci function reset.
>
> netxen_nic_reset_context() requires __NX_RESETTING bit
> cleared.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] netxen: fix firmware init after resume
From: David Miller @ 2009-09-22 21:14 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1253510439-28464-2-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 20 Sep 2009 22:20:39 -0700
> After successful firmware init, return instead of
> falling to error path (leading to detach) after
> resuming to D0 state. This was broken in recent
> firmware reset rehaul.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [RFC][PATCH] pcmcia: pcnet_cs.c removing useless condition
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: jaswinder; +Cc: jeff, netdev, linux-pcmcia, linux
In-Reply-To: <1252782529.3687.26.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 13 Sep 2009 00:38:49 +0530
> [This is untested]
>
> 'if (i < NR_INFO)' will only true if we breaks from 'for (i = 0; i < NR_INFO; i++)'
> So removing useless 'if (i < NR_INFO)'
>
> This also fixed following compilation warning :
>
> CC [M] drivers/net/pcmcia/pcnet_cs.o
> drivers/net/pcmcia/pcnet_cs.c: In function ‘get_hwinfo’:
> drivers/net/pcmcia/pcnet_cs.c:321: warning: ‘base’ may be used uninitialized in this function
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Looks good to me, applied.
^ permalink raw reply
* Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: John.Linn; +Cc: grant.likely, netdev, linuxppc-dev, jwboyer, sadanan, monstr
In-Reply-To: <20090922165612.584554A8052@mail195-sin.bigfish.com>
From: John Linn <John.Linn@xilinx.com>
Date: Tue, 22 Sep 2009 10:56:27 -0600
> Thanks Grant, I wondered about that myself.
I've applied this patch, thanks.
^ permalink raw reply
* Re: [PATCH] lib/vsprintf.c: Avoid possible unaligned accesses in %pI6c
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: joe; +Cc: netdev, me
In-Reply-To: <1253315046.2543.475.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 18 Sep 2009 16:04:06 -0700
> Jens Rosenboom noticed that a possibly unaligned const char*
> is cast to a const struct in6_addr *.
>
> Avoid this at the cost of a struct in6_addr copy on the stack.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] smsc95xx: fix transmission where ZLP is expected
From: David Miller @ 2009-09-22 21:19 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev, ian.saturley, vlad.lyalikov
In-Reply-To: <1253628027-2704-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Tue, 22 Sep 2009 15:00:27 +0100
> Usbnet framework assumes USB hardware doesn't handle zero length
> packets, but SMSC LAN95xx requires these to be sent for correct
> operation.
>
> This patch fixes an easily reproducible tx lockup when sending a frame
> that results in exactly 512 bytes in a USB transmission (e.g. a UDP
> frame with 458 data bytes, due to IP headers and our USB headers). It
> adds an extra flag to usbnet for the hardware driver to indicate that
> it can handle and requires the zero length packets.
>
> This patch should not affect other usbnet users, please also consider
> for -stable.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] smsc95xx: add additional USB product IDs
From: David Miller @ 2009-09-22 21:20 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev, ian.saturley, vlad.lyalikov
In-Reply-To: <1253632382-18458-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Tue, 22 Sep 2009 16:13:02 +0100
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/5] drivers/net: remove duplicate structure field initialization
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0909192148180.27171@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 19 Sep 2009 21:48:41 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> The definitions of vnet_ops and ehea_netdev_ops have initializations of a
> local function and eth_change_mtu for their respective ndo_change_mtu
> fields. This change uses only the local function.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: Set SKY2_HW_RAM_BUFFER in sky2_init
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: mikem; +Cc: shemminger, netdev
In-Reply-To: <4AB788F4.90503@ring3k.org>
From: Mike McCormack <mikem@ring3k.org>
Date: Mon, 21 Sep 2009 23:08:52 +0900
> The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
> before being set later in sky2_up().
>
> Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
> should avoid this problem recurring.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net-next]atl1c:remove compiling warning
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: jie.yang; +Cc: akpm, jirislaby, jcliburn, netdev, linux-kernel
In-Reply-To: <12535093181069-git-send-email-jie.yang@atheros.com>
From: <jie.yang@atheros.com>
Date: Mon, 21 Sep 2009 13:01:58 +0800
> Set wol_ctrl_data to value 0, to remove compiling warning.
>
> Signed-off-by: Jie Yang <jie.yang@atheros.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] pktgen: check for link down
From: David Miller @ 2009-09-22 21:24 UTC (permalink / raw)
To: shemminger; +Cc: robert, jdb, netdev
In-Reply-To: <20090921225543.44d2d5c4@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 21 Sep 2009 22:55:43 -0700
> You can hold off on these two patches, I have better version
> which fixes some other issues. But testing time is limited this week.
Ok
^ 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