* Re: [PATCH net-next 00/20] Support v6 real servers in v4 pools and vice versa
From: Simon Horman @ 2014-09-10 6:22 UTC (permalink / raw)
To: Julian Anastasov
Cc: Alex Gartrell, netdev, lvs-devel, kernel-team, ps,
Pablo Neira Ayuso, David Miller
In-Reply-To: <alpine.LFD.2.11.1409100853260.6338@ja.home.ssi.bg>
[ CC Pablo, Dave M ]
On Wed, Sep 10, 2014 at 09:01:34AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 9 Sep 2014, Alex Gartrell wrote:
>
> > The following patch set has been iterated upon in the lvs-devel mailing
> > list. I am submitting it here per Julian's advice for inclusion in the
> > net-next tree.
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
>
> Simon, please apply the patchset to ipvs-next.
> I guess ipvs-next and nf-next need to be updated
> before that due to dependency on net-next commit ea1d5d7755a3e556
> ("ipvs: properly declare tunnel encapsulation").
Thanks Julian, yes that does seem to be the case.
Pablo, could you merge nf into nf-next and push the result
so that I can apply this series on top?
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Tom Gundersen @ 2014-09-10 6:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: One Thousand Gnomes, Takashi Iwai, Kay Sievers, Sreekanth Reddy,
James Bottomley, Praveen Krishnamoorthy, hare,
Nagalakshmi Nandigama, Wu Zhangjin, Tetsuo Handa,
mpt-fusionlinux.pdl, Tim Gardner, Benjamin Poirier,
Santosh Rastapur, Casey Leedom, Hariprasad S, Pierre Fersing,
Arjan van de Ven, Abhijit Mahajan, systemd Mailing List
In-Reply-To: <CAB=NE6U6v-GhAaZv3yXn9uVFvBvE4Uq8z7MQU8N+CyW19WpnNQ@mail.gmail.com>
On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>>> <James.Bottomley@hansenpartnership.com> wrote:
>>> > If we want to sort out some sync/async mechanism for probing devices, as
>>> > an agreement between the init systems and the kernel, that's fine, but
>>> > its a to-be negotiated enhancement.
>>>
>>> Unfortunately as Tejun notes the train has left which already made
>>> assumptions on this.
>>
>> Well, that's why it's a bug. It's a material regression impacting
>> users.
>
> Indeed. I believe the issue with this regression however was that the
> original commit e64fae55 (January 2012) was only accepted by *kernel
> folks* to be a real regression until recently.
Just for the record, this only caused user-visible problems after
kernel commit 786235ee (November 2013), right?
> More than two years
> have gone by on growing design and assumptions on top of that original
> commit. I'm not sure if *systemd folks* yet believe its was a design
> regression?
I don't think so. udev should not allow its workers to run for an
unbounded length of time. Whether the upper bound should be 30, 60,
180 seconds or something else is up for debate (currently it is 60,
but if that is too short for some drivers we could certainly revisit
that). Moreover, it seems from this discussion that the aim is (still)
that insmod should be near-instantaneous (i.e., not wait for probe),
so it seems to me that the basic design is correct and all we need is
some temporary work-around and a way to better detect misbehaving
drivers?
>>> I'm afraid distributions that want to avoid this
>>> sigkill at least on the kernel front will have to work around this
>>> issue either on systemd by increasing the default timeout which is now
>>> possible thanks to Hannes' changes or by some other means such as the
>>> combination of a modified non-chatty version of this patch + a check
>>> at the end of load_module() as mentioned earlier on these threads.
>>
>> Increasing the default timeout in systemd seems like the obvious bug fix
>> to me. If the patch exists already, having distros that want it use it
>> looks to be correct ... not every bug is a kernel bug, after all.
>
> Its merged upstream on systemd now, along with a few fixes on top of
> it. I also see Kay merged a change to the default timeout to 60 second
> on August 30. Its unclear if these discussions had any impact on that
> decision or if that was just because udev firmware loading got now
> ripped out. I'll note that the new 60 second timeout wouldn't suffice
> for cxgb4 even if it didn't do firmware loading, its probe takes over
> one full minute.
>
>> Negotiating a probe vs init split for drivers is fine too, but it's a
>> longer term thing rather than a bug fix.
>
> Indeed. What I proposed with a multiplier for the timeout for the
> different types of built in commands was deemed complex but saw no
> alternatives proposed despite my interest to work on one and
> clarifications noted that this was a design regression. Not quite sure
> what else I could have done here. I'm interested in learning what the
> better approach is for the future as if we want to marry init + kernel
> we need a smooth way for us to discuss design without getting worked
> up about it, or taking it personal. I really want this to work as I
> personally like systemd so far.
How about this: keep the timeout global, but also introduce a
(relatively short, say 10 or 15 seconds) timeout after which a warning
is printed. Even if nothing is actually killed, having workers (be it
insmod or something else) take longer than a couple of seconds is
likely a sign that something is seriously off somewhere.
Cheers,
Tom
^ permalink raw reply
* Re: 3.17-rc1 oops during network interface configuration
From: Or Gerlitz @ 2014-09-10 7:42 UTC (permalink / raw)
To: Chuck Lever, Govindarajulu Varadarajan, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, LKML Kernel, linux-rdma,
Bart Van Assche, Saeed Mahameed, Tal Alon, Yevgeny Petrilin,
Roland Dreier
In-Reply-To: <F580F466-28A5-4BDD-A338-D5C065A760C1-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On 9/9/2014 10:30 PM, Chuck Lever wrote:
> This crash happens when booting v3.17-rcN on any of my IB-enabled
> systems. I have both ConnectX-2 and mthca systems, all are affected.
>
> I bisected this to:
>
> commit e0f31d8498676fda36289603a054d0d490aa2679
> Author: Govindarajulu Varadarajan <_govind-KK0ffGbhmjU@public.gmane.org>
> AuthorDate: Mon Jun 23 16:07:58 2014 +0530
> Commit: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> CommitDate: Mon Jun 23 14:32:19 2014 -0700
>
> flow_keys: Record IP layer protocol in skb_flow_dissect()
>
> skb_flow_dissect() dissects only transport header type in ip_proto. It dose not
> give any information about IPv4 or IPv6.
> This patch adds new member, n_proto, to struct flow_keys. Which records the
> IP layer type. i.e IPv4 or IPv6.
> This can be used in netdev->ndo_rx_flow_steer driver function to dissect flow.
> Adding new member to flow_keys increases the struct size by around 4 bytes.
> This causes BUILD_BUG_ON(sizeof(qcb->data) < sz); to fail in
> qdisc_cb_private_validate()
> So increase data size by 4
>
> Signed-off-by: Govindarajulu Varadarajan <_govind-KK0ffGbhmjU@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>
>
> This commit includes a hunk that increases the size of struct qdisc_skb_cb
> by at least 4 bytes:
>
>> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>> index 624f985..a3cfb8e 100644
>> --- a/include/net/sch_generic.h
>> +++ b/include/net/sch_generic.h
>> @@ -231,7 +231,7 @@ struct qdisc_skb_cb {
>> unsigned int pkt_len;
>> u16 slave_dev_queue_mapping;
>> u16 _pad;
>> - unsigned char data[20];
>> + unsigned char data[24];
>> };
>>
>> static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
>
>
> IPoIB defines the following structure in drivers/infiniband/ulp/ipoib/ipoib.h:
>
>> struct ipoib_cb {
>> struct qdisc_skb_cb qdisc_cb;
>> u8 hwaddr[INFINIBAND_ALEN];
>> };
> IPoIB keeps this in the sk_buff:cb field, which is exactly 48 bytes.
> After commit e0f31d84, the size of struct ipoib_cb on x86_64 becomes
> 52 bytes.
>
> Thus IPoIB overruns sk_buff:cb, and trashes the sk_buff::_skb_refdst
> field, which contains a pointer. By the time we get into
> __dev_queue_xmit() and try to use the result of skb_dst(), that pointer
> is garbage, and we oops.
>
> Obviously, cb[] could be increased to 56 bytes to accommodate struct
> ipoib_cb. I tried this, and it is effective in preventing the oops on
> one of my systems.
>
> But I suspect there is an historical reason I’m not aware of that it
> has remained 48 bytes for years.
Hi Chuck, thanks for bisecting this out. Indeed, as of this kernel 3.2
commit 936d7de "IPoIB: Stop lying about hard_header_len and use skb->cb
to stash LL addresses" we are using the skb->cb field to enable proper
work under GRO and avoid another historical quirk we had there... so I
think we can definetly consider commit e0f31d849 to introduce a severe
regression... Govindarajulu, Dave - what's your thinking here? any quick
idea on how to fix?
Also, I was thinking we have the mechanics in the kernel, e.g commit
a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound explicit.") to
catch such over-flows?
Or.
>>> BUG: unable to handle kernel paging request at ffff88090000007e
>>> IP: __dev_queue_xmit+0x519
>>> Call Trace:
>>> ? __dev_queue_xmit+0x49
>>> dev_queue_xmit+0x10
>>> neigh_connected_output
>>> ? ip_finish_output
>>> ip_finish_output
>>> ? ip_finish_output
>>> ? netif_rx_ni
>>> ip_mc_output
>>> ip_local_out_sk
>>> ip_send_skb
>>> udp_send_skb
>>> udp_sendmsg
>>> ? ip_reply_glue_bits
>>> ? __lock_is_held
>>> inet_sendmsg
>>> ? inet_sendmsg
>>> sock_sendmsg
>>> ? might_fault
>>> ? might_fault
>>> ? move_addr_to_kernel.part.38
>>> SYSC_sendto
>>> ? sysret_check
>>> ? trace_hardirqs_on_caller
>>> ? trace_hardirqs_on_thunk
>>> SyS_sendto
>>> system_call_fastpath
>>>
>>> Kernel panic - not syncing: Fatal exception in interrupt
>>> Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
>>> drm_kms_helper: panic occurred, switching back to text console
>>>
>>> A screenshot of this kernel oops can be found here:
>>> https://drive.google.com/file/d/0B1YQOreL3_FxVDB5UTNwekF6LVU/
>>>
>>> gdb translates the crash address into the following (not sure this makes sense
>>> since offset 0x519 is past the end of __dev_queue_xmit()):
>>>
>>> (gdb) list *(__dev_queue_xmit+0x519)
>>> 0xffffffff8136bc89 is in netdev_adjacent_rename_links (net/core/dev.c:5167).
>>> 5162 void netdev_adjacent_rename_links(struct net_device *dev, char *oldname)
>>> 5163 {
>>> 5164 struct netdev_adjacent *iter;
>>> 5165
>>> 5166 list_for_each_entry(iter, &dev->adj_list.upper, list) {
>>> 5167 netdev_adjacent_sysfs_del(iter->dev, oldname,
>>> 5168 &iter->dev->adj_list.lower);
>>> 5169 netdev_adjacent_sysfs_add(iter->dev, dev,
>>> 5170 &iter->dev->adj_list.lower);
>>> 5171 }
>>>
>>> And the address __dev_queue_xmit+0x49 is translated by gdb into:
>>>
>>> (gdb) list *(__dev_queue_xmit+0x49)
>>> 0xffffffff8136b7b9 is in __dev_queue_xmit (./arch/x86/include/asm/preempt.h:75).
>>> 70 * The various preempt_count add/sub methods
>>> 71 */
>>> 72
>>> 73 static __always_inline void __preempt_count_add(int val)
>>> 74 {
>>> 75 raw_cpu_add_4(__preempt_count, val);
>>> 76 }
>>> 77
>>> 78 static __always_inline void __preempt_count_sub(int val)
>>> 79 {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v1] net: ethernet: arc: Don't free Rockchip resources before disconnect from phy
From: Romain Perier @ 2014-09-10 7:51 UTC (permalink / raw)
To: heiko; +Cc: linux-rockchip, linux-arm-kernel, netdev
Free resources before being disconnected from phy and calling core driver is
wrong and should not happen. It avoids a delay of 4-5s caused by the timeout of
phy_disconnect().
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/net/ethernet/arc/emac_rockchip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index 51d0585..c31c740 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -202,12 +202,13 @@ static int emac_rockchip_remove(struct platform_device *pdev)
struct rockchip_priv_data *priv = netdev_priv(ndev);
int err;
+ err = arc_emac_remove(ndev);
+
clk_disable_unprepare(priv->refclk);
if (priv->regulator)
regulator_disable(priv->regulator);
- err = arc_emac_remove(ndev);
free_netdev(ndev);
return err;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v11 net-next 04/12] bpf: expand BPF syscall with program load/unload
From: Daniel Borkmann @ 2014-09-10 8:04 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1410325808-3657-5-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
> eBPF programs are similar to kernel modules. They are loaded by the user
> process and automatically unloaded when process exits. Each eBPF program is
> a safe run-to-completion set of instructions. eBPF verifier statically
> determines that the program terminates and is safe to execute.
>
> The following syscall wrapper can be used to load the program:
> int bpf_prog_load(enum bpf_prog_type prog_type,
> const struct bpf_insn *insns, int insn_cnt,
> const char *license)
> {
> union bpf_attr attr = {
> .prog_type = prog_type,
> .insns = insns,
> .insn_cnt = insn_cnt,
> .license = license,
> };
>
> return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
> }
> where 'insns' is an array of eBPF instructions and 'license' is a string
> that must be GPL compatible to call helper functions marked gpl_only
>
> Upon succesful load the syscall returns prog_fd.
> Use close(prog_fd) to unload the program.
>
> User space tests and examples follow in the later patches
>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
...
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 4b59edead908..9727616693e5 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -15,6 +15,7 @@
> struct sk_buff;
> struct sock;
> struct seccomp_data;
> +struct bpf_prog_info;
>
> /* ArgX, context and stack frame pointer register positions. Note,
> * Arg1, Arg2, Arg3, etc are used as argument mappings of function
> @@ -302,8 +303,12 @@ struct bpf_work_struct {
> struct bpf_prog {
> u16 pages; /* Number of allocated pages */
> bool jited; /* Is our filter JIT'ed? */
> + bool has_info; /* whether 'info' is valid */
> u32 len; /* Number of filter blocks */
> - struct sock_fprog_kern *orig_prog; /* Original BPF program */
> + union {
> + struct sock_fprog_kern *orig_prog; /* Original BPF program */
> + struct bpf_prog_info *info;
> + };
All members of this bpf_prog_info should go into bpf_work_struct,
as I have intended this to be a ancillary structure here. Since
we already allocate this anyway, you can reduce complexity by doing
the additional allocation plus remove the has_info member.
> struct bpf_work_struct *work; /* Deferred free work struct */
> unsigned int (*bpf_func)(const struct sk_buff *skb,
> const struct bpf_insn *filter);
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 3a03fdf4db0e..1d0411965576 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -99,12 +99,23 @@ enum bpf_cmd {
...
> +/* called by sockets/tracing/seccomp before attaching program to an event
> + * pairs with bpf_prog_put()
> + */
But seccomp already does refcounting on each BPF filter. Or, is the
intention to remove this from seccomp?
> +struct bpf_prog *bpf_prog_get(u32 ufd)
> +{
> + struct fd f = fdget(ufd);
> + struct bpf_prog *prog;
> +
> + prog = get_prog(f);
> +
> + if (IS_ERR(prog))
> + return prog;
> +
> + atomic_inc(&prog->info->refcnt);
> + fdput(f);
> + return prog;
> +}
...
> diff --git a/net/core/filter.c b/net/core/filter.c
> index dfc716ffa44b..d771e4f03745 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -835,6 +835,7 @@ static void bpf_release_orig_filter(struct bpf_prog *fp)
> {
> struct sock_fprog_kern *fprog = fp->orig_prog;
>
> + BUG_ON(fp->has_info);
Why BUG_ON() (also in so many other places)?
> if (fprog) {
> kfree(fprog->filter);
> kfree(fprog);
> @@ -973,6 +974,7 @@ static struct bpf_prog *bpf_prepare_filter(struct bpf_prog *fp)
>
> fp->bpf_func = NULL;
> fp->jited = false;
> + fp->has_info = false;
>
> err = bpf_check_classic(fp->insns, fp->len);
> if (err) {
>
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the arm-soc tree
From: Arnd Bergmann @ 2014-09-10 8:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stephen Rothwell, David Miller, netdev, Olof Johansson,
linux-next, Romain Perier, linux-kernel, Heiko Stübner
In-Reply-To: <20140910144837.5e3089e1@canb.auug.org.au>
On Wednesday 10 September 2014 14:48:37 Stephen Rothwell wrote:
> Today's linux-next merge of the net-next tree got a conflict in
> arch/arm/boot/dts/rk3188-radxarock.dts between commit 4721ab855d1a
> ("ARM: dts: rockchip: add hym8563 rtc to Radxa Rock board") from the
> arm-soc tree and commit c6ec956b73db ("ARM: dts: Enable emac node on
> the rk3188-radxarock boards") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Thanks, looks good.
Arnd
^ permalink raw reply
* Re: [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite
From: Daniel Borkmann @ 2014-09-10 8:19 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1410325808-3657-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
> As requested by Andy and others, here is the man page:
>
> BPF(2) Linux Programmer's Manual BPF(2)
...
> In the future maps can have different types: hash, array, bloom filter,
> radix-tree, but currently only hash type is supported:
> enum bpf_map_type {
> BPF_MAP_TYPE_UNSPEC,
> BPF_MAP_TYPE_HASH,
> };
If we mention them here in the man page, users are going to request
them, naturally. ;) So I'd just mention what we have, not what we do
not yet have. But I'm wondering how much library boiler plate only
for BPF we want to add in future, hopefully not most of what's in
Corman ... ? ;)
^ permalink raw reply
* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Emmanuel Grumbach @ 2014-09-10 8:24 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Vadim Kochan, John W. Linville, linux-wireless,
netdev@vger.kernel.org
In-Reply-To: <540FDB3C.6060301@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
On Wed, Sep 10, 2014 at 8:01 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 10.09.2014 00:07, Vadim Kochan wrote:
>> I have the same issue with iwlwifi.
>
> I tried an old zd1211 wireless USB stick to check if this problem is 80211
> related. But the USB stick works fine (I'm using it right now).
> So its definitely looks like an iwlwifi issue.
>
>> iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
>
> Wasn't there any change in the iwlwifi tx path recently??
Can you please try the patch attached? It works for me.
>
> Regards,
> Oliver
>
>>
[-- Attachment #2: 0001-iwlwifi-trans-don-t-configure-the-set_active-in-SCD-.patch --]
[-- Type: text/x-patch, Size: 4548 bytes --]
From 42bfcf93e18cb850d0b5f5e0a4b99a239e0e57ab Mon Sep 17 00:00:00 2001
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Wed, 10 Sep 2014 11:16:41 +0300
Subject: [PATCH] iwlwifi: trans: don't configure the set_active in SCD for dvm
This configuration is not needed for dvm, and it actually
broke it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-trans.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/ops.c | 1 +
drivers/net/wireless/iwlwifi/pcie/internal.h | 2 ++
drivers/net/wireless/iwlwifi/pcie/trans.c | 1 +
drivers/net/wireless/iwlwifi/pcie/tx.c | 6 ++++--
5 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans.h b/drivers/net/wireless/iwlwifi/iwl-trans.h
index 36275b4..c87b452 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@ -382,6 +382,7 @@ enum iwl_trans_status {
* if unset 4k will be the RX buffer size
* @bc_table_dword: set to true if the BC table expects the byte count to be
* in DWORD (as opposed to bytes)
+ * @scd_set_active: should the transport configure the SCD for HCMD queue
* @queue_watchdog_timeout: time (in ms) after which queues
* are considered stuck and will trigger device restart
* @command_names: array of command names, must be 256 entries
@@ -397,6 +398,7 @@ struct iwl_trans_config {
bool rx_buf_size_8k;
bool bc_table_dword;
+ bool scd_set_active;
unsigned int queue_watchdog_timeout;
const char *const *command_names;
};
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c b/drivers/net/wireless/iwlwifi/mvm/ops.c
index 77b0b48..ed82547 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -504,6 +504,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct iwl_cfg *cfg,
trans_cfg.cmd_queue = IWL_MVM_CMD_QUEUE;
trans_cfg.cmd_fifo = IWL_MVM_TX_FIFO_CMD;
+ trans_cfg.scd_set_active = true;
snprintf(mvm->hw->wiphy->fw_version,
sizeof(mvm->hw->wiphy->fw_version),
diff --git a/drivers/net/wireless/iwlwifi/pcie/internal.h b/drivers/net/wireless/iwlwifi/pcie/internal.h
index 5bca9a6..e6129af 100644
--- a/drivers/net/wireless/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/iwlwifi/pcie/internal.h
@@ -257,6 +257,7 @@ iwl_pcie_get_scratchbuf_dma(struct iwl_txq *txq, int idx)
* @cmd_queue - command queue number
* @rx_buf_size_8k: 8 kB RX buffer size
* @bc_table_dword: true if the BC table expects DWORD (as opposed to bytes)
+ * @scd_set_active: should the transport configure the SCD for HCMD queue
* @rx_page_order: page order for receive buffer size
* @wd_timeout: queue watchdog timeout (jiffies)
* @reg_lock: protect hw register access
@@ -306,6 +307,7 @@ struct iwl_trans_pcie {
bool rx_buf_size_8k;
bool bc_table_dword;
+ bool scd_set_active;
u32 rx_page_order;
const char *const *command_names;
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 0f4a4c1..a215624 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -1177,6 +1177,7 @@ static void iwl_trans_pcie_configure(struct iwl_trans *trans,
trans_pcie->command_names = trans_cfg->command_names;
trans_pcie->bc_table_dword = trans_cfg->bc_table_dword;
+ trans_pcie->scd_set_active = trans_cfg->scd_set_active;
/* Initialize NAPI here - it should be before registering to mac80211
* in the opmode but after the HW struct is allocated.
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index f4df951..d69f2e9 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -1085,7 +1085,8 @@ void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
fifo = cfg->fifo;
/* Disable the scheduler prior configuring the cmd queue */
- if (txq_id == trans_pcie->cmd_queue)
+ if (txq_id == trans_pcie->cmd_queue &&
+ trans_pcie->scd_set_active)
iwl_scd_enable_set_active(trans, 0);
/* Stop this Tx queue before configuring it */
@@ -1147,7 +1148,8 @@ void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
SCD_QUEUE_STTS_REG_MSK);
/* enable the scheduler for this queue (only) */
- if (txq_id == trans_pcie->cmd_queue)
+ if (txq_id == trans_pcie->cmd_queue &&
+ trans_pcie->scd_set_active)
iwl_scd_enable_set_active(trans, BIT(txq_id));
}
--
1.9.1
^ permalink raw reply related
* RE: [PATCH V2 net] core: Don't attempt to load the "" driver.
From: David Laight @ 2014-09-10 8:50 UTC (permalink / raw)
To: 'David Miller'; +Cc: netdev@vger.kernel.org
In-Reply-To: <20140909.172410.519439746131615877.davem@davemloft.net>
From: David Miller
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Mon, 8 Sep 2014 13:23:33 +0000
>
> > This whole 'try to load the module' path should be predicated on
> > 'interface not found'.
>
> And that's the first thing dev_load() does, it tries to look up the
> device by name, and only does the module load attempt if that fails.
OK, I'd not looked back at the code before making that comment.
> Nobody cares if the module load itself actually fails, dev_load()
> returns void after all.
The actual code path is typically:
dev_load(net, ifr.ifr_name);
rtnl_lock()
ret = dev_xxx(net, &ifr, cmd);
rtnl_unlock()
where the first thing dev_xxx() does is to call __dev_get_by_name()
(or the equivalent dev_get_by_name_rcu()) again.
So the code 'sort of' cares whether the module loaded.
I actually wonder when the module load is useful - must be useful sometimes,
otherwise it wouldn't have been added.
I thought ifr.ifr_name was likely to be (say) "eth2" - but the module
won't be called that.
Looks like some hack to get something like the 'bond' driver loaded,
but even then surely ifr.ifr_name would be "bond0" not "bond".
I've had a quick look with 'git blame', but dev_ioctl.c was split from
somewhere and doesn't contain the history.
David.
^ permalink raw reply
* [PATCH] [RESEND] ath5k: Remove AHB bus support
From: Paul Bolle @ 2014-09-10 8:53 UTC (permalink / raw)
To: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, John W. Linville
Cc: Sergey Ryazanov, Oleksij Rempel, Richard Weinberger,
Jonathan Bither, Hauke Mehrtens, ath5k-devel, open, list,
antonynpavlov, openwrt-devel, ath5k-devel, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20140909182734.GJ29412@tuxdriver.com>
AHB bus support was added in v2.6.38, through commit a0b907ee2a71
("ath5k: Add AHB bus support."). That code can only be build if the
Kconfig symbol ATHEROS_AR231X is set. But that symbol has never been
added to the tree. So AHB bus support has always been dead code.
Let's remove all code that depends on ATHEROS_AR231X. If that symbol
ever gets added to the tree the AHB bus support can be re-added too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
First sent in https://lkml.org/lkml/2013/5/13/303 . Updated on top of
next-20140909.
Build tested only (no access to this hardware).
drivers/net/wireless/ath/ath5k/Kconfig | 14 +-
drivers/net/wireless/ath/ath5k/Makefile | 1 -
drivers/net/wireless/ath/ath5k/ahb.c | 234 --------------------------------
drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----
drivers/net/wireless/ath/ath5k/base.c | 14 --
drivers/net/wireless/ath/ath5k/led.c | 6 -
6 files changed, 3 insertions(+), 294 deletions(-)
delete mode 100644 drivers/net/wireless/ath/ath5k/ahb.c
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index c9f81a388f15..93caf8e68901 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,13 +1,12 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
- depends on (PCI || ATHEROS_AR231X) && MAC80211
+ depends on PCI && MAC80211
select ATH_COMMON
select MAC80211_LEDS
select LEDS_CLASS
select NEW_LEDS
select AVERAGE
- select ATH5K_AHB if (ATHEROS_AR231X && !PCI)
- select ATH5K_PCI if (!ATHEROS_AR231X && PCI)
+ select ATH5K_PCI
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -52,16 +51,9 @@ config ATH5K_TRACER
If unsure, say N.
-config ATH5K_AHB
- bool "Atheros 5xxx AHB bus support"
- depends on (ATHEROS_AR231X && !PCI)
- ---help---
- This adds support for WiSoC type chipsets of the 5xxx Atheros
- family.
-
config ATH5K_PCI
bool "Atheros 5xxx PCI bus support"
- depends on (!ATHEROS_AR231X && PCI)
+ depends on PCI
---help---
This adds support for PCI type chipsets of the 5xxx Atheros
family.
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index 1b3a34f7f224..51e2d8668041 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -17,6 +17,5 @@ ath5k-y += ani.o
ath5k-y += sysfs.o
ath5k-y += mac80211-ops.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
-ath5k-$(CONFIG_ATH5K_AHB) += ahb.o
ath5k-$(CONFIG_ATH5K_PCI) += pci.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
deleted file mode 100644
index 79bffe165cab..000000000000
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ /dev/null
@@ -1,234 +0,0 @@
-/*
- * Copyright (c) 2008-2009 Atheros Communications Inc.
- * Copyright (c) 2009 Gabor Juhos <juhosg@openwrt.org>
- * Copyright (c) 2009 Imre Kaloz <kaloz@openwrt.org>
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-#include <linux/nl80211.h>
-#include <linux/platform_device.h>
-#include <linux/etherdevice.h>
-#include <linux/export.h>
-#include <ar231x_platform.h>
-#include "ath5k.h"
-#include "debug.h"
-#include "base.h"
-#include "reg.h"
-
-/* return bus cachesize in 4B word units */
-static void ath5k_ahb_read_cachesize(struct ath_common *common, int *csz)
-{
- *csz = L1_CACHE_BYTES >> 2;
-}
-
-static bool
-ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
-{
- struct ath5k_hw *ah = common->priv;
- struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
- u16 *eeprom, *eeprom_end;
-
- eeprom = (u16 *) bcfg->radio;
- eeprom_end = ((void *) bcfg->config) + BOARD_CONFIG_BUFSZ;
-
- eeprom += off;
- if (eeprom > eeprom_end)
- return false;
-
- *data = *eeprom;
- return true;
-}
-
-int ath5k_hw_read_srev(struct ath5k_hw *ah)
-{
- struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
- ah->ah_mac_srev = bcfg->devid;
- return 0;
-}
-
-static int ath5k_ahb_eeprom_read_mac(struct ath5k_hw *ah, u8 *mac)
-{
- struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
- u8 *cfg_mac;
-
- if (to_platform_device(ah->dev)->id == 0)
- cfg_mac = bcfg->config->wlan0_mac;
- else
- cfg_mac = bcfg->config->wlan1_mac;
-
- memcpy(mac, cfg_mac, ETH_ALEN);
- return 0;
-}
-
-static const struct ath_bus_ops ath_ahb_bus_ops = {
- .ath_bus_type = ATH_AHB,
- .read_cachesize = ath5k_ahb_read_cachesize,
- .eeprom_read = ath5k_ahb_eeprom_read,
- .eeprom_read_mac = ath5k_ahb_eeprom_read_mac,
-};
-
-/*Initialization*/
-static int ath_ahb_probe(struct platform_device *pdev)
-{
- struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
- struct ath5k_hw *ah;
- struct ieee80211_hw *hw;
- struct resource *res;
- void __iomem *mem;
- int irq;
- int ret = 0;
- u32 reg;
-
- if (!dev_get_platdata(&pdev->dev)) {
- dev_err(&pdev->dev, "no platform data specified\n");
- ret = -EINVAL;
- goto err_out;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "no memory resource found\n");
- ret = -ENXIO;
- goto err_out;
- }
-
- mem = ioremap_nocache(res->start, resource_size(res));
- if (mem == NULL) {
- dev_err(&pdev->dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto err_out;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "no IRQ resource found\n");
- ret = -ENXIO;
- goto err_iounmap;
- }
-
- irq = res->start;
-
- hw = ieee80211_alloc_hw(sizeof(struct ath5k_hw), &ath5k_hw_ops);
- if (hw == NULL) {
- dev_err(&pdev->dev, "no memory for ieee80211_hw\n");
- ret = -ENOMEM;
- goto err_iounmap;
- }
-
- ah = hw->priv;
- ah->hw = hw;
- ah->dev = &pdev->dev;
- ah->iobase = mem;
- ah->irq = irq;
- ah->devid = bcfg->devid;
-
- if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
- /* Enable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
- reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
- iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
-
- /* Enable global WMAC swapping */
- reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
- reg |= AR5K_AR2315_BYTESWAP_WMAC;
- iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
- } else {
- /* Enable WMAC DMA access (assuming 5312 or 231x*/
- /* TODO: check other platforms */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
- if (to_platform_device(ah->dev)->id == 0)
- reg |= AR5K_AR5312_ENABLE_WLAN0;
- else
- reg |= AR5K_AR5312_ENABLE_WLAN1;
- iowrite32(reg, (void __iomem *) AR5K_AR5312_ENABLE);
-
- /*
- * On a dual-band AR5312, the multiband radio is only
- * used as pass-through. Disable 2 GHz support in the
- * driver for it
- */
- if (to_platform_device(ah->dev)->id == 0 &&
- (bcfg->config->flags & (BD_WLAN0 | BD_WLAN1)) ==
- (BD_WLAN1 | BD_WLAN0))
- ah->ah_capabilities.cap_needs_2GHz_ovr = true;
- else
- ah->ah_capabilities.cap_needs_2GHz_ovr = false;
- }
-
- ret = ath5k_init_ah(ah, &ath_ahb_bus_ops);
- if (ret != 0) {
- dev_err(&pdev->dev, "failed to attach device, err=%d\n", ret);
- ret = -ENODEV;
- goto err_free_hw;
- }
-
- platform_set_drvdata(pdev, hw);
-
- return 0;
-
- err_free_hw:
- ieee80211_free_hw(hw);
- err_iounmap:
- iounmap(mem);
- err_out:
- return ret;
-}
-
-static int ath_ahb_remove(struct platform_device *pdev)
-{
- struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
- struct ieee80211_hw *hw = platform_get_drvdata(pdev);
- struct ath5k_hw *ah;
- u32 reg;
-
- if (!hw)
- return 0;
-
- ah = hw->priv;
-
- if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
- /* Disable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
- reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
- iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
- } else {
- /*Stop DMA access */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
- if (to_platform_device(ah->dev)->id == 0)
- reg &= ~AR5K_AR5312_ENABLE_WLAN0;
- else
- reg &= ~AR5K_AR5312_ENABLE_WLAN1;
- iowrite32(reg, (void __iomem *) AR5K_AR5312_ENABLE);
- }
-
- ath5k_deinit_ah(ah);
- iounmap(ah->iobase);
- ieee80211_free_hw(hw);
-
- return 0;
-}
-
-static struct platform_driver ath_ahb_driver = {
- .probe = ath_ahb_probe,
- .remove = ath_ahb_remove,
- .driver = {
- .name = "ar231x-wmac",
- .owner = THIS_MODULE,
- },
-};
-
-module_platform_driver(ath_ahb_driver);
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 85316bb3f8c6..ed2468220216 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1647,32 +1647,6 @@ static inline struct ath_regulatory *ath5k_hw_regulatory(struct ath5k_hw *ah)
return &(ath5k_hw_common(ah)->regulatory);
}
-#ifdef CONFIG_ATHEROS_AR231X
-#define AR5K_AR2315_PCI_BASE ((void __iomem *)0xb0100000)
-
-static inline void __iomem *ath5k_ahb_reg(struct ath5k_hw *ah, u16 reg)
-{
- /* On AR2315 and AR2317 the PCI clock domain registers
- * are outside of the WMAC register space */
- if (unlikely((reg >= 0x4000) && (reg < 0x5000) &&
- (ah->ah_mac_srev >= AR5K_SREV_AR2315_R6)))
- return AR5K_AR2315_PCI_BASE + reg;
-
- return ah->iobase + reg;
-}
-
-static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
-{
- return ioread32(ath5k_ahb_reg(ah, reg));
-}
-
-static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
-{
- iowrite32(val, ath5k_ahb_reg(ah, reg));
-}
-
-#else
-
static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
{
return ioread32(ah->iobase + reg);
@@ -1683,8 +1657,6 @@ static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
iowrite32(val, ah->iobase + reg);
}
-#endif
-
static inline enum ath_bus_type ath5k_get_bus_type(struct ath5k_hw *ah)
{
return ath5k_hw_common(ah)->bus_ops->ath_bus_type;
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 59a87247aac4..a4a09bb8f2f3 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -99,15 +99,6 @@ static int ath5k_reset(struct ath5k_hw *ah, struct ieee80211_channel *chan,
/* Known SREVs */
static const struct ath5k_srev_name srev_names[] = {
-#ifdef CONFIG_ATHEROS_AR231X
- { "5312", AR5K_VERSION_MAC, AR5K_SREV_AR5312_R2 },
- { "5312", AR5K_VERSION_MAC, AR5K_SREV_AR5312_R7 },
- { "2313", AR5K_VERSION_MAC, AR5K_SREV_AR2313_R8 },
- { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R6 },
- { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R7 },
- { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R1 },
- { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R2 },
-#else
{ "5210", AR5K_VERSION_MAC, AR5K_SREV_AR5210 },
{ "5311", AR5K_VERSION_MAC, AR5K_SREV_AR5311 },
{ "5311A", AR5K_VERSION_MAC, AR5K_SREV_AR5311A },
@@ -126,7 +117,6 @@ static const struct ath5k_srev_name srev_names[] = {
{ "5418", AR5K_VERSION_MAC, AR5K_SREV_AR5418 },
{ "2425", AR5K_VERSION_MAC, AR5K_SREV_AR2425 },
{ "2417", AR5K_VERSION_MAC, AR5K_SREV_AR2417 },
-#endif
{ "xxxxx", AR5K_VERSION_MAC, AR5K_SREV_UNKNOWN },
{ "5110", AR5K_VERSION_RAD, AR5K_SREV_RAD_5110 },
{ "5111", AR5K_VERSION_RAD, AR5K_SREV_RAD_5111 },
@@ -142,10 +132,6 @@ static const struct ath5k_srev_name srev_names[] = {
{ "5413", AR5K_VERSION_RAD, AR5K_SREV_RAD_5413 },
{ "5424", AR5K_VERSION_RAD, AR5K_SREV_RAD_5424 },
{ "5133", AR5K_VERSION_RAD, AR5K_SREV_RAD_5133 },
-#ifdef CONFIG_ATHEROS_AR231X
- { "2316", AR5K_VERSION_RAD, AR5K_SREV_RAD_2316 },
- { "2317", AR5K_VERSION_RAD, AR5K_SREV_RAD_2317 },
-#endif
{ "xxxxx", AR5K_VERSION_RAD, AR5K_SREV_UNKNOWN },
};
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 2062d1190556..0beb7e7d6075 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -163,20 +163,14 @@ int ath5k_init_leds(struct ath5k_hw *ah)
{
int ret = 0;
struct ieee80211_hw *hw = ah->hw;
-#ifndef CONFIG_ATHEROS_AR231X
struct pci_dev *pdev = ah->pdev;
-#endif
char name[ATH5K_LED_MAX_NAME_LEN + 1];
const struct pci_device_id *match;
if (!ah->pdev)
return 0;
-#ifdef CONFIG_ATHEROS_AR231X
- match = NULL;
-#else
match = pci_match_id(&ath5k_led_devices[0], pdev);
-#endif
if (match) {
__set_bit(ATH_STAT_LEDSOFT, ah->status);
ah->led_pin = ATH_PIN(match->driver_data);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite
From: Daniel Borkmann @ 2014-09-10 9:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api, netdev, linux-kernel
In-Reply-To: <1410325808-3657-1-git-send-email-ast@plumgrid.com>
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
> struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
> int map_fd;
> void *key;
> union {
> void *value;
> void *next_key;
> };
> };
>
> struct { /* anonymous struct used by BPF_PROG_LOAD command */
> enum bpf_prog_type prog_type;
> __u32 insn_cnt;
> const struct bpf_insn *insns;
> const char *license;
> __u32 log_level; /* verbosity level of eBPF verifier */
> __u32 log_size; /* size of user buffer */
> void *log_buf; /* user supplied buffer */
What is log buffer? Would that mean the verifier will return an error
string if the program will not pass it, or if not, what other data?
I think the man page is missing how to examine the returned verifier
log buffer data.
^ permalink raw reply
* gcc 4.8.3 miscompiles drivers/net/ethernet/freescale/fec_main.c ?!
From: David Jander @ 2014-09-10 9:09 UTC (permalink / raw)
To: Russell King, David S. Miller; +Cc: netdev, linux-arm-kernel
Hi,
I am seeing a strange problem when building a recent kernel with gcc-4.8.3 for
armv7-a that contains the following patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=bfd4ecdd87d350e19457fe0d02fa1e046774c44e
Unfortunately I am not good enough at reading ARM assembly output from GCC to
understand whats going wrong, so I am asking for help.
I started noticing ethernet packet loss on a i.MX6 board after upgrading the
kernel from 3.16-rc-something to latest mainline. The problem is very easy to
reproduce so I started git-bisecting. Git bisect gave me the above patch as
the culprit, and indeed: Without the patch a flood-ping goes fine (just one
dot on screen, no lost packets). I apply the patch and the dots start filling
the screen instantly.
I am compiling the kernel using Pengutronix's OSELAS toolchain version
2013.12.1, which is based on linaro gcc-4.8.3 without any relevant patches
AFAIK.
Compiling with -O2 breaks the code, while -Os seems to produce a correctly
working kernel.
I decided to make changes to the code and see if I could find other ways to
"fix" the problem, and I got the following result:
The above mentioned patch introduces the static function fec_enet_hwtstamp()
near line 1068 of fec_main.c. If I make an exact copy of this function, where
I only change the name (e.g. fec_enet_hwtstamp2), and change one of the two
places this function is called to instead use the other name, GCC inlines both
copies and the problem disappears!
Since I am not very good at GCC internals nor do I know this piece of code in
fec_main.c very well, I am asking here for help in hunting down the real bug,
which I suspect is in GCC... but I want to know for sure.
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Vadim Kochan @ 2014-09-10 9:16 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Oliver Hartkopp, John W. Linville, linux-wireless,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CANUX_P3kOetqEneHgqoCDN4c85SQYD-G=mQj_o1c_TvKmE5psA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
Your patch works for me.
On Wed, Sep 10, 2014 at 11:24 AM, Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Sep 10, 2014 at 8:01 AM, Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
>> On 10.09.2014 00:07, Vadim Kochan wrote:
>>> I have the same issue with iwlwifi.
>>
>> I tried an old zd1211 wireless USB stick to check if this problem is 80211
>> related. But the USB stick works fine (I'm using it right now).
>> So its definitely looks like an iwlwifi issue.
>>
>>> iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
>>
>> Wasn't there any change in the iwlwifi tx path recently??
>
> Can you please try the patch attached? It works for me.
>
>>
>> Regards,
>> Oliver
>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite
From: Daniel Borkmann @ 2014-09-10 9:21 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api, netdev, linux-kernel
In-Reply-To: <1410325808-3657-1-git-send-email-ast@plumgrid.com>
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
....
> BPF(2) Linux Programmer's Manual BPF(2)
...
> union bpf_attr {
> struct { /* anonymous struct used by BPF_MAP_CREATE command */
> enum bpf_map_type map_type;
> __u32 key_size; /* size of key in bytes */
> __u32 value_size; /* size of value in bytes */
> __u32 max_entries; /* max number of entries in a map */
> };
>
> struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
> int map_fd;
> void *key;
> union {
> void *value;
> void *next_key;
> };
When you pass in these structs with pointers in it to other user space
buffers, how do you handle this with mixed 32/64 bit user/kernel space?
As an example, for the current way to load BPF although we export ...
struct sock_fprog {
unsigned short len;
struct sock_filter __user *filter;
};
... through uapi, we still need to handle this via compat_sock_fprog
to take care of different pointer sizes via compat_uptr_t :
#ifdef CONFIG_COMPAT
struct compat_sock_fprog {
u16 len;
compat_uptr_t filter;
};
#endif
Perhaps I'm missing something, but I think, that would currently break in
your syscall handler, no?
> };
>
> struct { /* anonymous struct used by BPF_PROG_LOAD command */
> enum bpf_prog_type prog_type;
> __u32 insn_cnt;
> const struct bpf_insn *insns;
> const char *license;
> __u32 log_level; /* verbosity level of eBPF verifier */
> __u32 log_size; /* size of user buffer */
> void *log_buf; /* user supplied buffer */
> };
> };
^ permalink raw reply
* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Oliver Hartkopp @ 2014-09-10 9:23 UTC (permalink / raw)
To: Vadim Kochan, Emmanuel Grumbach
Cc: John W. Linville, linux-wireless,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMw6YJKgVVnDrn1X7atemC1r9kwvsr3PQDs4qx5KDeeNy-P3VA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi all,
yes for me too.
Although I only could test it here with my mobile hotspot which only supports
WEP ... but before that hotspot was not working too.
I'll check with my WPA2 setup again when I'm back home (if it's still needed).
So far feel free to add my
Reported-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Tested-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Many thanks for your quick reaction!
Best regards,
Oliver
On 10.09.2014 11:16, Vadim Kochan wrote:
> Hi,
>
> Your patch works for me.
>
> On Wed, Sep 10, 2014 at 11:24 AM, Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Wed, Sep 10, 2014 at 8:01 AM, Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
>>> On 10.09.2014 00:07, Vadim Kochan wrote:
>>>> I have the same issue with iwlwifi.
>>>
>>> I tried an old zd1211 wireless USB stick to check if this problem is 80211
>>> related. But the USB stick works fine (I'm using it right now).
>>> So its definitely looks like an iwlwifi issue.
>>>
>>>> iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
>>>
>>> Wasn't there any change in the iwlwifi tx path recently??
>>
>> Can you please try the patch attached? It works for me.
>>
>>>
>>> Regards,
>>> Oliver
>>>
>>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net-next v2] r8169:add support for RTL8168H and RTL8107E
From: Hayes Wang @ 2014-09-10 9:25 UTC (permalink / raw)
To: Ivan Vecera, Hau, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, romieu@fr.zoreil.com
In-Reply-To: <540EF02E.7090209@redhat.com>
From: Ivan Vecera [mailto:ivecera@redhat.com]
> Sent: Tuesday, September 09, 2014 8:19 PM
[...]
> Thanks Hayes,
> have you got any idea when do you update them?
If all are fine, I would release them this week.
Best Regards,
Hayes
^ permalink raw reply
* [PATCH net-next] ipv6: implement rt_genid_bump_ipv6 with fn_sernum and remove rt6i_genid
From: Hannes Frederic Sowa @ 2014-09-10 9:31 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Nicolas Dichtel
In-Reply-To: <1410267519.27979.31.camel@localhost>
Some special routes will never be cloned in IPv6. Those are mainly
DST_HOST routes without RTF_NONEXTHOP or RTF_GATEWAY flags, thus mostly
routes handling the input path.
rt_genid depends on rt6_info clones being removed from the trie and
recreated with current rt6i_genid, thus bumping the genid would invalidate
all routes cached in the sockets and relookup will recreate them. But in
case a non-cloned route ends up in the per-socket cache, it will never
be recreated, thus will never get a current rt_genid.
After the rt_genid is incremented for the first time all those routes
will always get invalidated by ip6_dst_check on the next check, thus
making early socket demultiplexing absolutely pointless for IPv6. It is
not possible to solve this with rt6i_genid, thus remove it.
In case we need to force the sockets to relookup the routes we now
increase the fn_sernum on all fibnodes in the routing tree. This is a
costly operation but should only happen if we have major routing/policy
changes in the kernel (e.g. manual route adding/removal, xfrm policy
changes). Also this patch optimized the walk over the trie a bit, we
don't touch every rt6_info but only touch the fib6_nodes.
Thanks to Eric Dumazet who noticed this problem.
Fixes: 6f3118b571b8 ("ipv6: use net->rt_genid to check dst validity")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
Notes:
I based this patch on net-next, because it "only" fixes a performance
problem so far and want it to be a bit more exposed to testing before
a possible submission to stable.
include/net/ip6_fib.h | 5 ++--
include/net/net_namespace.h | 4 +++-
net/core/dst.c | 8 +++++++
net/ipv6/ip6_fib.c | 57 ++++++++++++++++++++++++++++++++++++---------
net/ipv6/route.c | 4 ----
5 files changed, 59 insertions(+), 19 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 9bcb220..a5e09b8 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -119,8 +119,6 @@ struct rt6_info {
struct inet6_dev *rt6i_idev;
unsigned long _rt6i_peer;
- u32 rt6i_genid;
-
/* more non-fragment space at head required */
unsigned short rt6i_nfheader_len;
@@ -281,7 +279,8 @@ struct fib6_node *fib6_locate(struct fib6_node *root,
const struct in6_addr *daddr, int dst_len,
const struct in6_addr *saddr, int src_len);
-void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
+void fib6_clean_all(struct net *net,
+ int (*rt_visit)(struct rt6_info *, void *arg),
void *arg);
int fib6_add(struct fib6_node *root, struct rt6_info *rt, struct nl_info *info,
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 361d260..e0b0476 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -358,9 +358,11 @@ static inline int rt_genid_ipv6(struct net *net)
return atomic_read(&net->ipv6.rt_genid);
}
+extern void (*__rt_genid_bump_ipv6)(struct net *net);
static inline void rt_genid_bump_ipv6(struct net *net)
{
- atomic_inc(&net->ipv6.rt_genid);
+ if (__rt_genid_bump_ipv6)
+ __rt_genid_bump_ipv6(net);
}
#else
static inline int rt_genid_ipv6(struct net *net)
diff --git a/net/core/dst.c b/net/core/dst.c
index a028409..995183b 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -23,6 +23,14 @@
#include <net/dst.h>
+/* as soon as the ipv6 module registers, this function is used to
+ * force all cached routing lookups to relookup
+ */
+#if IS_ENABLED(CONFIG_IPV6)
+void (*__rt_genid_bump_ipv6)(struct net *net);
+EXPORT_SYMBOL(__rt_genid_bump_ipv6);
+#endif
+
/*
* Theory of operations:
* 1) We use a list, protected by a spinlock, to add
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 76b7f5e..d23b76f 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -106,10 +106,15 @@ static inline void fib6_walker_unlink(struct fib6_walker_t *w)
}
static __inline__ u32 fib6_new_sernum(void)
{
- u32 n = ++rt_sernum;
- if ((__s32)n <= 0)
- rt_sernum = n = 1;
- return n;
+ u32 new, old;
+
+ do {
+ old = ACCESS_ONCE(rt_sernum);
+ new = old + 1;
+ if ((s32)new <= 0)
+ new = 1;
+ } while (cmpxchg(&rt_sernum, old, new) != old);
+ return new;
}
/*
@@ -1553,25 +1558,28 @@ static int fib6_clean_node(struct fib6_walker_t *w)
*/
static void fib6_clean_tree(struct net *net, struct fib6_node *root,
- int (*func)(struct rt6_info *, void *arg),
+ int (*node_visit)(struct fib6_walker_t *),
+ int (*rt_visit)(struct rt6_info *, void *arg),
int prune, void *arg)
{
struct fib6_cleaner_t c;
c.w.root = root;
- c.w.func = fib6_clean_node;
+ c.w.func = node_visit;
c.w.prune = prune;
c.w.count = 0;
c.w.skip = 0;
- c.func = func;
+ c.func = rt_visit;
c.arg = arg;
c.net = net;
fib6_walk(&c.w);
}
-void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
- void *arg)
+static void __fib6_clean_all(struct net *net,
+ int (*node_visit)(struct fib6_walker_t *),
+ int (*rt_visit)(struct rt6_info *, void *arg),
+ void *arg)
{
struct fib6_table *table;
struct hlist_head *head;
@@ -1583,13 +1591,20 @@ void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
hlist_for_each_entry_rcu(table, head, tb6_hlist) {
write_lock_bh(&table->tb6_lock);
fib6_clean_tree(net, &table->tb6_root,
- func, 0, arg);
+ node_visit, rt_visit, 0, arg);
write_unlock_bh(&table->tb6_lock);
}
}
rcu_read_unlock();
}
+void fib6_clean_all(struct net *net,
+ int (*rt_visit)(struct rt6_info *, void *arg),
+ void *arg)
+{
+ __fib6_clean_all(net, fib6_clean_node, rt_visit, arg);
+}
+
static int fib6_prune_clone(struct rt6_info *rt, void *arg)
{
if (rt->rt6i_flags & RTF_CACHE) {
@@ -1602,7 +1617,25 @@ static int fib6_prune_clone(struct rt6_info *rt, void *arg)
static void fib6_prune_clones(struct net *net, struct fib6_node *fn)
{
- fib6_clean_tree(net, fn, fib6_prune_clone, 1, NULL);
+ fib6_clean_tree(net, fn, fib6_clean_node, fib6_prune_clone, 1, NULL);
+}
+
+static int fib6_upd_sernum(struct fib6_walker_t *w)
+{
+ struct fib6_cleaner_t *c = container_of(w, struct fib6_cleaner_t, w);
+ int *sernum = c->arg;
+
+ w->node->fn_sernum = *sernum;
+ w->leaf = NULL;
+ return 0;
+}
+
+static void fib6_genid_bump(struct net *net)
+{
+ int sernum;
+
+ sernum = fib6_new_sernum();
+ __fib6_clean_all(net, fib6_upd_sernum, NULL, &sernum);
}
/*
@@ -1788,6 +1821,8 @@ int __init fib6_init(void)
NULL);
if (ret)
goto out_unregister_subsys;
+
+ __rt_genid_bump_ipv6 = fib6_genid_bump;
out:
return ret;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f74b041..a318dd89 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -314,7 +314,6 @@ static inline struct rt6_info *ip6_dst_alloc(struct net *net,
memset(dst + 1, 0, sizeof(*rt) - sizeof(*dst));
rt6_init_peer(rt, table ? &table->tb6_peers : net->ipv6.peers);
- rt->rt6i_genid = rt_genid_ipv6(net);
INIT_LIST_HEAD(&rt->rt6i_siblings);
}
return rt;
@@ -1096,9 +1095,6 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
* DST_OBSOLETE_FORCE_CHK which forces validation calls down
* into this function always.
*/
- if (rt->rt6i_genid != rt_genid_ipv6(dev_net(rt->dst.dev)))
- return NULL;
-
if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
return NULL;
--
1.9.3
^ permalink raw reply related
* Re: Macvlan WARNiNGS about duplicate sysfs filenames (Was [GIT] Networking)
From: Alexander Y. Fomichev @ 2014-09-10 9:32 UTC (permalink / raw)
To: Andres Freund
Cc: Cong Wang, David Miller, Linus Torvalds, Andrew Morton, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <20140909235534.GH24649@awork2.anarazel.de>
[-- Attachment #1: Type: text/plain, Size: 4502 bytes --]
On Wed, Sep 10, 2014 at 3:55 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2014-09-10 01:48:06 +0200, Andres Freund wrote:
>> On 2014-09-09 15:43:55 -0700, Cong Wang wrote:
>> > On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund <andres@anarazel.de> wrote:
>> > > Hi,
>> > >
>> > > (don't have netdev archived, thus answering here, sorry)
>> > >
>> > > On 2014-09-07 16:41:09 -0700, David Miller wrote:
>> > >> Alexander Y. Fomichev (1):
>> > >> net: prevent of emerging cross-namespace symlinks
>> > >
>> >
>> > Since you are quoting this change, are you saying it causes
>> > the following kernel warning?
>>
>> I thought it might be a likely candidate; but I'm not sure at all. I'll
>> verify it as soon as I can reboot the machine a couple of times (end of
>> week-ish).
>>
>> > > I'm seeing WARNINGs like:
>> > > [ 1005.269134] ------------[ cut here ]------------
>> > > [ 1005.269148] WARNING: CPU: 6 PID: 4213 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80()
>> > > [ 1005.269150] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0'
>> >
>> >
>> > Is there a network device named upper_mv-eth0 existed in your system
>> > before you created macvlan?
>>
>> No, there wasn't any. Afaics, the sequence is:
>> 1) macvlan mv-eth0 is created in global namespace
>> 2) mv-eth0 is moved (by systemd-nsspawn) into a new network
>> namespace. Leaving a dangling symlink in the host namespace
>> /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0 pointing toward
>> ../mv-eth0
>> which doesn't exist in the external namespace. The new namespace seems
>> to have broken 'lower_bond0' symlink as well
>>
>> This seems to be the case (and probably the actual root cause) in
>> slightly earlier kernels as well.
>> What changed seems to be that:
>> 3) macvlan mv-eth0 is destroyed in the namespace (potentially while
>> tearing it down)
>> 4) Now there's a broken symlink that doesn't make sense in any namespace
>> 5) mv-eth0 can't be created anew
>>
>> It seems that 3-5 didn't happen that way on older kernels. The most
>> recent where it's not persistently broken is 3.16.0-rc7-00007 -
>> 31dab719f. The oldest where I know it's reproducible is
>> 3.17.0-rc4-andres-00135-g35af256.
>
> I've reproduced the problem on another machine where it's perfectly
> reproducible (except being about mv-bond0).
did you mean this is a macvlan which has bond as a real device?
hmm... current implementation of bonding unconditionally
refuses to switch ns due to NETIF_F_NETNS_LOCAL flag afaik,
macvlan steals flags from lowerdev so it should behave the same.
just to clarify: custom patches?
btw, could i ask you to try attached patch?
in short, my initial assumption we don't need check ns
in __netdev_adjacent_dev_insert was incorrect, I do really forgot (at
least) this :(
/* When creating macvlans or macvtaps on top of other macvlans - use
* the real device as the lowerdev.
so we can create broken links playing with macvlan in container.
diff --git a/net/core/dev.c b/net/core/dev.c
index ab9a165..12f496f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4841,7 +4841,9 @@ static int __netdev_adjacent_dev_insert(struct
net_device *dev,
pr_debug("dev_hold for %s, because of link added from %s to %s\n",
adj_dev->name, dev->name, adj_dev->name);
- if (netdev_adjacent_is_neigh_list(dev, dev_list)) {
+ if (netdev_adjacent_is_neigh_list(dev, dev_list) &&
+ net_eq(dev_net(dev),dev_net(adj_dev))) {
+
ret = netdev_adjacent_sysfs_add(dev, adj_dev, dev_list);
if (ret)
goto free_adj;
@@ -4862,7 +4864,8 @@ static int __netdev_adjacent_dev_insert(struct
net_device *dev,
return 0;
remove_symlinks:
- if (netdev_adjacent_is_neigh_list(dev, dev_list))
+ if (netdev_adjacent_is_neigh_list(dev, dev_list) &&
+ net_eq(dev_net(dev),dev_net(adj_dev)))
netdev_adjacent_sysfs_del(dev, adj_dev->name, dev_list);
free_adj:
kfree(adj);
> After reverting only the
> aforementioned 4c75431ac352063 it works again.
> As I said above, I'm not sure whether 4c75431ac352063 is the actual
> culprit, but it certainly made the problem visible. How are these
> upper_$if/lower_$if supposed to behave when the macvlan and the
> underlying device are in differing namespaces?
>
> Greetings,
>
> Andres Freund
--
Best regards.
Alexander Y. Fomichev <git.user@gmail.com>
[-- Attachment #2: netdev_adjacent_dev_insert.patch --]
[-- Type: application/x-download, Size: 924 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next v2] r8169:add support for RTL8168H and RTL8107E
From: Ivan Vecera @ 2014-09-10 9:32 UTC (permalink / raw)
To: Hayes Wang, Hau, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, romieu@fr.zoreil.com
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB252152B@RTITMBSV03.realtek.com.tw>
On 10.9.2014 11:25, Hayes Wang wrote:
> From: Ivan Vecera [mailto:ivecera@redhat.com]
>> Sent: Tuesday, September 09, 2014 8:19 PM
> [...]
>> Thanks Hayes,
>> have you got any idea when do you update them?
>
> If all are fine, I would release them this week.
>
> Best Regards,
> Hayes
>
Great, thanks Hayes.
Ivan
^ permalink raw reply
* Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Ceriel Jacobs @ 2014-09-10 10:07 UTC (permalink / raw)
To: Tom Gundersen, Luis R. Rodriguez
Cc: James Bottomley, One Thousand Gnomes, Takashi Iwai, Kay Sievers,
Oleg Nesterov, Praveen Krishnamoorthy, hare,
Nagalakshmi Nandigama, Wu Zhangjin, Tetsuo Handa,
mpt-fusionlinux.pdl, Tim Gardner, Benjamin Poirier,
Santosh Rastapur, Casey Leedom, Hariprasad S, Pierre Fersing,
Sreekanth Reddy, Arjan van de Ven, Abhijit Mahajan, systemd
In-Reply-To: <CAG-2HqUiUksdT4UyeDsdc1Q74=2BiX2TuzzGh_hoLiO5_DOvXQ@mail.gmail.com>
Tom Gundersen schreef op 10-09-14 om 08:46:
>> >Indeed. What I proposed with a multiplier for the timeout for the
>> >different types of built in commands was deemed complex but saw no
>> >alternatives proposed despite my interest to work on one and
>> >clarifications noted that this was a design regression. Not quite sure
>> >what else I could have done here. I'm interested in learning what the
>> >better approach is for the future as if we want to marry init + kernel
>> >we need a smooth way for us to discuss design without getting worked
>> >up about it, or taking it personal. I really want this to work as I
>> >personally like systemd so far.
> How about this: keep the timeout global, but also introduce a
> (relatively short, say 10 or 15 seconds) timeout after which a warning
> is printed. Even if nothing is actually killed, having workers (be it
> insmod or something else) take longer than a couple of seconds is
> likely a sign that something is seriously off somewhere.
I don't agree with the statement that something is seriously off when it
takes more then 10 to 15 seconds.
When probing only one hard disk drive, then I do agree that something is
seriously off after 10 to 15 seconds.
When probing a SAS bus with one hundred hard disk drives in standby
mode, then I do expect that to take longer then 10 to 15 seconds.
^ permalink raw reply
* [PATCH net] ipv6: clean up anycast when an interface is destroyed
From: Sabrina Dubroca @ 2014-09-10 10:27 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, David Miller
If we try to rmmod the driver for an interface while sockets with
setsockopt(JOIN_ANYCAST) are alive, some refcounts aren't cleaned up
and we get stuck on:
unregister_netdevice: waiting for ens3 to become free. Usage count = 1
If we LEAVE_ANYCAST/close everything before rmmod'ing, there is no
problem.
We need to perform a cleanup similar to the one for multicast in
addrconf_ifdown(how == 1).
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
The problem is also present on a 3.2 and 3.16 kernel, and most likely
everything in between.
include/net/addrconf.h | 1 +
net/ipv6/addrconf.c | 8 +++++---
net/ipv6/anycast.c | 22 ++++++++++++++++++++++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index f679877bb601..ec51e673b4b6 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -204,6 +204,7 @@ void ipv6_sock_ac_close(struct sock *sk);
int ipv6_dev_ac_inc(struct net_device *dev, const struct in6_addr *addr);
int __ipv6_dev_ac_dec(struct inet6_dev *idev, const struct in6_addr *addr);
+void ipv6_ac_destroy_dev(struct inet6_dev *idev);
bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
const struct in6_addr *addr);
bool ipv6_chk_acast_addr_src(struct net *net, struct net_device *dev,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fc1fac2a0528..3342ee64f2e3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3094,11 +3094,13 @@ static int addrconf_ifdown(struct net_device *dev, int how)
write_unlock_bh(&idev->lock);
- /* Step 5: Discard multicast list */
- if (how)
+ /* Step 5: Discard anycast and multicast list */
+ if (how) {
+ ipv6_ac_destroy_dev(idev);
ipv6_mc_destroy_dev(idev);
- else
+ } else {
ipv6_mc_down(idev);
+ }
idev->tstamp = jiffies;
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index ff2de7d9d8e6..a1bf80574bfe 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -351,6 +351,28 @@ static int ipv6_dev_ac_dec(struct net_device *dev, const struct in6_addr *addr)
return __ipv6_dev_ac_dec(idev, addr);
}
+/* Device is being destroyed: clean up */
+void ipv6_ac_destroy_dev(struct inet6_dev *idev)
+{
+ struct ifacaddr6 *aca;
+
+ write_lock_bh(&idev->lock);
+ while ((aca = idev->ac_list) != NULL) {
+ idev->ac_list = aca->aca_next;
+ write_unlock_bh(&idev->lock);
+
+ addrconf_leave_solict(idev, &aca->aca_addr);
+
+ dst_hold(&aca->aca_rt->dst);
+ ip6_del_rt(aca->aca_rt);
+
+ aca_put(aca);
+
+ write_lock_bh(&idev->lock);
+ }
+ write_unlock_bh(&idev->lock);
+}
+
/*
* check if the interface has this anycast address
* called with rcu_read_lock()
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-09-10 10:33 UTC (permalink / raw)
To: John W. Linville
Cc: Paul Bolle, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Oleksij Rempel, Richard Weinberger, Jonathan Bither,
Hauke Mehrtens, ath5k-devel, open,
list@hauke-m.de:NETWORKING DRIVERS, antonynpavlov@gmail.com,
OpenWrt Development List, linux-wireless@vger.kernel.org,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <20140909182734.GJ29412@tuxdriver.com>
2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>:
> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote:
>> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>:
>> > Hi Sergey,
>> >
>> > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote:
>> >> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>:
>> >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote:
>> >> >> Having this conversation every rc1 is getting a bit silly. Could
>> >> >> Jiri
>> >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be
>> >> >> submitted?
>> >> >
>> >> > I waited until rc3. Have you seen any activity on this front? If
>> >> > not,
>> >> > should I resend the patch that removes the code in mainline that
>> >> > depends
>> >> > on ATHEROS_AR231X (ie, AHB bus support)?
>> >> >
>> >> Recent activity always could be found in [1]. Now I finish another one
>> >> round of cleanups and have a plan to fix several things (you can
>> >> always find something that you really want to improve). But if you
>> >> insist I could immediately switch to "send upstream" mode. And seems
>> >> that this would be better approach.
>> >>
>> >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros
>> >
>> > And where can the related PULL requests or patch submissions be found?
>> >
>> I have not sent patches yet, since I thought that it would be easier
>> to cleanup them in openwrt tree and then send them upstream.
>
> That excuse has worn a bit thin. Perhaps Paul should repost his
> removal and you can add a revert to the start of your patch series?
>
As for me, I do not like such flapping, but you have a final say in
this discussion as a maintainer.
--
BR,
Sergey
^ permalink raw reply
* [net PATCH v2 1/1] drivers: net: cpsw: dual_emac: fix reducing of rx descriptor during ifdown
From: Mugunthan V N @ 2014-09-10 11:08 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N
In Dual EMAC, when both interface are up and while doing ifdown with heavy
traffic then skbs already processed by DMA from that slave emac has to be
requeued as still the other interface is up and running.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Changes from initial version:
* fixed warn issue during suspend/resume by adding aditional check on
status before requeueing the skb.
* Added more comments in requeue if statement.
---
drivers/net/ethernet/ti/cpsw.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 999fb72..411232f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -699,6 +699,28 @@ static void cpsw_rx_handler(void *token, int len, int status)
cpsw_dual_emac_src_port_detect(status, priv, ndev, skb);
if (unlikely(status < 0) || unlikely(!netif_running(ndev))) {
+ bool ndev_status = false;
+ struct cpsw_slave *slave = priv->slaves;
+ int n;
+
+ if (priv->data.dual_emac) {
+ /* In dual emac mode check for all interfaces */
+ for (n = priv->data.slaves; n; n--, slave++)
+ if (netif_running(slave->ndev))
+ ndev_status = true;
+ }
+
+ if (ndev_status && (status >= 0)) {
+ /* The packet received is for the interface which
+ * is already down and the other interface is up
+ * and running, intead of freeing which results
+ * in reducing of the number of rx descriptor in
+ * DMA engine, requeue skb back to cpdma.
+ */
+ new_skb = skb;
+ goto requeue;
+ }
+
/* the interface is going down, skbs are purged */
dev_kfree_skb_any(skb);
return;
@@ -717,6 +739,7 @@ static void cpsw_rx_handler(void *token, int len, int status)
new_skb = skb;
}
+requeue:
ret = cpdma_chan_submit(priv->rxch, new_skb, new_skb->data,
skb_tailroom(new_skb), 0);
if (WARN_ON(ret < 0))
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v11 net-next 11/12] net: filter: move eBPF instruction macros
From: Daniel Borkmann @ 2014-09-10 11:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1410325808-3657-12-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
> move instruction macros (like BPF_MOV64_REG or BPF_ALU32_IMM)
> from linux/filter.h into uapi/linux/bpf.h
> so that userspace programs can use them.
>
> verifier testsuite (in later patches) will be using them.
>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
I don't think we need this commit at all. These macros are not really
part of the ABI and we should expose __as less as possible__, otherwise
we won't be able to alter them anymore. Plus, based on your previous
argumentation regarding the header file expose, we also won't be able
to add any new macros anymore since you could run into name collisions.
Anyway, I don't see a reason why a e.g. central user space eBPF library
cannot live with, for example, a private copy of these helper macros or
whatever it wants to define by itself.
I know in classic BPF there's BPF_STMT() and BPF_JUMP() but it's much
less complicated than eBPF and less likely to changes.
^ permalink raw reply
* Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support
From: Jamal Hadi Salim @ 2014-09-10 11:33 UTC (permalink / raw)
To: Santosh Shilimkar, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, sandeep_n-l0cyMroinI0,
Benjamin LaHaise, shrijeet Mukherjee
In-Reply-To: <540F1A9A.1020309-l0cyMroinI0@public.gmane.org>
On 09/09/14 11:19, Santosh Shilimkar wrote:
> All the documentation is open including packet accelerator offload
> in ti.com.
Very nice.
Would you do me a kindness and point to the switch interface
documentation (and other ones on that soc)?
> We got such requests from customers but couldn't
> support it for Linux.
It has been difficult because every chip vendor is trying
to do their own thing. Some have huge (fugly) SDKs in user space
which make it worse. Thats the struggle we are trying to
deal with. Of course none of those vendors want to open
up their specs. You present a nice opportunity to not follow
that path.
> We are also looking for such
> support and any direction are welcome. Your slide
> deck seems to capture the key topics like L2/IPSEC
> offload which we are also interested to hear.
>
The slides list the most popular offloads. But not necessarily
all known offloads.
> Just to be clear, your point was about L2 switch offload
> which the driver don't support at the moment. It might confuse
> others. The driver doesn't implements anything non-standard.
>
If i understood you correctly:
Your initial patches dont intend to expose any offloads - you are just
abstracting this as a NIC. I think that is a legit reason.
However, the problem is you are also exposing the packet processors
and switch offloading in a proprietary way.
For a sample of how L2 basic functions like FDB tables are controlled
within a NIC - take a look at the Intel NICs.
Either that or you hide all the offload interfaces and over time add
them (starting with L2 - NICs with L2 are common).
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox