Re: [PATCH 00/14] Present useful limits to user (v2)

,Johannes Weiner ,Alexei Starovoitov ,Arnaldo Carvalho de Melo ,Alexander Shishkin ,Balbir Singh ,Markus Elfring ,"David S.

Re: IPv6: proxy_ndp to a network range

On May 9, 2016 1:39:08 AM PDT, Alexander Aring <alex.ar...@gmail.com> wrote: >Hi, > >On Mon, May 09, 2016 at 01:06:51AM -0700, H. Peter Anvin wrote: >> Hello, >> >> There currently doesn't seem to be any support for proxy_ndp of a >whole >> netwo

IPv6: proxy_ndp to a network range

Hello, There currently doesn't seem to be any support for proxy_ndp of a whole network mask, as IPv4 proxy_arp seems to permit. a) Am I actually correct in this, or am I just missing something important? b) Is there a technical reason for this, or is it just a limitation of the current

Re: [PATCH v2 net-next] net: Implement fast csum_partial for x86_64

On 01/05/2016 02:18 PM, Eric Dumazet wrote: > On Tue, 2016-01-05 at 10:41 -0800, Tom Herbert wrote: >> Implement assembly routine for csum_partial for 64 bit x86. This >> primarily speeds up checksum calculation for smaller lengths such as >> those that are present when doing skb_postpull_rcsum

Re: [PATCH] x86: Wire up 32-bit direct socket calls

On 09/14/2015 06:35 AM, Ingo Molnar wrote: >> >> I missed sys_ipc entirely. >> >> Ingo, Thomas, want to just wire those up, too? I can send a patch >> next week, but it'll be as trivial as the socket one. > > Yeah, sure - split out system calls are so much better (and slightly faster) > than >

Re: [PATCH] x86: Wire up 32-bit direct socket calls

On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > Should all other architectures follow suit? > Or should we follow the s390 approach: > It is up to the maintainer(s), largely dependent on how likely you are going to want to support this in your libc, but in general, socketcall is an

Re: [PATCH 0/8] Use correctly the Xen memory terminologies in Linux

On 07/28/2015 08:02 AM, Julien Grall wrote: Hi all, This patch series aims to use the memory terminologies described in include/linux/mm.h [1] for Linux xen code. Linux is using mistakenly MFN when GFN is meant, I suspect this is because the first support of Xen was for PV. This has

Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)

Jeff Garzik wrote: Signed-off-by: Andrew Morton [EMAIL PROTECTED] NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. Either that, or detect

Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)

Jeff Garzik wrote: Indeed, that would work too... though we would need to put out a call for Gigabyte testers during 2.6.25-rc. It is an entirely reasonable scenario for NVIDIA to deploy a fix to Gigabyte, which would then return us to the same scenario we have today: some work and some

Re: [klibc] [patch] import socket defines

Mike Frysinger wrote: all this stuff is ABI constants, and the only reason glibc doesn't use them is that glibc prefers to use enums over #defines. a proper libc defines things in their headers according to the POSIX specs rather than relying on others to do it for them. if you want to argue

Re: [klibc] [patch] import socket defines

Mike Frysinger wrote: On Friday 11 January 2008, David Miller wrote: From: H. Peter Anvin [EMAIL PROTECTED] Seems the most logical thing to do would be to break out the small portion that everyone wants into linux/sockaddr.h or somesuch, and then remove those ifdefs entirely. Proposed patch

Re: [klibc] [patch] import socket defines

David Miller wrote: Hmmm... Doesn't glibc include linux/socket.h? If so, before it wouldn't get the sa_family_t et al. defines (because __GLIBC__ will be defined and it will be = 2), but with your change it get those things. Correct me if I'm wrong. At the moment, yes, it does.

Re: [klibc] [patch] import socket defines

Mike Frysinger wrote: oh, sorry, i see what you mean. i was thinking in terms of crap removed (as that's what i'm after), not crap added (which is what Peter is after). i hadnt noticed that. i dont know if it'll break glibc (and really, any other sane libc). if that is the case, then i

Re: [klibc] [patch] import socket defines

