* [IPv6] Why does IPV6_ROUTE_INFO still depends on EXPERIMENTAL?
From: Stefan (metze) Metzmacher @ 2011-07-12 22:03 UTC (permalink / raw)
To: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi,
I'm wondering why IPV6_ROUTE_INFO still depends on EXPERIMENTAL about
5 years after the initial implementation?
I'm also wondering why IPV6_PRIVACY, IPV6_ROUTER_PREF, IPV6_ROUTE_INFO
are compile time switches at all, while there're runtime switches which
are of
by default.
It would be nice to have more IPv6 features enabled (at compile time) by
default,
so that features can be turned (at runtime) with default distribution
kernels.
Is there a chance get patches accepted, which remove some compile time
switches?
metze
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [net-next 5/5] ixgbe: convert to ndo_fix_features
From: Michal Miroslaw @ 2011-07-12 21:44 UTC (permalink / raw)
To: Skidmore, Donald C
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <C0716E470783B24A8178C9E38CD2F34505E7682C@orsmsx509.amr.corp.intel.com>
Good to see the idea converging. :) More hints below.
On Tue, Jul 12, 2011 at 02:28:15PM -0700, Skidmore, Donald C wrote:
[...]
> The logic in this conditional is a little complex. I believe it would
> end up looking something like the following:
>
> in fix_features:
>
> /* Prevent change if not RSC capable or invalid ITR setting */
> if (data & NETIF_F_LRO)
That's not a fast path - you can drop (data & NETIF_F_LRO) check.
> if (!(adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) {
> data &= ~NETIF_F_LRO;
> else if (!(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) &&
> (adapter->rx_itr_setting != 1 &&
> adapter->rx_itr_setting > IXGBE_MAX_RSC_INT_RATE)) {
> data &= ~NETIF_F_LRO;
> }
> }
Same for !(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED). After this change,
you might add a call to netdev_update_features() whenever the second part
of the condition is changed by user and you get correctness all the time
'for free'.
> in set_feature:
>
> /* Make sure RSC matches LRO, reset if change */
> if (!!(data & NETIF_F_LRO) !=
> !!(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)) {
> adapter->flags2 ^= IXGBE_FLAG2_RSC_ENABLED;
> switch (adapter->hw.mac.type) {
> case ixgbe_mac_X540:
> case ixgbe_mac_82599EB:
> need_reset = true;
> break;
> default:
> break;
> }
> }
Correct. Why would you need IXGBE_FLAG2_RSC_ENABLED now, when it just
mirrors NETIF_F_LRO?
[...]
> Thanks again for the clarifications, the netdev-features.txt helped a lot too.
Nice to hear (read) that!
Best Regards,
Michał Mirosław
^ permalink raw reply
* RE: [net-next 5/5] ixgbe: convert to ndo_fix_features
From: Skidmore, Donald C @ 2011-07-12 21:28 UTC (permalink / raw)
To: Michal Miroslaw
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <20110712100932.GA6433@rere.qmqm.pl>
>-----Original Message-----
>From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>Sent: Tuesday, July 12, 2011 3:10 AM
>To: Skidmore, Donald C
>Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
>gospo@redhat.com
>Subject: Re: [net-next 5/5] ixgbe: convert to ndo_fix_features
>
>On Mon, Jul 11, 2011 at 04:53:57PM -0700, Skidmore, Donald C wrote:
>> >-----Original Message-----
>> >From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>> >Sent: Saturday, July 09, 2011 5:11 AM
>> >To: Kirsher, Jeffrey T
>> >Cc: davem@davemloft.net; Skidmore, Donald C; netdev@vger.kernel.org;
>> >gospo@redhat.com
>> >Subject: Re: [net-next 5/5] ixgbe: convert to ndo_fix_features
>> >
>> >On Sat, Jul 09, 2011 at 04:50:40AM -0700, Jeff Kirsher wrote:
>> >> From: Don Skidmore <donald.c.skidmore@intel.com>
>> >>
>> >> Private rx_csum flags are now duplicate of netdev->features &
>> >> NETIF_F_RXCSUM. We remove those duplicates and now use the
>> >net_device_ops
>> >> ndo_set_features. This was based on the original patch submitted
>by
>> >> Michal Miroslaw <mirq-linux@rere.qmqm.pl>. I also removed the
>special
>> >> case not requiring a reset for X540 hardware. It is needed just as
>it
>> >is
>> >> in 82599 hardware.
>> >[...]
>> >> --- a/drivers/net/ixgbe/ixgbe_main.c
>> >> +++ b/drivers/net/ixgbe/ixgbe_main.c
>> >> @@ -7188,6 +7188,88 @@ int ixgbe_setup_tc(struct net_device *dev,
>u8
>> >tc)
>> >[...]
>> >> +static int ixgbe_set_features(struct net_device *netdev, u32 data)
>> >> +{
>> >> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
>> >> + bool need_reset = false;
>> >> +
>> >> +#ifdef CONFIG_DCB
>> >> + if ((adapter->flags & IXGBE_FLAG_DCB_ENABLED) &&
>> >> + !(data & NETIF_F_HW_VLAN_RX))
>> >> + return -EINVAL;
>> >> +#endif
>> >> + /* return error if RXHASH is being enabled when RSS is not
>> >supported */
>> >> + if (!(adapter->flags & IXGBE_FLAG_RSS_ENABLED) &&
>> >> + (data & NETIF_F_RXHASH))
>> >> + return -EINVAL;
>> >> +
>> >> + /* If Rx checksum is disabled, then RSC/LRO should also be
>> >disabled */
>> >> + if (!(data & NETIF_F_RXCSUM)) {
>> >> + data &= ~NETIF_F_LRO;
>> >> + adapter->flags &= ~IXGBE_FLAG_RX_CSUM_ENABLED;
>> >> + } else {
>> >> + adapter->flags |= IXGBE_FLAG_RX_CSUM_ENABLED;
>> >> + }
>> >
>> >The checks above should be done in ndo_fix_features callback. The
>check
>> >for
>> >RSS_ENABLED for RXHASH is redundant, as the feature is removed in
>> >probe()
>> >in this case (see [MARK] below).
>> Thanks for the comments Michal, it clears up a lot in my mind. :)
>>
>> So in ndo_fix_features we would just turn off feature flags rather
>than return an error? For example:
>>
>> if (!(data & NETIF_F_RXCSUM))
>> data &= ~NETIF_F_LRO;
>
>Exactly.
>
>> As for RSS_ENABLED/RXHASH check it was to cover the cases where
>RSS_ENABLED might have changed since probe. This could happen with a
>resume were we don't get enough MSI-X vectors. There are also paths in
>FCoE and DCB that get into code that could clear IXGBE_FLAG_RSS_ENABLED.
>
>That makes sense now. The checks should be in ndo_fix_features and clear
>features whenever they are unavailable.
>
I'm seeing how this would work; most of my earlier checks should fall pretty naturally in to ndo_fix_feature. :)
>> >> +
>> >> + /* if state changes we need to update adapter->flags and
>reset */
>> >> + if ((adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) &&
>> >> + (!!(data & NETIF_F_LRO) !=
>> >> + !!(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED))) {
>
>ndo_fix_features() should prevent the change if
>!(adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) is true.
>
The logic in this conditional is a little complex. I believe it would end up looking something like the following:
in fix_features:
/* Prevent change if not RSC capable or invalid ITR setting */
if (data & NETIF_F_LRO)
if (!(adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) {
data &= ~NETIF_F_LRO;
else if (!(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) &&
(adapter->rx_itr_setting != 1 &&
adapter->rx_itr_setting > IXGBE_MAX_RSC_INT_RATE)) {
data &= ~NETIF_F_LRO;
}
}
in set_feature:
/* Make sure RSC matches LRO, reset if change */
if (!!(data & NETIF_F_LRO) !=
!!(adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)) {
adapter->flags2 ^= IXGBE_FLAG2_RSC_ENABLED;
switch (adapter->hw.mac.type) {
case ixgbe_mac_X540:
case ixgbe_mac_82599EB:
need_reset = true;
break;
default:
break;
}
}
>> >> + if ((data & NETIF_F_LRO) &&
>> >> + adapter->rx_itr_setting != 1 &&
>> >> + adapter->rx_itr_setting > IXGBE_MAX_RSC_INT_RATE)
>{
>> >> + e_info(probe, "rx-usecs set too low, "
>> >> + "not enabling RSC\n");
>
>And should clear NETIF_F_LRO when above condition is met.
>
>> >> + } else {
>> >> + adapter->flags2 ^= IXGBE_FLAG2_RSC_ENABLED;
>> >> + switch (adapter->hw.mac.type) {
>> >> + case ixgbe_mac_X540:
>> >> + case ixgbe_mac_82599EB:
>> >> + need_reset = true;
>> >> + break;
>> >> + default:
>> >> + break;
>> >> + }
>> >> + }
>> >> + }
>> >> +
>> >> + /*
>> >> + * Check if Flow Director n-tuple support was enabled or
>disabled.
>> >If
>> >> + * the state changed, we need to reset.
>> >> + */
>> >> + if (!(adapter->flags & IXGBE_FLAG_FDIR_PERFECT_CAPABLE)) {
>> >> + /* turn off ATR, enable perfect filters and reset */
>> >> + if (data & NETIF_F_NTUPLE) {
>> >> + adapter->flags &= ~IXGBE_FLAG_FDIR_HASH_CAPABLE;
>> >> + adapter->flags |=
>IXGBE_FLAG_FDIR_PERFECT_CAPABLE;
>> >> + need_reset = true;
>> >> + }
>> >> + } else if (!(data & NETIF_F_NTUPLE)) {
>> >> + /* turn off Flow Director, set ATR and reset */
>> >> + adapter->flags &= ~IXGBE_FLAG_FDIR_PERFECT_CAPABLE;
>> >> + if ((adapter->flags & IXGBE_FLAG_RSS_ENABLED) &&
>> >> + !(adapter->flags & IXGBE_FLAG_DCB_ENABLED))
>> >> + adapter->flags |= IXGBE_FLAG_FDIR_HASH_CAPABLE;
>> >> + need_reset = true;
>> >> + }
>> >
>> >Part of the checks above should be in ndo_fix_features, too.
>> >ndo_set_features
>> >should just enable what it has been passed. What ndo_fix_features
>> >callback
>> >returns is further limited by generic checks, and then (if the
>resulting
>> >set
>> >is different than current dev->features) ndo_set_features is called.
>>
>> I'm a little confused here. From your comments I get the idea that
>ndo_fix_features() just modifies and error checks our feature set. The
>result of this would then be just a change to the feature set (data
>variable in my case above). Is that a correct assumption? If so I'm
>confused as none of the two checks above change the feature set. They
>do change driver flags to indicate the new state and mark whether we
>need a reset. I don't believe we would want to do the reset until
>ndo_set_feature is called and if we broke up the setting of the driver
>flags into ndo_fix_features we would lose some state (i.e. if the
>IXGBE_FLAG2_RSC_ENABLED changed) that we need to decide if a reset is
>needed in ndo_set_features.
>>
>> Am I just missing something here?
>
>I see that this changes only driver internal state, so your right in
>putting
>this in ndo_set_features callback.
>
>Can you draw a map of the relevant bits and what state should result
>from
>them (a truth table if you will)? I have a hard time understanding the
>idea.
>This changes _CAPABLE bits depending on _ENABLED which adds to
>confusion.
>
>I would expect that:
> _CAPABLE are set whenever a config is possible, disregarding
>dependencies
> _ENABLED are set whenever a config is requested and possible
>But it looks like what I described is reversed or just wrong.
>
>Best Regards,
>Michał Mirosław
Hopefully the code example above answers your questions. I can see why you were having a hard time understanding it; I was making the FALSE assumption and not clearing the feature flags for the more complex conditionals. Thanks again for the clarifications, the netdev-features.txt helped a lot too.
Assuming I'm on the right track now I'll code up a new patch and send it out after our validation runs.
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage
From: Michał Mirosław @ 2011-07-12 20:59 UTC (permalink / raw)
To: Ralf Baechle
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
Senthil Balasubramanian, ath9k-devel-juf53994utBLZpfksSYvnA,
Vasanthakumar Thiagarajan
In-Reply-To: <20110712205316.GA13503-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
On Tue, Jul 12, 2011 at 10:53:16PM +0200, Michał Mirosław wrote:
> In the case we're analysing, the ownership is on the device's side
> until it stops writing the buffer.
Just to be clear, this should say: ... until it marks the buffer as done.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage
From: Michał Mirosław @ 2011-07-12 20:53 UTC (permalink / raw)
To: Ralf Baechle
Cc: Felix Fietkau, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
Senthil Balasubramanian, ath9k-devel-juf53994utBLZpfksSYvnA,
Vasanthakumar Thiagarajan
In-Reply-To: <20110712193204.GB13413-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
On Tue, Jul 12, 2011 at 08:32:04PM +0100, Ralf Baechle wrote:
> On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
>
> > >diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> > >index 70dc8ec..c5f46d5 100644
> > >--- a/drivers/net/wireless/ath/ath9k/recv.c
> > >+++ b/drivers/net/wireless/ath/ath9k/recv.c
> > >@@ -684,15 +684,11 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
> > > BUG_ON(!bf);
> > >
> > > dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
> > >- common->rx_bufsize, DMA_FROM_DEVICE);
> > >+ common->rx_bufsize, DMA_BIDIRECTIONAL);
> > >
> > > ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb->data);
> > >- if (ret == -EINPROGRESS) {
> > >- /*let device gain the buffer again*/
> > >- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
> > >- common->rx_bufsize, DMA_FROM_DEVICE);
> > >+ if (ret == -EINPROGRESS)
> > > return false;
> > >- }
> > >
> > > __skb_unlink(skb,&rx_edma->rx_fifo);
> > > if (ret == -EINVAL) {
> > I have strong doubts about this change. On most MIPS devices,
> > dma_sync_single_for_cpu is a no-op, whereas
> > dma_sync_single_for_device flushes the cache range. With this
> > change, the CPU could cache the DMA status part behind skb->data and
> > that cache entry would not be flushed inbetween calls to this
> > functions on the same buffer, likely leading to rx stalls.
>
> The code was already broken before. By the time dma_sync_single_for_cpu
> and ath9k_hw_process_rxdesc_edma are called, the DMA engine may still be
> active in the buffer, yet the driver is looking at it.
>
> dma_sync_single_for_cpu() is part of changing the buffer ownership from
> the device to the CPU. When it is being called, DMA into the buffer should
> already have been completed ... or else the shit may hit the jet engine.
Let's get rid of the "buffer ownership" misunderstanding from the picture.
Ownership is about who is expected to be writing (or is assured the data
is not being changed under his foot). This has nothing to do with DMA API.
DMA API is there for two purposes: to make part of memory visible to
both CPU and device (map/unmap) and to ensure memory consistency in
presence of caches (sync; implicitly done in map/unmap).
In the case we're analysing, the ownership is on the device's side
until it stops writing the buffer. sync_to_cpu doesn't change that.
It only allows the CPU to see more recent data (in case the CPU cached
something earlier).
> Imagine what would happen on a hypothetic cache architecture which does not
> have a dirty bit, that is which would have to write back every cache line -
> even clean lines - to memory in order to evict it. Corruption.
dma_map_whatever() would mark the memory uncachable on such an architecture.
Otherwise this would violate assumptions on DMA_FROM_DEVICE mappings (or
"device owned buffers") that the CPU does not write to the mapped memory.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] connector: add an event for monitoring process tracers
From: Vladimir Zapolskiy @ 2011-07-12 20:32 UTC (permalink / raw)
To: Evgeniy Polyakov, David S. Miller
Cc: Oleg Nesterov, Roland McGrath, netdev, Vladimir Zapolskiy
This change adds a procfs connector event, which is emitted on every
successful process tracer attach or detach.
If some process connects to other one, kernelspace connector reports
process id and thread group id of both these involved processes. On
disconnection null process id is returned.
Such an event allows to create a simple automated userspace mechanism
to be aware about processes connecting to others, therefore predefined
process policies can be applied to them if needed.
Note, a detach signal is not emitted, if a tracer process terminates
without explicit PTRACE_DETACH request. Such cases can be covered
listening to PROC_EVENT_EXIT connector events.
Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>
---
drivers/connector/cn_proc.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/cn_proc.h | 12 ++++++++++++
kernel/ptrace.c | 6 ++++++
3 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 2b46a7e..44f9881 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/connector.h>
#include <linux/gfp.h>
+#include <linux/tracehook.h>
#include <asm/atomic.h>
#include <asm/unaligned.h>
@@ -166,6 +167,43 @@ void proc_sid_connector(struct task_struct *task)
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_ptrace_connector(struct task_struct *task)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ struct timespec ts;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+ struct task_struct *tracer;
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg *)buffer;
+ ev = (struct proc_event *)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_PTRACE;
+ ev->event_data.ptrace.process_pid = task->pid;
+ ev->event_data.ptrace.process_tgid = task->tgid;
+
+ rcu_read_lock();
+ tracer = tracehook_tracer_task(task);
+ if (tracer) {
+ ev->event_data.ptrace.tracer_pid = tracer->pid;
+ ev->event_data.ptrace.tracer_tgid = tracer->tgid;
+ } else {
+ ev->event_data.ptrace.tracer_pid = 0;
+ ev->event_data.ptrace.tracer_tgid = 0;
+ }
+ rcu_read_unlock();
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_exit_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff --git a/include/linux/cn_proc.h b/include/linux/cn_proc.h
index 47dac5e..03013ad 100644
--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -53,6 +53,7 @@ struct proc_event {
PROC_EVENT_UID = 0x00000004,
PROC_EVENT_GID = 0x00000040,
PROC_EVENT_SID = 0x00000080,
+ PROC_EVENT_PTRACE = 0x00000100,
/* "next" should be 0x00000400 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
@@ -95,6 +96,13 @@ struct proc_event {
__kernel_pid_t process_tgid;
} sid;
+ struct ptrace_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ __kernel_pid_t tracer_pid;
+ __kernel_pid_t tracer_tgid;
+ } ptrace;
+
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -109,6 +117,7 @@ void proc_fork_connector(struct task_struct *task);
void proc_exec_connector(struct task_struct *task);
void proc_id_connector(struct task_struct *task, int which_id);
void proc_sid_connector(struct task_struct *task);
+void proc_ptrace_connector(struct task_struct *task);
void proc_exit_connector(struct task_struct *task);
#else
static inline void proc_fork_connector(struct task_struct *task)
@@ -124,6 +133,9 @@ static inline void proc_id_connector(struct task_struct *task,
static inline void proc_sid_connector(struct task_struct *task)
{}
+static inline void proc_ptrace_connector(struct task_struct *task)
+{}
+
static inline void proc_exit_connector(struct task_struct *task)
{}
#endif /* CONFIG_PROC_EVENTS */
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 2df1157..9238b5d 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -23,6 +23,7 @@
#include <linux/uaccess.h>
#include <linux/regset.h>
#include <linux/hw_breakpoint.h>
+#include <linux/cn_proc.h>
/*
@@ -260,6 +261,9 @@ out:
if (wait_trap)
wait_event(current->signal->wait_chldexit,
!(task->group_stop & GROUP_STOP_TRAPPING));
+ if (!retval)
+ proc_ptrace_connector(task);
+
return retval;
}
@@ -365,6 +369,8 @@ static int ptrace_detach(struct task_struct *child, unsigned int data)
}
write_unlock_irq(&tasklist_lock);
+ proc_ptrace_connector(child);
+
if (unlikely(dead))
release_task(child);
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/3] ps3_gelic: Don't kill the device on DMA failure
From: Andre Heider @ 2011-07-12 20:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: netdev, cbe-oss-dev, Andre Heider
In-Reply-To: <1310501606-829-1-git-send-email-a.heider@gmail.com>
Reset card->tx_dma_progress when lv1_net_start_tx_dma() fails or it
won't send anything afterwards anymore
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
drivers/net/ps3_gelic_net.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index 94422fc..4acc17b 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -838,9 +838,11 @@ static int gelic_card_kick_txdma(struct gelic_card *card,
card->tx_dma_progress = 1;
status = lv1_net_start_tx_dma(bus_id(card), dev_id(card),
descr->bus_addr, 0);
- if (status)
+ if (status) {
+ card->tx_dma_progress = 0;
dev_info(ctodev(card), "lv1_net_start_txdma failed," \
"status=%d\n", status);
+ }
}
return status;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] ps3_gelic: Fix start_xmit kick error path
From: Andre Heider @ 2011-07-12 20:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: netdev, cbe-oss-dev, Andre Heider
In-Reply-To: <1310501606-829-1-git-send-email-a.heider@gmail.com>
Revert to a proper state when gelic_card_kick_txdma() fails:
- Don't trigger BUG_ON when releasing the unsent tx descriptor
- Reset the tx chain head since the tail was not modified and
hence not in sync
- Unlink the released descriptor bus address from its predecessor
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
drivers/net/ps3_gelic_net.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index 9652d10..94422fc 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -897,12 +897,16 @@ int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
if (gelic_card_kick_txdma(card, descr)) {
/*
* kick failed.
- * release descriptors which were just prepared
+ * release descriptor which was just prepared
*/
netdev->stats.tx_dropped++;
+ /* don't trigger BUG_ON() in gelic_descr_release_tx */
+ descr->data_status = cpu_to_be32(GELIC_DESCR_TX_TAIL);
gelic_descr_release_tx(card, descr);
- gelic_descr_release_tx(card, descr->next);
- card->tx_chain.tail = descr->next->next;
+ /* reset head */
+ card->tx_chain.head = descr;
+ /* reset hw termination */
+ descr->prev->next_descr_addr = 0;
dev_info(ctodev(card), "%s: kick failure\n", __func__);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/3] ps3_gelic: Fix typos
From: Andre Heider @ 2011-07-12 20:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: netdev, cbe-oss-dev, Andre Heider
In-Reply-To: <1310501606-829-1-git-send-email-a.heider@gmail.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
drivers/net/ps3_gelic_net.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index 35e47c3..9652d10 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -876,7 +876,7 @@ int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
result = gelic_descr_prepare_tx(card, descr, skb);
if (result) {
/*
- * DMA map failed. As chanses are that failure
+ * DMA map failed. As chances are that failure
* would continue, just release skb and return
*/
netdev->stats.tx_dropped++;
@@ -1041,7 +1041,7 @@ static int gelic_card_decode_one_descr(struct gelic_card *card)
goto refill;
}
/*
- * descriptoers any other than FRAME_END here should
+ * descriptors any other than FRAME_END here should
* be treated as error.
*/
if (status != GELIC_DESCR_DMA_FRAME_END) {
@@ -1200,7 +1200,7 @@ void gelic_net_poll_controller(struct net_device *netdev)
#endif /* CONFIG_NET_POLL_CONTROLLER */
/**
- * gelic_net_open - called upon ifonfig up
+ * gelic_net_open - called upon ifconfig up
* @netdev: interface device structure
*
* returns 0 on success, <0 on failure
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/3] ps3_gelic: Fix error paths when a tx dma fails
From: Andre Heider @ 2011-07-12 20:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: netdev, cbe-oss-dev, Andre Heider
This series fixes a few bugs for the error paths once a tx dma request
fails. Without these I either ran into BUG_ON, the device got killed,
or the kernel crashed.
Note about #2:
I'm not sure what "gelic_descr_release_tx(card, descr->next)"
was doing there, ->next was never touched. Did i miss something?
Andre Heider (3):
ps3_gelic: Fix typos
ps3_gelic: Fix start_xmit kick error path
ps3_gelic: Don't kill the device on DMA failure
drivers/net/ps3_gelic_net.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
--
1.7.5.4
^ permalink raw reply
* Re: softirqs are invoked while bottom halves are masked (was: Re: [PATCH] [PATCH] Fix deadlock in af_packet while stressing raw ethernet socket interface)
From: Ronny Meeus @ 2011-07-12 19:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas De Schampheleire, linuxppc-dev, David Miller, netdev,
afleming
In-Reply-To: <1310484474.2871.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, Jul 12, 2011 at 5:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 12 juillet 2011 à 14:03 +0200, Ronny Meeus a écrit :
>
>> Sorry for not mentioning we were using a patched kernel.
>> I was not aware that the code involved was patched by the FreeScale
>> patches we applied. The code found in the stack dumps is not
>> implemented in FSL specific files.
>>
>> While reading the code of af_packet I saw that the spin_lock_bh is
>> used in several places while this is not the case in the tpacket_rcv
>> function. Since we had a locking issue in that code, I thought that my
>> patch would be OK.
>> I was not aware that for that specific function (tpacket_rcv) a
>> different lock primitive must be used. A suggestion for improvement:
>> it would be better to document this pre-condition in the code.
>>
>> After doing the change you proposed our code now looks like:
>>
>> >---if (dev->features & NETIF_F_HW_QDISC) {
>> >--->---txq = dev_pick_tx(dev, skb);
>> >--->---local_bh_disable();
>> >--->---rc = dev_hard_start_xmit(skb, dev, txq);
>> >--->---local_bh_enable();
>> >--->---return rc;
>> >---}
>>
>> >---/* Disable soft irqs for various locks below. Also
>> >--- * stops preemption for RCU.
>> >--- */
>> >---rcu_read_lock_bh();
>>
>> but we still see the issue "BUG: sleeping function called from invalid context":
>
> Of course you are if this is the only change you did.
>
>>
>> [ 91.015989] BUG: sleeping function called from invalid context at
>> include/linux/skbuff.h:786
>> [ 91.117096] in_atomic(): 1, irqs_disabled(): 0, pid: 1865, name: NMTX_T1842
>> [ 91.200461] Call Trace:
>> [ 91.229672] [ec58bbd0] [c000789c] show_stack+0x78/0x18c (unreliable)
>> [ 91.305791] [ec58bc10] [c0022900] __might_sleep+0x100/0x118
>> [ 91.372524] [ec58bc20] [c029f8d8] dpa_tx+0x128/0x758
>
>
> Please read again my mail :
>
> I said : "doing GFP_KERNEL allocations in dpa_tx() is wrong, for sure."
>
> I dont have this code, but I suspect it's using : skb_copy(skb,
> GFP_KERNEL)
>
> Just say no, use GFP_ATOMIC instead.
>
> Real question is : why skb_copy() is done, since its slow as hell.
>
>> [ 91.431957] [ec58bc80] [c02d78ec] dev_hard_start_xmit+0x424/0x588
>> [ 91.504952] [ec58bcc0] [c02d7ab0] dev_queue_xmit+0x60/0x3ac
>> [ 91.571692] [ec58bcf0] [c0338d54] packet_sendmsg+0x8c4/0x988
>> [ 91.639457] [ec58bd70] [c02c3838] sock_sendmsg+0x90/0xb4
>> [ 91.703066] [ec58be40] [c02c4420] sys_sendto+0xdc/0x120
>> [ 91.765646] [ec58bf10] [c02c57d0] sys_socketcall+0x148/0x210
>> [ 91.833420] [ec58bf40] [c001084c] ret_from_syscall+0x0/0x3c
>> [ 91.900153] --- Exception: c01 at 0x4824df00
>> [ 91.900157] LR = 0x4828a030
>>
>
>
>
I have identified the piece of code, it was a call to skb_unshare. I
have changed it into GFP_ATOMIC.
>---if (skb_cloned(skb))
>--->---skb = skb_unshare(skb, GFP_ATOMIC);
After doing this change, I do not see the issue anymore. At least not
for the test I'm doing right now.
After seeing all your comments today, it might be that other issues popup later.
BTW Are there any good sites (or books) that document this part of the
Linux kernel?
Best regards,
Ronny
^ permalink raw reply
* [PATCH v2] net: Add documentation for netdev features handling
From: Michał Mirosław @ 2011-07-12 19:41 UTC (permalink / raw)
To: netdev
Cc: Ben Greear, Stephen Hemminger, Ben Hutchings, Donald Skidmore,
Jeff Kirsher, David S. Miller, Randy Dunlap
In-Reply-To: <f95d92bfa1d8760db6ae0dbff67bb0e85eb77a2d.1310496866.git.mirq-linux@rere.qmqm.pl>
v2: incorporated suggestions from Randy Dunlap
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
Documentation/networking/netdev-features.txt | 155 ++++++++++++++++++++++++++
1 files changed, 155 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
new file mode 100644
index 0000000..1ade16c
--- /dev/null
+++ b/Documentation/networking/netdev-features.txt
@@ -0,0 +1,155 @@
+Netdev features mess and how to get out from it alive
+=====================================================
+
+Author:
+ Michał Mirosław <mirq-linux@rere.qmqm.pl>
+
+
+
+ Part I: Feature sets
+======================
+
+Long gone are the days when a network card would just take and give packets
+verbatim. Today's devices add multiple features and bugs (read: offloads)
+that relieve an OS of various tasks like generating and checking checksums,
+splitting packets, classifying them. Those capabilities and their state
+are commonly referred to as netdev features in Linux kernel world.
+
+There are currently three sets of features relevant to the driver, and
+one used internally by network core:
+
+ 1. netdev->hw_features set contains features whose state may possibly
+ be changed (enabled or disabled) for a particular device by user's
+ request. This set should be initialized in ndo_init callback and not
+ changed later.
+
+ 2. netdev->features set contains features which are currently enabled
+ for a device. This should be changed only by network core or in
+ error paths of ndo_set_features callback.
+
+ 3. netdev->vlan_features set contains features whose state is inherited
+ by child VLAN devices (limits netdev->features set). This is currently
+ used for all VLAN devices whether tags are stripped or inserted in
+ hardware or software.
+
+ 4. netdev->wanted_features set contains feature set requested by user.
+ This set is filtered by ndo_fix_features callback whenever it or
+ some device-specific conditions change. This set is internal to
+ networking core and should not be referenced in drivers.
+
+
+
+ Part II: Controlling enabled features
+=======================================
+
+When current feature set (netdev->features) is to be changed, new set
+is calculated and filtered by calling ndo_fix_features callback
+and netdev_fix_features(). If the resulting set differs from current
+set, it is passed to ndo_set_features callback and (if the callback
+returns success) replaces value stored in netdev->features.
+NETDEV_FEAT_CHANGE notification is issued after that whenever current
+set might have changed.
+
+The following events trigger recalculation:
+ 1. device's registration, after ndo_init returned success
+ 2. user requested changes in features state
+ 3. netdev_update_features() is called
+
+ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks
+are treated as always returning success.
+
+A driver that wants to trigger recalculation must do so by calling
+netdev_update_features() while holding rtnl_lock. This should not be done
+from ndo_*_features callbacks. netdev->features should not be modified by
+driver except by means of ndo_fix_features callback.
+
+
+
+ Part III: Implementation hints
+================================
+
+ * ndo_fix_features:
+
+All dependencies between features should be resolved here. The resulting
+set can be reduced further by networking core imposed limitations (as coded
+in netdev_fix_features()). For this reason it is safer to disable a feature
+when its dependencies are not met instead of forcing the dependency on.
+
+This callback should not modify hardware nor driver state (should be
+stateless). It can be called multiple times between successive
+ndo_set_features calls.
+
+Callback must not alter features contained in NETIF_F_SOFT_FEATURES or
+NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but
+care must be taken as the change won't affect already configured VLANs.
+
+ * ndo_set_features:
+
+Hardware should be reconfigured to match passed feature set. The set
+should not be altered unless some error condition happens that can't
+be reliably detected in ndo_fix_features. In this case, the callback
+should update netdev->features to match resulting hardware state.
+Errors returned are not (and cannot be) propagated anywhere except dmesg.
+(Note: successful return is zero, >0 means silent error.)
+
+
+
+ Part IV: Features
+===================
+
+For current list of features, see include/linux/netdev_features.h.
+This section describes semantics of some of them.
+
+ * Transmit checksumming
+
+For complete description, see comments near the top of include/linux/skbuff.h.
+
+Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM.
+It means that device can fill TCP/UDP-like checksum anywhere in the packets
+whatever headers there might be.
+
+ * Transmit TCP segmentation offload
+
+NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit
+set, be it TCPv4 (when NETIF_F_TSO is enabled) or TCPv6 (NETIF_F_TSO6).
+
+ * Transmit DMA from high memory
+
+On platforms where this is relevant, NETIF_F_HIGHDMA signals that
+ndo_start_xmit can handle skbs with frags in high memory.
+
+ * Transmit scatter-gather
+
+Those features say that ndo_start_xmit can handle fragmented skbs:
+NETIF_F_SG --- paged skbs (skb_shinfo()->frags), NETIF_F_FRAGLIST ---
+chained skbs (skb->next/prev list).
+
+ * Software features
+
+Features contained in NETIF_F_SOFT_FEATURES are features of networking
+stack. Driver should not change behaviour based on them.
+
+ * LLTX driver (deprecated for hardware drivers)
+
+NETIF_F_LLTX should be set in drivers that implement their own locking in
+transmit path or don't need locking at all (e.g. software tunnels).
+In ndo_start_xmit, it is recommended to use a try_lock and return
+NETDEV_TX_LOCKED when the spin lock fails. The locking should also properly
+protect against other callbacks (the rules you need to find out).
+
+Don't use it for new drivers.
+
+ * netns-local device
+
+NETIF_F_NETNS_LOCAL is set for devices that are not allowed to move between
+network namespaces (e.g. loopback).
+
+Don't use it in drivers.
+
+ * VLAN challenged
+
+NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope with VLAN
+headers. Some drivers set this because the cards can't handle the bigger MTU.
+[FIXME: Those cases could be fixed in VLAN code by allowing only reduced-MTU
+VLANs. This may be not useful, though.]
+
--
1.7.5.4
^ permalink raw reply related
* Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage
From: Ralf Baechle @ 2011-07-12 19:32 UTC (permalink / raw)
To: Felix Fietkau
Cc: Michał Mirosław, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
Senthil Balasubramanian, ath9k-devel-juf53994utBLZpfksSYvnA,
Vasanthakumar Thiagarajan
In-Reply-To: <4E1BCF36.2010506-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
> >diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> >index 70dc8ec..c5f46d5 100644
> >--- a/drivers/net/wireless/ath/ath9k/recv.c
> >+++ b/drivers/net/wireless/ath/ath9k/recv.c
> >@@ -684,15 +684,11 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
> > BUG_ON(!bf);
> >
> > dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
> >- common->rx_bufsize, DMA_FROM_DEVICE);
> >+ common->rx_bufsize, DMA_BIDIRECTIONAL);
> >
> > ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb->data);
> >- if (ret == -EINPROGRESS) {
> >- /*let device gain the buffer again*/
> >- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
> >- common->rx_bufsize, DMA_FROM_DEVICE);
> >+ if (ret == -EINPROGRESS)
> > return false;
> >- }
> >
> > __skb_unlink(skb,&rx_edma->rx_fifo);
> > if (ret == -EINVAL) {
> I have strong doubts about this change. On most MIPS devices,
> dma_sync_single_for_cpu is a no-op, whereas
> dma_sync_single_for_device flushes the cache range. With this
> change, the CPU could cache the DMA status part behind skb->data and
> that cache entry would not be flushed inbetween calls to this
> functions on the same buffer, likely leading to rx stalls.
The code was already broken before. By the time dma_sync_single_for_cpu
and ath9k_hw_process_rxdesc_edma are called, the DMA engine may still be
active in the buffer, yet the driver is looking at it.
dma_sync_single_for_cpu() is part of changing the buffer ownership from
the device to the CPU. When it is being called, DMA into the buffer should
already have been completed ... or else the shit may hit the jet engine.
Imagine what would happen on a hypothetic cache architecture which does not
have a dirty bit, that is which would have to write back every cache line -
even clean lines - to memory in order to evict it. Corruption.
And don't argue with what the actual MIPS implementation of dma_sync_single_-
for-{cpu,device} is doing. It's meant to bee treated as a black box; that
abstraction is the whole point of the ABI. And it seems the driver is also
being used on other architectures than MIPS …
Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: Add documentation for netdev features handling
From: Randy Dunlap @ 2011-07-12 19:19 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev, Ben Greear, Stephen Hemminger, Ben Hutchings,
Donald Skidmore, Jeff Kirsher, David S. Miller
In-Reply-To: <f95d92bfa1d8760db6ae0dbff67bb0e85eb77a2d.1310496866.git.mirq-linux@rere.qmqm.pl>
On Tue, 12 Jul 2011 21:01:30 +0200 (CEST) Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>
> Please comment if something is unclear!
> Apply otherwise. ;)
>
> ---
> Documentation/networking/netdev-features.txt | 155 ++++++++++++++++++++++++++
> 1 files changed, 155 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
> new file mode 100644
> index 0000000..9c209e6
> --- /dev/null
> +++ b/Documentation/networking/netdev-features.txt
> @@ -0,0 +1,155 @@
> +Netdev features mess and how to get out from it alive
> +=====================================================
> +
> +Author:
> + Michał Mirosław <mirq-linux@rere.qmqm.pl>
> +
> +
> +
> + Part I: Feature sets
> +======================
> +
> +Long gone are days, when a network card would just take and give packets
Long gone are the days when
> +verbatim. Todays devices add multiple features and bugs (read: offloads)
Today's
> +that relieves OS of various tasks like generating and checking checksums,
relieve an OS
> +splitting packets, classifying them. Those capabilities and their state
> +is commonly referred to as netdev features in Linux kernel world.
are
> +
> +There are currently three sets of features relevant to the driver, and
> +one used internally by network core:
> +
> + 1. netdev->hw_features set contains features whose state may possibly
> + be changed (enabled or disabled) for a particular device by user's
> + request. This set should be initialized in ndo_init callback and not
> + changed later.
> +
> + 2. netdev->features set contains features which are currently enabled
> + for a device. This should be changed only by network core or in
> + error paths of ndo_set_features callback.
> +
> + 3. netdev->vlan_features set contains features whose state is inherited
> + by child VLAN devices (limits netdev->features set). This is currently
> + used for all VLAN devices whether tags are stripped or inserted in
> + hardware or software.
> +
> + 4. netdev->wanted_features set contains feature set requested by user.
> + This set is filtered by ndo_fix_features callback whenever it or
> + some device-specific conditions change. This set is internal to
> + networking core and should not be referenced in drivers.
> +
> +
> +
> + Part II: Controlling enabled features
> +=======================================
> +
> +When current feature set (netdev->features) is to be changed, new set
> +is calculated and filtered by calling ndo_fix_features callback
> +and netdev_fix_features(). If the resulting set differs from current
> +set, it is passed to ndo_set_features callback and (if the callback
> +returns success) replaces value stored in netdev->features.
> +NETDEV_FEAT_CHANGE notification is issued after that whenever current
> +set might have changed.
> +
> +Following events trigger recalculation:
The following events ...
> + 1. device's registration, after ndo_init returned success
> + 2. user requested changes in features state
> + 3. netdev_update_features() is called
> +
> +ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks
> +are treated as always returning success.
> +
> +Driver wanting to trigger recalculation must do so by calling
A driver that wants to trigger ...
> +netdev_update_features() while holding rtnl_lock. This should not be done
> +from ndo_*_features callbacks. netdev->features should not be modified by
> +driver except by means of ndo_fix_features callback.
> +
> +
> +
> + Part III: Implementation hints
> +================================
> +
> + * ndo_fix_features:
> +
> +All dependencies between features should be resolved here. The resulting
> +set can be reduced further by networking core imposed limitations (as coded
> +in netdev_fix_features()). For this reason its safer to disable a feature
it is
> +when its dependencies are not met instead of forcing the dependency on.
> +
> +This callback should not modify hardware nor driver state (should be
> +stateless). It can be called multiple times between successive
> +ndo_set_features calls.
> +
> +Callback must not alter features contained in NETIF_F_SOFT_FEATURES or
> +NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but
> +care must be taken as the change won't affect already configured VLANs.
> +
> + * ndo_set_features:
> +
> +Hardware should be reconfigured to match passed feature set. The should not
The <what> should not
> +be altered unless some error condition happens that can't be reliably
> +detected in ndo_fix_features. In this case, the callback should update
> +netdev->features to match resulting hardware state. Errors returned are
> +not (and cannot be) propagated anywhere except dmesg. (Note: successful
> +return is zero, >0 is silent error.)
> +
> +
> +
> + Part IV: Features
> +===================
> +
> +For current list of features, see include/linux/netdev_features.h.
> +This section describes semantics of some of them.
> +
> + * Transmit checksumming
> +
> +For complete description, see comments near the top of include/linux/skbuff.h.
> +
> +Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM.
> +It means that device can fill TCP/UDP-like checksum anywhere in the packets
> +whatever headers there might be.
> +
> + * Transmit TCP segmentation offload
> +
> +NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit
> +set, be it TCPv4 (when NETIF_F_TSO is enabled) or TCPv6 (NETIF_F_TSO6).
> +
> + * Transmit DMA from high memory
> +
> +On platforms where this is relevant, NETIF_F_HIGHDMA signals that
> +ndo_start_xmit can handle skbs with frags in high memory.
> +
> + * Transmit scatter-gather
> +
> +Those features say that ndo_start_xmit can handle fragmented skbs:
> +NETIF_F_SG --- paged skbs (skb_shinfo()->frags), NETIF_F_FRAGLIST ---
> +chained skbs (skb->next/prev list).
> +
> + * Software features
> +
> +Features contained in NETIF_F_SOFT_FEATURES are a features of networking
^ drop "a"
> +stack. Driver should not change behaviour based on them.
> +
> + * LLTX driver (deprecated for hardware drivers)
> +
> +NETIF_F_LLTX should be set in drivers that implement their own locking in
> +transmit path or don't need locking at all (e.g. software tunnels).
> +In ndo_start_xmit, it is recommended to use a try_lock and return
> +NETDEV_TX_LOCKED when the spin lock fails. The locking should also properly
> +protect against other callbacks (the rules you need to find out).
> +
> +Don't use it for new drivers.
> +
> + * netns-local device
> +
> +NETIF_F_NETNS_LOCAL is set for devices that are not allowed to move between
> +network namespaces (e.g. loopback).
> +
> +Don't use it in drivers.
> +
> + * VLAN challenged
> +
> +NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope with VLAN
> +headers. Some drivers set this because the cards can't handle the bigger MTU.
> +[FIXME: Those cases could be fixed in VLAN code by allowing only reduced-MTU
> +VLANs. This may be not usefull, though.]
useful
> +
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: netdevice: Kill 'feature' test macros.
From: David Miller @ 2011-07-12 19:18 UTC (permalink / raw)
To: arnd; +Cc: shemminger, netdev
In-Reply-To: <201107122106.21570.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 12 Jul 2011 21:06:21 +0200
> On Tuesday 12 July 2011 20:10:33 Stephen Hemminger wrote:
>> On Tue, 12 Jul 2011 10:50:05 -0700 (PDT)
>> David Miller <davem@davemloft.net> wrote:
>>
>> >
>> > Almost all of these have long outstayed their welcome.
>> >
>> > And for every one of these macros, there are 10 features for which we
>> > didn't get macros added.
>> >
>> > Let's just delete them all, and get out of habit of doing things this
>> > way.
>> >
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> This is sure to break out of tree drivers...
>
> I guess that's a good thing, but it also breaks these:
>
> drivers/staging/wlags49_h2/wl_internal.h:#ifdef HAVE_NETDEV_PRIV
> drivers/net/cxgb4vf/cxgb4vf_main.c:#ifdef HAVE_NET_DEVICE_OPS
> drivers/staging/ft1000/ft1000-usb/ft1000_hw.c:#ifdef HAVE_NET_DEVICE_OPS
> net/batman-adv/soft-interface.c:#ifdef HAVE_NET_DEVICE_OPS
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> if the above are taken care of.
Thanks for catching this Arnd.
^ permalink raw reply
* Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage
From: Michał Mirosław @ 2011-07-12 19:13 UTC (permalink / raw)
To: Felix Fietkau
Cc: Felix Fietkau, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Jouni Malinen,
Senthil Balasubramanian, ath9k-devel@lists.ath9k.org,
Vasanthakumar Thiagarajan, Ralf Baechle,
linux-mips@linux-mips.org
In-Reply-To: <57124BD4-F53A-4424-A61F-5D8E629EB36F@nbd.name>
On Wed, Jul 13, 2011 at 12:04:50AM +0800, Felix Fietkau wrote:
> On 12.07.2011, at 23:58, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> > On Tue, Jul 12, 2011 at 10:21:05PM +0800, Felix Fietkau wrote:
> >> On 12.07.2011, at 21:03, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >>
> >>> On Tue, Jul 12, 2011 at 08:54:32PM +0800, Felix Fietkau wrote:
> >>>> On 12.07.2011, at 17:55, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >>>>
> >>>>> On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
> >>>>>> On 2011-07-11 8:52 AM, Michał Mirosław wrote:
> >>>>>>> Also constify buf_addr for ath9k_hw_process_rxdesc_edma() to verify
> >>>>>>> assumptions --- dma_sync_single_for_device() call can be removed.
> >>>>>>>
> >>>>>>> Signed-off-by: Michał Mirosław<mirq-linux@rere.qmqm.pl>
> >>>>>>> ---
> >>>>>>> drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++--
> >>>>>>> drivers/net/wireless/ath/ath9k/ar9003_mac.h | 2 +-
> >>>>>>> drivers/net/wireless/ath/ath9k/recv.c | 10 +++-------
> >>>>>>> 3 files changed, 6 insertions(+), 10 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> >>>>>>> index 70dc8ec..c5f46d5 100644
> >>>>>>> --- a/drivers/net/wireless/ath/ath9k/recv.c
> >>>>>>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> >>>>>>> @@ -684,15 +684,11 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
> >>>>>>> BUG_ON(!bf);
> >>>>>>>
> >>>>>>> dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
> >>>>>>> - common->rx_bufsize, DMA_FROM_DEVICE);
> >>>>>>> + common->rx_bufsize, DMA_BIDIRECTIONAL);
> >>>>>>>
> >>>>>>> ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb->data);
> >>>>>>> - if (ret == -EINPROGRESS) {
> >>>>>>> - /*let device gain the buffer again*/
> >>>>>>> - dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
> >>>>>>> - common->rx_bufsize, DMA_FROM_DEVICE);
> >>>>>>> + if (ret == -EINPROGRESS)
> >>>>>>> return false;
> >>>>>>> - }
> >>>>>>>
> >>>>>>> __skb_unlink(skb,&rx_edma->rx_fifo);
> >>>>>>> if (ret == -EINVAL) {
> >>>>>> I have strong doubts about this change. On most MIPS devices,
> >>>>>> dma_sync_single_for_cpu is a no-op, whereas
> >>>>>> dma_sync_single_for_device flushes the cache range. With this
> >>>>>> change, the CPU could cache the DMA status part behind skb->data and
> >>>>>> that cache entry would not be flushed inbetween calls to this
> >>>>>> functions on the same buffer, likely leading to rx stalls.
> >>>>> You're suggesting a platform implementation bug then. If the platform is not
> >>>>> cache-coherent, it should invalidate relevant CPU cache lines for sync_to_cpu
> >>>>> and unmap cases. Do other devices show such symptoms on MIPS systems?
> >>>>>
> >>>>> I'm not familiar with the platform internals, so we should ask MIPS people.
> >>>> I only mentioned MIPS to describe the potential side effect of this change. From my current understanding of the DMA API, it would be wrong on other platforms as well. I believe the _for_device function needs to be used to transfer ownership of the buffer back to the device, before calling _for_cpu again later for another read.
> >>> What you're saying reminds the wording in DMA-API-HOWTO.txt that I find
> >>> wrong (or at least misleading) compared to what DMA-API.txt describes.
> >>> DMA sync calls do not transfer the ownership of the buffer - they are
> >>> cache synchronization points, ownership passing is handled entirely by
> >>> the driver.
> >> What I meant was that the DMA sync calls reflect the ownership transfer of the memory regions. In this case ownership is transferred between device and CPU multiple times and the code reflects that.
> >>>> This is definitely required in this case, because when the return code is -EINPROGRESS, the driver waits for the hardware to complete this buffer, and the next call has to fetch the memory again after the device has updated it.
> >>> Correctness of this access should be provided by sync_to_cpu() call.
> >> At least in MIPS I'm sure it isn't. If I remember correctly, it also isn't on ARM, so I'm pretty sure that either your understanding of the API is incorrect, or arch code does not implement it properly. In either case, this change (and probably also the p54 one) should not be merged.
> >
> > I briefly looked through DMA API implementation in MIPS, and except
> > for R10k and R12k both sync_for_cpu and sync_for_device are no-ops
> > (see: arch/mips/mm/dma-default.c). For R10k and R12k the syncs are
> > in both points, and exactly like I described before - CPU cachelines
> > are invalidated for DMA_FROM_DEVICE mappings, written back for
> > DMA_TO_DEVICE, both for DMA_BIDIRECTIONAL (including redundant
> > mapping+sync direction).
> >
> > So doing that sync_to_device you are just invalidating the same cachelines
> > twice for no gain (or do nothing twice in some cases) - they are not read
> > by CPU between sync_to_device -> sync_to_cpu (unless you have other bugs
> > in the driver).
> I think you're missing something. It works like this: In the AR9380 rx path, the descriptor is part of the skb. The rx tasklet checks for rx frame completion by calling the sync for cpu, reading the completion flag and (in case of a not completed frame) flushes the cache for that location again (for device). If you remove the for_device call, the next call to this function can see stale data, as the for_cpu call can be a no-op.
Is the descriptor modified in any way before being checked again? Looks like
it isn't. That is my assumption - if this doesn't hold, then we're talking
about different things.
When I looked through the DMA API implementation for MIPS, I saw that whenever
sync_to_cpu is a no-op, sync_to_device is also a no-op. So the bug you're
seeing is not related to those calls. It might be that despite no-op sync
primitives, the platform is not cache-coherent --- that is DMA writes by
device do not cause corresponding CPU cache lines to be invalidated.
BTW, cache flush (other name: invalidation) is needed just before reading the
value. Doing it once more earlier does not really matter. Unless you're
modifying some data in the same cache line as mapped buffer --- then this
is a BUG in the driver and should either use DMA_BIDIRECTIONAL if the modified
value is part of the buffer, or move the modified data away.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: netdevice: Kill 'feature' test macros.
From: Arnd Bergmann @ 2011-07-12 19:11 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <20110712120923.e90730f8.rdunlap@xenotime.net>
On Tuesday 12 July 2011 21:09:23 Randy Dunlap wrote:
> >
> > I guess that's a good thing, but it also breaks these:
> >
> > drivers/staging/wlags49_h2/wl_internal.h:#ifdef HAVE_NETDEV_PRIV
> > drivers/net/cxgb4vf/cxgb4vf_main.c:#ifdef HAVE_NET_DEVICE_OPS
> > drivers/staging/ft1000/ft1000-usb/ft1000_hw.c:#ifdef HAVE_NET_DEVICE_OPS
> > net/batman-adv/soft-interface.c:#ifdef HAVE_NET_DEVICE_OPS
>
> Really? I thought it would only break:
>
> #if UNKNOWN_SYMBOL
> but not
> #ifdef UNKNOWN_SYMBOL
The point is that the drivers expect the symbol to be defined, e.g.
#ifdef HAVE_NETDEV_PRIV
#define wl_priv(dev) ((struct wl_private *) netdev_priv(dev))
#else
extern inline struct wl_private *wl_priv(struct net_device *dev)
{
return dev->priv;
}
#endif
With current Linux versions, the first one is correct, the second one
is wrong, and removing the symbol changes which one is used.
Arnd
^ permalink raw reply
* Re: netdevice: Kill 'feature' test macros.
From: Randy Dunlap @ 2011-07-12 19:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <201107122106.21570.arnd@arndb.de>
On Tue, 12 Jul 2011 21:06:21 +0200 Arnd Bergmann wrote:
> On Tuesday 12 July 2011 20:10:33 Stephen Hemminger wrote:
> > On Tue, 12 Jul 2011 10:50:05 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> > >
> > > Almost all of these have long outstayed their welcome.
> > >
> > > And for every one of these macros, there are 10 features for which we
> > > didn't get macros added.
> > >
> > > Let's just delete them all, and get out of habit of doing things this
> > > way.
> > >
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > This is sure to break out of tree drivers...
>
> I guess that's a good thing, but it also breaks these:
>
> drivers/staging/wlags49_h2/wl_internal.h:#ifdef HAVE_NETDEV_PRIV
> drivers/net/cxgb4vf/cxgb4vf_main.c:#ifdef HAVE_NET_DEVICE_OPS
> drivers/staging/ft1000/ft1000-usb/ft1000_hw.c:#ifdef HAVE_NET_DEVICE_OPS
> net/batman-adv/soft-interface.c:#ifdef HAVE_NET_DEVICE_OPS
Really? I thought it would only break:
#if UNKNOWN_SYMBOL
but not
#ifdef UNKNOWN_SYMBOL
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> if the above are taken care of.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: netdevice: Kill 'feature' test macros.
From: Arnd Bergmann @ 2011-07-12 19:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110712111033.6e3923db@nehalam.ftrdhcpuser.net>
On Tuesday 12 July 2011 20:10:33 Stephen Hemminger wrote:
> On Tue, 12 Jul 2011 10:50:05 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> >
> > Almost all of these have long outstayed their welcome.
> >
> > And for every one of these macros, there are 10 features for which we
> > didn't get macros added.
> >
> > Let's just delete them all, and get out of habit of doing things this
> > way.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>
> This is sure to break out of tree drivers...
I guess that's a good thing, but it also breaks these:
drivers/staging/wlags49_h2/wl_internal.h:#ifdef HAVE_NETDEV_PRIV
drivers/net/cxgb4vf/cxgb4vf_main.c:#ifdef HAVE_NET_DEVICE_OPS
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c:#ifdef HAVE_NET_DEVICE_OPS
net/batman-adv/soft-interface.c:#ifdef HAVE_NET_DEVICE_OPS
Acked-by: Arnd Bergmann <arnd@arndb.de>
if the above are taken care of.
^ permalink raw reply
* [PATCH] net: Add documentation for netdev features handling
From: Michał Mirosław @ 2011-07-12 19:01 UTC (permalink / raw)
To: netdev
Cc: Ben Greear, Stephen Hemminger, Ben Hutchings, Donald Skidmore,
Jeff Kirsher, David S. Miller
In-Reply-To: <1310487816.2732.13.camel@bwh-desktop>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
Please comment if something is unclear!
Apply otherwise. ;)
---
Documentation/networking/netdev-features.txt | 155 ++++++++++++++++++++++++++
1 files changed, 155 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
new file mode 100644
index 0000000..9c209e6
--- /dev/null
+++ b/Documentation/networking/netdev-features.txt
@@ -0,0 +1,155 @@
+Netdev features mess and how to get out from it alive
+=====================================================
+
+Author:
+ Michał Mirosław <mirq-linux@rere.qmqm.pl>
+
+
+
+ Part I: Feature sets
+======================
+
+Long gone are days, when a network card would just take and give packets
+verbatim. Todays devices add multiple features and bugs (read: offloads)
+that relieves OS of various tasks like generating and checking checksums,
+splitting packets, classifying them. Those capabilities and their state
+is commonly referred to as netdev features in Linux kernel world.
+
+There are currently three sets of features relevant to the driver, and
+one used internally by network core:
+
+ 1. netdev->hw_features set contains features whose state may possibly
+ be changed (enabled or disabled) for a particular device by user's
+ request. This set should be initialized in ndo_init callback and not
+ changed later.
+
+ 2. netdev->features set contains features which are currently enabled
+ for a device. This should be changed only by network core or in
+ error paths of ndo_set_features callback.
+
+ 3. netdev->vlan_features set contains features whose state is inherited
+ by child VLAN devices (limits netdev->features set). This is currently
+ used for all VLAN devices whether tags are stripped or inserted in
+ hardware or software.
+
+ 4. netdev->wanted_features set contains feature set requested by user.
+ This set is filtered by ndo_fix_features callback whenever it or
+ some device-specific conditions change. This set is internal to
+ networking core and should not be referenced in drivers.
+
+
+
+ Part II: Controlling enabled features
+=======================================
+
+When current feature set (netdev->features) is to be changed, new set
+is calculated and filtered by calling ndo_fix_features callback
+and netdev_fix_features(). If the resulting set differs from current
+set, it is passed to ndo_set_features callback and (if the callback
+returns success) replaces value stored in netdev->features.
+NETDEV_FEAT_CHANGE notification is issued after that whenever current
+set might have changed.
+
+Following events trigger recalculation:
+ 1. device's registration, after ndo_init returned success
+ 2. user requested changes in features state
+ 3. netdev_update_features() is called
+
+ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks
+are treated as always returning success.
+
+Driver wanting to trigger recalculation must do so by calling
+netdev_update_features() while holding rtnl_lock. This should not be done
+from ndo_*_features callbacks. netdev->features should not be modified by
+driver except by means of ndo_fix_features callback.
+
+
+
+ Part III: Implementation hints
+================================
+
+ * ndo_fix_features:
+
+All dependencies between features should be resolved here. The resulting
+set can be reduced further by networking core imposed limitations (as coded
+in netdev_fix_features()). For this reason its safer to disable a feature
+when its dependencies are not met instead of forcing the dependency on.
+
+This callback should not modify hardware nor driver state (should be
+stateless). It can be called multiple times between successive
+ndo_set_features calls.
+
+Callback must not alter features contained in NETIF_F_SOFT_FEATURES or
+NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but
+care must be taken as the change won't affect already configured VLANs.
+
+ * ndo_set_features:
+
+Hardware should be reconfigured to match passed feature set. The should not
+be altered unless some error condition happens that can't be reliably
+detected in ndo_fix_features. In this case, the callback should update
+netdev->features to match resulting hardware state. Errors returned are
+not (and cannot be) propagated anywhere except dmesg. (Note: successful
+return is zero, >0 is silent error.)
+
+
+
+ Part IV: Features
+===================
+
+For current list of features, see include/linux/netdev_features.h.
+This section describes semantics of some of them.
+
+ * Transmit checksumming
+
+For complete description, see comments near the top of include/linux/skbuff.h.
+
+Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM.
+It means that device can fill TCP/UDP-like checksum anywhere in the packets
+whatever headers there might be.
+
+ * Transmit TCP segmentation offload
+
+NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit
+set, be it TCPv4 (when NETIF_F_TSO is enabled) or TCPv6 (NETIF_F_TSO6).
+
+ * Transmit DMA from high memory
+
+On platforms where this is relevant, NETIF_F_HIGHDMA signals that
+ndo_start_xmit can handle skbs with frags in high memory.
+
+ * Transmit scatter-gather
+
+Those features say that ndo_start_xmit can handle fragmented skbs:
+NETIF_F_SG --- paged skbs (skb_shinfo()->frags), NETIF_F_FRAGLIST ---
+chained skbs (skb->next/prev list).
+
+ * Software features
+
+Features contained in NETIF_F_SOFT_FEATURES are a features of networking
+stack. Driver should not change behaviour based on them.
+
+ * LLTX driver (deprecated for hardware drivers)
+
+NETIF_F_LLTX should be set in drivers that implement their own locking in
+transmit path or don't need locking at all (e.g. software tunnels).
+In ndo_start_xmit, it is recommended to use a try_lock and return
+NETDEV_TX_LOCKED when the spin lock fails. The locking should also properly
+protect against other callbacks (the rules you need to find out).
+
+Don't use it for new drivers.
+
+ * netns-local device
+
+NETIF_F_NETNS_LOCAL is set for devices that are not allowed to move between
+network namespaces (e.g. loopback).
+
+Don't use it in drivers.
+
+ * VLAN challenged
+
+NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope with VLAN
+headers. Some drivers set this because the cards can't handle the bigger MTU.
+[FIXME: Those cases could be fixed in VLAN code by allowing only reduced-MTU
+VLANs. This may be not usefull, though.]
+
--
1.7.5.4
^ permalink raw reply related
* Re: netdevice: Kill 'feature' test macros.
From: Stephen Hemminger @ 2011-07-12 18:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110712.105005.34046159802896038.davem@davemloft.net>
On Tue, 12 Jul 2011 10:50:05 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
>
> Almost all of these have long outstayed their welcome.
>
> And for every one of these macros, there are 10 features for which we
> didn't get macros added.
>
> Let's just delete them all, and get out of habit of doing things this
> way.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
This is sure to break out of tree drivers...
^ permalink raw reply
* netdevice: Kill 'feature' test macros.
From: David Miller @ 2011-07-12 17:50 UTC (permalink / raw)
To: netdev
Almost all of these have long outstayed their welcome.
And for every one of these macros, there are 10 features for which we
didn't get macros added.
Let's just delete them all, and get out of habit of doing things this
way.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/netdevice.h | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 011eb89..30f17e4 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -60,11 +60,6 @@ struct wireless_dev;
#define SET_ETHTOOL_OPS(netdev,ops) \
( (netdev)->ethtool_ops = (ops) )
-#define HAVE_ALLOC_NETDEV /* feature macro: alloc_xxxdev
- functions are available. */
-#define HAVE_FREE_NETDEV /* free_netdev() */
-#define HAVE_NETDEV_PRIV /* netdev_priv() */
-
/* hardware address assignment types */
#define NET_ADDR_PERM 0 /* address is permanent (default) */
#define NET_ADDR_RANDOM 1 /* address is generated randomly */
@@ -313,7 +308,6 @@ struct header_ops {
const void *saddr, unsigned len);
int (*parse)(const struct sk_buff *skb, unsigned char *haddr);
int (*rebuild)(struct sk_buff *skb);
-#define HAVE_HEADER_CACHE
int (*cache)(const struct neighbour *neigh, struct hh_cache *hh);
void (*cache_update)(struct hh_cache *hh,
const struct net_device *dev,
@@ -887,7 +881,6 @@ struct netdev_tc_txq {
* Must return >0 or -errno if it changed dev->features itself.
*
*/
-#define HAVE_NET_DEVICE_OPS
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
void (*ndo_uninit)(struct net_device *dev);
@@ -1781,8 +1774,6 @@ static inline void input_queue_tail_incr_save(struct softnet_data *sd,
DECLARE_PER_CPU_ALIGNED(struct softnet_data, softnet_data);
-#define HAVE_NETIF_QUEUE
-
extern void __netif_schedule(struct Qdisc *q);
static inline void netif_schedule_queue(struct netdev_queue *txq)
@@ -2058,10 +2049,8 @@ extern void dev_kfree_skb_irq(struct sk_buff *skb);
*/
extern void dev_kfree_skb_any(struct sk_buff *skb);
-#define HAVE_NETIF_RX 1
extern int netif_rx(struct sk_buff *skb);
extern int netif_rx_ni(struct sk_buff *skb);
-#define HAVE_NETIF_RECEIVE_SKB 1
extern int netif_receive_skb(struct sk_buff *skb);
extern gro_result_t dev_gro_receive(struct napi_struct *napi,
struct sk_buff *skb);
@@ -2241,7 +2230,6 @@ extern void netif_device_attach(struct net_device *dev);
/*
* Network interface message level settings
*/
-#define HAVE_NETIF_MSG 1
enum {
NETIF_MSG_DRV = 0x0001,
--
1.7.6
^ permalink raw reply related
* Your Mailbox Is Almost Full
From: Mail Quota alert -Error Code @ 2011-07-12 17:04 UTC (permalink / raw)
Your Mail Quota Has Exceeded The Set Quota/Limit. You Are Currently
Running On 23GB Due To Hidden Files And Folder On Your Mailbox.
Please Click the Link Below To Validate Your Mailbox And Increase Your Quota.
http://buzurl.com/ao70
Failure To Click This Link And Validate Your Quota May Result In Loss Of
Important Information In Your Mailbox Or Cause Limited Access To It.
Mail Quota alert -Error Code #1997142DDE
^ permalink raw reply
* Re: bonding and IPv6 "doesn't work"?
From: Chris Friesen @ 2011-07-12 17:15 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: David Lamparter, netdev
In-Reply-To: <4E1C756C.2010700@wpkg.org>
On 07/12/2011 10:25 AM, Tomasz Chmielewski wrote:
> On 12.07.2011 18:14, David Lamparter wrote:
>> Your bonding peer is probably looping those
>> packets back on the other link, most likely because...
>>
>>> Bonding Mode: load balancing (round-robin)
>>
>> ... most likely because you maybe have a switch on the other side, and
>> that switch expects you to do 802.3ad?
>
> It's a virtual machine, so the host shouldn't know or care much about
> 802.3ad (I think!).
I suspect that connecting multiple links of a bond to the same unmanaged
switch (or virtual bridge) is going to confuse things.
Try using multiple virtual bridges instead, one for each slave in the
bond. That way they won't interfere with each other.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Business proposal from hong kong
From: Lee Lan @ 2011-07-12 17:04 UTC (permalink / raw)
To: netdev
Hello
How are you ? Am from Hong Kong, am a Chinese , I have a Mutual business
proposal am proposing to you, that I will want you to handle from your
country, I will like to seek your consent first.
I have a serious business project proposal for you to manage and handle
for me in your country. This project involves a huge specific amount I
can't mention here for security reasons. It involve a transaction from my
bank in Hong Kong. Am a chinese man, and we are bound by laws here.
If you feel you can have this handled, please let me know, so that I send
you an attached comprehensive details of this transaction. you should send
me response to my email: leelanhk12@bricksmail.com
Sincerely,
Lan Lee Cheng
^ 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