* Re: [PATCH net] qed: fix old-style function definition
From: Johannes Thumshirn @ 2016-12-16 8:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Yuval Mintz, Ariel Elior, everest-linux-l2, Arun Easi,
Hannes Reinecke, David S. Miller, netdev, linux-kernel
In-Reply-To: <20161216084808.1815139-1-arnd@arndb.de>
On Fri, Dec 16, 2016 at 09:47:41AM +0100, Arnd Bergmann wrote:
> The newly added file causes a harmless warning, with "make W=1":
>
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c: In function 'qed_get_iscsi_ops':
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c:1268:29: warning: old-style function definition [-Wold-style-definition]
>
> This makes it a proper prototype.
>
> Fixes: fc831825f99e ("qed: Add support for hardware offloaded iSCSI.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Looks good,
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH mac80211-next] rfkill: hide unused goto label
From: Johannes Berg @ 2016-12-16 9:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, João Paulo Rechi Vita,
Michał Kępień, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20161216084425.1692828-1-arnd@arndb.de>
On Fri, 2016-12-16 at 09:44 +0100, Arnd Bergmann wrote:
> A cleanup introduced a harmless warning in some configurations:
>
> net/rfkill/core.c: In function 'rfkill_init':
> net/rfkill/core.c:1350:1: warning: label 'error_input' defined but
> not used [-Wunused-label]
>
> This adds another #ifdef around the label to match that around the
> caller.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: batman-adv: Treat NET_XMIT_CN as transmit successfully
From: Sven Eckelmann @ 2016-12-16 9:19 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: mareklindner-rVWd3aGhH2z5bpWLKbzFeg,
netdev-u79uwXL29TY76Z2rM5mHXA, a, fgao-KlmEoCYek3zQT0dZR+AlfA,
gfree.wind-Re5JQEeQqe8AvxtiuMwx3w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1479740432-3721-1-git-send-email-fgao-KlmEoCYek3zQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Montag, 21. November 2016 23:00:32 CET fgao-KlmEoCYek3zQT0dZR+AlfA@public.gmane.org wrote:
> From: Gao Feng <gfree.wind-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> The tc could return NET_XMIT_CN as one congestion notification, but
> it does not mean the packet is lost. Other modules like ipvlan,
> macvlan, and others treat NET_XMIT_CN as success too.
>
> So batman-adv should add the NET_XMIT_CN check.
>
> Signed-off-by: Gao Feng <gfree.wind-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> net/batman-adv/distributed-arp-table.c | 2 +-
> net/batman-adv/fragmentation.c | 2 +-
> net/batman-adv/routing.c | 10 +++++-----
> net/batman-adv/soft-interface.c | 2 +-
> net/batman-adv/tp_meter.c | 2 +-
> 5 files changed, 9 insertions(+), 9 deletions(-)
David marked your patches as "derefered" after "under review" and did not
apply them directly. Also Florian Westphal didn't continue the discussion
about the direction you should choose.
The patches were therefore queued up in the in batman-adv
671630d6aad0..eab7617142d2. They will be submitted later(tm) in a pull
request to David.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net 2/3] cpsw/netcp: davinci_cpdma: sanitize inter-module API
From: Arnd Bergmann @ 2016-12-16 9:19 UTC (permalink / raw)
To: Mugunthan V N
Cc: Arnd Bergmann, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Uwe Kleine-König, linux-omap, netdev,
linux-kernel
In-Reply-To: <20161216092017.2560717-1-arnd@arndb.de>
The davinci_cpdma module is a helper library that is used by the
actual device drivers and does nothing by itself, so all its API
functions need to be exported.
Four new functions were added recently without an export, so now
we get a build error:
ERROR: "cpdma_chan_set_weight" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_chan_get_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_chan_get_min_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_chan_set_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
This exports those symbols. After taking a closer look, I found two
more global functions in this file that are not exported and not used
anywhere, so they can obviously be removed. There is also one function
that is only used internally in this module, and should be 'static'.
Fixes: 8f32b90981dc ("net: ethernet: ti: davinci_cpdma: add set rate for a channel")
Fixes: 0fc6432cc78d ("net: ethernet: ti: davinci_cpdma: add weight function for channels")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 59 ++++++++++-----------------------
drivers/net/ethernet/ti/davinci_cpdma.h | 4 ---
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 36518fc5c7cc..b9d40f0cdf6c 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -628,6 +628,23 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
}
EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);
+static int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->state != CPDMA_STATE_ACTIVE) {
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return -EINVAL;
+ }
+
+ dma_reg_write(chan->ctlr, enable ? chan->int_set : chan->int_clear,
+ chan->mask);
+ spin_unlock_irqrestore(&chan->lock, flags);
+
+ return 0;
+}
+
int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
{
unsigned long flags;
@@ -1274,46 +1291,4 @@ int cpdma_chan_stop(struct cpdma_chan *chan)
}
EXPORT_SYMBOL_GPL(cpdma_chan_stop);
-int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&chan->lock, flags);
- if (chan->state != CPDMA_STATE_ACTIVE) {
- spin_unlock_irqrestore(&chan->lock, flags);
- return -EINVAL;
- }
-
- dma_reg_write(chan->ctlr, enable ? chan->int_set : chan->int_clear,
- chan->mask);
- spin_unlock_irqrestore(&chan->lock, flags);
-
- return 0;
-}
-
-int cpdma_control_get(struct cpdma_ctlr *ctlr, int control)
-{
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(&ctlr->lock, flags);
- ret = _cpdma_control_get(ctlr, control);
- spin_unlock_irqrestore(&ctlr->lock, flags);
-
- return ret;
-}
-
-int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value)
-{
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(&ctlr->lock, flags);
- ret = _cpdma_control_set(ctlr, control, value);
- spin_unlock_irqrestore(&ctlr->lock, flags);
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(cpdma_control_set);
-
MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
index 4a167db2abab..36d0a09a3d44 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -87,7 +87,6 @@ int cpdma_chan_process(struct cpdma_chan *chan, int quota);
int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value);
-int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
u32 cpdma_ctrl_rxchs_state(struct cpdma_ctlr *ctlr);
u32 cpdma_ctrl_txchs_state(struct cpdma_ctlr *ctlr);
bool cpdma_check_free_tx_desc(struct cpdma_chan *chan);
@@ -111,7 +110,4 @@ enum cpdma_control {
CPDMA_RX_BUFFER_OFFSET, /* read-write */
};
-int cpdma_control_get(struct cpdma_ctlr *ctlr, int control);
-int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value);
-
#endif
--
2.9.0
^ permalink raw reply related
* [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers
From: Arnd Bergmann @ 2016-12-16 9:19 UTC (permalink / raw)
To: David S. Miller
Cc: Arnd Bergmann, Grygorii Strashko, Thomas Gleixner, John Stultz,
Uwe Kleine-König, WingMan Kwok, Nicolas Pitre, netdev,
linux-kernel
With posix timers having become optional, we get a build error with
the cpts time sync option of the CPSW driver:
drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts':
drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of function 'ptp_classify_raw';did you mean 'ptp_classifier_init'? [-Werror=implicit-function-declaration]
It really makes no sense to build this driver if we can't use PTP,
so it's better to go back to 'select PTP_1588_CLOCK' but instead
add a dependency on POSIX_TIMERS.
Fixes: baa73d9e478f ("posix-timers: Make them configurable")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ti/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 296c8efd0038..366e29ff8605 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -76,7 +76,8 @@ config TI_CPSW
config TI_CPTS
tristate "TI Common Platform Time Sync (CPTS) Support"
depends on TI_CPSW || TI_KEYSTONE_NETCP
- imply PTP_1588_CLOCK
+ depends on POSIX_TIMERS
+ select PTP_1588_CLOCK
---help---
This driver supports the Common Platform Time Sync unit of
the CPSW Ethernet Switch and Keystone 2 1g/10g Switch Subsystem.
--
2.9.0
^ permalink raw reply related
* [PATCH net 3/3] cpsw/netcp: work around reverse cpts dependency
From: Arnd Bergmann @ 2016-12-16 9:19 UTC (permalink / raw)
To: David S. Miller
Cc: Arnd Bergmann, Grygorii Strashko, Thomas Gleixner, Nicolas Pitre,
Uwe Kleine-König, WingMan Kwok, netdev, linux-kernel
In-Reply-To: <20161216092017.2560717-1-arnd@arndb.de>
The dependency is reversed: cpsw and netcp call into cpts,
but cpts depends on the other two in Kconfig. This can lead
to cpts being a loadable module and its callers built-in:
drivers/net/ethernet/ti/cpsw.o: In function `cpsw_remove':
cpsw.c:(.text.cpsw_remove+0xd0): undefined reference to `cpts_release'
drivers/net/ethernet/ti/cpsw.o: In function `cpsw_rx_handler':
cpsw.c:(.text.cpsw_rx_handler+0x2dc): undefined reference to `cpts_rx_timestamp'
drivers/net/ethernet/ti/cpsw.o: In function `cpsw_tx_handler':
cpsw.c:(.text.cpsw_tx_handler+0x7c): undefined reference to `cpts_tx_timestamp'
drivers/net/ethernet/ti/cpsw.o: In function `cpsw_ndo_stop':
As a workaround, I'm introducing another Kconfig symbol to
control the compilation of cpts, while making the actual
module controlled by a silent symbol that is =y when necessary.
Fixes: 6246168b4a38 ("net: ethernet: ti: netcp: add support of cpts")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ti/Kconfig | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 366e29ff8605..c114efcd1575 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -73,8 +73,8 @@ config TI_CPSW
To compile this driver as a module, choose M here: the module
will be called cpsw.
-config TI_CPTS
- tristate "TI Common Platform Time Sync (CPTS) Support"
+config TI_CPTS_ENABLE
+ bool "TI Common Platform Time Sync (CPTS) Support"
depends on TI_CPSW || TI_KEYSTONE_NETCP
depends on POSIX_TIMERS
select PTP_1588_CLOCK
@@ -84,6 +84,12 @@ config TI_CPTS
The unit can time stamp PTP UDP/IPv4 and Layer 2 packets, and the
driver offers a PTP Hardware Clock.
+config TI_CPTS
+ tristate
+ depends on TI_CPTS_ENABLE
+ default y if TI_CPSW=y || TI_KEYSTONE_NETCP=y
+ default m
+
config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_CPSW_ALE
--
2.9.0
^ permalink raw reply related
* Re: [PATCH net 2/3] cpsw/netcp: davinci_cpdma: sanitize inter-module API
From: Ivan Khoronzhuk @ 2016-12-16 9:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mugunthan V N, Grygorii Strashko, David S. Miller,
Uwe Kleine-König, linux-omap, netdev, linux-kernel
In-Reply-To: <20161216092017.2560717-2-arnd@arndb.de>
On Fri, Dec 16, 2016 at 10:19:58AM +0100, Arnd Bergmann wrote:
> The davinci_cpdma module is a helper library that is used by the
> actual device drivers and does nothing by itself, so all its API
> functions need to be exported.
>
> Four new functions were added recently without an export, so now
> we get a build error:
>
> ERROR: "cpdma_chan_set_weight" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_chan_get_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_chan_get_min_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_chan_set_rate" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
/\
||
A patch correcting this has been applied.
(397c5ad153f0ea62023accb67b3d2b07e5039948)
>
> This exports those symbols. After taking a closer look, I found two
> more global functions in this file that are not exported and not used
> anywhere, so they can obviously be removed. There is also one function
> that is only used internally in this module, and should be 'static'.
>
> Fixes: 8f32b90981dc ("net: ethernet: ti: davinci_cpdma: add set rate for a channel")
> Fixes: 0fc6432cc78d ("net: ethernet: ti: davinci_cpdma: add weight function for channels")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/ti/davinci_cpdma.c | 59 ++++++++++-----------------------
> drivers/net/ethernet/ti/davinci_cpdma.h | 4 ---
> 2 files changed, 17 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
> index 36518fc5c7cc..b9d40f0cdf6c 100644
> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
> @@ -628,6 +628,23 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
> }
> EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);
>
> +static int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&chan->lock, flags);
> + if (chan->state != CPDMA_STATE_ACTIVE) {
> + spin_unlock_irqrestore(&chan->lock, flags);
> + return -EINVAL;
> + }
> +
> + dma_reg_write(chan->ctlr, enable ? chan->int_set : chan->int_clear,
> + chan->mask);
> + spin_unlock_irqrestore(&chan->lock, flags);
> +
> + return 0;
> +}
> +
> int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
> {
> unsigned long flags;
> @@ -1274,46 +1291,4 @@ int cpdma_chan_stop(struct cpdma_chan *chan)
> }
> EXPORT_SYMBOL_GPL(cpdma_chan_stop);
>
> -int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable)
> -{
> - unsigned long flags;
> -
> - spin_lock_irqsave(&chan->lock, flags);
> - if (chan->state != CPDMA_STATE_ACTIVE) {
> - spin_unlock_irqrestore(&chan->lock, flags);
> - return -EINVAL;
> - }
> -
> - dma_reg_write(chan->ctlr, enable ? chan->int_set : chan->int_clear,
> - chan->mask);
> - spin_unlock_irqrestore(&chan->lock, flags);
> -
> - return 0;
> -}
> -
> -int cpdma_control_get(struct cpdma_ctlr *ctlr, int control)
> -{
> - unsigned long flags;
> - int ret;
> -
> - spin_lock_irqsave(&ctlr->lock, flags);
> - ret = _cpdma_control_get(ctlr, control);
> - spin_unlock_irqrestore(&ctlr->lock, flags);
> -
> - return ret;
> -}
> -
> -int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value)
> -{
> - unsigned long flags;
> - int ret;
> -
> - spin_lock_irqsave(&ctlr->lock, flags);
> - ret = _cpdma_control_set(ctlr, control, value);
> - spin_unlock_irqrestore(&ctlr->lock, flags);
> -
> - return ret;
> -}
> -EXPORT_SYMBOL_GPL(cpdma_control_set);
> -
> MODULE_LICENSE("GPL");
> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
> index 4a167db2abab..36d0a09a3d44 100644
> --- a/drivers/net/ethernet/ti/davinci_cpdma.h
> +++ b/drivers/net/ethernet/ti/davinci_cpdma.h
> @@ -87,7 +87,6 @@ int cpdma_chan_process(struct cpdma_chan *chan, int quota);
>
> int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
> void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr, u32 value);
> -int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
> u32 cpdma_ctrl_rxchs_state(struct cpdma_ctlr *ctlr);
> u32 cpdma_ctrl_txchs_state(struct cpdma_ctlr *ctlr);
> bool cpdma_check_free_tx_desc(struct cpdma_chan *chan);
> @@ -111,7 +110,4 @@ enum cpdma_control {
> CPDMA_RX_BUFFER_OFFSET, /* read-write */
> };
>
> -int cpdma_control_get(struct cpdma_ctlr *ctlr, int control);
> -int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value);
> -
> #endif
> --
> 2.9.0
>
^ permalink raw reply
* RE: [PATCH v5 3/4] secure_seq: use SipHash in place of MD5
From: David Laight @ 2016-12-16 9:59 UTC (permalink / raw)
To: 'Jason A. Donenfeld', Netdev,
kernel-hardening@lists.openwall.com, LKML,
linux-crypto@vger.kernel.org, Ted Tso, Hannes Frederic Sowa,
Linus Torvalds, Eric Biggers, Tom Herbert, George Spelvin,
Vegard Nossum, ak@linux.intel.com, davem@davemloft.net,
luto@amacapital.net
In-Reply-To: <20161215203003.31989-4-Jason@zx2c4.com>
From: Jason A. Donenfeld
> Sent: 15 December 2016 20:30
> This gives a clear speed and security improvement. Siphash is both
> faster and is more solid crypto than the aging MD5.
>
> Rather than manually filling MD5 buffers, for IPv6, we simply create
> a layout by a simple anonymous struct, for which gcc generates
> rather efficient code. For IPv4, we pass the values directly to the
> short input convenience functions.
...
> diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
> index 88a8e429fc3e..c80583bf3213 100644
...
> + const struct {
> + struct in6_addr saddr;
> + struct in6_addr daddr;
> + __be16 sport;
> + __be16 dport;
> + u32 padding;
> + } __aligned(SIPHASH_ALIGNMENT) combined = {
> + .saddr = *(struct in6_addr *)saddr,
> + .daddr = *(struct in6_addr *)daddr,
> + .sport = sport,
> + .dport = dport
> + };
I think you should explicitly initialise the 'padding'.
It can do no harm and makes it obvious that it is necessary.
You are still putting over-aligned data on stack.
You only need to align it to the alignment of u64 (not the size of u64).
If an on-stack item has a stronger alignment requirement than the stack
the gcc has to generate two stack frames for the function.
If you assign to each field (instead of using initialisers) then you
can get the alignment by making the first member an anonymous union
of in6_addr and u64.
Oh - and wait a bit longer between revisions.
David
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: John Crispin @ 2016-12-16 9:31 UTC (permalink / raw)
To: Volodymyr Bendiuga, Vivien Didelot
Cc: Florian Fainelli, Andrew Lunn, Volodymyr Bendiuga, netdev,
Volodymyr Bendiuga
In-Reply-To: <CABHmqqCOYMPA-Py7Uu4gsQ=s8CrQd-tT4-Db+j8eJH9=2s4L2g@mail.gmail.com>
On 16/12/2016 10:24, Volodymyr Bendiuga wrote:
> Hi all,
>
> Does this mean we all agree on implementing caching
> mechanism in net/dsa layer? If yes, then I can start
> working on it immediately.
>
> Regards,
> Volodymyr
i think that the brcm approach is better as at least on QCA you can also
read auto learned values from the table which would get broken by a
caching mechanism. filtering inside the dump function or the code
calling the dump function seams a lot simpler and lightweight to me.
John
>
> On Thu, Dec 15, 2016 at 6:50 PM, Vivien Didelot
> <vivien.didelot@savoirfairelinux.com
> <mailto:vivien.didelot@savoirfairelinux.com>> wrote:
>
> Florian Fainelli <f.fainelli@gmail.com
> <mailto:f.fainelli@gmail.com>> writes:
>
> >> In all cases *if caching is really needed*, I think it won't hurt to do
> >> it in DSA core even if a switch support FDB dump operations on a
> >> per-port basis, as Andrew mentioned.
> >
> > Agreed, and there does not appear to be any need to new dsa_switch_ops
> > operations to be introduced?
>
> Nope.
>
>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Andrew Lunn @ 2016-12-16 10:08 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: Vivien Didelot, Florian Fainelli, Volodymyr Bendiuga, netdev,
Volodymyr Bendiuga, John Crispin
In-Reply-To: <CABHmqqCOYMPA-Py7Uu4gsQ=s8CrQd-tT4-Db+j8eJH9=2s4L2g@mail.gmail.com>
On Fri, Dec 16, 2016 at 10:24:28AM +0100, Volodymyr Bendiuga wrote:
> Hi all,
>
> Does this mean we all agree on implementing caching
> mechanism in net/dsa layer? If yes, then I can start
> working on it immediately.
Volodymyr
Could you provide us with your test script, which adds multicast MAC
addresses to ports. I would like to do some profiling with it.
Thanks
Andrew
^ permalink raw reply
* Re: [PULL] virtio, vhost: new device, fixes, speedups
From: Paolo Bonzini @ 2016-12-16 10:12 UTC (permalink / raw)
To: Linus Torvalds, Michael S. Tsirkin
Cc: Network Development, arend.vanspriel, Linux Kernel Mailing List,
KVM list, virtualization
In-Reply-To: <CA+55aFxwG=jj6=2fKjNkHCOnbKr-mNvNucbA=CSdPvb4kzW3FA@mail.gmail.com>
On 16/12/2016 03:20, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 3:05 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
>
> Pulled, but I wonder...
>
>> Documentation/translations/zh_CN/sparse.txt | 7 +-
>> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
>> drivers/crypto/virtio/virtio_crypto_common.h | 128 +++++
> [...]
>
> what are you generating these diffstats with? Because they are pretty bogus..
>
> The end result is correct:
>
>> 86 files changed, 2106 insertions(+), 280 deletions(-)
>
> but the file order in the diffstat is completely random, which makes
> it very hard to compare with what I get. It also makes it hard to see
> what you changed, because it's not alphabetical like it should be
> (strictly speaking the git pathname ordering isnt' really
> alphabetical, since the '/' sorts as the NUL character, but close
> enough).
>
> I can't see the logic to the re-ordering of the lines, so I'm
> intrigued how you even generated it.
Looks like a diff.orderFile that places .h and .txt first, then .c, then
Makefile. I've seen others propose it.
Paolo
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-16 10:26 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Luis R. Rodriguez
In-Reply-To: <76365770-f5ba-9565-3fca-710518f64d81-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 3594 bytes --]
On Thursday 15 December 2016 21:12:47 Arend Van Spriel wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
> > On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> >> (Adding Luis because he has been working on request_firmware()
> >> lately)
> >>
> >> Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>>>> So no, there is no argument against... request_firmware() in
> >>>>> fallback mode with userspace helper is by design blocking and
> >>>>> waiting for userspace. But waiting for some change in DTS in
> >>>>> kernel is just nonsense.
> >>>>
> >>>> I would just mark the wlan device with status = "disabled" and
> >>>> enable it in the overlay together with adding the NVS & MAC
> >>>> info.
> >>>
> >>> So if you think that this solution make sense, we can wait what
> >>> net wireless maintainers say about it...
> >>>
> >>> For me it looks like that solution can be:
> >>>
> >>> extending request_firmware() to use only userspace helper
> >>
> >> I haven't followed the discussion very closely but this is my
> >> preference what drivers should do:
> >>
> >> 1) First the driver should do try to get the calibration data and
> >> mac
> >>
> >> address from the device tree.
> >
> > Ok, but there is no (dynamic, device specific) data in DTS for
> > N900. So 1) is noop.
>
> Uhm. What do you mean? You can propose a patch to the DT bindings [1]
> to get it in there and create your N900 DTB or am I missing
> something here. Are there hardware restrictions that do not allow
> you to boot with your own DTB.
What is [1]?
N900's bootloader does not support DTB and it does not pass any DTB. It
boots kernel in ATAGs mode. What we are doing is appending DTB compiled
from kernel sources to end of zImage.
But that appended DTB cannot contains device specific nodes (e.g.
calibration data for device) as zImage is there for any N900 device, not
just only one.
> >> 2) If they are not in DT the driver should retrieve the
> >> calibration data
> >>
> >> with request_firmware(). BUT with an option for user space
> >> to implement that with a helper script so that the data
> >> can be created dynamically, which I believe openwrt does
> >> with ath10k calibration data right now.
> >
> > Currently there is flag for request_firmware() that it should
> > fallback to user helper if direct VFS access not find needed
> > firmware.
> >
> > But this flag is not suitable as /lib/firmware already provides
> > default (not device specific) calibration data.
> >
> > So I would suggest to add another flag/function which will primary
> > use user helper.
>
> I recall Luis saying that user-mode helper (fallback) should be
> discouraged, because there is no assurance that there is a user-mode
> helper so you might just be pissing in the wind. The idea was to have
> a dedicated API call that explicitly does the request towards
> user-space.
>
> By the way, are we talking here about wl1251 device or driver as you
> also mentioned wl12xx? I did not read the entire thread.
Yes, we are talking about wl1251 device, which is in Nokia N900 and
wl1251.ko and wl1251_spi.ko drivers.
I mentioned wl12xx as it already uses similar approach with mac address
via request_firmware(). And as those drivers are very similar plus from
one manufactor and in same kernel folder I mentioned similar API for
consistency...
--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-16 10:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Arend Van Spriel, Tom Gundersen, Daniel Wagner, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <CAB=NE6VHF+U7DzapENvLMKtN4Dgi9J0qMoeUJ8o4vSwc2-rRFQ@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 8476 bytes --]
On Friday 16 December 2016 03:03:19 Luis R. Rodriguez wrote:
> On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
>
> <arend.vanspriel@broadcom.com> wrote:
> > On 15-12-2016 16:33, Pali Rohár wrote:
> >> On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@codeaurora.org>
> >> wrote:
> >>> (Adding Luis because he has been working on request_firmware()
> >>> lately)
> >>>
> >>> Pali Rohár <pali.rohar@gmail.com> writes:
> >>>>>> So no, there is no argument against... request_firmware() in
> >>>>>> fallback mode with userspace helper is by design blocking and
> >>>>>> waiting for userspace. But waiting for some change in DTS in
> >>>>>> kernel is just nonsense.
> >>>>>
> >>>>> I would just mark the wlan device with status = "disabled" and
> >>>>> enable it in the overlay together with adding the NVS & MAC
> >>>>> info.
> >>>>
> >>>> So if you think that this solution make sense, we can wait what
> >>>> net wireless maintainers say about it...
> >>>>
> >>>> For me it looks like that solution can be:
> >>>>
> >>>> extending request_firmware() to use only userspace helper
> >>>
> >>> I haven't followed the discussion very closely but this is my
> >>> preference what drivers should do:
> >>>
> >>> 1) First the driver should do try to get the calibration data and
> >>> mac
> >>>
> >>> address from the device tree.
> >>
> >> Ok, but there is no (dynamic, device specific) data in DTS for
> >> N900. So 1) is noop.
> >
> > Uhm. What do you mean? You can propose a patch to the DT bindings
> > [1] to get it in there and create your N900 DTB or am I missing
> > something here. Are there hardware restrictions that do not allow
> > you to boot with your own DTB.
> >
> >>> 2) If they are not in DT the driver should retrieve the
> >>> calibration data
> >>>
> >>> with request_firmware(). BUT with an option for user space
> >>> to implement that with a helper script so that the data
> >>> can be created dynamically, which I believe openwrt does
> >>> with ath10k calibration data right now.
> >>
> >> Currently there is flag for request_firmware() that it should
> >> fallback to user helper if direct VFS access not find needed
> >> firmware.
> >>
> >> But this flag is not suitable as /lib/firmware already provides
> >> default (not device specific) calibration data.
> >>
> >> So I would suggest to add another flag/function which will primary
> >> use user helper.
> >
> > I recall Luis saying that user-mode helper (fallback) should be
> > discouraged, because there is no assurance that there is a
> > user-mode helper so you might just be pissing in the wind.
>
> There's tons of issues with the current status quo of the so called
> "firmware usermode helper". To start off with its a complete
> misnomer, the kernel's usermode helper infrastructure is implemented
> in lib/kmod.c and it provides an API to help call out to userspace
> some helper for you. That's the real kernel usermode helper. In so
> far as the firmware_class.c driver is concerned -- it only makes use
> of the kernel user mode helper as an option if you have
> CONFIG_UEVENT_HELPER_PATH set to help address kobject uevents. Most
> distributions do not use this, and back in the day systemd udev, and
> prior to that hotplug used to process firmware kobject uevents.
> systemd udev is long gone. Gone. This kobject uevents really are a
> "fallback mechanism" for firmware only -- if cached firmware,
> built-in firmware, or direct filesystem lookup fails. These each are
> their own beast. Finally kobject uevents are only one of the
> fallback
> mechanisms, "custom fallback mechanisms" are the other option and its
> what you and others seem to describe to want for these sorts of
> custom things.
>
> There are issues with the existing request_firmware() API in that
> everyone and their mother keeps extending it with stupid small API
> extensions to do yet-another-tweak, and then having to go and change
> tons of drivers. Or a new API call added for just one custom knob.
> Naturally this is all plain dumb, so yet-another-API call or new
> argument is not going to help us. We don't have "flags" persi in this
> API, that was one issue with the design of the API, but there are
> much more. The entire change in mechanism of "firmware fallback
> mechanism" depending on which kernel config options you have is
> another. Its a big web of gum put together. All this needs to end.
>
> I've recently proposed a new patch to first help with understanding
> each of the individual items I've listed above with as much new
> information as is possible. I myself need to re-read it to just keep
> tabs on what the hell is going on at times. After this I have a new
> API proposal which I've been working on for a long time now which
> adds an extensible API with only 2 calls: sync, async, and lets us
> modify attributes through a parameters struct. This is what we
> should use in the future for further extensions.
>
> For the new API a solution for "fallback mechanisms" should be clean
> though and I am looking to stay as far as possible from the existing
> mess. A solution to help both the old API and new API is possible for
> the "fallback mechanism" though -- but for that I can only refer you
> at this point to some of Daniel Wagner and Tom Gunderson's firmwared
> deamon prospect. It should help pave the way for a clean solution and
> help address other stupid issues.
>
> I'll note -- the "custom fallback mechanism", part of the old API is
> just a terrible idea for many reasons. I've documented issues in my
> documentation revamp, I suggest to read that, refer to this thread:
>
> https://lkml.kernel.org/r/20161213030828.17820-4-mcgrof@kernel.org
>
> > The idea was to have a
> > dedicated API call that explicitly does the request towards
> > user-space.
>
> In so far as this driver example that was mentioned in this thread my
> recommendation is to use the default existing MAC address /
> calibration data on /lib/firmware/ and then use another request to
> help override for the custom thing. The only issue of course is that
> the timeout for the custom thing is 60 seconds, but if your platforms
> are controlled -- just reduce this to 1 second or so given that udev
> is long gone and it would seem you'd only use a custom fw request to
> depend on. You could also wrap this thing into a kconfig option for
> now, and have the filename specified, if empty then no custom request
> is sent. If set then you have it request it.
>
> Please note the other patches in my series for the custom fallback
> though. We have only 2 users upstream -- and from recent discussions
> it would seem it might be possible to address what you need with
> firmwared in a clean way without this custom old fallback crap thing.
> Johannes at least has a similar requirement and is convinced a
> "custom" thing can be done without even adding an extra custom
> kobject uevent attribute as from what I recall he hinted, drivers
> have no business to be involved in this. If you do end up using the
> custom fallback mechanism be sure to add super crystal clear
> documentation for it (see my other patches for the declarer for this
> documentation). Since we have only 2 drivers using this custom thing
> its hard to get folks to commit to writing the docs, write it now
> and be sure you think of the future as well.
>
> Oh also the "custom firmware fallback" was also broken on recent
> kernels for many kernel revisions, it just did not work until
> recently a fix which went in, so your users wills need this fix
> cherry picked. Hey I tell you, the custom fw thing was a terrible
> incarnation. Only 2 drivers use it. There are good reasons to not
> like it (be sure to read the suspend issue I documented).
>
> > By the way, are we talking here about wl1251 device or driver as
> > you also mentioned wl12xx? I did not read the entire thread.
>
> Luis
Hi Luis! wl1251 already uses request_firmware for loading calibration
data from VFS. And because /lib/firmware/ contains preinstalled default
calibration data it uses it -- which is wrong as wireless has bad
quality.
In my setup I'm going to use udev with firmware loading support
(probably fork eudev), so it should be systemd-independent.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH v5 2/4] siphash: add Nu{32,64} helpers
From: David Laight @ 2016-12-16 10:39 UTC (permalink / raw)
To: 'Jason A. Donenfeld', Netdev,
kernel-hardening@lists.openwall.com, LKML,
linux-crypto@vger.kernel.org, Ted Tso, Hannes Frederic Sowa,
Linus Torvalds, Eric Biggers, Tom Herbert, George Spelvin,
Vegard Nossum, ak@linux.intel.com, davem@davemloft.net,
luto@amacapital.net
In-Reply-To: <20161215203003.31989-3-Jason@zx2c4.com>
From: Jason A. Donenfeld
> Sent: 15 December 2016 20:30
> These restore parity with the jhash interface by providing high
> performance helpers for common input sizes.
...
> +#define PREAMBLE(len) \
> + u64 v0 = 0x736f6d6570736575ULL; \
> + u64 v1 = 0x646f72616e646f6dULL; \
> + u64 v2 = 0x6c7967656e657261ULL; \
> + u64 v3 = 0x7465646279746573ULL; \
> + u64 b = ((u64)len) << 56; \
> + v3 ^= key[1]; \
> + v2 ^= key[0]; \
> + v1 ^= key[1]; \
> + v0 ^= key[0];
Isn't that equivalent to:
v0 = key[0];
v1 = key[1];
v2 = key[0] ^ (0x736f6d6570736575ULL ^ 0x646f72616e646f6dULL);
v3 = key[1] ^ (0x646f72616e646f6dULL ^ 0x7465646279746573ULL);
Those constants also look like ASCII strings.
What cryptographic analysis has been done on the values?
David
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-16 10:40 UTC (permalink / raw)
To: Daniel Wagner
Cc: Luis R. Rodriguez, Arend Van Spriel, Tom Gundersen, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <07be7fc8-6c7f-6e03-379d-fa781b248259@monom.org>
[-- Attachment #1: Type: Text/Plain, Size: 2061 bytes --]
On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> > For the new API a solution for "fallback mechanisms" should be
> > clean though and I am looking to stay as far as possible from the
> > existing mess. A solution to help both the old API and new API is
> > possible for the "fallback mechanism" though -- but for that I can
> > only refer you at this point to some of Daniel Wagner and Tom
> > Gunderson's firmwared deamon prospect. It should help pave the way
> > for a clean solution and help address other stupid issues.
>
> The firmwared project is hosted here
>
> https://github.com/teg/firmwared
>
> As Luis pointed out, firmwared relies on
> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
I know. But it does not mean that I cannot enable this option at kernel
compile time.
Bigger problem is that currently request_firmware() first try to load
firmware directly from VFS and after that (if fails) fallback to user
helper.
So I would need to extend kernel firmware code with new function (or
flag) to not use VFS and try only user mode helper.
> I
> don't see any reason why firmwared should not also support loading
> calibration data. If we find a sound way to do this.
It can, but why should I use another daemon for firmware loading as
non-systemd version of udev (and eudev fork) support firmware loading?
I think I stay with udev/eudev.
> As you can see from the commit history it is a pretty young project
> and more ore less reanimation of the old udev firmware loader
> feature. We are getting int into shape, adding integration tests
> etc.
>
> The main motivation for this project is the get movement back in
> stuck discussion on the firmware loader API. Luis was very busy
> writing up all the details on the current situation and purely from
> the amount of documentation need to describe the API you can tell
> something is awry.
>
> Thanks,
> Daniel
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* (unknown),
From: системы администратор @ 2016-12-16 10:25 UTC (permalink / raw)
внимания;
аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже:
имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:
Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен!
Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2016
Почты технической поддержки ©2016
спасибо
системы администратор
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Andrew Lunn @ 2016-12-16 11:01 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: Vivien Didelot, Florian Fainelli, Volodymyr Bendiuga, netdev,
Volodymyr Bendiuga, John Crispin
In-Reply-To: <CABHmqqAQddcQZqVBi7gTjR40cHx6+aQebmsY3BwJgeEbLsX5Yw@mail.gmail.com>
On Fri, Dec 16, 2016 at 11:26:01AM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
>
> I don't have any script right now, the code I have is a part of
> the OS, but I could write simple C program which represents
> what we are doing with mc entries and send it to you for profiling.
It would be nice to have a benchmark test we can use to test out
ideas.
Please try to make the code flexible. The slave interface names on my
boards are probably not the same as on your. Also, the number of ports
may differ.
Thanks
Andrew
^ permalink raw reply
* pull-request: mac80211 2016-12-16
From: Johannes Berg @ 2016-12-16 12:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Since you seem to be updating net, I thought I'd send you a few fixes.
These aren't really all that important though, so if you want to let
them wait for a bit I can live with that.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:
Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-12-16
for you to fetch changes up to a17d93ff3a950fefaea40e4a4bf3669b9137c533:
mac80211: fix legacy and invalid rx-rate report (2016-12-15 10:54:48 +0100)
----------------------------------------------------------------
Three fixes:
* avoid a WARN_ON() when trying to use WEP with AP_VLANs
* ensure enough headroom on mesh forwarding packets
* don't report unknown/invalid rates to userspace
----------------------------------------------------------------
Ben Greear (1):
mac80211: fix legacy and invalid rx-rate report
Cedric Izoard (1):
mac80211: Ensure enough headroom when forwarding mesh pkt
Johannes Berg (1):
mac80211: don't call drv_set_default_unicast_key() for VLANs
net/mac80211/key.c | 3 ++-
net/mac80211/rx.c | 2 +-
net/mac80211/sta_info.c | 14 ++++++++------
3 files changed, 11 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 12:39 UTC (permalink / raw)
To: Jean-Philippe Aumasson
Cc: George Spelvin, Andi Kleen, David Miller, David Laight,
Eric Biggers, Hannes Frederic Sowa, kernel-hardening,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Tom Herbert, Linus Torvalds, Theodore Ts'o, vegard.nossum,
Daniel J . Bernstein
In-Reply-To: <CAGiyFdd6_LVzUUfFcaqMyub1c2WPvWUzAQDCH+Aza-_t6mvmXg@mail.gmail.com>
Hey JP,
On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson
<jeanphilippe.aumasson@gmail.com> wrote:
> Here's a tentative HalfSipHash:
> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c
>
> Haven't computed the cycle count nor measured its speed.
This is incredible. Really. Wow!
I'll integrate this into my patchset and will write up some
documentation about when one should be used over the other.
Thanks again. Quite exciting.
Jason
^ permalink raw reply
* [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths
From: Colin King @ 2016-12-16 12:50 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
A qed_spq_entry entry is allocated by qed_sp_init_request but is not
kfree'd if an error occurs, causing a memory leak. Fix this by
kfree'ing it and also setting *pp_ent to NULL to be safe.
Found with static analysis by CoverityScan, CIDs 1389468-1389470
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
index a39ef2e..273a6bb 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
@@ -55,8 +55,10 @@ int qed_sp_init_request(struct qed_hwfn *p_hwfn,
break;
case QED_SPQ_MODE_BLOCK:
- if (!p_data->p_comp_data)
- return -EINVAL;
+ if (!p_data->p_comp_data) {
+ rc = -EINVAL;
+ goto err;
+ }
p_ent->comp_cb.cookie = p_data->p_comp_data->cookie;
break;
@@ -71,7 +73,8 @@ int qed_sp_init_request(struct qed_hwfn *p_hwfn,
default:
DP_NOTICE(p_hwfn, "Unknown SPQE completion mode %d\n",
p_ent->comp_mode);
- return -EINVAL;
+ rc = -EINVAL;
+ goto err;
}
DP_VERBOSE(p_hwfn, QED_MSG_SPQ,
@@ -85,6 +88,11 @@ int qed_sp_init_request(struct qed_hwfn *p_hwfn,
memset(&p_ent->ramrod, 0, sizeof(p_ent->ramrod));
return 0;
+err:
+ kfree(*pp_ent);
+ *pp_ent = NULL;
+
+ return rc;
}
static enum tunnel_clss qed_tunn_get_clss_type(u8 type)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jean-Philippe Aumasson @ 2016-12-16 13:22 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: George Spelvin, Andi Kleen, David Miller, David Laight,
Eric Biggers, Hannes Frederic Sowa, kernel-hardening,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Tom Herbert, Linus Torvalds, Theodore Ts'o, vegard.nossum,
Daniel J . Bernstein
In-Reply-To: <CAHmME9pjoAsoct1sVDpFFuqaqutv9X7DGJ5OBQXRAS57KFimUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
It needs some basic security review, which I'll try do next week (check for
security margin, optimality of rotation counts, etc.). But after a lot of
experience with this kind of construction (BLAKE, SipHash, NORX), I'm
confident it will be safe as it is.
On Fri, Dec 16, 2016 at 1:44 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hey JP,
>
> On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson
> <jeanphilippe.aumasson@gmail.com> wrote:
> > Here's a tentative HalfSipHash:
> > https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c
> >
> > Haven't computed the cycle count nor measured its speed.
>
> This is incredible. Really. Wow!
>
> I'll integrate this into my patchset and will write up some
> documentation about when one should be used over the other.
>
> Thanks again. Quite exciting.
>
> Jason
>
[-- Attachment #2: Type: text/html, Size: 1706 bytes --]
^ permalink raw reply
* [PATCH 3/3] net: fec: Fix typo in error msg and comment
From: Peter Meerwald-Stadler @ 2016-12-16 13:23 UTC (permalink / raw)
To: netdev; +Cc: Peter Meerwald-Stadler, Fugang Duan, trivial
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Fugang Duan <fugang.duan@nxp.com>
Cc: trivial@kernel.org
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 38160c2..250b790 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2001,7 +2001,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
mii_speed--;
if (mii_speed > 63) {
dev_err(&pdev->dev,
- "fec clock (%lu) to fast to get right mii speed\n",
+ "fec clock (%lu) too fast to get right mii speed\n",
clk_get_rate(fep->clk_ipg));
err = -EINVAL;
goto err_out;
@@ -2950,7 +2950,7 @@ static void set_multicast_list(struct net_device *ndev)
}
/* only upper 6 bits (FEC_HASH_BITS) are used
- * which point to specific bit in he hash registers
+ * which point to specific bit in the hash registers
*/
hash = (crc >> (32 - FEC_HASH_BITS)) & 0x3f;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] net: wan: Use dma_pool_zalloc
From: Souptick Joarder @ 2016-12-16 13:55 UTC (permalink / raw)
To: Joe Perches; +Cc: Krzysztof Hałasa, netdev, Rameshwar Sahu
In-Reply-To: <1481868649.29291.85.camel@perches.com>
On Fri, Dec 16, 2016 at 11:40 AM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2016-12-16 at 11:33 +0530, Souptick Joarder wrote:
>> On Thu, Dec 15, 2016 at 10:18 PM, Joe Perches <joe@perches.com> wrote:
>> > On Thu, 2016-12-15 at 10:41 +0530, Souptick Joarder wrote:
>> > > On Mon, Dec 12, 2016 at 10:12 AM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
>> > > > On Fri, Dec 9, 2016 at 6:33 PM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>> > > > > Souptick Joarder <jrdr.linux@gmail.com> writes:
>> > > > >
>> > > > > > We should use dma_pool_zalloc instead of dma_pool_alloc/memset
>> >
>> > []
>> > > > > > diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
>> >
>> > []
>> > > > > > @@ -976,10 +976,9 @@ static int init_hdlc_queues(struct port *port)
>> > > > > > return -ENOMEM;
>> > > > > > }
>> > > > > >
>> > > > > > - if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL,
>> > > > > > - &port->desc_tab_phys)))
>> > > > > > + if (!(port->desc_tab = dma_pool_zalloc(dma_pool, GFP_KERNEL,
>> > > > > > + &port->desc_tab_phys)))
>> > > > > > return -ENOMEM;
>> > > > > > - memset(port->desc_tab, 0, POOL_ALLOC_SIZE);
>> > > > > > memset(port->rx_buff_tab, 0, sizeof(port->rx_buff_tab)); /* tables */
>> > > > > > memset(port->tx_buff_tab, 0, sizeof(port->tx_buff_tab));
>> > > > >
>> > > > > This look fine, feel free to send it to the netdev mailing list for
>> > > > > inclusion.
>> > > >
>> > > > Including netdev mailing list based as requested.
>> > > > > Acked-by: Krzysztof Halasa <khalasa@piap.pl>
>> >
>> > []
>> > > Any comment on this patch ?
>> >
>> > Shouldn't the one in drivers/net/ethernet/xscale/ixp4xx_eth.c
>> > also be changed?
>>
>> Yes, you are right. Do you want me to include it in same patch?
>
> Your choice. I would use a single patch.
There are few other places where the same change is applicable.
I am planning to put all those changes in a single patch. It includes
changes in drivers/net/ethernet/xscale/ixp4xx_eth.c
You can review this patch separately.
>
^ permalink raw reply
* [PATCH iproute2/net-next 0/2] tc: flower: enhance mask support
From: Simon Horman @ 2016-12-16 13:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Simon Horman
Hi,
this short series enhances mask support for tc flower by:
* Documenting existing mask support for *_ip parameters
* Allowing *_mac options to accept a mask.
This makes use of existing kernel features.
Based on net-next +
"[PATCH iproute2 0/2] Add dest UDP port to IP tunnel parameters"
Simon Horman (2):
tc: flower: document that *_ip parameters take a PREFIX as an
argument.
tc: flower: Allow *_mac options to accept a mask
man/man8/tc-flower.8 | 41 +++++++++++++++++++++++------------------
tc/f_flower.c | 51 ++++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 63 insertions(+), 29 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH iproute2/net-next 1/2] tc: flower: document that *_ip parameters take a PREFIX as an argument.
From: Simon Horman @ 2016-12-16 13:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Simon Horman
In-Reply-To: <1481896477-13497-1-git-send-email-simon.horman@netronome.com>
* The argument to src_ip, dst_ip, enc_src_ip and enc_dst_ip take an
optional prefix length which is used to provide a mask to limit the scope
of matching.
* This is documented as a PREFIX in keeping with ip-route(8).
Example of uses of IPv4 and IPv6 prefixes
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: flower \
indev eth0 dst_ip 192.168.1.1 action drop
tc filter add dev eth0 protocol ip parent ffff: flower \
indev eth0 src_ip 10.0.0.0/8 action drop
tc filter add dev eth0 protocol ipv6 parent ffff: flower \
indev eth0 src_ip 2001:DB8:1::/48 action drop
tc filter add dev eth0 protocol ipv6 parent ffff: flower \
indev eth0 dst_ip 2001:DB8::1 action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
man/man8/tc-flower.8 | 28 ++++++++++++++--------------
tc/f_flower.c | 8 ++++----
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index 88df83360b89..a383b6584dc6 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -31,8 +31,8 @@ flower \- flow based traffic control filter
.IR ETH_TYPE " } | "
.BR ip_proto " { " tcp " | " udp " | " sctp " | " icmp " | " icmpv6 " | "
.IR IP_PROTO " } | { "
-.BR dst_ip " | " src_ip " } { "
-.IR ipv4_address " | " ipv6_address " } | { "
+.BR dst_ip " | " src_ip " } "
+.IR PREFIX " | { "
.BR dst_port " | " src_port " } "
.IR port_number " } | "
.B enc_key_id
@@ -103,14 +103,14 @@ may be
.BR tcp ", " udp ", " sctp ", " icmp ", " icmpv6
or an unsigned 8bit value in hexadecimal format.
.TP
-.BI dst_ip " ADDRESS"
+.BI dst_ip " PREFIX"
.TQ
-.BI src_ip " ADDRESS"
+.BI src_ip " PREFIX"
Match on source or destination IP address.
-.I ADDRESS
-must be a valid IPv4 or IPv6 address, depending on
-.BR protocol
-option of tc filter.
+.I PREFIX
+must be a valid IPv4 or IPv6 address, depending on the \fBprotocol\fR
+option to tc filter, optionally followed by a slash and the prefix length.
+If the prefix is missing, \fBtc\fR assumes a full-length host match.
.TP
.BI dst_port " NUMBER"
.TQ
@@ -128,16 +128,16 @@ which have to be specified in beforehand.
.TP
.BI enc_key_id " NUMBER"
.TQ
-.BI enc_dst_ip " ADDRESS"
+.BI enc_dst_ip " PREFIX"
.TQ
-.BI enc_src_ip " ADDRESS"
-.TQ
-.BI enc_dst_port " NUMBER"
+.BI enc_src_ip " PREFIX"
Match on IP tunnel metadata. Key id
.I NUMBER
is a 32 bit tunnel key id (e.g. VNI for VXLAN tunnel).
-.I ADDRESS
-must be a valid IPv4 or IPv6 address. Dst port
+.I PREFIX
+must be a valid IPv4 or IPv6 address optionally followed by a slash and the
+prefix length. If the prefix is missing, \fBtc\fR assumes a full-length
+host match. Dst port
.I NUMBER
is a 16 bit UDP dst port.
.SH NOTES
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 653dfefc060a..cdf74344f78f 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -48,14 +48,14 @@ static void explain(void)
" dst_mac MAC-ADDR |\n"
" src_mac MAC-ADDR |\n"
" ip_proto [tcp | udp | sctp | icmp | icmpv6 | IP-PROTO ] |\n"
- " dst_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
- " src_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
+ " dst_ip PREFIX |\n"
+ " src_ip PREFIX |\n"
" dst_port PORT-NUMBER |\n"
" src_port PORT-NUMBER |\n"
" type ICMP-TYPE |\n"
" code ICMP-CODE }\n"
- " enc_dst_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
- " enc_src_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
+ " enc_dst_ip PREFIX |\n"
+ " enc_src_ip PREFIX |\n"
" enc_key_id [ KEY-ID ] }\n"
" FILTERID := X:Y:Z\n"
" ACTION-SPEC := ... look at individual actions\n"
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
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