H. Peter Anvin wrote: Right now, glibc is special-cased. glibc also tends to be very deliberate about its kernel header inclusions. It wants a subset of the available defines, so it can include a subset header. The reverse is definitely possible too -- all other users (kernel, newlib

Re: [klibc] [patch] import socket defines

Mike Frysinger wrote: On Tuesday 01 January 2008, H. Peter Anvin wrote: Mike Frysinger wrote: The kernel __GLIBC__ hacks were re-added so as to appease klibc people, but the klibc people didnt actually fix the problem on their side. This patch imports the structures/defines that klibc seems

Re: wireless vs. alignment requirements

Herbert Xu wrote: On Tue, Nov 27, 2007 at 09:16:07AM -0800, H. Peter Anvin wrote: I wrote a patch for the IP stack to realign packets if necessary at one point. I should dredge it up again and submit it for collective flamage. As long as it doesn't penalise Ethernet (e.g., the 10Gb crowd

Re: wireless vs. alignment requirements

Herbert Xu wrote: On Thu, Nov 29, 2007 at 04:28:34PM -0800, H. Peter Anvin wrote: sky2 is the exception here, not the rule. It is, but it's not unique. Several USB adapters have the same problem, for example. Notice the common theme here that slow (or slower, i.e., certainly nowhere near

Re: wireless vs. alignment requirements

Herbert Xu wrote: On Thu, Nov 29, 2007 at 09:50:35AM -0800, H. Peter Anvin wrote: Uhm, most cards affected *ARE* Ethernet cards, due to the bloody 14-byte header. Well most Ethernet drivers are using NET_IP_ALIGN which means that IP stack gets aligned packets only. sky2 is the exception here

Re: wireless vs. alignment requirements

Stephen Hemminger wrote: Herbert Xu wrote: On Sat, Nov 24, 2007 at 02:49:36PM +0100, Johannes Berg wrote: Right. I just didn't think that would be a valid value for an architecture to set. OK. Let me clarify this a bit more. We require at least one of the following rules to be met:

Re: wireless vs. alignment requirements

Herbert Xu wrote: Luckily all sky2 users have been on x86 so far :) Hardly so. My previous employer was MIPS and we used it there (with my patch.) -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo

Re: bnx2 dirver's firmware images

maximilian attems wrote: On Tue, 18 Sep 2007, Sam Ravnborg wrote: Anyway - if we again consider klibc I will do my best to make the build stuff as smooth as possible. Sam nitpicking mode on currently klibc has tendency to rebuild a bit too much if you touch some part of it, seen

Re: bnx2 dirver's firmware images

