,Johannes Weiner ,Alexei Starovoitov
,Arnaldo Carvalho de Melo ,Alexander Shishkin
,Balbir Singh
,Markus Elfring ,"David
S. Miller" ,Nicolas Dichtel
,Andrew Morton
,Konstantin Khlebnikov ,Jiri Slaby
,Cyrill Gorcunov ,Michal Hocko
,Vlastimil Babka ,Dave Hansen
,Greg Kroah-Hartman
,Dan Carp
On May 9, 2016 1:39:08 AM PDT, Alexander Aring 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
>> network mask, as IPv4 proxy_arp
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 imple
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 whe
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
>
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 abomina
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
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 d
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 detec
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
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
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 thin
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.
-
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 or somesuch, and
then remove those ifdefs entirely.
Proposed pa
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
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
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
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
Stephen Hemminger wrote:
Is there any standard kernel config define for "this platform can't do
unaligned accesses"?
Not that I know of, but there should be.
To be somewhat more complexicated, some platforms (e.g. MIPS) can do
unaligned references quite cheaply, but they need different opco
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:
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
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
>
>
> currently klibc has tendency to rebuild a bit too much if you
> touch some part of it, seen in usr
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 st
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
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 in exploring that
avenue again.
-hpa
-
To unsubscribe from this list: send the line "u
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.
>
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
errupt 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 <[EM
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 functional
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, ha
Andi Kleen wrote:
Let me see... You throw code like that and expect someone to actually
understand it in one year, and be able to correct a bug ?
To be honest I don't expect any bugs in this function.
Please add something, an URL or even better a nice explanation, per favor...
It's stra
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
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
2orange
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 architect
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__) || (__GLIBC
Eric W. Biederman wrote:
Agreed. *Furthermore*, if the number isn't in 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. However, I am wonderin
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 responsi
Eric W. Biederman wrote:
I think it would be fair to say that if they're not in they're
not architectural, but that doesn't resolve the counterpositive (are there
sysctls in which aren't architectural? From the looks of it, I
would say yes.) Non-architectural sysctl numbers should not be ex
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
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 list:
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 manu
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 dev
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 tu
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 set
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 abo
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
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 ou
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 thi
48 matches
Mail list logo
