* RE: [PATCH] r8169: remember WOL preferences on driver load
From: hayeswang @ 2013-08-15 6:09 UTC (permalink / raw)
To: 'Peter Wu', 'Francois Romieu'; +Cc: netdev, 'nic_swsd'
In-Reply-To: <5823402.G5n4G2k0Uv@al>
Peter Wu [mailto:lekensteyn@gmail.com]
> Sent: Wednesday, August 14, 2013 8:57 PM
> To: Francois Romieu
> Cc: netdev@vger.kernel.org; nic_swsd; Hayeswang
> Subject: Re: [PATCH] r8169: remember WOL preferences on driver load
>
> On Tuesday 13 August 2013 23:28:43 Francois Romieu wrote:
> > > The r8168 vendor driver used to write to both Config1 and
> Config5, but
> > > in recent versions, this is commented out. Here we keep
> writing PMEnable
> > > to Config1 because there may be older chips where
> PMEnable is not sticky.
> >
> > <sneak regression paranoia>
> > Please include the bits you want to keep in the "&" mask.
> > </sneak regression paranoia>
>
> I previously tried:
>
> RTL_W8(Config5, RTL_R8(Config5) & (BWF | MWF | UWF |
> LanWake | PMEStatus));
I think this way is better and safe.
> but then I realized that the Realtek r8168 vendor driver does
> not touch this
> register on load. The bits not included in the above mask are
> 2, 3 and 7. On
> most datasheets for recent hardware, these are marked reserved.
Some settings would be in rtl8168_hw_start() for different chips.
We sure only correct bit would be enabled.
The simple way is to clear bit 2, 3 and 7 for all chips. Or set desired
bit which you want.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH net-next] ipip: Add room for user-specified custom header
From: Kristian Evensen @ 2013-08-15 6:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130814.133929.975837205960955245.davem@davemloft.net>
On Wed, Aug 14, 2013 at 10:39 PM, David Miller <davem@davemloft.net> wrote:
>
> Sorry I'm not even going to consider applying this until you post
> use-cases for this feature, because right now it just looks like a
> random way to facilitate some third party proprietary kernel module
> or similar.
Thank you for your feedback and I agree, one challenge with this patch
is that it easy facilitates proprietary code.
My use-case when creating this patch was to simplify the
implementation of IP-in-UDP tunneling. I initially started out by
cloning IP-in-IP and managing a set of UDP-sockets (for the incoming
packets), but it seemed like overkill for something so simple.
Especially since UDP source ports are used on something that does not
need to be UDP sockets. So instead I made space between the IP headers
for the UDP header, and the UDP header was inserted using an xtables
extension. I was planning to post the xtables-module at the same time,
but some other things came in the way. There are only a few features
missing, so it will be out soon. I am aware that all of this could be
implemented in the xtables-module directly, but the additional
memmove() required has an impact on performance on the devices I am
working with.
Another, and perhaps more interesting, use-case is to ease development
and prototyping of new transport protocols on slower devices (for
example typical consumer routers). In the research lab I belong to, we
are currently looking into new protocols designed for mobile broadband
networks. In order to have the largest possible selection of test
applications and to avoid modifying client devices, we use existing
applications (or applications using existing protocols) and tunnel the
traffic through tunnels using our protocol. The devices we have are
too slow for user-space tunneling and the links are all connected to
the public internet. The protocol logic and header insertion is kept
in a separate xtables-module. Using this approach has improved the
speed at which we are able to prototype for example new flow or
congestion control algorithms, and given us sufficient networking
performance.
What is the recommended way forward for getting this patch considered?
Shall I focus on finishing the xtables example-module, or abandon this
patch and implement IP in UDP as a new tunneling protocol in the
kernel?
(Sorry about sending two emails, it was too early in the morning and I
forgot to enable plain-text)
-Kristian
^ permalink raw reply
* Re: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
From: Fernando Gont @ 2013-08-15 6:28 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20130814230617.GA13066@order.stressinduktion.org>
Hi, Hannes,
Thanks so much for your timely response! -- Please find my comments
in-line...
On 08/14/2013 08:06 PM, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:
>> Folks,
>>
>> FYI. -- this is an important piece when it comes to First Hop (i.e.,
>> "local link") Security.
>
> Thanks for the heads-up, Fernando!
>
> I sketched up a patch to protect the receiving side. I still don't know if I
> should make this behaviour default or configurable via a sysctl knob. I really
> don't want to break existing installations.
Make it the default behavior. If anything, provide a sysctl knob to
override it.
Note: In the specific case of NS/NA messages, it's impossible nowadays
to find them fragmented in a real network (we don't even have options
(other than padding) to make NS/NAs grow so large!).
> As an extra plus, we now discard packets with nested fragment headers at once.
> Those packets should never have been accepted.
Is that the "goto fail_hdr" part in your patch?
P.S.: What about RS/RA messages?
Cheers,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
* Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
From: Benedikt Spranger @ 2013-08-15 6:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, Alexander Frank, Sebastian Andrzej Siewior, Hans J. Koch,
Holger Dengler
In-Reply-To: <20130814163311.GB7208@kroah.com>
On Wed, 14 Aug 2013 09:33:11 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> Step 4 should have told UIO that it was gone and had it shut everything
> down properly, so that there would not be a crash.
The MFD driver only knows about a specific MFD cell. Through
enable/disable callbacks the driver could tell UIO ...hm... whom? what?
Neither the MFD driver nor the MFD core knows something about a specific
UIO driver. But only that specific UIO driver knows about the device
node activities.
> > > You shouldn't need a module reference for this type of thing.
> > The driver uio_pdrv has no chance to recognize that the underlaying platform
> > device has gone.
> The mfd driver could tell it that it is gone, right?
It could tell, but whom and how?
Regards
Benedikt Spranger
^ permalink raw reply
* Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
From: Greg Kroah-Hartman @ 2013-08-15 6:59 UTC (permalink / raw)
To: Benedikt Spranger
Cc: netdev, Alexander Frank, Sebastian Andrzej Siewior, Hans J. Koch,
Holger Dengler
In-Reply-To: <20130815084221.3339142f@mitra.spranger.biz>
On Thu, Aug 15, 2013 at 08:42:21AM +0200, Benedikt Spranger wrote:
> On Wed, 14 Aug 2013 09:33:11 -0700
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > Step 4 should have told UIO that it was gone and had it shut everything
> > down properly, so that there would not be a crash.
> The MFD driver only knows about a specific MFD cell. Through
> enable/disable callbacks the driver could tell UIO ...hm... whom? what?
>
> Neither the MFD driver nor the MFD core knows something about a specific
> UIO driver. But only that specific UIO driver knows about the device
> node activities.
>
> > > > You shouldn't need a module reference for this type of thing.
> > > The driver uio_pdrv has no chance to recognize that the underlaying platform
> > > device has gone.
> > The mfd driver could tell it that it is gone, right?
> It could tell, but whom and how?
Hm. Ah, doesn't this work like PCI, when a PCI device is removed from
the system, reads just start returning all 0xFF, so the userspace UIO
driver now knows the device is gone from the system. Doesn't MFD
hardware work the same way? Why would removing the MFD driver affect
UIO at all, as it's just an interrupt and memory, both of which are
controlled by UIO, not MFD at all.
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
From: Benedikt Spranger @ 2013-08-15 7:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, Alexander Frank, Sebastian Andrzej Siewior, Hans J. Koch,
Holger Dengler
In-Reply-To: <20130815065936.GA13320@kroah.com>
On Wed, 14 Aug 2013 23:59:36 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> Hm. Ah, doesn't this work like PCI, when a PCI device is removed from
> the system, reads just start returning all 0xFF, so the userspace UIO
> driver now knows the device is gone from the system. Doesn't MFD
> hardware work the same way? Why would removing the MFD driver affect
> UIO at all, as it's just an interrupt and memory, both of which are
> controlled by UIO, not MFD at all.
>
> confused,
Sorry for the confusion.
MFD core allocates the platform device structure and platform data
dynamicaly and fill it up with appropriate data from the MFD cell data.
And MFD core frees this memory on unregistering.
Therefore the UIO driver needs to know that the underlaying platform device
struct and platform device data are invalid and should not be used any more.
The whole point are dynamicaly allocated devices and UIO.
Regards
Benedikt Spranger
^ permalink raw reply
* [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.
From: Sonic Zhang @ 2013-08-15 7:37 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
Some synopsys ip implementation doesn't support DMA store and forward mode,
such as BF60x. So, define force_sf_dma_mode negative to use DMA thresholds only.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f2ccb36..b0e003a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
*/
static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
{
- if (likely(priv->plat->force_sf_dma_mode ||
+ if (priv->plat->force_sf_dma_mode < 0)
+ priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
+ else if (likely(priv->plat->force_sf_dma_mode > 0 ||
((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {
/*
* In case of GMAC, SF mode can be enabled
--
1.8.2.3
^ permalink raw reply related
* Re: [PATCHv2 net-next] 6lowpan: handle only real link-local addresses
From: David Miller @ 2013-08-15 7:38 UTC (permalink / raw)
To: alex.aring-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20130815045701.GA3110-P4zwP3w+81Pu/k754drY8A@public.gmane.org>
From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 15 Aug 2013 06:57:21 +0200
> Hi David,
>
> On Wed, Aug 14, 2013 at 05:18:25PM -0700, David Miller wrote:
>> From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 14 Aug 2013 23:17:01 +0200
>>
>> > Ok, please let me know what should I do to submit it properly.
>>
>> What you don't understand is that just because patches aren't
>> related doesn't mean that their order of application doesn't
>> matter.
>>
> Ok. I got the information on an other mailinglist that I should
> not mix "features" and "fixes" in a single series. Then I just
> try to seperate...
If it's a fix it's destined for the 'net' tree not 'net-next'.
And in that case you first submit only the bug fix, then you
politely ask me after it's been included to merge 'net' into
'net-next' so you can then rebase your net-next patches and
submit them seperately.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
^ permalink raw reply
* [PATCHv2 net-next] xfrm: Make xfrm_state timer monotonic
From: Fan Du @ 2013-08-15 7:49 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
xfrm_state timer should be independent of system clock change,
so switch to CLOCK_BOOTTIME base which is not only monotonic but
also counting suspend time.
Thus issue reported in commit: 9e0d57fd6dad37d72a3ca6db00ca8c76f2215454
("xfrm: SAD entries do not expire correctly after suspend-resume")
could ALSO be avoided.
Signed-off-by: Fan Du <fan.du@windriver.com>
v2: Use CLOCK_BOOTTIME to count suspend time, but still monotonic.
---
net/xfrm/xfrm_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 79bf9a0..0824679 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -486,7 +486,8 @@ struct xfrm_state *xfrm_state_alloc(struct net *net)
INIT_HLIST_NODE(&x->bydst);
INIT_HLIST_NODE(&x->bysrc);
INIT_HLIST_NODE(&x->byspi);
- tasklet_hrtimer_init(&x->mtimer, xfrm_timer_handler, CLOCK_REALTIME, HRTIMER_MODE_ABS);
+ tasklet_hrtimer_init(&x->mtimer, xfrm_timer_handler,
+ CLOCK_BOOTTIME, HRTIMER_MODE_ABS);
setup_timer(&x->rtimer, xfrm_replay_timer_handler,
(unsigned long)x);
x->curlft.add_time = get_seconds();
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] hrtimer: Add notifer when clock_was_set was called
From: Fan Du @ 2013-08-15 7:50 UTC (permalink / raw)
To: tglx, davem, steffen.klassert; +Cc: herbert, dborkman, netdev
In-Reply-To: <1376553043-19007-1-git-send-email-fan.du@windriver.com>
When clock_was_set is called in case of system wall time change
or host resume from suspend state, use this notifier for places
where interested in this action, e.g Ipsec SA lifetime management.
Signed-off-by: Fan Du <fan.du@windriver.com>
v3:
-Beautify notifier with register/unregister API exported for other subsystem.
---
include/linux/hrtimer.h | 3 +++
kernel/hrtimer.c | 19 +++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index d19a5c2..f0404e4 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -461,4 +461,7 @@ extern u64 ktime_divns(const ktime_t kt, s64 div);
/* Show pending timers: */
extern void sysrq_timer_list_show(void);
+extern int register_clock_change_notifier(struct notifier_block *nb);
+extern int unregister_clock_change_notifier(struct notifier_block *nb);
+
#endif
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 383319b..c6e6405 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -755,6 +755,24 @@ static inline void retrigger_next_event(void *arg) { }
#endif /* CONFIG_HIGH_RES_TIMERS */
+static ATOMIC_NOTIFIER_HEAD(clock_change_notifier_list);
+static int call_clock_change_notifiers(void)
+{
+ return atomic_notifier_call_chain(&clock_change_notifier_list, 0, 0);
+}
+
+int register_clock_change_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&clock_change_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(register_clock_change_notifier);
+
+int unregister_clock_change_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(&clock_change_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_clock_change_notifier);
+
/*
* Clock realtime was set
*
@@ -773,6 +791,7 @@ void clock_was_set(void)
on_each_cpu(retrigger_next_event, NULL, 1);
#endif
timerfd_clock_was_set();
+ call_clock_change_notifiers();
}
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 net-next 0/3] xfrm: Refactor xfrm_state timer management
From: Fan Du @ 2013-08-15 7:50 UTC (permalink / raw)
To: tglx, davem, steffen.klassert; +Cc: herbert, dborkman, netdev
The first version of "refactor xfrm_state timer management" has been
flushed into toilet since nobody but only me like it.
Anyway new approach here is updating SAs lifetime timeout whenever
clock_was_set is called, iow, system clock changed or host resume from
suspend state. Rule is simple, force soft expire for any SAs which has
not reach their soft expire limit and hard expire for those has experienced
soft expire timeout but wait for hard expire timeout to come.
Locking issue:
- holding rtnl_lock when iterate on all net namespace.
- holding xfrm_state_lock when iterate all xfrm_state in this net.
- holding state->lock when changing xfrm_state.
Any comments would be wellcome! harsh or gentle :)
Thanks!
v3:
- Fixing locking issue clock_change_callback reported by LOCKDEP.
- Beautify notifier in clock_was_set as suggested by Daniel Borkmann.
v2:
- Instead of getting rid of original xfrm_state timer code almost completely,
new approach is updating SA lifetime when clock_was_set is called.
v1:
- The initiative of v1 is making xfrm_state timer independent of wall clock
changing which could result in sudden SA termination or extremely long SA
lifetime. So no need to read wall clock in timer handler and also
unnecessary to turn on the timer for just 1 second as the original
implementation. Simply start the timer right after SA is create for soft
timeout, and after soft timeout happened, reload timer for hard timeout.
Fan Du (3):
hrtimer: Add notifer when clock_was_set was called
xfrm: Update xfrm_state lifetime expire after clock_was_set
xfrm: Revert "Fix unexpected SA hard expiration after changing date"
include/linux/hrtimer.h | 3 +++
include/net/xfrm.h | 4 ---
kernel/hrtimer.c | 19 ++++++++++++++
net/xfrm/xfrm_state.c | 65 ++++++++++++++++++++++++++++++++++-------------
4 files changed, 70 insertions(+), 21 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/3] xfrm: Update xfrm_state lifetime expire after clock_was_set
From: Fan Du @ 2013-08-15 7:50 UTC (permalink / raw)
To: tglx, davem, steffen.klassert; +Cc: herbert, dborkman, netdev
In-Reply-To: <1376553043-19007-1-git-send-email-fan.du@windriver.com>
After clock_was_set called to set new time or host resume from suspend
state. Notify IKED with soft timeout for SAs which haven't reach its
soft timeout limit. For those dying SAs, arrange them to hard expire.
This modification is characterized by SA is sensible to any degree of
clock changes while as SA lifetime is marked by second.
Another point is clock_was_set is traversing all net name space to
update SA time while holding rtnl_lock, it may not scale very well.
Signed-off-by: Fan Du <fan.du@windriver.com>
v3:
- Fix lockdep complaint about circular locking with trying to acquire
state->clock while holding xfrm_state_lock.
v2:
- Use notifier when clock was set, and then update SA lifetime accordingly.
---
net/xfrm/xfrm_state.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 78f66fa..dcfcd98 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2002,6 +2002,48 @@ int xfrm_init_state(struct xfrm_state *x)
EXPORT_SYMBOL(xfrm_init_state);
+static int clock_change_callback(struct notifier_block *nb,
+ unsigned long reason, void *arg)
+{
+ struct xfrm_state_walk *walk;
+ struct xfrm_state *state;
+ struct net *net;
+ long next;
+
+ rtnl_lock();
+ for_each_net(net) {
+ spin_lock_bh(&xfrm_state_lock);
+ list_for_each_entry(walk, &net->xfrm.state_all, all) {
+ state = container_of(walk, struct xfrm_state, km);
+ xfrm_state_hold(state);
+ spin_unlock_bh(&xfrm_state_lock);
+
+ spin_lock_bh(&state->lock);
+ if (state->km.dying) {
+ next = 0;
+ } else {
+ state->km.dying = 1;
+ km_state_expired(state, 0, 0);
+ next = state->lft.hard_add_expires_seconds -
+ state->lft.soft_add_expires_seconds;
+ }
+ state->km.state = XFRM_STATE_EXPIRED;
+ tasklet_hrtimer_start(&state->mtimer, ktime_set(next, 0), HRTIMER_MODE_REL);
+ spin_unlock_bh(&state->lock);
+ xfrm_state_put(state);
+ spin_lock_bh(&xfrm_state_lock);
+ }
+ spin_unlock_bh(&xfrm_state_lock);
+ }
+ rtnl_unlock();
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block clock_change_notifier = {
+ .notifier_call = clock_change_callback,
+};
+
int __net_init xfrm_state_init(struct net *net)
{
unsigned int sz;
@@ -2026,6 +2068,7 @@ int __net_init xfrm_state_init(struct net *net)
INIT_HLIST_HEAD(&net->xfrm.state_gc_list);
INIT_WORK(&net->xfrm.state_gc_work, xfrm_state_gc_task);
init_waitqueue_head(&net->xfrm.km_waitq);
+ register_clock_change_notifier(&clock_change_notifier);
return 0;
out_byspi:
@@ -2057,6 +2100,7 @@ void xfrm_state_fini(struct net *net)
xfrm_hash_free(net->xfrm.state_bysrc, sz);
WARN_ON(!hlist_empty(net->xfrm.state_bydst));
xfrm_hash_free(net->xfrm.state_bydst, sz);
+ unregister_clock_change_notifier(&clock_change_notifier);
}
#ifdef CONFIG_AUDITSYSCALL
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] xfrm: Revert "Fix unexpected SA hard expiration after changing date"
From: Fan Du @ 2013-08-15 7:50 UTC (permalink / raw)
To: tglx, davem, steffen.klassert; +Cc: herbert, dborkman, netdev
In-Reply-To: <1376553043-19007-1-git-send-email-fan.du@windriver.com>
Since SAs lifetime timeout has been updated whenever clock_was_set is
called. So commit: e3c0d04750751389d5116267f8cf4687444d9a50
("Fix unexpected SA hard expiration after changing date") is not needed
anymore.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
include/net/xfrm.h | 4 ----
net/xfrm/xfrm_state.c | 21 ++++-----------------
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 94ce082..b9df23f 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -214,9 +214,6 @@ struct xfrm_state {
struct xfrm_lifetime_cur curlft;
struct tasklet_hrtimer mtimer;
- /* used to fix curlft->add_time when changing date */
- long saved_tmo;
-
/* Last used time */
unsigned long lastused;
@@ -242,7 +239,6 @@ static inline struct net *xs_net(struct xfrm_state *x)
/* xflags - make enum if more show up */
#define XFRM_TIME_DEFER 1
-#define XFRM_SOFT_EXPIRE 2
enum {
XFRM_STATE_VOID,
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index dcfcd98..79bf9a0 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -407,17 +407,8 @@ static enum hrtimer_restart xfrm_timer_handler(struct hrtimer * me)
if (x->lft.hard_add_expires_seconds) {
long tmo = x->lft.hard_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0) {
- if (x->xflags & XFRM_SOFT_EXPIRE) {
- /* enter hard expire without soft expire first?!
- * setting a new date could trigger this.
- * workarbound: fix x->curflt.add_time by below:
- */
- x->curlft.add_time = now - x->saved_tmo - 1;
- tmo = x->lft.hard_add_expires_seconds - x->saved_tmo;
- } else
- goto expired;
- }
+ if (tmo <= 0)
+ goto expired;
if (tmo < next)
next = tmo;
}
@@ -434,14 +425,10 @@ static enum hrtimer_restart xfrm_timer_handler(struct hrtimer * me)
if (x->lft.soft_add_expires_seconds) {
long tmo = x->lft.soft_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0) {
+ if (tmo <= 0)
warn = 1;
- x->xflags &= ~XFRM_SOFT_EXPIRE;
- } else if (tmo < next) {
+ else if (tmo < next)
next = tmo;
- x->xflags |= XFRM_SOFT_EXPIRE;
- x->saved_tmo = tmo;
- }
}
if (x->lft.soft_use_expires_seconds) {
long tmo = x->lft.soft_use_expires_seconds +
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next v2 0/4] ipip/ip6tnl: allow to switch netns during encap/decap
From: David Miller @ 2013-08-15 8:01 UTC (permalink / raw)
To: nicolas.dichtel
Cc: netdev, ebiederm, bcrl, ravi.mlists, bhutchings, eric.dumazet
In-Reply-To: <1376409072-6414-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 13 Aug 2013 17:51:08 +0200
>
> This serie is a follow up of the previous serie witch adds this functionality
> for sit tunnels.
>
> The goal is to add x-netns support for the module ipip and ip6_tunnel, ie the
> encapsulation addresses and the network device are not owned by the same
> namespace.
>
> Note that the two first patches are cleanup.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: tg3: fix NULL pointer dereference in tg3_io_error_detected and tg3_io_slot_reset
From: David Miller @ 2013-08-15 8:07 UTC (permalink / raw)
To: nsujir; +Cc: netdev, dborkman, shangw, mchan
In-Reply-To: <1376419513-31924-1-git-send-email-nsujir@broadcom.com>
From: "Nithin Nayak Sujir" <nsujir@broadcom.com>
Date: Tue, 13 Aug 2013 11:45:13 -0700
> From: Daniel Borkmann <dborkman@redhat.com>
>
> Commit d8af4dfd8 ("net/tg3: Fix kernel crash") introduced a possible
> NULL pointer dereference in tg3 driver when !netdev || !netif_running(netdev)
> condition is met and netdev is NULL. Then, the jump to the 'done' label
> calls dev_close() with a netdevice that is NULL. Therefore, only call
> dev_close() when we have a netdevice, but one that is not running.
>
> [ Add the same checks in tg3_io_slot_reset() per Gavin Shan - by Nithin
> Nayak Sujir ]
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
> Cc: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Can I get some reviews from the Broadcom folks?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
From: Greg Kroah-Hartman @ 2013-08-15 8:09 UTC (permalink / raw)
To: Benedikt Spranger
Cc: netdev, Alexander Frank, Sebastian Andrzej Siewior, Hans J. Koch,
Holger Dengler
In-Reply-To: <20130815092753.5a23810b@mitra.spranger.biz>
On Thu, Aug 15, 2013 at 09:27:53AM +0200, Benedikt Spranger wrote:
> On Wed, 14 Aug 2013 23:59:36 -0700
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > Hm. Ah, doesn't this work like PCI, when a PCI device is removed from
> > the system, reads just start returning all 0xFF, so the userspace UIO
> > driver now knows the device is gone from the system. Doesn't MFD
> > hardware work the same way? Why would removing the MFD driver affect
> > UIO at all, as it's just an interrupt and memory, both of which are
> > controlled by UIO, not MFD at all.
> >
> > confused,
> Sorry for the confusion.
>
> MFD core allocates the platform device structure and platform data
> dynamicaly and fill it up with appropriate data from the MFD cell data.
> And MFD core frees this memory on unregistering.
>
> Therefore the UIO driver needs to know that the underlaying platform device
> struct and platform device data are invalid and should not be used any more.
> The whole point are dynamicaly allocated devices and UIO.
Given that a UIO driver does need to specificly bind to a device (be it
a PCI, OF, or something else), it should be the one that is notified
when a device is removed.
Again, just like PCI is handled today, why is MFD so "special" that it
can't tell the drivers bound to its devices that it is going away?
Do you have a specific example of an in-tree UIO driver that has this
problem that I can look at to try to understand this better?
Still confused,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
From: Sebastian Andrzej Siewior @ 2013-08-15 8:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Benedikt Spranger, netdev, Alexander Frank, Hans J. Koch,
Holger Dengler
In-Reply-To: <20130815080901.GC7080@kroah.com>
On 08/15/2013 10:09 AM, Greg Kroah-Hartman wrote:
> Do you have a specific example of an in-tree UIO driver that has this
> problem that I can look at to try to understand this better?
grep for "uio_pdrv" and you find a few devices in arm and sh tree. Each
one is created once at boot time and never removed. With mfd the device
can be removed.
If you look now at uio_write() then you will notice that it will
deference idev->info->irqcontrol but once the device is gone the memory
starting at info is gone, not to mention the code behind irqcontrol.
> Still confused,
>
> greg k-h
Sebastian
^ permalink raw reply
* Re: [PATCH v2 1/3] drivers/net: enic: Adding support for Cisco Low Latency NIC
From: David Miller @ 2013-08-15 8:19 UTC (permalink / raw)
To: neepatel; +Cc: netdev, umalhi, nistrive, benve
In-Reply-To: <1376432265-5497-2-git-send-email-neepatel@cisco.com>
From: Neel Patel <neepatel@cisco.com>
Date: Tue, 13 Aug 2013 15:17:43 -0700
> +static inline u64 vnic_cached_posted_index(dma_addr_t addr,
> + unsigned int len, unsigned int index)
You are adding functions in this patch which are not used, therefore
breaking bisectability because after just this patch is applied
the compiler will warn about the static unused function.
^ permalink raw reply
* Re: [PATCH net v2] be2net: Clear any capability flags that driver is not interested in.
From: David Miller @ 2013-08-15 8:22 UTC (permalink / raw)
To: sarveshwar.bandi; +Cc: netdev
In-Reply-To: <07165eb6-9b8f-45b4-bec6-bb53f0e1aa52@CMEXHTCAS2.ad.emulex.com>
From: <sarveshwar.bandi@emulex.com>
Date: Wed, 14 Aug 2013 13:21:47 +0530
> From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
>
> It is possible for some versions of firmware to advertise capabilities that driver
> is not ready to handle. This may lead to controller stall. Since the driver is
> interested only in subset of flags, clearing the rest.
>
> Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Revert "cxgb3: Check and handle the dma mapping errors"
From: David Miller @ 2013-08-15 8:24 UTC (permalink / raw)
To: divy; +Cc: aik, linuxppc-dev, netdev, linux-kernel, torvalds, santosh,
fenlason
In-Reply-To: <520BA8E4.3010406@chelsio.com>
From: Divy Le ray <divy@chelsio.com>
Date: Wed, 14 Aug 2013 08:57:24 -0700
> On 08/14/2013 02:19 AM, Alexey Kardashevskiy wrote:
>> This reverts commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9.
>>
>> As the tests PPC64 (powernv platform) show, IOMMU pages are leaking
>> when transferring big amount of small packets (<=64 bytes),
>> "ping -f" and waiting for 15 seconds is the simplest way to confirm
>> the bug.
>>
>> Cc: Linus Torvalds<torvalds@linux-foundation.org>
>> Cc: Santosh Rastapur<santosh@chelsio.com>
>> Cc: Jay Fenlason<fenlason@redhat.com>
>> Cc: David S. Miller<davem@davemloft.net>
>> Cc: Divy Le ray<divy@chelsio.com>
>> Signed-off-by: Alexey Kardashevskiy<aik@ozlabs.ru>
>
> Acked-by: Divy Le Ray <divy@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch] rtnetlink: remove an unneeded test
From: David Miller @ 2013-08-15 8:29 UTC (permalink / raw)
To: ebiederm
Cc: dan.carpenter, john.r.fastabend, jiri, vyasevic, netdev,
kernel-janitors
In-Reply-To: <8761v8aww3.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 14 Aug 2013 12:35:24 -0700
> Dan Carpenter <dan.carpenter@oracle.com> writes:
>
>> We know that "dev" is a valid pointer at this point, so we can remove
>> the test and clean up a little.
>
> Quite right.
>
> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net/usb/r8152: support aggregation
From: David Miller @ 2013-08-15 8:34 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1376484880-741-1-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 14 Aug 2013 20:54:38 +0800
> Enable the tx/rx aggregation which could contain one or more packets
> for each bulk in/out. This could reduce the loading of the host
> controller by sending less bulk transfer.
>
> The rx packets in the bulk in buffer should be 8-byte aligned, and
> the tx packets in the bulk out buffer should be 4-byte aligned.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net/usb/r8152: enable tx checksum
From: David Miller @ 2013-08-15 8:34 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1376484880-741-2-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 14 Aug 2013 20:54:39 +0800
> Enable tx checksum.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net/usb/r8152: enable interrupt transfer
From: David Miller @ 2013-08-15 8:35 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1376484880-741-3-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 14 Aug 2013 20:54:40 +0800
> Use the interrupt transfer to replace polling link status.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* [PATCH] bond: Don't set skb->queue_mapping in netpoll.
From: Tao Ma @ 2013-08-15 8:36 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David S. Miller, Cong Wang, Eric Dumazet
From: Tao Ma <boyu.mt@taobao.com>
When we are using netpoll, we don't go through the normal
transmit process. In this case, bond_select_queue is not called
and qdisc_skb_cb(skb)->slave_dev_queue_mapping isn't set.
So when netpoll_send_skb_on_dev calls ndo_start_xmit and we
enter bond_dev_queue_xmit, we will set skb->queue_mapping to
an invalid value and in some cases cause the driver panic the
kernel(We meet with bnx2 panic because of a very large queue_mapping).
This patch skip skb->queue_mapping if we find we are in netpoll.
CC: "David S. Miller" <davem@davemloft.net>
CC: Cong Wang <amwang@redhat.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
---
drivers/net/bonding/bond_main.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 07f257d..97b2f52 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -405,12 +405,13 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
BUILD_BUG_ON(sizeof(skb->queue_mapping) !=
sizeof(qdisc_skb_cb(skb)->slave_dev_queue_mapping));
- skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
if (unlikely(netpoll_tx_running(bond->dev)))
bond_netpoll_send_skb(bond_get_slave_by_dev(bond, slave_dev), skb);
- else
+ else {
+ skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
dev_queue_xmit(skb);
+ }
return 0;
}
--
1.7.0.4
^ 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