David Miller wrote: From: H. Peter Anvin [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 11:41:34 -0700 David Miller wrote: I don't like it because it means people have to setup full initrd's in order to do network booting with such network cards. klibc could help with that, if there is interest

Re: bnx2 dirver's firmware images

Sam Ravnborg wrote: Except there seems to be great resistance to include userland code in the kernel as demonstrated at last KS. Or this is maybe just a single vocal person and the topic were brought up late? Anyway - if we again consider klibc I will do my best to make the build stuff as

Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console

Jeff Garzik wrote: On Tue, 24 Jul 2007, Adrian Bunk wrote: buffered_rmqueue() and prep_new_page() are static functions with only one caller each, and for the normal non-debug case it's a really nice optimization to have them inlined automatically. I'm not at all sure I agree.

Re: [PATCH] e1000: Fix msi enable leak on error, don't print error message, cleanup

Rick Jones wrote: Some more of my paranoid questions :) So, if a driver tries to enable MSI and that is unsuccessful (I'll try to avoid using the possibly loaded term fails) shouldn't that show-up _somewhere_? It already does -- in /proc/interrupts. Just how normal is an attempt to enable

Re: select(0, ..) is valid ?

Badari Pulavarty wrote: Hi, Is select(0, ..) is a valid operation ? I see that there is no check to prevent this or return success early, without doing any work. Do we need one ? slub code is complaining that we are doing kmalloc(0). select(0, ...) is valid, and is functionally

[PATCH] [e1000] Lower the MSI unavailable message to INFO priority

and will print another message if that fails. Accordingly, lower the priority of this message to INFO priority, since it does not reflect any sort of loss of functionality, but rather just a limitation of the configuration of the runtime system. Signed-off-by: H. Peter Anvin [EMAIL PROTECTED

Re: [RFT] e100 driver on ARM

Lennart Sorensen wrote: My suspicision (although it is only that) is that the PXA255 trying to access memory may cause interruptions in PCI bus master transfers, which is of course not permitted by the PCI spec (at least the way I read it). Why wouldn't that be permitted? It, in fact,

Re: [RFC] div64_64 support II

Andi Kleen wrote: The problem with these algorithms that tradoff one or more multiplies in order to avoid a divide is that they don't give anything and often lose when both multiplies and divides are emulated in software. Actually on rereading this: is there really any Linux port that emulates

Re: D-Link DGE-528T (r8159) autonegotation of 1000 Mbps link does not work

Petri T. Koistinen wrote: Hi! I just brought two D-Link DGE-528T (uses r8159 driver) network adapters to have nice 1 Gbps home network between two computers. I have gigabit crossover cable that is connected like this... Pin Connector #1 Connector #2 1white/orange white/green 2

Re: [RFC] div64_64 support

Stephen Hemminger wrote: Hmm. Those are the GCC internal versions, that are picked up but doing divide in place. Do we want to allow general 64 bit in kernel to be easily used? It could cause sloppy slow code, but it would look cleaner. ... and it would handle datatypes which may be

Re: [patch] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h

Erik Andersen wrote: On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote: On 11/30/06, Robert P. J. Day [EMAIL PROTECTED] wrote: but there are a few other cases which still contain compound preprocessor directives such as: #if defined(__KERNEL__) || !defined(__GLIBC__) ||

Re: [PATCH 0/59] Cleanup sysctl

Eric W. Biederman wrote: I think it would be fair to say that if they're not in linux/sysctl.h they're not architectural, but that doesn't resolve the counterpositive (are there sysctls in linux/sysctl.h which aren't architectural? From the looks of it, I would say yes.) Non-architectural

Re: [PATCH 0/59] Cleanup sysctl

Eric W. Biederman wrote: With architectural I mean guaranteed to be stable (as opposed to incidental). Sorry for the confusion. Ok. Then largely we are in agreement. To implement that the rule is simple. If it isn't CTL_UNNUMBERED and the number is in Linus's tree, it is our

Re: [PATCH 0/59] Cleanup sysctl

Eric W. Biederman wrote: Agreed. *Furthermore*, if the number isn't in linux/sysctl.h it shouldn't exist anywhere else, either. That would be a good habit. Feel free to send the patches to ensure that is so. I'm a practical fix it when it is in my way kind of guy ;) That's fine.

Re: [PATCH 0/59] Cleanup sysctl

Eric W. Biederman wrote: - Removal of sys_sysctl support where people had used conflicting sysctl numbers. Trying to break glibc or other applications by changing the ABI is not cool. 9 instances of this in the kernel seems a little extreme. It would be highly advantageous if we could

Re: ProxyARP and IPSec

Thomas Graf wrote: What about adding blackhole device to be used for such routes. I believe it would be good architecture to always use devices to state directions packets are being received from and sent to. The dummy device can be used for that. -hpa - To unsubscribe from this

Re: ProxyARP and IPSec

Alexey Kuznetsov wrote: sarcasm mode is not accepted. Linux does exactly standard tunnel-mode IPsec. It does not give you device to make you totally happy. The sarcasm was a commentary to the just switch protocols then comment. Probably, you are not aware that standard IPsec tunnel device,

Re: ProxyARP and IPSec

Stephen J. Bevan wrote: Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't If you use ipip the over-wire protocol is identical, see RFC 3884 section 3.1 or you can test it right now using

Re: ProxyARP and IPSec

Stephen J. Bevan wrote: H. Peter Anvin writes: Fair enough. However, that does beg a question: is there any sane way to create the pseudo-device model on top of the current model, as a convenience layer? That way you could get the best of both. I assume you were using tunnel-mode

Re: ProxyARP and IPSec

Alexey Kuznetsov wrote: Hello! I'm thinking that David definitely has a point about having a usability problem, though. All other kind of tunnels have endpoint devices associated with them, and that would make all these kinds of problems go away, Yes, when you deal with sane practical

Re: ProxyARP and IPSec

Alexey Kuznetsov wrote: The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0. IPsec policy will figure

Re: ProxyARP and IPSec

H. Peter Anvin wrote: Alexey Kuznetsov wrote: The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0

Re: ProxyARP and IPSec

Andy Gay wrote: Just tried it, and it works as advertised. ... except that OpenSwan will rip out the route and install a route pointing to eth0, thus breaking the thing again. Use a custom updown script with Openswan to fix that. *Nod.* I'm thinking that David definitely has a point

ProxyARP and IPSec

Hello all, I am having a puzzlement combining ProxyARP and IPsec. Specificially, I want to take a single address from a local LAN and extend it via IPsec to another site. Unfortunately IPsec tunnels, unlike all other tunnels, don't have pseudo-devices associated with them. I understand