Re: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit

[Alan Cox]

On Wed, 31 Jan 2018 18:24:07 -0600
"Gustavo A. R. Silva"  wrote:

> Cast to s64 some variables and a macro in order to give the
> compiler complete information about the proper arithmetic to
> use. Notice that these elements are used in contexts that
> expect expressions of type s64 (64 bits, signed).
> 
> Currently such expression are being evaluated using 32-bit
> arithmetic.

The question you need to ask is 'can it overflow 32bit maths', otherwise
you are potentially making the system do extra work for no reason.

Alan

Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

[Alan Cox]

>  (c) isn't actually done in any real CPU's today that I'm aware of
> (unless you want to call the return stack data speculation).

There are processors out there today that data speculate.

For Intel family 6 Core, Knights and Atom today all is good.

Alan

Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

[Alan Cox]

> That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-
> 5753)" on
> all architectures with and without JIT.

For Intel we believe this is true for all family 6 Core, Atom and
Knights processors. If that ceases to be the case in future then Intel
will provide guidance beforehand.

For non x86 you need to check what level of data speculation anyone is
doing. I know some Power did data speculation. Your statement may well
be true but it would be nice to see AMD, ARM, Power, Sparc etc acks on
it.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

On Mon, 8 Jan 2018 12:00:28 +
David Laight  wrote:

> From: Linus Torvalds
> > Sent: 07 January 2018 19:47  
> ...
> > Also, people definitely *are* noticing the performance issues with the
> > current set of patches, and they are causing real problems. Go search
> > for reports of Amazon AWS slowdowns.  
> 
> Try over 35% slowdown
> Given that AWS instance runs known code (user and kernel) why do we
> need to worry about any of these sideband attacks?

You may not need to. Amazon themselves obviously need to worry that no
other VM steals your data (or vice versa) but above that (and with raw
hardware appliances) if you control all the code you run then the nopti
and other disables may be useful (At the end of the day as with anything
else you do your own risk assessment).

Do remember to consider if you are running untrusted but supposedly
sandboxed code (eg Java, js).

I'm not using pti etc on my minecraft VMs - no point. If anyone gets to
run arbitrary code on them except me then it's already compromised.

Alan

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Alan Cox]

On Mon, 8 Jan 2018 11:08:36 +0100
Peter Zijlstra  wrote:

> On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman  
> > wrote:  
> > > In at least one place (mpls) you are patching a fast path.  Compile out
> > > or don't load mpls by all means.  But it is not acceptable to change the
> > > fast path without even considering performance.  
> > 
> > Performance matters greatly, but I need help to identify a workload
> > that is representative for this fast path to see what, if any, impact
> > is incurred. Even better is a review that says "nope, 'index' is not
> > subject to arbitrary userspace control at this point, drop the patch."  
> 
> I think we're focussing a little too much on pure userspace. That is, we
> should be saying under the attackers control. Inbound network packets
> could equally be under the attackers control.

Inbound network packets don't come with a facility to read back and do
cache timimg. For the more general case, timing attacks on network
activity are not exactly new, and you have to mitigate them in user space
because most of them are about how many instructions you execute on each
path. The ancient classic being telling if a user exists by seeing if the
password was actually checked.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

> everyone.  I'm not saying this always happens, but it is reasonable to
> let the iterative pushback see if we can get to better code in this
> case rather than trying to cut it of with the "because *security*"
> argument.
> 

I'm not arguing otherwise - I'd just prefer most users machines are
secure while we have the discussion and while we see what other
architectural tricks people can come up with

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

> > 2.  It is very very complicated to answer a question like "is
> > sequence x safe on all of vendor's microprocessors" even for the vendor  
> 
> so far "is sequence x safe" was viewed by cpu vendors as
> "is sequence x going to stop speculative execution".

Incorrect. Modern processors are very very sophisticated beasts and you
are dealing with a wide range of architectures and micro-architectures
that all have their own differences.

> > Intel's current position is 'lfence'.  

> which clearly states that bpf_tail_call() was used in the attack.
> Yet none of the intel nor arm patches address speculation in
> this bpf helper!

There are a set of patches under discussion for eBPF both the JIT and
interpreter. BTW I would expect that there are things Coverity didn't
find, and that we'll also see variants on the attack where different
tricks for measurement emerge that may change what is needed a little.

> which means that POC is relying 64-bit address speculation.
> In the places coverity found the user supplied value is 32-bit,

People have 32bit computers as well as 64bit and in some cases 32bit is
fine for an attack depending where your target is relative to the object.

> > The differences involved on the "lfence" versus "and" versus before are
> > not likely to be anywhere in that order of magnitude.  
> 
> we clearly disagree here. Both intel and arm patches proposed
> to add lfence in bpf_map_lookup() which is the hottest function
> we have and we do run it at 40+Gbps speeds where every nanosecond
> counts, so no, lfence is not a solution.

The last solution I saw proposed in that path for the JIT is to "and" with
constant which in that situation clearly makes the most sense providing
it is safe on all the CPUs involved.

lfence timing is also heavily dependent upon what work has to be done to
retire previous live instructions. BPF does not normally do a lot of
writing so you'd expect the cost to be low.

Anyway - Intel's current position is that lfence is safe. It's not
impossible other sequences will in future be documented as safe by one or
more vendors of x86 processors.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

> Even if it would be practical the speed probably going to be in bytes per 
> second,
> so to read anything meaningful an attack detection techniques (that people
> are actively working on) will be able to catch it.
> At the end security cannot be absolute.
> The current level of paranoia shouldn't force us to make hastily decisions.

I think there are at least three overlapping problem spaces here

1.  This is a new field. That could mean that it turns out to be
really hard and everyone discovers that eBPF was pretty much the only
interesting attack. It could also mean we are going to see several years
or refinement by evil geniuses all over the world and what we see now is
tip of iceberg in cleverness.

2.  It is very very complicated to answer a question like "is
sequence x safe on all of vendor's microprocessors" even for the vendor

3.  A lot of people outside of the professional security space are
very new to the concept of security economics and risk management as
opposed to seeing the fake binary nice green tick that says their
computers are secure that they can pass to their senior management or
show to audit.

> So how about we do array_access() macro similar to above by default
> with extra CONFIG_ to convert it to lfence ?

We don't have to decide today. Intel's current position is 'lfence'. Over
time we may see vendors provide more sequences. We will see vendors add
new instruction hints and the like (See the ARM whitepaper for example)
and the array access code will change and change again for the better.

The important thing is that there is something clean, all architecture
that can be used today that doesn't keep forcing everyone to change
drivers when new/better ways to do the speculation management appear.

> Why default to AND approach instead of lfence ?
> Because the kernel should still be usable. If security
> sacrifices performance so much such security will be turned off.
> Ex: kpti suppose to add 5-30%. If it means 10% on production workload
> and the datacenter capacity cannot grow 10% overnight, kpti will be off.

The differences involved on the "lfence" versus "and" versus before are
not likely to be anywhere in that order of magnitude. As I said I want to
take a hard look at the IPv4/6 ones but most of them are not in places
where you'd expect a lot of data to be in flight in a perf critical path.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

> "Value prediction consists of predicting entire 32- and 64-bit register values
> based  on  previously-seen values"

For their implementation yes

> 
> > In other words there are at least two problems with Linus proposal
> > 
> > 1. The / mask has to be generated and that has to involve
> > speculative flows.  
> 
> to answer above and Thomas's
> "For one particular architecture and that's not a solution for generic code."
> 
> The following:
> #define array_access(base, idx, max) ({ \
> union { typeof(base[0]) _val; unsigned long _bit; } __u;\
> unsigned long _i = (idx);   \
> unsigned long _m = (max);   \
> unsigned long _mask = ~(long)(_m - 1 - _i) >> 63;   \
> __u._val = base[_i & _mask];\
> __u._bit &= _mask;  \
> __u._val; })
> 
> is generic and no speculative flows.

In the value speculation case imagine it's been called 1000 times for
process A which as a limit of say 16 so that file->priv->max is 16, and
then is run for process B which is different.

A value speculating processor waiting for file->priv->max which has been
pushed out of cache by an attacker is at liberty to say 'I've no idea
what max is but hey it was 16 last time so lets plug 16 in and keep going"

So while the change in the mask computation is clever and (subject to
compiler cleverness) safe against guesses of which path will be taken I
don't think it's generically safe.

Unfortunately a lot of things we index are of different sizes as seen by
different tasks, or when passed different other index values so this does
matter.

> Even if 'mask' in 'index & mask' example is a stall the educated
> guess will come from the prior value (according to the quoted paper)

Which might be for a different set of variables when the table is say per
process like file handles, or the value is different each call.

If we have single array of fixed size then I suspect you are right but
usually we don't.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

> cpus execute what they see. speculative execution does the same
> except results are not committed to visible registers and stay
> in renanmed/shadow set. There is no 'undo' of the speculative execution.
> The whole issue is that cache and branch predictor don't have
> a shadow unlike registers.

Can I suggest you read something like "Exploitig Value Locaity to Exceed
The Dataflow Limit" by Lipasti and Shen 1996.

In other words there are at least two problems with Linus proposal

1. The / mask has to be generated and that has to involve
speculative flows.

2. There are processors on the planet that may speculate not just what
instruction to execute but faced with a stall on an input continue by
using an educated guess at the value that will appear at the input in
future.

