* Re: [PATCH]: Add Network Sysrq Support
From: Flavio Leitner @ 2011-06-21 22:05 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621130040.12035.62533.sendpatchset@prarit.bos.redhat.com>
On 06/21/2011 10:00 AM, Prarit Bhargava wrote:
> Add Network Sysrq Support
>
> In some circumstances, a system can hang/lockup in such a way that the system
> is completely unresponsive to keyboard or console input but is still
> responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> net/ipv4/sysrq-ping.ko which allows a root user to configure the system for
> a remote sysrq.
>
> To use this do:
>
> mount -t debugfs none /sys/kernel/debug/
> echo 1 > /proc/sys/kernel/sysrq
> echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> echo 1 > /sys/kernel/debug/network_sysrq_enable
>
> Then on another system on the network you can do:
>
> ping -c 1 -p <up to 30 hex digit val><hex val of sysrq> <target_system_name>
>
> ex) sysrq-m, m is ascii 0x6d
>
> ping -c 1 p 1623a06f554d46d676d <target_system_name>
missing '-' in front of 'p'
>
> Note that the network sysrq automatically disables after the receipt of
> the ping, ie) it is single-shot mode. If you want to use this again, you
> must complete the above four steps again.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> diff --git a/Documentation/networking/sysrq-ping.txt b/Documentation/networking/sysrq-ping.txt
> new file mode 100644
> index 0000000..efa8be3
> --- /dev/null
> +++ b/Documentation/networking/sysrq-ping.txt
> @@ -0,0 +1,26 @@
> +In some circumstances, a system can hang/lockup in such a way that the system
> +is completely unresponsive to keyboard or console input but is still
> +responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> +net/ipv4/sysrq-ping.ko which allows a root user to configure the system for a
> +remote sysrq.
> +
> +To use this do:
> +
> +mount -t debugfs none /sys/kernel/debug/
> +echo 1 > /proc/sys/kernel/sysrq
> +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> +echo 1 > /sys/kernel/debug/network_sysrq_enable
> +
> +Then on another system you can do:
> +
> +ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
> +
> +ex) sysrq-m, m is ascii 0x6d
> +
> + ping -c 1 p 1623a06f554d46d676d <target_system_name>
again -p
> +
> +Note that the network sysrq automatically disables after the receipt of
> +the ping, ie) it is single-shot mode. If you want to use this again, you
> +must complete the above four steps again.
> +
> +Hint: 'man ascii' ;)
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index cbb505b..03bb7b1 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,11 @@ config TCP_MD5SIG
> on the Internet.
>
> If unsure, say N.
> +
> +config SYSRQ_PING
> + tristate
> + default m
prompt?
> + help
> + Allows execution of sysrq-X commands via ping over ipv4. This is a
> + known security hazard and should not be used in unsecure
> + environments.
> diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
> index f2dc69c..c23c15e 100644
> --- a/net/ipv4/Makefile
> +++ b/net/ipv4/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
> obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
> obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
> obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
> +obj-$(CONFIG_SYSRQ_PING) += sysrq-ping.o
>
> obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
> xfrm4_output.o
> diff --git a/net/ipv4/sysrq-ping.c b/net/ipv4/sysrq-ping.c
> new file mode 100644
> index 0000000..67a6d0e
> --- /dev/null
> +++ b/net/ipv4/sysrq-ping.c
> @@ -0,0 +1,207 @@
> +/*
> + * network_sysrq.c - allow sysrq to be executed over a network via ping
> + *
> + * written by: Prarit Bhargava <prarit@redhat.com>
> + * Andy Gospodarek <agospoda@redhat.com>
> + * Neil Horman <nhorman@redhat.com>
> + *
> + * based on work by: Larry Woodman <lwoodman@redhat.com>
> + *
> + * To use this do:
> + *
> + * mount -t debugfs none /sys/kernel/debug/
> + * echo 1 > /proc/sys/kernel/sysrq
> + * echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> + * echo 1 > /sys/kernel/debug/network_sysrq_enable
> + *
> + * Then on another system you can do:
> + *
> + * ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
> + *
> + * ex) sysrq-m, m is 0x6d
> + *
> + * ping -c 1 p 1623a06f554d46d676d <target_system_name>
again -p
> + *
> + * 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.
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))...
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.
> + *
> + */
> +
> +#include <linux/debugfs.h>
> +#include <linux/icmp.h>
> +#include <linux/init.h>
> +#include <linux/ip.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/netdevice.h>
> +#include <linux/sysrq.h>
> +
> +#include <net/xfrm.h>
> +
> +static u8 network_sysrq_enable; /* set in debugfs network_sysrq_enable */
> +static u16 network_sysrq_magic[16]; /* 15 bytes leaves 1 feature byte */
> +static int network_sysrq_magic_len;
> +
> +static int to_hex(int val)
> +{
> + if ((val >= '0') && (val <= '9'))
> + return val - 0x30;
> +
> + if ((val >= 'a') && (val <= 'f'))
> + return val - 0x37;
> +
> + if ((val >= 'A') && (val <= 'F'))
> + return val - 0x57;
> +
> + return -1;
> +}
> +
> +static bool network_sysrq_armed(void)
> +{
> + int i;
> +
> + if (!network_sysrq_enable)
> + return false;
> + if (!network_sysrq_magic_len)
> + return false;
> + for (i = 0; i < 16; i++)
> + if (network_sysrq_magic[i] != 0)
> + return true;
> + return false;
> +}
> +
> +static void network_sysrq_disable(void)
> +{
> + network_sysrq_enable = 0;
> + memset(network_sysrq_magic, 0, 32);
> + network_sysrq_magic_len = 0;
> +}
> +
> +static ssize_t network_sysrq_seq_write(struct file *file,
> + const char __user *ubuf,
> + size_t count, loff_t *ppos)
> +{
> + int i, j, hi, lo;
> + char buf[33];
> + memset(buf, 0, sizeof(buf));
> +
> + if (count >= 33)
> + return -EINVAL;
> +
> + if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
> + return -EFAULT;
> +
> + for (i = 0, j = 0; i < count - 2 ; i += 2, j++) {
> + hi = to_hex(buf[i]);
> + lo = to_hex(buf[i+1]) & 0x0f;
> + if ((hi == -1) || (lo == -1)) {
> + network_sysrq_disable();
> + return -EINVAL;
> + }
> + network_sysrq_magic[j] = (u16)(hi << 4) + lo;
> + }
> + network_sysrq_magic_len = j;
> +
> + return count;
> +}
> +
> +static int network_sysrq_seq_show(struct seq_file *m, void *p)
> +{
> + int i;
> +
> + for (i = 0; i < network_sysrq_magic_len; i++)
> + seq_printf(m, "%02x", network_sysrq_magic[i]);
> + seq_printf(m, "\n");
> + return 0;
> +}
> +
> +static int network_sysrq_fops_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, network_sysrq_seq_show, inode->i_private);
> +}
> +
> +static const struct file_operations xnetwork_sysrq_fops = {
> + .open = network_sysrq_fops_open,
> + .write = network_sysrq_seq_write,
> + .read = seq_read,
> + .llseek = seq_lseek,
> +};
> +
> +static int network_sysrq_func(struct sk_buff *skb, struct net_device *dev,
> + struct packet_type *pt,
> + struct net_device *orig_dev)
> +{
> + struct icmphdr *icmph;
> + char *found;
> +
> + if (ip_hdr(skb)->protocol != IPPROTO_ICMP)
> + goto end;
> +
> + if (!skb_pull(skb, sizeof(struct iphdr)))
> + goto end;
> +
> + skb_reset_transport_header(skb);
> + icmph = icmp_hdr(skb);
> +
> + if (!skb_pull(skb, sizeof(*icmph)))
> + goto end;
> +
> + /* is this a ping? */
> + if (icmph->type != ICMP_ECHO)
> + goto end;
What about a whitelist of source MAC or IP addresses to accept the sysrq?
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.
Tested here and it works.
Tested-by: Flavio Leitner <fbl@redhat.com>
fbl
> + if (network_sysrq_armed()) {
> + found = strnstr(skb->data, (char *)network_sysrq_magic,
> + skb->len - skb->data_len);
> + if (found)
> + handle_sysrq(found[network_sysrq_magic_len]);
> + network_sysrq_disable();
> + }
> +end:
> + kfree_skb(skb);
> + return 0;
> +}
> +
> +static struct packet_type network_sysrq_type = {
> + .type = cpu_to_be16(ETH_P_IP),
> + .func = network_sysrq_func,
> +};
> +
> +static struct dentry *network_sysrq_enable_dentry;
> +static struct dentry *network_sysrq_magic_dentry;
> +
> +int __init init_network_sysrq(void)
> +{
> + network_sysrq_enable_dentry = debugfs_create_u8("network_sysrq_enable",
> + S_IWUGO | S_IRUGO,
> + NULL,
> + &network_sysrq_enable);
> + if (!network_sysrq_enable_dentry)
> + return -EIO;
> +
> + network_sysrq_magic_dentry = debugfs_create_file("network_sysrq_magic",
> + S_IWUGO | S_IRUGO,
> + NULL,
> + &network_sysrq_magic,
> + &xnetwork_sysrq_fops);
> + if (!network_sysrq_magic_dentry) {
> + debugfs_remove(network_sysrq_enable_dentry);
> + return -EIO;
> + }
> +
> + dev_add_pack(&network_sysrq_type);
> + return 0;
> +}
> +
> +void __exit cleanup_network_sysrq(void)
> +{
> + dev_remove_pack(&network_sysrq_type);
> + debugfs_remove(network_sysrq_enable_dentry);
> + debugfs_remove(network_sysrq_magic_dentry);
> +}
> +
> +module_init(init_network_sysrq);
> +module_exit(cleanup_network_sysrq);
> +
> +MODULE_LICENSE("GPL");
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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 1/3] serial/imx: add device tree support
From: Mitch Bradley @ 2011-06-21 22:08 UTC (permalink / raw)
To: Grant Likely
Cc: patches, netdev, devicetree-discuss, Jason Liu, linux-kernel,
Shawn Guo, Jeremy Kerr, Sascha Hauer, linux-arm-kernel
In-Reply-To: <BANLkTik9LXTJ--fRwUBscokWraPwOZnpHA@mail.gmail.com>
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).
>
> g.
>
>>
>>
>> On 6/21/2011 9:13 AM, Grant Likely wrote:
>>>
>>> On Tue, Jun 21, 2011 at 7:55 AM, Shawn Guo<shawn.guo@freescale.com>
>>> wrote:
>>>>
>>>> Hi Grant,
>>>>
>>>> I just gave a try to use aliases node for identify the device index.
>>>> Please take a look and let me know if it's what you expect.
>>>
>>> Thanks Shawn. This is definitely on track. Comments below...
>>>
>>>>
>>>> On Sun, Jun 19, 2011 at 03:30:02PM +0800, Shawn Guo wrote:
>>>> [...]
>>>>>>>
>>>>>>> +#ifdef CONFIG_OF
>>>>>>> +static int serial_imx_probe_dt(struct imx_port *sport,
>>>>>>> + struct platform_device *pdev)
>>>>>>> +{
>>>>>>> + struct device_node *node = pdev->dev.of_node;
>>>>>>> + const __be32 *line;
>>>>>>> +
>>>>>>> + if (!node)
>>>>>>> + return -ENODEV;
>>>>>>> +
>>>>>>> + line = of_get_property(node, "id", NULL);
>>>>>>> + if (!line)
>>>>>>> + return -ENODEV;
>>>>>>> +
>>>>>>> + sport->port.line = be32_to_cpup(line) - 1;
>>>>>>
>>>>>> Hmmm, I really would like to be rid of this. Instead, if uarts must
>>>>>> be enumerated, the driver should look for a /aliases/uart* property
>>>>>> that matches the of_node. Doing it that way is already established in
>>>>>> the OpenFirmware documentation, and it ensures there are no overlaps
>>>>>> in the global namespace.
>>>>>>
>>>>>
>>>>> I just gave one more try to avoid using 'aliases', and you gave a
>>>>> 'no' again. Now, I know how hard you are on this. Okay, I start
>>>>> thinking about your suggestion seriously :)
>>>>>
>>>>>> We do need some infrastructure to make that easier though. Would you
>>>>>> have time to help put that together?
>>>>>>
>>>>> Ok, I will give it a try.
>>>>>
>>>>
>>>> diff --git a/arch/arm/boot/dts/imx51-babbage.dts
>>>> b/arch/arm/boot/dts/imx51-babbage.dts
>>>> index da0381a..f4a5c3c 100644
>>>> --- a/arch/arm/boot/dts/imx51-babbage.dts
>>>> +++ b/arch/arm/boot/dts/imx51-babbage.dts
>>>> @@ -18,6 +18,12 @@
>>>> compatible = "fsl,imx51-babbage", "fsl,imx51";
>>>> interrupt-parent =<&tzic>;
>>>>
>>>> + aliases {
>>>> + serial0 =&uart0;
>>>> + serial1 =&uart1;
>>>> + serial2 =&uart2;
>>>> + };
>>>> +
>>>
>>> Hmmm. David Gibson had tossed out an idea of automatically generating
>>> aliases from labels. It may be time to revisit that idea.
>>>
>>> David, perhaps using this format for a label should turn it into an
>>> alias (prefix label with an asterisk):
>>>
>>> *thealias: i2c@12340000 { /*...*/ };
>>>
>>> .... although that approach gets *really* hairy when considering that
>>> different boards will want different enumeration. How would one
>>> override an automatic alias defined by an included .dts file?
>>>
>>>> chosen {
>>>> bootargs = "console=ttymxc0,115200 root=/dev/mmcblk0p3
>>>> rootwait";
>>>> };
>>>> @@ -47,29 +53,29 @@
>>>> reg =<0x70000000 0x40000>;
>>>> ranges;
>>>>
>>>> - uart@7000c000 {
>>>> + uart2: uart@7000c000 {
>>>> compatible = "fsl,imx51-uart",
>>>> "fsl,imx21-uart";
>>>> reg =<0x7000c000 0x4000>;
>>>> interrupts =<33>;
>>>> id =<3>;
>>>> - fsl,has-rts-cts;
>>>> + fsl,uart-has-rtscts;
>>>> };
>>>> };
>>>>
>>>> - uart@73fbc000 {
>>>> + uart0: uart@73fbc000 {
>>>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>>>> reg =<0x73fbc000 0x4000>;
>>>> interrupts =<31>;
>>>> id =<1>;
>>>> - fsl,has-rts-cts;
>>>> + fsl,uart-has-rtscts;
>>>> };
>>>>
>>>> - uart@73fc0000 {
>>>> + uart1: uart@73fc0000 {
>>>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>>>> reg =<0x73fc0000 0x4000>;
>>>> interrupts =<32>;
>>>> id =<2>;
>>>> - fsl,has-rts-cts;
>>>> + fsl,uart-has-rtscts;
>>>> };
>>>> };
>>>>
>>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>>> index 632ebae..13df5d2 100644
>>>> --- a/drivers/of/base.c
>>>> +++ b/drivers/of/base.c
>>>> @@ -737,6 +737,37 @@ err0:
>>>> EXPORT_SYMBOL(of_parse_phandles_with_args);
>>>>
>>>> /**
>>>> + * of_get_device_index - Get device index by looking up "aliases"
>>>> node
>>>> + * @np: Pointer to device node that asks for device index
>>>> + * @name: The device alias without index number
>>>> + *
>>>> + * Returns the device index if find it, else returns -ENODEV.
>>>> + */
>>>> +int of_get_device_index(struct device_node *np, const char *alias)
>>>> +{
>>>> + struct device_node *aliases = of_find_node_by_name(NULL,
>>>> "aliases");
>>>> + struct property *prop;
>>>> + char name[32];
>>>> + int index = 0;
>>>> +
>>>> + if (!aliases)
>>>> + return -ENODEV;
>>>> +
>>>> + while (1) {
>>>> + snprintf(name, sizeof(name), "%s%d", alias, index);
>>>> + prop = of_find_property(aliases, name, NULL);
>>>> + if (!prop)
>>>> + return -ENODEV;
>>>> + if (np == of_find_node_by_path(prop->value))
>>>> + break;
>>>> + index++;
>>>> + }
>>>
>>> Rather than parsing the alias strings everytime, it would probably be
>>> better to preprocess all the properties in the aliases node and create
>>> a lookup table of alias->node references that can be walked quickly
>>> and trivially.
>>>
>>> Also, when obtaining an enumeration for a device, you'll need to be
>>> careful about what number gets returned. If the node doesn't match a
>>> given alias, but aliases do exist for other devices of like type, then
>>> you need to be careful not to assign a number already assigned to
>>> another device via an alias (this of course assumes the driver
>>> supports dynamics enumeration, which many drivers will). It would be
>>>
>>> \> +
>>>>
>>>> + return index;
>>>> +}
>>>> +EXPORT_SYMBOL(of_get_device_index);
>>>> +
>>>> +/**
>>>> * prom_add_property - Add a property to a node
>>>> */
>>>> int prom_add_property(struct device_node *np, struct property *prop)
>>>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>>>> index da436e0..852668f 100644
>>>> --- a/drivers/tty/serial/imx.c
>>>> +++ b/drivers/tty/serial/imx.c
>>>> @@ -1271,18 +1271,18 @@ static int serial_imx_probe_dt(struct imx_port
>>>> *sport,
>>>> struct device_node *node = pdev->dev.of_node;
>>>> const struct of_device_id *of_id =
>>>> of_match_device(imx_uart_dt_ids,&pdev->dev);
>>>> - const __be32 *line;
>>>> + int line;
>>>>
>>>> if (!node)
>>>> return -ENODEV;
>>>>
>>>> - line = of_get_property(node, "id", NULL);
>>>> - if (!line)
>>>> + line = of_get_device_index(node, "serial");
>>>> + if (IS_ERR_VALUE(line))
>>>> return -ENODEV;
>>>
>>> Personally, it an alias isn't present, then I'd dynamically assign a port
>>> id.
>>>
>>>>
>>>> - sport->port.line = be32_to_cpup(line) - 1;
>>>> + sport->port.line = line;
>>>>
>>>> - if (of_get_property(node, "fsl,has-rts-cts", NULL))
>>>> + if (of_get_property(node, "fsl,uart-has-rtscts", NULL))
>>>> sport->have_rtscts = 1;
>>>>
>>>> if (of_get_property(node, "fsl,irda-mode", NULL))
>>>> diff --git a/include/linux/of.h b/include/linux/of.h
>>>> index bfc0ed1..3153752 100644
>>>> --- a/include/linux/of.h
>>>> +++ b/include/linux/of.h
>>>> @@ -213,6 +213,8 @@ extern int of_parse_phandles_with_args(struct
>>>> device_node *np,
>>>> const char *list_name, const char *cells_name, int index,
>>>> struct device_node **out_node, const void **out_args);
>>>>
>>>> +extern int of_get_device_index(struct device_node *np, const char
>>>> *alias);
>>>> +
>>>> extern int of_machine_is_compatible(const char *compat);
>>>>
>>>> extern int prom_add_property(struct device_node* np, struct property*
>>>> prop);
>>>>
>>>> --
>>>> Regards,
>>>> Shawn
>>>>
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>
>
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-21 22:12 UTC (permalink / raw)
To: Randy Dunlap; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621130929.ddd107f7.rdunlap@xenotime.net>
On 06/21/2011 04:09 PM, Randy Dunlap wrote:
>
>
>> +remote sysrq.
>> +
>> +To use this do:
>> +
>> +mount -t debugfs none /sys/kernel/debug/
>> +echo 1 > /proc/sys/kernel/sysrq
>> +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
>> +echo 1 > /sys/kernel/debug/network_sysrq_enable
>>
> so all of this (insecure) stuff has to be done before you suspect that
> you need it .. in case the local keyboard/console is dead.
>
>
Randy,
Yes -- this needs to be enabled before the system is unresponsive. I've
used it to sysrq-c systems that were reproducibly hanging in ways that
the system could not be accessed via console or keyboard. It really is
a debug feature.
[I've also sysrq-t'd and sysrq-m'd systems as well fwiw]
>> +
>> +Then on another system you can do:
>> +
>> +ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
>>
> What are the <up to 30 hex digits> for?
>
>
A secret key. By turning this on you're leaving a system susceptible to
a panic by anyone else who decides to ping your system. The ping
payload accepts up to a 32 digit hex number. Two of those are needed
for the sysrq type, so that leaves 30.
I figured a 30 digit hash, with multiple enabling steps, and single-shot
mode, was good enough to alleviate any security issues anyone would have
about this code.
I'll take all of your suggestions into [v2].
Thanks for the review,
P.
^ 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
* 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: 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] 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: [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 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 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 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 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]: 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: [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: 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: [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 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 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] 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 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 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] 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 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: [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 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
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