* Re: [PATCH v4 14/20] selftests/size: add install target to enable test install
From: Tim Bird @ 2015-01-07 23:05 UTC (permalink / raw)
To: Shuah Khan, mmarek@suse.cz, gregkh@linuxfoundation.org,
akpm@linux-foundation.org, rostedt@goodmis.org, mingo@redhat.com,
davem@davemloft.net, keescook@chromium.org,
tranmanphong@gmail.com, mpe@ellerman.id.au, cov@codeaurora.org,
dh.herrmann@gmail.com, hughd@google.com, bobby.prani@gmail.com,
serge.hallyn@ubuntu.com, ebiederm@xmission.com,
josh@joshtriplett.org, koct9i@gmail.com,
"masami.hiramatsu.pt@hitachi.com" <masami.hiram
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <5861e16e1b533cae37471a8cf18597d3e9e6b6f6.1420571615.git.shuahkh@osg.samsung.com>
On 01/06/2015 11:43 AM, Shuah Khan wrote:
> Add a new make target to enable installing test. This target
> installs test in the kselftest install location and add to the
> kselftest script to run the test. Install target can be run
> only from top level kernel source directory.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> tools/testing/selftests/size/Makefile | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/size/Makefile b/tools/testing/selftests/size/Makefile
> index 04dc25e..a1478fa 100644
> --- a/tools/testing/selftests/size/Makefile
> +++ b/tools/testing/selftests/size/Makefile
> @@ -1,12 +1,22 @@
> CC = $(CROSS_COMPILE)gcc
>
> +TEST_STR = ./get_size || echo 'get_size selftests: [FAIL]'
> +
> all: get_size
>
> get_size: get_size.c
> $(CC) -static -ffreestanding -nostartfiles -s $< -o $@
>
> +install:
> +ifdef INSTALL_KSFT_PATH
> + install ./get_size $(INSTALL_KSFT_PATH)
> + @echo "$(TEST_STR)" >> $(KSELFTEST)
> +else
> + @echo "Run make kselftest_install in top level source directory"
> +endif
> +
> run_tests: all
> - ./get_size
> + @$(TEST_STR)
>
> clean:
> $(RM) get_size
>
Acked-by: Tim Bird <tim.bird@sonymobile.com>
^ permalink raw reply
* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Arend van Spriel @ 2015-01-07 23:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Giel van Schijndel, Andy Shevchenko, linux-kernel, Kalle Valo,
Eliad Peller, John W. Linville, Arik Nemtsov,
open list:TI WILINK WIRELES..., NETWORKING DRIVERS
In-Reply-To: <1420668978.3407.28.camel@sipsolutions.net>
On 01/07/15 23:16, Johannes Berg wrote:
> On Wed, 2015-01-07 at 20:18 +0100, Giel van Schijndel wrote:
>
>> IMO the aligned block of code has the significant advantage of taking
>> advantage of humans' ability to spot things that break a pattern. Which
>> in this case becomes *very* visible when properly aligned, because
>> without the alignment there is no (visual) pattern (or at least not one
>> very suitable for my "visual processing system", I know the same applies
>> to at least some others).
>
> Yeah, well, but why even invoke that "visual processing system"?
>
> If you look, for example, at the __skb_clone function it just uses a
> macro:
>
> #define C(x) n->x = skb->x
This requires fixed names so I generally prefer to add them:
#define C(d, s, f) (d)->f = (s)->f
> and then
>
> C(len);
> C(data_len);
C(acx, conf, window_size);
C(acx, conf, increase_time);
Regards,
Arend
>
> etc.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH iproute2 -next v2] ip: route: add congestion control metric
From: Stephen Hemminger @ 2015-01-07 23:06 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: fw, netdev
In-Reply-To: <1420630098-21621-1-git-send-email-dborkman@redhat.com>
On Wed, 7 Jan 2015 12:28:18 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> + if (i != RTAX_CC_ALGO)
> + val = *(unsigned *)RTA_DATA(mxrta[i]);
Please use rta_getattr_u32 here.
Yes, I know you copied old code, but the old code predated the helper
functions.
^ permalink raw reply
* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Stephen Hemminger @ 2015-01-07 23:08 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <20150107215331.GA19197@angus-think.lan>
On Wed, 7 Jan 2015 23:53:31 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Hi,
>
> I'd like to make possible to generate plot info about class hierarchy
> with qdisc, filters, stats info, but I see that all this staffs are
> printed to 'FILE *fp' which makes this hard to implement and seems to me
> that it should be changed to be printed to 'char *s' (memory safety
> should be considered by asprintf or similar), so this is a big change
> but all this is possible and I ready to do it, but before do it I'd like
> to ask if this could be acceptable as idea.
>
> BUT maybe someone can advise me easier solution ?
>
> Regards,
> --
> 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
Rather than screen scraping tc command, why not use libmnl and get the
data you want programmatically.
^ permalink raw reply
* Re: [patch iproute2 2/2] iplink: print out addrgenmode attribute
From: Stephen Hemminger @ 2015-01-07 23:10 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, thaller
In-Reply-To: <1420561426-3118-2-git-send-email-jiri@resnulli.us>
On Tue, 6 Jan 2015 17:23:46 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> addrgenmode is currently write only by ip. So display this information
> if provided by kernel as well.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Patch does not apply to current iproute2 git
^ permalink raw reply
* Re: [patch iproute2 1/2] libnetlink: add parse_rtattr_one_nested helper
From: Stephen Hemminger @ 2015-01-07 23:15 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, thaller
In-Reply-To: <1420561426-3118-1-git-send-email-jiri@resnulli.us>
On Tue, 6 Jan 2015 17:23:45 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Sometimes, it is more convenient to get only one specific nested attribute by
> type. For example for IFLA_AF_SPEC where type is address family (AF_INET6).
> So add this helper for this purpose.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
This one applies.
^ permalink raw reply
* Re: WIP alternative - was Re: [PATCH v3 14/20] selftests/size: add install target to enable test install
From: Shuah Khan @ 2015-01-07 23:22 UTC (permalink / raw)
To: Tim Bird, mmarek@suse.cz, gregkh@linuxfoundation.org,
akpm@linux-foundation.org, rostedt@goodmis.org, mingo@redhat.com,
davem@davemloft.net, keescook@chromium.org,
tranmanphong@gmail.com, mpe@ellerman.id.au, cov@codeaurora.org,
dh.herrmann@gmail.com, hughd@google.com, bobby.prani@gmail.com,
serge.hallyn@ubuntu.com, ebiederm@xmission.com,
josh@joshtriplett.org, koct9i@gmail.com
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <54AB08AB.7040009@sonymobile.com>
On 01/05/2015 02:56 PM, Tim Bird wrote:
> On 01/05/2015 01:28 PM, Shuah Khan wrote:
>> On 12/31/2014 07:31 PM, Tim Bird wrote:
> ...
>>> The install phase is desperately needed for usage of kselftest in
>>> cross-target situations (applicable to almost all embedded). So this
>>> is great stuff.
>>
>> Thanks.
>>
>>>
>>> I worked a bit on isolating the install stuff to a makefile include file.
>>> This allows simplifying some of the sub-level Makefiles a bit, and allowing
>>> control of some of the install and run logic in less places.
>>>
>>> This is still a work in progress, but before I got too far along, I wanted
>>> to post it for people to provide feedback. A couple of problems cropped
>>> up that are worth discussing, IMHO.
>>>
>>> 1) I think it should be a requirement that each test has a single
>>> "main" program to execute to run the tests. If multiple tests are supported
>>> or more flexibility is desired for additional arguments, or that sort of
>>> thing, then that's fine, but the automated script builder should be able
>>> to run just a single program or script to have things work. This also
>>> makes things more consistent. In the case of the firmware test, I created
>>> a single fw_both.sh script to do this, instead of having two separate
>>> blocks in the kselftest.sh script.
>>
>> It is a good goal for individual tests to use a main program to run
>> tests, even though, I would not make it a requirement. I would like to
>> leave that decision up to the individual test writer.
>>
> OK. It helps to have a single line when trying to isolate
> RUN_TEST creation into the include file, but there may be other
> ways to accomplish this.
>
>>>
>>> 2) I've added a CROSS_INSTALL variable, which can call an arbitrary program
>>> to place files on the target system (rather than just calling 'install').
>>> In my case, I'd use my own 'ttc cp' command, which I can extend as necessary
>>> to put things on a remote machine. This works for a single directory,
>>> but things get dicier with sub-directory trees full of files (like
>>> the ftrace test uses.)
>>>
>>> If additional items need to be installed to the target, then maybe a setup
>>> program should be used, rather than just copying files.
>>>
>>> 3) Some of the scripts were using /bin/bash to execute them, rather
>>> than rely on the interpreter line in the script itself (and having
>>> the script have executable privileges). Is there a reason for this?
>>> I modified a few scripts to be executable, and got rid of the
>>> explicit execution with /bin/bash.
>>
>> Probably no reason other than the choice made by the test writer.
>> It could be cleaned up and made consistent, however, I would see
>> this as a separate enhancement type work that could be done on its
>> own and not include it in the install work.
>
> OK - this was also something that simplified the creation
> of the RUN_TEST variable in the isolated include file.
> Also, having the interpreter explicit in the invocation line
> in the Makefile as well as in the script itself is a bit redundant.
>>>
>>> The following is just a start... Let me know if this direction looks
>>> OK, and I'll finish this up. The main item to look at is
>>> kselftest.include file. Note that these patches are based on Shuah's
>>> series - but if you want to use these ideas I can rebase them onto
>>> mainline, and break them out per test sub-level like Shuah did.
>>
>> One of the reasons I picked install target approach is to enable the
>> feature by extending the existing run_tests support. This way we will
>> have the feature available quickly. Once that is supported, we can work
>> on evolving to a generic approach to use the include file approach, as
>> the changes you are proposing are based on the the series I sent out,
>> and makes improvements to it.
>>
>> kselftest.include file approach could work for several tests and tests
>> that can't use the generic could add their own install support.
>>
>> I propose evolving to a generic kselftest.include as the second step in
>> evolving the install feature. Can I count on you do the work and update
>> the tests to use kselftest.include, CROSS_INSTALL variable support?
>
> Yes. I'd be happy to evolve it through phases to support the include
> file and cross-target install feature.
Thanks that would be great.
>
> Is there anything I can help with in the mean time? Some of the tests
> require a directory tree of files rather than just a few top-level files
> (e.g. ftrace).
I left out couple of tests in this first round. exec and powerpc. Would
you like to add install target support for these tests? That is the next
thing on my list of todo and if you would like to get that working, you
are welcome to.
>
> I was thinking about doing some work to tar-ify the needed directories of
> data files during build, and untar it in the execution area during the
> install step. Do you want me to propose something there?
More like generating tar-ball of the install directory for remote
installs perhaps. Since install feature is using existing Makefile,
user can specify a override install location. Is there a need for,
more like use for generating a tar-ball for remote installs?
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Thomas Graf @ 2015-01-07 23:24 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Linux Netdev List,
Stephen Hemminger, David Miller, Tom Herbert
In-Reply-To: <CAEP_g=_Xr=6nVoeVT8dgRZoM0bNXDiiua5GrjweZ1GaT1ixhZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/07/15 at 02:45pm, Jesse Gross wrote:
> My concern is that having multiple (and potentially overlapping)
> extensions is going to make the VXLAN code very messy and hard to
> follow. I think there's already quite a big of complexity there from
> the DOVE extensions (which are basically dead at this point to the
> best of my knowledge). We already see this some with the discussion
> over the header struct but that's just the beginning - can you imagine
> the code that checks a single bit for several different
> interpretations?
I'm not disagreeing with you Jesse. I think it's manageable though.
I don't think the code as proposed is overly difficult to understand
or messy. I'm glad to adjust the struct definition if the union style
is considered messy, no problem.
We have these reserved bits in a widely used protocol and it is our
choice to make use of these bits or not. My opinion is that we should.
Good candidates to me seem to be GBP for security labels, RCO for
checksumming and GPE for non-L2 over VXLAN.
I would love for everybody to switch over to Geneve or GUE and as you
know I'm highly interested in pushing it forward. Reality is that it
might be another couple of years for it to become fully established.
> Not to mention the fact that the location of the bits
> in some of these proposals has already been shuffled several times. It
> seems very painful...
I don't really want to defend the process behind these drafts. I
believe that code defines the standard, in particular open source code.
As for GBP, we are the authors of the draft and this has been deployed
to hardware as well so this won't change.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Thomas Graf @ 2015-01-07 23:27 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Stephen Hemminger,
David S. Miller
In-Reply-To: <CAADnVQJErdNJrXOOSqEqkbC8524VCH2E9vYL-WdTb_6SGsTwvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/07/15 at 09:32am, Alexei Starovoitov wrote:
> I'm afraid 'union' style with first u8 flags working as selector
> won't work for the case you're describing, but since
> md.gbp = ntohs(vxh->gbp.policy_id);
> 2652: 41 0f b7 55 0a movzwl 0xa(%r13),%edx
> then at least from performance side it's ok at least on x86.
> So this _packed stuff is fine, though not pretty.
> It's internal header, so we can improve it later.
I'm not sure I understand your first sentence but I'm not
married to the code as-is.
Would you like something like this?
struct vxlanhdr_gbp {
__u8 vx_flags;
+#ifdef __LITTLE_ENDIAN_BITFIELD
+ __u8 reserved_flags1:3,
+ policy_applied:1,
+ reserved_flags2:2,
+ dont_learn:1,
+ reserved_flags3:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8 reserved_flags1:1,
+ dont_learn:1,
+ reserved_flags2:2,
+ policy_applied:1,
+ reserved_flags3:3;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
+ __be16 policy_id;
+ __be32 vx_vni;
};
struct vxlanhdr {
+ union {
+ struct {
+#ifdef __LITTLE_ENDIAN_BITFIELD
+ __u8 reserved_flags1:3,
+ vni_present:1,
+ reserved_flags2:3,
+ gbp_present:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8 gbp_present:1,
+ reserved_flags2:3,
+ vni_present:1,
+ reserved_flags1:3;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
+ __u8 vx_reserved1;
+ __be16 vx_reserved2;
+ };
+ __be32 vx_flags;
+ };
+ __be32 vx_vni;
};
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH iproute2 -next v2] ip: route: add congestion control metric
From: Daniel Borkmann @ 2015-01-07 23:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: fw, netdev
In-Reply-To: <20150107150657.1defa6bd@urahara>
On 01/08/2015 12:06 AM, Stephen Hemminger wrote:
> On Wed, 7 Jan 2015 12:28:18 +0100
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
>> + if (i != RTAX_CC_ALGO)
>> + val = *(unsigned *)RTA_DATA(mxrta[i]);
>
> Please use rta_getattr_u32 here.
>
> Yes, I know you copied old code, but the old code predated the helper
> functions.
No problem, that looks better indeed. Will add it.
Btw, while we're on the topic, we ignore errors for all rta_addattr*()
functions f.e. in iproute_modify(). I think at least we should undo the
mxlock in case of an error (or bail out entirely as a different option).
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Alexei Starovoitov @ 2015-01-07 23:39 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, Jesse Gross, Stephen Hemminger, Pravin Shelar,
netdev@vger.kernel.org, dev@openvswitch.org
In-Reply-To: <20150107232740.GE21149@casper.infradead.org>
On Wed, Jan 7, 2015 at 3:27 PM, Thomas Graf <tgraf@suug.ch> wrote:
>
> Would you like something like this?
yes. imo this version is much easier to read
and reason about different bits in protocol.
May be even use a flag mask on '__be32 vx_flags'
instead of calling out 'gbp_present' as explicit bitfield.
Then different vxlan extensions proposals don't
have to fight over positions in the first byte of
single 'struct vxlanhdr'...
but to me the below two structs look good as-is.
> struct vxlanhdr_gbp {
> __u8 vx_flags;
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + policy_applied:1,
> + reserved_flags2:2,
> + dont_learn:1,
> + reserved_flags3:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 reserved_flags1:1,
> + dont_learn:1,
> + reserved_flags2:2,
> + policy_applied:1,
> + reserved_flags3:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __be16 policy_id;
> + __be32 vx_vni;
> };
>
> struct vxlanhdr {
> + union {
> + struct {
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + vni_present:1,
> + reserved_flags2:3,
> + gbp_present:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 gbp_present:1,
> + reserved_flags2:3,
> + vni_present:1,
> + reserved_flags1:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __u8 vx_reserved1;
> + __be16 vx_reserved2;
> + };
> + __be32 vx_flags;
> + };
> + __be32 vx_vni;
> };
>
^ permalink raw reply
* [PATCH 1/1] update ip-sysctl.txt documentation (v2)
From: Ani Sinha @ 2015-01-07 23:45 UTC (permalink / raw)
To: corbet, davem, edumazet, linux-doc, linux-kernel, ani, P, netdev,
fruggeri
Update documentation to reflect the fact that
/proc/sys/net/ipv4/route/max_size is no longer used for ipv4.
Signed-off-by: Ani Sinha <ani@arista.com>
---
Documentation/networking/ip-sysctl.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 9bffdfc..85b0221 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -66,6 +66,8 @@ fwmark_reflect - BOOLEAN
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
+ From linux kernel 3.6 onwards, this is deprecated for ipv4
+ as route cache is no longer used.
neigh/default/gc_thresh1 - INTEGER
Minimum number of entries to keep. Garbage collector will not
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/1] update ip-sysctl.txt documentation
From: Ani Sinha @ 2015-01-07 23:46 UTC (permalink / raw)
To: David Laight
Cc: corbet@lwn.net, davem@davemloft.net, edumazet@google.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
P@draigbrady.com, netdev@vger.kernel.org, fruggeri@arista.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAC2762@AcuExch.aculab.com>
On Wed, Jan 7, 2015 at 2:11 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Ani Sinha
>> Update documentation to reflect the fact that
>> /proc/sys/net/ipv4/route/max_size is no longer used for ipv4.
>>
>> Signed-off-by: Ani Sinha <ani@arista.com>
>> ---
>> Documentation/networking/ip-sysctl.txt | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
>> index 9bffdfc..2a28261 100644
>> --- a/Documentation/networking/ip-sysctl.txt
>> +++ b/Documentation/networking/ip-sysctl.txt
>> @@ -64,8 +64,10 @@ fwmark_reflect - BOOLEAN
>> Default: 0
>>
>> route/max_size - INTEGER
>> - Maximum number of routes allowed in the kernel. Increase
>> - this when using large numbers of interfaces and/or routes.
>> + Post linux kernel 3.6, this is deprecated for ipv4 as route cache is no
>> + longer used. For ipv6, this is used to limit the maximum number of ipv6
>> + routes allowed in the kernel. Increase this when using large numbers of
>> + interfaces and/or routes.
>
> Now imagine you are reading ip-sysctl.txt, the new text is all wrong.
> Something like:
> Limit on the size of the ip route caches.
> Ignored for ipv4 after kernel 3.6 because the ipv4 route cache was removed.
> Increase this when using large numbers of interfaces and/or routes.
> would read better.
Ok please take a look at my patch v2.
^ permalink raw reply
* [PATCH net-next] openvswitch: Add ovs_vport_get_index() to hide vport implementation
From: Daniele Di Proietto @ 2015-01-07 23:48 UTC (permalink / raw)
To: netdev; +Cc: Daniele Di Proietto
datapath.c should not access private vport data. This commit adds
'ovs_vport_get_index()' to vport.c and '.get_index()' to vport_ops
to hide vport implementation details.
Signed-off-by: Daniele Di Proietto <daniele.di.proietto@gmail.com>
---
net/openvswitch/datapath.c | 5 +----
net/openvswitch/vport-internal_dev.c | 1 +
net/openvswitch/vport-netdev.c | 8 ++++++++
net/openvswitch/vport-netdev.h | 1 +
net/openvswitch/vport.c | 9 +++++++++
net/openvswitch/vport.h | 2 ++
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4e9a5f0..a1b113f 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -185,10 +185,7 @@ static int get_dpifindex(const struct datapath *dp)
rcu_read_lock();
local = ovs_vport_rcu(dp, OVSP_LOCAL);
- if (local)
- ifindex = netdev_vport_priv(local)->dev->ifindex;
- else
- ifindex = 0;
+ ifindex = ovs_vport_get_index(local);
rcu_read_unlock();
diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index 6a55f71..d0090b0 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -250,6 +250,7 @@ static struct vport_ops ovs_internal_vport_ops = {
.create = internal_dev_create,
.destroy = internal_dev_destroy,
.get_name = ovs_netdev_get_name,
+ .get_index = ovs_netdev_get_index,
.send = internal_dev_recv,
};
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 4776282..06a4824 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -182,6 +182,13 @@ const char *ovs_netdev_get_name(const struct vport *vport)
return netdev_vport->dev->name;
}
+int ovs_netdev_get_index(const struct vport *vport)
+{
+ const struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
+
+ return netdev_vport->dev->ifindex;
+}
+
static unsigned int packet_length(const struct sk_buff *skb)
{
unsigned int length = skb->len - ETH_HLEN;
@@ -231,6 +238,7 @@ static struct vport_ops ovs_netdev_vport_ops = {
.create = netdev_create,
.destroy = netdev_destroy,
.get_name = ovs_netdev_get_name,
+ .get_index = ovs_netdev_get_index,
.send = netdev_send,
};
diff --git a/net/openvswitch/vport-netdev.h b/net/openvswitch/vport-netdev.h
index 6f7038e..892520a 100644
--- a/net/openvswitch/vport-netdev.h
+++ b/net/openvswitch/vport-netdev.h
@@ -39,6 +39,7 @@ netdev_vport_priv(const struct vport *vport)
}
const char *ovs_netdev_get_name(const struct vport *);
+int ovs_netdev_get_index(const struct vport *);
void ovs_netdev_detach_dev(struct vport *);
int __init ovs_netdev_init(void);
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 53f3ebb..884bba5 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -633,3 +633,12 @@ int ovs_vport_get_egress_tun_info(struct vport *vport, struct sk_buff *skb,
return vport->ops->get_egress_tun_info(vport, skb, info);
}
+
+int ovs_vport_get_index(const struct vport *vport)
+{
+ /* return 0 if get_index is not implemented */
+ if (!vport || !vport->ops->get_index)
+ return 0;
+
+ return vport->ops->get_index(vport);
+}
diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
index 99c8e71..8645dab 100644
--- a/net/openvswitch/vport.h
+++ b/net/openvswitch/vport.h
@@ -57,6 +57,7 @@ int ovs_vport_get_upcall_portids(const struct vport *, struct sk_buff *);
u32 ovs_vport_find_upcall_portid(const struct vport *, struct sk_buff *);
int ovs_vport_send(struct vport *, struct sk_buff *);
+int ovs_vport_get_index(const struct vport *);
int ovs_tunnel_get_egress_info(struct ovs_tunnel_info *egress_tun_info,
struct net *net,
@@ -171,6 +172,7 @@ struct vport_ops {
/* Called with rcu_read_lock or ovs_mutex. */
const char *(*get_name)(const struct vport *);
+ int (*get_index)(const struct vport *);
int (*send)(struct vport *, struct sk_buff *);
int (*get_egress_tun_info)(struct vport *, struct sk_buff *,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] openvswitch: Do not use private netdev_vport fields
From: Daniele Di Proietto @ 2015-01-07 23:49 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, netdev
In-Reply-To: <CALnjE+q6v-vOT7_j52LbytoFSy=fbKU=_MBrp2PWgX4rAKhCBA@mail.gmail.com>
Ok, I've sent the other version of the patch (openvswitch: Add
ovs_vport_get_index() to hide vport implementation).
It adds the .get_index() vport operation (which mimics .get_name())
and ovs_vport_get_index().
Please, let me know which approach you would prefer
Thanks
2015-01-07 7:00 GMT+01:00 Pravin Shelar <pshelar@nicira.com>:
> On Tue, Jan 6, 2015 at 3:32 PM, Daniele Di Proietto
> <daniele.di.proietto@gmail.com> wrote:
>> The motivation for the change is to make datapath.c independent from
>> the actual implementation of the vport. The problem came up when
>> experimenting with other vport implementations and this type of change
>> will help identifying layering violations.
>> You are perfectly right, however, that in this form the code does not
>> improve much: we should rather provide a vport_index() call, and
>> implement one in each of the vports.
>>
>
> This sounds like lot more invasive change compared to the current
> patch. For such change I need to see complete set of changes that you
> are planning.
>
>
>> Thoughts?
>>
>> 2015-01-06 23:28 GMT+01:00 Pravin Shelar <pshelar@nicira.com>:
>>> On Tue, Jan 6, 2015 at 2:15 PM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>> On Tue, Jan 6, 2015 at 2:02 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: Pravin Shelar <pshelar@nicira.com>
>>>>> Date: Tue, 6 Jan 2015 13:16:11 -0800
>>>>>
>>>>>> Function return type and function name should be on same line,
>>>>>> otherwise looks good.
>>>>>
>>>>> I disagree, where is the code in the tree that needs this?
>>>>
>>>> Most of function definitions that I have seen are defined like this. I
>>>> was pointing out coding style issue.
>>>
>>> About the actual change, I think it is a cleanup. netdev_vport_index()
>>> hides the implementation from datapath.c. I hope Daniele will explain
>>> need for the change.
^ permalink raw reply
* Re: [PATCH] sh_eth: Fix access to TRSCER register
From: Nobuhiro Iwamatsu @ 2015-01-07 23:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: netdev@vger.kernel.org, Yoshihiro Shimoda, Linux-sh list
In-Reply-To: <CAMuHMdUyJk+27BsGaZGh+TOqhA5qH4q_pL2hM=tp-Ktn=hkFnw@mail.gmail.com>
Hi,
Thanks for youre review.
(2015/01/07 17:42), Geert Uytterhoeven wrote:
> Hi Iwamatsu-san,
>
> On Wed, Jan 7, 2015 at 6:35 AM, Nobuhiro Iwamatsu
> <nobuhiro.iwamatsu.yj@renesas.com> wrote:
>> TRSCER register is configured differently by SoCs. TRSCER of R-Car is
>> RINT8 bit only valid, other bits are reserved bits.
>> This removes access to TRSCER register reserve bit.
>>
>> Signed-off-by: Nobuhiro Iwamatsu<nobuhiro.iwamatsu.yj@renesas.com>
>> ---
>> drivers/net/ethernet/renesas/sh_eth.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
>> index c29ba80..59ee457 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>> @@ -1294,7 +1294,11 @@ static int sh_eth_dev_init(struct net_device *ndev, bool start)
>> /* Frame recv control (enable multiple-packets per rx irq) */
>> sh_eth_write(ndev, RMCR_RNC, RMCR);
>>
>> - sh_eth_write(ndev, DESC_I_RINT8 | DESC_I_RINT5 | DESC_I_TINT2, TRSCER);
>> + if (mdp->cd->register_type == SH_ETH_REG_FAST_RCAR)
>
> This catches both the R-Car Gen1 and R-Car Gen2 cases.
> According to the datasheets, r8a7778/9 do have the other bits?
> Only R-Car Gen2 doesn't have them.
I see. I checked mistake.
I will resend about this patch.
>
>> + sh_eth_write(ndev, DESC_I_RINT8, TRSCER);
>> + else
>> + sh_eth_write(ndev, DESC_I_RINT8 | DESC_I_RINT5 | DESC_I_TINT2,
>> + TRSCER);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Best regards,
Nobuhiro
^ permalink raw reply
* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Vadim Kochan @ 2015-01-07 23:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vadim Kochan, netdev
In-Reply-To: <20150107150828.5b61f26f@urahara>
On Wed, Jan 07, 2015 at 03:08:28PM -0800, Stephen Hemminger wrote:
> On Wed, 7 Jan 2015 23:53:31 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > Hi,
> >
> > I'd like to make possible to generate plot info about class hierarchy
> > with qdisc, filters, stats info, but I see that all this staffs are
> > printed to 'FILE *fp' which makes this hard to implement and seems to me
> > that it should be changed to be printed to 'char *s' (memory safety
> > should be considered by asprintf or similar), so this is a big change
> > but all this is possible and I ready to do it, but before do it I'd like
> > to ask if this could be acceptable as idea.
> >
> > BUT maybe someone can advise me easier solution ?
> >
> > Regards,
> > --
> > 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
>
> Rather than screen scraping tc command, why not use libmnl and get the
> data you want programmatically.
I'd like to have text info from tc on screen and output on the other
data format to be the same, just only for this.
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Cong Wang @ 2015-01-08 0:00 UTC (permalink / raw)
To: Vadim Kochan; +Cc: Brian Haley, netdev
In-Reply-To: <20150107195517.GA4645@angus-think.lan>
On Wed, Jan 7, 2015 at 11:55 AM, Vadim Kochan <vadim4j@gmail.com> wrote:
> So I think that do not allow to add netns "all" can be a solution, I'd
> like to hear from other people if it might be OK.
>
Nope, that would break existing scripts using "all" as a netns.
^ permalink raw reply
* Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Tom Herbert @ 2015-01-08 0:02 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Linux Netdev List,
Stephen Hemminger, David Miller
In-Reply-To: <20150107232412.GD21149-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On Wed, Jan 7, 2015 at 3:24 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/07/15 at 02:45pm, Jesse Gross wrote:
>> My concern is that having multiple (and potentially overlapping)
>> extensions is going to make the VXLAN code very messy and hard to
>> follow. I think there's already quite a big of complexity there from
>> the DOVE extensions (which are basically dead at this point to the
>> best of my knowledge). We already see this some with the discussion
>> over the header struct but that's just the beginning - can you imagine
>> the code that checks a single bit for several different
>> interpretations?
>
> I'm not disagreeing with you Jesse. I think it's manageable though.
> I don't think the code as proposed is overly difficult to understand
> or messy. I'm glad to adjust the struct definition if the union style
> is considered messy, no problem.
>
> We have these reserved bits in a widely used protocol and it is our
> choice to make use of these bits or not. My opinion is that we should.
> Good candidates to me seem to be GBP for security labels, RCO for
> checksumming and GPE for non-L2 over VXLAN.
>
Do you know how could GPE work with GBP they want to use the same bits
in header for data? Seems like these are mutually exclusive
extensions. RCO should be fine with either :-)
> I would love for everybody to switch over to Geneve or GUE and as you
> know I'm highly interested in pushing it forward. Reality is that it
> might be another couple of years for it to become fully established.
>
>> Not to mention the fact that the location of the bits
>> in some of these proposals has already been shuffled several times. It
>> seems very painful...
>
> I don't really want to defend the process behind these drafts. I
> believe that code defines the standard, in particular open source code.
> As for GBP, we are the authors of the draft and this has been deployed
> to hardware as well so this won't change.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH iproute2 0/3] ip netns: Run over all netns
From: Cong Wang @ 2015-01-08 0:04 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1420628662-9930-1-git-send-email-vadim4j@gmail.com>
On Wed, Jan 7, 2015 at 3:04 AM, Vadim Kochan <vadim4j@gmail.com> wrote:
> From: Vadim Kochan <vadim4j@gmail.com>
>
> Allow 'ip netns del' and 'ip netns exec' run over each network namespace names.
>
> 'ip netns exec' executes command forcely on eacn nsname.
>
Why this has to be done in iproute command?
That is, why not just offloading this to a shell script like below?
for ns in `ip netns show`;
do
ip netns exec $ns ip link show.....
done
^ permalink raw reply
* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Thomas Graf @ 2015-01-08 0:06 UTC (permalink / raw)
To: Vadim Kochan; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20150107234608.GA1073@angus-think.lan>
On 01/08/15 at 01:46am, Vadim Kochan wrote:
> I'd like to have text info from tc on screen and output on the other
> data format to be the same, just only for this.
Look at:
https://github.com/tgraf/libnl/blob/master/src/nl-tctree-list.c
It shows how to use an API to retrieve the information you want and
allows to pretty print tc entries.
^ permalink raw reply
* Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Thomas Graf @ 2015-01-08 0:14 UTC (permalink / raw)
To: Tom Herbert
Cc: Jesse Gross, David Miller, Stephen Hemminger, Pravin B Shelar,
Linux Netdev List, dev@openvswitch.org
In-Reply-To: <CA+mtBx8HDc1OfsuED8afUnTdf562RAyU37tVeKk0ndAm5wMWfQ@mail.gmail.com>
On 01/07/15 at 04:02pm, Tom Herbert wrote:
> Do you know how could GPE work with GBP they want to use the same bits
> in header for data? Seems like these are mutually exclusive
> extensions. RCO should be fine with either :-)
Yes, GBP and GPE are mutually exclusive extensions. Although
GPE would allow to define an intermediate header for additional
metadata, f.e. encoded as GUE or Geneve options.
^ permalink raw reply
* Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Tom Herbert @ 2015-01-08 0:23 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Linux Netdev List,
Stephen Hemminger, David Miller
In-Reply-To: <20150108001401.GG21149-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On Wed, Jan 7, 2015 at 4:14 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/07/15 at 04:02pm, Tom Herbert wrote:
>> Do you know how could GPE work with GBP they want to use the same bits
>> in header for data? Seems like these are mutually exclusive
>> extensions. RCO should be fine with either :-)
>
> Yes, GBP and GPE are mutually exclusive extensions. Although
> GPE would allow to define an intermediate header for additional
> metadata, f.e. encoded as GUE or Geneve options.
The latest GPE draft uses eight bits for next protocol, so if you make
the security field eight bits it would fit nicely in the octet before
the next protocol.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH iproute2] ss: Fix case when UDP is printed as ipproto-xxx
From: Vadim Kochan @ 2015-01-08 0:42 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
When 'ss' prints UDP sockets info together with RAW sockets
e.g.:
$ ss -a
then UDP sockets are resolved as "ipproto-xxx".
It was caused that dg_proto was set after printing UDP
socket info from netlink. So fixed issue by moving
setting dg_proto before printing info from Netlink.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
misc/ss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 08d210a..7c94463 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2287,12 +2287,12 @@ static int udp_show(struct filter *f)
{
FILE *fp = NULL;
+ dg_proto = UDP_PROTO;
+
if (!getenv("PROC_NET_UDP") && !getenv("PROC_ROOT")
&& inet_show_netlink(f, NULL, IPPROTO_UDP) == 0)
return 0;
- dg_proto = UDP_PROTO;
-
if (f->families&(1<<AF_INET)) {
if ((fp = net_udp_open()) == NULL)
goto outerr;
--
2.1.3
^ permalink raw reply related
* [PATCH 2/3] module: remove mod arg from module_free, rename module_memfree().
From: Rusty Russell @ 2015-01-08 0:58 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Mikael Starvik, Jesper Nilsson, Ralf Baechle,
Ley Foon Tan, Benjamin Herrenschmidt, Chris Metcalf,
Steven Rostedt, x86, Alexei Starovoitov,
Ananth N Mavinakayanahalli, Anil S Keshavamurthy,
Masami Hiramatsu, linux-cris-kernel, linux-mips, nios2-dev,
linuxppc-dev, sparclinux, netdev
In-Reply-To: <1420678687-30548-1-git-send-email-rusty@rustcorp.com.au>
Nothing needs the module pointer any more, and the next patch will
call it from RCU, where the module itself might no longer exist.
Removing the arg is the safest approach.
This just codifies the use of the module_alloc/module_free pattern
which ftrace and bpf use.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: x86@kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: linux-cris-kernel@axis.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: nios2-dev@lists.rocketboards.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: netdev@vger.kernel.org
---
arch/cris/kernel/module.c | 2 +-
arch/mips/net/bpf_jit.c | 2 +-
arch/nios2/kernel/module.c | 2 +-
arch/powerpc/net/bpf_jit_comp.c | 2 +-
arch/sparc/net/bpf_jit_comp.c | 4 ++--
arch/tile/kernel/module.c | 2 +-
arch/x86/kernel/ftrace.c | 2 +-
include/linux/moduleloader.h | 2 +-
kernel/bpf/core.c | 2 +-
kernel/kprobes.c | 2 +-
kernel/module.c | 14 +++++++-------
11 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/cris/kernel/module.c b/arch/cris/kernel/module.c
index 51123f985eb5..af04cb6b6dc9 100644
--- a/arch/cris/kernel/module.c
+++ b/arch/cris/kernel/module.c
@@ -36,7 +36,7 @@ void *module_alloc(unsigned long size)
}
/* Free memory returned from module_alloc */
-void module_free(struct module *mod, void *module_region)
+void module_memfree(void *module_region)
{
kfree(module_region);
}
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 9fd6834a2172..5d6139390bf8 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1388,7 +1388,7 @@ out:
void bpf_jit_free(struct bpf_prog *fp)
{
if (fp->jited)
- module_free(NULL, fp->bpf_func);
+ module_memfree(fp->bpf_func);
bpf_prog_unlock_free(fp);
}
diff --git a/arch/nios2/kernel/module.c b/arch/nios2/kernel/module.c
index cc924a38f22a..e2e3f13f98d5 100644
--- a/arch/nios2/kernel/module.c
+++ b/arch/nios2/kernel/module.c
@@ -36,7 +36,7 @@ void *module_alloc(unsigned long size)
}
/* Free memory returned from module_alloc */
-void module_free(struct module *mod, void *module_region)
+void module_memfree(void *module_region)
{
kfree(module_region);
}
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 1ca125b9c226..d1916b577f2c 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -699,7 +699,7 @@ out:
void bpf_jit_free(struct bpf_prog *fp)
{
if (fp->jited)
- module_free(NULL, fp->bpf_func);
+ module_memfree(fp->bpf_func);
bpf_prog_unlock_free(fp);
}
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index f33e7c7a3bf7..7931eeeb649a 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -776,7 +776,7 @@ cond_branch: f_offset = addrs[i + filter[i].jf];
if (unlikely(proglen + ilen > oldproglen)) {
pr_err("bpb_jit_compile fatal error\n");
kfree(addrs);
- module_free(NULL, image);
+ module_memfree(image);
return;
}
memcpy(image + proglen, temp, ilen);
@@ -822,7 +822,7 @@ out:
void bpf_jit_free(struct bpf_prog *fp)
{
if (fp->jited)
- module_free(NULL, fp->bpf_func);
+ module_memfree(fp->bpf_func);
bpf_prog_unlock_free(fp);
}
diff --git a/arch/tile/kernel/module.c b/arch/tile/kernel/module.c
index 62a597e810d6..2305084c9b93 100644
--- a/arch/tile/kernel/module.c
+++ b/arch/tile/kernel/module.c
@@ -74,7 +74,7 @@ error:
/* Free memory returned from module_alloc */
-void module_free(struct module *mod, void *module_region)
+void module_memfree(void *module_region)
{
vfree(module_region);
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 2142376dc8c6..8b7b0a51e742 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -674,7 +674,7 @@ static inline void *alloc_tramp(unsigned long size)
}
static inline void tramp_free(void *tramp)
{
- module_free(NULL, tramp);
+ module_memfree(tramp);
}
#else
/* Trampolines can only be created if modules are supported */
diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
index 054eac853090..f7556261fe3c 100644
--- a/include/linux/moduleloader.h
+++ b/include/linux/moduleloader.h
@@ -26,7 +26,7 @@ unsigned int arch_mod_section_prepend(struct module *mod, unsigned int section);
void *module_alloc(unsigned long size);
/* Free memory returned from module_alloc. */
-void module_free(struct module *mod, void *module_region);
+void module_memfree(void *module_region);
/*
* Apply the given relocation to the (simplified) ELF. Return -error
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index d6594e457a25..a64e7a207d2b 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -163,7 +163,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
void bpf_jit_binary_free(struct bpf_binary_header *hdr)
{
- module_free(NULL, hdr);
+ module_memfree(hdr);
}
#endif /* CONFIG_BPF_JIT */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 06f58309fed2..ee619929cf90 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -127,7 +127,7 @@ static void *alloc_insn_page(void)
static void free_insn_page(void *page)
{
- module_free(NULL, page);
+ module_memfree(page);
}
struct kprobe_insn_cache kprobe_insn_slots = {
diff --git a/kernel/module.c b/kernel/module.c
index 68be0b1f9e7f..1f85fd5c89d3 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1795,7 +1795,7 @@ static void unset_module_core_ro_nx(struct module *mod) { }
static void unset_module_init_ro_nx(struct module *mod) { }
#endif
-void __weak module_free(struct module *mod, void *module_region)
+void __weak module_memfree(void *module_region)
{
vfree(module_region);
}
@@ -1846,7 +1846,7 @@ static void free_module(struct module *mod)
/* This may be NULL, but that's OK */
unset_module_init_ro_nx(mod);
module_arch_freeing_init(mod);
- module_free(mod, mod->module_init);
+ module_memfree(mod->module_init);
kfree(mod->args);
percpu_modfree(mod);
@@ -1855,7 +1855,7 @@ static void free_module(struct module *mod)
/* Finally, free the core (containing the module structure) */
unset_module_core_ro_nx(mod);
- module_free(mod, mod->module_core);
+ module_memfree(mod->module_core);
#ifdef CONFIG_MPU
update_protections(current->mm);
@@ -2790,7 +2790,7 @@ static int move_module(struct module *mod, struct load_info *info)
*/
kmemleak_ignore(ptr);
if (!ptr) {
- module_free(mod, mod->module_core);
+ module_memfree(mod->module_core);
return -ENOMEM;
}
memset(ptr, 0, mod->init_size);
@@ -2936,8 +2936,8 @@ static void module_deallocate(struct module *mod, struct load_info *info)
{
percpu_modfree(mod);
module_arch_freeing_init(mod);
- module_free(mod, mod->module_init);
- module_free(mod, mod->module_core);
+ module_memfree(mod->module_init);
+ module_memfree(mod->module_core);
}
int __weak module_finalize(const Elf_Ehdr *hdr,
@@ -3062,7 +3062,7 @@ static int do_init_module(struct module *mod)
#endif
unset_module_init_ro_nx(mod);
module_arch_freeing_init(mod);
- module_free(mod, mod->module_init);
+ module_memfree(mod->module_init);
mod->module_init = NULL;
mod->init_size = 0;
mod->init_ro_size = 0;
--
2.1.0
^ permalink raw reply related
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