> > > I think "lets sprinkle lfence everywhere" approach is going to
> > > cause serious performance degradation. Yet people pushing for lfence
> > > didn't present any numbers.  
> > 
> > Normally people who propose security fixes don't have to argue about the
> > fact they added 30 clocks to avoid your box being 0wned.
> > 
> > If you look at the patches very very few are in remotely hot paths, which
> > is good news. The ones in hot paths definitely need careful scrutiny but
> > the priority ought to be fixing and then optimizing unless its obvious
> > how to tackle it.  
> 
> fdtable, access_ok and networking are clearly hot, 

Those points are not when compared to a lot of paths executed far far
more (like packet processing). The ipv4/6 ones are mixing lfences and a
lot of stores so probably hurt with lfence. fdtable worries me
a lot less and is anyway clearly required.

I have reviewing the packet building ones on my TODO list for a reason.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

On Sat, 6 Jan 2018 10:13:33 -0800
Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote:

> On Sat, Jan 06, 2018 at 12:32:42PM +0000, Alan Cox wrote:
> > On Fri, 5 Jan 2018 18:52:07 -0800
> > Linus Torvalds <torva...@linux-foundation.org> wrote:
> >   
> > > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams <dan.j.willi...@intel.com> 
> > > wrote:  
> > > > From: Andi Kleen <a...@linux.intel.com>
> > > >
> > > > When access_ok fails we should always stop speculating.
> > > > Add the required barriers to the x86 access_ok macro.
> > > 
> > > Honestly, this seems completely bogus.  
> > 
> > Also for x86-64 if we are trusting that an AND with a constant won't get
> > speculated into something else surely we can just and the address with ~(1
> > << 63) before copying from/to user space ? The user will then just
> > speculatively steal their own memory.  
> 
> +1
> 
> Any type of straight line code can address variant 1.
> Like changing:
>   array[index]
> into
>   array[index & mask]
> works even when 'mask' is a variable.

That statement is unfortunately not one that we currently believe is
true for all architectures, platforms and implementations. It may be true
for some architectures but processors can speculate on more than just
execution paths. For some architecutres it may be the right way to
implement Linus array_* methods.

> I think "lets sprinkle lfence everywhere" approach is going to
> cause serious performance degradation. Yet people pushing for lfence
> didn't present any numbers.

Normally people who propose security fixes don't have to argue about the
fact they added 30 clocks to avoid your box being 0wned.

If you look at the patches very very few are in remotely hot paths, which
is good news. The ones in hot paths definitely need careful scrutiny but
the priority ought to be fixing and then optimizing unless its obvious
how to tackle it.

Alan

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

[Alan Cox]

> The only way a user can set this in any meaningful way would be via
> a NL80211_CMD_SET_WIPHY netlink message. However, the value will get
> vetted there by cfg80211's parse_txq_params [0]. This is long before

Far more than a couple of hundred instructions ? The problem is that the
processor will speculate that the parameter is valid and continue on that
basis until the speculation resolves or it hits some other limit that
stops it speculating further. That can be quite a distance on a modern
x86 processor, and for all we know could be even more on some of the
other CPUs involved.

> it reaches any of the *_op_conf_tx functions.
> 
> And Furthermore a invalid queue (param->ac) would cause a crash in 
> this line in mac80211 before it even reaches the driver [1]:
> | sdata->tx_conf[params->ac] = p;
> |   

Firstly it might not because the address you get as a result could be
valid kernel memory. In fact your attackers wants it to be valid kernel
memory since they are trying to find the value of a piece of that memory.

Secondly the processor is doing this speculatively so it won't fault. It
will eventually decide it went the wrong way and throw all the
speculative work away - leaving footprints. It won't fault unless the
speculative resolves that was the real path the code took.

If it's not a performance critical path then it's better to be safe.

Alan

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Alan Cox]

On Fri, 5 Jan 2018 18:52:07 -0800
Linus Torvalds  wrote:

> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams  wrote:
> > From: Andi Kleen 
> >
> > When access_ok fails we should always stop speculating.
> > Add the required barriers to the x86 access_ok macro.  
> 
> Honestly, this seems completely bogus.

Also for x86-64 if we are trusting that an AND with a constant won't get
speculated into something else surely we can just and the address with ~(1
<< 63) before copying from/to user space ? The user will then just
speculatively steal their own memory.

Alan

Re: [PATCH 14/18] ipv4: prevent bounds-check bypass via speculative execution

[Alan Cox]

On Sat, 6 Jan 2018 10:01:54 +0100
Greg KH  wrote:

> On Fri, Jan 05, 2018 at 05:11:10PM -0800, Dan Williams wrote:
> > Static analysis reports that 'offset' may be a user controlled value  
> 
> Can I see the rule that determined that?  It does not feel like that is
> correct, given the 3+ levels deep that this function gets this value
> from...

On a current x86 you can execute something upwards of 150 instructions in
a speculation window.

Alan

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

[Alan Cox]

On Tue, 28 Nov 2017 13:39:58 -0800
Kees Cook  wrote:

> On Tue, Nov 28, 2017 at 1:16 PM, Luis R. Rodriguez  wrote:
> > And *all* auto-loading uses aliases? What's the difference between 
> > auto-loading
> > and direct-loading?  
> 
> The difference is the process privileges. Unprivilged autoloading
> (e.g. int n_hdlc = N_HDLC; ioctl(fd,
> TIOCSETD, _hdlc)), triggers a privileged call to finit_module()
> under CAP_SYS_MODULE.

If you have CAP_SYS_DAC you can rename any module to ppp.ko and ask the
network manager (which has the right permissions) to init a ppp
connection. Capabilities alone are simply not enough to do any kind of
useful protection on a current system and the Linux capability model is
broken architecturally and not fixable because fixing it would break lots
of real systems.

I really don't care what the module loading rules end up with and whether
we add CAP_SYS_YET_ANOTHER_MEANINGLESS_FLAG but what is actually needed
is to properly incorporate it into securiy ruiles for whatever LSM you
are using.

Alan

Re: RFC(v2): Audit Kernel Container IDs

[Alan Cox]

On Thu, 12 Oct 2017 10:14:00 -0400
Richard Guy Briggs  wrote:

> Containers are a userspace concept.  The kernel knows nothing of them.
> 
> The Linux audit system needs a way to be able to track the container
> provenance of events and actions.  Audit needs the kernel's help to do
> this.
> 
> Since the concept of a container is entirely a userspace concept, a
> registration from the userspace container orchestration system initiates
> this.  This will define a point in time and a set of resources
> associated with a particular container with an audit container ID.

I don't think this has anything to do with containers directly. If i
read it right you need a subtree of stuff to be asigned a (possibly
irrevocable) magic identifier that you can use for other purposes.

Traditional Unix in the more 'secure' space had that decades ago in the
form of luid. At login time you did a setluid() and that set an
irrevocable tag onthe session which was (traditionally) the uid of the
login process so that audit and other related tools always knew how to
tie the process back to the login session.

That doesn't quite work as of itself (if you login you'd get luid set and
not be able to change it for the container), but it seems something
similarly trivial like a "setauditid(void)" would do the trick providing
the kernel picked the UUID randomly [otherwise I can copy another known
UUID to confuse or hide].

As you say a container is a userspace concept. So IMHO any audit
interface should be about auditing and what needs tracking, not about
containers. If the container management tool wants to set a suitable tag
then let it. If not then it doesn't.

Then it's a simple as checking CAP_AUDIT_WRITE to see if you are allowed
to setauditit(), generating a random uuid and a matching getauditid() to
copy it back.

Alan

Re: drivers/net/hamradio: divide error in hdlcdrv_ioctl

[Alan Cox]

On Tue, 16 May 2017 17:05:32 +0200
Andrey Konovalov <andreyk...@google.com> wrote:

> Hi,
> 
> I've got the following error report while fuzzing the kernel with syzkaller.
> 
> On commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6 (4.12-rc1).
> 
> A reproducer and .config are attached.

This should fix it.

commit 37b3fa4b617681f00cfa1f76d6d7716cc6d9f79a
Author: Alan Cox <alan@llwyncelyn.cymru>
Date:   Wed May 17 21:04:27 2017 +0100

hdlcdrv: Fix division by zero when bitrate is unset

The code attempts to check for out of range calibration. What it forgets to 
do
is check for the 0 bitrate case. As a result the range check itself oopses 
the
kernel.

Found by Andrey Konovalov using Syzkaller.

Signed-off-by: Alan Cox <a...@linux.intel.com>

diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
index 8c3633c..9f34a48 100644
--- a/drivers/net/hamradio/hdlcdrv.c
+++ b/drivers/net/hamradio/hdlcdrv.c
@@ -576,7 +576,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
case HDLCDRVCTL_CALIBRATE:
if(!capable(CAP_SYS_RAWIO))
return -EPERM;
-   if (bi.data.calibrate > INT_MAX / s->par.bitrate)
+   if (!s->par.bitrate || bi.data.calibrate > INT_MAX / 
s->par.bitrate)
return -EINVAL;
s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;
return 0;

Re: Network cooling device and how to control NIC speed on thermal condition

[Alan Cox]

> I am looking on Linux thermal framework and on how to cool down the
> system effectively when it hits thermal condition. Already existing
> cooling methods cpu_cooling and clock_cooling are good. However, I
> wanted to go further and dynamically control also a switch ports'
> speed based on thermal condition. Lowering speed means less power,
> less power means lower temp.
> 
> Is there any in-kernel interface to configure switch port/NIC from other 
> driver?

