* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-22 3:19 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, Ying Han
In-Reply-To: <CAKTCnzmkuL+9ftD5d0Z8b5w+DUSUoLiWqSX_TgGxtRxtoPsxpA@mail.gmail.com>
On 09/22/2011 12:17 AM, Balbir Singh wrote:
> On Wed, Sep 21, 2011 at 7:53 AM, Glauber Costa<glommer@parallels.com> wrote:
>>
>> Hi people,
>>
>> Any insights on this series?
>> Kame, is it inline with your expectations ?
>>
>> Thank you all
>>
>> On 09/18/2011 09:56 PM, Glauber Costa wrote:
>>>
>>> This patch lays down the foundation for the kernel memory component
>>> of the Memory Controller.
>>>
>>> As of today, I am only laying down the following files:
>>>
>>> * memory.independent_kmem_limit
>>> * memory.kmem.limit_in_bytes (currently ignored)
>>> * memory.kmem.usage_in_bytes (always zero)
>>>
>>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>>> CC: Paul Menage<paul@paulmenage.org>
>>> CC: Greg Thelen<gthelen@google.com>
>>> ---
>>> Documentation/cgroups/memory.txt | 30 +++++++++-
>>> init/Kconfig | 11 ++++
>>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>>> index 6f3c598..6f1954a 100644
>>> --- a/Documentation/cgroups/memory.txt
>>> +++ b/Documentation/cgroups/memory.txt
>>> @@ -44,8 +44,9 @@ Features:
>>> - oom-killer disable knob and oom-notifier
>>> - Root cgroup has no limit controls.
>>>
>>> - Kernel memory and Hugepages are not under control yet. We just manage
>>> - pages on LRU. To add more controls, we have to take care of performance.
>>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>>> + controls, we have to take care of performance. Kernel memory support is work
>>> + in progress, and the current version provides basically functionality.
>>>
>>> Brief summary of control files.
>>>
>>> @@ -56,8 +57,11 @@ Brief summary of control files.
>>> (See 5.5 for details)
>>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>>> (See 5.5 for details)
>>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>>> + (See 2.7 for details)
>>> memory.limit_in_bytes # set/show limit of memory usage
>>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>>> memory.failcnt # show the number of memory usage hits limits
>>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>>> memory.max_usage_in_bytes # show max memory usage recorded
>>> @@ -72,6 +76,9 @@ Brief summary of control files.
>>> memory.oom_control # set/show oom controls.
>>> memory.numa_stat # show the number of memory usage per numa node
>>>
>>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>>> + independent of user limits
>>> +
>>> 1. History
>>>
>>> The memory controller has a long history. A request for comments for the memory
>>> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
>>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>>> zone->lru_lock, it has no lock of its own.
>>>
>>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>>> +
>>> + With the Kernel memory extension, the Memory Controller is able to limit
>>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>>> +different than user memory, since it can't be swapped out, which makes it
>>> +possible to DoS the system by consuming too much of this precious resource.
>>> +Kernel memory limits are not imposed for the root cgroup.
>>> +
>>> +Memory limits as specified by the standard Memory Controller may or may not
>>> +take kernel memory into consideration. This is achieved through the file
>>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>>> +memory to be controlled separately.
>>> +
>>> +When kernel memory limits are not independent, the limit values set in
>>> +memory.kmem files are ignored.
>>> +
>>> +Currently no soft limit is implemented for kernel memory. It is future work
>>> +to trigger slab reclaim when those limits are reached.
>>> +
>
> Ying Han was also looking into this (cc'ing her)
>
>>> 3. User Interface
>>>
>>> 0. Configuration
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index d627783..49e5839 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>>> For those who want to have the feature enabled by default should
>>> select this option (if, for some reason, they need to disable it
>>> then swapaccount=0 does the trick).
>>> +config CGROUP_MEM_RES_CTLR_KMEM
>>> + bool "Memory Resource Controller Kernel Memory accounting"
>>> + depends on CGROUP_MEM_RES_CTLR
>>> + default y
>>> + help
>>> + The Kernel Memory extension for Memory Resource Controller can limit
>>> + the amount of memory used by kernel objects in the system. Those are
>>> + fundamentally different from the entities handled by the standard
>>> + Memory Controller, which are page-based, and can be swapped. Users of
>>> + the kmem extension can use it to guarantee that no group of processes
>>> + will ever exhaust kernel resources alone.
>>>
>>> config CGROUP_PERF
>>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index ebd1e86..d32e931 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>>> #define do_swap_account (0)
>>> #endif
>>>
>>> -
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +int do_kmem_account __read_mostly = 1;
>>> +#else
>>> +#define do_kmem_account 0
>>> +#endif
>>> /*
>>> * Statistics for memory cgroup.
>>> */
>>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>>> */
>>> struct res_counter memsw;
>>> /*
>>> + * the counter to account for kmem usage.
>>> + */
>>> + struct res_counter kmem;
>>> + /*
>>> * Per cgroup active and inactive list, similar to the
>>> * per zone LRU lists.
>>> */
>>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>>> */
>>> unsigned long move_charge_at_immigrate;
>>> /*
>>> + * Should kernel memory limits be stabilished independently
>>> + * from user memory ?
>>> + */
>>> + int kmem_independent;
>>> + /*
>>> * percpu counter.
>>> */
>>> struct mem_cgroup_stat_cpu *stat;
>>> @@ -388,9 +401,14 @@ enum charge_type {
>>> };
>>>
>>> /* for encoding cft->private value on file */
>>> -#define _MEM (0)
>>> -#define _MEMSWAP (1)
>>> -#define _OOM_TYPE (2)
>>> +
>>> +enum mem_type {
>>> + _MEM = 0,
>>> + _MEMSWAP,
>>> + _OOM_TYPE,
>>> + _KMEM,
>>> +};
>>> +
>>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>>> u64 val;
>>>
>>> if (!mem_cgroup_is_root(mem)) {
>>> + val = 0;
>>> + if (!mem->kmem_independent)
>>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>>> if (!swap)
>>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>>> else
>>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> +
>>> + return val;
>>> }
>>>
>>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>>> else
>>> val = res_counter_read_u64(&mem->memsw, name);
>>> break;
>>> + case _KMEM:
>>> + val = res_counter_read_u64(&mem->kmem, name);
>>> + break;
>>> +
>>> default:
>>> BUG();
>>> break;
>>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>>> return 0;
>>> }
>>>
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>>> +{
>>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>>> +}
>>> +
>>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>>> + u64 val)
>>> +{
>>> + cgroup_lock();
>>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>>> + cgroup_unlock();
>>> + return 0;
>>> +}
>
> I know we have a lot of pending xxx_from_cont() and struct cgroup
> *cont, can we move it to memcg notation to be more consistent with our
> usage. There is a patch to convert old usage
>
>>> +#endif
>>>
>>> static struct cftype mem_cgroup_files[] = {
>>> {
>>> @@ -4877,6 +4919,47 @@ static int register_memsw_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> }
>>> #endif
>>>
>>> +
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static struct cftype kmem_cgroup_files[] = {
>>> + {
>>> + .name = "independent_kmem_limit",
>>> + .read_u64 = kmem_limit_independent_read,
>>> + .write_u64 = kmem_limit_independent_write,
>>> + },
>>> + {
>>> + .name = "kmem.usage_in_bytes",
>>> + .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE),
>>> + .read_u64 = mem_cgroup_read,
>>> + },
>>> + {
>>> + .name = "kmem.limit_in_bytes",
>>> + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
>>> + .read_u64 = mem_cgroup_read,
>>> + },
>>> +};
>>> +
>>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> +{
>>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cont);
>>> + int ret = 0;
>>> +
>>> + if (!do_kmem_account)
>>> + return 0;
>>> +
>>> + if (!mem_cgroup_is_root(mem))
>>> + ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>>> + ARRAY_SIZE(kmem_cgroup_files));
>>> + return ret;
>>> +};
>>> +
>>> +#else
>>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> +{
>>> + return 0;
>>> +}
>>> +#endif
>>> +
>>> static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
>>> {
>>> struct mem_cgroup_per_node *pn;
>>> @@ -5075,6 +5158,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>>> if (parent&& parent->use_hierarchy) {
>>> res_counter_init(&mem->res,&parent->res);
>>> res_counter_init(&mem->memsw,&parent->memsw);
>>> + res_counter_init(&mem->kmem,&parent->kmem);
>>> /*
>>> * We increment refcnt of the parent to ensure that we can
>>> * safely access it on res_counter_charge/uncharge.
>>> @@ -5085,6 +5169,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>>> } else {
>>> res_counter_init(&mem->res, NULL);
>>> res_counter_init(&mem->memsw, NULL);
>>> + res_counter_init(&mem->kmem, NULL);
>>> }
>>> mem->last_scanned_child = 0;
>>> mem->last_scanned_node = MAX_NUMNODES;
>>> @@ -5129,6 +5214,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,
>>>
>>> if (!ret)
>>> ret = register_memsw_files(cont, ss);
>>> +
>>> + if (!ret)
>>> + ret = register_kmem_files(cont, ss);
>>> +
>>> return ret;
>>> }
>>>
>>> @@ -5665,3 +5754,17 @@ static int __init enable_swap_account(char *s)
>>> __setup("swapaccount=", enable_swap_account);
>>>
>>> #endif
>>> +
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static int __init disable_kmem_account(char *s)
>>> +{
>>> + /* consider enabled if no parameter or 1 is given */
>>> + if (!strcmp(s, "1"))
>>> + do_kmem_account = 1;
>>> + else if (!strcmp(s, "0"))
>>> + do_kmem_account = 0;
>>> + return 1;
>>> +}
>>> +__setup("kmemaccount=", disable_kmem_account);
>>> +
>>> +#endif
>
> The infrastructure looks OK, we need better integration with
> statistics for kmem usage.
>
> Balbir Singh
Hello Balbir,
Thank you for your comments.
I agree here. With this patch, however, I am only trying to lay down the
foundations needed for the rest of the patches, that touch tcp memory
pressure conditions.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Balbir Singh @ 2011-09-22 3:17 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, Ying Han
In-Reply-To: <4E794AA2.9080008@parallels.com>
On Wed, Sep 21, 2011 at 7:53 AM, Glauber Costa <glommer@parallels.com> wrote:
>
> Hi people,
>
> Any insights on this series?
> Kame, is it inline with your expectations ?
>
> Thank you all
>
> On 09/18/2011 09:56 PM, Glauber Costa wrote:
>>
>> This patch lays down the foundation for the kernel memory component
>> of the Memory Controller.
>>
>> As of today, I am only laying down the following files:
>>
>> * memory.independent_kmem_limit
>> * memory.kmem.limit_in_bytes (currently ignored)
>> * memory.kmem.usage_in_bytes (always zero)
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: Paul Menage<paul@paulmenage.org>
>> CC: Greg Thelen<gthelen@google.com>
>> ---
>> Documentation/cgroups/memory.txt | 30 +++++++++-
>> init/Kconfig | 11 ++++
>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 6f3c598..6f1954a 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
>> @@ -44,8 +44,9 @@ Features:
>> - oom-killer disable knob and oom-notifier
>> - Root cgroup has no limit controls.
>>
>> - Kernel memory and Hugepages are not under control yet. We just manage
>> - pages on LRU. To add more controls, we have to take care of performance.
>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>> + controls, we have to take care of performance. Kernel memory support is work
>> + in progress, and the current version provides basically functionality.
>>
>> Brief summary of control files.
>>
>> @@ -56,8 +57,11 @@ Brief summary of control files.
>> (See 5.5 for details)
>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>> (See 5.5 for details)
>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>> + (See 2.7 for details)
>> memory.limit_in_bytes # set/show limit of memory usage
>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>> memory.failcnt # show the number of memory usage hits limits
>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>> memory.max_usage_in_bytes # show max memory usage recorded
>> @@ -72,6 +76,9 @@ Brief summary of control files.
>> memory.oom_control # set/show oom controls.
>> memory.numa_stat # show the number of memory usage per numa node
>>
>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>> + independent of user limits
>> +
>> 1. History
>>
>> The memory controller has a long history. A request for comments for the memory
>> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>> +memory to be controlled separately.
>> +
>> +When kernel memory limits are not independent, the limit values set in
>> +memory.kmem files are ignored.
>> +
>> +Currently no soft limit is implemented for kernel memory. It is future work
>> +to trigger slab reclaim when those limits are reached.
>> +
Ying Han was also looking into this (cc'ing her)
>> 3. User Interface
>>
>> 0. Configuration
>> diff --git a/init/Kconfig b/init/Kconfig
>> index d627783..49e5839 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>> For those who want to have the feature enabled by default should
>> select this option (if, for some reason, they need to disable it
>> then swapaccount=0 does the trick).
>> +config CGROUP_MEM_RES_CTLR_KMEM
>> + bool "Memory Resource Controller Kernel Memory accounting"
>> + depends on CGROUP_MEM_RES_CTLR
>> + default y
>> + help
>> + The Kernel Memory extension for Memory Resource Controller can limit
>> + the amount of memory used by kernel objects in the system. Those are
>> + fundamentally different from the entities handled by the standard
>> + Memory Controller, which are page-based, and can be swapped. Users of
>> + the kmem extension can use it to guarantee that no group of processes
>> + will ever exhaust kernel resources alone.
>>
>> config CGROUP_PERF
>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index ebd1e86..d32e931 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>> #define do_swap_account (0)
>> #endif
>>
>> -
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int do_kmem_account __read_mostly = 1;
>> +#else
>> +#define do_kmem_account 0
>> +#endif
>> /*
>> * Statistics for memory cgroup.
>> */
>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>> */
>> struct res_counter memsw;
>> /*
>> + * the counter to account for kmem usage.
>> + */
>> + struct res_counter kmem;
>> + /*
>> * Per cgroup active and inactive list, similar to the
>> * per zone LRU lists.
>> */
>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>> */
>> unsigned long move_charge_at_immigrate;
>> /*
>> + * Should kernel memory limits be stabilished independently
>> + * from user memory ?
>> + */
>> + int kmem_independent;
>> + /*
>> * percpu counter.
>> */
>> struct mem_cgroup_stat_cpu *stat;
>> @@ -388,9 +401,14 @@ enum charge_type {
>> };
>>
>> /* for encoding cft->private value on file */
>> -#define _MEM (0)
>> -#define _MEMSWAP (1)
>> -#define _OOM_TYPE (2)
>> +
>> +enum mem_type {
>> + _MEM = 0,
>> + _MEMSWAP,
>> + _OOM_TYPE,
>> + _KMEM,
>> +};
>> +
>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>> u64 val;
>>
>> if (!mem_cgroup_is_root(mem)) {
>> + val = 0;
>> + if (!mem->kmem_independent)
>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>> if (!swap)
>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>> else
>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>> +
>> + return val;
>> }
>>
>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>> else
>> val = res_counter_read_u64(&mem->memsw, name);
>> break;
>> + case _KMEM:
>> + val = res_counter_read_u64(&mem->kmem, name);
>> + break;
>> +
>> default:
>> BUG();
>> break;
>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>> +{
>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>> +}
>> +
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>> + cgroup_unlock();
>> + return 0;
>> +}
I know we have a lot of pending xxx_from_cont() and struct cgroup
*cont, can we move it to memcg notation to be more consistent with our
usage. There is a patch to convert old usage
>> +#endif
>>
>> static struct cftype mem_cgroup_files[] = {
>> {
>> @@ -4877,6 +4919,47 @@ static int register_memsw_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> }
>> #endif
>>
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static struct cftype kmem_cgroup_files[] = {
>> + {
>> + .name = "independent_kmem_limit",
>> + .read_u64 = kmem_limit_independent_read,
>> + .write_u64 = kmem_limit_independent_write,
>> + },
>> + {
>> + .name = "kmem.usage_in_bytes",
>> + .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE),
>> + .read_u64 = mem_cgroup_read,
>> + },
>> + {
>> + .name = "kmem.limit_in_bytes",
>> + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
>> + .read_u64 = mem_cgroup_read,
>> + },
>> +};
>> +
>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> +{
>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cont);
>> + int ret = 0;
>> +
>> + if (!do_kmem_account)
>> + return 0;
>> +
>> + if (!mem_cgroup_is_root(mem))
>> + ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> + ARRAY_SIZE(kmem_cgroup_files));
>> + return ret;
>> +};
>> +
>> +#else
>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
>> {
>> struct mem_cgroup_per_node *pn;
>> @@ -5075,6 +5158,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>> if (parent&& parent->use_hierarchy) {
>> res_counter_init(&mem->res,&parent->res);
>> res_counter_init(&mem->memsw,&parent->memsw);
>> + res_counter_init(&mem->kmem,&parent->kmem);
>> /*
>> * We increment refcnt of the parent to ensure that we can
>> * safely access it on res_counter_charge/uncharge.
>> @@ -5085,6 +5169,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>> } else {
>> res_counter_init(&mem->res, NULL);
>> res_counter_init(&mem->memsw, NULL);
>> + res_counter_init(&mem->kmem, NULL);
>> }
>> mem->last_scanned_child = 0;
>> mem->last_scanned_node = MAX_NUMNODES;
>> @@ -5129,6 +5214,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,
>>
>> if (!ret)
>> ret = register_memsw_files(cont, ss);
>> +
>> + if (!ret)
>> + ret = register_kmem_files(cont, ss);
>> +
>> return ret;
>> }
>>
>> @@ -5665,3 +5754,17 @@ static int __init enable_swap_account(char *s)
>> __setup("swapaccount=", enable_swap_account);
>>
>> #endif
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static int __init disable_kmem_account(char *s)
>> +{
>> + /* consider enabled if no parameter or 1 is given */
>> + if (!strcmp(s, "1"))
>> + do_kmem_account = 1;
>> + else if (!strcmp(s, "0"))
>> + do_kmem_account = 0;
>> + return 1;
>> +}
>> +__setup("kmemaccount=", disable_kmem_account);
>> +
>> +#endif
The infrastructure looks OK, we need better integration with
statistics for kmem usage.
Balbir Singh
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* dccp test-tree [ANNOUNCE] dccp: DCCP-Cubic / CCID-5 subtree available
From: Gerrit Renker @ 2011-09-22 2:50 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev, percomp-pos
Thanks to Ivo for implementing DCCP-Cubic (aka CCID-249, aka CCID-5).
I have added a new subtree for CCID-249 at
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree `ccid5']
Patch based on net-2.6 is at
http://eden-feed.erg.abdn.ac.uk/latest-dccp-ccid5-test-tree.diff.gz
Tarball based on net-2.6 is at
http://eden-feed.erg.abdn.ac.uk/latest-dccp-ccid5-test-tree.tar.bz2
after fixing some whitespace issues in the patch. I will keep it in synch
with the rest of the test tree, please do send any updates you find for CCID-5.
==========================================
Short HOWTO on installing and using CCID-5
==========================================
To clone the ccid5 tree,
git checkout -b ccid5
git pull git://eden-feed.erg.abdn.ac.uk/dccp_exp +ccid5:ccid5
When recompiling the dccp module, set
CONFIG_IP_DCCP_CCID5=y
CONFIG_IP_DCCP_CCID5_DEBUG=y
After installation and modprobing the dccp module, set
echo 249 > /proc/sys/net/dccp/default/tx_ccid
echo 249 > /proc/sys/net/dccp/default/rx_ccid
to use the CCID-5 (resp. CCID-249) module.
On 1Gbit ethernet, I measured up to 776 Mbps with iperf,
on a noisy 2.4Ghz 802.11g it was still 13.7 Mbps.
^ permalink raw reply
* I Need Your Assistance
From: Mr Ahmed Hassan @ 2011-09-22 0:54 UTC (permalink / raw)
Dear Beloved,
I Mr Ahmed Hassan,a Business merchant who is diagnosed with
"Esophageal Cancer"
which
defiled all forms of medical treatment and i have cash deposit of Twenty One
million dollars ($21,000,000,00) that I have with a finance Company abroad,i
need someone to stand as a benefactor,if you are interested indicate your
interest.and i will give you the full details
^ permalink raw reply
* RE: [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: Rasesh Mody @ 2011-09-22 0:54 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, dan.carpenter@oracle.com,
adapter_linux_open_src_team@blc-10-4.brocade.com
In-Reply-To: <20110921.204200.1913137093700457756.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, September 21, 2011 5:42 PM
>
>Applied, but I had to add:
>
>Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
>Please don't leave out bug reporter credit like this.
Thanks for doing it this time, we'll take care of adding the bug reporter in future.
^ permalink raw reply
* Re: [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: David Miller @ 2011-09-22 0:42 UTC (permalink / raw)
To: rmody; +Cc: netdev, dan.carpenter, adapter_linux_open_src_team
In-Reply-To: <1316651510-19646-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Wed, 21 Sep 2011 17:31:50 -0700
> If register_netdev() fails now, then we call mutex_unlock(&bnad->conf_mutex);
> on the error path, but it's already unlocked. So we acquire the lock in error
> path which will be later unlocked after the cleanup.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Applied, but I had to add:
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Please don't leave out bug reporter credit like this.
^ permalink raw reply
* File Your CLaims
From: BMW GROUP @ 2011-09-22 0:12 UTC (permalink / raw)
Your E-mail Have 750,000.00GBP And a brand new BMW X6 35iM, M Sport Saloon car. Please
contact Us for more-details.(Email:wu-claimsdept@w.cn ).Send your name / address / age /
country.
^ permalink raw reply
* RE: bna: PCI Probe Fix
From: Rasesh Mody @ 2011-09-22 0:32 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110920084721.GA8441@elgon.mountain>
>From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
>Sent: Tuesday, September 20, 2011 1:47 AM
>
>There is a problem introduced in 0caa9aaec5 "bna: PCI Probe Fix".
>
>If register_netdev() fails now, then we call mutex_unlock(&bnad-
>>conf_mutex);
>on the error path, but it's already unlocked.
Thanks Dan!
Sent a fix so that we acquire the lock in error path which will be later unlocked after the cleanup.
Regards,
Rasesh
^ permalink raw reply
* [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: Rasesh Mody @ 2011-09-22 0:31 UTC (permalink / raw)
To: netdev; +Cc: dan.carpenter, adapter_linux_open_src_team, Rasesh Mody
If register_netdev() fails now, then we call mutex_unlock(&bnad->conf_mutex);
on the error path, but it's already unlocked. So we acquire the lock in error
path which will be later unlocked after the cleanup.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index abca139..db6c097 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3359,6 +3359,7 @@ probe_success:
return 0;
probe_uninit:
+ mutex_lock(&bnad->conf_mutex);
bnad_res_free(bnad, &bnad->mod_res_info[0], BNA_MOD_RES_T_MAX);
disable_ioceth:
bnad_ioceth_disable(bnad);
--
1.7.1
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-22 0:11 UTC (permalink / raw)
To: lindner_marek; +Cc: b.a.t.m.a.n, netdev
In-Reply-To: <201109220210.05025.lindner_marek@yahoo.de>
From: Marek Lindner <lindner_marek@yahoo.de>
Date: Thu, 22 Sep 2011 02:10:04 +0200
> No, the data structures for the routing lookups remain the same but there will
> be more than one way to fill them with data. You will only use one "filling
> algorithm" at a time, so you will need to select the one you want.
Extend the userspace interface for adding route entries with a boolean
flag. You're using netlink right? If so, this should be trivial by
simply adding a flags attribute if you don't have one already.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: Marek Lindner @ 2011-09-22 0:10 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20110921.200539.1422752575190292433.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thursday, September 22, 2011 02:05:39 David Miller wrote:
> From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
> Date: Thu, 22 Sep 2011 01:39:26 +0200
>
> > To ensure a smooth transition and efficient testing later, we
> > decided to offer a choice of routing algorithm but have not
> > come to a final decision on how to design this choice yet. It
> > either will be a compile time option, a module parameter or a
> > runtime switch. Any suggestions / best practice tips ?
>
> What do you mean by "algorithm"? Do you mean the implementation
> of the data-structure used to perform lookups?
>
> We had two data structures for our main routing table lookup
> implementation in ipv4, this was a mistake. We spent the next couple
> years maintaining two pieces of code, and finally investing lots of
> effort to eliminate the older code.
No, the data structures for the routing lookups remain the same but there will
be more than one way to fill them with data. You will only use one "filling
algorithm" at a time, so you will need to select the one you want.
Regards,
Marek
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-22 0:05 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <201109220139.26897.lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 22 Sep 2011 01:39:26 +0200
> To ensure a smooth transition and efficient testing later, we
> decided to offer a choice of routing algorithm but have not
> come to a final decision on how to design this choice yet. It
> either will be a compile time option, a module parameter or a
> runtime switch. Any suggestions / best practice tips ?
What do you mean by "algorithm"? Do you mean the implementation
of the data-structure used to perform lookups?
We had two data structures for our main routing table lookup
implementation in ipv4, this was a mistake. We spent the next couple
years maintaining two pieces of code, and finally investing lots of
effort to eliminate the older code.
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Rick Jones @ 2011-09-21 23:58 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7A765E.6020701@candelatech.com>
>>> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With
>>> TSO what gets passed to the NIC isn't the MTU, but the
>>> connection's MSS derived (in part at least) from the MTU of the
>>> egress interface. If one had made a setsockopt(TCP_MAX_SEG) call
>>> prior to the connect() or listen() call, presumably that would
>>> have influenced the MSS exchange at connection establishment.
>>
>> Ohh, that looks promising!
>>
>> I'll give that a try.
>
> This works like a charm. I'm so glad I don't need to hack
> a new sockopt!
Glad it works for you.
happy benchmarking,
rick jones
One of these days I'll have to decide if I add that as an option to
netperf, which presently only does the getsockopt(TCP_MAX_SEG). Folks
with a strong preference one way or t'other should feel free to contact
me on the side or via netperf-talk at netperf.org.
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 23:42 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4E7A6225.8040902@candelatech.com>
On 09/21/2011 03:16 PM, Ben Greear wrote:
> On 09/21/2011 03:11 PM, Rick Jones wrote:
>> On 09/21/2011 02:06 PM, Ben Greear wrote:
>>> We saw something interesting while doing some testing
>>> on 3.0.4.
>>>
>>> We configured 2 Ethernet NICs with standard 1500 MTU, and added
>>> a mac-vlan on each, with MTU of 300. The goal was to generate as
>>> many ~300 byte TCP packets as possible, for load testing purposes.
>>> We configured our tool to open sockets on the mac-vlans and send/receive
>>> TCP (IPv4) traffic.
>>
>> Presumably one could instead set static PathMTU entries in the routing tables and accomplish the same thing as you did with the mac-vlans?
>>
>>> This actually seems to work quite nicely, allowing user-space to
>>> do large writes (24k in our case), and it appears have lots of
>>> small packets on the wire. We still need to sniff with external
>>> system to verify this..but packets-per-second counters look good.
>>>
>>> Evidently this all works because macvlans know that the NIC
>>> can do TSO, and the '300' MTU is passed in the big packet
>>> given to the NIC.
>>>
>>> This got me thinking...at least for my purposes, it would be
>>> nice to have a per-socket 'MTU' setting. The idea is that
>>> you could ask the NIC to do the TSO at whatever 'mtu' you
>>> wanted, without having to resort to mac-vlans with artificially
>>> small MTU.
>>>
>>> So, is there any interest in supporting such a socket option?
>>>
>>> I can't think of any use besides TCP traffic load testing, but
>>> perhaps someone else can think of one? Or, is load-testing
>>> enough?
>>
>> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO what gets passed to the NIC isn't the MTU, but the connection's MSS derived (in part at
>> least) from the MTU of the egress interface. If one had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or listen() call, presumably that would have
>> influenced the MSS exchange at connection establishment.
>
> Ohh, that looks promising!
>
> I'll give that a try.
This works like a charm. I'm so glad I don't need to hack
a new sockopt!
Thanks,
Ben
>
> Thanks,
> Ben
>
>>
>> rick jones
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: Marek Lindner @ 2011-09-21 23:39 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20110921.152616.1053525623924985457.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wednesday, September 21, 2011 21:26:16 David Miller wrote:
> > are available in the git repository at:
> > git://git.open-mesh.org/linux-merge.git batman-adv/next
>
> Pulled, thanks Marek.
Pretty sure you are quite busy fighting with your backlog of patches but would
you mind giving some advice on this:
To ensure a smooth transition and efficient testing later, we
decided to offer a choice of routing algorithm but have not
come to a final decision on how to design this choice yet. It
either will be a compile time option, a module parameter or a
runtime switch. Any suggestions / best practice tips ?
Regards,
Marek
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 22:16 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4E7A612C.9090508@hp.com>
On 09/21/2011 03:11 PM, Rick Jones wrote:
> On 09/21/2011 02:06 PM, Ben Greear wrote:
>> We saw something interesting while doing some testing
>> on 3.0.4.
>>
>> We configured 2 Ethernet NICs with standard 1500 MTU, and added
>> a mac-vlan on each, with MTU of 300. The goal was to generate as
>> many ~300 byte TCP packets as possible, for load testing purposes.
>> We configured our tool to open sockets on the mac-vlans and send/receive
>> TCP (IPv4) traffic.
>
> Presumably one could instead set static PathMTU entries in the routing tables and accomplish the same thing as you did with the mac-vlans?
>
>> This actually seems to work quite nicely, allowing user-space to
>> do large writes (24k in our case), and it appears have lots of
>> small packets on the wire. We still need to sniff with external
>> system to verify this..but packets-per-second counters look good.
>>
>> Evidently this all works because macvlans know that the NIC
>> can do TSO, and the '300' MTU is passed in the big packet
>> given to the NIC.
>>
>> This got me thinking...at least for my purposes, it would be
>> nice to have a per-socket 'MTU' setting. The idea is that
>> you could ask the NIC to do the TSO at whatever 'mtu' you
>> wanted, without having to resort to mac-vlans with artificially
>> small MTU.
>>
>> So, is there any interest in supporting such a socket option?
>>
>> I can't think of any use besides TCP traffic load testing, but
>> perhaps someone else can think of one? Or, is load-testing
>> enough?
>
> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO what gets passed to the NIC isn't the MTU, but the connection's MSS derived (in part at
> least) from the MTU of the egress interface. If one had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or listen() call, presumably that would have
> influenced the MSS exchange at connection establishment.
Ohh, that looks promising!
I'll give that a try.
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Rick Jones @ 2011-09-21 22:11 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7A51EE.8010403@candelatech.com>
On 09/21/2011 02:06 PM, Ben Greear wrote:
> We saw something interesting while doing some testing
> on 3.0.4.
>
> We configured 2 Ethernet NICs with standard 1500 MTU, and added
> a mac-vlan on each, with MTU of 300. The goal was to generate as
> many ~300 byte TCP packets as possible, for load testing purposes.
> We configured our tool to open sockets on the mac-vlans and send/receive
> TCP (IPv4) traffic.
Presumably one could instead set static PathMTU entries in the routing
tables and accomplish the same thing as you did with the mac-vlans?
> This actually seems to work quite nicely, allowing user-space to
> do large writes (24k in our case), and it appears have lots of
> small packets on the wire. We still need to sniff with external
> system to verify this..but packets-per-second counters look good.
>
> Evidently this all works because macvlans know that the NIC
> can do TSO, and the '300' MTU is passed in the big packet
> given to the NIC.
>
> This got me thinking...at least for my purposes, it would be
> nice to have a per-socket 'MTU' setting. The idea is that
> you could ask the NIC to do the TSO at whatever 'mtu' you
> wanted, without having to resort to mac-vlans with artificially
> small MTU.
>
> So, is there any interest in supporting such a socket option?
>
> I can't think of any use besides TCP traffic load testing, but
> perhaps someone else can think of one? Or, is load-testing
> enough?
Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO
what gets passed to the NIC isn't the MTU, but the connection's MSS
derived (in part at least) from the MTU of the egress interface. If one
had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or
listen() call, presumably that would have influenced the MSS exchange at
connection establishment.
rick jones
^ permalink raw reply
* MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 21:06 UTC (permalink / raw)
To: netdev
We saw something interesting while doing some testing
on 3.0.4.
We configured 2 Ethernet NICs with standard 1500 MTU, and added
a mac-vlan on each, with MTU of 300. The goal was to generate as
many ~300 byte TCP packets as possible, for load testing purposes.
We configured our tool to open sockets on the mac-vlans and send/receive
TCP (IPv4) traffic.
This actually seems to work quite nicely, allowing user-space to
do large writes (24k in our case), and it appears have lots of
small packets on the wire. We still need to sniff with external
system to verify this..but packets-per-second counters look good.
Evidently this all works because macvlans know that the NIC
can do TSO, and the '300' MTU is passed in the big packet
given to the NIC.
This got me thinking...at least for my purposes, it would be
nice to have a per-socket 'MTU' setting. The idea is that
you could ask the NIC to do the TSO at whatever 'mtu' you
wanted, without having to resort to mac-vlans with artificially
small MTU.
So, is there any interest in supporting such a socket option?
I can't think of any use besides TCP traffic load testing, but
perhaps someone else can think of one? Or, is load-testing
enough?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: e1000e: NIC not working, power management issue?
From: Frederik Himpe @ 2011-09-21 20:57 UTC (permalink / raw)
To: jeffrey.t.kirsher, linux-kernel, netdev
Cc: e1000-devel@lists.sourceforge.net, Lucas Nussbaum, Ronciak, John,
Brandeburg, Jesse, John Ronciak
In-Reply-To: <1316598051.2182.48.camel@jtkirshe-mobl>
On Wed, 2011-09-21 at 02:40 -0700, Jeff Kirsher wrote:
> On Tue, 2011-09-20 at 12:03 -0700, Frederik Himpe wrote:
> > On Sun, 2011-09-18 at 18:04 +0200, Frederik Himpe wrote:
> > > On Sun, 2011-09-18 at 17:38 +0200, Frederik Himpe wrote:
> > >
> > > > I also tried some older Debian kernels and 2.6.34-1~experimental.2 is
> > > > working fine, while 2.6.35-1~experimental.3 (and later kernels I tried)
> > > > is broken, so I guess the problem started between 2.6.34 and 2.6.35.
> > > > Maybe I'll try to bisect now...
> > >
> > > Apparently these old kernels do not build anymore with my recent
> > > toolchain:
> > >
> > > AS arch/x86/kernel/entry_64.o
> > > /tmp/ccksyA7i.s: Assembler messages:
> > > /tmp/ccksyA7i.s: Error: .size expression for do_hypervisor_callback does
> > > not evaluate to a constant
> > >
> > > So I'm stuck here.
> >
> > Any further thing we can do to help this problem getting fixed?
> >
>
> You noted that the problem started between 2.6.34 and 2.6.35, and that
> you were going to try and bisect to find the "problem" patch. How is
> that effort coming along?
I cannot successfully build these kernels with my toolchain (see above).
> It also appears that you copied netdev and lkml on the original email,
> but they appear to have been dropped from the CC earlier on in this
> email discussion. It sounds like it would be prudent to add lkml &
> netdev back on to the email thread with what Jesse & John have suggested
> and seen based on the information provided. This way the power
> management maintainers are aware of the issue and potentially suggest
> other possible fix(es) that have not already been suggested.
Added these lists again.
To resume what we have found up to now: when runtime PM is activated for
the e1000e NIC, it does not wake up when a cable is plugged or when
ethtool is run. Runtime PM has to be deactivated to get the NIC working
again. Apparently this problem started between 2.6.34 and 2.6.35.
--
Frederik Himpe <fhimpe@telenet.be>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-09-21 20:30 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Highlights: IPSEC crash fix, ipv4 FIB rule BUG trigger fix, cure
wireless regression that hard-hangs some APs, eliminate deadlock in
ipw2x00 driver, add bluetooth device IDs for current generation
Mac Mini and Macbook Air.
1) Fix IPSEC crash due to misplaced replay check, from Steffen Klassert.
2) iwlagn revert as a workaround for behavior which has been found to
hard-hang some wireless APs. From Don Fry.
3) FIB rule insertion can trigger BUG in fib_nl_newrule() if the rule
already has a ctarget. Fix from Gao Feng.
4) Fix DMA address validation in IXGBE, from Jesse Brandeburg.
5) Fix tg3 VLAN regression on outbound packets, from Kasper Pedersen.
6) Fix pxa168_eth build failure, missing interrupt.h include, from Tanmay
Upadhyay.
7) netconsole needs to init after built-in drivers, from Lin Ming.
8) gianfar classifier rule handler walks past end of array, fix from
Ben Hutchings.
9) Fix MTU fragment calculations in ppp, we generate frags in situations
where the packet actually fits. From Henry WOng.
10) greth accidently corrupts computed checksum on TX, this happens in the
case where the stack has fully computed the checksum already in sw.
Fix from Daniel Hellstrom.
11) Fix double-free in ipv6_add_dev() failure path. From Roy Li.
12) b43 should not issue wireless beacons in ad-hoc mode, fix from Manual Munz.
13) Add bluetooth device IDs for 2011 Mac Mini and Macbook Air, from Jurgen
Kramer and Pieter-Augustijn Van Malleghem.
14) r8169 bug fixes from Hayes Wang and Francois Romieu:
a) Make sure TX processes are really stopped on rtl8111ev1 before
spinning on TXCFG_EMPTY bit to clear.
b) Add missing MODULE_FIRMWARE entry for RTL8111E-VL
c) Set proper RxConfig bits when wake-on-lan is enabled.
d) Fix intepretation of RX descriptor status bits.
e) Only check TBI bit in PHY status on old 8169 parts.
15) Make sure rate mask is updated properly in cfg80211_conn_scan(), from
Rajkumar Manoharan.
16) rtl2800usb MAC address storage endian fix, from Larry Finger.
17) Fix rx2x00 compile error on PowerPC.
18) Fix RTNL mutex deadlock regression in ipw2x00 driver. From Stanislaw Gruszka.
19) Make sure beacon hint flag is cleared when necessary, otherwise updates
are ignored and lost. From Rajkumar Manoharan.
20) Fix ordering of HCI_MGMT vs. HCI_INQUIRY state bits in bluetooth to
fix scanning timeouts. From Oliver Neukum.
Please pull, thanks a lot!
The following changes since commit 38867a28a7dc9d69389990bcd42f6b7c77da3d9d:
Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-soc (2011-09-20 14:23:16 -0700)
are available in the git repository at:
git://github.com/davem330/net.git master
Ben Hutchings (1):
gianfar: Fix overflow check and return value for gfar_get_cls_all()
Chen Ganir (1):
Bluetooth: Fixed BT ST Channel reg order
Daniel Hellstrom (2):
GRETH: RX/TX bytes were never increased
GRETH: avoid overwrite IP-stack's IP-frags checksum
David S. Miller (1):
Merge branch 'davem.r8169.fixes' of git://violet.fr.zoreil.com/romieu/linux
Don Fry (1):
iwlagn: workaround bug crashing some APs
Francois Romieu (2):
r8169: remove erroneous processing of always set bit.
r8169: do not enable the TBI for anything but the original 8169.
Gao feng (1):
fib:fix BUG_ON in fib_nl_newrule when add new fib rule
Hayes Wang (3):
r8169: fix the reset setting for 8111evl
r8169: add MODULE_FIRMWARE for the firmware of 8111evl
r8169: fix WOL setting for 8105 and 8111evl
Henry Wong (1):
ppp_generic: fix multilink fragment MTU calculation (again)
Jesse Brandeburg (1):
ixgbe: fix possible null buffer error
John W. Linville (2):
Merge branch 'for-3.1' of git://github.com/padovan/bluetooth-next
Merge branch 'master' of ssh://infradead/~/public_git/wireless into for-davem
Jurgen Kramer (1):
Bluetooth: add support for 2011 mac mini
Kasper Pedersen (1):
tg3: fix VLAN tagging regression
Larry Finger (2):
rt2800pci: Fix compiler error on PowerPC
rtl2800usb: Fix incorrect storage of MAC address on big-endian platforms
Lin Ming (1):
netconsole: switch init_netconsole() to late_initcall
Manual Munz (1):
b43: Fix beacon problem in ad-hoc mode
Oliver Neukum (1):
Bluetooth: Fix timeout on scanning for the second time
Pieter-Augustijn Van Malleghem (1):
Bluetooth: Add MacBookAir4,1 support
Rajkumar Manoharan (2):
wireless: Reset beacon_found while updating regulatory
wireless: Fix rate mask for scan request
Roy Li (1):
ipv6: fix a possible double free
Stanislaw Gruszka (1):
ipw2x00: fix rtnl mutex deadlock
Steffen Klassert (1):
xfrm: Perform a replay check after return from async codepaths
Tanmay Upadhyay (1):
net: pxa168: Fix build errors by including interrupt.h
drivers/bluetooth/btusb.c | 6 ++++
drivers/bluetooth/btwilink.c | 16 +++++-----
drivers/net/gianfar_ethtool.c | 8 ++--
drivers/net/greth.c | 12 ++++++-
drivers/net/greth.h | 1 +
drivers/net/ixgbe/ixgbe_main.c | 4 +-
drivers/net/netconsole.c | 8 ++++-
drivers/net/ppp_generic.c | 7 ++++-
drivers/net/pxa168_eth.c | 1 +
drivers/net/r8169.c | 32 +++++++++++++++++---
drivers/net/tg3.c | 2 -
drivers/net/wireless/b43/main.c | 3 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 21 +++++++++----
drivers/net/wireless/ipw2x00/ipw2200.c | 39 +++++++++++++++++--------
drivers/net/wireless/iwlwifi/iwl-agn.c | 5 +++
drivers/net/wireless/rt2x00/rt2800lib.c | 47 +++++++++++++++++--------------
net/bluetooth/hci_event.c | 17 +++++------
net/core/fib_rules.c | 4 +-
net/ipv6/addrconf.c | 4 +-
net/wireless/reg.c | 1 +
net/wireless/sme.c | 2 +
net/xfrm/xfrm_input.c | 5 +++
22 files changed, 165 insertions(+), 80 deletions(-)
^ permalink raw reply
* RE: [net-next 0/8][pull request] Intel Wired LAN Driver Update
From: Rose, Gregory V @ 2011-09-21 19:58 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, konrad.wilk@oracle.com,
ijc@hellion.org.uk
In-Reply-To: <20110921.151345.393155542435419672.davem@davemloft.net>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Wednesday, September 21, 2011 12:14 PM
> To: Kirsher, Jeffrey T
> Cc: netdev@vger.kernel.org; gospo@redhat.com
> Subject: Re: [net-next 0/8][pull request] Intel Wired LAN Driver Update
>
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Wed, 21 Sep 2011 03:12:46 -0700
>
> > - reconfigure SR-IOV init to take advantage of the new pci flag
>
> Has this gotten any review from the PCI maintainers?
Yes, when it was posted as an RFC back in July. It was deemed acceptable at the time.
See inline mail below.
We probably should have copied Ian Campbell on Konrad Wilk. I have added them to the CC line in this response.
- Greg
From: netdev-owner@vger.kernel.org on behalf of Rose, Gregory V [gregory.v.rose@intel.com]
Sent: Friday, July 29, 2011 9:55 AM
To: Jesse Barnes; Ian Campbell
Cc: Konrad Rzeszutek Wilk; netdev@vger.kernel.org; davem@davemloft.net; bhutchings@solarflare.com; Kirsher, Jeffrey T; linux-pci@vger.kernel.org
Subject: RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Friday, July 29, 2011 9:52 AM
> To: Ian Campbell
> Cc: Rose, Gregory V; Konrad Rzeszutek Wilk; netdev@vger.kernel.org;
> davem@davemloft.net; bhutchings@solarflare.com; Kirsher, Jeffrey T; linux-
> pci@vger.kernel.org
> Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Thu, 28 Jul 2011 16:11:17 +0100
> Ian Campbell <ijc@hellion.org.uk> wrote:
>
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Device drivers that create and destroy SR-IOV virtual functions via
> > > calls to pci_enable_sriov() and pci_disable_sriov can cause
> catastrophic
> > > failures if they attempt to destroy VFs while they are assigned to
> > > guest virtual machines. By adding a flag for use by the KVM module
> > > to indicate that a device is assigned a device driver can check that
> > > flag and avoid destroying VFs while they are assigned and avoid system
> > > failures.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/pci.h | 2 ++
> >
> > I added Jesse and linux-pci to CC.
> >
> > > virt/kvm/assigned-dev.c | 2 ++
> > > virt/kvm/iommu.c | 4 ++++
> > > 3 files changed, 8 insertions(+), 0 deletions(-)
> >
> > I suppose this would also be useful in Xen's pciback or any other system
> > which does passthrough? (Konrad CC'd for pciback)
> >
> > Is there some common lower layer we could hook this in to? (does
> > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > manipulations to pciback as well?
> >
> > Ian.
> >
> > >
> > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > index 2d29218..a297ca2 100644
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -174,6 +174,8 @@ enum pci_dev_flags {
> > > PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force pci_dev_flags_t) 1,
> > > /* Device configuration is irrevocably lost if disabled into D3 */
> > > PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> > > + /* Provide indication device is assigned by KVM */
> > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > };
>
> Looks fine, but I'd make the comment less redundant with the code, e.g.
> "set when the device is assigned to a guest instance" or somesuch.
Sure, sounds good to me.
Rev 2 of the RFC patches will be out in a couple of weeks, I'm away next week.
Thanks,
- Greg
>
> --
> Jesse Barnes, Intel Open Source Technology Center
--
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
* [RFC PATCH] net: Always fire at least one linkwatch event
From: Neil Horman @ 2011-09-21 19:51 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller, jfeeney
It was recently noted that the tg3 driver had a problem in that after boot a
kernel and if-upping the tg3 interface the sysfs operstate attribute continued
to read 'unkown'. This was happening because tg3 assumes the default carrier
state (which is to say the __LINK_STATE_NOCARRIER bit is clear) is correct.
That said, when the device is if-upped, and the open path, calls
netif_carrier_on, the test_and_set_bit call in that function returns false
(since the bit was previously zero from its initial state). This means that
netif_carrier_on call never generates a linkwatch event, and as a result
dev->operstate never gets recomputed. This could be fixed by unconditionally
calling netif_carrier_off in the probe routine, to simply force a state change
on that bit, but that seems like a sub-par solution, given that many drivers may
have this error. Instead it seems like it might be better to burn an extra bit
in the state field to indicate that the CARRIER bit is still in the initial
state and our first call to netif_carrier_[off|on] should always fire a
linkwatch event.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: jfeeney@redhat.com
---
include/linux/netdevice.h | 1 +
net/sched/sch_generic.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a7f619..85d6f68 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -306,6 +306,7 @@ enum netdev_state_t {
__LINK_STATE_NOCARRIER,
__LINK_STATE_LINKWATCH_PENDING,
__LINK_STATE_DORMANT,
+ __LINK_STATE_CARRIER_INIT,
};
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 69fca27..6f8bfd1 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -298,7 +298,9 @@ static void dev_watchdog_down(struct net_device *dev)
*/
void netif_carrier_on(struct net_device *dev)
{
- if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state)) {
+ int force = !test_and_set_bit(__LINK_STATE_CARRIER_INIT, &dev->state);
+
+ if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state) || force) {
if (dev->reg_state == NETREG_UNINITIALIZED)
return;
linkwatch_fire_event(dev);
@@ -316,7 +318,9 @@ EXPORT_SYMBOL(netif_carrier_on);
*/
void netif_carrier_off(struct net_device *dev)
{
- if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state)) {
+ int force = !test_and_set_bit(__LINK_STATE_CARRIER_INIT, &dev->state);
+
+ if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state) || force) {
if (dev->reg_state == NETREG_UNINITIALIZED)
return;
linkwatch_fire_event(dev);
--
1.7.6.2
^ permalink raw reply related
* Re: [PATCH] macmace, macsonic: cleanup
From: David Miller @ 2011-09-21 19:31 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, netdev
In-Reply-To: <alpine.LNX.2.00.1109140317300.20729@nippy.intranet>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Wed, 14 Sep 2011 03:30:25 +1000 (EST)
>
> We check ether_type before registering the platform device in
> arch/m68k/mac/config.c. Doing the same test again in the driver is
> redundant so remove it.
>
> Multiple probes should not happen since the conversion to platform devices,
> so lose that test too.
>
> Then macmace.c need not include macintosh.h, so remove that and irq.h and
> include linux/interrupt.h explicitly.
>
> Tested on PowerBook 520, Quadra 660av, LC 630.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Applied to net-next, thanks.
^ permalink raw reply
* [patch 1/1] connector: add comm change event report to proc connector
From: akpm @ 2011-09-21 19:26 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, vzapolskiy, zbr
From: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Subject: connector: add comm change event report to proc connector
Add an event to monitor comm value changes of tasks. Such an event
becomes vital, if someone desires to control threads of a process in
different manner.
A natural characteristic of threads is its comm value, and helpfully
application developers have an opportunity to change it in runtime.
Reporting about such events via proc connector allows to fine-grain
monitoring and control potentials, for instance a process control daemon
listening to proc connector and following comm value policies can place
specific threads to assigned cgroup partitions.
It might be possible to achieve a pale partial one-shot likeness without
this update, if an application changes comm value of a thread generator
task beforehand, then a new thread is cloned, and after that proc
connector listener gets the fork event and reads new thread's comm value
from procfs stat file, but this change visibly simplifies and extends the
matter.
Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@google.com>
---
drivers/connector/cn_proc.c | 26 ++++++++++++++++++++++++++
include/linux/cn_proc.h | 11 +++++++++++
kernel/sys.c | 1 +
3 files changed, 38 insertions(+)
diff -puN drivers/connector/cn_proc.c~connector-add-comm-change-event-report-to-proc-connector drivers/connector/cn_proc.c
--- a/drivers/connector/cn_proc.c~connector-add-comm-change-event-report-to-proc-connector
+++ a/drivers/connector/cn_proc.c
@@ -205,6 +205,32 @@ void proc_ptrace_connector(struct task_s
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_comm_connector(struct task_struct *task)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ struct timespec ts;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg *)buffer;
+ ev = (struct proc_event *)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_COMM;
+ ev->event_data.comm.process_pid = task->pid;
+ ev->event_data.comm.process_tgid = task->tgid;
+ get_task_comm(ev->event_data.comm.comm, task);
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_exit_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff -puN include/linux/cn_proc.h~connector-add-comm-change-event-report-to-proc-connector include/linux/cn_proc.h
--- a/include/linux/cn_proc.h~connector-add-comm-change-event-report-to-proc-connector
+++ a/include/linux/cn_proc.h
@@ -54,6 +54,7 @@ struct proc_event {
PROC_EVENT_GID = 0x00000040,
PROC_EVENT_SID = 0x00000080,
PROC_EVENT_PTRACE = 0x00000100,
+ PROC_EVENT_COMM = 0x00000200,
/* "next" should be 0x00000400 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
@@ -103,6 +104,12 @@ struct proc_event {
__kernel_pid_t tracer_tgid;
} ptrace;
+ struct comm_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ char comm[16];
+ } comm;
+
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -118,6 +125,7 @@ void proc_exec_connector(struct task_str
void proc_id_connector(struct task_struct *task, int which_id);
void proc_sid_connector(struct task_struct *task);
void proc_ptrace_connector(struct task_struct *task, int which_id);
+void proc_comm_connector(struct task_struct *task);
void proc_exit_connector(struct task_struct *task);
#else
static inline void proc_fork_connector(struct task_struct *task)
@@ -133,6 +141,9 @@ static inline void proc_id_connector(str
static inline void proc_sid_connector(struct task_struct *task)
{}
+static inline void proc_comm_connector(struct task_struct *task)
+{}
+
static inline void proc_ptrace_connector(struct task_struct *task,
int ptrace_id)
{}
diff -puN kernel/sys.c~connector-add-comm-change-event-report-to-proc-connector kernel/sys.c
--- a/kernel/sys.c~connector-add-comm-change-event-report-to-proc-connector
+++ a/kernel/sys.c
@@ -1760,6 +1760,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
sizeof(me->comm) - 1) < 0)
return -EFAULT;
set_task_comm(me, comm);
+ proc_comm_connector(me);
return 0;
case PR_GET_NAME:
get_task_comm(comm, me);
_
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-21 19:26 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1315500051-1122-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 8 Sep 2011 18:40:44 +0200
> The following changes since commit a943cac144e035c21d4f1b31b95f15b33c33a480:
>
> batman-adv: merge update_transtable() into tt related code (2011-08-22 15:16:22 +0200)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/next
Pulled, thanks Marek.
^ 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