* Re: pull-request: wireless-drivers-next 2015-02-07
From: David Miller @ 2015-02-09 20:13 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev
In-Reply-To: <87a90qosos.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sat, 07 Feb 2015 13:40:51 +0200
> There's a small conflict in drivers/net/wireless/rtlwifi/pci.c, the fix
> is to leave the two labels like this:
>
> schedule_work(&rtlpriv->works.lps_change_work);
> }
> end:
> skb = new_skb;
> no_new:
> if (rtlpriv->use_new_trx_flow) {
>
>
That can't be the correct resolution:
drivers/net/wireless/rtlwifi/pci.c: In function ‘_rtl_pci_rx_interrupt’:
drivers/net/wireless/rtlwifi/pci.c:934:1: warning: label ‘end’ defined but not used [-Wunused-label]
So I've removed that label in the merge commit.
> Please let me know if there are any issues and sorry for being late.
Pulled, thanks a lot.
^ permalink raw reply
* [PATCH net] tcp: don't include Fast Open option in SYN-ACK on pure SYN-data
From: Yuchung Cheng @ 2015-02-09 20:35 UTC (permalink / raw)
To: davem; +Cc: edumazet, ncardwell, netdev, Yuchung Cheng
If a server has enabled Fast Open and it receives a pure SYN-data
packet (without a Fast Open option), it won't accept the data but it
incorrectly returns a SYN-ACK with a Fast Open cookie and also
increments the SNMP stat LINUX_MIB_TCPFASTOPENPASSIVEFAIL.
This patch makes the server include a Fast Open cookie in SYN-ACK
only if the SYN has some Fast Open option (i.e., when client
requests or presents a cookie).
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_fastopen.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 815c85e..53db2c3 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -255,6 +255,9 @@ bool tcp_try_fastopen(struct sock *sk, struct sk_buff *skb,
struct tcp_fastopen_cookie valid_foc = { .len = -1 };
bool syn_data = TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq + 1;
+ if (foc->len == 0) /* Client requests a cookie */
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPFASTOPENCOOKIEREQD);
+
if (!((sysctl_tcp_fastopen & TFO_SERVER_ENABLE) &&
(syn_data || foc->len >= 0) &&
tcp_fastopen_queue_check(sk))) {
@@ -265,7 +268,8 @@ bool tcp_try_fastopen(struct sock *sk, struct sk_buff *skb,
if (syn_data && (sysctl_tcp_fastopen & TFO_SERVER_COOKIE_NOT_REQD))
goto fastopen;
- if (tcp_fastopen_cookie_gen(req, skb, &valid_foc) &&
+ if (foc->len >= 0 && /* Client presents or requests a cookie */
+ tcp_fastopen_cookie_gen(req, skb, &valid_foc) &&
foc->len == TCP_FASTOPEN_COOKIE_SIZE &&
foc->len == valid_foc.len &&
!memcmp(foc->val, valid_foc.val, foc->len)) {
@@ -284,11 +288,10 @@ fastopen:
LINUX_MIB_TCPFASTOPENPASSIVE);
return true;
}
- }
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPFASTOPENPASSIVEFAIL);
+ } else if (foc->len > 0) /* Client presents an invalid cookie */
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPFASTOPENPASSIVEFAIL);
- NET_INC_STATS_BH(sock_net(sk), foc->len ?
- LINUX_MIB_TCPFASTOPENPASSIVEFAIL :
- LINUX_MIB_TCPFASTOPENCOOKIEREQD);
*foc = valid_foc;
return false;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: pull-request: wireless-drivers-next 2015-02-07
From: John W. Linville @ 2015-02-09 20:37 UTC (permalink / raw)
To: David Miller; +Cc: kvalo, linux-wireless, netdev
In-Reply-To: <20150209.121342.1535841700027616341.davem@davemloft.net>
On Mon, Feb 09, 2015 at 12:13:42PM -0800, David Miller wrote:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Sat, 07 Feb 2015 13:40:51 +0200
>
> > There's a small conflict in drivers/net/wireless/rtlwifi/pci.c, the fix
> > is to leave the two labels like this:
> >
> > schedule_work(&rtlpriv->works.lps_change_work);
> > }
> > end:
> > skb = new_skb;
> > no_new:
> > if (rtlpriv->use_new_trx_flow) {
> >
> >
>
> That can't be the correct resolution:
>
> drivers/net/wireless/rtlwifi/pci.c: In function ‘_rtl_pci_rx_interrupt’:
> drivers/net/wireless/rtlwifi/pci.c:934:1: warning: label ‘end’ defined but not used [-Wunused-label]
>
> So I've removed that label in the merge commit.
FWIW, that's the way I have it in wireless-testing as well...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: Nicolas Dichtel @ 2015-02-09 20:48 UTC (permalink / raw)
To: Eric W. Biederman, David Ahern
Cc: Stephen Hemminger, netdev, roopa, hannes, Dinesh Dutt,
Vipin Kumar
In-Reply-To: <87iofe7n1x.fsf@x220.int.ebiederm.org>
Le 06/02/2015 22:22, Eric W. Biederman a écrit :
>
>
> Having looked at this problem, I am currently convinced that network
> namespaces can be improved to the point where they can reasonably
> act as VRFS.
We are using netns this way at 6WIND.
>
> Further I think code maintenance argues that this VRF proposal is a bad
> direction to go.
>
> David Ahern <dsahern@gmail.com> writes:
>
>> On 2/5/15 9:14 PM, Eric W. Biederman wrote:
>>> David Ahern <dsahern@gmail.com> writes:
>>>
>>>> On 2/5/15 6:33 PM, Stephen Hemminger wrote:
>>>>> It is still not clear how adding another level of abstraction
>>>>> solves the scaling problem. Is it just because you can have one application
>>>>> connect to multiple VRF's? so you don't need N routing daemons?
>
>>>> All of those options are rather heavyweight and the number of 'things' is linear
>>>> with the number of VRFs. When multiplied by the number of services needed for a
>>>> full-featured product the end result is a lot of wasted resources.
>>>
>>> If all you want is a single listening socket there are other
>>> implementation possibilities that are focused on solving just that
>>> problem, and would be much more generally applicable.
>>
>> These are examples of the higher level problem -- the current need for
>> replicating processes/threads/sockets per namespace, not to mention the memory
>> consumed by the creation of the namespace itself which is fairly high. i.e., The
>> problem is more than just a listening socket of a single process.
>
> Sometimes replication is simpler and more efficient, so I do not believe
> this is a fundamental design problem.
>
> That said. Having N listening sockets is arguably a mis-feature of the
> berkely sockets layer, and is fixable by adding support for adding
> features for listening sockets to listen on more than one address. So
> by adding an feature to teach a listening socket how to listen on
> additional addresses that is fixable. SCTP and MPTCP have even done
> some work in that area, so it may just be a matter of generalizing
> earlier solutions. More likely we would want to build on Nicolas
> Dichtels work on adding ids to other network namespaces and have
> our VRF any sockets listen on any network namespace that we an for.
I agree, it would be great to have this kind of feature. Any help to
achieve it is welcomed :)
>
> Similarly we can build on Nicolas Dichtel's work of implementing in
> kernel ids for other network namespaces to provide proc files or
> netlink messages that report on multiple network namespaces at once.
> Assuming of course that such interfaces are shown to be worth
> implementing.
Same here. At least, we should have a try to have a status or to see which
problems can block.
>
> I believe that with small focused changes we can make the existing
> userspace API efficient to work with for programs that want to work
> with multiple network namespaces (or VRFs) at once.
Yes, some work remains into this area.
Regards,
Nicolas
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2015-02-07
From: Larry Finger @ 2015-02-09 20:49 UTC (permalink / raw)
To: David Miller
Cc: John W. Linville, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150209203741.GG3566-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On 02/09/2015 02:37 PM, John W. Linville wrote:
> On Mon, Feb 09, 2015 at 12:13:42PM -0800, David Miller wrote:
>> From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Date: Sat, 07 Feb 2015 13:40:51 +0200
>>
>>> There's a small conflict in drivers/net/wireless/rtlwifi/pci.c, the fix
>>> is to leave the two labels like this:
>>>
>>> schedule_work(&rtlpriv->works.lps_change_work);
>>> }
>>> end:
>>> skb = new_skb;
>>> no_new:
>>> if (rtlpriv->use_new_trx_flow) {
>>>
>>>
>>
>> That can't be the correct resolution:
>>
>> drivers/net/wireless/rtlwifi/pci.c: In function ‘_rtl_pci_rx_interrupt’:
>> drivers/net/wireless/rtlwifi/pci.c:934:1: warning: label ‘end’ defined but not used [-Wunused-label]
>>
>> So I've removed that label in the merge commit.
>
> FWIW, that's the way I have it in wireless-testing as well..
I must have missed the pull request. Removal of the label "end" is correct.
Larry
--
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 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620
From: Andy Green @ 2015-02-09 21:07 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kalle Valo, Eugene Krasnikov, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAJAp7OhcFTuYfc7JOKW1SrVRbucuSWg5jcFaoVnSDgBxsyo2ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10 February 2015 at 01:54, Bjorn Andersson <bjorn-UYDU3/A3LUY@public.gmane.org> wrote:
> On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> WCN3620 powersaving mode is not stable. Disable it if we're
>> on a wcn3620 chip type.
>>
>> Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> drivers/net/wireless/ath/wcn36xx/main.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>> index c4178c7..569d45b 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -924,6 +924,10 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> IEEE80211_HW_AMPDU_AGGREGATION |
>> IEEE80211_HW_TIMING_BEACON_ONLY;
>>
>> + /* 3620 powersaving currently unstable */
>> + if (wcn->chip_version == WCN36XX_CHIP_3620)
>> + wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
>> +
>
> Hi Andy,
>
> I have the same problem (Data Abort Exception in wcnss) on 3680, this
> with my wip smd code and a hacked up remoteproc-pil. I haven't spent
> any effort on debugging this, but it looks like it's something related
> to what we have ported to mainline (or lack thereof) rather than a
> 3620 specific issue.
Makes sense since I only have 3620, I assumed it's related to that.
However he can work for a while with powersaving on, but ping
latencies are +600-800ms and he's shaky.
Later I found something mac80211 generic scan preparation or post-scan
code (for scan initiated by wpa_supplicant) is able to stop wlan
traffic after a few goes even if the actual scan mode smd is not sent.
At that point I think a nice solution would be a donation of time from
guys who specialize in wcn for a living to come and hand out a pony or
two...
-Andy
> Regards,
> Bjorn
--
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-next v1 00/17] tipc: new compat layer for the legacy NL API
From: David Miller @ 2015-02-09 21:21 UTC (permalink / raw)
To: richard.alpe; +Cc: netdev, tipc-discussion
In-Reply-To: <1423471819-23112-1-git-send-email-richard.alpe@ericsson.com>
From: <richard.alpe@ericsson.com>
Date: Mon, 9 Feb 2015 09:50:02 +0100
> This is a compatibility / transcoding layer for the old netlink API.
> It relies on the new netlink API to collect data or perform actions
> (dumpit / doit).
>
> The main benefit of this compat layer is that it removes a lot of
> complex code from the tipc core as only the new API needs to be able
> harness data or perform actions. I.e. the compat layer isn't concerned
> with locking or how the internal data-structures look. As long as the
> new API stays relatively intact the compat layer should be fine.
>
> The main challenge in this compat layer is the randomness of the legacy
> API. Some commands send binary data and some send ASCII data, some are
> very picky in optimizing there buffer sizes and some just don't care.
> Most legacy commands put there data in a single TLV (data container) but some
> segment the data into multiple TLV's. This list of randomness goes on and on..
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620
From: Andy Green @ 2015-02-09 21:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: netdev, Eugene Krasnikov, Kalle Valo, linux-wireless, wcn36xx
In-Reply-To: <CAJAp7OjLDCzLYeb3LHNs1sOHWM64XZWzr46UQ2vNirH_2JibNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10 February 2015 at 05:11, Bjorn Andersson <bjorn-UYDU3/A3LUY@public.gmane.org> wrote:
> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>
>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn-UYDU3/A3LUY@public.gmane.org> wrote:
>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> > wrote:
>> >> WCN3620 powersaving mode is not stable. Disable it if we're
>> >> on a wcn3620 chip type.
>> >>
>> >> Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >> ---
>> >> drivers/net/wireless/ath/wcn36xx/main.c | 4 ++++
>> >> 1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> >> b/drivers/net/wireless/ath/wcn36xx/main.c
>> >> index c4178c7..569d45b 100644
>> >> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> >> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> >> @@ -924,6 +924,10 @@ static int wcn36xx_init_ieee80211(struct wcn36xx
>> >> *wcn)
>> >> IEEE80211_HW_AMPDU_AGGREGATION |
>> >> IEEE80211_HW_TIMING_BEACON_ONLY;
>> >>
>> >> + /* 3620 powersaving currently unstable */
>> >> + if (wcn->chip_version == WCN36XX_CHIP_3620)
>> >> + wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
>> >> +
>> >
>> > Hi Andy,
>> >
>> > I have the same problem (Data Abort Exception in wcnss) on 3680, this
>> > with my wip smd code and a hacked up remoteproc-pil. I haven't spent
>> > any effort on debugging this, but it looks like it's something related
>> > to what we have ported to mainline (or lack thereof) rather than a
>> > 3620 specific issue.
>>
>> Makes sense since I only have 3620, I assumed it's related to that.
>>
>> However he can work for a while with powersaving on, but ping
>> latencies are +600-800ms and he's shaky.
>>
>> Later I found something mac80211 generic scan preparation or post-scan
>> code (for scan initiated by wpa_supplicant) is able to stop wlan
>> traffic after a few goes even if the actual scan mode smd is not sent.
>>
>> At that point I think a nice solution would be a donation of time from
>> guys who specialize in wcn for a living to come and hand out a pony or
>> two...
>>
>
> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
> and remoteproc-tz) so that people with the domain knowledge can go in and
> make it work well.
Sounds great thanks.
I also tried hostapd which is fully workable without encryption, plus
or minus the instabilities mentioned. But for wpa, he chokes trying
to inject a packet. So it's another pony needed from somewhere.
Can I ask if smdtty will also appear? I uplevelled and hacked smdtty
a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
wcn3620 BT working stably for BT keyboard + mouse and even ad2p.
However the hack bound together smdtty ch2 + 3 in smdtty driver and
made it understand about the missing hci protocol byte... this is far
from reasonable for upstream, but it works like the 3.10 except needs
no special bluez / userland treatment. So I'm curious if no smdtty
how the split smd hci / acl link in firmware will appear coherently to
userspace as a normal uart.
-Andy
> Regards,
> Bjorn
--
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 v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: Chen Gang S @ 2015-02-09 21:39 UTC (permalink / raw)
To: David Laight, 'Marcel Holtmann'
Cc: Joe Perches, Sergei Shtylyov, Gustavo F. Padovan, Johan Hedberg,
David S. Miller, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAE0B02@AcuExch.aculab.com>
On 2/10/15 00:57, David Laight wrote:
> From: Marcel Holtmann
>> Hi David,
>>
>>>> So at present, in kernel part, we can only say the original authors
>>>> intended to do like this. And only within kernel part, it can not cause
>>>> issue. I guess, original authors originally knew what we talk about.
>>>
>>> I've just searched for hci_u*filter it is all horrid.
>>> Look at the code for get/set_sockopt of HCI_FILTER.
>>> Someone seems to have done a complete 'bodge job' of fixing the user interface
>>> for apps (32bit and 64bit) on 64bit kernels.
>>
>> we are actually fully aware of that. Just keep in mind that this code is from 2.4.6 kernel and with
>> that most likely 14 years old by now. Unfortunately it ended up as userspace API.
>
> AFAICT the userspace API is always __u32[2] the long[2] is never exposed
> to userspace (certainly not through the socket option code).
>
> Quite why all the casts were added - instead of changing the type
> is probably hidden in the annals of the source repo.
> Some serious archaeology might be in order.
>
For me, I guess what you said above sounds reasonable. But excuse me,
I am not familiar with the related modules outside Linux kernel (at
present, it is out of my border).
I guess, I am not the suitable member to make the related fix patch for
this issue. Welcome any other members to send the fix patch for it.
And for me, if "hci_u*filter" is related with the modules outside kernel
(I guess, it should be), I recommend to put it to the related "uapi"
header.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply
* Re: [PATCH v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: Marcel Holtmann @ 2015-02-09 21:40 UTC (permalink / raw)
To: Chen Gang S
Cc: David Laight, Joe Perches, Sergei Shtylyov, Gustavo F. Padovan,
Johan Hedberg, David S. Miller, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <54D9290A.8070306@sunrus.com.cn>
Hi Chen,
>>>>> So at present, in kernel part, we can only say the original authors
>>>>> intended to do like this. And only within kernel part, it can not cause
>>>>> issue. I guess, original authors originally knew what we talk about.
>>>>
>>>> I've just searched for hci_u*filter it is all horrid.
>>>> Look at the code for get/set_sockopt of HCI_FILTER.
>>>> Someone seems to have done a complete 'bodge job' of fixing the user interface
>>>> for apps (32bit and 64bit) on 64bit kernels.
>>>
>>> we are actually fully aware of that. Just keep in mind that this code is from 2.4.6 kernel and with
>>> that most likely 14 years old by now. Unfortunately it ended up as userspace API.
>>
>> AFAICT the userspace API is always __u32[2] the long[2] is never exposed
>> to userspace (certainly not through the socket option code).
>>
>> Quite why all the casts were added - instead of changing the type
>> is probably hidden in the annals of the source repo.
>> Some serious archaeology might be in order.
>>
>
> For me, I guess what you said above sounds reasonable. But excuse me,
> I am not familiar with the related modules outside Linux kernel (at
> present, it is out of my border).
>
> I guess, I am not the suitable member to make the related fix patch for
> this issue. Welcome any other members to send the fix patch for it.
>
> And for me, if "hci_u*filter" is related with the modules outside kernel
> (I guess, it should be), I recommend to put it to the related "uapi"
> header.
since that is such old code, the "uapi" is essentially what we have as libbluetooth from the BlueZ userspace code.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620
From: Bjorn Andersson @ 2015-02-09 21:40 UTC (permalink / raw)
To: Andy Green
Cc: netdev, Eugene Krasnikov, Kalle Valo, linux-wireless, wcn36xx,
linux-arm-msm
In-Reply-To: <CAAfg0W58Wssa=OKRSGtxY4rQJCzP0uTw__Rd278fc1v7Q0fqUw@mail.gmail.com>
On Mon, Feb 9, 2015 at 1:28 PM, Andy Green <andy.green@linaro.org> wrote:
> On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@kryo.se> wrote:
>> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@linaro.org> wrote:
>>>
>>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
>>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org>
[..]
>>> At that point I think a nice solution would be a donation of time from
>>> guys who specialize in wcn for a living to come and hand out a pony or
>>> two...
>>>
>>
>> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
>> and remoteproc-tz) so that people with the domain knowledge can go in and
>> make it work well.
>
[..]
>
> Can I ask if smdtty will also appear? I uplevelled and hacked smdtty
> a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
> wcn3620 BT working stably for BT keyboard + mouse and even ad2p.
>
> However the hack bound together smdtty ch2 + 3 in smdtty driver and
> made it understand about the missing hci protocol byte... this is far
> from reasonable for upstream, but it works like the 3.10 except needs
> no special bluez / userland treatment. So I'm curious if no smdtty
> how the split smd hci / acl link in firmware will appear coherently to
> userspace as a normal uart.
>
I'm not entirely sure how we're to proceed with this one.
In msm-3.4 with BlueZ the kernel has a driver named hci_smd, that
consumes the two channels and register with the hci core.
In msm-3.10 Qualcomm have dropped this, because they are running
bluedroid which instead consumes the two smd channels in userspace
(through the smd_pkt driver).
We need smd_pkt for modem related matters anyways, so on that we can
run bluedroid and we could bring in hci_smd for use with BlueZ. But
then we would have to configure the kernel based on what stack we want
to run on top.
So we should probably look into userspace and try to consolidate
things there before deciding where to take this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620
From: Andy Green @ 2015-02-09 22:01 UTC (permalink / raw)
To: Bjorn Andersson
Cc: netdev, Eugene Krasnikov, Kalle Valo, linux-wireless, wcn36xx,
linux-arm-msm
In-Reply-To: <CAJAp7Ojpgm=U+AmBSEZrOpv_B7aGpa-rNPiXPjoDbRTS6C84Tw@mail.gmail.com>
On 10 February 2015 at 05:40, Bjorn Andersson <bjorn@kryo.se> wrote:
> On Mon, Feb 9, 2015 at 1:28 PM, Andy Green <andy.green@linaro.org> wrote:
>> On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@kryo.se> wrote:
>>> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@linaro.org> wrote:
>>>>
>>>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
>>>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org>
> [..]
>>>> At that point I think a nice solution would be a donation of time from
>>>> guys who specialize in wcn for a living to come and hand out a pony or
>>>> two...
>>>>
>>>
>>> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
>>> and remoteproc-tz) so that people with the domain knowledge can go in and
>>> make it work well.
>>
> [..]
>>
>> Can I ask if smdtty will also appear? I uplevelled and hacked smdtty
>> a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
>> wcn3620 BT working stably for BT keyboard + mouse and even ad2p.
>>
>> However the hack bound together smdtty ch2 + 3 in smdtty driver and
>> made it understand about the missing hci protocol byte... this is far
>> from reasonable for upstream, but it works like the 3.10 except needs
>> no special bluez / userland treatment. So I'm curious if no smdtty
>> how the split smd hci / acl link in firmware will appear coherently to
>> userspace as a normal uart.
>>
>
> I'm not entirely sure how we're to proceed with this one.
>
> In msm-3.4 with BlueZ the kernel has a driver named hci_smd, that
> consumes the two channels and register with the hci core.
>
> In msm-3.10 Qualcomm have dropped this, because they are running
> bluedroid which instead consumes the two smd channels in userspace
> (through the smd_pkt driver).
>
> We need smd_pkt for modem related matters anyways, so on that we can
> run bluedroid and we could bring in hci_smd for use with BlueZ. But
> then we would have to configure the kernel based on what stack we want
> to run on top.
>
> So we should probably look into userspace and try to consolidate
> things there before deciding where to take this.
I understand, although it's a shame to make a whole new protocol in
bluez when it's just the normal protocol with a byte trimmed at the
start of a block. It can work with stock distro bluez out of the box
if the kernel binds the channels.
The hci_smd thing sounds okay, maybe he can be a module and Android /
bluedroid just doesn't have the module in the rootfs, traditional
Linux gets the module and udev inserts him.
-Andy
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH V1 net-next 0/3] bonding and mlx4 fixes for the HA/LAG support and mlx4 reset flow
From: David Miller @ 2015-02-09 22:04 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, roland, amirv, talal
In-Reply-To: <1423388974-9635-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 8 Feb 2015 11:49:31 +0200
> There are two fixes to the boding + mlx4 HA/LAG support from Moni
> and a patch from Yishai which does further hardening of the mlx4
> reset support for IB kernel ULPs.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: dsa: Remove redundant phy_attach()
From: David Miller @ 2015-02-09 22:06 UTC (permalink / raw)
To: f.fainelli; +Cc: andrew, netdev
In-Reply-To: <54D908B6.9020101@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 09 Feb 2015 11:21:26 -0800
> On 08/02/15 17:29, Andrew Lunn wrote:
>> dsa_slave_phy_setup() finds the phy for the port via device tree and
>> using of_phy_connect(), or it uses the fall back of taking a phy from
>> the switch internal mdio bus and calling phy_connect_direct(). Either
>> way, if a phy is found, phy_attach_direct() is called to attach the
>> phy to the slave device.
>>
>> In dsa_slave_create(), a second call to phy_attach() is made. This
>> results in the warning "PHY already attached". Remove this second,
>> redundant attaching of the phy.
>>
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next 0/3] Add support in ethtool to get expansion ROM version
From: David Miller @ 2015-02-09 22:08 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1423463851-19073-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 9 Feb 2015 12:07:28 +0530
> This series adds support to get expansion ROM version via ethtool getdrvinfo.
> PATCH 1/3 ("ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
> ROM version") is created against net-next tree.
> PATCH 2/3 ("cxgb4: Add support in cxgb4 to get expansion rom version via
> ethtool") is created against net-next tree.
> PATCH 3/3 ("ethtool: Add support to get expansion ROM version in ethtool
> getdrvinfo") is created against ethtool tree.
>
> We have included all the maintainers of respective trees. Kindly review the
> change and let us know in case of any review comments.
...
> V2: Use MACRO instead of hardcoded value for EROM version string len. Based on
> review comment by David Miller.
Patch 1 and 2 applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: Namespecify TCP PMTU mechanism
From: David Miller @ 2015-02-09 22:09 UTC (permalink / raw)
To: fan.du; +Cc: jheffner, netdev, fengyuleidian0615
In-Reply-To: <1423471498-22442-1-git-send-email-fan.du@intel.com>
From: Fan Du <fan.du@intel.com>
Date: Mon, 9 Feb 2015 16:44:58 +0800
> Packetization Layer Path MTU Discovery works separately beside
> Path MTU Discovery at IP level, different net namespace has
> various requirements on which one to chose, e.g., a virutalized
> container instance would require TCP PMTU to probe an usable
> effective mtu for underlying tunnel, while the host would
> employ classical ICMP based pmtu to function.
>
> Hence making TCP PMTU mechanism per net namespace to decouple
> two functionality. Furthermore the probe base MSS should also
> be configured separately for each namespace.
>
> Signed-off-by: Fan Du <fan.du@intel.com>
This does not apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH v2] net: Mellanox: Delete unnecessary checks before the function call "vunmap"
From: David Miller @ 2015-02-09 22:10 UTC (permalink / raw)
To: elfring
Cc: eli, netdev, linux-rdma, linux-kernel, kernel-janitors,
julia.lawall
In-Reply-To: <54D88A26.2060307@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 09 Feb 2015 11:21:26 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 9 Feb 2015 11:10:41 +0100
>
> The vunmap() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Acked-by: Eli Cohen <eli@mellanox.com>
Applied.
^ permalink raw reply
* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates 2015-02-09
From: David Miller @ 2015-02-09 22:18 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1423478641-3138-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 9 Feb 2015 02:43:46 -0800
> This series contains updates to i40e and i40evf only.
Pulled, please send me a fixup patch for the over indented lines in patch #15.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bridge: Fix inability to add non-vlan fdb entry
From: David Miller @ 2015-02-09 22:19 UTC (permalink / raw)
To: makita.toshiaki; +Cc: stephen, vyasevic, bridge, netdev
In-Reply-To: <1423480577-9473-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Mon, 9 Feb 2015 20:16:17 +0900
> Bridge's default_pvid adds a vid by default, by which we cannot add a
> non-vlan fdb entry by default, because br_fdb_add() adds fdb entries for
> all vlans instead of a non-vlan one when any vlan is configured.
>
> # ip link add br0 type bridge
> # ip link set eth0 master br0
> # bridge fdb add 12:34:56:78:90:ab dev eth0 master temp
> # bridge fdb show brport eth0 | grep 12:34:56:78:90:ab
> 12:34:56:78:90:ab dev eth0 vlan 1 static
>
> We expect a non-vlan fdb entry as well as vlan 1:
> 12:34:56:78:90:ab dev eth0 static
>
> To fix this, we need to insert a non-vlan fdb entry if vlan is not
> specified, even when any vlan is configured.
>
> Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: David Miller @ 2015-02-09 22:19 UTC (permalink / raw)
To: kristian.evensen; +Cc: bjorn, netdev, aleksander
In-Reply-To: <CAKfDRXjhN7q98PKeddgoHhx8rFx+bf8YweTE62AbCfbi7v8E3w@mail.gmail.com>
From: Kristian Evensen <kristian.evensen@gmail.com>
Date: Mon, 9 Feb 2015 15:30:02 +0100
> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> That is pretty old relative to this hardware. First commercial release?
>> I don't really want to push you to do an upgrade, but it would sure be
>> nice to have this test repeated on a recent firmware version. Not that
>> I can spot anything particularily promising in the release notes.
>
> I updated firmware now, but still see the same behavior.
>
>> I did find our previous discussions about these two RMNET1 and RMNET2
>> functions, e.g:
>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>> and it seems to indicate that both work as long as you configure them
>> for 802.3 framing. But that could just be an information feedback
>> loop...
>
> That is correct. In order for this device to accept network traffic
> (or driver to accept packets from device), I have to set the transfer
> mode to 802.3.
So what are we going to do with this patch?
^ permalink raw reply
* Re: [PATCH v2 0/2] IPv6 Fix 2 small issues with UFO restoration code
From: David Miller @ 2015-02-09 22:27 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, eric.dumazet, vyasevic
In-Reply-To: <1423492701-21429-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Mon, 9 Feb 2015 09:38:19 -0500
> This series fixes 2 small issues introduced by the
> "Restore UFO support to virtio_net devices" series.
...
> V2: Fixed patch title and description for patch1.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] tcp: don't include Fast Open option in SYN-ACK on pure SYN-data
From: David Miller @ 2015-02-09 22:27 UTC (permalink / raw)
To: ycheng; +Cc: edumazet, ncardwell, netdev
In-Reply-To: <1423514123-6825-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 9 Feb 2015 12:35:23 -0800
> If a server has enabled Fast Open and it receives a pure SYN-data
> packet (without a Fast Open option), it won't accept the data but it
> incorrectly returns a SYN-ACK with a Fast Open cookie and also
> increments the SNMP stat LINUX_MIB_TCPFASTOPENPASSIVEFAIL.
>
> This patch makes the server include a Fast Open cookie in SYN-ACK
> only if the SYN has some Fast Open option (i.e., when client
> requests or presents a cookie).
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Only set TUNNEL_VXLAN_OPT if VXLAN-GBP metadata is set
From: David Miller @ 2015-02-09 22:27 UTC (permalink / raw)
To: tgraf; +Cc: netdev, pshelar
In-Reply-To: <27de6976a7a40d1da2875b93138353724cbfa24b.1423497309.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Mon, 9 Feb 2015 16:56:37 +0100
> This avoids setting TUNNEL_VXLAN_OPT for VXLAN frames which don't
> have any GBP metadata set. It is not invalid to set it but unnecessary.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied.
^ permalink raw reply
* [PATCH v3 0/3] Two printf fixes
From: Rasmus Villemoes @ 2015-02-09 23:44 UTC (permalink / raw)
To: Andrew Morton, Andy Shevchenko, Trond Myklebust, J. Bruce Fields,
David S. Miller
Cc: Rasmus Villemoes, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422525801-26560-1-git-send-email-linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>
Both %pE and %ph are unusable in kasprintf(), since the occurrence of
either will trigger an oops during the first vsnprintf call where
kasprintf tries to find the correct size to allocate. These oopses
could be papered over with somewhat smaller patches than these, but
then the return value from vsnprintf would still not reflect the
actual size needed. For %pE, this requires a change of semantics of
string_escape_mem and hence an annoyingly large diffstat.
Not changed in v3: The test_string_escape_nomem helper is still gone,
and the overflow test done in test_string_escape. I also kept the "if
(out + 1 < end)" conditionals that way.
Changed in v3:
* Add Andy's ack to 1/3.
* Ensure that string_escape_mem doesn't output partial escape
sequences after 2/3, while still preparing for it to do exactly that
in 3/3.
* Leave the return value of string_escape_mem as int.
v2: Suggestions from Andy Shevchenko:
* Simpler fix of hex_string().
* The string_escape_mem change is split in two, 2/3 updating the
internal helpers and 3/3 then changing the external interface.
Rasmus Villemoes (3):
lib/vsprintf.c: Fix potential NULL deref in hex_string
lib/string_helpers.c: Refactor string_escape_mem
lib/string_helpers.c: Change semantics of string_escape_mem
include/linux/string_helpers.h | 8 +-
lib/string_helpers.c | 189 ++++++++++++++++-------------------------
lib/test-string_helpers.c | 35 ++++----
lib/vsprintf.c | 24 ++++--
net/sunrpc/cache.c | 8 +-
5 files changed, 113 insertions(+), 151 deletions(-)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v3 3/3] lib/string_helpers.c: Change semantics of string_escape_mem
From: Rasmus Villemoes @ 2015-02-09 23:44 UTC (permalink / raw)
To: Andrew Morton, Andy Shevchenko, Trond Myklebust, J. Bruce Fields,
David S. Miller
Cc: Rasmus Villemoes, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1423525491-12613-1-git-send-email-linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>
The current semantics of string_escape_mem are inadequate for one of
its current users, vsnprintf(). If that is to honour its contract, it
must know how much space would be needed for the entire escaped
buffer, and string_escape_mem provides no way of obtaining that (short
of allocating a large enough buffer (~4 times input string) to let it
play with, and that's definitely a big no-no inside vsnprintf).
So change the semantics for string_escape_mem to be more
snprintf-like: Return the size of the output that would be generated
if the destination buffer was big enough, but of course still only
write to the part of dst it is allowed to, and don't do
'\0'-termination. It is then up to the caller to detect whether output
was truncated and to append a '\0' if desired. Also, we must output
partial escape sequences, otherwise a call such as snprintf(buf, 3,
"%1pE", "\123") would cause printf to write a \0 to buf[2] but leaving
buf[0] and buf[1] with whatever they previously contained.
This also fixes a bug in the escaped_string() helper function, which
used to unconditionally pass a length of "end-buf" to
string_escape_mem(); since the latter doesn't check osz for being
insanely large, it would happily write to dst. For example,
kasprintf(GFP_KERNEL, "something and then %pE", ...); is an easy way
to trigger an oops.
In test-string_helpers.c, I removed the now meaningless -ENOMEM test,
and replaced it with testing for getting the expected return value
even if the buffer is too small. Also ensure that nothing is written
when osz == 0.
In net/sunrpc/cache.c, I think qword_add still has the same
semantics. Someone should definitely double-check this.
Signed-off-by: Rasmus Villemoes <linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>
---
include/linux/string_helpers.h | 8 ++++----
lib/string_helpers.c | 39 +++++++--------------------------------
lib/test-string_helpers.c | 35 +++++++++++++++--------------------
lib/vsprintf.c | 8 ++++++--
net/sunrpc/cache.c | 8 +++++---
5 files changed, 37 insertions(+), 61 deletions(-)
diff --git a/include/linux/string_helpers.h b/include/linux/string_helpers.h
index 6eb567ac56bc..38a2a6f1fc76 100644
--- a/include/linux/string_helpers.h
+++ b/include/linux/string_helpers.h
@@ -47,22 +47,22 @@ static inline int string_unescape_any_inplace(char *buf)
#define ESCAPE_ANY_NP (ESCAPE_ANY | ESCAPE_NP)
#define ESCAPE_HEX 0x20
-int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
+int string_escape_mem(const char *src, size_t isz, char *dst, size_t osz,
unsigned int flags, const char *esc);
static inline int string_escape_mem_any_np(const char *src, size_t isz,
- char **dst, size_t osz, const char *esc)
+ char *dst, size_t osz, const char *esc)
{
return string_escape_mem(src, isz, dst, osz, ESCAPE_ANY_NP, esc);
}
-static inline int string_escape_str(const char *src, char **dst, size_t sz,
+static inline int string_escape_str(const char *src, char *dst, size_t sz,
unsigned int flags, const char *esc)
{
return string_escape_mem(src, strlen(src), dst, sz, flags, esc);
}
-static inline int string_escape_str_any_np(const char *src, char **dst,
+static inline int string_escape_str_any_np(const char *src, char *dst,
size_t sz, const char *esc)
{
return string_escape_str(src, dst, sz, ESCAPE_ANY_NP, esc);
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 7e2fef1eb40e..df7fda90b333 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -278,14 +278,11 @@ static bool escape_space(unsigned char c, char **dst, char *end)
return false;
}
- if (out + 1 >= end)
- goto skip;
if (out + 0 < end)
out[0] = '\\';
if (out + 1 < end)
out[1] = to;
-skip:
*dst = out + 2;
return true;
}
@@ -309,14 +306,11 @@ static bool escape_special(unsigned char c, char **dst, char *end)
return false;
}
- if (out + 1 >= end)
- goto skip;
if (out + 0 < end)
out[0] = '\\';
if (out + 1 < end)
out[1] = to;
-skip:
*dst = out + 2;
return true;
}
@@ -328,14 +322,11 @@ static bool escape_null(unsigned char c, char **dst, char *end)
if (c)
return false;
- if (out + 1 >= end)
- goto skip;
if (out + 0 < end)
out[0] = '\\';
if (out + 1 < end)
out[1] = '0';
-skip:
*dst = out + 2;
return true;
}
@@ -344,8 +335,6 @@ static bool escape_octal(unsigned char c, char **dst, char *end)
{
char *out = *dst;
- if (out + 3 >= end)
- goto skip;
if (out + 0 < end)
out[0] = '\\';
if (out + 1 < end)
@@ -355,7 +344,6 @@ static bool escape_octal(unsigned char c, char **dst, char *end)
if (out + 3 < end)
out[3] = ((c >> 0) & 0x07) + '0';
-skip:
*dst = out + 4;
return true;
}
@@ -364,8 +352,6 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
{
char *out = *dst;
- if (out + 3 >= end)
- goto skip;
if (out + 0 < end)
out[0] = '\\';
if (out + 1 < end)
@@ -375,7 +361,6 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
if (out + 3 < end)
out[3] = hex_asc_lo(c);
-skip:
*dst = out + 4;
return true;
}
@@ -429,20 +414,17 @@ skip:
* it if needs.
*
* Return:
- * The amount of the characters processed to the destination buffer, or
- * %-ENOMEM if the size of buffer is not enough to put an escaped character is
- * returned.
- *
- * Even in the case of error @dst pointer will be updated to point to the byte
- * after the last processed character.
+ * The total size of the escaped output that would be generated for
+ * the given input and flags. To check whether the output was
+ * truncated, compare the return value to osz. There is room left in
+ * dst for a '\0' terminator if and only if ret < osz.
*/
-int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
+int string_escape_mem(const char *src, size_t isz, char *dst, size_t osz,
unsigned int flags, const char *esc)
{
- char *p = *dst;
+ char *p = dst;
char *end = p + osz;
bool is_dict = esc && *esc;
- int ret;
while (isz--) {
unsigned char c = *src++;
@@ -482,13 +464,6 @@ int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
escape_passthrough(c, &p, end);
}
- if (p > end) {
- *dst = end;
- return -ENOMEM;
- }
-
- ret = p - *dst;
- *dst = p;
- return ret;
+ return p - dst;
}
EXPORT_SYMBOL(string_escape_mem);
diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
index ab0d30e1e18f..5f759c3c2f60 100644
--- a/lib/test-string_helpers.c
+++ b/lib/test-string_helpers.c
@@ -264,12 +264,12 @@ static __init void test_string_escape(const char *name,
const struct test_string_2 *s2,
unsigned int flags, const char *esc)
{
- int q_real = 512;
- char *out_test = kmalloc(q_real, GFP_KERNEL);
- char *out_real = kmalloc(q_real, GFP_KERNEL);
+ size_t out_size = 512;
+ char *out_test = kmalloc(out_size, GFP_KERNEL);
+ char *out_real = kmalloc(out_size, GFP_KERNEL);
char *in = kmalloc(256, GFP_KERNEL);
- char *buf = out_real;
int p = 0, q_test = 0;
+ int q_real;
if (!out_test || !out_real || !in)
goto out;
@@ -301,29 +301,26 @@ static __init void test_string_escape(const char *name,
q_test += len;
}
- q_real = string_escape_mem(in, p, &buf, q_real, flags, esc);
+ q_real = string_escape_mem(in, p, out_real, out_size, flags, esc);
test_string_check_buf(name, flags, in, p, out_real, q_real, out_test,
q_test);
+
+ memset(out_real, 'Z', out_size);
+ q_real = string_escape_mem(in, p, out_real, 0, flags, esc);
+ if (q_real != q_test)
+ pr_warn("Test '%s' failed: flags = %u, osz = 0, expected %d, got %d\n",
+ name, flags, q_test, q_real);
+ if (memchr_inv(out_real, 'Z', out_size))
+ pr_warn("Test '%s' failed: osz = 0 but string_escape_mem wrote to the buffer\n",
+ name);
+
out:
kfree(in);
kfree(out_real);
kfree(out_test);
}
-static __init void test_string_escape_nomem(void)
-{
- char *in = "\eb \\C\007\"\x90\r]";
- char out[64], *buf = out;
- int rc = -ENOMEM, ret;
-
- ret = string_escape_str_any_np(in, &buf, strlen(in), NULL);
- if (ret == rc)
- return;
-
- pr_err("Test 'escape nomem' failed: got %d instead of %d\n", ret, rc);
-}
-
static int __init test_string_helpers_init(void)
{
unsigned int i;
@@ -342,8 +339,6 @@ static int __init test_string_helpers_init(void)
for (i = 0; i < (ESCAPE_ANY_NP | ESCAPE_HEX) + 1; i++)
test_string_escape("escape 1", escape1, i, TEST_STRING_2_DICT_1);
- test_string_escape_nomem();
-
return -EINVAL;
}
module_init(test_string_helpers_init);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3568e3906777..58e1193eaa4b 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1159,8 +1159,12 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
len = spec.field_width < 0 ? 1 : spec.field_width;
- /* Ignore the error. We print as many characters as we can */
- string_escape_mem(addr, len, &buf, end - buf, flags, NULL);
+ /*
+ * string_escape_mem writes as many characters as it can to
+ * the given buffer, and returns the total size of the output
+ * had the buffer been big enough.
+ */
+ buf += string_escape_mem(addr, len, buf, buf < end ? end - buf : 0, flags, NULL);
return buf;
}
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 33fb105d4352..22c4418057f4 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1068,12 +1068,14 @@ void qword_add(char **bpp, int *lp, char *str)
{
char *bp = *bpp;
int len = *lp;
- int ret;
+ int ret, written;
if (len < 0) return;
- ret = string_escape_str(str, &bp, len, ESCAPE_OCTAL, "\\ \n\t");
- if (ret < 0 || ret == len)
+ ret = string_escape_str(str, bp, len, ESCAPE_OCTAL, "\\ \n\t");
+ written = min(ret, len);
+ bp += written;
+ if (ret >= len)
len = -1;
else {
len -= ret;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
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