No but you can always hook that kind of functionality to the thermal
daemon. However I'd be careful with your assumptions. Lower speed also
means more time active.

https://github.com/01org/thermal_daemon

For example if you run a big encoding job on an atom instead of an Intel
i7, the atom will often not only take way longer but actually use more
total power than the i7 did.

Thus it would often be far more efficient to time synchronize your
systems, batch up data on the collecting end, have the processing node
wake up on an alarm, collect data from the other node and then actually
go back into suspend.

Modern processors are generally very good in idle state (less so
sometimes the platform around them) so trying to lower speeds may
actually be the wrong thing to do, versus say trying to batch up activity
so that you handle a burst and then sleep the entire platform.

It also makes sense to keep policy like that mostly user space - because
what you do is going to be very device specific - eg with things like
dimming the screen, lowering the wifi power, pausing some system
services, pausing battery charge etc.

Now at platform design time there are some interesting trade offs between
100Mbit and 1Gbit ethernet although less so than there used to be 8)

Alan

Re: Sending short raw packets using sendmsg() broke

[Alan Cox]

> > A quick search for ethhdr in drivers/net/ethernet shows, for
> > instance,
> > bnx2x_select_queue casting skb->data to an ethernet header. Reading
> > nonsense in that particular function is quite safe and given the
> > skbuff layout (skb_shared_info) code will never read beyond an
> > allocated region. But that was just the first occurrence I found.
> > efx_tso_check_protocol is another example.

So would always allocating that much space be a good mitigation in
general, and perhaps then making the logic check validate() IFF
CAP_SYS_RAWIO is not set.

A user with CAP_SYS_RAWIO already has the power to control the device
by banging registers so the check is not a security loss.

Alan

Re: Sending short raw packets using sendmsg() broke

[Alan Cox]

> More thorough validation of the header contents is not necessarily
> hard. The following validates the address, including optional
> repeaters.
> 
>   static bool ax25_validate_hard_header(const char *ll_header,
>unsigned short len)
>   {
>  ax25_digi digi;
> 
>  return !ax25_addr_parse(ll_header, len, NULL, NULL, ,
> NULL, NULL);
>   }

This also breaks because there is a KISS header byte on an AX.25
transmission and it is valid to send a KISS control frame via
SOCK_PACKET but it cannot be generated by other protocols.

Basically everything hitting an AX.25 port is either a zero byte
followed by an AX.25 frame, or a KISS frame the first of which is non
zero and which is used to set parameters on the radio side.

The AX.25 device level drivers are simply written to be robust if
thrown partial frames.

The other thing that concerns me about this added logic in general is
that you are also breaking test tools that want to deliberately send
corrupt frames to certain classes of interface. I'm not sure how big an
issue that is given we always for example padded ethernet frames
properly, but the more validation we do for a privileged interface the
more we prevent applications for testing network behaviour from being
able to run on Linux. Possibly there should be a CAP_SYS_RAWIO test but
making it impossible is a bad step.

Alan

Re: Sending short raw packets using sendmsg() broke

[Alan Cox]

On Fri, 2016-02-26 at 12:33 -0500, Willem de Bruijn wrote:
> On Fri, Feb 26, 2016 at 9:44 AM, Alan Cox <a...@linux.intel.com>
> wrote:
> > On Thu, 2016-02-25 at 15:26 -0500, David Miller wrote:
> > > From: Heikki Hannikainen <he...@hes.iki.fi>
> > > Date: Thu, 25 Feb 2016 21:36:07 +0200 (EET)
> > > 
> > > > Commit 9c7077622dd9174 added a check, ll_header_truncated(),
> > > > which
> > > > requires that a packet transmitted using sendmsg() with
> > > > PF_PACKET,
> > > > SOCK_RAW must be longer than dev->hard_header_len.
> > > 
> > > Fixed by:
> > > 
> > > commit 880621c2605b82eb5af91a2c94223df6f5a3fb64
> > > Author: Martin Blumenstingl <martin.blumensti...@googlemail.com>
> > > Date:   Sun Nov 22 17:46:09 2015 +0100
> > > 
> > > packet: Allow packets with only a header (but no payload)
> > 
> > The AX.25 case the header is variable length so this still doesn't
> > fix
> > the regression as far as I can see.
> 
> Right. The simplest, if hacky, fix is to add something along the
> lines of
> 
>   static unsigned short netdev_min_hard_header_len(struct net_device
> *dev)
>   {
>   if (unlikely(dev->type ==ARPHDR_AX25))
> return AX25_KISS_HEADER_LEN;
>   else
> return dev->hard_header_len;
>   }

AX.25 is not unique in this. Also there are protocols where the minimum
header length for a valid raw frame is not the same as the minimum
sized header for encapsulation of an IP frame because the IP frame is
encapsulated with an extra header block.

> Depending on how the variable encoding scheme works, a basic min
> 
> length check may still produce buggy headers that confuse the stack
> or
> driver. I need to read up on AX25. If so, then extending header_ops
> with an optional validate() function is a more generic approach of
> checking header sanity.

A validate() method is doable for NetROM, AX.25 and friends. So
something like

if (likely(len >= dev->hard_header_len)) 
return good;
if (proto->validate && proto->validate(skb))
return good;
return bad;

works for amateur radio at least, and I think could be extended ok for
any other cases like tunnels.

Alan

Re: Sending short raw packets using sendmsg() broke

[Alan Cox]

On Thu, 2016-02-25 at 15:26 -0500, David Miller wrote:
> From: Heikki Hannikainen 
> Date: Thu, 25 Feb 2016 21:36:07 +0200 (EET)
> 
> > Commit 9c7077622dd9174 added a check, ll_header_truncated(), which
> > requires that a packet transmitted using sendmsg() with PF_PACKET,
> > SOCK_RAW must be longer than dev->hard_header_len.
> 
> Fixed by:
> 
> commit 880621c2605b82eb5af91a2c94223df6f5a3fb64
> Author: Martin Blumenstingl 
> Date:   Sun Nov 22 17:46:09 2015 +0100
> 
> packet: Allow packets with only a header (but no payload)

The AX.25 case the header is variable length so this still doesn't fix
the regression as far as I can see.

Alan

Re: ni52.c warnings explosion

[Alan Cox]

On Wed, 20 Feb 2008 23:26:24 -0800
Harvey Harrison [EMAIL PROTECTED] wrote:

 Dave,
 
 Somewhere between 2.6.25-rc1 and -rc2 something changed that produces a
 few hundred sparse warnings in ni52.c.

I gave it a massive clean up but I've not annotated it
 
 I see Alan touched it last.
 
 drivers/net/ni52.c:219:15: warning: incorrect type in argument 1 (different 
 address spaces)
 drivers/net/ni52.c:219:15:expected void const volatile [noderef] 
 asn:2*addr
 drivers/net/ni52.c:219:15:got unsigned char *noident
 
 If you want the full log, let me know.

Throw it my way. I'll go through it but its probably mostly about
annotating it now it uses io spaces.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 Also your sub PC class appliances rarely run LISTEN servers anyways
 that are open to the world.

Really. The ones that first come to mind often have exposed ports
including PDA devices and phones. (Ditto low end PC boxes - portscan an
EEPC some day ;))

Is the other stuff enough - good question, and can be measured easily
enough on a little dlink router or similar.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 Syncookies are discouraged these days. They disable too many 
 valuable TCP features (window scaling, SACK) and even without them 
 the kernel is usually strong enough to defend against syn floods
 and systems have much more memory than they used to be.

Somewhat untrue. Network speeds have risen dramatically, the number of
appliances running Linux that are not PC class means memory has fallen
not risen and CPU has been pretty level.

 So I don't think it makes much sense to add more code to it, sorry.

I think it makes a lot of sense - providing it defaults off for the PC
world where as you say its use is limited.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 What kind of LISTEN ports? And does it matter if they're DoS'ed?

I guess that depends on the opinion of the owner

- Push based mobile services
- Email delivery
- VoIP
- Management ports
- Peer to peer data transfer
- Instant messaging direct user/user connections

Some of that can also be hardened using IP filter rules

  Is the other stuff enough - good question, and can be measured easily
  enough on a little dlink router or similar.
 
 My guess would be that it is.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 How does syncookies prevent windows from growing?

Enabling them doesn't.

 Most (if not all) distributions have them enabled and window growing
 works just fine. Actually I do not see any reason why connection
 establishment handshake should prevent any run-time operations at all,
 even if it was setup during handshake.

Syncookies are only triggered if the system is under a load where it
would begin to lose connections otherwise. So they merely turn a DoS into
a working if slightly slower setup (and  64K windows don't matter for
most normal users, especially on mobile devices).

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 So I don't think it makes much sense to add more code to it, sorry.
 
 Distributions should then probably deactivate it by default.
 SUSE 10.3 for example still has it enabled on default installs.

Even though I work the loyal opposition to SuSE I'd say SuSE 10.3 is
correct in having it enabled in the build.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Alan Cox]

 SACK is actually a good idea for mobile devices, so preventing
 syncookies from not getting into account some options (btw, does it work
 with timestamps and PAWS?) is not a solution.

Syncookies only get used at the point where the alternative is failure.
No SACK beats a DoS situation most days
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AF_UNIX MSG_PEEK bug?

[Alan Cox]

 and the parallel portions/comments in unix_dgram_recvmsg(),
 it looks like there's been a lot of uncertainty as to how
 file descriptor passing should be handled durning MSG_PEEK
 operations.  To quote:

