Re: [PATCH V4 5/6] net: maclorawan: Implement maclorawan class module
> +void > +lrw_parse_frame(struct lrw_session *ss, struct sk_buff *skb) > +{ > + struct lrw_fhdr *fhdr = &ss->rx_fhdr; > + __le16 *p_fcnt; > + > + pr_debug("%s: %s\n", LORAWAN_MODULE_NAME, __func__); > + > + /* Get message type */ > + fhdr->mtype = skb->data[0]; > + skb_pull(skb, LRW_MHDR_LEN); This does not seem robust. There is no point at which you actually check the message size is valid etc > + fhdr->fopts_len = fhdr->fctrl & 0xF; > + if (fhdr->fopts_len > 0) { > + memcpy(fhdr->fopts, skb->data, fhdr->fopts_len); > + skb_pull(skb, fhdr->fopts_len); > + } In fact you appear to copy random kernel memory into a buffer > + > + /* TODO: Parse frame options */ > + > + /* Remove message integrity code */ > + skb_trim(skb, skb->len - LRW_MIC_LEN); and then try and trim the buffer to a negative size ? Alan
Re: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit
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
> (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
> 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
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
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
> 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
> > 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
> 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
> "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
> 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
On Sat, 6 Jan 2018 10:13:33 -0800 Alexei Starovoitov 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 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. > > +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
> 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
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
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()
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, &n_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
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
On Tue, 16 May 2017 17:05:32 +0200 Andrey Konovalov 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 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 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
> 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
> > 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
> 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, &digi, > 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
On Fri, 2016-02-26 at 12:33 -0500, Willem de Bruijn wrote: > On Fri, Feb 26, 2016 at 9:44 AM, Alan Cox > wrote: > > 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. > > 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
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
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] > *addr > drivers/net/ni52.c:219:15:got unsigned char * > > 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
> 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: [PATCH] Add IPv6 support to TCP SYN cookies
> >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
> 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
> 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
> 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
> 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: AF_UNIX MSG_PEEK bug?
> 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
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: [PATCH] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007 17:17:19 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > a) this could be disabled during development if you want this > b) this would even only affect development if you add new code that > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > right now this would also need to trigger a rerun of depmod. And the > same trigger could redo this garbage collect. > > Or am I missing something obvious? Development is not a phase seperate from use or distribution. A lot of module testers for distributions will not be compiling their own modules but loading in ones to test provided by their vendor - which may of course then need different ksyms 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] Force UNIX domain sockets to be built in
> I'd say the practical advantage to the user would be almost zero. > Which distribution is going to enable this option and defacto > banning external modules? It would be a real nuisance for developing code let alone for using it. The entries are currently far bigger than is needed and fixing that would be much more productive. 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: Top 10 kernel oopses/warnings for the week of December 21st 2007
> 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"
> 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"
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"
> 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: namespace support requires network modules to say "GPL"
> 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: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space
> 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
> 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: [BUG] New Kernel Bugs
> 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
> 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
> > 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: [2.6 patch] remove Documentation/networking/pt.txt
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
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.
> 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
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
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
> 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: [PATCH 1/2] bnx2: factor out gzip unpacker
> 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: follow-up: discrepancy with POSIX
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 null address for the protocol. > > 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: follow-up: discrepancy with POSIX
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: Fwd: That whole "Linux stealing our code" thing
> > 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: Fwd: That whole "Linux stealing our code" thing
> 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
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
> - 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: That whole "Linux stealing our code" thing
> 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
> It is illegal to modify a license unless you are the owner/author, > because it is a legal document. If there are multiple owners/authors, Oh dear - Theo, go talk to a lawyer, or do a course on licencing. The owner generally starts with the rights to control who performs acts covered by copyright law. They pass some of those rights on to others by contract, licence or statutory means. It is quite normal for the owner to pass on the right to relicence or modify the licencing of a work. In many cases the owner actually hands on all such rights to a third party (eg an evil music company). [Owner and author often differ as many legal systems start from the basis that an employee produces a work for the employer rather than it being transferred solely by contract] The ath5k C file in question (not the headers) seems to give recipients permission to further convey the work under a choice of two licences. It doesn't say they must redistribute under both. So I appear to have a right to convey the work under the GPL to a third party, who from me receives no right to use it except under the GPL. The Ath5K C code is very clear about the intention of the licencing: * 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. The choice appears to be delegated to the recipient very clearly and very specifically by the licencing on the file. It does not say that I must convey the work under both licences. It quite specifically says I may convey the work under whichever of the two I prefer (and probably both if I wish). Clearly if that had not been the intent it would not have included the clause giving the choice. This is quite different to the case Theo tries to discuss. > In http://lkml.org/lkml/2007/8/29/183, Alan Cox managed to summarize > what Jiri Slaby and Luis Rodriguez were trying to do by proposing a > modification of a Dual Licenced file without the consent of all the > authors. Alan asks "So whats the problem ?". Well, Alan, I must > caution you -- your post is advising people to break the law. Re-read my email and then apologize. I do question the .h files where they are BSD licence and no changes were made to the work. I also point out that the dual licence on that code appears to give permission to distribute under one of those licences by choice. > - If you receive dual licensed code, you may not delete the license > you don't like and then distribute it. It has to stay, because you > may not edit someone's else's license -- which is a three-part legal > document (For instance: Copyright notice, BSD, followed by GPL). If you got BSD licenced code that doesn't give you a choice of licence then of course the original work remains BSD and you can't go around removing that information, the copyright holder's name and other things protected variously by different legal systems. I would submit the ath5k header files fit this (if they are even copyrightable works at all) > - If you wish for everyone to remain friends, you should give code back. That's about the first thing I would agree on - its somewhat rude and not something I personally woul usually choose todo. However to many there are problems as the BSD licence doesn't mean giving it back to the community it means giving a copy to everyone who wants rip it off for private proprietary use. > "Thanks for what you wrote, but this is a one-way street, you give > us code, and we take it, we give you you nothing back. screw off." The BSD licence allows this. If you in the BSD world don't want that to happen you need to look hard at your licencing. Linux takes very little from the BSD world this way, the big one way takers are all proprietary software companies. Perhaps Theo should write to that nice Bill guy instead. > GPL fans said the great problem we would face is that companies would > take our BSD code, modify it, and not give back. Nope -- the great > problem we face is that people would wrap the GPL around our code, and You just don't realise who takes your code and what they do with it. The proprietary people don't tell you, but the free ones you can see. > If the Linux developers wrap GPL's around things we worked very hard > on, it will definately not be viewed as community development. So you'd prefer that the Linux developers worked on it and then Microsoft took the results of all our work and didn't give anything back. At least if the Linux work is GPL licenced its protected from further abuse. See the viewpoint the free software people come from - you may not agree with it but it has a logic. If OpenBSD wants a world where code must be returned, but you can mix it with free code in a product in some fashion and do binary only rele
Re: [PATCH 4/5] Net: ath5k, license is GPLv2
> 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 4/5] Net: ath5k, license is GPLv2
> > 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] [70/2many] MAINTAINERS - ARPD SUPPORT
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
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] [70/2many] MAINTAINERS - ARPD SUPPORT
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: drivers/net/tokenring/3c359.c
On Mon, 13 Aug 2007 15:43:30 +0530 Surya Prabhakar N <[EMAIL PROTECTED]> wrote: > Hi, >Replacing kmalloc with kzalloc and cleaning up memset in > drivers/net/tokenring/3c359.c > > > Signed-off-by: Surya Prabhakar <[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] [70/2many] MAINTAINERS - ARPD SUPPORT
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 1/7] sysctl: Remove broken cdrom binary sysctls
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
> 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
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
> > 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
> >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
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: [PATCH] fix race in AF_UNIX
> 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: select(0, ..) is valid ?
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
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: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
> > 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 #3]
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: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
> 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]
> (*) 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 #2]
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 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
> > 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]
> 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]
> 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]
> 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 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
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 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2]
> > 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]
> 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 3/5] AF_RXRPC: Make it possible to merely try to cancel timers and delayed work [try #2]
> +/** > + * 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 3/9] iPhase: 64bit cleanup
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
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: [PATCH 1/2] [PCI] Check that MWI bit really did get set
Ar Sul, 2006-10-15 am 17:16 -0700, ysgrifennodd David Brownell: > Signed-off-by: David Brownell <[EMAIL PROTECTED]> Acked-by: Alan Cox <[EMAIL PROTECTED]> > > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -499,7 +499,7 @@ int __must_check pci_enable_device_bars( > void pci_disable_device(struct pci_dev *dev); > void pci_set_master(struct pci_dev *dev); > #define HAVE_PCI_SET_MWI > -int __must_check pci_set_mwi(struct pci_dev *dev); > +int pci_set_mwi(struct pci_dev *dev); > void pci_clear_mwi(struct pci_dev *dev); > void pci_intx(struct pci_dev *dev, int enable); > int pci_set_dma_mask(struct pci_dev *dev, u64 mask); - 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
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
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: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh
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: [Bulk] Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set
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: [Bulk] Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set
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: Hardware bug or kernel bug?
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
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
> (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: [PATCH] Introduce BROKEN_ON_64BIT facility
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; inum_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