[PATCH] nfsd4: do not compute undefined pointer arithmetic

From: Jason A. Donenfeld ja...@zx2c4.com If statp is NULL, NULL - ptr_value will be computed, which is undefined behavior: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result

Re: [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock

On Fri, Aug 23, 2013 at 8:18 PM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: NACK. This we won't do. It is a LED misuse, and it will get in the way when we finally put that LED to its proper use. Agreed. Please see my response to mjg. -- To unsubscribe from this list: send the line

[PATCH 1/3] Input: atkbd - add LED triggers for keyboard state

-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/input/keyboard/atkbd.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index 2626773..15061bf 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers

[PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock

Thinkpads with a micmute LED do not have a capslock LED. The micmute LED is currently not used by any piece of Linux kernel land or user land. It seems reasonable to hook it up to caps lock, at least by default, so users can have some degree of functionality. Signed-off-by: Jason A. Donenfeld ja

[PATCH 2/3] thinkpad_acpi: Support micmute LED

The micmute LED is currently unused. This patch allows it to be hooked up to various LED triggers. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/platform/x86/thinkpad_acpi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86

Re: [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock

On Thu, Aug 22, 2013 at 5:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think there's a risk of user confusion here, in that it's now possible for the mic mute light to be lit despite the internal microphone still being active. That seems like surprising behaviour. Yeah, that is a

[PATCH] Input: atkbd - add LED triggers for keyboard state

-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/input/keyboard/atkbd.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index 2626773..15061bf 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers

[PATCH] ip_set: remove extraneous log message

-by: Jason A. Donenfeld ja...@zx2c4.com --- net/netfilter/ipset/ip_set_core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c index de770ec..283f197 100644 --- a/net/netfilter/ipset/ip_set_core.c +++ b/net/netfilter/ipset

[PATCH] pl2303: Remove antiquated support for I330 phone

it. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/usb/serial/pl2303.c | 1 - drivers/usb/serial/pl2303.h | 4 2 files changed, 5 deletions(-) diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c index 829604d..f5257af 100644 --- a/drivers/usb/serial/pl2303.c +++ b

Re: [PATCH] pl2303, visor: Match I330 phone more precisely

On Wed, Apr 22, 2015 at 2:38 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: I'd bet this is really a pl2303 device, given that the visor driver was just a dumb pipe to the device and the pilot sync tools never cared about baud rates and the like, so odds are the visor entry should be

[PATCH 2/2] visor: Match I330 phone more precisely

(0xff). Since usb-storage requires an interface class of 0x8, I believe it's correct to disambiguate the two devices by matching on 0xff inside visor. [1] http://permalink.gmane.org/gmane.linux.usb.user/4264 Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/usb/serial/visor.c | 2 +- 1

[PATCH 1/2] pl2303: Remove support for Samsung I330

This phone is already supported by the visor driver. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/usb/serial/pl2303.c | 1 - drivers/usb/serial/pl2303.h | 4 2 files changed, 5 deletions(-) diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c index

[PATCH 1/2] visor: Remove support for Samsung I330

This phone is actually a pl2303 device, and is already supported there. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/usb/serial/visor.c | 2 -- drivers/usb/serial/visor.h | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c

[PATCH 2/2] pl2303: Match I330 phone more precisely

usb-storage requires an interface class of 0x8, I believe it's correct to disambiguate the two devices by matching on 0xff inside pl2303. [1] http://permalink.gmane.org/gmane.linux.usb.user/4264 Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/usb/serial/pl2303.c | 2 +- 1 file

[PATCH] pl2303, visor: Match I330 phone more precisely

to be the interface class, which has value 255 (0xff). Since usb-storage requires an interface class of 0x8, I believe it's correct to disambiguate the two devices by matching on 0xff inside pl2303 and visor. [1] http://permalink.gmane.org/gmane.linux.usb.user/4264 Signed-off-by: Jason A. Donenfeld ja...@zx2c4

[PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities

of the socket buffer. Jason A. Donenfeld (4): ozwpan: Use proper check to prevent heap overflow ozwpan: Use unsigned ints to prevent heap overflow ozwpan: divide-by-zero leading to panic ozwpan: unchecked signed subtraction leads to DoS drivers/staging/ozwpan/ozhcd.c | 8 drivers

[PATCH 2/4] ozwpan: Use unsigned ints to prevent heap overflow

; } usleep(30); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers

[PATCH 1/4] ozwpan: Use proper check to prevent heap overflow

); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c

[PATCH 3/4] ozwpan: divide-by-zero leading to panic

] } }; if (sendto(sockfd, packet, sizeof(packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging

[PATCH 1/4] ozwpan: Use proper check to prevent heap overflow

); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c

[PATCH 4/4] ozwpan: unchecked signed subtraction leads to DoS

) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ozwpan/ozusbsvc1.c b/drivers/staging/ozwpan

[PATCH 3/4] ozwpan: divide-by-zero leading to panic

] } }; if (sendto(sockfd, packet, sizeof(packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging

[PATCH 2/4] ozwpan: Use unsigned ints to prevent heap overflow

; } usleep(30); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers

[PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities

of the socket buffer. Jason A. Donenfeld (4): ozwpan: Use proper check to prevent heap overflow ozwpan: Use unsigned ints to prevent heap overflow ozwpan: divide-by-zero leading to panic ozwpan: unchecked signed subtraction leads to DoS drivers/staging/ozwpan/ozhcd.c | 8 drivers

Re: [oss-security] [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities

On Wed, May 13, 2015 at 8:43 PM, Greg KH g...@kroah.com wrote: Any reason you didn't cc: the maintainer who could actually apply these to the kernel tree? I did, look at the email again: the first recipient is shigekatsu.tat...@atmel.com. From the MAINTAINERS file: STAGING - OZMO DEVICES

[PATCH 4/4] ozwpan: unchecked signed subtraction leads to DoS

) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ozwpan/ozusbsvc1.c b/drivers/staging/ozwpan

Re: [PATCH 1/4] ozwpan: Use proper check to prevent heap overflow

On May 15, 2015 4:10 PM, David Laight david.lai...@aculab.com wrote: Why not just check the length. eg: unsigned int data_len = elt-length; if (data_len sizeof(struct oz_get_desc_rsp) + 1) break; Sure.

[PATCH] netdevice: add netdev_pub helper function

Being able to utilize this makes much code a lot simpler and cleaner. It's a nice convenience function. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- include/linux/netdevice.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux

[PATCH v3 2/4] ozwpan: Use unsigned ints to prevent heap overflow

; } usleep(30); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers

[PATCH v3 0/4] ozwpan: Four remote packet-of-death vulnerabilities

to ensure all reads and casts are within the bounds of the socket buffer. Jason A. Donenfeld (4): ozwpan: Use proper check to prevent heap overflow ozwpan: Use unsigned ints to prevent heap overflow ozwpan: divide-by-zero leading to panic ozwpan: unchecked signed subtraction leads to DoS

[PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow

); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c

[PATCH v3 4/4] ozwpan: unchecked signed subtraction leads to DoS

) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/staging/ozwpan/ozusbsvc1.c b/drivers/staging/ozwpan

[PATCH v3 3/4] ozwpan: divide-by-zero leading to panic

] } }; if (sendto(sockfd, packet, sizeof(packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging

Re: [PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow

On Fri, May 29, 2015 at 2:36 PM, Frans Klaver franskla...@gmail.com wrote: I would say that it is because part of the expression has been placed inside parentheses: a - b + 1 == a - (b - 1) Guess it makes the decision logic slightly more readable. Yes, exactly this. It's so that the

Re: [PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow

On Fri, May 29, 2015 at 2:41 PM, Dan Carpenter dan.carpen...@oracle.com wrote: Acked-by: Dan Carpenter dan.carpen...@oracle.com Acked for the rest of the set too? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More

Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

, 2015 at 8:33 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: On a slightly related note, there are several other vulnerabilities in this driver that are worth looking into. When ozwpan receives a packet, it casts the packet into a variety of different structs, based on the value of type

Re: [oss-security] Re: [PATCH v2 4/4] ozwpan: unchecked signed subtraction leads to DoS

On Thu, May 28, 2015 at 1:04 PM, Dan Carpenter dan.carpen...@oracle.com wrote: It's really not simpler to understand though. Greg - do you want me to resubmit a v3 for this, or does it not really matter and we can address this in another series? Personally, I'm erring on the side of wanting to

Re: Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

On Tue, Jun 2, 2015 at 3:35 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: I don't know, but I'm a bit loath to delete the driver from the tree as then people will just continue to use the version with all of the bugs. Yea, I understand that. Though, I'm pretty sure that most users of

Re: [PATCH] sock: honor GFP_ATOMIC when allocating send skbs

Hi Eric, Thanks for your feedback on this. The precise problem is a BUG in the scheduler code when sleep is called from atomic context, due to having to wait on that allocation. This is triggered by a module I'm writing. I'm probably doing something I shouldn't... I'm calling udp_sendmsg from

[PATCH] sock: honor GFP_ATOMIC when allocating send skbs

context, we need to honor this and not sleep. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- net/core/sock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/core/sock.c b/net/core/sock.c index 1e1fe9a..f00e691 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -1804,34 +1804,37

Searching for mentor - writing kernel-space VPN more

and avx2 implementations of chacha20poly1305 rolling successfully, which I'm quite proud of. Well, hope to hear from somebody soon! Regards, Jason Donenfeld -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo

[PATCH v2 1/4] ozwpan: Use proper check to prevent heap overflow

); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c

[PATCH v2 2/4] ozwpan: Use unsigned ints to prevent heap overflow

; } usleep(30); if (sendto(sockfd, pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers

[PATCH v2 0/4] ozwpan: Four remote packet-of-death vulnerabilities

checks to ensure all reads and casts are within the bounds of the socket buffer. Jason A. Donenfeld (4): ozwpan: Use proper check to prevent heap overflow ozwpan: Use unsigned ints to prevent heap overflow ozwpan: divide-by-zero leading to panic ozwpan: unchecked signed subtraction leads to DoS

[PATCH v2 4/4] ozwpan: unchecked signed subtraction leads to DoS

) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging/ozwpan/ozusbsvc1.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ozwpan/ozusbsvc1.c b/drivers/staging/ozwpan

[PATCH v2 3/4] ozwpan: divide-by-zero leading to panic

] } }; if (sendto(sockfd, packet, sizeof(packet), 0, (struct sockaddr *)socket_address, sizeof(socket_address)) 0) { perror(sendto); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/staging

Re: [PATCH v2 1/4] ozwpan: Use proper check to prevent heap overflow

On Tue, May 26, 2015 at 3:32 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Tue, May 26, 2015 at 02:17:46PM +0200, Jason A. Donenfeld wrote: + data_len = elt-length - sizeof(struct oz_get_desc_rsp) + 1; This was in the original

Re: [oss-security] Re: [PATCH v2 4/4] ozwpan: unchecked signed subtraction leads to DoS

On Tue, May 26, 2015 at 4:06 PM, Dan Carpenter dan.carpen...@oracle.com wrote: You sure do like wrapping to a high value and testing the result for wrapping instead of validating before doing the subtraction... I do indeed. It seems like asking did it overflow? is more straight-forward and

Re: [PATCH v2 1/4] ozwpan: Use proper check to prevent heap overflow

On Tue, May 26, 2015 at 3:56 PM, Dan Carpenter dan.carpen...@oracle.com wrote: elt-length is a u8, so the upper bound is 255. Yes. I know that, but is 255 correct? Eventually body-data is passed to oz_hcd_get_desc_cnf along with data_len. In there, body-data (now called desc) is memcpy'd into

Performance bottleneck with ndo_start_xmit

Hi folks, I'm writing a kernel module that creates a virtual network device with rtnl_link_register. At initialization time, it creates a UDP socket with sock_create_kern. On ndo_start_xmit, it passes the data of the skb to the UDP socket's sendmsg, after some minimal crypto and processing. The

Re: Performance bottleneck with ndo_start_xmit

On Tue, Jul 7, 2015 at 8:10 PM, Stephen Hemminger step...@networkplumber.org wrote: Is it open source, is the source available to look at? If not, please solve your own problems. Yes it is. Right now the repo is under password because it's supposed to keep your data secure, but I haven't

[PATCH] Makefile: Force gzip and xz on module install

and xz will error out if the file already exists, unless -f is passed. This patch adds -f so that the behavior is uniform. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 6c6f146

[PATCH v2] xen-apic: Enable on domU as well

0x in ?? () Mailing-list-thread: https://lkml.org/lkml/2015/8/4/755 Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com Cc: David Vrabel david.vra...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: sta...@vger.kernel.org --- arch/x86/xen/Makefile | 4 ++-- arch/x86/xen

DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

Hi folks, In setting up a socket, there are two functions I make use of that in turn wind up calling static_key_slow_inc: setup_udp_tunnel_sock and sk_set_memalloc. These both make use of static_key_slow_inc because they selectively enable certain important code paths. This is all fine, except

Exporting obscene amounts of data in rtnl_link_ops-fill_info()

Hi guys, I have a new link driver that registers a rtnl_link_ops. For many things, the rtnl interfaces are perfectly suited: I can use netlink in userspace to check out packet counts, adjust interface parameters, and all sorts of things. There is even the fill_info function exporting

Re: DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

Ahhh, interesting, so it turns out you can't do a number of things with a read_lock_bh held, because it increases the softirq count. Mystery solved. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

Bueller? ... Bueller? On Thu, Aug 20, 2015 at 2:39 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: Hi folks, In setting up a socket, there are two functions I make use of that in turn wind up calling static_key_slow_inc: setup_udp_tunnel_sock and sk_set_memalloc. These both make use

Re: Exporting obscene amounts of data in rtnl_link_ops-fill_info()

On Thu, Aug 20, 2015 at 7:59 AM, Scott Feldman sfel...@gmail.com wrote: What kind of data are you sending up? Maybe there is an alternate interface. This is what I'm wondering about: alternative interfaces, that are still kosher in the netlink/rtnl world. Each interface is associated with a

[PATCH] net_dbg_ratelimited: turn into no-op when !DEBUG

with !DEBUG -- nothing. This patch replaces calls to net_dbg_ratelimited when !DEBUG with no_printk, keeping with the idiom of all the other debug print helpers. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- include/linux/net.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include

[PATCH] net_dbg_ratelimited: turn into no-op when !DEBUG

. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- include/linux/net.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/net.h b/include/linux/net.h index 04aa068..b3a06ef 100644 --- a/include/linux/net.h +++ b/include/linux/net.h @@ -239,8 +239,14 @@ do

Re: [oss-security] Linux x86_64 NMI security issues

On Wed, Jul 22, 2015 at 8:12 PM, Andy Lutomirski l...@amacapital.net wrote: You can mitigate CVE-2015-3290 by blocking modify_ldt or perf_event_open using seccomp. A fully-functional, portable, reliable exploit is privately available and will be published in a week or two. *Patch your

Re: [PATCH] net_dbg_ratelimited: turn into no-op when !DEBUG

Sorry, I forgot to 'v2' the subject, but here's the respin suggested by Joe and asked for by David. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] printk from softirq on xen: hard lockup

; setup_udp_tunnel_sock(init_net, s, tunnel); return ret; } static void __exit mod_exit(void) { if (s) udp_tunnel_sock_release(s); } module_init(mod_init); module_exit(mod_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(Send a UDP packet to port 32812); MODULE_AUTHOR(Jason A. Donenfeld ja...@zx2c4.com

[PATCH] rcu: Correct doc to use rcu_dereference_protected

-by: Jason A. Donenfeld ja...@zx2c4.com --- Documentation/RCU/whatisRCU.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 5746b0c..b852c10 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b

Re: [Xen-devel] printk from softirq on xen: hard lockup

Hey David, Sorry for the premature response on my phone earlier. Real reply follows. rcu_read_lock, when using Xen PV. Relevant excerpts of the ^^ PV guest? Yes. The lockup occurs on a PV guest. Nothing special at all about the configuration. Vanilla upstream

printk from softirq on xen: hard lockup

Hi folks, Paul McKenney and I had an offline discussion about some rcu questions that eventually lead into me investigating a strange full lock-up I'm experiencing as a consequence of a printk in softirq inside of an rcu_read_lock, when using Xen PV. Relevant excerpts of the conversation follow:

[PATCH v3] net_dbg_ratelimited: turn into no-op when !DEBUG

. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- include/linux/net.h | 8 1 file changed, 8 insertions(+) diff --git a/include/linux/net.h b/include/linux/net.h index 04aa068..049d4b0 100644 --- a/include/linux/net.h +++ b/include/linux/net.h @@ -239,8 +239,16 @@ do

Re: [Xen-devel] [PATCH v2] xen-apic: Enable on domU as well

On Fri, Aug 7, 2015 at 4:23 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: Anyhow, your patch seems to fix a regression my patch feb44f1f7a4ac299d1ab1c3606860e70b9b89d69 x86/xen: Provide a Xen PV APIC driver to support 255 VCPUs introduced. Ahhh, good, okay. That explains why I

Ozwpan Driver: Removal Recommended

from the tree. It simply didn't pass the staging test. Regards, Jason On Tue, Jun 2, 2015 at 1:35 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: On Tue, Jun 2, 2015 at 3:35 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: I don't know, but I'm a bit loath to delete the driver from the tree

[PATCH v3] xen-apic: Enable on domU as well

0x in ?? () Mailing-list-thread: https://lkml.org/lkml/2015/8/4/755 Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com Cc: David Vrabel david.vra...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: sta...@vger.kernel.org --- arch/x86/xen/Makefile | 4 ++-- arch/x86/xen/xen

Re: Ozwpan Driver: Removal Recommended

On Mon, Aug 10, 2015 at 3:31 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: Meanwhile Dan Carpenter has posted a patch for a security vulnerability in ozwpan that hasn't been reviewed or merged. Sorry, I see that you did in fact pick up this patch, so I retract that statement. Nonetheless

[PATCH 1/2] ozwpan: The maintainers are MIA, so orphan

Ozwpan is completely unmaintained and potentially a security problem. As this is a staging driver, it should be removed, since it has been abandoned. Marking it as orphaned is the first step here. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- MAINTAINERS | 2 +- 1 file changed, 1

Re: [PATCH v3] xen-apic: Enable on domU as well

On Mon, Aug 10, 2015 at 3:41 PM, David Vrabel david.vra...@citrix.com wrote: On 10/08/15 14:40, Jason A. Donenfeld wrote: It turns out that domU also requires the Xen APIC driver. Otherwise we get stuck in busy loops that never exit, such as in this stack trace: What's the difference between

Re: [Xen-devel] printk from softirq on xen: hard lockup

In that case, it doesn't compile. arch/x86/xen/apic.c:204:13: error: redefinition of ‘xen_init_apic’ void __init xen_init_apic(void) ^ In file included from arch/x86/xen/apic.c:9:0: arch/x86/xen/xen-ops.h:110:27: note: previous definition of ‘xen_init_apic’ was here static inline

[PATCH] xen-apic: Enable on domU as well

0x in ?? () Mailing-list-thread: https://lkml.org/lkml/2015/8/4/755 Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com Cc: David Vrabel david.vra...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: sta...@vger.kernel.org --- arch/x86/xen/Makefile | 4 ++-- arch/x86/xen

Re: [Xen-devel] printk from softirq on xen: hard lockup

On Thu, Aug 6, 2015 at 12:02 PM, David Vrabel david.vra...@citrix.com wrote: Linux PV guests must use the Xen PV APIC driver. You need to investigate why your PV guest is not using this (although I'm surprised it works at all with the wrong one). Actually it appears this PV Guest is using the

[PATCH] printk: include pr_fmt in pr_debug_ratelimited

The other two implementations of pr_debug_ratelimited include pr_fmt, along with every other pr_* function. But pr_debug_ratelimited forgot to add it with the CONFIG_DYNAMIC_DEBUG implementation. This patch unifies the behavior. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- include

[PATCH] thinkpad_acpi: Support micmute LED

The micmute LED is currently unused. This patch allows it to be hooked up to various LED triggers. Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/platform/x86/thinkpad_acpi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86

[PATCH] Input: atkbd - add LED triggers for keyboard state

-by: Jason A. Donenfeld ja...@zx2c4.com --- drivers/input/keyboard/atkbd.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index ec876b5..d01f83c 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers

Re: [PATCH] Makefile: Force gzip and xz on module install

Bump? This should be trivial to merge, and it fixes a really annoying bug for module development. On Tue, Jul 7, 2015 at 8:26 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: Running `make modules_install` ordinarily will overwrite existing modules. This is the desired behavior, and is how pretty

[PATCH] timeconst: update path in comment

Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com --- kernel/time/timeconst.bc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc index c7388de..c486889 100644 --- a/kernel/time/timeconst.bc +++ b/kernel/time/timeconst.bc

[PATCH] e1000: free skb when returning on -ENOMEM error

eth_skb_pad fails, if a network device is transmitting repeatedly, this bug could lead to rapidly leaking memory that could only be recovered by a reboot or crash. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/net/ethernet/intel/e1000/e1000_main.c | 4 +++- 1 file chan

Re: [PATCH] timeconst: update path in comment

file?". On Tue, Jul 14, 2015 at 7:24 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > --- > kernel/time/timeconst.bc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/time/timecon

Re: [Intel-wired-lan] [PATCH] e1000: free skb when returning on -ENOMEM error

You're right. Sorry for the noise Please ignore. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: GSO with udp_tunnel_xmit_skb

Hi Maciej, On Sun, Nov 8, 2015 at 12:40 AM, Maciej Żenczykowski wrote: > This isn't particularly efficient. This is basically equivalent to doing > GSO before the superpacket reaches your driver (you might get some > savings by not bothering to look at the packet headers

Re: GSO with udp_tunnel_xmit_skb

On Sun, Nov 8, 2015 at 11:57 AM, Herbert Xu wrote: > UDP carries no ordering information so this doesn't work. But if there's no ordering information, what's the problem? Isn't it good enough to send the packets in the order they were sendto()d? Or in any order at

Re: GSO with udp_tunnel_xmit_skb

On Mon, Nov 9, 2015 at 2:40 AM, Herbert Xu wrote: > You're right. I don't think the ordering matters. Cool, so we're on the same page then. In that case, any ideas about constructing UDP super-packets for GSO? As Maciej pointed out, UFO is actually just IP

Is ndo_do_ioctl still acceptable?

Hi David & Folks, Soon I will submit a virtual tunnel device driver to LKML for review. It uses rtnl_link_register to create a virtual network interface, which then handles encryption, authentication, and some other things, amongst various configured peers. Right now the device is configurable

Re: Is ndo_do_ioctl still acceptable?

On Thu, Nov 12, 2015 at 9:30 PM, Austin S Hemmelgarn wrote: >> > On the other hand, based on what you are saying about your device, it sounds > like you are working on some kind of cryptographically secured (either > authenticated or encrypted or both) tunnel, in which case

Re: [PATCH v2] ip_tunnel: disable preemption when updating per-cpu tstats

On Mon, Nov 16, 2015 at 8:17 PM, David Miller wrote: > So another fix could have been to do local_bh_disable() in the > udp_tunnel6_xmit_skb() helper. This would have fixed one problem, but everywhere udp_tunnel_xmit_skb() (4, not 6) is called, iptunnel_xmit_stats is called

Re: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

On Mon, Nov 16, 2015 at 10:17 PM, David Miller wrote: > > Not without a complete redesign of the x86 fpu save/restore mechanism. Urg, okay. I still wonder why irq_fpu_usable() is true when using TCP but not when using UDP... Any ideas on this? > The driver is the wrong

Re: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

On Mon, Nov 16, 2015 at 10:33 PM, David Miller wrote: > Someone already did a Linux implemenation of exactly that two decades > ago, we rejected that design and did what we did. It's not exactly IPSec though, so don't worry. It's a totally new thing that combines a lot of

irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

Hi David & Folks, I have a virtual device driver that does some fancy processing of packets in ndo_start_xmit before forwarding them onward out of a tunnel elsewhere. In order to make that fancy processing fast, I have AVX and AVX2 implementations. This means I need to use the FPU. So, I do the

Re: Routing loops & TTL tracking with tunnel devices

Hi Sowmini, Neat. Though, in my case, I'm not actually just prepending a header. I'm doing some more substantial transformations of a packet. And this needs to work with v4 too. So I'm not sure implementing a v6 spec will help with things. I need to identify the right mechanism inside the kernel

Re: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

Hi David, On Mon, Nov 16, 2015 at 9:32 PM, David Miller wrote: > Network device driver transmit executes with software interrupts > disabled. > > Therefore on x86, you cannot use the FPU. That is extremely problematic for me. Is there a way to make this not so? A driver

Routing loops & TTL tracking with tunnel devices

Hi folks, A few tunnel devices, like geneve or vxlan, are using udp_tunnel_xmit_skb, or related functions for transmitting packets, and are doing the usual FIB lookup to get the dst entry. I see a lot of code like this: if (rt->dst.dev == dev) {

Re: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

On Tue, Nov 17, 2015 at 12:57 AM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > 2. irq_fpu_usable() is FALSE for UDP! Since in_interrupt() is always > true in ndo_start_xmit, this means that in this case, both > interrupted_user_mode() and interrupted_kernel_fpu_idle() are false!

Re: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

Hi Hannes, Thanks for your response. On Mon, Nov 16, 2015 at 11:27 PM, Hannes Frederic Sowa wrote: > Use the irqsoff tracer to find the problematic functions which disable > interrupts and try to work around it in case of UDP. This could benefit > the whole stack. I

Re: Routing loops & TTL tracking with tunnel devices

On Mon, Nov 16, 2015 at 11:25 PM, Hannes Frederic Sowa wrote: > Have a look at __dev_queue_xmit and the per_cpu recursion limits > implemented there: > > if (__this_cpu_read(xmit_recursion) > > RECURSION_LIMIT) >

Re: Routing loops & TTL tracking with tunnel devices

Hi Eric, On Mon, Nov 16, 2015 at 11:28 PM, Eric Dumazet wrote: > There is very little chance we'll accept a new member in sk_buff, unless > proven needed. I actually have no intention of doing this! I'm wondering if there already is a member in sk_buff that moonlights as

  1   2   3   4   5   6   7   8   9   10   >