Re: [PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti

On Fri, Jan 26, 2018 at 11:55 PM, Dan Williams wrote: > > Here's another spin of the spectre-v1 mitigations for 4.16. I see nothing really objectionable here. And unlike Spectre-v2 and Meltdown, I expect Spectre-v1 to be with us for a long time. It's not a "CPU did a

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

On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote: > > Here there isn't any reason for speculation. The core has the > value of 'x' in a register and the upper bound encoded into the > "cmp" instruction. Both are right there, no waiting, no speculation. So this is an

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

On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote: > > This series incorporates Mark Rutland's latest ARM changes and adds > the x86 specific implementation of 'ifence_array_ptr'. That ifence > based approach is provided as an opt-in fallback, but the default >

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu wrote: > > Yes it's accessing the list. Here is the faddr2line output. Ok, so it's a corrupted timer list. Which is not a big surprise. It's next->pprev = pprev; in __hlist_del(), and the trapping instruction

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote: > > Here are 3 dmesgs related to wireless and 1 from ethernet. Fengguang, these would be lovelier still _if_ you have DEBUG_INFO enabled on the kernel, and your script were to find things like "symbol+0xhex/0xhex", and

Re: iwlwifi firmware load broken in current -git

On Fri, Sep 15, 2017 at 12:43 PM, Luca Coelho <l...@coelho.fi> wrote: > On Fri, 2017-09-15 at 12:38 -0700, Linus Torvalds wrote: >> >> From some of the context it looks like commit 40f11adc7cd9 ("PCI: >> Avoid race while enabling upstream bridges"), is

Re: iwlwifi firmware load broken in current -git

On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe wrote: >> >> In any case, your patch introduces a regression on systems. Please get >> it reverted now, and then you can come up with a new approach to fix the >> double enable of the upstream bridge. > > Who's sending in the revert? I

Re: [PATCH] iwlwifi: mvm: only send LEDS_CMD when the FW supports it

On Thu, Sep 7, 2017 at 5:39 AM, Kalle Valo wrote: > > Linus, do you want to apply this directly or should we take it via the > normal route (wireless-drivers -> net)? If your prefer the latter when > I'm planning to submit this to Dave in a day or two and expecting it to >

Re: [GIT] Networking

On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho wrote: > > This patch is not very important (unless you really like blinking lights > -- maybe I'll change my mind when the holidays approach :P). so it is > fine if you just want to revert it for now. > > In any case, I'll send a patch

Re: [GIT] Networking

On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano wrote: > > This seems to be a problem with backwards-compatibility with FW version > 27. We are now in version 31[1] and upgrading will probably fix that. I can confirm that fw version 31 works. > But obviously the

Re: [GIT] Networking

On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > The firmware is iwlwifi-8000C-28.ucode from > iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports > > iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iw

Re: [GIT] Networking

This pull request completely breaks Intel wireless for me. This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). That remains a very standard Intel machine with absolutely zero odd things going on. The firmware is iwlwifi-8000C-28.ucode from

Re: [PATCH V2] brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

On Fri, Jul 7, 2017 at 1:09 PM, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > Now I signed off on the patch although formally I suppose Linus should > sign it off. You can certainly consider it Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> but I

Re: [PATCH] brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

On Fri, Jul 7, 2017 at 6:17 AM, Johannes Berg wrote: > > Linus, since you were involved already, will you apply this directly? I don't think it's _that_ urgent, since it's specific to one particular driver anyway. I'd suggest just going through the normal channels, and

Re: [PATCH] brcmfmac: buffer overflow in brcmf_cfg80211_mgmt_tx()

On Thu, Jul 6, 2017 at 10:11 AM, Arend van Spriel wrote: > > Looks fine to me so ... I really think that if we can't trust 'len', then we have to check against the lower bound of DOT11_MGMT_HDR_LEN too, because otherwise we'll just have a big 16-bit number instead.

Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default

On Thu, May 4, 2017 at 8:22 AM, David Miller wrote: > From: Johannes Berg >> >> I figured I'd give Linus to a chance to try or even apply it, but I >> have no objection to you applying it either. I don't have anything else >> yet right now, and

new warning at net/wireless/util.c:1236

So my Dell XPS 13 seems to have grown a new warning as of the networking merge yesterday. Things still work, but when it starts warning, it generates a *lot* of noise (I got 36 of these within about ten minutes). I have no idea what triggered it, because when I rebooted (not because of this

Re: ath10k regression on XPS13

On Tue, Feb 21, 2017 at 10:18 AM, David Miller wrote: > > Kalle I really wanted to send my net-next pull request to Linus later > today. But I guess I have to wait for this ath10k first. Feel free to send it to me - it sounds like the regression is (a) easy to work around

Re: [RFC (v7)] add basic register-field manipulation macros

On Thu, Aug 18, 2016 at 10:11 AM, Jakub Kicinski wrote: > Hi! > > This is what I came up with. Changes: I can live with this, certainly. I'm not really sure how many drivers (or perhaps core code, for that matter) will actually start using it, but it at least

Re: [PATCHv6 1/2] add basic register-field manipulation macros

On Wed, Aug 17, 2016 at 10:11 AM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Wed, 17 Aug 2016 09:33:26 -0700, Linus Torvalds wrote: >> >> I'm not a huge fan, since the interface fundamentally seems to be >> oddly designed (why pass in the mask rather

Re: [PATCHv6 1/2] add basic register-field manipulation macros

On Wed, Aug 17, 2016 at 3:31 AM, Kalle Valo wrote: > > Are people ok with this? I think they are useful and I can take these > through my tree, but I would prefer to get an ack from other maintainers > first. Dave? Andrew? I'm not a huge fan, since the interface

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote: > > This patch changes all users of IS_ERR_VALUE() that I could find > on 32-bit ARM randconfig builds and x86 allmodconfig. For the > moment, this doesn't change the definition of IS_ERR_VALUE() > because there are probably

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:46 PM, Andrew Morton wrote: > > So you do plan to add some sort of typechecking into IS_ERR_VALUE()? The easiest way to do it is to just turn the (x) into (unsigned long)(void *)(x), which then complains about casting an integer to a pointer

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote: > > It would be best if you could send a patch either directly to Dave or > Linus to resolve this quickly. I'm committing my patch myself right now, since this bug makes my laptop useless, and I will take credit for

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > From what I can tell, there's a merge bug in commit 909b27f70643, > where David seems to have lost some of the changes to > iwl_mvm_set_tx_cmd(). > > I do not know if that's the reas

Re: [GIT] Networking

On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano wrote: > > I can confirm that 4.6 contains the same bug. And reverting the patch > I mentioned does solve the problem... > > The same patch works fine in our internal tree. I'll have to figure > out together with

Re: [GIT] Networking

On Tue, May 17, 2016 at 12:11 PM, David Miller wrote: > > Highlights: Lowlights: 1) the iwlwifi driver seems to be broken My laptop that uses the intel 7680 iwlwifi module no longer connects to the network. It fails with a "Microcode SW error detected." and spews out

iwlwifi incomplete initialization in Linux 4.5?

So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made the wireless no longer work with a 4.5 kernel. I could get the occasional packets through, but not many, and ti would hang for ten seconds at a time, and then output errors like iwlwifi :01:00.0: Queue 2 stuck for 1

Re: iwlwifi incomplete initialization in Linux 4.5?

On Wed, Mar 16, 2016 at 2:13 PM, Grumbach, Emmanuel wrote: > > This ... typically means that the firmware got stuck while sending > packets. Can you tell me on what band your router operates? 2.4GHz or > 5.2GHz? Both. > Do you use 20Mhz or 40MHz? HT20 on 2.4GHz,

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote: > > The test patch that Johannes sent earlier was close. The section needed to > add VHT rates is: Hmm. This looks pretty much exactly like what I already tried (I had fixed Johannes' patch to use "vht_cap" already,

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, Jan 28, 2016 at 4:13 AM, Johannes Berg <johan...@sipsolutions.net> wrote: > On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote: > >> .. except now I upgraded the nearest access point, and now wireless >> on that machine no longer works. > > Can you d

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg wrote: > > Your best workaround may just be to ignore VHT for now - clearly it's > broken so using "just" HT (which is likely not that much of a penalty > anyway since you're apparently not using 80 MHz) will be much

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, Jan 28, 2016 at 1:44 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I will try Johannes' suggestion on that machine to see if it makes a > difference Well, it "makes a difference" in the sense that the warning goes away. But it doesn't make thing

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

that this is not a new issue. Or at least I seem to find reports that look very much like this from over a year ago. Linus On Thu, Jan 28, 2016 at 12:40 PM, Johannes Berg <johan...@sipsolutions.net> wrote: > On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote: >> &g

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, Jan 28, 2016 at 5:54 PM, Larry Finger wrote: > > I have been running an RTL8821AE since kernel 3.18 without hitting this > problem using a TRENDnet AC1750 dual-band AP. The UniFi may be doing > something that the driver is not expecting. I've had issues with

WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

Hmm. So my daughter has a little Gigabyte Brix that has rtl8821ae wireless in it. Yeah, nasty, I know, but it has actually worked reasonably well. .. except now I upgraded the nearest access point, and now wireless on that machine no longer works. Or rather, it actually *does* work in the sense

Re: [PATCH] mac80211: Send EAPOL frames at lowest rate

Johannes, On Thu, Feb 26, 2015 at 5:50 AM, Jouni Malinen jo...@qca.qualcomm.com wrote: Reported-by: Linus Torvalds torva...@linux-foundation.org Also Tested-by:, and I'd suggest marking it for stable too (although I understand that David generally doesn't use stable tags, and just sends them

Re: [ath9k-devel] AR9462 problems connecting again..

On Wed, Feb 25, 2015 at 6:47 AM, Jouni Malinen j...@w1.fi wrote: There may be something else wrong (say, some kind of interference), but there is no way we can assume normal users to be able to fix such issues. If we make EAPOL frames go through more robustly, the connection can be

Re: [ath9k-devel] AR9462 problems connecting again..

On Wed, Feb 25, 2015 at 10:14 AM, Linus Torvalds torva...@linux-foundation.org wrote: I'm talking about the two from Jouni - the don't encrypt EAPOL frames one, and the one-liner that makes all EAPOL frames go at the lowest data rate. So I just found out and confirmed that this is not Atheros

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote: mac80211: Do not encrypt EAPOL frames before peer has used the key Hmm. This patch does not seem to make a difference. I thought it did at first, but then removed the wpa_supplicant debugging, and got the same failures. On Sun,

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds torva...@linux-foundation.org wrote: This machine has a fairly minimal kernel config. Does that type monitor interface perhaps need some debug infrastructure that I haven't added? Nope. Same behavior with a F21 kernel (which means

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote: How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? Well, it was pretty much within five meters already, but there was a thin wall in between

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote: This did not get exactly supportive response when this was proposed last time (Sep 2013). Anyway, for a quick test, this can be done with the following one-liner: fwiw, that one-liner seems to work fine for me. Which I guess is

Re: AR9462 problems connecting again..

On Sat, Feb 21, 2015 at 10:50 PM, Sujith Manoharan suj...@msujith.org wrote: Can you please post the output of 'iw dev wlp1s0 scan' ? Attached. It's the UniFi-home SSID that doesn't work. The 1gnoraNT one is the old working one that I'm obviously associated with, and that has multiple AP's.

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd adr...@freebsd.org wrote: Just a wild shot - try disabling fast authentication and see if that makes a difference? wpa_supplicant.conf: fast_reauth=0 I recall having issues with fast_reauth once, but I never stuck around that location long

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 11:39 AM, Adrian Chadd adr...@freebsd.org wrote: Hm, can you enable wpa debugging to log everything whilst it's associating / reassociating? Ugh. When I add -dd to the command line, it has now worked three times in a row, when before it worked once out of ten tries. So

Re: [ath9k-devel] AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 10:58 AM, Dave Taht dave.t...@gmail.com wrote: Hint: Several unifi (and most ubnt) products are well supported by openwrt directly, I want Linux to just work. None of this oh, you can change something else and it probably works. I want to fix the problem in *linux*.

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds torva...@linux-foundation.org wrote: Ugh. When I add -dd to the command line, it has now worked three times in a row, when before it worked once out of ten tries. So my guess is that it's something timing-dependent. So it stays working with -dd

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 5:55 PM, Adrian Chadd adr...@freebsd.org wrote: Do you have a 5GHz SSID setup on this access point? Is this kind of messed up diassociation-to-steer-you-to-another-band thing? Nope. That's the older single-band UniFi UAP - 2.4GHz only. Linus --

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 4:54 PM, Adrian Chadd adr...@freebsd.org wrote: I /think/ it's okay? The removed stuff is the pre-shared key pieces. Ok. Attached is what seems to be the relevant part of the wpa_supplicant.log file. The datestamp has been changed so that it can be matched up with the

Re: Wireless scanning while turning off the radio problem..

On Mon, Jan 19, 2015 at 5:48 AM, Arend van Spriel ar...@broadcom.com wrote: So as you indicated you were in location where none of your configured networks were available. Flipping the rfkill switch in that situation is the way to trigger the issue. So you certainly seem to be able to explain

Re: Wireless scanning while turning off the radio problem..

On Sun, Jan 18, 2015 at 11:24 PM, Emmanuel Grumbach egrumb...@gmail.com wrote: we have different scan flows based on the firmware version you have, so it would help if you could tell me what firmware you have. Sure. It's the larest one I could find iwlwifi :01:00.0: loaded firmware

Wireless scanning while turning off the radio problem..

So there seems to be some issue with unlucky timing when turning off wireless while the driver is busy scanning. I can't reproduce this, so it's a one-off, but it's not just ugly warnings, the kernel woudln't scan any wireless on that device afterwards and I had to reboot to get networking back,

Re: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

On Thu, Jan 1, 2015 at 11:44 AM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: ifconfig seems to just be broken for many cases of perfectly nice features in the kernel. So I'm not saying ifconfig is wonderful. It's not. But I *am* saying that changing user interfaces and then expecting

Re: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o ty...@mit.edu wrote: Most poeple are still using route and ifconfig instead of ip. Deal with it. Indeed. This whole let's throw out the old and broken stuff is a disease. It would have been much better (and it's still an option, as Ted points

Re: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o ty...@mit.edu wrote: Yeah, the confusing part is that ip tends to use verb object scheme, which is consistent with the Cisco IOS command set it was trying to emulate. Side note: does anybody think that was really a good idea to begin with? I