Re: [PATCH net 000/117] net: avoid to remove module when its debugfs is being used
Taehee Yoo writes: > On Fri, 9 Oct 2020 at 01:14, Johannes Berg wrote: > On Thu, 2020-10-08 at 15:59 +, David Laight wrote: > >> From: Taehee Yoo >> > Sent: 08 October 2020 16:49 >> > >> > When debugfs file is opened, its module should not be removed until >> > it's closed. >> > Because debugfs internally uses the module's data. >> > So, it could access freed memory. Yes, the file_operations' ->release() to be more specific -- that's not covered by debugfs' proxy fops. >> > In order to avoid panic, it just sets .owner to THIS_MODULE. >> > So that all modules will be held when its debugfs file is opened. >> >> Can't you fix it in common code? > >> Yeah I was just wondering that too - weren't the proxy_fops even already >> intended to fix this? > > I didn't try to fix this issue in the common code(debugfs). > Because I thought It's a typical pattern of panic and THIS_MODULE > can fix it clearly. > So I couldn't think there is a root reason in the common code. That's correct, ->owner should get set properly, c.f. my other mail in this thread. Thanks, Nicolai -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer
Re: [PATCH net 000/117] net: avoid to remove module when its debugfs is being used
Johannes Berg writes:
> On Thu, 2020-10-08 at 15:59 +, David Laight wrote:
>> From: Taehee Yoo
>> > Sent: 08 October 2020 16:49
>> >
>> > When debugfs file is opened, its module should not be removed until
>> > it's closed.
>> > Because debugfs internally uses the module's data.
>> > So, it could access freed memory.
>> >
>> > In order to avoid panic, it just sets .owner to THIS_MODULE.
>> > So that all modules will be held when its debugfs file is opened.
>>
>> Can't you fix it in common code?
Probably not: it's the call to ->release() that's faulting in the Oops
quoted in the cover letter and that one can't be protected by the
core debugfs code, unfortunately.
There's a comment in full_proxy_release(), which reads as
/*
* We must not protect this against removal races here: the
* original releaser should be called unconditionally in order
* not to leak any resources. Releasers must not assume that
* ->i_private is still being meaningful here.
*/
> Yeah I was just wondering that too - weren't the proxy_fops even already
> intended to fix this?
No, as far as file_operations are concerned, the proxy fops's intent was
only to ensure that the memory the file_operations' ->owner resides in
is still valid so that try_module_get() won't splat at file open
(c.f. [1]).
You're right that the default "full" proxy fops do prevent all
file_operations but ->release() from getting invoked on removed files,
but the motivation had not been to protect the file_operations
themselves, but accesses to any stale data associated with removed files
([2]).
> The modules _should_ be removing the debugfs files, and then the
> proxy_fops should kick in, no?
No, as said, not for ->release(). I haven't looked into the inidividual
patches here, but setting ->owner indeed sounds like the right thing to
do.
But you're right that modules should be removing any left debugfs files
at exit.
Thanks,
Nicolai
[1] 9fd4dcece43a ("debugfs: prevent access to possibly dead
file_operations at file open")
[2] 49d200deaa68 ("debugfs: prevent access to removed files' private data")
--
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Felix Imendörffer
[PATCH v2] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
due to concurrent updates by reading this bit-field member into a local
variable and using the thus stabilized value in subsequent tests.
However, aforementioned commit also adds the (correct) comment that
/* hdrincl should be READ_ONCE(inet->hdrincl)
* but READ_ONCE() doesn't work with bit fields
*/
because as it stands, the compiler is free to shortcut or even eliminate
the local variable at its will.
Note that I have not seen anything like this happening in reality and thus,
the concern is a theoretical one.
However, in order to be on the safe side, emulate a READ_ONCE() on the
bit-field by doing it on the local 'hdrincl' variable itself:
int hdrincl = inet->hdrincl;
hdrincl = READ_ONCE(hdrincl);
This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange
---
Compile-tested only (with inspection of compiler output on x86_64).
Note that there's still a ->hdrincl reload, but that's due to the
inet_sk_flowi_flags() invocation and probably harmless.
Applicable to linux-next-20180108.
Changes to v2:
- Apply review from Stefano Brivio, i.e. drop the __hdrincl
intermediate, update comment and commit message accordingly.
net/ipv4/raw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 5b9bd5c33d9d..6717cf2008f0 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -520,9 +520,11 @@ static int raw_sendmsg(struct sock *sk, struct msghdr
*msg, size_t len)
goto out;
/* hdrincl should be READ_ONCE(inet->hdrincl)
-* but READ_ONCE() doesn't work with bit fields
+* but READ_ONCE() doesn't work with bit fields.
+* Doing this indirectly yields the same result.
*/
hdrincl = inet->hdrincl;
+ hdrincl = READ_ONCE(hdrincl);
/*
* Check the flags.
*/
--
2.13.6
Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
Hi Stefano, Stefano Brivio writes: > On Tue, 2 Jan 2018 17:30:20 +0100 > Nicolai Stange wrote: > >> [...] >> >> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c >> index 5b9bd5c33d9d..e84290c28c0c 100644 >> --- a/net/ipv4/raw.c >> +++ b/net/ipv4/raw.c >> @@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct msghdr >> *msg, size_t len) >> int err; >> struct ip_options_data opt_copy; >> struct raw_frag_vec rfv; >> -int hdrincl; >> +int hdrincl, __hdrincl; >> >> err = -EMSGSIZE; >> if (len > 0x) >> goto out; >> >> /* hdrincl should be READ_ONCE(inet->hdrincl) >> - * but READ_ONCE() doesn't work with bit fields >> + * but READ_ONCE() doesn't work with bit fields. >> + * Emulate it by doing the READ_ONCE() from an intermediate int. >> */ >> -hdrincl = inet->hdrincl; >> +__hdrincl = inet->hdrincl; >> +hdrincl = READ_ONCE(__hdrincl); > > I guess you don't actually need to use a third variable. What about > doing READ_ONCE() on hdrincl itself after the first assignment? > > Perhaps something like the patch below -- applies to net.git, yields > same binary output as your version with gcc 6, looks IMHO more > straightforward: > > diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c > index 125c1eab3eaa..8c2f783a95fc 100644 > --- a/net/ipv4/raw.c > +++ b/net/ipv4/raw.c > @@ -519,10 +519,12 @@ static int raw_sendmsg(struct sock *sk, struct msghdr > *msg, size_t len) > if (len > 0x) > goto out; > > - /* hdrincl should be READ_ONCE(inet->hdrincl) > - * but READ_ONCE() doesn't work with bit fields > + /* hdrincl should be READ_ONCE(inet->hdrincl) but READ_ONCE() doesn't > + * work with bit fields. Emulate it by adding a further sequence point. >*/ > hdrincl = inet->hdrincl; > + hdrincl = READ_ONCE(hdrincl); > + Yes, this does also work. In fact, after having been lowered into SSA form, it should be equivalent to what I posted. So, it's a matter of preference/style and I'd leave the decision on this to the maintainers -- for me, either way is fine. I don't like the "sequence point" wording in the comment above though: AFAICS, if taken in the meaning of C99, it's not any sequence point but the volatile access in READ_ONCE() which ensures that there won't be any reloads from ->hdrincl. If you don't mind, I'll adjust that comment if asked to resend with your solution. Thanks, Nicolai
[PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
due to concurrent updates by reading this bit-field member into a local
variable and using the thus stabilized value in subsequent tests.
However, aforementioned commit also adds the (correct) comment that
/* hdrincl should be READ_ONCE(inet->hdrincl)
* but READ_ONCE() doesn't work with bit fields
*/
because as it stands, the compiler is free to shortcut or even eliminate
the local variable at its will.
Note that I have not seen anything like this happening in reality and thus,
the concern is a theoretical one.
However, in order to be on the safe side, emulate a READ_ONCE() on the
bit-field by introducing an intermediate local variable and doing a
READ_ONCE() from it:
int __hdrincl = inet->hdrincl;
int hdrincl = READ_ONCE(__hdrincl);
This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange
---
Compile-tested only (with inspection of compiler output on x86_64).
Applicable to linux-next-20180102.
net/ipv4/raw.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 5b9bd5c33d9d..e84290c28c0c 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct msghdr
*msg, size_t len)
int err;
struct ip_options_data opt_copy;
struct raw_frag_vec rfv;
- int hdrincl;
+ int hdrincl, __hdrincl;
err = -EMSGSIZE;
if (len > 0x)
goto out;
/* hdrincl should be READ_ONCE(inet->hdrincl)
-* but READ_ONCE() doesn't work with bit fields
+* but READ_ONCE() doesn't work with bit fields.
+* Emulate it by doing the READ_ONCE() from an intermediate int.
*/
- hdrincl = inet->hdrincl;
+ __hdrincl = inet->hdrincl;
+ hdrincl = READ_ONCE(__hdrincl);
/*
* Check the flags.
*/
--
2.13.6
Re: [PATCH net-next 10/13] debugfs: constify argument to debugfs_real_fops()
Hi Jakub,
thanks for this.
However, the debugfs maintainer, Greg K-H, as well as the lkml is
missing from the To/Cc. Can you resend please?
Jakub Kicinski writes:
> seq_file users can only access const version of file pointer,
... because the ->file member of struct seq_operations is marked as such.
> make parameter to debugfs_real_fops() const.
>
> CC: Nicolai Stange
> CC: Christian Lamparter
> Signed-off-by: Jakub Kicinski
> ---
> include/linux/debugfs.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index 4d3f0d1aec73..bf1907d96097 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -52,7 +52,8 @@ struct debugfs_regset32 {
> * Must only be called under the protection established by
> * debugfs_use_file_start().
> */
> -static inline const struct file_operations *debugfs_real_fops(struct file
> *filp)
> +static inline const struct file_operations *
> +debugfs_real_fops(const struct file *filp)
> __must_hold(&debugfs_srcu)
> {
> /*
Re: [PATCH v2] net, socket, socket_wq: fix missing initialization of flags
David Miller writes:
> From: Nicolai Stange
> Date: Tue, 29 Dec 2015 13:29:55 +0100
>
>> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
>>
>> Commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") from
>> the current 4.4 release cycle introduced a new flags member in
>> struct socket_wq and moved SOCKWQ_ASYNC_NOSPACE and SOCKWQ_ASYNC_WAITDATA
>> from struct socket's flags member into that new place.
>>
>> Unfortunately, the new flags field is never initialized properly, at least
>> not for the struct socket_wq instance created in sock_alloc_inode().
>>
>> One particular issue I encountered because of this is that my GNU Emacs
>> failed to draw anything on my desktop -- i.e. what I got is a transparent
>> window, including the title bar. Bisection lead to the commit mentioned
>> above and further investigation by means of strace told me that Emacs
>> is indeed speaking to my Xorg through an O_ASYNC AF_UNIX socket. This is
>> reproducible 100% of times and the fact that properly initializing the
>> struct socket_wq ->flags fixes the issue leads me to the conclusion that
>> somehow SOCKWQ_ASYNC_WAITDATA got set in the uninitialized ->flags,
>> preventing my Emacs from receiving any SIGIO's due to data becoming
>> available and it got stuck.
>>
>> Make sock_alloc_inode() set the newly created struct socket_wq's ->flags
>> member to zero.
>>
>> Signed-off-by: Nicolai Stange
>
> Applied, but please in the future please put the Fixes: tag right
> above the first signoff/ack, like this:
>
> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
> Signed-off-by: Nicolai Stange
Thank you very much!
Regarding the correct position of the "Fixes:" tag: lesson learned.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.4-rc4 regression, bisected to "net: fix sock_wake_async() rcu protection"
Andy Lutomirski writes: > On recent v4.4-rc releases, I can't run emacs. No, really, running > "emacs" in a GNOME 3 session makes gnome-shell think that emacs is > running, but no window is drawn, and the overall system UI is a bit > weird when the invisible emacs window is focused. > > This is 100% reproducible. > > There might be other symptoms involving gdb malfunctioning, but those > are, at best, sporadic. The emacs failure is entirely reliable. I > have no idea what the underlying failure mode is, but failure to wake > a socket waiter seems plausible, I also have no idea why oocalc, > gimp, vim, gedit, firefox, etc aren't affected. > > A somewhat unorthodox "git bisect" run blames: > > commit ceb5d58b217098a657f3850b7a2640f995032e62 > Author: Eric Dumazet > Date: Sun Nov 29 20:03:11 2015 -0800 > > net: fix sock_wake_async() rcu protection > > I've confirmed that v4.4-rc7 with that patch reverted works fine. > > Since the offending commit was apparently a security fix, simply > reverting it might not be the best idea. Please have a look at https://lkml.kernel.org/g/87ege73bma@gmail.com I ran into the same issue and this one fixes it for me. Best, Nicolai -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] net, socket, socket_wq: fix missing initialization of flags
Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
Commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") from
the current 4.4 release cycle introduced a new flags member in
struct socket_wq and moved SOCKWQ_ASYNC_NOSPACE and SOCKWQ_ASYNC_WAITDATA
from struct socket's flags member into that new place.
Unfortunately, the new flags field is never initialized properly, at least
not for the struct socket_wq instance created in sock_alloc_inode().
One particular issue I encountered because of this is that my GNU Emacs
failed to draw anything on my desktop -- i.e. what I got is a transparent
window, including the title bar. Bisection lead to the commit mentioned
above and further investigation by means of strace told me that Emacs
is indeed speaking to my Xorg through an O_ASYNC AF_UNIX socket. This is
reproducible 100% of times and the fact that properly initializing the
struct socket_wq ->flags fixes the issue leads me to the conclusion that
somehow SOCKWQ_ASYNC_WAITDATA got set in the uninitialized ->flags,
preventing my Emacs from receiving any SIGIO's due to data becoming
available and it got stuck.
Make sock_alloc_inode() set the newly created struct socket_wq's ->flags
member to zero.
Signed-off-by: Nicolai Stange
---
Changes to V1 (only commit message changes):
- Uhm, I misread sock_wake_async(). The meaning of the flags is actually
inverted. My Ghostmacs wasn't waiting for free send space, but some
received data becoming available. This makes indeed more sense and I
replaced "SOCKWQ_ASYNC_NOSPACE" by "SOCKWQ_ASYNC_WAITDATA" in my
speculative explanation above.
- Furthermore I fixed some minor grammar issues.
Sorry for any inconvenience this late-night induced brainfart might
have caused at your side...
net/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/socket.c b/net/socket.c
index 29822d6..d730ef9 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -257,6 +257,7 @@ static struct inode *sock_alloc_inode(struct super_block
*sb)
}
init_waitqueue_head(&wq->wait);
wq->fasync_list = NULL;
+ wq->flags = 0;
RCU_INIT_POINTER(ei->socket.wq, wq);
ei->socket.state = SS_UNCONNECTED;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net, socket, socket_wq: fix missing initialization of flags
Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
Commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") from
the current 4.4 release cycle introduces a new flags member in
struct socket_wq and moved SOCKWQ_ASYNC_NOSPACE and SOCKWQ_ASYNC_WAITDATA
from struct socket's flags member into that new place.
Unfortunately, the new flags field is never initialized properly, at least
not for the struct socket_wq instance created in sock_alloc_inode().
One particular issue I encountered because of this is that my GNU Emacs
failed to draw anything on my desktop -- i.e. what I got is a transparent
window, including the title bar. Bisection lead to the commit mentioned
above and further investigation by means of strace told me that Emacs
is indeed speaking to my Xorg through an O_ASYNC AF_UNIX socket. This is
reproducible 100% of times and the fact that properly initializing the
struct socket_wq ->flags fixes the issue leads me to the conclusion that
somehow SOCKWQ_ASYNC_NOSPACE got set in the uninitialized ->flags,
preventing my Emacs from receiving any SIGIO's due to send space becoming
available again and it got stuck.
Make sock_alloc_inode() set the newly created struct socket_wq's ->flags
member to zero.
Signed-off-by: Nicolai Stange
---
net/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/socket.c b/net/socket.c
index 29822d6..d730ef9 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -257,6 +257,7 @@ static struct inode *sock_alloc_inode(struct super_block
*sb)
}
init_waitqueue_head(&wq->wait);
wq->fasync_list = NULL;
+ wq->flags = 0;
RCU_INIT_POINTER(ei->socket.wq, wq);
ei->socket.state = SS_UNCONNECTED;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib: test_bpf: purge CPP register redefinitions
Richard Weinberger writes: > While riding the bus to my office I've materialized that idea. > Nicolai, can you please give the attached patch a try? W/o my test_bpf patch applied, w/ your patch applied: - linux mainline: um compiles - linux-next: um compiles up to this mfd/syscon issue communicated to you in sidechannel In particular, your patch fixes, next to [0], the issue addressed by my patch. -> My 1K line regexp replace patch reduces to a debatable naming style patch. Drop it, sorry for the noise. [0] http://lkml.kernel.org/r/1420386535-22530-1-git-send-email-rich...@nod.at -- To unsubscribe from this list: send the line "unsubscribe netdev" in
Re: [PATCH] isdn: disable HiSax NetJet driver on microblaze arch
Jean Delvare writes:
> Le Sunday 21 June 2015 à 19:59 +0200, Nicolai Stange a écrit :
>> David Miller writes:
>>> Applied, but we're long overdue for an across-the-board-available
>>> endianness Kconfig option that can flat out be used in these situations.
>>> The current way this is handled is at best, a mess.
>>
>> Regarding the general Kconfig endianess symbol, I will do another patch
>> based on the information of
>> git grep '_endian\.h' -- arch/
>> and supply every arch with either of CONFIG_CPU_{LITTLE,BIG}_ENDIAN if
>> lacking.
>
> Note that Chen Gang (Cc'd) attempted the same almost a year ago:
> http://patchwork.linux-mips.org/patch/7540/
> then:
> http://marc.info/?t=14095865642&r=1&w=2
>
> The idea was great IMHO but it did not work out, and I can't remember
> why.
Thank you very much for this pointer, Jean! I've read through these
threads and to summarize, some arch maintainers' main point against that
patchset is that (recent) drivers should generally support both, LE and
BE.
It is interesting to note that Chen Gang had already addressed the very
same issue (Hisax NetJet driver) by the far more general approach
proposed by David Miller here, namely by introducing an
"across-the-board-available endianess Kconfig option".
So unless you really want to have such an option and ping me, I will not
do another patch in the mood of Chen Gang's original one.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
[PATCH] lib: test_bpf: purge CPP register redefinitions
Fix compilation failer with allmodconfig on ARCH=um:
lib/test_bpf.c:50:0: warning: "R8" redefined
#define R8 BPF_REG_8
^
In file included from arch/um/include/asm/ptrace-generic.h:11:0,
from arch/x86/um/asm/ptrace.h:8,
from arch/x86/include/asm/alternative.h:8,
from arch/x86/include/asm/bitops.h:16,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from lib/test_bpf.c:19:
arch/x86/include/uapi/asm/ptrace-abi.h:42:0:
note: this is the location of the previous definition
#define R8 72
Get rid of the
#define Rx BPF_REG_x
defines by substituting the Rx macros with their BPF_REG_x expansion
in test_bpf.c.
Signed-off-by: Nicolai Stange
---
Tested:
- compilation for ARCH=x86_64 and ARCH=um
- 'modprobe test_bpf' on ARCH=x86_64
lib/test_bpf.c | 2374
1 file changed, 1193 insertions(+), 1181 deletions(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 7f58c73..8618325 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -39,19 +39,6 @@
#define SKB_DEV_IFINDEX577
#define SKB_DEV_TYPE 588
-/* Redefine REGs to make tests less verbose */
-#define R0 BPF_REG_0
-#define R1 BPF_REG_1
-#define R2 BPF_REG_2
-#define R3 BPF_REG_3
-#define R4 BPF_REG_4
-#define R5 BPF_REG_5
-#define R6 BPF_REG_6
-#define R7 BPF_REG_7
-#define R8 BPF_REG_8
-#define R9 BPF_REG_9
-#define R10BPF_REG_10
-
/* Flags that can be passed to test cases */
#define FLAG_NO_DATA BIT(0)
#define FLAG_EXPECTED_FAIL BIT(1)
@@ -274,11 +261,11 @@ static int bpf_fill_maxinsns9(struct bpf_test *self)
return -ENOMEM;
insn[0] = BPF_JMP_IMM(BPF_JA, 0, 0, len - 2);
- insn[1] = BPF_ALU32_IMM(BPF_MOV, R0, 0xcbababab);
+ insn[1] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xcbababab);
insn[2] = BPF_EXIT_INSN();
for (i = 3; i < len - 2; i++)
- insn[i] = BPF_ALU32_IMM(BPF_MOV, R0, 0xfefefefe);
+ insn[i] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xfefefefe);
insn[len - 2] = BPF_EXIT_INSN();
insn[len - 1] = BPF_JMP_IMM(BPF_JA, 0, 0, -(len - 1));
@@ -305,7 +292,7 @@ static int bpf_fill_maxinsns10(struct bpf_test *self)
insn[i] = BPF_JMP_IMM(BPF_JA, 0, 0, hlen - 1 - 2 * i);
insn[hlen / 2] = BPF_JMP_IMM(BPF_JA, 0, 0, hlen / 2 - 1);
- insn[hlen] = BPF_ALU32_IMM(BPF_MOV, R0, 0xabababac);
+ insn[hlen] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xabababac);
insn[hlen + 1] = BPF_EXIT_INSN();
self->u.ptr.insns = insn;
@@ -974,13 +961,13 @@ static struct bpf_test tests[] = {
{
"INT: ADD trivial",
.u.insns_int = {
- BPF_ALU64_IMM(BPF_MOV, R1, 1),
- BPF_ALU64_IMM(BPF_ADD, R1, 2),
- BPF_ALU64_IMM(BPF_MOV, R2, 3),
- BPF_ALU64_REG(BPF_SUB, R1, R2),
- BPF_ALU64_IMM(BPF_ADD, R1, -1),
- BPF_ALU64_IMM(BPF_MUL, R1, 3),
- BPF_ALU64_REG(BPF_MOV, R0, R1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_1, 1),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 2),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_2, 3),
+ BPF_ALU64_REG(BPF_SUB, BPF_REG_1, BPF_REG_2),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_MUL, BPF_REG_1, 3),
+ BPF_ALU64_REG(BPF_MOV, BPF_REG_0, BPF_REG_1),
BPF_EXIT_INSN(),
},
INTERNAL,
@@ -990,13 +977,13 @@ static struct bpf_test tests[] = {
{
"INT: MUL_X",
.u.insns_int = {
- BPF_ALU64_IMM(BPF_MOV, R0, -1),
- BPF_ALU64_IMM(BPF_MOV, R1, -1),
- BPF_ALU64_IMM(BPF_MOV, R2, 3),
- BPF_ALU64_REG(BPF_MUL, R1, R2),
- BPF_JMP_IMM(BPF_JEQ, R1, 0xfffd, 1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_0, -1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_2, 3),
+ BPF_ALU64_REG(BPF_MUL, BPF_REG_1, BPF_REG_2),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0xfffd, 1),
BPF_EXIT_INSN(),
- BPF_ALU64_IMM(BPF_MOV, R0, 1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_0, 1),
BPF_EXIT_INSN(),
},
Re: [PATCH] isdn: disable HiSax NetJet driver on microblaze arch
David Miller writes:
>> Note that endianess on microblaze is not determined through Kconfig,
>> but by means of a compiler provided CPP macro, namely __MICROBLAZEEL__.
>> However, gcc defaults to big endianess on that platform.
> Applied, but we're long overdue for an across-the-board-available
> endianness Kconfig option that can flat out be used in these situations.
> The current way this is handled is at best, a mess.
Thanks!
Regarding the general Kconfig endianess symbol, I will do another patch
based on the information of
git grep '_endian\.h' -- arch/
and supply every arch with either of CONFIG_CPU_{LITTLE,BIG}_ENDIAN if
lacking.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
Re: [PATCH] isdn: disable HiSax NetJet driver on microblaze arch
> Acked-by: Jean Delvare Jean, thank you very much for your prompt reaction! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] isdn: disable HiSax NetJet driver on microblaze arch
Fix an allmodconfig compilation failer on microblaze due to big endian architectures being apparently unsupported by the NetJet code: drivers/isdn/hisax/nj_s.c: In function 'setup_netjet_s': drivers/isdn/hisax/nj_s.c:265:2: error: #error "not running on big endian machines now" Modify the relevant Kconfig such that the NetJet code is not built on microblaze anymore. Note that endianess on microblaze is not determined through Kconfig, but by means of a compiler provided CPP macro, namely __MICROBLAZEEL__. However, gcc defaults to big endianess on that platform. Signed-off-by: Nicolai Stange --- The maintainer tree listed under "ISDN SUBSYSTEM" in MAINTAINERS does not exist anymore. I created the diff against the Linus tree. drivers/isdn/hisax/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig index 97465ac..eb83d94 100644 --- a/drivers/isdn/hisax/Kconfig +++ b/drivers/isdn/hisax/Kconfig @@ -237,7 +237,7 @@ config HISAX_MIC config HISAX_NETJET bool "NETjet card" - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN))) + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE)) depends on VIRT_TO_BUS help This enables HiSax support for the NetJet from Traverse @@ -249,7 +249,7 @@ config HISAX_NETJET config HISAX_NETJET_U bool "NETspider U card" - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN))) + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE)) depends on VIRT_TO_BUS help This enables HiSax support for the Netspider U interface ISDN card -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
