> +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
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, signe
> (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
> 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
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 s
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 al
> 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
sec
> > 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
> 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'
> "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
>
> 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.
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
> >
> 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 wil
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 bog
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 d
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 autoloadin
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.
>
> Sin
his 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. A
> 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 therm
> > 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
> > allocate
> 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_di
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)
> > >
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 long
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.
>
>
> 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 day
> >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 enabl
> 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 i
> 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 harde
> 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
> 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 ri
> 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
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:
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 thi
> 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 tha
> 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
>
> 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
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 kee
> 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 net
> 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
> 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 a
> 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
> 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 t
> 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.
> > 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 lon
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
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
> 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
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
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 sav
> 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 p
> 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 sho
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.
> >
> > memse
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
> > 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 G
> 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
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
> &
> - 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 per
> 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 qu
o 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 pro
> 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
> > 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
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
&
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:Mai
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/MAINT
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 <[E
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 SUPP
gt; 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 &
> 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
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 fo
> > 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
> >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
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 */
> >
> 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
ex
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 PROT
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
> > 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 i
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
> 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 ma
> (*) 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.or
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/m
> > 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
> 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 disagreemen
> 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. RD
> 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 li
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 -> SO
> > 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
> 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
> +/**
> + * 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
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 "unsubs
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 br
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_
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 i
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 severa
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 p
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
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 t
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
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
> (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
owever
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
linu
1 - 100 of 142 matches
Mail list logo