The specs basically don't answer the question. What is critical is that
the behaviour does not change compared with older Linux releases.

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] the scheduled shaper removal

[Alan Cox]

On Tue, 1 Jan 2008 15:47:35 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:

 This patch contains the scheduled removal of the shaper driver.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Acked-by: Alan Cox [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Top 10 kernel oopses/warnings for the week of December 21st 2007

[Alan Cox]

 Rank 2: uart_flush_buffer
   Warning at drivers/serial/serial_core.c:544 in uart_flush_buffer()
   Reported 16 times
   No specific version information reported; bug present in 2.6.24-rc5
   Caused by a bug in the Bluetooth line discipline/tty code

 Rank 7: uart_write
   Warning at drivers/serial/serial_core.c:490 in uart_write()
   Reported 2 times

Seems to be more of the Bluetooth stuf


Alan
--
DASD is not really IBM - it has a vowel
-Arjan van de Ven
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: namespace support requires network modules to say GPL

[Alan Cox]

On Sat, 1 Dec 2007 16:30:35 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:

 On Sat, 1 Dec 2007 11:17:36 -0800
 Stephen Hemminger [EMAIL PROTECTED] wrote:
 
  Then init_net needs to be not GPL limited. Sorry, we need to allow
  non GPL network drivers.  There is a fine line between keeping the
  binary seething masses from accessing random kernel functions, and allowing
  reasonable (but still non GPL) things like ndiswrapper to use network
  device interface.
  
 I spoke too soon earlier, ndiswrapper builds and loads against current
 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I 
 don't
 give a damn, but the enterprise distro vendors certainly care.

Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't
see why they care.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: namespace support requires network modules to say GPL

[Alan Cox]

 You license yours under the GPL, so they should respect the GPL.
 
 It sounds like we're back to where we were years ago. Didn't we already
 agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had
 nothing to do with respecting the GPL? After all, if it s a GPL-enforcement

No we seem to be back recycling the fact that certain people were making
statements that might be construed, unanswered, as giving permission to
violate the GPL.

I'm merely reminding people that I've not waived my GPL rights, I've not
said modules are somehow magically OK, and I don't agree with Linus. 

The GPL very clearly says that you can make your own unredistributed
modifications and keep them that way.

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: namespace support requires network modules to say GPL

[Alan Cox]

 Then init_net needs to be not GPL limited. Sorry, we need to allow
 non GPL network drivers.  There is a fine line between keeping the

Why - they aren't exactly likely to be permissible by law

 binary seething masses from accessing random kernel functions, and allowing
 reasonable (but still non GPL) things like ndiswrapper to use network
 device interface.

Its up to the ndiswrapper authors how the licence their code, but they
should respect how we licence ours.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: namespace support requires network modules to say GPL

[Alan Cox]

 Then change the license, explicitly and get it approved, forcing license
 changes by technically subversive means is bad policy. It is like Euro 
 bureaucrats

I don't need to - the licence has been the same since about 0.12

Alan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

[Alan Cox]

 when these messages appear, removing r8169 would appear to be key. Indeed, if 
 there is no significant libata activity, the problem still occurs on the NIC 
 within approximately the same amount of transfer.

You seem to have a leak, which actually isn't suprising

rtl8169_xmit_frags allocates a set of maps for a fragmented packet

rtl8169_start_xmit allocates a buffer

When we finish the transit we free the main buffer (always using skb-len
when sometimes its skb-headlne. We don't seem to free the fragment
buffers at all.

Looks like the unmap path for fragmented packets is broken with any kind
of iommu

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] New Kernel Bugs

[Alan Cox]

  pata_pdc202xx_old excessive ATA bus errors
  http://bugzilla.kernel.org/show_bug.cgi?id=9337
  2.6.24-rc2
 
 No response from developers

Untrue. We've been discussing it on list in the past and its now on
bugzilla. Not obvious from outside I realise. That one I'm afraid is
probably a longer term item.

  DVD-RAM umount and disk free bug
  http://bugzilla.kernel.org/show_bug.cgi?id=9265
  Kernel: 2.6.15  (asked to try current kernel)
 
 No response from developers

Not actually sure who is looking after this now ?

  LPC IT8705 POST port making noise on parallel port
  http://bugzilla.kernel.org/show_bug.cgi?id=9306
  Kernel: 2.6.16+
  
 
 No response from developers

Not sure who really owns parallel. Have grabbed and will sort
out.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] New Kernel Bugs

[Alan Cox]

 The other an automated set of standard pre-built bisection points so
 that testers can more easily localize a bug down to a few hundred
 commits without needing to learn how to use git bisect (think Ubuntu
 users).

Before that you want a flowchart or instruction list of boot options to
try. A lot of errors can be localised simply by asking the reported to
boot with things like iommu=off, pci=routeirq, apci=off etc

That takes a lot less time to run through and can be very informative.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] New Kernel Bugs

[Alan Cox]

 Given the wide range of ARM platforms today, it is utterly idiotic to
 expect a single person to be able to provide responses for all ARM bugs.
 I for one wish I'd never *VOLUNTEERED* to be a part of the kernel
 bugzilla, and really *WISH* I could pull out of that function.

You can. Perhaps that bugzilla needs to point to some kind of
[EMAIL PROTECTED] list for the various ARM platform
maintainers ?

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] New Kernel Bugs

[Alan Cox]

 Bug fixing is not about finding someone to blame, it's about getting the 
 bug fixed.

Partly - its also about understanding why the bug occurred and making it
not happen again.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] remove Documentation/networking/pt.txt

[Alan Cox]

On Mon, 5 Nov 2007 18:05:57 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:

 There's no no point in keeping documentation for a driver that was 
 removed many years ago.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Defintiely very dead

Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] remove comx driver docs

[Alan Cox]

On Mon, 5 Nov 2007 18:04:45 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:

 The drivers have already been removed 3.5 years ago.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]


Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.

[Alan Cox]

 People aren't going to report this as a bug. They aren't going to try out 
 patches,
 they're going to do what I did and stick another network card in the box and
 go on with life.
 
 Our users deserve better than this.

Agreed. By all means warn people, or give them a 1-800 Intel number to
phone, but they should be able to continue as well.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bind and O_NONBLOCK

[Alan Cox]

On Sat, Sep 22, 2007 at 10:58:18PM -0700, David Miller wrote:
 From: Ulrich Drepper [EMAIL PROTECTED]
 Date: Sat, 22 Sep 2007 10:11:01 -0700
 
  There was no public mail.  I asked RH engineering for proposals for
  changes to the POSIX spec and Alan replied.
 
 Please do not discuss such proposals only privately, especially when
 the ramifications affect the entire community.
 
 It is important the things get hashed out on a public forum where
 all networking developers can add their insight into the problem.

It was - about six years ago while netbeui/netbios merging was being
discussed. It got tagged then and finally ended up here.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bind and O_NONBLOCK

[Alan Cox]

On Sat, Sep 22, 2007 at 08:14:15PM +0400, Evgeniy Polyakov wrote:
 of operations. There are four ways where bind can fail:
 
 1. unsufficient rights - nothing can help here
 2. there is no memory - async binding can not help here too, since it
   some memory just has to be allocated to save async request
   somewhere.
 3. socket is locked.
 4. addres is being bound is in use.

For most protocols yes - but not all. For things like IP specifying O_NDELAY
is meaningless on a bind it will always complete on the spot as you say

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] bnx2: factor out gzip unpacker

[Alan Cox]

 For example, bnx2 maintainer says that driver and
 firmware are closely tied for his driver. IOW: you upgrade kernel
 and your NIC is not working anymore.
 
 Another argument is to make kernel be able to bring up NICs
 without needing firmware images in initramfs/initrd/hard drive.

dgrs should be using the request_firmware interface. Actually dgrs is
probably a good candidate for /dev/null

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] bnx2: factor out gzip unpacker

