* [PATCH net 6/6] ixp4xx_eth: Validate hwtstamp_config completely before applying it
From: Ben Hutchings @ 2013-11-14 0:48 UTC (permalink / raw)
To: David Miller, Krzysztof Halasa; +Cc: netdev, Richard Cochran
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
hwtstamp_ioctl() should validate all fields of hwtstamp_config
before making any changes. Currently it sets the TX configuration
before validating the rx_filter field.
Untested as I don't have a cross-compiler to hand.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index e78802e75ea6..bcc224a83734 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -389,16 +389,8 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
ch = PORT2CHANNEL(port);
regs = (struct ixp46x_ts_regs __iomem *) IXP4XX_TIMESYNC_BASE_VIRT;
- switch (cfg.tx_type) {
- case HWTSTAMP_TX_OFF:
- port->hwts_tx_en = 0;
- break;
- case HWTSTAMP_TX_ON:
- port->hwts_tx_en = 1;
- break;
- default:
+ if (cfg.tx_type != HWTSTAMP_TX_OFF && cfg.tx_type != HWTSTAMP_TX_ON)
return -ERANGE;
- }
switch (cfg.rx_filter) {
case HWTSTAMP_FILTER_NONE:
@@ -416,6 +408,8 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
return -ERANGE;
}
+ port->hwts_tx_en = cfg.tx_type == HWTSTAMP_TX_ON;
+
/* Clear out any old time stamps. */
__raw_writel(TX_SNAPSHOT_LOCKED | RX_SNAPSHOT_LOCKED,
®s->channel[ch].ch_event);
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: Honggang LI @ 2013-11-14 0:55 UTC (permalink / raw)
To: Josh Hunt, Venkat Venkatsubra; +Cc: David Miller, jjolly, LKML, netdev
In-Reply-To: <CAKA=qzbK1YX5OrVQbwM=1xM6Si=GKv0UDofULkOC7RNo08zZPw@mail.gmail.com>
On 11/14/2013 01:40 AM, Josh Hunt wrote:
> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
> <venkat.x.venkatsubra@oracle.com> wrote:
>>
>> -----Original Message-----
>> From: Josh Hunt [mailto:joshhunt00@gmail.com]
>> Sent: Tuesday, November 12, 2013 10:25 PM
>> To: David Miller
>> Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
>> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>>
>> On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
>>> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: John Jolly <jjolly@suse.com>
>>>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>>>
>>>>> Attempting an rds connection from the IP address of an IPoIB
>>>>> interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>>>>> Making the test less strict allows rds-ping to work without
>>>>> crashing the machine.
>>>>>
>>>>> A local unprivileged user could use this flaw to crash the system.
>>>>>
>>>>> Signed-off-by: John Jolly <jjolly@suse.com>
>>>> Besides the questions being asked of you by Venkat Venkatsubra, this
>>>> patch has another issue.
>>>>
>>>> It has been completely corrupted by your email client, it has turned
>>>> all TAB characters into spaces, making the patch useless.
>>>>
>>>> Please learn how to send a patch unmolested in the body of your
>>>> email. Test it by emailing the patch to yourself, and verifying that
>>>> you can in fact apply the patch you receive in that email.
>>>> Then, and only then, should you consider making a new submission of
>>>> this patch.
>>>>
>>>> Use Documentation/email-clients.txt for guidance.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>> I think this issue was lost in the shuffle. It appears that redhat,
>>> ubuntu, and oracle are maintaining local patches to resolve this:
>>>
>>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
>>> 2be130fa15fa8be10d4704e8
>>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td49853
>>> 88.html
>>>
>>> Given that Oracle has applied it I'll make the assumption that
>>> Venkat's question was answered at some point.
>>>
>>> David - I can resubmit the patch with the proper signed-off-by and
>>> formatting if you are willing to apply it unless John wants to try
>>> again. I think it's time this got upstream.
>>>
>>> --
>>> Josh
>> Ugh.. hopefully resending with all the html crap removed...
>>
>> --
>> Josh
>>
>> Hi Josh,
>>
>> No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
>> Because, rds-ping uses zero byte messages to ping.
>> If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
>> The Oracle's internal code I checked doesn't have that patch applied.
>>
>> Venkat
> No I don't have a test case. I came across this CVE while doing an
> audit and noticed it was patched in Ubuntu's kernel and other distros,
> but was not in the upstream kernel yet. Quick googling of lkml showed
> that there were at least two attempts to get this patch upstream, but
> both had issues due to not following the proper submission process:
>
> https://lkml.org/lkml/2012/10/22/433
> https://lkml.org/lkml/2012/9/21/505
>
> From my searching it appears the initial bug was found by someone at redhat:
> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>
> I've added Li Honggang the reporter of this issue from Redhat to the
> mail. Hopefully he can share his testcase.
The test case is very simple:
Steps to Reproduce:
1. yum install -y rds-tools
2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You
may need to wait for a few seconds before the kernel panic.)
>
> and possibly requires certain hardware as Jay writes in the first link above:
> "...some Infiniband HCAs(QLogic, possibly others) the machine will panic..."
This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko),
QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
As I know the upstream code of RDS is broken. There are *many* RDS bugs.
Best regards.
Honggang
>
> I was referring to this oracle commit:
> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d636852be130fa15fa8be10d4704e8
>
> I have no experience with this code. There were a few comments around
> the reset and xmit fns about making sure the caller did certain things
> if not they were racy, but I have no idea if that's coming into play
> here.
>
^ permalink raw reply
* Re: [PATCH net 1/6] tg3: Validate hwtstamp_config completely before applying it
From: Nithin Nayak Sujir @ 2013-11-14 0:55 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: netdev, Richard Cochran, Michael Chan
In-Reply-To: <1384389656.29151.7.camel@bwh-desktop.uk.level5networks.com>
On 11/13/2013 04:40 PM, Ben Hutchings wrote:
> tg3_hwtstamp_ioctl() should validate all fields of hwtstamp_config
> before making any changes. Currently it sets the TX configuration
> before validating the rx_filter field.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 12d961c4ebca..d3a700f86f1a 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -13598,16 +13598,9 @@ static int tg3_hwtstamp_ioctl(struct net_device *dev,
> if (stmpconf.flags)
> return -EINVAL;
>
> - switch (stmpconf.tx_type) {
> - case HWTSTAMP_TX_ON:
> - tg3_flag_set(tp, TX_TSTAMP_EN);
> - break;
> - case HWTSTAMP_TX_OFF:
> - tg3_flag_clear(tp, TX_TSTAMP_EN);
> - break;
> - default:
> + if (stmpconf.tx_type != HWTSTAMP_TX_ON &&
> + stmpconf.tx_type != HWTSTAMP_TX_OFF)
> return -ERANGE;
> - }
>
> switch (stmpconf.rx_filter) {
> case HWTSTAMP_FILTER_NONE:
> @@ -13669,6 +13662,11 @@ static int tg3_hwtstamp_ioctl(struct net_device *dev,
> tw32(TG3_RX_PTP_CTL,
> tp->rxptpctl | TG3_RX_PTP_CTL_HWTS_INTERLOCK);
>
> + if (stmpconf.tx_type == HWTSTAMP_TX_ON)
> + tg3_flag_set(tp, TX_TSTAMP_EN);
> + else
> + tg3_flag_clear(tp, TX_TSTAMP_EN);
> +
> return copy_to_user(ifr->ifr_data, &stmpconf, sizeof(stmpconf)) ?
> -EFAULT : 0;
> }
>
>
Thanks Ben.
Acked-by: Nithin Nayak Sujir <nsujir@broadcom.com>
^ permalink raw reply
* [PATCH] rds: fix local ping DoS
From: Josh Hunt @ 2013-11-14 1:15 UTC (permalink / raw)
To: netdev, venkat.x.venkatsubra
Cc: linux-kernel, jjolly, fenlason, honli, Josh Hunt
The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
(RDS) protocol implementation allows local users to cause a denial of service
(BUG_ON and kernel panic) by establishing an RDS connection with the source
IP address equal to the IPoIB interface's own IP address, as demonstrated by
rds-ping.
A local unprivileged user could use this flaw to crash the system.
CVE-2012-2372
Reported-by: Honggang Li <honli@redhat.com>
Signed-off-by: Josh Hunt <johunt@akamai.com>
---
net/rds/ib_send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index e590949..7920c85 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
int flow_controlled = 0;
int nr_sig = 0;
- BUG_ON(off % RDS_FRAG_SIZE);
+ BUG_ON(!conn->c_loopback && off % RDS_FRAG_SIZE);
BUG_ON(hdr_off != 0 && hdr_off != sizeof(struct rds_header));
/* Do not send cong updates to IB loopback */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: Josh Hunt @ 2013-11-14 1:27 UTC (permalink / raw)
To: Honggang LI; +Cc: Venkat Venkatsubra, David Miller, jjolly, LKML, netdev
In-Reply-To: <52841F95.7040204@redhat.com>
On Wed, Nov 13, 2013 at 6:55 PM, Honggang LI <honli@redhat.com> wrote:
> On 11/14/2013 01:40 AM, Josh Hunt wrote:
>> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
>> <venkat.x.venkatsubra@oracle.com> wrote:
>>>
>>> -----Original Message-----
>>> From: Josh Hunt [mailto:joshhunt00@gmail.com]
>>> Sent: Tuesday, November 12, 2013 10:25 PM
>>> To: David Miller
>>> Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
>>> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>>>
>>> On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
>>>> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: John Jolly <jjolly@suse.com>
>>>>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>>>>
>>>>>> Attempting an rds connection from the IP address of an IPoIB
>>>>>> interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>>>>>> Making the test less strict allows rds-ping to work without
>>>>>> crashing the machine.
>>>>>>
>>>>>> A local unprivileged user could use this flaw to crash the system.
>>>>>>
>>>>>> Signed-off-by: John Jolly <jjolly@suse.com>
>>>>> Besides the questions being asked of you by Venkat Venkatsubra, this
>>>>> patch has another issue.
>>>>>
>>>>> It has been completely corrupted by your email client, it has turned
>>>>> all TAB characters into spaces, making the patch useless.
>>>>>
>>>>> Please learn how to send a patch unmolested in the body of your
>>>>> email. Test it by emailing the patch to yourself, and verifying that
>>>>> you can in fact apply the patch you receive in that email.
>>>>> Then, and only then, should you consider making a new submission of
>>>>> this patch.
>>>>>
>>>>> Use Documentation/email-clients.txt for guidance.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>>> I think this issue was lost in the shuffle. It appears that redhat,
>>>> ubuntu, and oracle are maintaining local patches to resolve this:
>>>>
>>>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
>>>> 2be130fa15fa8be10d4704e8
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>>> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td49853
>>>> 88.html
>>>>
>>>> Given that Oracle has applied it I'll make the assumption that
>>>> Venkat's question was answered at some point.
>>>>
>>>> David - I can resubmit the patch with the proper signed-off-by and
>>>> formatting if you are willing to apply it unless John wants to try
>>>> again. I think it's time this got upstream.
>>>>
>>>> --
>>>> Josh
>>> Ugh.. hopefully resending with all the html crap removed...
>>>
>>> --
>>> Josh
>>>
>>> Hi Josh,
>>>
>>> No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
>>> Because, rds-ping uses zero byte messages to ping.
>>> If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
>>> The Oracle's internal code I checked doesn't have that patch applied.
>>>
>>> Venkat
>> No I don't have a test case. I came across this CVE while doing an
>> audit and noticed it was patched in Ubuntu's kernel and other distros,
>> but was not in the upstream kernel yet. Quick googling of lkml showed
>> that there were at least two attempts to get this patch upstream, but
>> both had issues due to not following the proper submission process:
>>
>> https://lkml.org/lkml/2012/10/22/433
>> https://lkml.org/lkml/2012/9/21/505
>>
>> From my searching it appears the initial bug was found by someone at redhat:
>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>
>> I've added Li Honggang the reporter of this issue from Redhat to the
>> mail. Hopefully he can share his testcase.
> The test case is very simple:
> Steps to Reproduce:
> 1. yum install -y rds-tools
>
> 2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
> inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
>
> 3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You
> may need to wait for a few seconds before the kernel panic.)
>>
>> and possibly requires certain hardware as Jay writes in the first link above:
>> "...some Infiniband HCAs(QLogic, possibly others) the machine will panic..."
> This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko),
> QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
>
> As I know the upstream code of RDS is broken. There are *many* RDS bugs.
>
> Best regards.
> Honggang
Thanks Honggang. I have resubmitted the patch for approval.
--
Josh
^ permalink raw reply
* Re: [PATCH] net: sctp: bug-fixing: retran_path not set properly after transports recovering (v3)
From: Vlad Yasevich @ 2013-11-14 1:42 UTC (permalink / raw)
To: Chang Xiangzhong; +Cc: nhorman, davem, linux-sctp, netdev
In-Reply-To: <1384387106-8105-1-git-send-email-changxiangzhong@gmail.com>
On 11/13/2013 06:58 PM, Chang Xiangzhong wrote:
> When a transport recovers due to the new coming sack, SCTP should
> iterate all of its transport_list to locate the __two__ most recently used
> transport and set to active_path and retran_path respectively. The exising
> code does not find the two properly - In case of the following list:
>
> [most-recent] -> [2nd-most-recent] -> ...
>
> Both active_path and retran_path would be set to the 1st element.
>
> The bug happens when:
> 1) multi-homing
> 2) failure/partial_failure transport recovers
> Both active_path and retran_path would be set to the same most-recent one, in
> other words, retran_path would not take its role - an end user might not even
> notice this issue.
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/associola.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index ab67efc..8f26276 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -913,8 +913,8 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
> if (!first || t->last_time_heard > first->last_time_heard) {
> second = first;
> first = t;
> - }
> - if (!second || t->last_time_heard > second->last_time_heard)
> + } else if (!second ||
> + t->last_time_heard > second->last_time_heard)
> second = t;
> }
>
> @@ -935,6 +935,8 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
> first = asoc->peer.primary_path;
> }
>
> + if (!second)
> + second = first;
> /* If we failed to find a usable transport, just camp on the
> * primary, even if it is inactive.
> */
>
^ permalink raw reply
* RE: [PATCH v2 1/1] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-14 1:47 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem@davemloft.net, netdev@vger.kernel.org, Frank Li
In-Reply-To: <1384378020.29151.3.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Data: Thursday, November 14, 2013 5:27 AM
>To: Duan Fugang-B38611
>Cc: davem@davemloft.net; netdev@vger.kernel.org; Li Frank-B20596
>Subject: Re: [PATCH v2 1/1] net:fec: fix WARNING caused by lack of calls to
>dma_mapping_error()
>
>On Wed, 2013-11-13 at 11:04 +0800, Fugang Duan wrote:
>[...]
>> =============================================
>> V2: add net_ratelimit() to limit map err message.
>> use dma_sync_single_for_cpu() instead of dma_map_single().
>> fix the issue that pass DMA addresses to __va() to get virture address.
>> V1: initial send
>> =============================================
>>
>> Signed-off-by: Fugang Duan <B38611@freescale.com>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>[...]
>
>No that's not how it works. If I were to thoroughly review this (but I haven't,
>and I don't have time to) then I might say 'Reviewed-by: Ben Hutchings' which
>you could then add to the patch if re-posting it.
>Signed-off-by means something different and you must never add it on behalf of
>someone else.
>
>Ben.
You had supported many ideas for the patch V2, so add you to Signed-off.
Ok, I change it to "Reveiewed-by" and resend the patch.
Thanks,
Andy
>
>--
>Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's
>the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net] bonding: fix two race conditions in bond_store_updelay/downdelay
From: Ding Tianhong @ 2013-11-14 1:50 UTC (permalink / raw)
To: Nikolay Aleksandrov, Eric Dumazet
Cc: netdev, davem, Jay Vosburgh, Andy Gospodarek, Veaceslav Falico
In-Reply-To: <5283B19A.9050302@redhat.com>
On 2013/11/14 1:06, Nikolay Aleksandrov wrote:
> On 11/13/2013 06:03 PM, Eric Dumazet wrote:
>> On Wed, 2013-11-13 at 17:07 +0100, Nikolay Aleksandrov wrote:
>>> This patch fixes two race conditions between bond_store_updelay/downdelay
>>> and bond_store_miimon which could lead to division by zero as miimon can
>>> be set to 0 while either updelay/downdelay are being set and thus miss the
>>> zero check in the beginning, the zero div happens because updelay/downdelay
>>> are stored as new_value / bond->params.miimon. Use rtnl to synchronize with
>>> miimon setting.
>>
>> It seems a bit heavy duty to take rtnl for this.
>>
>> Using ACCESS_ONCE() in bonding_store_updelay()/bonding_store_downdelay()
>> should be enough ?
>>
>> int miimon = ACCESS_ONCE(bond->params.miimon);
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> Hi Eric,
> I thought about this version too, but downdelay/updelay can be changed in other
> places (e.g., store_miimon) and the resulting downdelay/updelay value might not
> be the right one.
> Correct me if I'm wrong, but this is what I have in mind (miimon = 100, updelay
> = 200):
> set miimon to 300 and concurrently set updelay to 400, we might endup leaving
> updelay to 400 because the old value of miimon is used in the calculation in
> store_updelay even though when changing miimon updelay/downdelay get adjusted,
> they might get adjusted by store_updelay/downdelay to a wrong value afterwards.
>
> Nik
>
>
agree, set miimon and set updelay may conflict.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-14 1:30 UTC (permalink / raw)
To: bhutchings, davem; +Cc: netdev
The driver fails to check the results of DMA mapping and results in
the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable)
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:937 check_unmap+0x43c/0x7d8()
fec 2188000.ethernet: DMA-API: device driver failed to check map
error[device address=0x00000000383a8040] [size=2048 bytes] [mapped as single]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-16827-g9cdb0ba-dirty #188
[<80013c4c>] (unwind_backtrace+0x0/0xf8) from [<80011704>] (show_stack+0x10/0x14)
[<80011704>] (show_stack+0x10/0x14) from [<80025614>] (warn_slowpath_common+0x4c/0x6c)
[<80025614>] (warn_slowpath_common+0x4c/0x6c) from [<800256c8>] (warn_slowpath_fmt+0x30/0x40)
[<800256c8>] (warn_slowpath_fmt+0x30/0x40) from [<8026bfdc>] (check_unmap+0x43c/0x7d8)
[<8026bfdc>] (check_unmap+0x43c/0x7d8) from [<8026c584>] (debug_dma_unmap_page+0x6c/0x78)
[<8026c584>] (debug_dma_unmap_page+0x6c/0x78) from [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8)
[<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) from [<804dc8c0>] (net_rx_action+0x94/0x160)
[<804dc8c0>] (net_rx_action+0x94/0x160) from [<8002c758>] (__do_softirq+0xe8/0x1d0)
[<8002c758>] (__do_softirq+0xe8/0x1d0) from [<8002c8e8>] (do_softirq+0x4c/0x58)
[<8002c8e8>] (do_softirq+0x4c/0x58) from [<8002cb50>] (irq_exit+0x90/0xc8)
[<8002cb50>] (irq_exit+0x90/0xc8) from [<8000ea88>] (handle_IRQ+0x3c/0x94)
[<8000ea88>] (handle_IRQ+0x3c/0x94) from [<8000855c>] (gic_handle_irq+0x28/0x5c)
[<8000855c>] (gic_handle_irq+0x28/0x5c) from [<8000de00>] (__irq_svc+0x40/0x50)
Exception stack(0x815a5f38 to 0x815a5f80)
5f20: 815a5f80 3b9aca00
5f40: 0fe52383 00000002 0dd8950e 00000002 81e7b080 00000000 00000000 815ac4d8
5f60: 806032ec 00000000 00000017 815a5f80 80059028 8041fc4c 60000013 ffffffff
[<8000de00>] (__irq_svc+0x40/0x50) from [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0)
[<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) from [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c)
[<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) from [<8000edac>] (arch_cpu_idle+0x10/0x4c)
[<8000edac>] (arch_cpu_idle+0x10/0x4c) from [<800582f8>] (cpu_startup_entry+0x60/0x130)
[<800582f8>] (cpu_startup_entry+0x60/0x130) from [<80bc7a48>] (start_kernel+0x2d0/0x328)
[<80bc7a48>] (start_kernel+0x2d0/0x328) from [<10008074>] (0x10008074)
---[ end trace c6edec32436e0042 ]---
Because dma-debug add new interfaces to debug dma mapping errors, pls refer
to: http://lwn.net/Articles/516640/
After dma mapping, it must call dma_mapping_error() to check mapping error,
otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
the mapping is not checked and dump the error msg. So,add dma_mapping_error()
checking to fix the WARNING
And RX DMA buffers are used repeatedly and the driver copies it into an skb,
fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device()
instead of dma_map_single()/dma_unmap_single().
There have another potential issue: fec_enet_rx() passes the DMA address to __va().
Physical and DMA addresses are *not* the same thing. They may differ if the device
is behind an IOMMU or bounce buffering was required, or just because there is a fixed
offset between the device and host physical addresses. Also fix it in this patch.
=============================================
V2: add net_ratelimit() to limit map err message.
use dma_sync_single_for_cpu() instead of dma_map_single().
fix the issue that pass DMA addresses to __va() to get virture address.
V1: initial send
=============================================
Signed-off-by: Fugang Duan <B38611@freescale.com>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/ethernet/freescale/fec_main.c | 31 +++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index b2793b9..4cbebf3 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -386,7 +386,14 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
*/
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, bufaddr,
FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
-
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ bdp->cbd_bufaddr = 0;
+ fep->tx_skbuff[index] = NULL;
+ dev_kfree_skb_any(skb);
+ if (net_ratelimit())
+ netdev_err(ndev, "Tx DMA memory map failed\n");
+ return NETDEV_TX_OK;
+ }
/* Send it on its way. Tell FEC it's ready, interrupt when done,
* it's the last BD of the frame, and to put the CRC on the end.
*/
@@ -861,6 +868,7 @@ fec_enet_rx(struct net_device *ndev, int budget)
struct bufdesc_ex *ebdp = NULL;
bool vlan_packet_rcvd = false;
u16 vlan_tag;
+ int index = 0;
#ifdef CONFIG_M532x
flush_cache_all();
@@ -916,10 +924,15 @@ fec_enet_rx(struct net_device *ndev, int budget)
ndev->stats.rx_packets++;
pkt_len = bdp->cbd_datlen;
ndev->stats.rx_bytes += pkt_len;
- data = (__u8*)__va(bdp->cbd_bufaddr);
- dma_unmap_single(&fep->pdev->dev, bdp->cbd_bufaddr,
- FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
+ if (fep->bufdesc_ex)
+ index = (struct bufdesc_ex *)bdp -
+ (struct bufdesc_ex *)fep->rx_bd_base;
+ else
+ index = bdp - fep->rx_bd_base;
+ data = fep->rx_skbuff[index]->data;
+ dma_sync_single_for_cpu(&fep->pdev->dev, bdp->cbd_bufaddr,
+ FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, pkt_len);
@@ -999,8 +1012,8 @@ fec_enet_rx(struct net_device *ndev, int budget)
napi_gro_receive(&fep->napi, skb);
}
- bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
- FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_device(&fep->pdev->dev, bdp->cbd_bufaddr,
+ FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
rx_processing_done:
/* Clear the status flags for this buffer */
status &= ~BD_ENET_RX_STATS;
@@ -1719,6 +1732,12 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, skb->data,
FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ fec_enet_free_buffers(ndev);
+ if (net_ratelimit())
+ netdev_err(ndev, "Rx DMA memory map failed\n");
+ return -ENOMEM;
+ }
bdp->cbd_sc = BD_ENET_RX_EMPTY;
if (fep->bufdesc_ex) {
--
1.7.2.rc3
^ permalink raw reply related
* [PATCH V3] usbnet: fix race condition caused spinlock bad magic issue
From: wangbiao @ 2013-11-14 2:03 UTC (permalink / raw)
To: oneukum-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, mingo-X9Un+BFzKDI,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, rusty-8n+1lVoiYb80n/F98K4Iww,
william.douglas-ral2JQCrhuEAvxtiuMwx3w,
di.zhang-ral2JQCrhuEAvxtiuMwx3w, biao.wang-ral2JQCrhuEAvxtiuMwx3w
From: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Mon, 11 Nov 2013 10:23:40 +0800
Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
there is race between usbnet_terminate_urbs and usbnet_bh.
for example:
cpu 0 cpu 1
usbnet_suspend
usbnet_bh { ->usbnet_terminate_urbs {
dev->wait = &unlink_wakeup;
while(....){..}//break
if(dev->wait) is true
dev->wait=NULL
}//unlink_wakeup is invalid
__wake_up(dev->wait)//garbage value
}
the race is due to unprotection of dev->wait, so this patch involves a
spinlock to avoid it.
Signed-off-by: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Zhang, Di <di.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/usbnet.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 90a429b..f7df1af 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -86,6 +86,7 @@ static const char driver_name [] = "usbnet";
/* use ethtool to change the level for any given device */
static int msg_level = -1;
+static spinlock_t dev_wait_lock = __SPIN_LOCK_UNLOCKED(dev_wait_lock);
module_param (msg_level, int, 0);
MODULE_PARM_DESC (msg_level, "Override default message level");
@@ -764,11 +765,14 @@ static void usbnet_terminate_urbs(struct usbnet *dev)
DECLARE_WAIT_QUEUE_HEAD_ONSTACK(unlink_wakeup);
DECLARE_WAITQUEUE(wait, current);
int temp;
+ unsigned long flags;
/* ensure there are no more active urbs */
add_wait_queue(&unlink_wakeup, &wait);
set_current_state(TASK_UNINTERRUPTIBLE);
+ spin_lock_irqsave(&dev_wait_lock, flags);
dev->wait = &unlink_wakeup;
+ spin_unlock_irqrestore(&dev_wait_lock, flags);
temp = unlink_urbs(dev, &dev->txq) +
unlink_urbs(dev, &dev->rxq);
@@ -782,7 +786,9 @@ static void usbnet_terminate_urbs(struct usbnet *dev)
"waited for %d urb completions\n", temp);
}
set_current_state(TASK_RUNNING);
+ spin_lock_irqsave(&dev_wait_lock, flags);
dev->wait = NULL;
+ spin_unlock_irqrestore(&dev_wait_lock, flags);
remove_wait_queue(&unlink_wakeup, &wait);
}
@@ -1424,6 +1430,7 @@ static void usbnet_bh (unsigned long param)
struct usbnet *dev = (struct usbnet *) param;
struct sk_buff *skb;
struct skb_data *entry;
+ unsigned long flags;
while ((skb = skb_dequeue (&dev->done))) {
entry = (struct skb_data *) skb->cb;
@@ -1447,13 +1454,18 @@ static void usbnet_bh (unsigned long param)
clear_bit(EVENT_RX_KILL, &dev->flags);
// waiting for all pending urbs to complete?
+ spin_lock_irqsave(&dev_wait_lock, flags);
if (dev->wait) {
if ((dev->txq.qlen + dev->rxq.qlen + dev->done.qlen) == 0) {
- wake_up (dev->wait);
+ wake_up(dev->wait);
}
+ spin_unlock_irqrestore(&dev_wait_lock, flags);
+ return;
+ }
+ spin_unlock_irqrestore(&dev_wait_lock, flags);
// or are we maybe short a few urbs?
- } else if (netif_running (dev->net) &&
+ if (netif_running(dev->net) &&
netif_device_present (dev->net) &&
netif_carrier_ok(dev->net) &&
!timer_pending (&dev->delay) &&
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Ben Hutchings @ 2013-11-14 2:12 UTC (permalink / raw)
To: Fugang Duan; +Cc: davem, netdev
In-Reply-To: <1384392631-2059-1-git-send-email-B38611@freescale.com>
On Thu, 2013-11-14 at 09:30 +0800, Fugang Duan wrote:
[...]
> =============================================
> V2: add net_ratelimit() to limit map err message.
> use dma_sync_single_for_cpu() instead of dma_map_single().
> fix the issue that pass DMA addresses to __va() to get virture address.
> V1: initial send
> =============================================
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
> Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
[...]
I'm sorry if I wasn't clear in my previous mail. The 'Reviewed-by' tag
means someone has reviewed *this version* of the patch and explicitly
said it was good, usually by writing that tag in their reply. You must
not add it just because someone reviewed and commented on an earlier
version of the patch.
I am not familiar with this driver or hardware so I would have to spend
some time looking at the surrounding code before being sure that it's
OK. I can't spare that time, and so I don't claim to have given this
patch a full review. But that's OK as you don't need my approval for
David to apply the patch. :-)
Please re-post without any reference to me.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-14 2:15 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1384395141.29151.23.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Data: Thursday, November 14, 2013 10:12 AM
>To: Duan Fugang-B38611
>Cc: davem@davemloft.net; netdev@vger.kernel.org
>Subject: Re: [PATCH] net:fec: fix WARNING caused by lack of calls to
>dma_mapping_error()
>
>On Thu, 2013-11-14 at 09:30 +0800, Fugang Duan wrote:
>[...]
>> =============================================
>> V2: add net_ratelimit() to limit map err message.
>> use dma_sync_single_for_cpu() instead of dma_map_single().
>> fix the issue that pass DMA addresses to __va() to get virture address.
>> V1: initial send
>> =============================================
>>
>> Signed-off-by: Fugang Duan <B38611@freescale.com>
>> Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
>[...]
>
>I'm sorry if I wasn't clear in my previous mail. The 'Reviewed-by' tag means
>someone has reviewed *this version* of the patch and explicitly said it was
>good, usually by writing that tag in their reply. You must not add it just
>because someone reviewed and commented on an earlier version of the patch.
>
>I am not familiar with this driver or hardware so I would have to spend some
>time looking at the surrounding code before being sure that it's OK. I can't
>spare that time, and so I don't claim to have given this patch a full review.
>But that's OK as you don't need my approval for David to apply the patch. :-)
>
>Please re-post without any reference to me.
>
>Ben.
Ok, I know. Thanks for your detail info to explain it again.
^ permalink raw reply
* [PATCH v2 1/1] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-14 1:57 UTC (permalink / raw)
To: bhutchings, davem; +Cc: netdev, stephen
The driver fails to check the results of DMA mapping and results in
the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable)
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:937 check_unmap+0x43c/0x7d8()
fec 2188000.ethernet: DMA-API: device driver failed to check map
error[device address=0x00000000383a8040] [size=2048 bytes] [mapped as single]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-16827-g9cdb0ba-dirty #188
[<80013c4c>] (unwind_backtrace+0x0/0xf8) from [<80011704>] (show_stack+0x10/0x14)
[<80011704>] (show_stack+0x10/0x14) from [<80025614>] (warn_slowpath_common+0x4c/0x6c)
[<80025614>] (warn_slowpath_common+0x4c/0x6c) from [<800256c8>] (warn_slowpath_fmt+0x30/0x40)
[<800256c8>] (warn_slowpath_fmt+0x30/0x40) from [<8026bfdc>] (check_unmap+0x43c/0x7d8)
[<8026bfdc>] (check_unmap+0x43c/0x7d8) from [<8026c584>] (debug_dma_unmap_page+0x6c/0x78)
[<8026c584>] (debug_dma_unmap_page+0x6c/0x78) from [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8)
[<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) from [<804dc8c0>] (net_rx_action+0x94/0x160)
[<804dc8c0>] (net_rx_action+0x94/0x160) from [<8002c758>] (__do_softirq+0xe8/0x1d0)
[<8002c758>] (__do_softirq+0xe8/0x1d0) from [<8002c8e8>] (do_softirq+0x4c/0x58)
[<8002c8e8>] (do_softirq+0x4c/0x58) from [<8002cb50>] (irq_exit+0x90/0xc8)
[<8002cb50>] (irq_exit+0x90/0xc8) from [<8000ea88>] (handle_IRQ+0x3c/0x94)
[<8000ea88>] (handle_IRQ+0x3c/0x94) from [<8000855c>] (gic_handle_irq+0x28/0x5c)
[<8000855c>] (gic_handle_irq+0x28/0x5c) from [<8000de00>] (__irq_svc+0x40/0x50)
Exception stack(0x815a5f38 to 0x815a5f80)
5f20: 815a5f80 3b9aca00
5f40: 0fe52383 00000002 0dd8950e 00000002 81e7b080 00000000 00000000 815ac4d8
5f60: 806032ec 00000000 00000017 815a5f80 80059028 8041fc4c 60000013 ffffffff
[<8000de00>] (__irq_svc+0x40/0x50) from [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0)
[<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) from [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c)
[<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) from [<8000edac>] (arch_cpu_idle+0x10/0x4c)
[<8000edac>] (arch_cpu_idle+0x10/0x4c) from [<800582f8>] (cpu_startup_entry+0x60/0x130)
[<800582f8>] (cpu_startup_entry+0x60/0x130) from [<80bc7a48>] (start_kernel+0x2d0/0x328)
[<80bc7a48>] (start_kernel+0x2d0/0x328) from [<10008074>] (0x10008074)
---[ end trace c6edec32436e0042 ]---
Because dma-debug add new interfaces to debug dma mapping errors, pls refer
to: http://lwn.net/Articles/516640/
After dma mapping, it must call dma_mapping_error() to check mapping error,
otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
the mapping is not checked and dump the error msg. So,add dma_mapping_error()
checking to fix the WARNING
And RX DMA buffers are used repeatedly and the driver copies it into an skb,
fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device()
instead of dma_map_single()/dma_unmap_single().
There have another potential issue: fec_enet_rx() passes the DMA address to __va().
Physical and DMA addresses are *not* the same thing. They may differ if the device
is behind an IOMMU or bounce buffering was required, or just because there is a fixed
offset between the device and host physical addresses. Also fix it in this patch.
=============================================
V2: add net_ratelimit() to limit map err message.
use dma_sync_single_for_cpu() instead of dma_map_single().
fix the issue that pass DMA addresses to __va() to get virture address.
V1: initial send
=============================================
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 31 +++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index b2793b9..4cbebf3 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -386,7 +386,14 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
*/
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, bufaddr,
FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
-
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ bdp->cbd_bufaddr = 0;
+ fep->tx_skbuff[index] = NULL;
+ dev_kfree_skb_any(skb);
+ if (net_ratelimit())
+ netdev_err(ndev, "Tx DMA memory map failed\n");
+ return NETDEV_TX_OK;
+ }
/* Send it on its way. Tell FEC it's ready, interrupt when done,
* it's the last BD of the frame, and to put the CRC on the end.
*/
@@ -861,6 +868,7 @@ fec_enet_rx(struct net_device *ndev, int budget)
struct bufdesc_ex *ebdp = NULL;
bool vlan_packet_rcvd = false;
u16 vlan_tag;
+ int index = 0;
#ifdef CONFIG_M532x
flush_cache_all();
@@ -916,10 +924,15 @@ fec_enet_rx(struct net_device *ndev, int budget)
ndev->stats.rx_packets++;
pkt_len = bdp->cbd_datlen;
ndev->stats.rx_bytes += pkt_len;
- data = (__u8*)__va(bdp->cbd_bufaddr);
- dma_unmap_single(&fep->pdev->dev, bdp->cbd_bufaddr,
- FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
+ if (fep->bufdesc_ex)
+ index = (struct bufdesc_ex *)bdp -
+ (struct bufdesc_ex *)fep->rx_bd_base;
+ else
+ index = bdp - fep->rx_bd_base;
+ data = fep->rx_skbuff[index]->data;
+ dma_sync_single_for_cpu(&fep->pdev->dev, bdp->cbd_bufaddr,
+ FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, pkt_len);
@@ -999,8 +1012,8 @@ fec_enet_rx(struct net_device *ndev, int budget)
napi_gro_receive(&fep->napi, skb);
}
- bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
- FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_device(&fep->pdev->dev, bdp->cbd_bufaddr,
+ FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
rx_processing_done:
/* Clear the status flags for this buffer */
status &= ~BD_ENET_RX_STATS;
@@ -1719,6 +1732,12 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, skb->data,
FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ fec_enet_free_buffers(ndev);
+ if (net_ratelimit())
+ netdev_err(ndev, "Rx DMA memory map failed\n");
+ return -ENOMEM;
+ }
bdp->cbd_sc = BD_ENET_RX_EMPTY;
if (fep->bufdesc_ex) {
--
1.7.2.rc3
^ permalink raw reply related
* [PATCH net] sit: fix use after free of fb_tunnel_dev
From: Willem de Bruijn @ 2013-11-14 2:27 UTC (permalink / raw)
To: davem, edumazet, nicolas.dichtel, netdev; +Cc: Willem de Bruijn
Bug: The fallback device is created in sit_init_net and assumed to be
freed in sit_exit_net. First, it is dereferenced in that function, in
sit_destroy_tunnels:
struct net *net = dev_net(sitn->fb_tunnel_dev);
Prior to this, rtnl_unlink_register has removed all devices that match
rtnl_link_ops == sit_link_ops.
Commit 205983c43700 added the line
+ sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops;
which cases the fallback device to match here and be freed before it
is last dereferenced.
Fix: This commit adds an explicit .delllink callback to sit_link_ops
that skips deallocation at rtnl_unlink_register for the fallback
device. This mechanism is comparable to the one in ip_tunnel.
It also modifies sit_destroy_tunnels and its only caller sit_exit_net
to avoid the offending dereference in the first place. That double
lookup is more complicated than required.
Test: The bug is only triggered when CONFIG_NET_NS is enabled. It
causes a GPF only when CONFIG_DEBUG_SLAB is enabled. Verified that
this bug exists at the mentioned commit, at davem-net HEAD and at
3.11.y HEAD. Verified that it went away after applying this patch.
Fixes: 205983c43700 ("sit: allow to use rtnl ops on fb tunnel")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
Please also queue this patch up for 3.11 stable.
---
net/ipv6/sit.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 3a9038d..5a57f38 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1604,6 +1604,15 @@ static const struct nla_policy ipip6_policy[IFLA_IPTUN_MAX + 1] = {
#endif
};
+static void ipip6_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct sit_net *sitn = net_generic(net, sit_net_id);
+
+ if (dev != sitn->fb_tunnel_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static struct rtnl_link_ops sit_link_ops __read_mostly = {
.kind = "sit",
.maxtype = IFLA_IPTUN_MAX,
@@ -1615,6 +1624,7 @@ static struct rtnl_link_ops sit_link_ops __read_mostly = {
.changelink = ipip6_changelink,
.get_size = ipip6_get_size,
.fill_info = ipip6_fill_info,
+ .dellink = ipip6_dellink,
};
static struct xfrm_tunnel sit_handler __read_mostly = {
@@ -1629,9 +1639,10 @@ static struct xfrm_tunnel ipip_handler __read_mostly = {
.priority = 2,
};
-static void __net_exit sit_destroy_tunnels(struct sit_net *sitn, struct list_head *head)
+static void __net_exit sit_destroy_tunnels(struct net *net,
+ struct list_head *head)
{
- struct net *net = dev_net(sitn->fb_tunnel_dev);
+ struct sit_net *sitn = net_generic(net, sit_net_id);
struct net_device *dev, *aux;
int prio;
@@ -1706,11 +1717,10 @@ err_alloc_dev:
static void __net_exit sit_exit_net(struct net *net)
{
- struct sit_net *sitn = net_generic(net, sit_net_id);
LIST_HEAD(list);
rtnl_lock();
- sit_destroy_tunnels(sitn, &list);
+ sit_destroy_tunnels(net, &list);
unregister_netdevice_many(&list);
rtnl_unlock();
}
--
1.8.4.1
^ permalink raw reply related
* [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable
From: Tony Lindgren @ 2013-11-14 2:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap
Cc: Nicolas Pitre, David S. Miller, netdev, devicetree
In-Reply-To: <1384396537-3486-1-git-send-email-tony@atomide.com>
Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.
Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
.../devicetree/bindings/net/smsc-lan91c111.txt | 4 ++
drivers/net/ethernet/smsc/smc91x.c | 52 +++++++++++++++++-----
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
index 953049b..53d69e3 100644
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
Optional properties:
- phy-device : phandle to Ethernet phy
- local-mac-address : Ethernet mac address to use
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 1, 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,nowait : Setup for fast register access with no waits
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 73be7f3..93d4b7d 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
#include <linux/mii.h>
#include <linux/workqueue.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
}
}
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+ { .compatible = "smsc,lan91c94", },
+ { .compatible = "smsc,lan91c111", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
/*
* smc_init(void)
* Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
static int smc_drv_probe(struct platform_device *pdev)
{
struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match = NULL;
struct smc_local *lp;
struct net_device *ndev;
struct resource *res, *ires;
@@ -2222,11 +2234,40 @@ static int smc_drv_probe(struct platform_device *pdev)
*/
lp = netdev_priv(ndev);
+ lp->cfg.flags = 0;
if (pd) {
memcpy(&lp->cfg, pd, sizeof(lp->cfg));
lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
- } else {
+ }
+
+#if IS_BUILTIN(CONFIG_OF)
+ match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+ if (match) {
+ u32 val;
+
+ of_property_read_u32(np, "reg-io-width", &val);
+ switch (val) {
+ case 1:
+ lp->cfg.flags |= SMC91X_USE_8BIT;
+ break;
+ case 2:
+ lp->cfg.flags |= SMC91X_USE_16BIT;
+ break;
+ case 4:
+ lp->cfg.flags |= SMC91X_USE_32BIT;
+ break;
+ default:
+ lp->cfg.flags |= SMC91X_USE_16BIT;
+ break;
+ }
+
+ if (of_get_property(np, "smsc,nowait", NULL))
+ lp->cfg.flags |= SMC91X_NOWAIT;
+ }
+#endif
+
+ if (!pd && !match) {
lp->cfg.flags |= (SMC_CAN_USE_8BIT) ? SMC91X_USE_8BIT : 0;
lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2416,6 @@ static int smc_drv_resume(struct device *dev)
return 0;
}
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
- { .compatible = "smsc,lan91c94", },
- { .compatible = "smsc,lan91c111", },
- {},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
static struct dev_pm_ops smc_drv_pm_ops = {
.suspend = smc_drv_suspend,
.resume = smc_drv_resume,
--
1.8.1.1
^ permalink raw reply related
* [PATCH net v2] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-14 2:35 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
I met a Bug when I add ip target with the wrong ip address:
echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
the wrong ip address will transfor to 245.245.245.244 and add
to the ip target success, it is uncorrect, so I add checks to avoid
adding wrong address.
The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
the next check and will not add to ip target.
Thanks for Veaceslav's opinion and make the code more simplify.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_sysfs.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 25ef533..8dd34eb 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -611,15 +611,14 @@ static ssize_t bonding_store_arp_targets(struct device *d,
return restart_syscall();
targets = bond->params.arp_targets;
- newtarget = in_aton(buf + 1);
+ if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
+ newtarget == 0) {
+ pr_err("%s: invalid ARP target %pI4 specified for addition\n",
+ bond->dev->name, &newtarget);
+ goto out;
+ }
/* look for adds */
if (buf[0] == '+') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for addition\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
pr_err("%s: ARP target %pI4 is already present\n",
bond->dev->name, &newtarget);
@@ -642,12 +641,6 @@ static ssize_t bonding_store_arp_targets(struct device *d,
targets[ind] = newtarget;
write_unlock_bh(&bond->lock);
} else if (buf[0] == '-') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for removal\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
ind = bond_get_targets_ip(targets, newtarget);
if (ind == -1) {
pr_err("%s: unable to remove nonexistent ARP target %pI4.\n",
--
1.7.12
^ permalink raw reply related
* [RFC][PATCH 0/3] net_tstamp: Add SIOCGHWTSTAMP ioctl
From: Ben Hutchings @ 2013-11-14 2:37 UTC (permalink / raw)
To: David Miller, Richard Cochran; +Cc: netdev, linux-net-drivers
SIOCSHWTSTAMP returns the real configuration to the application
using it, but there is currently no way for any other
application to find out the configuration non-destructively.
This series adds a new ioctl with the obvious name which just reads the
configuration, and an example implementation for the sfc driver.
This information could alternately be added to struct ethtool_ts_info
returned by the ethtool ETHTOOL_GET_TS_INFO command, although that
wouldn't be very symmetric. There would also be a problem of how to
indicate whether this extra information is present, given that all
fields of hwtstamp_config can validly be 0.
Ben.
Ben Hutchings (3):
net_tstamp: Improve kernel-doc for struct hwtstamp_config
net_tstamp: Add SIOCGHWTSTAMP ioctl to match SIOCSHWTSTAMP
sfc: Implement the SIOCGHWTSTAMP ioctl
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/ethernet/sfc/ptp.c | 14 +++++++++-----
include/uapi/linux/net_tstamp.h | 16 ++++++++--------
include/uapi/linux/sockios.h | 3 ++-
net/core/dev_ioctl.c | 2 ++
5 files changed, 22 insertions(+), 15 deletions(-)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [RFC][PATCH 1/3] net_tstamp: Improve kernel-doc for struct hwtstamp_config
From: Ben Hutchings @ 2013-11-14 2:38 UTC (permalink / raw)
To: David Miller, Richard Cochran; +Cc: netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
Fix the name of the rx_filter field.
Remove text about 32/64-bit compatibility; this works just the same as
for most socket ioctls and as the structure is not allowed to grow
there is no need to remind anyone how to maintain it.
Add explanation about drivers changing the filter mode.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/uapi/linux/net_tstamp.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index ae5df122e42f..c9a7de2a6276 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -30,13 +30,13 @@ enum {
*
* @flags: no flags defined right now, must be zero
* @tx_type: one of HWTSTAMP_TX_*
- * @rx_type: one of one of HWTSTAMP_FILTER_*
+ * @rx_filter: one of HWTSTAMP_FILTER_*
*
* %SIOCSHWTSTAMP expects a &struct ifreq with a ifr_data pointer to
- * this structure. dev_ifsioc() in the kernel takes care of the
- * translation between 32 bit userspace and 64 bit kernel. The
- * structure is intentionally chosen so that it has the same layout on
- * 32 and 64 bit systems, don't break this!
+ * this structure. If the driver or hardware does not support the
+ * requested @rx_filter value, the driver may use a more general
+ * filter mode. In this case @rx_filter will indicate the actual mode
+ * on return.
*/
struct hwtstamp_config {
int flags;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [RFC][PATCH 2/3] net_tstamp: Add SIOCGHWTSTAMP ioctl to match SIOCSHWTSTAMP
From: Ben Hutchings @ 2013-11-14 2:39 UTC (permalink / raw)
To: David Miller, Richard Cochran; +Cc: netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
SIOCSHWTSTAMP returns the real configuration to the application
using it, but there is currently no way for any other
application to find out the configuration non-destructively.
Add a new ioctl for this, making it unprivileged.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/uapi/linux/net_tstamp.h | 14 +++++++-------
include/uapi/linux/sockios.h | 3 ++-
net/core/dev_ioctl.c | 2 ++
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index c9a7de2a6276..f53879c0f590 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -26,17 +26,17 @@ enum {
};
/**
- * struct hwtstamp_config - %SIOCSHWTSTAMP parameter
+ * struct hwtstamp_config - %SIOCGHWTSTAMP and %SIOCSHWTSTAMP parameter
*
- * @flags: no flags defined right now, must be zero
+ * @flags: no flags defined right now, must be zero for %SIOCSHWTSTAMP
* @tx_type: one of HWTSTAMP_TX_*
* @rx_filter: one of HWTSTAMP_FILTER_*
*
- * %SIOCSHWTSTAMP expects a &struct ifreq with a ifr_data pointer to
- * this structure. If the driver or hardware does not support the
- * requested @rx_filter value, the driver may use a more general
- * filter mode. In this case @rx_filter will indicate the actual mode
- * on return.
+ * %SIOCGHWTSTAMP and %SIOCSHWTSTAMP expect a &struct ifreq with a
+ * ifr_data pointer to this structure. For %SIOCSHWTSTAMP, if the
+ * driver or hardware does not support the requested @rx_filter value,
+ * the driver may use a more general filter mode. In this case
+ * @rx_filter will indicate the actual mode on return.
*/
struct hwtstamp_config {
int flags;
diff --git a/include/uapi/linux/sockios.h b/include/uapi/linux/sockios.h
index 7997a506ad41..e888b1aed69f 100644
--- a/include/uapi/linux/sockios.h
+++ b/include/uapi/linux/sockios.h
@@ -125,7 +125,8 @@
#define SIOCBRDELIF 0x89a3 /* remove interface from bridge */
/* hardware time stamping: parameters in linux/net_tstamp.h */
-#define SIOCSHWTSTAMP 0x89b0
+#define SIOCSHWTSTAMP 0x89b0 /* set and get config */
+#define SIOCGHWTSTAMP 0x89b1 /* get config */
/* Device private ioctl calls */
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 5b7d0e1d0664..cf999e09bcd2 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -327,6 +327,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
cmd == SIOCBRADDIF ||
cmd == SIOCBRDELIF ||
cmd == SIOCSHWTSTAMP ||
+ cmd == SIOCGHWTSTAMP ||
cmd == SIOCWANDEV) {
err = -EOPNOTSUPP;
if (ops->ndo_do_ioctl) {
@@ -546,6 +547,7 @@ int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
*/
default:
if (cmd == SIOCWANDEV ||
+ cmd == SIOCGHWTSTAMP ||
(cmd >= SIOCDEVPRIVATE &&
cmd <= SIOCDEVPRIVATE + 15)) {
dev_load(net, ifr.ifr_name);
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [RFC][PATCH 3/3] sfc: Implement the SIOCGHWTSTAMP ioctl
From: Ben Hutchings @ 2013-11-14 2:40 UTC (permalink / raw)
To: David Miller, Richard Cochran; +Cc: netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/ethernet/sfc/ptp.c | 14 +++++++++-----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 07c9bc4c61bc..d5fbac313bf7 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1856,7 +1856,7 @@ static int efx_ioctl(struct net_device *net_dev, struct ifreq *ifr, int cmd)
struct efx_nic *efx = netdev_priv(net_dev);
struct mii_ioctl_data *data = if_mii(ifr);
- if (cmd == SIOCSHWTSTAMP)
+ if (cmd == SIOCGHWTSTAMP || cmd == SIOCSHWTSTAMP)
return efx_ptp_ioctl(efx, ifr, cmd);
/* Convert phy_id from older PRTAD/DEVAD format */
diff --git a/drivers/net/ethernet/sfc/ptp.c b/drivers/net/ethernet/sfc/ptp.c
index 03acf57df045..ba14a4d95dfb 100644
--- a/drivers/net/ethernet/sfc/ptp.c
+++ b/drivers/net/ethernet/sfc/ptp.c
@@ -1240,12 +1240,16 @@ int efx_ptp_ioctl(struct efx_nic *efx, struct ifreq *ifr, int cmd)
if (!efx->ptp_data)
return -EOPNOTSUPP;
- if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
- return -EFAULT;
+ if (cmd == SIOCSHWTSTAMP) {
+ if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
+ return -EFAULT;
- rc = efx_ptp_ts_init(efx, &config);
- if (rc != 0)
- return rc;
+ rc = efx_ptp_ts_init(efx, &config);
+ if (rc != 0)
+ return rc;
+ } else {
+ config = efx->ptp_data->config;
+ }
return copy_to_user(ifr->ifr_data, &config, sizeof(config))
? -EFAULT : 0;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Test program for SIOC{G,S}HWTSTAMP
From: Ben Hutchings @ 2013-11-14 2:46 UTC (permalink / raw)
To: David Miller, Richard Cochran; +Cc: netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
I used this to exercise the two ioctls.
Ben.
---
/* Test program for SIOC{G,S}HWTSTAMP - bhutchings@solarflare.com, 2013 */
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <linux/if.h>
#include <linux/net_tstamp.h>
#include <linux/sockios.h>
#ifndef SIOCGHWTSTAMP
#define SIOCGHWTSTAMP 0x89b1
#endif
static int
lookup_value(const char **names, int size, const char *name)
{
int value;
for (value = 0; value < size; value++)
if (names[value] && strcasecmp(names[value], name) == 0)
return value;
return -1;
}
static const char *
lookup_name(const char **names, int size, int value)
{
return (value >= 0 && value < size) ? names[value] : NULL;
}
static void list_names(FILE *f, const char **names, int size)
{
int value;
for (value = 0; value < size; value++)
if (names[value])
fprintf(f, " %s\n", names[value]);
}
static const char *tx_types[] = {
#define TX_TYPE(name) [HWTSTAMP_TX_ ## name] = #name
TX_TYPE(OFF),
TX_TYPE(ON),
TX_TYPE(ONESTEP_SYNC)
#undef TX_TYPE
};
#define N_TX_TYPES ((int)(sizeof(tx_types) / sizeof(tx_types[0])))
static const char *rx_filters[] = {
#define RX_FILTER(name) [HWTSTAMP_FILTER_ ## name] = #name
RX_FILTER(NONE),
RX_FILTER(ALL),
RX_FILTER(SOME),
RX_FILTER(PTP_V1_L4_EVENT),
RX_FILTER(PTP_V1_L4_SYNC),
RX_FILTER(PTP_V1_L4_DELAY_REQ),
RX_FILTER(PTP_V2_L4_EVENT),
RX_FILTER(PTP_V2_L4_SYNC),
RX_FILTER(PTP_V2_L4_DELAY_REQ),
RX_FILTER(PTP_V2_L2_EVENT),
RX_FILTER(PTP_V2_L2_SYNC),
RX_FILTER(PTP_V2_L2_DELAY_REQ),
RX_FILTER(PTP_V2_EVENT),
RX_FILTER(PTP_V2_SYNC),
RX_FILTER(PTP_V2_DELAY_REQ),
#undef RX_FILTER
};
#define N_RX_FILTERS ((int)(sizeof(rx_filters) / sizeof(rx_filters[0])))
static void usage(void)
{
fputs("Usage: hwtstamp_config if_name [tx_type rx_filter]\n"
"tx_type is any of (case-insensitive):\n",
stderr);
list_names(stderr, tx_types, N_TX_TYPES);
fputs("rx_filter is any of (case-insensitive):\n", stderr);
list_names(stderr, rx_filters, N_RX_FILTERS);
}
int main(int argc, char **argv)
{
struct ifreq ifr;
struct hwtstamp_config config;
const char *name;
int sock;
if ((argc != 2 && argc != 4) || (strlen(argv[1]) >= IFNAMSIZ)) {
usage();
return 2;
}
if (argc == 4) {
config.flags = 0;
config.tx_type = lookup_value(tx_types, N_TX_TYPES, argv[2]);
config.rx_filter = lookup_value(rx_filters, N_RX_FILTERS, argv[3]);
if (config.tx_type < 0 || config.rx_filter < 0) {
usage();
return 2;
}
}
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) {
perror("socket");
return 1;
}
strcpy(ifr.ifr_name, argv[1]);
ifr.ifr_data = (caddr_t)&config;
if (ioctl(sock, (argc == 2) ? SIOCGHWTSTAMP : SIOCSHWTSTAMP, &ifr)) {
perror("ioctl");
return 1;
}
printf("flags = %#x\n", config.flags);
name = lookup_name(tx_types, N_TX_TYPES, config.tx_type);
if (name)
printf("tx_type = %s\n", name);
else
printf("tx_type = %d\n", config.tx_type);
name = lookup_name(rx_filters, N_RX_FILTERS, config.rx_filter);
if (name)
printf("rx_filter = %s\n", name);
else
printf("rx_filter = %d\n", config.rx_filter);
return 0;
}
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time
From: Theodore Ts'o @ 2013-11-14 2:54 UTC (permalink / raw)
To: Daniel Borkmann, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
keescook-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <20131112134603.GE14929-5j1vdhnGyZutBveJljeh2VPnkB77EeZ12LY78lusg7I@public.gmane.org>
On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote:
> > It is needed by fork to set up the stack canary. And this actually gets
> > called before the secret is initialized.
>
> Maybe we could use this for the time being and use the seeding method
> of kaslr as soon as it hits the tree?
Hmm, from what I can tell even early_initcall() is going to be early
enough. The stack canary is set up by boot_init_stack_canary(), which
is run very, very early in start_kerne() --- way before
early_initcalls, or even before interrupts are enabled. So adding
random_int_secret_init_early() as a core_initcall is still too late.
I wonder if we need to do something in common with what Kees has been
considering for the kaslr code, since it's a similar issue --- we need
random number way earlier than we can really afford to initialize
/dev/random.
- Ted
P.S. Unless I'm missing something (and I hope I am), it would appear
that the stack canary is going to easily predictable by an attacker on
non-x86 platforms that don't have RDRAND. Has someone tested whether
or not the stack canary isn't constant across ARM or pre-Sandy Bridge
x86 systems?
--
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] sit: fix use after free of fb_tunnel_dev
From: Willem de Bruijn @ 2013-11-14 2:58 UTC (permalink / raw)
To: David Miller, Eric Dumazet, nicolas.dichtel, netdev; +Cc: Willem de Bruijn
In-Reply-To: <1384396058-26850-1-git-send-email-willemb@google.com>
> Please also queue this patch up for 3.11 stable.
It is apparently also relevant for 3.10. That is the only other stable
branch that has the mentioned patch. This fix does not apply cleanly
there, however. Only the top half is required. Applying that does
appear to resolve the problem.
And I forgot to mention the actual test: `modprobe sit; rmmod sit`
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 3:09 UTC (permalink / raw)
To: Stefan Priebe, Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <5283DC91.1010402@profihost.ag>
[-- Attachment #1: Type: text/plain, Size: 8365 bytes --]
On 11/13/2013 03:09 PM, Stefan Priebe wrote:
> Am 13.11.2013 18:21, schrieb Vlad Yasevich:
>> On 11/13/2013 11:21 AM, Veaceslav Falico wrote:
>>> On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>>> Hi Falico,
>>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe -
>>>>>>> Profihost AG
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>>> never
>>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>>
>>>>>>>> I've this:
>>>>>>>>
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> /
>>>>>>>> eth3
>>>>>>>>
>>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>>> bonding and using a bridge.
>>>>>>>>
>>>>>>>> I the past i had this:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>> This was working fine until 3.9.X since 3.10. Right now using
>>>>>>>> 3.10 i
>>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-(
>>>>>>>> this
>>>>>>>> is bad!
>>>>>>>
>>>>>>> As a guess - do you use arp monitoring for bonding? Try using
>>>>>>> miimon -
>>>>>>> there were some issues with it in 3.10, which were fixed by some
>>>>>>> huge
>>>>>>> patchsets that will never hit 3.10 stable.
>>>>>>> Also, the bonding configuration would be welcome.
>>>>>>
>>>>>> Debian Bonding konfiguration looks like this:
>>>>>> auto bond1
>>>>>> iface bond1 inet manual
>>>>>> slaves eth2 eth3
>>>>>> bond-mode 802.3ad
>>>>>> bond_miimon 100
>>>>>> bond_updelay 200
>>>>>> bond_downdelay 0
>>>>>>
>>>>>> This should be miimon using lacp and not arp isn't it?
>>>>>> Anything more needed?
>>>>>>
>>>>>
>>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>>> the the kernel messages that say that?
>>>>
>>>> No it does not - i only see:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 5.445161] device bond0 entered promiscuous mode
>>>> [ 7.670701] device bond1 entered promiscuous mode
>>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>>>
>>>> Now adding variant 1:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>
>>>> Now it looks like this:
>>>> # ip a l|grep PROMISC
>>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr0 state UNKNOWN qlen 500
>>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>>
>>> eth* should get into forwarding mode cause bond0 is a port of the bridge
>>> and should propagate its state towards its slaves. Something is wrong
>>> here.
>>>
>>> Maybe we're looking at the wrong direction - and the promisc for the
>>> ethernet drivers got broken?
>>
>> I was able to duplicate Stefans results only when I turn off the link to
>> the underlying devices when building the bridge. When the link is off,
>> the rx_flags do not propagate down to the lower level devices.
>>
>> What about something like this (completely untested)
>>
[snip old patch]
>>
>> -vlad
>>>
>
> I tried that one but it still looks like this:
>
> [ 173.266915] device tap113i1 entered promiscuous mode
> [ 173.305617] 8021q: adding VLAN 3000 to HW filter on device bond1.3000
> [ 173.315881] device bond1.3000 entered promiscuous mode
> [ 173.315926] vmbr1v3000: port 1(bond1.3000) entered forwarding state
> [ 173.315929] vmbr1v3000: port 1(bond1.3000) entered forwarding state
> [ 173.319844] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 173.319847] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 188.344076] vmbr1v3000: port 1(bond1.3000) entered forwarding state
>
> # ip a l|grep PROMISC
> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr0 state UNKNOWN qlen 500
> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr1v3000 state UNKNOWN qlen 500
>
Stefan
Can you try out attached patch please. I ran it in my environment and
always get promisc link when attaching devices to the bridge.
Thanks
-vlad
>>> What ethernet cards/driver do you use for eth*?
>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>>
>>>>
>>>> Main question is - is this one correct:
>>>
>>> Both are correct. Here's my setup (sorry for stretching):
>>>
>>> +---------------+ +------------+
>>> +-------------+ +---------+ +------+
>>> | bond1 | | | | bridge0
>>> | | | | |
>>> | 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 |
>>> master | bond0 | master | eth2 |
>>> | | --------> | | ------------ | 192.168.4.1 |
>>> --------> | | --------> | |
>>> +---------------+ +------------+
>>> +-------------+ +---------+ +------+
>>>
>>> |
>>>
>>> | master
>>>
>>> v
>>> +---------------+
>>> +---------+
>>> | dummy0
>>> | |
>>> eth0 |
>>> +---------------+
>>> +---------+
>>>
>>> (disregard that dummy0).
>>>
>>> All 192.168.X.1 ips are pingable (via the correct vlans) on both
>>> net-next and stable 3.10.19.
>>>
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= does not work at all
>>>>
>>>> or this one?:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>>
>>>>> -vlad
>>>>>
>>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben
>>>>>> not
>>>>>> with promisc mode. The one below works fine if i set eth2 and eth3
>>>>>> into
>>>>>> promisc mode.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>>>> I also tried this one without success:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Greets,
>>>>>>>> Stefan
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> netdev" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: 0001-core-Propagate-rx_flags-changes-to-slave-master-devi.patch --]
[-- Type: text/x-patch, Size: 1080 bytes --]
>From 964cbe4596d002871fa0dea7526536769bef4b69 Mon Sep 17 00:00:00 2001
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 13 Nov 2013 13:18:59 -0500
Subject: [PATCH] core: Propagate rx_flags changes to slave|master devices even
if down.
If the device is a master or slave device, propagate rx_flag
changes to them even if they are down. This makes sure that
when complex stacked configuration are set up, the flags
are properly set on all devices.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
net/core/dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index fc913f4..016857b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4525,7 +4525,9 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
{
const struct net_device_ops *ops = dev->netdev_ops;
- if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
+ if (((dev->flags & IFF_UP) ||
+ (dev->flags & (IFF_MASTER | IFF_SLAVE)))
+ && ops->ndo_change_rx_flags)
ops->ndo_change_rx_flags(dev, flags);
}
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net 0/3] bridge: Fix undesirable behavior related to vlan
From: Vlad Yasevich @ 2013-11-14 3:14 UTC (permalink / raw)
To: Toshiaki Makita, David S . Miller, Stephen Hemminger, netdev
In-Reply-To: <1384331175-4136-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 11/13/2013 03:26 AM, Toshiaki Makita wrote:
> There seem to be some problems around vlan code.
>
> - Unexpectedly filter vlan by NIC.
> - Not correctly decrement refcount of vlan_vid_info.
> - Memory leak when deleting a bridge with vlan_info allocated.
>
> This is a patch series to fix these issues.
>
> Toshiaki Makita (3):
> bridge: Use vlan_vid_[add/del] instead of direct
> ndo_vlan_rx_[add/kill]_vid calls
> bridge: Call vlan_vid_del for all vids at nbp_vlan_flush
> bridge: Fix memory leak when deleting bridge with vlan filtering
> enabled
>
These all look good to me. Thanks you.
Acked-by: Vlad Yasevich <vyasevic@redhat.com>
-vlad
> net/bridge/br_if.c | 1 +
> net/bridge/br_vlan.c | 24 ++++++++++--------------
> 2 files changed, 11 insertions(+), 14 deletions(-)
>
^ 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