* Re: 4.9.0-rc8: tg3 dead after resume
From: Billy Shuman @ 2016-12-09 14:29 UTC (permalink / raw)
To: Siva Reddy Kallam; +Cc: Michael Chan, Netdev
In-Reply-To: <CAMet4B6t9neFPcGstZw6ebhFCBQzRsesStXZ8bjSaC5ggcuKxw@mail.gmail.com>
On Thu, Dec 8, 2016 at 4:03 AM, Siva Reddy Kallam
<siva.kallam@broadcom.com> wrote:
> On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman <wshuman3@gmail.com> wrote:
>> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman <wshuman3@gmail.com> wrote:
>>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>>
>>>> In logs I see:
>>>> kernel: tg3 0000:44:00.0: phy probe failed, err -19
>>>> kernel: tg3 0000:44:00.0: Problem fetching invariants of chip, aborting
>>>
>>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>>
>>> If it's a true suspend/resume operation, the driver does not have to
>>> go through probe during resume. Please explain how you do
>>> suspend/resume.
>>>
>>
>> Sorry my previous message was accidentally sent to early.
>>
>> I used systemd (systemctl suspend) to suspend.
>>
> We need more information to proceed further.
> Without suspend, Are you able to use the tg3 port?
Yes the port works fine without suspend.
> Which Broadcom card are you having in laptop?
The nic is a NetXtreme BCM57762 Gigabit Ethernet PCIe in a thunderbolt3 dock.
> Please provide complete tg3 specific logs in dmesg.
>
[ 32.084010] tg3.c:v3.137 (May 11, 2014)
[ 32.124695] tg3 0000:44:00.0 eth0: Tigon3 [partno(BCM957762) rev
57766001] (PCI Express) MAC address 98:e7:f4:8b:13:19
[ 32.124698] tg3 0000:44:00.0 eth0: attached PHY is 57765
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[ 32.124699] tg3 0000:44:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[0] TSOcap[1]
[ 32.124700] tg3 0000:44:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit]
[ 32.219764] tg3 0000:44:00.0 enp68s0: renamed from eth0
[ 36.219245] tg3 0000:44:00.0 enp68s0: Link is up at 1000 Mbps, full duplex
[ 36.219250] tg3 0000:44:00.0 enp68s0: Flow control is on for TX and on for RX
[ 36.219251] tg3 0000:44:00.0 enp68s0: EEE is disabled
after resume
[ 92.292838] tg3 0000:44:00.0 enp68s0: No firmware running
[ 93.521744] tg3 0000:44:00.0: tg3_abort_hw timed out,
TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
[ 106.704655] tg3 0000:44:00.0 enp68s0: Link is down
[ 108.370356] tg3 0000:44:00.0: tg3_abort_hw timed out,
TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
after rmmod, modprobe
[ 570.933636] tg3 0000:44:00.0: tg3_abort_hw timed out,
TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
[ 604.847215] tg3.c:v3.137 (May 11, 2014)
[ 605.010075] tg3 0000:44:00.0: phy probe failed, err -19
[ 605.010077] tg3 0000:44:00.0: Problem fetching invariants of chip, aborting
>>> Did this work before? There has been very few changes to tg3 recently.
>>>
>>
>> This is a new laptop for me, but the same behavior is seen on 4.4.36 and 4.8.12.
>>
>>>>
>>>> rmmod and modprobe does not fix the problem only a reboot resolves the issue.
>>>>
>>>> Billy
^ permalink raw reply
* Re: [PATCHv3 perf/core 3/7] tools lib bpf: Add flags to bpf_create_map()
From: Arnaldo Carvalho de Melo @ 2016-12-09 14:27 UTC (permalink / raw)
To: Wangnan (F); +Cc: Joe Stringer, linux-kernel, ast, daniel, netdev
In-Reply-To: <b2c274c5-5e2c-749f-648e-7664a1daa6c2@huawei.com>
Em Fri, Dec 09, 2016 at 11:36:18AM +0800, Wangnan (F) escreveu:
>
>
> On 2016/12/9 10:46, Joe Stringer wrote:
> > The map_flags argument to bpf_create_map() was previously not exposed.
> > By exposing it, users can access flags such as whether or not to
> > preallocate the map.
> >
> > Signed-off-by: Joe Stringer <joe@ovn.org>
>
> Please mention commit 6c90598174322b8888029e40dd84a4eb01f56afe in
> commit message:
>
> Commit 6c905981743 ("bpf: pre-allocate hash map elements") introduces
> map_flags to bpf_attr for BPF_MAP_CREATE command. Expose this new
> parameter in libbpf.
will do it, thanks.
- Arnaldo
> Acked-by: Wang Nan <wangnan0@huawei.com>
>
> > ---
> > v3: Split from "tools lib bpf: Sync with samples/bpf/libbpf".
> > ---
> > tools/lib/bpf/bpf.c | 3 ++-
> > tools/lib/bpf/bpf.h | 2 +-
> > tools/lib/bpf/libbpf.c | 3 ++-
> > 3 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> > index 89e8e8e5b60e..d0afb26c2e0f 100644
> > --- a/tools/lib/bpf/bpf.c
> > +++ b/tools/lib/bpf/bpf.c
> > @@ -54,7 +54,7 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
> > }
> > int bpf_create_map(enum bpf_map_type map_type, int key_size,
> > - int value_size, int max_entries)
> > + int value_size, int max_entries, __u32 map_flags)
> > {
> > union bpf_attr attr;
> > @@ -64,6 +64,7 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size,
> > attr.key_size = key_size;
> > attr.value_size = value_size;
> > attr.max_entries = max_entries;
> > + attr.map_flags = map_flags;
> > return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
> > }
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index 61130170a6ad..7fcdce16fd62 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -24,7 +24,7 @@
> > #include <linux/bpf.h>
> > int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
> > - int max_entries);
> > + int max_entries, __u32 map_flags);
> > /* Recommend log buffer size */
> > #define BPF_LOG_BUF_SIZE 65536
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 2e974593f3e8..84e6b35da4bd 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -854,7 +854,8 @@ bpf_object__create_maps(struct bpf_object *obj)
> > *pfd = bpf_create_map(def->type,
> > def->key_size,
> > def->value_size,
> > - def->max_entries);
> > + def->max_entries,
> > + 0);
> > if (*pfd < 0) {
> > size_t j;
> > int err = *pfd;
>
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Eric Dumazet @ 2016-12-09 14:24 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Paul Gortmaker, netfilter-devel, David Miller, netdev,
linux-next@vger.kernel.org
In-Reply-To: <20161209102432.GA986@salvia>
On Fri, 2016-12-09 at 11:24 +0100, Pablo Neira Ayuso wrote:
> Hi Paul,
Hi Pablo
Given that bytes/packets counters are modified without cmpxchg64() :
static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
{
struct nft_counter_percpu *this_cpu;
local_bh_disable();
this_cpu = this_cpu_ptr(priv->counter);
u64_stats_update_begin(&this_cpu->syncp);
this_cpu->counter.bytes += pkt->skb->len;
this_cpu->counter.packets++;
u64_stats_update_end(&this_cpu->syncp);
local_bh_enable();
}
It means that the cmpxchg64() used to clear the stats is not good enough.
It does not help to make sure stats are properly cleared.
On 64 bit, the ->syncp is not there, so the nft_counter_reset() might
not see that a bytes or packets counter was modified by another cpu.
CPU 1 CPU 2
LOAD PTR->BYTES into REG_A old = *counter;
REG_A += skb->len;
cmpxchg64(counter, old, 0);
PTR->BYTES = REG_A
It looks that you want a seqcount, even on 64bit arches,
so that CPU 2 can restart its loop, and more importantly you need
to not accumulate the values you read, because they might be old/invalid.
Another way would be to not use cmpxchg64() at all.
Way to expensive in fast path !
The percpu value would never be modified by an other cpu than the owner.
You need a per cpu seqcount, no need to add a syncp per nft percpu counter.
static DEFINE_PERCPU(seqcount_t, nft_pcpu_seq);
static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
{
struct nft_counter_percpu *this_cpu;
seqcount_t *myseq;
local_bh_disable();
this_cpu = this_cpu_ptr(priv->counter);
myseq = this_cpu_ptr(&nft_pcpu_seq);
write_seqcount_begin(myseq);
this_cpu->counter.bytes += pkt->skb->len;
this_cpu->counter.packets++;
write_seqcount_end(myseq);
local_bh_enable();
}
Thanks !
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Tejun Heo @ 2016-12-09 13:27 UTC (permalink / raw)
To: John Stultz
Cc: Andy Lutomirski, Alexei Starovoitov, Andy Lutomirski,
Mickaël Salaün, Daniel Mack, David S. Miller, kafai,
Florian Westphal, Harald Hoyer, Network Development,
Sargun Dhillon, Pablo Neira Ayuso, lkml, Li Zefan,
Jonathan Corbet, open list:CONTROL GROUP (CGROUP),
Android Kernel Team, Rom Lemarchand, Colin Cross
In-Reply-To: <CALAqxLUkqSAEiHE038w+ZGUmhPgj2SpG7BLcPrrtU46VYcO=KA@mail.gmail.com>
Hello, John.
On Thu, Dec 08, 2016 at 09:39:38PM -0800, John Stultz wrote:
> So just to clarify the discussion for my purposes and make sure I
> understood, per-cgroup CAP rules was not desired, and instead we
> should either utilize an existing cap (are there still objections to
> CAP_SYS_RESOURCE? - this isn't clear to me) or create a new one (ie,
> bring back the older CAP_CGROUP_MIGRATE patch).
Let's create a new one. It looks to be a bit too different to share
with an existing one.
> Tejun: Do you have a more finished version of your patch that I should
> add my changes on top of?
Oh, just submit the patch on top of the current for-next. I can queue
mine on top of yours. They are mostly orthogonal.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] net: smsc911x: back out silently on probe deferrals
From: Linus Walleij @ 2016-12-09 13:18 UTC (permalink / raw)
To: netdev, David S . Miller, Steve Glendinning
Cc: Guenter Roeck, Jeremy Linton, Kamlakant Patel, Pavel Fedin,
Linus Walleij
When trying to get a regulator we may get deferred and we see
this noise:
smsc911x 1b800000.ethernet-ebi2 (unnamed net_device) (uninitialized):
couldn't get regulators -517
Then the driver continues anyway. Which means that the regulator
may not be properly retrieved and reference counted, and may be
switched off in case noone else is using it.
Fix this by returning silently on deferred probe and let the
system work it out.
Cc: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/net/ethernet/smsc/smsc911x.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 86b7c04e3738..c492e4ffd9e7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -442,9 +442,16 @@ static int smsc911x_request_resources(struct platform_device *pdev)
ret = regulator_bulk_get(&pdev->dev,
ARRAY_SIZE(pdata->supplies),
pdata->supplies);
- if (ret)
+ if (ret) {
+ /*
+ * Retry on deferrals, else just report the error
+ * and try to continue.
+ */
+ if (ret == -EPROBE_DEFER)
+ return ret;
netdev_err(ndev, "couldn't get regulators %d\n",
ret);
+ }
/* Request optional RESET GPIO */
pdata->reset_gpiod = devm_gpiod_get_optional(&pdev->dev,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
From: Mark Lord @ 2016-12-09 13:05 UTC (permalink / raw)
To: Hayes Wang
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20105C9EE@RTITMBSV03.realtek.com.tw>
On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord <mlord@pobox.com>
>
> I find an issue about autosuspend, and it may result in the same
> problem with you. I don't sure if this is helpful to you, because
> it only occurs when enabling the autosuspend.
Thanks. I am using ASIX adapters now.
I did try the latest 4.9-rc8, and 4.8.12 kernels with the r8152 dongle yesterday,
in hope that perhaps the many EHCI fixes from those kernels might help out.
The dongle was unusable with those newer kernels.
Most of the time it failed with "Get ether addr fail\n" at startup.
On the occasions where it got past that point, it often failed
the DHCP negotiation, but this looks more like a bug elsewhere in
the kernel, possibly racing against initialization of the random
number generators. Adding a 2-second sleep the the r8151 probe
function made this error mostly go away.
Cheers
--
Mark Lord
^ permalink raw reply
* [PATCH] net:ethernet:samsung:initialize cur_rx_qnum
From: Rayagond Kokatanur @ 2016-12-09 12:14 UTC (permalink / raw)
To: siva.kallam, bh74.an, ks.giri, vipul.pandya; +Cc: netdev, Rayagond Kokatanur
This patch initialize the cur_rx_qnum upon occurence of rx interrupt,
without this initialization driver will not work with multiple rx queues configurations.
NOTE: This patch is not tested on actual hw.
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index ea44a24..580a1a4 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1681,6 +1681,7 @@ static irqreturn_t sxgbe_rx_interrupt(int irq, void *dev_id)
struct sxgbe_rx_queue *rxq = (struct sxgbe_rx_queue *)dev_id;
struct sxgbe_priv_data *priv = rxq->priv_ptr;
+ priv->cur_rx_qnum = rxq->queue_no;
/* get the channel status */
status = priv->hw->dma->rx_dma_int_status(priv->ioaddr, rxq->queue_no,
&priv->xstats);
--
1.9.1
^ permalink raw reply related
* Re: netlink: GPF in sock_sndtimeo
From: Richard Guy Briggs @ 2016-12-09 12:12 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, LKML, linux-audit
In-Reply-To: <CACT4Y+ZsOXoQqVE4vhenb9fUJkwAbGL6wUZxGyaT2h7Cncbfog@mail.gmail.com>
On 2016-12-09 12:53, Dmitry Vyukov wrote:
> On Fri, Dec 9, 2016 at 12:48 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2016-12-09 11:49, Dmitry Vyukov wrote:
> >> On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >> > On 2016-11-29 23:52, Richard Guy Briggs wrote:
> >> > I tried a quick compile attempt on the test case (I assume it is a
> >> > socket fuzzer) and get the following compile error:
> >> > cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
> >> > socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
> >> > <command-line>: warning: this is the location of the previous definition
> >> > socket_fuzz.c: In function ‘segv_handler’:
> >> > socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
> >> > socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
> >> > socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
> >> > socket_fuzz.c:89: error: for each function it appears in.)
> >> > socket_fuzz.c: In function ‘loop’:
> >> > socket_fuzz.c:280: warning: unused variable ‘errno0’
> >> > socket_fuzz.c: In function ‘test’:
> >> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
> >> > socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
> >> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
> >>
> >> -std=gnu99 should help
> >> ignore warnings
> >
> > I got a little further, left with "__ATOMIC_RELAXED undeclared", "__ATOMIC_SEQ_CST
> > undeclared" under gcc 4.4.7-16.
> >
> > gcc 4.8.2-15 leaves me with "undefined reference to `clock_gettime'"
>
> add -lrt
Ok, that helped. Thanks!
> > What compiler version do you recommend?
>
> 6.x sounds reasonable
> 4.4 branch is 7.5 years old, surprised that it does not disintegrate
> into dust yet :)
These are under RHEL6... so there are updates to them, but yeah, they are old.
> >> >> - RGB
> >> >
> >> > - RGB
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Kernel Security Engineering, Base Operating Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH V2 21/22] bnxt_re: Add QP event handling
From: Sergei Shtylyov @ 2016-12-09 12:12 UTC (permalink / raw)
To: Selvin Xavier, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Eddie Wai, Devesh Sharma,
Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <1481266096-23331-22-git-send-email-selvin.xavier-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Hello!
On 12/9/2016 9:48 AM, Selvin Xavier wrote:
> Implements callback handler for processing affiliated Async events of a QP.
> This patch also implements the control path command completion handling.
>
> Signed-off-by: Eddie Wai <eddie.wai-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Devesh Sharma <devesh.sharma-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Somnath Kotur <somnath.kotur-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Selvin Xavier <selvin.xavier-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c | 49 ++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c b/drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c
> index 5b71acd..3e6bb3f 100644
> --- a/drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c
> +++ b/drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c
> @@ -246,6 +246,46 @@ static int bnxt_qplib_process_func_event(struct bnxt_qplib_rcfw *rcfw,
> return 0;
> }
>
> +static int bnxt_qplib_process_qp_event(struct bnxt_qplib_rcfw *rcfw,
> + struct creq_qp_event *qp_event)
> +{
> + struct bnxt_qplib_crsq *crsq = &rcfw->crsq;
> + struct bnxt_qplib_hwq *cmdq = &rcfw->cmdq;
> + struct bnxt_qplib_crsqe *crsqe;
> + u16 cbit, cookie, blocked = 0;
> + unsigned long flags;
> + u32 sw_cons;
> +
> + switch (qp_event->event) {
> + case CREQ_QP_EVENT_EVENT_QP_ERROR_NOTIFICATION:
> + break;
> + default:
> + {
> + /* Command Response */
> + spin_lock_irqsave(&cmdq->lock, flags);
> + sw_cons = HWQ_CMP(crsq->cons, crsq);
> + crsqe = &crsq->crsq[sw_cons];
> + crsq->cons++;
> + memcpy(&crsqe->qp_event, qp_event, sizeof(crsqe->qp_event));
> +
> + cookie = le16_to_cpu(crsqe->qp_event.cookie);
> + blocked = cookie & RCFW_CMD_IS_BLOCKING;
> + cookie &= RCFW_MAX_COOKIE_VALUE;
> + cbit = cookie % RCFW_MAX_OUTSTANDING_CMD;
> + if (!test_and_clear_bit(cbit, rcfw->cmdq_bitmap))
> + dev_warn(&rcfw->pdev->dev,
> + "QPLIB: CMD bit %d was not requested", cbit);
> +
> + cmdq->cons += crsqe->req_size;
> + spin_unlock_irqrestore(&cmdq->lock, flags);
> + if (!blocked)
> + wake_up(&rcfw->waitq);
> + break;
> + }
> + }
Hum, strange indentation... Not seeing why you need {} in the *default* at
all...
> + return 0;
> +}
> +
> /* SP - CREQ Completion handlers */
> static void bnxt_qplib_service_creq(unsigned long data)
> {
> @@ -269,6 +309,15 @@ static void bnxt_qplib_service_creq(unsigned long data)
> type = creqe->type & CREQ_BASE_TYPE_MASK;
> switch (type) {
> case CREQ_BASE_TYPE_QP_EVENT:
> + if (!bnxt_qplib_process_qp_event
> + (rcfw, (struct creq_qp_event *)creqe))
> + rcfw->creq_qp_event_processed++;
> + else {
CodingStyle: there should be {} used in all branches if it's used on at
least branch of *if*.
> + dev_warn(&rcfw->pdev->dev, "QPLIB: crsqe with");
> + dev_warn(&rcfw->pdev->dev,
> + "QPLIB: type = 0x%x not handled",
> + type);
> + }
> break;
> case CREQ_BASE_TYPE_FUNC_EVENT:
> if (!bnxt_qplib_process_func_event
MBR, Sergei
--
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
* Re: [PATCH] ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
From: Sergei Shtylyov @ 2016-12-09 12:03 UTC (permalink / raw)
To: Zheng Li, netdev, linux-kernel, davem, kuznet, jmorris, yoshfuji,
kaber
Cc: james.z.li
In-Reply-To: <1481252918-3514-1-git-send-email-lizheng043@gmail.com>
Hello!
On 12/9/2016 6:08 AM, Zheng Li wrote:
> From: zheng li <james.z.li@ericsson.com>
>
> There is an inconsitent conditional judgement in __ip_append_data and
Inconsistent.
> ip_finish_output functions, the variable length in __ip_append_data just
> include the length of applicatoin's payload and udp header, don't include
Application.
> the length of ip header, but in ip_finish_output use
> (skb->len > ip_skb_dst_mtu(skb)) as judgement, and skb->len include the
> length of ip header.
>
> That cuase some particular applicatoin's udp payload whose length is
Causes, application.
> between (MTU - IP Header) and MTU were framented by ip_fragment even
Fragmented.
> though the rst->dev support UFO feature.
>
> Add the length of ip header to length in __ip_append_data to keep
> consistent conditional judgement as ip_finish_output for ip fragment.
>
> Signed-off-by: Zheng Li <james.z.li@ericsson.com>
[...]
MBR, Sergei
^ permalink raw reply
* pull-request: mac80211-next 2016-12-09
From: Johannes Berg @ 2016-12-09 12:00 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Closing net-next caught me by surprise, so I had to rebase a bit,
but these three patches really should go in soon. I'm not sending
them for 4.9 this late though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit f81a8a02bb3b3e882ba6aa580230c13b5be64849:
Merge branch 'mV88e6xxx-interrupt-fixes' (2016-11-20 21:16:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-12-09
for you to fetch changes up to e6f462df9acd2a3295e5d34eb29e2823220cf129:
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts (2016-12-09 12:57:49 +0100)
----------------------------------------------------------------
Three fixes:
* fix a logic bug introduced by a previous cleanup
* fix nl80211 attribute confusing (trying to use
a single attribute for two purposes)
* fix a long-standing BSS leak that happens when an
association attempt is abandoned
----------------------------------------------------------------
Johannes Berg (2):
nl80211: fix logic inversion in start_nan()
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts
Vamsi Krishna (1):
nl80211: Use different attrs for BSSID and random MAC addr in scan req
include/net/cfg80211.h | 11 +++++++++++
include/uapi/linux/nl80211.h | 7 ++++++-
net/mac80211/mlme.c | 21 ++++++++++++---------
net/wireless/core.h | 1 +
net/wireless/mlme.c | 12 ++++++++++++
net/wireless/nl80211.c | 18 ++++++++++++++++--
net/wireless/sme.c | 14 ++++++++++++++
7 files changed, 72 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Dmitry Vyukov @ 2016-12-09 11:53 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: netdev, LKML
In-Reply-To: <20161209114847.GX22655@madcap2.tricolour.ca>
On Fri, Dec 9, 2016 at 12:48 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-12-09 11:49, Dmitry Vyukov wrote:
>> On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2016-11-29 23:52, Richard Guy Briggs wrote:
>> > I tried a quick compile attempt on the test case (I assume it is a
>> > socket fuzzer) and get the following compile error:
>> > cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
>> > socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
>> > <command-line>: warning: this is the location of the previous definition
>> > socket_fuzz.c: In function ‘segv_handler’:
>> > socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
>> > socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
>> > socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
>> > socket_fuzz.c:89: error: for each function it appears in.)
>> > socket_fuzz.c: In function ‘loop’:
>> > socket_fuzz.c:280: warning: unused variable ‘errno0’
>> > socket_fuzz.c: In function ‘test’:
>> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
>> > socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
>> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
>>
>> -std=gnu99 should help
>> ignore warnings
>
> I got a little further, left with "__ATOMIC_RELAXED undeclared", "__ATOMIC_SEQ_CST
> undeclared" under gcc 4.4.7-16.
>
> gcc 4.8.2-15 leaves me with "undefined reference to `clock_gettime'"
add -lrt
> What compiler version do you recommend?
6.x sounds reasonable
4.4 branch is 7.5 years old, surprised that it does not disintegrate
into dust yet :)
>> >> - RGB
>> >
>> > - RGB
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Richard Guy Briggs @ 2016-12-09 11:48 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, LKML
In-Reply-To: <CACT4Y+beWN9jmdTREk3JdEBQ3GRALGDJhy7pYF=wu3HdnNWEog@mail.gmail.com>
On 2016-12-09 11:49, Dmitry Vyukov wrote:
> On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2016-11-29 23:52, Richard Guy Briggs wrote:
> > I tried a quick compile attempt on the test case (I assume it is a
> > socket fuzzer) and get the following compile error:
> > cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
> > socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
> > <command-line>: warning: this is the location of the previous definition
> > socket_fuzz.c: In function ‘segv_handler’:
> > socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
> > socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
> > socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
> > socket_fuzz.c:89: error: for each function it appears in.)
> > socket_fuzz.c: In function ‘loop’:
> > socket_fuzz.c:280: warning: unused variable ‘errno0’
> > socket_fuzz.c: In function ‘test’:
> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
> > socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
>
> -std=gnu99 should help
> ignore warnings
I got a little further, left with "__ATOMIC_RELAXED undeclared", "__ATOMIC_SEQ_CST
undeclared" under gcc 4.4.7-16.
gcc 4.8.2-15 leaves me with "undefined reference to `clock_gettime'"
What compiler version do you recommend?
> >> - RGB
> >
> > - RGB
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [PATCH] uio-hv-generic: store physical addresses instead of virtual
From: Arnd Bergmann @ 2016-12-09 11:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, Arnd Bergmann, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, devel, linux-kernel
gcc warns about the newly added driver when phys_addr_t is wider than
a pointer:
drivers/uio/uio_hv_generic.c: In function 'hv_uio_mmap':
drivers/uio/uio_hv_generic.c:71:17: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
drivers/uio/uio_hv_generic.c: In function 'hv_uio_probe':
drivers/uio/uio_hv_generic.c:140:5: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
= (phys_addr_t)dev->channel->ringbuffer_pages;
drivers/uio/uio_hv_generic.c:147:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.int_page;
drivers/uio/uio_hv_generic.c:153:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.monitor_pages[1];
I can't see why we store a virtual address in a phys_addr_t here,
as the only user of that variable converts it into a physical
address anyway, so this moves the conversion to where it logically
fits according to the types.
Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/uio/uio_hv_generic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index ad3ab5805ad8..50958f167305 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -68,7 +68,7 @@ hv_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
mi = (int)vma->vm_pgoff;
return remap_pfn_range(vma, vma->vm_start,
- virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
+ info->mem[mi].addr >> PAGE_SHIFT,
vma->vm_end - vma->vm_start, vma->vm_page_prot);
}
@@ -137,20 +137,20 @@ hv_uio_probe(struct hv_device *dev,
/* mem resources */
pdata->info.mem[TXRX_RING_MAP].name = "txrx_rings";
pdata->info.mem[TXRX_RING_MAP].addr
- = (phys_addr_t)dev->channel->ringbuffer_pages;
+ = virt_to_phys(dev->channel->ringbuffer_pages);
pdata->info.mem[TXRX_RING_MAP].size
= dev->channel->ringbuffer_pagecount * PAGE_SIZE;
pdata->info.mem[TXRX_RING_MAP].memtype = UIO_MEM_LOGICAL;
pdata->info.mem[INT_PAGE_MAP].name = "int_page";
pdata->info.mem[INT_PAGE_MAP].addr =
- (phys_addr_t)vmbus_connection.int_page;
+ virt_to_phys(vmbus_connection.int_page);
pdata->info.mem[INT_PAGE_MAP].size = PAGE_SIZE;
pdata->info.mem[INT_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
pdata->info.mem[MON_PAGE_MAP].name = "monitor_pages";
pdata->info.mem[MON_PAGE_MAP].addr =
- (phys_addr_t)vmbus_connection.monitor_pages[1];
+ virt_to_phys(vmbus_connection.monitor_pages[1]);
pdata->info.mem[MON_PAGE_MAP].size = PAGE_SIZE;
pdata->info.mem[MON_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
--
2.9.0
^ permalink raw reply related
* Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-09 11:29 UTC (permalink / raw)
To: davem
Cc: Giuseppe CAVALLARO, lars.persson, rabin.vincent, netdev,
andy.shevchenko, CARLOS.PALMINHA
Dear David Miller,
These past 2 weeks we have been discussing the right way to go in terms of
Synopsys QoS support in the kernel.
The approach that raised more supporters was:
a) Test /stmicro/stmmac driver in a reference hardware prototyping platform (QoS
IPK) [Status: In Progress | 90% finished]
b) Merge the necessary features from AXIS’ synopsys based qos driver to the
/stmicro/stmmac
[Status: In Queue]
c) Rename /stmicro/stmmac driver to synopsys/ and re-factor the driver if necessary
[Status: In Queue]
d) Add QoS features incrementally to the new synopsys/ driver
[Status: In Queue]
This approach has the green light from AXIS and STMicro maintainers (Lars and
Peppe).
I would like to know if you support this plan.
Best Regards,
Joao
^ permalink raw reply
* Re: Misalignment, MIPS, and ip_hdr(skb)->version
From: Jiri Benc @ 2016-12-09 11:26 UTC (permalink / raw)
To: Daniel Kahn Gillmor
Cc: linux-mips, Netdev, LKML, Hannes Frederic Sowa,
WireGuard mailing list
In-Reply-To: <87vauvhwdu.fsf@alice.fifthhorseman.net>
On Wed, 07 Dec 2016 23:34:21 -0500, Daniel Kahn Gillmor wrote:
> fwiw, i'm not convinced that "most protocols of the IETF follow this
> mantra". we've had multiple discussions in different protocol groups
> about shaving or bloating by a few bytes here or there in different
> protocols, and i don't think anyone has brought up memory alignment as
> an argument in any of the discussions i've followed.
Which is sad. One would expect that this would be well understood for
decades already.
Jiri
^ permalink raw reply
* Re: [PATCH V2 22/22] bnxt_re: Add bnxt_re driver build support
From: kbuild test robot @ 2016-12-09 11:21 UTC (permalink / raw)
To: Selvin Xavier; +Cc: kbuild-all, dledford, linux-rdma, netdev, Selvin Xavier
In-Reply-To: <1481266096-23331-23-git-send-email-selvin.xavier@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 7977 bytes --]
Hi Selvin,
[auto build test ERROR on rdma/master]
[also build test ERROR on v4.9-rc8 next-20161208]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Selvin-Xavier/Broadcom-RoCE-Driver-bnxt_re/20161209-154823
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c: In function 'bnxt_qplib_creq_irq':
>> drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c:359:2: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
prefetch(&creq_ptr[CREQ_PG(sw_cons)][CREQ_IDX(sw_cons)]);
^~~~~~~~
cc1: some warnings being treated as errors
--
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_service_nq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:145:29: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
bnxt_qplib_arm_cq_enable((struct bnxt_qplib_cq *)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:147:29: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
if (!nq->cqn_handler(nq, (struct bnxt_qplib_cq *)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_nq_irq':
>> drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:182:2: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
prefetch(&nq_ptr[NQE_PG(sw_cons)][NQE_IDX(sw_cons)]);
^~~~~~~~
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_create_qp':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:484:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
psn_search = (unsigned long long int)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_destroy_qp':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1071:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
__clean_cq(qp->scq, (u64)qp);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1073:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
__clean_cq(qp->rcq, (u64)qp);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function '__flush_sq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1630:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function '__flush_rq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1664:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_req':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1688:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1720:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_rc':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1782:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1794:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_ud':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1836:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1847:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_raweth_qp1':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1893:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1902:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_terminal':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1964:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:2005:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
cc1: some warnings being treated as errors
vim +/prefetch +359 drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c
bd53aa95 Selvin Xavier 2016-12-08 343 CREQ_DB_REARM(rcfw->creq_bar_reg_iomem, raw_cons,
bd53aa95 Selvin Xavier 2016-12-08 344 creq->max_elements);
bd53aa95 Selvin Xavier 2016-12-08 345 }
bd53aa95 Selvin Xavier 2016-12-08 346 spin_unlock_irqrestore(&creq->lock, flags);
bd53aa95 Selvin Xavier 2016-12-08 347 }
bd53aa95 Selvin Xavier 2016-12-08 348
bd53aa95 Selvin Xavier 2016-12-08 349 static irqreturn_t bnxt_qplib_creq_irq(int irq, void *dev_instance)
bd53aa95 Selvin Xavier 2016-12-08 350 {
bd53aa95 Selvin Xavier 2016-12-08 351 struct bnxt_qplib_rcfw *rcfw = dev_instance;
bd53aa95 Selvin Xavier 2016-12-08 352 struct bnxt_qplib_hwq *creq = &rcfw->creq;
bd53aa95 Selvin Xavier 2016-12-08 353 struct creq_base **creq_ptr;
bd53aa95 Selvin Xavier 2016-12-08 354 u32 sw_cons;
bd53aa95 Selvin Xavier 2016-12-08 355
bd53aa95 Selvin Xavier 2016-12-08 356 /* Prefetch the CREQ element */
bd53aa95 Selvin Xavier 2016-12-08 357 sw_cons = HWQ_CMP(creq->cons, creq);
bd53aa95 Selvin Xavier 2016-12-08 358 creq_ptr = (struct creq_base **)rcfw->creq.pbl_ptr;
bd53aa95 Selvin Xavier 2016-12-08 @359 prefetch(&creq_ptr[CREQ_PG(sw_cons)][CREQ_IDX(sw_cons)]);
bd53aa95 Selvin Xavier 2016-12-08 360
bd53aa95 Selvin Xavier 2016-12-08 361 tasklet_schedule(&rcfw->worker);
bd53aa95 Selvin Xavier 2016-12-08 362
bd53aa95 Selvin Xavier 2016-12-08 363 return IRQ_HANDLED;
bd53aa95 Selvin Xavier 2016-12-08 364 }
bd53aa95 Selvin Xavier 2016-12-08 365
bd53aa95 Selvin Xavier 2016-12-08 366 /* RCFW */
bd53aa95 Selvin Xavier 2016-12-08 367 int bnxt_qplib_deinit_rcfw(struct bnxt_qplib_rcfw *rcfw)
:::::: The code at line 359 was first introduced by commit
:::::: bd53aa95a8998c3192837b1d2d6c6e795adf3276 bnxt_re: Enabling RoCE control path
:::::: TO: Selvin Xavier <selvin.xavier@broadcom.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47317 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Pavel Machek @ 2016-12-09 11:21 UTC (permalink / raw)
To: Francois Romieu
Cc: Lino Sanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <20161208231943.GA13102@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On Fri 2016-12-09 00:19:43, Francois Romieu wrote:
> Lino Sanfilippo <LinoSanfilippo@gmx.de> :
> [...]
> > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if
> > this is caused by that locking scheme (in a way I have not figured out yet)
> > or if it is a different issue.
>
> stmmac_tx_err races with stmmac_xmit.
Umm, yes, that looks real.
And that means that removing tx_lock will not be completely trivial
:-(. Lino, any ideas there?
netif_tx_lock_irqsave() would help, but afaict that one does not
exist.
Plus, does someone know how to trigger the status == tx_hard_error? I
tried powering down the switch, but that did not do it.
Thanks, Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] net: socket: preferred __aligned(size) for control buffer
From: Sergei Shtylyov @ 2016-12-09 11:14 UTC (permalink / raw)
To: kushwaha.a, davem; +Cc: netdev, akkushwaha9896
In-Reply-To: <1481201513-20783-1-git-send-email-kushwaha.a@samsung.com>
Hello!
On 12/8/2016 3:51 PM, kushwaha.a@samsung.com wrote:
> From: Amit Kushwaha <kushwaha.a@samsung.com>
>
> This patch cleanup checkpatch.pl warning
> WARNING: __aligned(size) is preferred over __attribute__((aligned(size)))
>
> Signed-off-by: Amit Kushwaha <kushwaha.a@samsung.com>
> ---
> net/socket.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/socket.c b/net/socket.c
> index e631894..5835383 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1,3 +1,4 @@
> +
Why?
> /*
> * NET An implementation of the SOCKET network access protocol.
> *
[...]
MBR, Sergei
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Richard Guy Briggs @ 2016-12-09 11:01 UTC (permalink / raw)
To: Cong Wang
Cc: linux-audit, Paul Moore, Dmitry Vyukov, David Miller,
Johannes Berg, Florian Westphal, Eric Dumazet, Herbert Xu, netdev,
LKML, syzkaller
In-Reply-To: <CAM_iQpWRe0tDk=wvXONG7hamH3EtE0nJuAOF1kVKJgdpMvz2DA@mail.gmail.com>
On 2016-12-08 22:57, Cong Wang wrote:
> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > I also tried to extend Cong Wang's idea to attempt to proactively respond to a
> > NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking error
> > stack dump using mutex_lock(&audit_cmd_mutex) in the notifier callback.
> > Eliminating the lock since the sock is dead anways eliminates the error.
> >
> > Is it safe? I'll resubmit if this looks remotely sane. Meanwhile I'll try to
> > get the test case to compile.
>
> It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and 'audit_pid'
> are updated as a whole and race between audit_receive_msg() and
> NETLINK_URELEASE.
This is what I expected and why I originally added the mutex lock in the
callback... The dumps I got were bare with no wrapper identifying the
process context or specific error, so I'm at a bit of a loss how to
solve this (without thinking more about it) other than instinctively
removing the mutex.
Another approach might be to look at consolidating the three into one
identifier or derive the other two from one, or serialize their access.
> > @@ -1167,10 +1190,14 @@ static void __net_exit audit_net_exit(struct net *net)
> > {
> > struct audit_net *aunet = net_generic(net, audit_net_id);
> > struct sock *sock = aunet->nlsk;
> > +
> > + mutex_lock(&audit_cmd_mutex);
> > if (sock == audit_sock) {
> > audit_pid = 0;
> > + audit_nlk_portid = 0;
> > audit_sock = NULL;
> > }
> > + mutex_unlock(&audit_cmd_mutex);
>
> If you decide to use NETLINK_URELEASE notifier, the above piece is no
> longer needed, the net_exit path simply releases a refcnt.
Good point. It would have already killed it off. So this piece is
arguably too late anyways.
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [PATCH] bnxt_re: fix itnull.cocci warnings
From: Julia Lawall @ 2016-12-09 10:54 UTC (permalink / raw)
To: Selvin Xavier; +Cc: dledford, linux-rdma, netdev, kbuild-all
list_for_each_entry iterator variable cannot be NULL.
Generated by: scripts/coccinelle/iterators/itnull.cocci
CC: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
url:
https://github.com/0day-ci/linux/commits/Selvin-Xavier/Broadcom-RoCE-Driver-bnxt_re/20161209-154823
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
master
I received some other warnings as well. Not sure if they have been passed
along already:
>> drivers/infiniband/hw/bnxtre/bnxt_re_ib_verbs.c:2455:4-14: code aligned
with following code on line 2456
--
>> drivers/infiniband/hw/bnxtre/bnxt_re_main.c:1047:2-20: code aligned
with following code on line 1048
drivers/infiniband/hw/bnxtre/bnxt_re_main.c:1188:3-43: code aligned
with following code on line 1190
--
>> drivers/infiniband/hw/bnxtre/bnxt_re_main.c:834:6-8: ERROR: iterator
variable bound on line 832 cannot be NULL
^ permalink raw reply
* Re: stmmac driver...
From: Niklas Cassel @ 2016-12-09 10:50 UTC (permalink / raw)
To: Jie Deng
Cc: David Miller, alexandre.torgue, peppe.cavallaro, netdev,
CARLOS.PALMINHA, Joao.Pinto
In-Reply-To: <59b37368-8670-659a-c257-034f73a83136@synopsys.com>
Hello Jie Deng
In your cover letter you wrote
dwc-eth-xxx.x
The DWC ethernet core layer (DWC ECL). This layer contains codes
can be shared by different DWC series ethernet cores
Does this mean that code in dwc-eth-xxx.x is common to all
the different Synopsys IPs, GMAC, XGMAC and XLGMAC ?
Regards,
Niklas
On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng <Jie.Deng1@synopsys.com> wrote:
>
>
> On 2016/12/8 23:25, David Miller wrote:
>> From: Alexandre Torgue <alexandre.torgue@st.com>
>> Date: Thu, 8 Dec 2016 14:55:04 +0100
>>
>>> Maybe I forget some series. Do you have others in mind ?
>> Please see the thread titled:
>>
>> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>>
>> which seems to be discussing consolidation of various drivers
>> for the same IP core, of which stmmac is one.
>>
>> I personally am against any change of the driver name and
>> things like this, and wish the people doing that work would
>> simply contribute to making whatever changes they need directly
>> to the stmmac driver.
>>
>> You really need to voice your opinion when major changes are being
>> proposed for the driver you maintain.
>>
> Hi David and Alex,
>
> XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has
> several versions.
>
> GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20...
> XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11...
> XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP.
>
> Regards,
> Jie
>
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Dmitry Vyukov @ 2016-12-09 10:49 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Cong Wang, linux-audit, pmoore, David Miller, Johannes Berg,
Florian Westphal, Eric Dumazet, Herbert Xu, netdev, LKML,
syzkaller
In-Reply-To: <20161209060248.GT22655@madcap2.tricolour.ca>
On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-11-29 23:52, Richard Guy Briggs wrote:
>> On 2016-11-29 15:13, Cong Wang wrote:
>> > On Tue, Nov 29, 2016 at 8:48 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > > On 2016-11-26 17:11, Cong Wang wrote:
>> > >> It is racy on audit_sock, especially on the netns exit path.
>> > >
>> > > I think that is the only place it is racy. The other places audit_sock
>> > > is set is when the socket failure has just triggered a reset.
>> > >
>> > > Is there a notifier callback for failed or reaped sockets?
>> >
>> > Is NETLINK_URELEASE event what you are looking for?
>>
>> Possibly, yes. Thanks, I'll have a look.
>
> I tried a quick compile attempt on the test case (I assume it is a
> socket fuzzer) and get the following compile error:
> cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
> socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
> <command-line>: warning: this is the location of the previous definition
> socket_fuzz.c: In function ‘segv_handler’:
> socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
> socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
> socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
> socket_fuzz.c:89: error: for each function it appears in.)
> socket_fuzz.c: In function ‘loop’:
> socket_fuzz.c:280: warning: unused variable ‘errno0’
> socket_fuzz.c: In function ‘test’:
> socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
> socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
> socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
-std=gnu99 should help
ignore warnings
> I also tried to extend Cong Wang's idea to attempt to proactively respond to a
> NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking error
> stack dump using mutex_lock(&audit_cmd_mutex) in the notifier callback.
> Eliminating the lock since the sock is dead anways eliminates the error.
>
> Is it safe? I'll resubmit if this looks remotely sane. Meanwhile I'll try to
> get the test case to compile.
>
> This is being tracked as https://github.com/linux-audit/audit-kernel/issues/30
>
> Subject: [PATCH] audit: proactively reset audit_sock on matching NETLINK_URELEASE
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..91d222d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -423,6 +423,7 @@ static void kauditd_send_skb(struct sk_buff *skb)
> snprintf(s, sizeof(s), "audit_pid=%d reset", audit_pid);
> audit_log_lost(s);
> audit_pid = 0;
> + audit_nlk_portid = 0;
> audit_sock = NULL;
> } else {
> pr_warn("re-scheduling(#%d) write to audit_pid=%d\n",
> @@ -1143,6 +1144,28 @@ static int audit_bind(struct net *net, int group)
> return 0;
> }
>
> +static int audit_sock_netlink_notify(struct notifier_block *nb,
> + unsigned long event,
> + void *_notify)
> +{
> + struct netlink_notify *notify = _notify;
> + struct audit_net *aunet = net_generic(notify->net, audit_net_id);
> +
> + if (event == NETLINK_URELEASE && notify->protocol == NETLINK_AUDIT) {
> + if (audit_nlk_portid == notify->portid &&
> + audit_sock == aunet->nlsk) {
> + audit_pid = 0;
> + audit_nlk_portid = 0;
> + audit_sock = NULL;
> + }
> + }
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block audit_netlink_notifier = {
> + .notifier_call = audit_sock_netlink_notify,
> +};
> +
> static int __net_init audit_net_init(struct net *net)
> {
> struct netlink_kernel_cfg cfg = {
> @@ -1167,10 +1190,14 @@ static void __net_exit audit_net_exit(struct net *net)
> {
> struct audit_net *aunet = net_generic(net, audit_net_id);
> struct sock *sock = aunet->nlsk;
> +
> + mutex_lock(&audit_cmd_mutex);
> if (sock == audit_sock) {
> audit_pid = 0;
> + audit_nlk_portid = 0;
> audit_sock = NULL;
> }
> + mutex_unlock(&audit_cmd_mutex);
>
> RCU_INIT_POINTER(aunet->nlsk, NULL);
> synchronize_net();
> @@ -1202,6 +1229,7 @@ static int __init audit_init(void)
> audit_enabled = audit_default;
> audit_ever_enabled |= !!audit_default;
>
> + netlink_register_notifier(&audit_netlink_notifier);
> audit_log(NULL, GFP_KERNEL, AUDIT_KERNEL, "initialized");
>
> for (i = 0; i < AUDIT_INODE_BUCKETS; i++)
> --
> 1.7.1
>
>
>> - RGB
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Pablo Neira Ayuso @ 2016-12-09 10:24 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netfilter-devel, David Miller, netdev, linux-next@vger.kernel.org
In-Reply-To: <CAP=VYLp-ZBFjR1W9=V_vyPYAi1=Yub3ugq6D8hkoLigcPaaxFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]
Hi Paul,
On Thu, Dec 08, 2016 at 07:40:14PM -0500, Paul Gortmaker wrote:
> On Wed, Dec 7, 2016 at 4:52 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> > dump-and-reset of the stateful object. This also comes with add support
> > for atomic dump and reset for counter and quota objects.
>
> This triggered a new build failure in linux-next on parisc-32, which a
> hands-off bisect
> run lists as resulting from this:
>
> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
> 43da04a593d8b2626f1cf4b56efe9402f6b53652 is the first bad commit
> commit 43da04a593d8b2626f1cf4b56efe9402f6b53652
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon Nov 28 00:05:44 2016 +0100
>
> netfilter: nf_tables: atomic dump and reset for stateful objects
>
> This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> dump-and-reset of the stateful object. This also comes with add support
> for atomic dump and reset for counter and quota objects.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> :040000 040000 6cd4554f69247e5c837db52342f26888beda1623
> 5908aca93c89e7922336546c3753bfcf2aceefba M include
> :040000 040000 f25d5831eb30972436bd198c5bb237a0cb0b4856
> 4ee5751c8de02bb5a8dcaadb2a2df7986d90f8e9 M net
> bisect run success
>
> Guessing this is more an issue with parisc than it is with netfilter, but I
> figured I'd mention it anyway.
I'm planning to submit this patch to parisc, I'm attaching it to this
email.
[-- Attachment #2: 0001-parisc-export-symbol-__cmpxchg_u64.patch --]
[-- Type: text/x-diff, Size: 1313 bytes --]
>From c9d320ac0be2a32a7b2bfad398be549865088ecf Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 8 Dec 2016 22:55:33 +0100
Subject: [PATCH] parisc: export symbol __cmpxchg_u64()
kbuild test robot reports:
>> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
Commit 43da04a593d8 ("netfilter: nf_tables: atomic dump and reset for
stateful objects") introduces the first client of cmpxchg64() from
modules.
Patch 54b668009076 ("parisc: Add native high-resolution sched_clock()
implementation") removed __cmpxchg_u64() dependency on CONFIG_64BIT.
So, let's fix this problem by exporting this symbol unconditionally.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
arch/parisc/kernel/parisc_ksyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index 3cad8aadc69e..cfa704548cf3 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -40,8 +40,8 @@ EXPORT_SYMBOL(__atomic_hash);
#endif
#ifdef CONFIG_64BIT
EXPORT_SYMBOL(__xchg64);
-EXPORT_SYMBOL(__cmpxchg_u64);
#endif
+EXPORT_SYMBOL(__cmpxchg_u64);
#include <asm/uaccess.h>
EXPORT_SYMBOL(lclear_user);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3 0/4] vsock: cancel connect packets when failing to connect
From: Stefan Hajnoczi @ 2016-12-09 10:18 UTC (permalink / raw)
To: Peng Tao
Cc: Stefan Hajnoczi, netdev, Jorgen Hansen, David Miller, kvm,
virtualization
In-Reply-To: <1481217156-7160-1-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Fri, Dec 09, 2016 at 01:12:32AM +0800, Peng Tao wrote:
> Currently, if a connect call fails on a signal or timeout (e.g., guest is still
> in the process of starting up), we'll just return to caller and leave the connect
> packet queued and they are sent even though the connection is considered a failure,
> which can confuse applications with unwanted false connect attempt.
>
> The patchset enables vsock (both host and guest) to cancel queued packets when
> a connect attempt is considered to fail.
>
> v3 changelog:
> - define cancel_pkt callback in struct vsock_transport rather than struct virtio_transport
> - rename virtio_vsock_pkt->vsk to virtio_vsock_pkt->cancel_token
> v2 changelog:
> - fix queued_replies counting and resume tx/rx when necessary
>
>
> Peng Tao (4):
> vsock: track pkt owner vsock
> vhost-vsock: add pkt cancel capability
> vsock: add pkt cancel capability
> vsock: cancel packets when failing to connect
>
> drivers/vhost/vsock.c | 41 ++++++++++++++++++++++++++++++++
> include/linux/virtio_vsock.h | 2 ++
> include/net/af_vsock.h | 3 +++
> net/vmw_vsock/af_vsock.c | 14 +++++++++++
> net/vmw_vsock/virtio_transport.c | 42 +++++++++++++++++++++++++++++++++
> net/vmw_vsock/virtio_transport_common.c | 7 ++++++
> 6 files changed, 109 insertions(+)
I'm happy although I pointed out two unnecessary (void*) casts.
Please wait for Jorgen to go happy on the af_vsock.c changes before
applying.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ 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