[Alan Cox]

 According to an earlier thread, dgrs was never really maintained, 
 written for hardware that was never really distributed widely, and very 
 likely hasn't had users in years... if ever.
 
 If that picture is accurate (it's a story I was told), then I am 
 definitely queueing up a deletion patch.

I think thats sensible. If someone whines it can be put back but I really
don't think anyone will
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: follow-up: discrepancy with POSIX

[Alan Cox]

On Wed, 19 Sep 2007 09:15:10 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:

 From: Ulrich Drepper [EMAIL PROTECTED]
 Date: Wed, 19 Sep 2007 08:21:47 -0700
 
  If you think the POSIX spec is wrong (and can point to other
  implementations doing the same as Linux) let me know and I'll work on
  getting the spec changed.
 
 The whole AF_UNSPEC thing I'm almost certain comes from BSD, which has
 behaved that way for centuries.

We got it from the 1003.4g draft socket specification if I remember
rightly. Its entirely plausible that got it from 4BSE.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: follow-up: discrepancy with POSIX

[Alan Cox]

On Wed, 19 Sep 2007 10:46:54 -0700
Ulrich Drepper [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Andi Kleen wrote:
  But the spec calls for a null address to be used and that's in my
  understanding something different from using AF_UNSPEC.
  
  memset(sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC
 
 But the spec calls for quotenull address for the protocol/quote.
 
 That means the family for the null address is the same as the family of
 the socket.

Which is a valid address in some protocols. If I remember rightly then
appletalk net 0 node 0 port 0 is valid although I'd want to look in the
book to check that - ditto AF_ECONET although I doubt anyone cares too
much 8)

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: That whole Linux stealing our code thing

[Alan Cox]

 co-operation. Together we advance our detective work and knowledge of
 the Macintosh platforms to the good of all Macintosh users dumped
 
 Alan Cox circa 1999.
 
 http://lists.freedesktop.org/archives/xorg/2007-August/027419.html
 
 well I'd be quite happy to see X go GPL but I'm aware
 thats not the intention of the project ;)
 Alan Cox circa 2007.
 
 What changed? 

Nothing that I am aware of. You can't take Linux/Mac68K code back into
BSD either. BSD code is being used according to the BSD licence. You
could adopt a different licence if the way your code is being used
bothers you, thats.

Where I've reused BSD code I've aways tried to contribute it back to the
BSD people or share the knowledge (and the knowledge far more than the
code mattered both ways for Mac68K systems)

I suggest you read drivers/net/wan/syncppp.c, which is I think the only
BSD derived bit of code of mine left in the kernel - and its quite
specific what it says.

Ath5k isn't my code so I don't get to pick. Having the OpenBSD maintainer
make bogus remarks about that doesn't help anyone, especially when he's
wrong and doesn't appear to know about the subject in the first place.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: That whole Linux stealing our code thing

[Alan Cox]

 - If you receive ISC or BSD licensed code, you may not delete the
  license.  Same principle, since the notice says so.  It's the law.
  Really.

You can shout this all you like but you would be wrong. You can remove
the licence if you have permission to do so. For the ath c files there
was permission to do so.

 My understanding is that with dual-licensed code, you choose to comply
 with all of the terms of either licence. However, you cannot simply
 remove either of these licences from the code, unless you specifically
 receive such right from the copyright holder (remember, with the
 copyright law, unless the rights are specifically given, they are
 retained). This is what Theo was trying to educate the community on. I
 don't see anything unethical in explaining the legal issues.

Your understanding isn't quite right. One of many things you may get with
dual licensed code is the right to pick a licence from several choices,
you may also get the right to remove some choices from the recipient.

A work that combines GPL and BSD licensed material is not the same as a
work which says I may choose between two licences. If both licences must
always apply (which is a perfectly possible condition to put in a
licence) then putting such a both GPL/BSD licence piece of code into
OpenBSD would require any OpenBSD distributed containing it was GPL
licenced when conveyed, which I am *very* sure is not the intent.

Thus what you appear to be doing by putting the ath5k C code in OpenBSD is
conveying it under the BSD licence (making a choice between the two
offered) and conveying a right for parties down the chain to convey it
under one of the licences only.

And as we've already established the header files are quite different.


Doesn't mean its not somewhat rude but illegal and rude are two very
different things.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: That whole Linux stealing our code thing

[Alan Cox]

On Sun, 02 Sep 2007 13:20:27 +0200 (CEST)
Igor Sobrado [EMAIL PROTECTED] wrote:

 On Sun, 2 Sep 2007, Alan Cox wrote:
  You can shout this all you like but you would be wrong. You can remove
  the licence if you have permission to do so. For the ath c files there
  was permission to do so.
 
 There was permission to do so from Reyk Floeter?  Really?

The code pieces I quoted contained that choice. As far as I am concerned
that is what the discussion was about. 

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: That whole Linux stealing our code thing

[Alan Cox]

 So, a multi-licensed file remains multi-licensed except when all authors 
 agree about a change in the licensing terms.  And it is clear on the BSD 

Not strictly true. They can either agree to a change and issue one or
they can convey to other parties the right to change the terms. The GPL
for example does this for version selection.

A multi-licensed work (note work not file - don't assume a file is a
boundary of a work) which conveys the choice of licence (as some bits of
ath5k did) allows a receiving party to choose the licence it wishes.
Failing that OpenBSD would have turned itself GPL by adding that file as
according to your argument it must be distributed under *all* these
licensing terms concurrently.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: That whole Linux stealing our code thing

[Alan Cox]

  Not strictly true. They can either agree to a change and issue one or
  they can convey to other parties the right to change the terms. The GPL
  for example does this for version selection.
 
 So, under a dual-licensed BSD/GPL code the latter license allows a 
 developer to remove the GPL license itself and release a single-licensed 
 BSD code if other parties want to do it?

If the dual licence permits you to select from two alternatives as
appears to be the case in

* Alternatively, this software may be distributed under the terms of the
 * GNU General Public License (GPL) version 2 as published by the Free
 * Software Foundation.

Then there is no problem in doing exactly what it says and distributing
it under the terms of the GPL v2 and the GPL v2 alone (or indeed the BSD
licence alone). Anyone who took the project code and produced a binary
only proprietary product from it would for example select the BSD licence
alone and convey almost no rights at all to their customer.

 I would assume a file as a boundary of a work in the case that file is 
 under different licensing terms to the rest of the software package.  On a 

Assuming is bad, you should consult caselaw.

 lot of software packages different modules are covered under different 
 licensing terms.
 
 We can choose what license terms we will honor; however, we do not have 
 the ability to remove the licensing terms we do not like.

If the author has conveyed that right to you, then you may usually do so.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Alan Cox]

  to remove the BSD/other license.   Jiri can release *his* code as GPLv2
  only, but I suspect the files as a whole really should be dual BSD/GPLv2,
  due to the numerous other stakeholders in those files.
 
 This mess has been occurring in the kernel for years. The DRM graphics
 drivers are used in both BSD and Linux. It is quite easy to contribute
 something to this code via LKML and think you are doing it under the
 GPL. Doesn't a patch against the kernel have to be GPL? When these
 patches get pulled back into BSD and distributed with it, did BSD get
 infected with the GPL? AFAIK this has never been legally sorted out.

I'm not aware anyone has felt it needed sorting out. Its not exactly
complicated.

BSD non advertising is compatible with GPL

The GPL says:
when you distribute the same sections as part of a whole which
is a work based on the Program, the distribution of the whole
must be on the terms of this License, 

The BSD license doesn't conflict with that

The GPL (and copyright law also say)

If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to ...

All a bit irrelevant anyway as Ath5K code (not the .h file) say:

 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License (GPL) version 2 as published by the Free
 * Software Foundation.

So Jiri is choosing to distribute it under the GPL, and with his changes
GPL only.

So whats the problem ?

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Alan Cox]

 Aren't patches made against the kernel GPL'd if the author doesn't
 explicitly grant them more liberal BSD license in addition?

That would be the normal assumption.

 The problem then comes in taking the patches that were only made
 available against GPL code and reshipping them under the BSD license
 without the author explicitly agreeing to this.
 
 What if a patch spans both code that is pure GPL and code imported
 from BSD, how do you license it?

See the acpi codebase for a worked example.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT

[Alan Cox]

On Wed, 15 Aug 2007 10:10:38 +0200
Stefan Richter [EMAIL PROTECTED] wrote:

 Alan Cox wrote:
   Actually I think the entire thing is a
   bad idea but thats another matter.
 
  Working off the git tree as it shows who actually is making
  changes/updating stuff recently and why which is a major clue when
  tracing bugs
 
 Adrian Bunk wrote in http://lkml.org/lkml/2007/6/30/107 :
 | I don't see how git could tell you to Cc net patches to
 | [EMAIL PROTECTED]
 
 Ditto with problem reports.
 
 For example, Cc'ing linux1394-devel on FireWire topics is a lot more
 important than Cc'ing me.

Tools question. And even if you need to keep a simple set of mappings by
hand for mailing list/files thats a fairly small set of patterns
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT

[Alan Cox]

On Sun, 12 Aug 2007 23:23:36 -0700
[EMAIL PROTECTED] wrote:

 Add file pattern to MAINTAINER entry
 
 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 90c1b81..ac2226b 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -697,6 +697,7 @@ ARPD SUPPORT
  P:   Jonathan Layes
  L:   netdev@vger.kernel.org
  S:   Maintained
 +F:   net/ipv4/arp.c

NAK

arp.c is the netdev people, ARPD is a corner case bit of code within it,
something your patterns don't actually cope with
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT

[Alan Cox]

On Mon, 13 Aug 2007 08:46:06 -0700
Joe Perches [EMAIL PROTECTED] wrote:

 On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote:
   diff --git a/MAINTAINERS b/MAINTAINERS
   index 90c1b81..ac2226b 100644
   --- a/MAINTAINERS
   +++ b/MAINTAINERS
   @@ -697,6 +697,7 @@ ARPD SUPPORT
P:   Jonathan Layes
L:   netdev@vger.kernel.org
S:   Maintained
   +F:   net/ipv4/arp.c
  
  NAK
  
  arp.c is the netdev people, ARPD is a corner case bit of code within it,
  something your patterns don't actually cope with
 
 Suggestions?

I wouldn't add a pattern for this. Actually I think the entire thing is a
bad idea but thats another matter.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT

[Alan Cox]

On Mon, 13 Aug 2007 10:04:19 -0700
Joe Perches [EMAIL PROTECTED] wrote:

 On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote:
  I wouldn't add a pattern for this.
 
 Back to:ARPD SUPPORT
 P:Jonathan Layes
 L:netdev@vger.kernel.org
 S:Maintained
 
  Actually I think the entire thing is a
  bad idea but thats another matter.
 
 Of course it's not an end-all solution,
 but what might work better?

Working off the git tree as it shows who actually is making
changes/updating stuff recently and why which is a major clue when
tracing bugs
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] sysctl: Remove broken cdrom binary sysctls

[Alan Cox]

On Fri, 10 Aug 2007 15:00:05 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:

 
 The binary interface for the cdrom sysctls can't possilby work.
 So remove the binary sysctls and reduce cdrom_sysctl_handler
 to it's essentials (to kill the uses of ctl_name).
 
 Since the last time this patch was posted I radically
 simplified cdrom_sysctl_helper to meet address Alan's objections.
 
 Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]

Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.20-2.6.21 - networking dies after random time

[Alan Cox]

 So the whole locking is to be able to keep irqs enabled for a long time, 
 without risking entry of the same IRQ handler on this same CPU, correct?

As implemented - on any CPU.

We also need to know that the IRQ handler is not doing useful work on
another processor which is why we take the lock after disabling the
interrupt line everywhere. Without that we might be completing an IRQ on
another CPU and that would race the transmit and make a nasty mess.

 So it seems to me that maybe the driver could be surprised via these 
 spurious interrupts that happen right after the irq_enable(). Does the 
 patch below make any sense in your opinion?

For MMIO it does look like that may be needed. Looks sensible.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][netdrvr] lib8390: comment on locking by Alan Cox Re: 2.6.20-2.6.21 - networking dies after random time

[Alan Cox]

On Thu, 26 Jul 2007 14:44:01 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:

 Hi,
 
 Very below is my patch proposal with a comment, which in my opinion
 is precious enough to save it for future help in reading and
 understanding the code.
 
 I hope Alan will not blame me I've not asked for his permission before
 sending, and he would ack this patch as it is or at least most of this.

Fine by me

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.20-2.6.21 - networking dies after random time

[Alan Cox]

  The code in question lib8390.c does
  
  disable_irq();
  fiddle_with_the_network_card_hardware()
  enable_irq();
 ...
  
  No idea how this affects the network card, as the code there must be
  able to handle interrupts, which are not originated from the card due to
  interrupt sharing.
 
 I think, in this last yesterday's patch Ingo could be right, yet!
 The comment at the beginnig points this is done like that because
 of chip's slowness. And problems with timing are mysterious.
 
 On the other hand author of this code didn't use spin_lock_irqsave
 for some reason, probably after testing this option too. So, I hope
 this is the right path, but alas, I'm not sure this patch has to
 prove this 100%.

The author (me) didn't use spin_lock_irqsave because the slowness of the
card means that approach caused horrible problems like losing serial data
at 38400 baud on some chips. Rememeber many 8390 nics on PCI were ISA
chips with FPGA front ends.

 Anyway, in my opinion this situation where interrupts could/have_to
 be used for such strange things should confirm the need of more
 options for handling irqs individually.

Ok the logic behind the 8390 is very simple:

Things to know
- IRQ delivery is asynchronous to the PCI bus
- Blocking the local CPU IRQ via spin locks was too slow
- The chip has register windows needing locking work

So the path was once (I say once as people appear to have changed it
in the mean time and it now looks rather bogus if the changes to use
disable_irq_nosync_irqsave are disabling the local IRQ)


Take the page lock
Mask the IRQ on chip
Disable the IRQ (but not mask locally- someone seems to have
broken this with the lock validator stuff)
[This must be _nosync as the page lock may otherwise
deadlock us]
Drop the page lock and turn IRQs back on

At this point an existing IRQ may still be running but we can't
get a new one

Take the lock (so we know the IRQ has terminated) but don't mask
the IRQs on the processor
Set irqlock [for debug]

Transmit (slow as )

re-enable the IRQ


We have to use disable_irq because otherwise you will get delayed
interrupts on the APIC bus deadlocking the transmit path.

Quite hairy but the chip simply wasn't designed for SMP and you can't
even ACK an interrupt without risking corrupting other parallel
activities on the chip.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] [PATCH] [IrDA] KS959 USB IrDA dongle support

[Alan Cox]

 Too late, Linus just closed the merge window, you had two
 weeks to submit this :-)
 Too bad...
 I submitted it as soon as it was ready. Will we have to wait until the
 2.6.24 merge window, or can it be applied earlier as it's a fully
 standalone driver ?

You can always send Linus a copy and ask but if its just finished then
far better to send it to Andrew so that it can get testing and picked at
in -mm then merged next time around when polished.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix race in AF_UNIX

[Alan Cox]

 No, correctness always trumps performance.  Lost packets on an AF_UNIX
 socket are _unexceptable_, and this is definitely not a theoretical
 problem.

If its so unacceptable why has nobody noticed until now - its a bug
clearly, it needs fixing clearly, but unless you can produce some kind of
exploit from it (eg a DoS attack or kernel memory leak exploiter) it
doesn't appear to be that serious.

 And BTW my second patch does _not_ have the performance problems you
 are arguing about, it's just plain ugly.  But hey, if you can't live
 with ugly code, go and fix it.

If you put ugly code into the kernel you pay for maintaining it for years
to come. If you get it right then you don't

 Do you want me to send the patch to Andrew instead?  His attitude
 towards bugfixes is rather better ;)

And it'll get NAKked and binned. DaveM is (as happens sometimes ;)) right
to insist on the code being clean and efficient.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix race in AF_UNIX

[Alan Cox]

On Mon, 18 Jun 2007 12:43:40 +0200
Thomas Graf [EMAIL PROTECTED] wrote:

 * Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 12:39
  You are wrong.  Look in unix_release_sock():
  
  if (atomic_read(unix_tot_inflight))
  unix_gc();  /* Garbage collect fds */
  
  
  unix_tot_inflight is the number of AF_UNIX sockets currently being
  transferred over some AF_UNIX sockets.
  
  That means that just sending (non-unix socket) fds over unix sockets
  will never invoke the gc.
 
 That's what I meant, I'm sorry, I should have written unix socket
 file descriptor to not leave any room for misinterpretation.

You can bound the worst case on this and I think stay within the specs
(as the specs don't say a lot about it). One way would be to make
unix_gc() kick off a thread/tasklet and if the last unix_gc was within 5
seconds then use a timer to defer it - that prevents any user driven
lets cause a ton of gc cases.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Cox]

On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty [EMAIL PROTECTED] wrote:

 Hi,
 
 Is select(0, ..) is a valid operation ?

Yes. It's a fairly classic old BSD way to do timeouts

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch:replace with time_after in drivers/net/eexpress.c

[Alan Cox]

On Wed, Mar 28, 2007 at 10:44:31AM +0530, Shani wrote:
 Hi,
 
 Replacing with time_after in drivers/net/eexpress.c
 Applies and compiles clean on latest tree.Not tested.
 
 thanks.
 
 Signed-off-by: Shani Moideen [EMAIL PROTECTED]

NAK as not tested. The existing code is known to work so ugly or not
it is better than untested changes


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]

[Alan Cox]

  (*) SOCK_RPC has been removed.  AF_RXRPC sockets now simply ignore the type
  argument to socket().

This is also incorrect

NAK

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]

[Alan Cox]

 These patches together supply secure client-side RxRPC connectivity as a Linux
 kernel socket family.  Only the transport/session side is supplied - the
 presentation side (marshalling the data) is left to the client.  Copies of the
 patches can be found here:

Some of them don't seem to be making it through to the list and are
dropped each time btw
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]

[Alan Cox]

Ok quickly going over the code that hasn't made the list

- recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
fixed one day as its useful to find out the sizeof message pending when
combined with MSG_PEEK

- RXRPC_MIN_SECURITY_LEVEL reads into rx-min_sec_level and then if it is
invalid reports an error but doesn't restore the valid level

- Why does rxrpc_writable always return 0 ?

- rxrpc_process_soft_ACKs doesn't itself limit and check acns-nAcks is
always below RXRPC_MAXACKS, as this is a stakc variable it ought to be
paranoid about it. I think its ok from the caller check but its very hard
to prove...


It needs a lot more eyes/review due to the complexity and network
exposure though - not your fault, whoever designed RXRPC's 8)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

[Alan Cox]

  Because that's really the issue: do you want a pretty backtrace, or do 
  you want one that is rock solid but has some crud in it.
 
 I just want an as exact backtrace as possible. I also think
 that we can make the unwinder robust enough.

Any reason you can't put the exact back trace in [xxx] and the ones we
see on the stack which dont look like call trace as ?xxx? It makes the
code a bit trickier but we depend on the quality of traces

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

 IMHO the problem with classifying RxRPC as a reliable datagram  
 socket is that even an atomic unidirectional communication isn't a  
 single datagram, it's at least 3; there is shared connection state  

Thats fine. Any *reliable* protocol sends more than one packet per
message you send. RDM is for reliable messages

 independent and possibly simultaneous RxRPC calls.  From the digging  
 around that I did in the kernel socket code a while ago I don't see a  
 cleaner way of implementing it than a new SOCK_RXRPC.

I disagree entirely. I've still seen no evidence you need a new type for
this. What does AIX do  out of interest ?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

 message transmission.  You yourself defined RDM to be a datagram service.
 RxRPC is not, in my opinion, a datagram service, and neither is it a stream
 service.

Message is what I should have said.

 Interestingly, searching for SOCK_RDM definitions with google shows there's
 some disagreement as to what it represents.  Some seem to thing it's 
 connection
 oriented and some that it's connectionless, and some seem to think it's
 ordered, and some not.

Which is just fine, does it need to be one or the other. SOCK_DGRAM an be
both connection oriented or connectionless.

 
   independent and possibly simultaneous RxRPC calls.  From the digging  
   around that I did in the kernel socket code a while ago I don't see a  
   cleaner way of implementing it than a new SOCK_RXRPC.
 
 Well, I suggest SOCK_RPC, not SOCK_RXRPC.  There's no particular reason such a
 flow type has to be limited to RxRPC.

