* Re: Steps to integrate new 40G Network driver to the kernel tree
From: Joyce Yu - System Software @ 2011-06-21 23:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <4E012D80.4090907@oracle.com>
Since it is a new driver, shall I follow the "Submitting Drivers for the
Linux Kernel" Doc? The driver is ready and passed all our QA cycles. I
have three source base, one is for 2.6.16 and 2.6.18 (for RHL 5.X and
SLES 10 SP3) , one is for 2.6.32 (For RHL 6.X, SLES11SP1), one for
2.6.27 (For SLES11). Can it be integrated to the 2.6.18 and 2.6.32 tree?
or it has to be in the latest 2.6.39 or later?
Thanks,
Joyce
^ permalink raw reply
* Re: Steps to integrate new 40G Network driver to the kernel tree
From: Stephen Hemminger @ 2011-06-21 23:52 UTC (permalink / raw)
To: Joyce Yu - System Software; +Cc: netdev
In-Reply-To: <4E012D80.4090907@oracle.com>
On Tue, 21 Jun 2011 16:47:12 -0700
Joyce Yu - System Software <joyce.yu@oracle.com> wrote:
>
> Since it is a new driver, shall I follow the "Submitting Drivers for the
> Linux Kernel" Doc? The driver is ready and passed all our QA cycles. I
> have three source base, one is for 2.6.16 and 2.6.18 (for RHL 5.X and
> SLES 10 SP3) , one is for 2.6.32 (For RHL 6.X, SLES11SP1), one for
> 2.6.27 (For SLES11). Can it be integrated to the 2.6.18 and 2.6.32 tree?
> or it has to be in the latest 2.6.39 or later?
>
Do you want the driver to show up in 3.0 (aka 2.6.40) or next release.
For 3.0 submit patch against 3.0-rc4 for next release base the patch
against the network development tree (net-next-2.6).
The code should remove all special case code to deal with old kernel
versions. No backward compatiablity #ifdef's
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Flavio Leitner @ 2011-06-21 23:32 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <4E011A96.7050509@redhat.com>
On 06/21/2011 07:26 PM, Prarit Bhargava wrote:
>> I'm thinking on a situation where we leave the systems with this enabled
>> and then an ordinary user starts pinging the network guessing the hexa to
>> cause reboots.
>>
>
> Good point Flavio, but that's *exactly* why I wrote this in single-shot
> mode. I really think the code might be a bit too risky for most people
> to deploy in production environments. It's too risky for me to let
> someone ping and ping and ping until they luckily hit the magic number
> and figure out how to bring *all* of my systems down. What are the
> chances that a lab admin is smart enough to set the password to
> different numbers across different machines in a single lab?
I see your point. I liked the patch because of the simplicity but
oh well, if we care that much about the security, then in the end
we will have something similar to what the xt_SYSRQ does already.
fbl
^ permalink raw reply
* Re: [PATCH net-next 0/3] Three possible UDP fixes.
From: David Miller @ 2011-06-21 23:31 UTC (permalink / raw)
To: paul.gortmaker; +Cc: eric.dumazet, netdev
In-Reply-To: <1308689020-1873-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue, 21 Jun 2011 16:43:37 -0400
> These were originally found on a 2.6.34 baseline, but I looked
> at them and couldn't see any reason why they wouldn't be valid
> fixes on net-next. But I'll feel better when someone like
> Dave and/or Eric sanity checks them too.
>
> There was one thing that was a consideration. In the 3rd patch,
> where we clear MSG_TRUNC bit -- is there anything in there that
> we really need to be concerned about preserving on the retry,
> or could we just unconditionally do "msg->msg_flags = 0" ?
> I wasn't sure, and so sticking with clearing the offending bit
> seemed like the most cautious approach.
All applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [RFT PATCH 0/9] Cleanup and extension of netdev features
From: Jeff Kirsher @ 2011-06-21 23:27 UTC (permalink / raw)
To: Ben Greear
Cc: Michał Mirosław, netdev, David S. Miller, Ben Hutchings
In-Reply-To: <4E011080.7000008@candelatech.com>
2011/6/21 Ben Greear <greearb@candelatech.com>:
> On 06/20/2011 12:14 PM, Michał Mirosław wrote:
>>
>> This is a preview of the cleanups pending after getting rid of old
>> ethtool ops from remaining drivers.
>
> Even when skipping patch 1 (seems this was just merged earlier today),
> these patches do not all apply to net-next.
>
Not all of patch was merged earlier today, just the update to e1000
and igbvf. I still have e1000e, igb, ixgb, ixgbe and ixgbevf patches
still being worked on. I do apologize for delay.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH v2] netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on
From: David Miller @ 2011-06-21 23:26 UTC (permalink / raw)
To: randy.dunlap; +Cc: bhutchings, akpm, netdev, bugme-daemon, hilld
In-Reply-To: <20110621110120.50c3b57d.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 21 Jun 2011 11:01:20 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> When NETCONSOLE_DYNAMIC=y and CONFIGFS_FS=m, there are build errors
> in netconsole:
>
> drivers/built-in.o: In function `drop_netconsole_target':
> netconsole.c:(.text+0x1a100f): undefined reference to `config_item_put'
> drivers/built-in.o: In function `make_netconsole_target':
> netconsole.c:(.text+0x1a10b9): undefined reference to `config_item_init_type_name'
> drivers/built-in.o: In function `write_msg':
> netconsole.c:(.text+0x1a11a4): undefined reference to `config_item_get'
> netconsole.c:(.text+0x1a1211): undefined reference to `config_item_put'
> drivers/built-in.o: In function `netconsole_netdev_event':
> netconsole.c:(.text+0x1a12cc): undefined reference to `config_item_put'
> netconsole.c:(.text+0x1a12ec): undefined reference to `config_item_get'
> netconsole.c:(.text+0x1a1366): undefined reference to `config_item_put'
> drivers/built-in.o: In function `init_netconsole':
> netconsole.c:(.init.text+0x953a): undefined reference to `config_group_init'
> netconsole.c:(.init.text+0x9560): undefined reference to `configfs_register_subsystem'
> drivers/built-in.o: In function `dynamic_netconsole_exit':
> netconsole.c:(.exit.text+0x809): undefined reference to `configfs_unregister_subsystem'
>
> so fix the NETCONSOLE_DYNAMIC depends clause to prevent this.
> Based on email suggestion from Ben Hutchings. Thanks.
>
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=37992
>
> Reported-by: David Hill <hilld@binarystorm.net>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH net-next] net: remove mm.h inclusion from netdevice.h
From: David Miller @ 2011-06-21 23:25 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, linux-kernel, fujita.tomonori, linux-arch
In-Reply-To: <20110616210134.GA18026@p183.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri, 17 Jun 2011 00:01:34 +0300
> Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually).
>
> To prevent mm.h inclusion via other channels also extract "enum dma_data_direction"
> definition into separate header. This tiny piece is what gluing netdevice.h with mm.h
> via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h".
> Removal of mm.h from scatterlist.h was tried and was found not feasible
> on most archs, so the link was cutoff earlier.
>
> Hope people are OK with tiny include file.
>
> Note, that mm_types.h is still dragged in, but it is a separate story.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
I've applied this, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] Tracepoints for queueing skb to rcvbuf
From: David Miller @ 2011-06-21 23:07 UTC (permalink / raw)
To: satoru.moriya; +Cc: netdev, nhorman, dle-develop, seiji.aguchi
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9C402B96E4@USINDEVS02.corp.hds.com>
From: Satoru Moriya <satoru.moriya@hds.com>
Date: Fri, 17 Jun 2011 17:56:55 -0400
> To separate these reasons, this patchset adds 3 tracepoints.
>
> 1st one is added to __udp_queue_rcv_skb to get return value of
> ip_queue_rcv_skb. Analyzing it we can separate above (*) (3 possibilities).
>
> 2nd and 3rd one are to get more detailed information. We can collect status
> of socket receive queue and related parameters(some of them are sysctl knob
> e.g. /proc/sys/net/ipv4/udp_mem, etc. for UDP) and then we can tune kernel
> behavior easily.
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cnic, bnx2i: Add support for new devices - 57800, 57810, and 57840
From: David Miller @ 2011-06-21 23:06 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1308618956-31169-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 20 Jun 2011 18:15:56 -0700
> And change iSCSI RQ doorbell size from 16B to 64B to match new firmware.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Remove redundant linux/version.h includes from net/
From: David Miller @ 2011-06-21 23:03 UTC (permalink / raw)
To: jj; +Cc: netdev, coreteam, netfilter, netfilter-devel, linux-kernel, xeb
In-Reply-To: <alpine.LNX.2.00.1106210009520.27735@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Tue, 21 Jun 2011 00:13:10 +0200 (CEST)
> It was suggested by "make versioncheck" that the follwing includes of
> linux/version.h are redundant:
>
> /home/jj/src/linux-2.6/net/caif/caif_dev.c: 14 linux/version.h not needed.
> /home/jj/src/linux-2.6/net/caif/chnl_net.c: 10 linux/version.h not needed.
> /home/jj/src/linux-2.6/net/ipv4/gre.c: 19 linux/version.h not needed.
> /home/jj/src/linux-2.6/net/netfilter/ipset/ip_set_core.c: 20 linux/version.h not needed.
> /home/jj/src/linux-2.6/net/netfilter/xt_set.c: 16 linux/version.h not needed.
>
> and it seems that it is right.
>
> Beyond manually inspecting the source files I also did a few build
> tests with various configs to confirm that including the header in
> those files is indeed not needed.
>
> Here's a patch to remove the pointless includes.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V4] mv643xx_eth: enable transmit time stamping.
From: David Miller @ 2011-06-21 23:01 UTC (permalink / raw)
To: richardcochran; +Cc: buytenh, netdev, eric.dumazet
In-Reply-To: <20110621043519.GA3579@riccoc20.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 21 Jun 2011 06:35:19 +0200
> This patch enables software (and phy device) transmit time stamping.
> Compile tested only.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] mv643xx_eth: fix race in trasmit path.
From: David Miller @ 2011-06-21 23:00 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, eric.dumazet, stable, buytenh
In-Reply-To: <25a379578b71bf01f3c77ac76a193d26554f9e0c.1308555865.git.richard.cochran@omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Mon, 20 Jun 2011 09:48:07 +0200
> Because the socket buffer is freed in the completion interrupt, it is not
> safe to access it after submitting it to the hardware.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Since this isn't actually a bonafide bug fix I've applied this to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Grant Likely @ 2011-06-21 22:58 UTC (permalink / raw)
To: Segher Boessenkool
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jeremy Kerr, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <ba379b3b42f1659f4f6649c78b8bb1b2-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Tue, Jun 21, 2011 at 4:52 PM, Segher Boessenkool
<segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
>> Ah, we're having an impedance mismatch. I'm thinking specifically
>> about the device tree compiler and some syntactic sugar for using the
>> label definition to generate /also/ create alias properties. The
>> hairiness is related to that and the way that dtc is implemented, not
>> with the final aliases themselves.
>
> You can generate DTC-style aliases from OFW-style aliases instead (or
> as well), it has other advantages (like being more readable, and having
> the aliases grouped together).
There is no difference between OFW and DTC aliases as far as I'm aware.
g.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-21 22:58 UTC (permalink / raw)
To: fw; +Cc: fbl, prarit, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <20110621225645.GD16021@Chamillionaire.breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 22 Jun 2011 00:56:45 +0200
> Flavio Leitner <fbl@redhat.com> wrote:
>> What about a whitelist of source MAC or IP addresses to accept the sysrq?
>
> This is one of the reasons why I still think that
> xt_SYSREQ would be the better solution, you get all
> kinds of filtering features for free.
>
> You could even use crazy things like '-m time' to restrict
> sysreq availability to working hours and whatnot.
Agreed.
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next 4/5] xen: convert to 64 bit stats interface
From: David Miller @ 2011-06-21 22:57 UTC (permalink / raw)
To: Ian.Campbell; +Cc: shemminger, Jeremy.Fitzhardinge, netdev, xen-devel
In-Reply-To: <1308670728.6920.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
Date: Tue, 21 Jun 2011 16:38:48 +0100
> On Tue, 2011-06-21 at 16:35 +0100, Stephen Hemminger wrote:
>> Convert xen driver to 64 bit statistics interface.
>> Use stats_sync to ensure that 64 bit update is read atomically on 32 bit platform.
>> Put hot statistics into per-cpu table.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> ---
>> v2 - add stats_sync and per-cpu
>> v2.1 - keep rx_errors on checksum error
>
> Thanks. Looks good to me from the Xen side.
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Florian Westphal @ 2011-06-21 22:56 UTC (permalink / raw)
To: Flavio Leitner
Cc: Prarit Bhargava, netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <4E0115B3.2030802@redhat.com>
Flavio Leitner <fbl@redhat.com> wrote:
> What about a whitelist of source MAC or IP addresses to accept the sysrq?
This is one of the reasons why I still think that
xt_SYSREQ would be the better solution, you get all
kinds of filtering features for free.
You could even use crazy things like '-m time' to restrict
sysreq availability to working hours and whatnot.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ifb: convert to 64 bit stats (v3)
From: David Miller @ 2011-06-21 22:55 UTC (permalink / raw)
To: hadi; +Cc: eric.dumazet, shemminger, netdev
In-Reply-To: <1308614681.12661.1.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Mon, 20 Jun 2011 20:04:41 -0400
> On Mon, 2011-06-20 at 23:44 +0200, Eric Dumazet wrote:
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/5] vxge: fix 64 bit access on 32 bit platforms
From: David Miller @ 2011-06-21 22:56 UTC (permalink / raw)
To: shemminger; +Cc: jdmason, netdev
In-Reply-To: <20110620203602.653878704@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 20 Jun 2011 13:35:07 -0700
> Need to add stat_sync wrapper around 64 bit statistic values.
> Fix wraparound bug in lockup detector where it is unsafely comparing
> 64 bit value that is not atomic. Since only care about detecting activity
> just looking at current low order bits will work.
>
> Remove unused entries in old vxge_sw_stats structure.
> Change the error counters to unsigned long since they won't grow so large
> as to have to be 64 bits.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Segher Boessenkool @ 2011-06-21 22:52 UTC (permalink / raw)
To: Grant Likely
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jeremy Kerr, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <BANLkTikBUo3jO=R0amkdxU1V3QMJoOUkEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Ah, we're having an impedance mismatch. I'm thinking specifically
> about the device tree compiler and some syntactic sugar for using the
> label definition to generate /also/ create alias properties. The
> hairiness is related to that and the way that dtc is implemented, not
> with the final aliases themselves.
You can generate DTC-style aliases from OFW-style aliases instead (or
as well), it has other advantages (like being more readable, and having
the aliases grouped together).
Segher
^ permalink raw reply
* Re: [PATCH net-next V2] drivers/net: Remove casts of void *
From: David Miller @ 2011-06-21 22:50 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <1308681934.3338.17.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Tue, 21 Jun 2011 11:45:34 -0700
> On Fri, 2011-06-17 at 15:19 -0400, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Thu, 16 Jun 2011 22:08:06 -0700
>> > Unnecessary casts of void * clutter the code.
>> > These are the remainder casts after several specific
>> > patches to remove netdev_priv and dev_priv.
>> > Done via coccinelle script (and a little editing):
>> Applied, thanks.
>
> Unapplied? I don't see this in net-next.
My bad, I have no idea how it disappeared.
I put it into net-next-2.6 and pushed it out, it should _really_
be there now.
^ permalink raw reply
* Re: [PATCH] svcauth_unix.c: quiet sparse noise
From: J. Bruce Fields @ 2011-06-21 22:44 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: Linux Kernel, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA, neilb-l3A5Bk7waGM,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <201106201819.12839.hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org>
On Mon, Jun 20, 2011 at 06:19:12PM -0700, H Hartley Sweeten wrote:
> Like svcauth_unix, the symbol svcauth_null is used external from this
> file. Declare it as extern to quiet the following sparse noise:
>
> warning: symbol 'svcauth_null' was not declared. Should it be static?
Also applying for 3.1.--b.
>
> Signed-off-by: H Hartley Sweeten <hsweeten-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org>
> Cc: Trond Myklebust <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
> Cc: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> Cc: Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>
> ---
>
> diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
> index c8e1021..62e49e2 100644
> --- a/net/sunrpc/svcauth_unix.c
> +++ b/net/sunrpc/svcauth_unix.c
> @@ -36,6 +36,7 @@ struct unix_domain {
> /* other stuff later */
> };
>
> +extern struct auth_ops svcauth_null;
> extern struct auth_ops svcauth_unix;
>
> static void svcauth_unix_domain_release(struct auth_domain *dom)
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] svcsock.c: include sunrpc.h to quite sparse noise
From: J. Bruce Fields @ 2011-06-21 22:44 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: Linux Kernel, netdev, linux-nfs, Trond.Myklebust, neilb, davem
In-Reply-To: <201106201754.51704.hartleys@visionengravers.com>
On Mon, Jun 20, 2011 at 05:54:51PM -0700, H Hartley Sweeten wrote:
> Include the private header sunrpc.h to pickup the declaration of the
> function svc_send_common to quiet the following sparse noise:
>
> warning: symbol 'svc_send_common' was not declared. Should it be static?
Thanks, applying for 3.1--b.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Neil Brown <neilb@suse.de>
> Cc: "David S. Miller" <davem@davemloft.net>
>
> ---
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index af04f77..f2cb5b8 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -51,6 +51,8 @@
> #include <linux/sunrpc/stats.h>
> #include <linux/sunrpc/xprt.h>
>
> +#include "sunrpc.h"
> +
> #define RPCDBG_FACILITY RPCDBG_SVCXPRT
>
>
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the trivial and net trees
From: Vitaliy Ivanov @ 2011-06-21 22:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Jiri Kosina, David Miller,
netdev
In-Reply-To: <20110621151055.0775f17a.sfr@canb.auug.org.au>
Stephen,
On Tue, Jun 21, 2011 at 8:10 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/brcm80211/brcmfmac/wl_iw.c between commit e44ba033c565
> ("treewide: remove duplicate includes") from the trivial tree, commit
> 219eb47e6f35 ("net/staging: add needed interrupt.h and hardirq.h
> includes") from the net tree and various commits from the staging tree.
>
> I fixed them up (see below) and can carry the fix as necessary.
This one and all the others look good to me.
Vitaliy
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Grant Likely @ 2011-06-21 22:33 UTC (permalink / raw)
To: Mitch Bradley
Cc: patches, netdev, devicetree-discuss, Jason Liu, linux-kernel,
Shawn Guo, Jeremy Kerr, Sascha Hauer, linux-arm-kernel
In-Reply-To: <4E011678.4030208@firmworks.com>
On Tue, Jun 21, 2011 at 4:08 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> On 6/21/2011 9:38 AM, Grant Likely wrote:
>>
>> On Tue, Jun 21, 2011 at 1:35 PM, Mitch Bradley<wmb@firmworks.com> wrote:
>>>
>>> What is the problem with
>>>
>>> aliases{
>>> serial0 = "/uart@7000c000";
>>> }
>>>
>>> Properties in the alias node are supposed to have string values.
>>
>> ?
>>
>> Not sure I follow. Indeed, properties in the aliases node are string
>> values.
>>
>> Are you referring to how I was proposing some dtc syntax for
>> generating the alias strings?
>
>
> The point is that if you refer to the node explicitly by its string name,
> the need for a label disappears and the problem of overriding a default
> alias disappears (assuming that a later redefinition of a property takes
> precedence over an earlier one, as is the OFW convention).
Ah, we're having an impedance mismatch. I'm thinking specifically
about the device tree compiler and some syntactic sugar for using the
label definition to generate /also/ create alias properties. The
hairiness is related to that and the way that dtc is implemented, not
with the final aliases themselves.
g.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-21 22:26 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <4E0115B3.2030802@redhat.com>
>> + * Note that the network sysrq automatically disables after the receipt of
>> + * *ANY* ping. If you want to use this again, you must complete the
>> + * above four steps again.
>>
>
Hi Flavio,
> why not leave it running? perhaps disable it for some time to
> filter any ping retransmission, for instance netsysrq_reenable=10 seconds.
> and then do if (time_after(jiffies, last_ping + netsysrq_reenable))...
>
>
To be honest I have no objection to that, except that I thought the
community's objection would be about the security of this code -- I
specifically set out to make this as secure as I could (multiple
enabling steps, 30 digit hash, single-shot mode).
With your method someone *theoretically* could ping -p a system and
eventually crash it. Of course anyone using this in production is crazy
and probably would end up getting what they deserved ;)
I'm certainly willing to consider your proposal -- but I have a feeling
that people would want this in single-shot mode over a rearming-mode.
> I have an USB KVM console, so often when testing workload, the USB takes
> ages to register the keyboard and I'd like to shot some sysrq+t or w,
> so if it disables after the first one, I can't get more traces because
> I simply can't enable it again.
>
>
Yup. One of the thoughts was to have the enable sysfs file take a
number from 1 to 5, which would become a countdown. I thought it better
to get the base code in than muddy the waters with a potentially risky
(security-wise) proposal. (see later comment on ping flooding)
>
>>
>
> What about a whitelist of source MAC or IP addresses to accept the sysrq?
>
Oh ... that's a great idea :). I'll think about that for a later
enhancement if that's okay. One of the other ideas that came up during
discussion was a maskfile of some sort that indicated what sysrq options
were available (maybe you *don't* want a sysrq-c to be executed).
> I'm thinking on a situation where we leave the systems with this enabled
> and then an ordinary user starts pinging the network guessing the hexa to
> cause reboots.
>
>
Good point Flavio, but that's *exactly* why I wrote this in single-shot
mode. I really think the code might be a bit too risky for most people
to deploy in production environments. It's too risky for me to let
someone ping and ping and ping until they luckily hit the magic number
and figure out how to bring *all* of my systems down. What are the
chances that a lab admin is smart enough to set the password to
different numbers across different machines in a single lab?
P.
^ 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