Just decided to take another look:
On Mon, 2017-10-09 at 13:58 +0200, Johannes Berg wrote:
> On Mon, 2017-10-09 at 13:56 +0200, Jason A. Donenfeld wrote:
>
> > @@ -2266,16 +2266,17 @@ int __netlink_dump_start(struct sock *ssk,
> > struct sk_buff *skb,
> > cb-&
On Mon, 2017-10-09 at 13:56 +0200, Jason A. Donenfeld wrote:
> @@ -2266,16 +2266,17 @@ int __netlink_dump_start(struct sock *ssk,
> struct sk_buff *skb,
> cb->min_dump_alloc = control->min_dump_alloc;
> cb->skb = skb;
>
> + if (cb->start) {
> + ret = cb->start(cb);
>
On Sun, 2017-10-08 at 01:43 -0400, Xiang Gao wrote:
>
> By the way, I'm still struggling on how to run unit tests. It might
> take time for me to make it run on my machine.
I can run it easily, so don't worry about it too much. Running it is of
course much appreciated, but I don't really want to
On Thu, 2017-10-05 at 10:39 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list
> pointer to
> all timer callbacks, switch to using the new timer_setup() and
> from_timer()
> to pass the timer pointer explicitly. This requires adding a pointer
> back
> to the
On Thu, 2017-10-05 at 12:00 +0100, David Howells wrote:
>
> Only validly signed wifi databases may be use.
We don't even have this yet, and when we do, we want this to be the
case for typical configurations regardless of lockdown.
johannes
On Wed, 2017-10-04 at 17:49 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly. This requires
> adding a pointer back to the sta_in
Please don't send obviously broken patches.
johannes
Please use "v2" tag or so in the subject line, having the same patch
again is really not helpful.
The next should be v3, obviously.
> +++ b/net/mac80211/aead_api.c
> @@ -1,7 +1,4 @@
> -/*
> - * Copyright 2014-2015, Qualcomm Atheros, Inc.
> - *
> - * This program is free software; you can redistri
ce start() has always been a function with an int return type, it
> therefore makes sense to use it properly, rather than ignoring it.
> This
> patch thus returns early and does not call dumpit() when start()
> fails.
>
> Signed-off-by: Jason A. Donenfeld
Reviewed-by: Johannes
On Wed, 2017-09-27 at 14:50 +0200, Jason A. Donenfeld wrote:
> On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld
> wrote:
> > - if (cb->start)
> > - cb->start(cb);
> > + if (cb->start) {
> > + ret = cb->start(cb);
> > + if (ret)
>
> I need t
Subject should say *not* initialized?
johannes
On Mon, 2017-09-25 at 12:56 +0800, Herbert Xu wrote:
> On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote:
> >
> > Unrelated to this, I'm not sure whose tree this should go through -
> > probably Herbert's (or DaveM's with his ACK? not sure
On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote:
>
> Do you mean to put more characters each line in the description
>
Huh, sorry, no - my bad. I was thinking of the code, not the
description at all.
For example here:
> -int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad
On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line
> copy of each other. This patch reduce code redundancy by moving
> the code in these two files to crypto/aead_api.c to make it a
> higher level aead api. The aes_ccm.c and aes_gcm.c
On Sat, 2017-09-23 at 21:37 +0200, Christian Lamparter wrote:
> But this also begs the question: Is this really working then?
> From what I can tell, if CONFIG_LOCKDEP is not set then there's no
> BUG no WARN, no other splat or any other odd system behaviour. Does
> [cancel | flush]_[delayed_]work
On Thu, 2017-09-21 at 23:56 +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate const array ac_to_fifo on the stack in an inlined
> function, instead make it static. Makes the object code smaller
> by over 800 bytes:
>
> text data bss dec hex
> filename
>
On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
> It seems this is caused as a result of:
> -> lock_map_acquire(&work->lockdep_map);
> lock_map_release(&work->lockdep_map);
>
> in flush_work() [0]
Agree.
> This was added by:
>
> commit 0976dfc1d0cd80a4e9df
On Wed, 2017-09-13 at 00:21 +0200, Vladis Dronov wrote:
> nl80211_set_rekey_data() does not check if the required attributes
> NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
> NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
> users with CAP_NET_ADMIN privil
On Wed, 2017-09-06 at 17:04 +0200, Matteo Croce wrote:
>
> I confirm that this patch fixes the hang too.
Cool, I'll go apply it.
> I'm curious to see if there are noticeable performance differences
> between the two solutions.
Nope, you hit this code path essentially once.
johannes
On Wed, 2017-09-06 at 16:27 +0200, Stefano Brivio wrote:
>
> Sorry for the extended bothering :) but here, you're extending quite
> a bit the scope of the lock also
> when__ieee80211_start_rx_ba_session() is called by
> ieee80211_process_addba_request().
I know, but it doesn't matter.
> No idea
On Wed, 2017-09-06 at 15:27 +0200, Stefano Brivio wrote:
>
> Yes, that was based on the assumption that the initial part of
> __ieee80211_start_rx_ba_session() can't really affect the AMPDU
> state-machine in any way.
That's not really the point, if that changes that function would have
to move t
On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote:
> On Wed, 06 Sep 2017 14:48:35 +0200
> Johannes Berg wrote:
>
> > I'll look in a bit - but
> >
> > > + mutex_unlock(&sta->ampdu_mlme.mtx);
> > >
On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote:
>
> I'm surprised nobody saw this before - though perhaps Sebastian's
> useless report is the same.
Oh, that's because this is only for the offloaded manager thing, and
that's only ath10k.
johannes
On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote:
> I have an hung task on vanilla 4.13 kernel which I haven't on 4.12.
> The problem is present both on my AP and on my notebook,
> so it seems it affects AP and STA mode as well.
> The generated messages are:
>
> INFO: task kworker/u16:6:120
I'll look in a bit - but
> + mutex_unlock(&sta->ampdu_mlme.mtx);
> ___ieee80211_stop_rx_ba_session(
> sta, tid, WLAN_BACK_RECIPIENT,
> WLAN_REASON_QSTA_TIMEOUT, true);
This already has three unde
On Tue, 2017-09-05 at 10:49 +0200, Thomas Gleixner wrote:
>
> > Are you planning to integrate all patches in the series through
> > some other tree, perhaps to be able to get rid of the
> > tasklet_hrtimer API, or should I apply this?
>
> The patch depends on the hrtimer core changes, so we eithe
: Anna-Maria Gleixner
> Cc: Johannes Berg
> Cc: Kalle Valo
> Cc: linux-wirel...@vger.kernel.org
>
This looks fine to me,
Reviewed-by: Johannes Berg
Are you planning to integrate all patches in the series through some
other tree, perhaps to be able to get rid of the tasklet_hr
On Wed, 2017-06-28 at 21:10 +0200, Lubomir Rintel wrote:
>
> I do use it as a development tool. I find it very convenient to
> always have a bunch of libvirt-managed LXC containers, some running
> hostapd instances with various access point configurations and some
> used for NetworkManager develop
On Wed, 2017-06-28 at 06:37 -0700, Joe Perches wrote:
> On Wed, 2017-06-28 at 15:17 +0200, Lubomir Rintel wrote:
> > The mac80211_hwsim doesn't offer a way to disable the debugging
> > output.
> > Unfortunately, it's pretty chatty, dumping a lot of stuff into the
> > message
> > buffer.
> >
> > T
On Wed, 2017-06-28 at 15:17 +0200, Lubomir Rintel wrote:
> The mac80211_hwsim doesn't offer a way to disable the debugging
> output.
> Unfortunately, it's pretty chatty, dumping a lot of stuff into the
> message buffer.
Why is this a problem? It's pretty much a testing tool only, and much
of the
On Tue, 2017-06-27 at 13:48 -0700, Brian Norris wrote:
> > There isn't really a good way to do this. You can, of course, call
> > wiphy_unregister(), but if you could do that you'd already have the
> > problem solved, I think?
>
> That's probably along the right track. There are still some things
Hi Brian,
> Wow, that's not exactly simple code; I expect it could be pretty
> difficult to get that right today on mwifiex.
Yeah, I have no doubt. You'd probably have to track a lot of state that
you just pass down to the firmware too, and possibly can't even track
some state that the firmware
On Fri, 2017-06-23 at 14:02 +0200, Matthias Schiffer wrote:
>
> It seems though that rtnl_link_ops.newlink/changelink don't allow
> passing the extack yet... how do we proceed here? Treewide change
> (maybe by someone who knows their Coccinelle-fu?), or would the
> introduction of new versions of
On Fri, 2017-06-23 at 12:13 +0200, Matthias Schiffer wrote:
>
> I was told the extended netlink error facilities were not ready yet,
> has that changed since the last release?
Yes, the facility is in the kernel tree now.
> Anyways, I will gladly work on improving the error handling if
> someone
On Fri, 2017-06-23 at 09:48 +0200, Jiri Slaby wrote:
>
> mac80211_queue is 255 which is IEEE80211_INVAL_HW_QUEUE, so it should
> not be worked with at all.
Funny you should find this today :-)
> The invalid queue is hopefully handled in ieee80211_check_queues
> after
> drv_add_interface in ieee8
On Wed, 2017-06-21 at 11:27 -0700, Brian Norris wrote:
>
> > I'm not sure what you mean by "we need to atually stop all the
> > virtual interfaces ([...]) first".
>
> Judging by your following comments, I may have been completely
> mistaken.
> (But that's why I asked you folks!)
:)
> > There ar
On Wed, 2017-06-21 at 10:48 -0700, Brian Norris wrote:
>
> Yes, that all sounds nice. But for my sake, can you describe better
> what's actually going on there (e.g., can you point me at which code
> does this)?
It's much easier with mac80211, it has all the state. Basically the
reconfig is in i
:
>
> - mark titles;
> - comment contents index;
> - mark literal blocks;
> - adjust identation.
>
> Signed-off-by: Mauro Carvalho Chehab
Fine by me, I assume somebody else is going to merge this?
Acked-by: Johannes Berg
On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote:
> But we don't accept kernel patches for some mythical future option
> that might be happening some time in the future. Heck, I'm still not
> convinced that firmware signing isn't anything more than just some
> snakeoil in the first place!
I for
On Sat, 2017-06-10 at 04:59 +0200, Jason A. Donenfeld wrote:
> Otherwise, we enable all sorts of forgeries via timing attack.
I'm not really sure that this is actually true, since you don't get
much feedback on your frame that's dropped, especially if you're
attacking from remote. Basically, I don
On Mon, 2017-06-05 at 18:54 +0300, Kalle Valo wrote:
> > BTW, since you're taking an interest in this code now, can I
> > trouble you with a question? Looking at mwifiex_uninit_sw() (after
> > this patchset), you can see a loop like this:
> >
> > /* Stop data */
> > for (i = 0; i
On Fri, 2017-06-02 at 15:03 +0800, Lai Jiangshan wrote:
>
> the @w2 is not queued before flush_work(&w2), it is expected
> that @w2 is not associated with @wq, and the dependence
> mtx -> wq will not be recorded. And it is expected no warning.
Lockdep is symmetric. So then maybe it won't warn whe
Hi Tejun,
> On Sun, May 28, 2017 at 09:33:13PM +0200, Johannes Berg wrote:
> > I suspect this is a long-standing bug introduced by all the pool
> > rework
> > you did at some point, but I don't really know nor can I figure out
> > how
> > to fix it right no
On Wed, 2017-05-31 at 10:36 +0200, Johannes Berg wrote:
>
> This was "ifndef", so it does in fact run here, just like you
> suggested. It doesn't warn though.
Also, even if DEADLOCK *is* defined, lockdep doesn't report anything.
johannes
Hi,
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > DEFINE_MUTEX(mtx);
> > static struct workqueue_struct *wq;
> > static struct work_struct w1, w2;
> >
> > static void w1_wk(struct work_struct *w)
> > {
> > mutex_lock(&mtx);
> > msleep(100);
> >
Hi,
> The issue here is that line 56 implies that pointer tfm_michael
> might be NULL. If this is the case, there is a potential NULL
> pointer dereference at line 52 once pointer tfm_michael is
> indirectly dereferenced inside macro SHASH_DESC_ON_STACK().
>
> My question is if there is any chanc
On Sat, 2017-05-27 at 14:59 -0700, Bjorn Andersson wrote:
> ieee80211_tx_status() is only one of the possible ways a driver can
> report a handled packet, some drivers call this for every packet
> while
> others calls it rarely or never.
>
> In order to invoke the TX LED in the non-status reportin
Hi Tejun,
I suspect this is a long-standing bug introduced by all the pool rework
you did at some point, but I don't really know nor can I figure out how
to fix it right now. I guess it could possibly also be a lockdep issue,
or an issue in how it's used, but I definitely know that this used to
wo
On Mon, 2017-05-22 at 18:19 +0200, Johannes Berg wrote:
>
> I'm not really all that convinced that we really need this -
> userspace should just be using the flush thing more often, and then
> it doesn't really matter.
>
> However, maybe that doesn't really m
> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
> create its own list? Given that the kernel provides the information
> userspace needs to figure out the age of a particular BSS, it doesn't
> seem like there needs to be a kernel tunable for this. Userspace can
> already a
On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote:
> The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in
> the
> past. Initially was set at 10 seconds (2a51931192), then increased at
> 15
> seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover
> the
> u
On Fri, 2017-05-19 at 08:11 -0300, Mauro Carvalho Chehab wrote:
>
> Yes, it should work. Actually, you would need to use :depth: 2 to
> produce this output:
>
>
> Contents
>
> . rfkill - RF kill switch support
> . Introduction
> . Implementation detai
On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
>
> +.. CONTENTS
>
> + 1. Introduction
> + 2. Implementation details
> + 3. Kernel API
> + 4. Userspace support
Why not let this be auto-generated?
.. contents::
:depth: 1
should work, no?
johannes
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote:
>
> It seems very important to a lot of people...
I get blinking, I guess, but I don't get toggling for every packet :)
The throughput thing we did in iwlwifi seems like a so much better
idea. Not that it really matters for this discussion
On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote:
> On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> >
> > > > In fact, why should the *driver* care either? IOW - why should
> > > > &quo
On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
>
> > > This code intentionally checked if TX status was requested, and
> > > if not then it doesn't go to the effort of building it.
> > >
> >
> > What I'm finding puzzling is the fact that the only caller of
> > ieee80211_led_tx() is ieee802
On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
>
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package.
[...]
Oh,
On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > Now for N900 case there is a similar scenario
> > > alhtough it has additional requirement to go to user-space due to
> > > need to use a proprietary library to obtain the NVS calibration
> > > data. My thought: Why should firmware_c
On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote:
>
> In rt2x00 driver we use poor convention in other kind of registers
> accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
> accessors and leaving others in the old way. And changing all
> accessors would be massive and er
On Tue, 2017-05-09 at 15:50 +0200, Jason A. Donenfeld wrote:
> The recent bug with macsec and historical one with virtio have
> indicated that letting skb_to_sgvec trounce all over an sglist
> without checking the length is probably a bad idea. And it's not
> necessary either: an sglist already exp
On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 8 May 2017 22:22:04 +0200
>
> Five single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
Please stop, this isn't really an issue worth worryi
On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > o Use explicit casts to proper types instead of casts to (void *)
> > > and have the compiler do the implicit cast
> >
> > I see no advantage
> o Use explicit casts to proper types instead of casts to (void *)
> and have the compiler do the implicit cast
I see no advantage in this, why? All it does is make the code longer,
and if anything changes, you have to change it in multiple places now.
johannes
Hi,
> Things still work, but when it starts warning, it generates a *lot*
> of noise (I got 36 of these within about ten minutes).
Yeah, that's kinda dumb - I just sent a patch to make that just warn
once and actually report the configuration.
> I have no idea what triggered it, because when I r
On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote:
> > So either you could return some valid ops (perhaps
> > debugfs_noop_file_operations although those don't have .name or
> > .poll, so it doesn't cover everything), or you can just BUG_ON()
> > here directly, saving the incomprehensible cr
> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
> struct wcn36xx_dxe_ch *ch)
> info = IEEE80211_SKB_CB(ctl->skb);
> if (!(info->flags &
> IEEE80211_TX_CTL_REQ_TX_STATUS)) {
> /* Keep frame until TX status
This is not a cfg80211 patch, please resend with the correct subject.
Thanks,
johannes
On Wed, 2017-04-19 at 23:55 -0700, Stefan Agner wrote:
> Use type enum nl80211_rate_info for bitrate information. This fixes
> a warning when compiling with clang:
> warning: implicit conversion from enumeration type 'enum
> nl80211_rate_info'
> to different enumeration type 'enum nl80211_attrs
On Tue, 2017-04-18 at 08:17 -0700, Paul E. McKenney wrote:
> > Again, no (S)RCU abuse here, just an ABBA deadlock.
>
> OK, please accept my apologies for failing to follow the thread.
No worries - just wanted to clarify this in case I was missing
something.
> I nevertheless reiterate my advice
On Tue, 2017-04-18 at 06:31 -0700, Paul E. McKenney wrote:
> On Tue, Apr 18, 2017 at 11:39:27AM +0200, Johannes Berg wrote:
> > On Mon, 2017-04-17 at 09:01 -0700, Paul E. McKenney wrote:
> >
> > > If you have not already done so, please run this with debug
> &g
On Mon, 2017-04-17 at 09:01 -0700, Paul E. McKenney wrote:
> If you have not already done so, please run this with debug enabled,
> especially CONFIG_PROVE_LOCKING=y (which implies CONFIG_PROVE_RCU=y).
> This is important because there are configurations for which the
> deadlocks you saw with SRCU
On Sun, 2017-04-16 at 11:51 +0200, Nicolai Stange wrote:
>
> +++ b/fs/debugfs/file.c
> @@ -53,6 +53,7 @@ const struct file_operations
> *debugfs_real_fops(const struct file *filp)
> {
> struct debugfs_fsdata *fsd = F_DENTRY(filp)->d_fsdata;
>
> + WARN_ON((unsigned long)fsd &
> DEBUGFS
On Mon, 2017-04-17 at 15:59 -0700, Matthias Kaehlcke wrote:
> rate_flg is of type 'enum nl80211_attrs', however it is assigned with
> 'enum nl80211_rate_info' values. Change the type of rate_flg
> accordingly.
Applied this, and the other two patches you had (IBSS enum and array-
bounds)
johannes
On Tue, 2017-04-18 at 15:53 +1000, Stephen Rothwell wrote:
> Caused by commit
>
> 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Oh, another new driver :)
> interacting with commit
>
> 818a986e4eba ("cfg80211: move add/change interface monitor flags
> into params")
>
> from the
On Thu, 2017-04-06 at 16:31 -0700, Matthias Kaehlcke wrote:
> When clang detects a non-boolean constant in a logical operation it
> generates a 'constant-logical-operand' warning. In
> ieee80211_try_rate_control_ops_get() the result of strlen( str>)
> is used in a logical operation, clang resolves
On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote:
> Ping, any feedback on this patch?
You didn't cc linux-wireless, so it fell through the cracks ... I'll
try to remember it when I merge later.
johannes
On Thu, 2017-04-06 at 15:42 -0700, Matthias Kaehlcke wrote:
>
> Thanks, it would also require to move the initialization of
> ieee80211_default_rc_algo into an ifdef. If you can live with such a
> solution I'm happy to change it.
I think that'd be something I can live with, yeah.
> > git gre
On Thu, 2017-04-06 at 12:24 -0700, Matthias Kaehlcke wrote:
> I agree that the code looks worse :( I hoped to find a fix using a
> preprocessor condition but wasn't successful.
It's actually easy - just remove the 'default ""' from Kconfig, and
then the symbol won't be defined at all if it doesn'
On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> being
> used in a logical operation. Clangs' builtin strlen function resolves
> the
> expression to a constant at compile time, which causes clang to
> generate
> a 'cons
On Fri, 2017-03-31 at 11:03 +0200, Nicolai Stange wrote:
> > 2)
> > There's a complete deadlock situation if this happens:
> >
> > CPU1CPU2
> >
> > debugfs_file_read(file="foo") mutex_lock(&M);
> > srcu_read_lock(&debugfs_srcu);
On Thu, 2017-03-30 at 12:27 +0200, Nicolai Stange wrote:
> So, please correct me if I'm wrong, there are two problems with
> indefinitely blocking debugfs files' fops:
>
> 1. The one which actually hung your system:
> An indefinitely blocking debugfs_remove() while holding a lock.
> Other ta
On Thu, 2017-03-30 at 09:32 +0200, Nicolai Stange wrote:
>
> I wonder if holding the RTNL during the debugfs file removal is
> really needed. I'll try to have a look in the next couple of days.
Yes, I'm pretty much convinced that it is. I considered doing a
deferred debugfs_remove() by holding th
Hi,
> > Before I go hunting - has anyone seen a deadlock in
> > synchronize_srcu() in debugfs_remove() before?
>
> Not yet. How reproducible is this?
So ... this turned out to be a livelock of sorts.
We have a debugfs file (not upstream (yet?), it seems) that basically
blocks reading data.
At
> > > - const skb_frag_t *frag = &sh->frags[-1];
> > > + const skb_frag_t *frag = &sh->frags[0];
[...]
> > > + frag--;
> >
> > Isn't it just a question of time until the compiler will see
> > through this trick and warn about it?
>
> Frag is incremented again before being accessed, so there is n
On Fri, 2017-03-24 at 13:20 -0700, Paul E. McKenney wrote:
>
> And I cannot resist adding this one:
>
> CPU 1 CPU 2
> i = srcu_read_lock(&s1);mutex_lock(&l1);
> mutex_lock(&l1);synchronize_srcu(&s2);
> mutex_unlock(&l1);
On Fri, 2017-03-24 at 18:06 -0700, Matthias Kaehlcke wrote:
> __ieee80211_amsdu_copy_frag intentionally initializes a pointer to
> array[-1] to increment it later to valid values. clang rightfully
> generates an array-bounds warning on the initialization statement.
> Work around this by initializin
> Yes. CPU2 has a pre-existing reader that CPU1's synchronize_srcu()
> must wait for. But CPU2's reader cannot end until CPU1 releases
> its lock, which it cannot do until after CPU2's reader ends. Thus,
> as you say, deadlock.
>
> The rule is that if you are within any kind of RCU read-side c
Hi,
On Fri, 2017-03-24 at 09:56 +0100, Johannes Berg wrote:
> On Thu, 2017-03-23 at 16:29 +0100, Johannes Berg wrote:
> > Isn't it possible for the following to happen?
> >
> > CPU1CPU2
> >
>
On Thu, 2017-03-23 at 16:29 +0100, Johannes Berg wrote:
> Isn't it possible for the following to happen?
>
> CPU1 CPU2
>
> mutex_lock(&M);
> full_proxy_xyz();
>
Hi,
> Not yet. How reproducible is this?
Apparently quite. I haven't tried myself - it happens during some
automated test that I need to analyse further.
> > We're observing that with our (backported, but very recent) driver
> > against 4.9 (and 4.10, I think),
>
> Do I understand it correctly
On Thu, 2017-03-23 at 08:37 -0700, Paul E. McKenney wrote:
> I have not seen this, but my usual question for __synchronize_srcu()
> is if some other task is blocked holding srcu_read_lock() for that
> same srcu_struct.
>
Not as far as I can see - but that was the scenario I was outlining in
my s
On Thu, 2017-03-23 at 15:54 +0100, Johannes Berg wrote:
> Before I go hunting - has anyone seen a deadlock in
> synchronize_srcu() in debugfs_remove() before?
Isn't it possible for the following to happen?
CPU1CPU2
mu
Hi,
Before I go hunting - has anyone seen a deadlock in synchronize_srcu()
in debugfs_remove() before? We're observing that with our (backported,
but very recent) driver against 4.9 (and 4.10, I think), but there are
no backports of any debugfs things so the backport itself doesn't seem
like a lik
On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
Applied.
johannes
On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
Btw, I suspect you generated thi
On Mon, 2017-03-06 at 13:25 +0100, Johannes Berg wrote:
> On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> > From: Ondřej Lysoněk
> >
> > Use setup_timer() and setup_deferrable_timer() to set the data and
> > function timer fields. It makes the code cleaner an
> Not really. This is one of assignments for students I lead, so this
> is done by hand every end of winter semester (Note the From line.)
You really should teach them about coccinelle then :-)
> > Care to send a patch for that one too?
>
> I am just a forwarder, he received this request too, s
> One of the limitations of using async_schedule() though is we cannot
> request_module() synchronously on async calls given that the module
> initialization code will call async_synchronize_full() if the module
> being initialized happened to have used async work on its
> initialization routine,
On Wed, 2017-02-08 at 13:03 +0100, Arnd Bergmann wrote:
>
> - Moving nla_put_{u8,u16,u32} out of line is probably uncontroversial
> and
> it helps enough with br_netlink.c, but nl820211 is worse and needs
> some
> additional fiddling.
Why would that not be sufficient by itself for nl80211?
B
On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote:
> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote:
> > Seems the problem is caused by rtl92c_dm_*() casting .priv to
> > "struct
> > rtl_pci_priv", while it is "struct rtl_usb_priv".
>
> Those routines are shared by rtl8192ce and rtl8192cu, thus
401 - 500 of 1282 matches
Mail list logo