Other RPC types use normal socket types.

 I'd say that that precludes applicability on two points: firstly, RxRPC is not
 a datagram layer by the definition I provided in a previous email; and
 secondly, RxRPC *does* provide some ordering guarantees.

So you want SOCK_SEQPACKET perhaps then ?

  What does AIX do out of interest ?
 
 I've no way to find out what AIX does, but I suspect it simply doesn't.

Perhaps someone with AIX boxes around (say @ibm.com) could answer ?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

  Other RPC types use normal socket types.
 
 They do?  Examples please.  I didn't think Linux, at least, has any other RPC
 socket families, though I could be wrong as I haven't made a thorough study of
 them.

SunRPC is implemented in user space and uses the existing TCP/IP layer
and socket types, even though it is using them in an RPC manner and
viewed at the RPC layer they are RPCs

  I have made my client sockets use connect(), but that's just a 
 convenience
  and I need to make it possible to avoid doing that to make it useful to
  the kernel.  It's similar to SOCK_DGRAM sockets in this respect.

So use SOCK_DGRAM, its clearly near enough.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

O No, it's not.  SOCK_DGRAM is an unreliable, unidirectional datagram passing
 service.

Thats funny UDP receives and sends packets.


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] AF_RXRPC: Make it possible to merely try to cancel timers and delayed work [try #2]

[Alan Cox]

 +/**
 + * try_to_cancel_delayed_work - Try to kill pending scheduled, delayed work
 + * @work: the work to cancel
 + *
 + * Try to kill off a pending schedule_delayed_work().
 + * - The timer may still be running afterwards, and if so, the work may still
 + *   be pending
 + * - Returns -1 if timer still active, 1 if timer removed, 0 if not scheduled
 + * - Can be called from the work routine; if it's still pending, just return
 + *   and it'll be called again.
 + */
 +static inline int try_to_cancel_delayed_work(struct delayed_work *work)
 +{
 + int ret;

This expands to a fair bit of code and IMHO isn't an inline candidate.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2]

[Alan Cox]

  very odd line split
 
 It's not really odd.  The static and inline don't actually add anything to
 the function template.  They're merely scope limiters / optimisation
 controllers, and so make a lot of sense placed on their own line.

As do many things but the goal of the coding style is consistency and
almost all other code doesn't have the static inline wasting an extra
display line.


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

 Sockets of AF_RXRPC family are:
 
  (1) created as type SOCK_RPC;

There is no such socket type and please don't invent one

If your messages are datagrams and unreliable - SOCK_DGRAM
If your messages are datagrams and reliable - SOCK_RDM
If your messages are datagrams, reliable and ordered - SOCK_SEQPACKET
If your messages are streams of bits, reliable and ordered - SOCK_STREAM


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

On Fri, 16 Mar 2007 14:23:13 +
David Howells [EMAIL PROTECTED] wrote:

 Alan Cox [EMAIL PROTECTED] wrote:
 
  If your messages are datagrams and unreliable - SOCK_DGRAM
 
 Nope.
 
  If your messages are datagrams and reliable - SOCK_RDM
 
 Nope.
 
  If your messages are datagrams, reliable and ordered - SOCK_SEQPACKET
 
 Nope.
 
  If your messages are streams of bits, reliable and ordered - SOCK_STREAM
 
 Nope.

So your messages are neither reliable not unreliable, nor ordered, nor
unordered.

NAK

Until you work out what your messages actually are and use a proper
standard socket type. And but there are higher layers isn't relevant
here, this is true for Appletalk as well and it doesn't have to go
inventing new types for everything as you seem to.

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Alan Cox]

 I know what they are; and I don't think that what's available covers it.
 
  and use a proper standard socket type.
 
 Assuming that that list is exhaustive...

SOCK_RDM seems to match perfectly well here. The point isn't to enumerate
everything in the universe the point is to find works like parallels
good enough to avoid more special casing.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/9] iPhase: 64bit cleanup

[Alan Cox]

Ar Iau, 2006-11-09 am 16:12 -0800, ysgrifennodd David Miller:
 Really, this driver has a ton of unresolved portability problems.

Agreed - but at least its now 64bit clean. No objection to leaving it !
64BIT at all even with the patch merged.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set

[Alan Cox]

Ar Sul, 2006-10-15 am 18:10 -0700, ysgrifennodd Andrew Morton:
 Question is, should pci_set_mwi() ever return -EFOO?  I guess it should, in
 the case where setting the line size didn't work out.

It does no harm, no driver will ever check anything but 0 v !0 because
the handling is no different in either case.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set

[Alan Cox]

Ar Sul, 2006-10-15 am 16:44 -0700, ysgrifennodd Andrew Morton:
 Let me restore the words from my earlier email which you removed so that
 you could say that:
 
   For you the driver author to make assumptions about what's happening
   inside pci_set_mwi() is a layering violation.  Maybe the bridge got
   hot-unplugged.  Maybe the attempt to set MWI caused some synchronous PCI
   error.  For example, take a look at the various implementations of
   pci_ops.read() around the place - various of them can fail for various
   reasons.  

Let me repeat what I said before. As a driver author I do not care. It
doesn't matter if it failed because it is not supported or because a
pink elephant went for a dance on the PCI bus.

   Now it could be that an appropriate solution is to make pci_set_mwi()
   return only 0 or 1, and to generate a warning from within pci_set_mwi()
   if some unexpected error happens.  In which case it is legitimate for
   callers to not check for errors.

That would be my belief, and ditto for a lot of these other functions -
even the correctly __must_check ones like pci_set_master should do the
error reporting in the set_master() function etc not in every driver.
That gives us a single consistent printk and avoids missing them out or
bloat.

Alan

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bulk] Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set

[Alan Cox]

Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
 Since it's not an error, there should be no such printk ... which
 is exactly how it's coded above.

The underlying bug is that someone marked pci_set_mwi must-check, that's
wrong for most of the drivers that use it. If you remove the must check
annotation from it then the problem and a thousand other spurious
warnings go away.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bulk] Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set

[Alan Cox]

Ar Sul, 2006-10-15 am 10:45 -0700, ysgrifennodd Andrew Morton:
 If the drivers doesn't care and if it makes no difference to performance
 then just delete the call to pci_set_mwi().
 
 But if MWI _does_ make a difference to performance then we should tell
 someone that it isn't working rather than silently misbehaving?

It isn't misbehaving it just isn't available. MWI is rather different to
say pci_set_master() in that it makes a lot of sense for many drivers to
ask for it but not care about the results. Something like pci_set_master
failing is a big problem and has to be handled (although as we often
don't use BIOS PCI services we see fake success in some cases).

MWI is an extra cheese option not a no pizza case

Alan

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh

[Alan Cox]

Ar Llu, 2006-10-16 am 07:26 +1000, ysgrifennodd Benjamin Herrenschmidt:
 On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
  From: Jesse Huang [EMAIL PROTECTED]
  
  Change Logs:
  For patent issue need to remove TxStartThresh and RxEarlyThresh. This 
  patent 
  is cut-through patent. If use this function, Tx will start to transmit 
  after 
  few data be move in to Tx FIFO. We are not allow to use those function in 
  DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little 
  performance.
 
 Somebody patented FIFO thresholds ? Gack ?

3COM hold several patents on certain kinds of early interrupt/early
start for network FIFOs. At least historically they also had a GPL Linux
driver that didn't use that feature on their own cards which I'm told
was fear of patent leakage

Alan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set

[Alan Cox]

Ar Sul, 2006-10-15 am 16:18 -0700, ysgrifennodd Andrew Morton:
 No.  If pci_set_mwi() detects an unexpected error then the driver should
 take some action: report it, recover from it, fail to load, etc.  If the
 driver fails to do any of this then it's a buggy driver.

Wrong and there are several drivers in the kernel that are proof of
this.

 You, the driver author _do not know_ what pci_set_mwi() does at present, on
 all platforms, nor do you know what it does in the future.  For you the

You don't care. It isn't an error for set_mwi to fail. In fact the only
reason set_mwi even needs to bother with a return code is that some
chips want you to set other config private to the device if it is
available and active.

Alan

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hardware bug or kernel bug?

[Alan Cox]

Ar Gwe, 2006-10-13 am 17:24 +0100, ysgrifennodd David Johnson:
 IDE controller, then continuing. Could the same thing be happening in Linux? 
 If Linux can't talk to the IDE controller when trying to write to disk, how 
 does it handle that?

It will timeout and then retry the command. It's not the most ideal
situation to end up in but I'd expect to see a DMA timeout and a retry
or two in the log not a crash.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git-or-PATCH] IRQ handler cleanups

[Alan Cox]

Acked-by: Alan Cox [EMAIL PROTECTED]

All looks ok, the bigger change in riscom8 is verifiably safe too

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Introduce BROKEN_ON_64BIT facility

[Alan Cox]

Ar Llu, 2006-10-02 am 00:55 -0400, ysgrifennodd Jeff Garzik:
 Add a broken-on-64bit option, similar to the existing broken-on-smp
 config option.  This is just the first pass, marking the obvious
 candidates.

NAK. This contains lots of stuff whcih isn't broken in the first place.

(Eg Megaraid works with 32bit config tools not 64bit ones and is
otherwise fine, ISDN is just bogus warnings now swatted)

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Introduce BROKEN_ON_64BIT facility

[Alan Cox]

Ar Llu, 2006-10-02 am 09:52 -0400, ysgrifennodd chas williams -
CONTRACTOR:
 some of the drivers in atm are already marked with !64BIT and some
 need to be marked.  this might be more complete for drivers/atm/Kconfig:

This should fix Iphase for one. Some of the others look a lot harder
however

Signed-off-by: Alan Cox [EMAIL PROTECTED]

Binary files linux.vanilla-2.6.18-mm2/drivers/atm/fore200e_mkfirm and 
linux-2.6.18-mm2/drivers/atm/fore200e_mkfirm differ
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.18-mm2/drivers/atm/iphase.c 
linux-2.6.18-mm2/drivers/atm/iphase.c
--- linux.vanilla-2.6.18-mm2/drivers/atm/iphase.c   2006-09-20 
04:42:06.0 +0100
+++ linux-2.6.18-mm2/drivers/atm/iphase.c   2006-10-02 15:28:51.678220488 
+0100
@@ -93,10 +93,6 @@
 
 MODULE_LICENSE(GPL);
 
-#if BITS_PER_LONG != 32
-#  error FIXME: this driver only works on 32-bit platforms
-#endif
-
 / IA_LIB **/
 
 static void ia_init_rtn_q (IARTN_Q *que) 
@@ -1408,7 +1404,6 @@
struct abr_vc_table  *abr_vc_table; 
u16 *vc_table;  
u16 *reass_table;  
-u16 *ptr16;
int i,j, vcsize_sel;  
u_short freeq_st_adr;  
u_short *freeq_start;  
@@ -1423,14 +1418,15 @@
printk(KERN_ERR DEV_LABEL can't allocate DLEs\n);
goto err_out;
}
-   iadev-rx_dle_q.start = (struct dle*)dle_addr;  
+   iadev-rx_dle_q.start = (struct dle *)dle_addr;
iadev-rx_dle_q.read = iadev-rx_dle_q.start;  
iadev-rx_dle_q.write = iadev-rx_dle_q.start;  
-   iadev-rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct 
dle)*DLE_ENTRIES);  
+   iadev-rx_dle_q.end = (struct dle*)((unsigned 
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* the end of the dle q points to the entry after the last  
DLE that can be used. */  
   
/* write the upper 20 bits of the start address to rx list address 
register */  
+   /* We know this is 32bit bus addressed so the following is safe */
writel(iadev-rx_dle_dma  0xf000,
   iadev-dma + IPHASE5575_RX_LIST_ADDR);  
IF_INIT(printk(Tx Dle list addr: 0x%08x value: 0x%0x\n, 
@@ -1584,11 +1580,12 @@
   Set Packet Aging Interval count register to overflow in about 4 us
*/  
 writew(0xF6F8, iadev-reass_reg+PKT_TM_CNT );
-ptr16 = (u16*)j;
-i = ((u32)ptr16  6)  0xff;
-   ptr16  += j - 1;
-   i |=(((u32)ptr16  2)  0xff00);
+
+i = (j  6)  0xFF;
+j += 2 * (j - 1);
+i |= ((j  2)  0xFF00);
 writew(i, iadev-reass_reg+TMOUT_RANGE);
+
 /* initiate the desc_tble */
 for(i=0; iiadev-num_tx_desc;i++)
 iadev-desc_tbl[i].timestamp = 0;
@@ -1911,7 +1908,7 @@
iadev-tx_dle_q.start = (struct dle*)dle_addr;  
iadev-tx_dle_q.read = iadev-tx_dle_q.start;  
iadev-tx_dle_q.write = iadev-tx_dle_q.start;  
-   iadev-tx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct 
dle)*DLE_ENTRIES);  
+   iadev-tx_dle_q.end = (struct dle*)((unsigned 
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);  
 
/* write the upper 20 bits of the start address to tx list address 
register */  
writel(iadev-tx_dle_dma  0xf000,
@@ -2913,7 +2910,7 @@
  dev_kfree_skb_any(skb);
   return 0;
 }
-if ((u32)skb-data  3) {
+if ((unsigned long)skb-data  3) {
printk(Misaligned SKB\n);
if (vcc-pop)
  vcc-pop(vcc, skb);

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Introduce BROKEN_ON_64BIT facility

[Alan Cox]

 (whitespace damaged; more for comment than for application).
 
  -if ((u32)skb-data  3) {
  +if ((unsigned long)skb-data  3) {
 
 I suppose it quietens a compiler warning.  Doesn't actually fix a bug
 though.

Right but it does no harm casting it to either so its worth cleaning up.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

[Alan Cox]

Ar Llu, 2006-09-18 am 16:29 +0200, ysgrifennodd Andi Kleen:
 The only delay this would add would be the queueing time from the NIC
 to the softirq. Do you really think that is that bad?

If you are trying to do things like network record/playback then you
want the minimal delay. There's a reason the original timestamp code
supported the hardware setting the timestamp itself - we actually had a
separare set of logic on a board that was doing the timestamping by
watching the IRQ line of the NIC chip.

Alan

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TG3 data corruption (TSO ?)

[Alan Cox]

Ar Sul, 2006-09-10 am 08:36 +1000, ysgrifennodd Benjamin Herrenschmidt:
 Well, some of you (Alan, you, etc...) seem to imply that it's always
 been the rule to have a memory store followed by an MMIO write be
 strongly ordered.

It has always been the rule

 However, if you look at drivers like e1000, USB OHCI, or even sungem
 (:-) they, all have at least wmb()'s between updating descriptor in

Driver hacks to cope with platform authors who got read/writel wrong.

 semantics. At least what is implemented currently on PowerPC is the
 __raw_* versions which not only have no barriers at all (they don't even
 order between MMIOs, for example, readl might cross writel), and do no
 endian swap. Quite a mess of semantics if you ask me... Then there has

__writel/__readl seems more in keeping for just not locking.


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64

[Alan Cox]

Ar Sad, 2006-09-02 am 22:14 +0200, ysgrifennodd Krzysztof Halasa:
 ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15
 
 There is no secondary IDE connector on this motherboard, I think
 it's just disabled by BIOS.

Its there if it got that far. May not be wired.

 scsi3 : pata_amd
 ata4: port is slow to respond, please be patient
 ata4: port failed to respond (30 secs)

Please send me an lspci -vxxx. This might be BIOS or might be us
misparsing disable/enable bits.



-- 
VGER BF report: U 0.5
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 08/10] [TULIP] Handle pci_enable_device() errors in resume

[Alan Cox]

Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
   pci_set_power_state(pdev, PCI_D0);
   pci_restore_state(pdev);
  
 - pci_enable_device(pdev);
 + if ((retval = pci_enable_device(pdev))) {
 + printk (KERN_ERR tulip: pci_enable_device failed in resume\n);
 + return retval;
 + }
Should you not stick it back in D3 if you are being neat about this ?

 
   if ((retval = request_irq(dev-irq, tulip_interrupt, IRQF_SHARED, 
 dev-name, dev))) {
   printk (KERN_ERR tulip: request_irq failed in resume\n);
 --- linux-2.6.18-rc4-mm1.orig/drivers/net/tulip/winbond-840.c
 +++ linux-2.6.18-rc4-mm1/drivers/net/tulip/winbond-840.c
 @@ -1626,14 +1626,18 @@ static int w840_resume (struct pci_dev *
  {
   struct net_device *dev = pci_get_drvdata (pdev);
   struct netdev_private *np = netdev_priv(dev);
 + int retval;
  
   rtnl_lock();
   if (netif_device_present(dev))
   goto out; /* device not suspended */
   if (netif_running(dev)) {
 - pci_enable_device(pdev);
 - /*  pci_power_on(pdev); */
 -
 + if ((retval = pci_enable_device(pdev))) {
 + printk (KERN_ERR
 + %s: pci_enable_device failed in resume\n,
 + dev-name);
 + return retval;

NAK: What about rtnl_lock()

 + }
   spin_lock_irq(np-lock);
   iowrite32(1, np-base_addr+PCIBusCfg);
   ioread32(np-base_addr+PCIBusCfg);
 --- linux-2.6.18-rc4-mm1.orig/drivers/net/tulip/de2104x.c
 +++ linux-2.6.18-rc4-mm1/drivers/net/tulip/de2104x.c
 @@ -2138,17 +2138,21 @@ static int de_resume (struct pci_dev *pd
  {
   struct net_device *dev = pci_get_drvdata (pdev);
   struct de_private *de = dev-priv;
 + int retval;
  
   rtnl_lock();
   if (netif_device_present(dev))
   goto out;
 - if (netif_running(dev)) {
 - pci_enable_device(pdev);
 - de_init_hw(de);
 - netif_device_attach(dev);
 - } else {
 - netif_device_attach(dev);
 + if (!netif_running(dev))
 + goto out_attach;
 + if ((retval = pci_enable_device(pdev))) {
 + printk (KERN_ERR %s: pci_enable_device failed in resume\n,
 + dev-name);
 + return retval;

NAK again - rtnl_lock


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 05/10] [TULIP] Defer tulip_select_media() to process context

[Alan Cox]

Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
 +static inline void tulip_tx_timeout_complete(struct tulip_private *tp, void 
 __iomem *ioaddr)
 +{
 + /* Stop and restart the chip's Tx processes. */
 + tulip_restart_rxtx(tp);
 + /* Trigger an immediate transmit demand. */
 + iowrite32(0, ioaddr + CSR1);

In mmio mode it will only be immediate if the caller is guaranteed to
read from the device and flush the iowrite 


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html