* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Johannes Berg @ 2013-10-01 12:32 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <52495798.1030408@openwrt.org>
On Mon, 2013-09-30 at 12:51 +0200, Felix Fietkau wrote:
> > Not sure I see why? It's an absolute value after we do the calculations
> > in that interface that has the TPC.
> Maybe we need to rework this somehow, but in the mean time, this patch
> fixes a serious regression that I've been looking into for a while now.
> I haven't worked out the exact conditions that trigger this yet, but
> often when an AP VLAN gets destroyed and recreated, or when a new
> temporary interface is brought up and then down again, the tx power for
> *all* interfaces gets reset to the lowest possible level.
I think we just need to skip VLANs in the loop instead, they don't
really matter here. Can you try that? Using the max would effectively
ignore them since they might always have 0 for bss_conf.txpower.
johannes
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] regulatory: enable channels 52-64 and 100-144 for world roaming
From: Johannes Berg @ 2013-10-01 12:15 UTC (permalink / raw)
To: linux-wireless; +Cc: bzhao, wireless-regdb, mcgrof
In-Reply-To: <1368738412-7740-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-05-16 at 23:06 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> If allowed in a country, these channels typically require DFS
> so mark them as such. Channel 144 is a bit special, it's coming
> into use now to allow more VHT 80 channels, but world roaming
> with passive scanning is acceptable anyway. It seems fairly
> unlikely that it'll be used as the control channel for a VHT
> AP, but it needs to be present to allow a full VHT connection
> to an AP that uses it as one of the secondary channels.
>
> Also enable VHT 160 on these channels, and also for channels
> 36-48 to be able to use VHT 160 there.
So many months later ... I'm merging this now.
johannes
^ permalink raw reply
* Re: [PATCH] iw: use nl80211 for phy_lookup function
From: Johannes Berg @ 2013-10-01 11:53 UTC (permalink / raw)
To: Javier Lopez; +Cc: linux-wireless
In-Reply-To: <1380534243-4766-1-git-send-email-jlopex@cozybit.com>
On Mon, 2013-09-30 at 11:44 +0200, Javier Lopez wrote:
> Original implementation uses sysfs to get dev index from
> dev name. Due the changes on netns and sysfs iw is broken
> if using multiple network namespaces. iw works properly
> if using it from the main namespace, but it won't work if
> using from the new namespace.
>
> Kernel commit 3ff195b0, "sysfs: Implement sysfs tagged
> directory support" patch, added a filtering mechanism
> to sysfs, allowing sysfs directories to look different
> depending on the context where they are being observed.
>
> When an interface is moved to another namespace, the
> interface dissapears from sysfs structure. In order
> to recover access to the directory a solution is to
> remount sysfs from the correct context. This will force
> the user to remount sysfs before using iw from a
> different namespace.
>
> To avoid this issue we can use nl80211 (using
> NL80211_CMD_GET_WIPHY command) this returns the list of
> phys, then process the list, find the device and return
> the device index.
This seems a bit workaround-ish/hack-ish to me. Why would a remount be
necessary? Can't sysfs look at the process tags when determining the
access? Should we maybe do something in our sysfs code in the kernel for
this?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Johannes Berg @ 2013-10-01 11:50 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <524AAE97.5020708@openwrt.org>
On Tue, 2013-10-01 at 13:14 +0200, Felix Fietkau wrote:
> On 2013-10-01 1:05 PM, Johannes Berg wrote:
> > On Fri, 2013-09-06 at 15:06 +0200, Felix Fietkau wrote:
> >> Report the maximum allowable extra antenna gain to the driver to allow
> >> it to reduce the tx power even further based on internal data
> >
> > I don't quite understand the maximum thing here - what's a user to do
> > who has an antenna that goes over? Is that then intended to not be
> > supported? That seems odd. A very high gain antenna might just result in
> > signal distortions, but what's the reason for limiting it this way?
> Very high gain antennas are useful for long distance links.
> The signal is not distorted, but focused directionally, which can easily
> make it exceed regulatory EIRP limits, unless tx power is reduced
> appropriately.
Sure.
> If the user explicitly configures the gain of the directional antenna
> using this patch, mac80211 will reduce the maximum allowed tx power
> setting to stay within the legal limit.
I understand. I don't understand the pieces about "max_antenna_gain".
johannes
^ permalink raw reply
* Re: [PATCH 0/5] Add Mesh Channel Switch Support
From: Johannes Berg @ 2013-10-01 11:31 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-1-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-09-13 at 16:36 -0700, Chun-Yeow Yeoh wrote:
> These patches are reviewed and commented by Bob Copeland and Thomas
> Pedersen. Any further comments are welcomed.
Sorry for the long delay, I posted some more comments. Can't really
comment on how good this is etc. since I'm not familiar with mesh :)
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: process mesh channel switching using beacon
From: Johannes Berg @ 2013-10-01 11:30 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-6-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-09-13 at 16:36 -0700, Chun-Yeow Yeoh wrote:
> err = ieee80211_parse_ch_switch_ie(sdata, elems, beacon,
> ifibss->chandef.chan->band,
> sta_flags, ifibss->bssid,
> - ¶ms.count, &mode,
> + ¶ms.count, &mode, &ttl,
> ¶ms.chandef);
I think it'd be worth doing some refactoring here to have an output
struct ... the parameters to this function are getting unreal. :)
> + if (!cfg80211_chandef_usable(sdata->local->hw.wiphy, ¶ms.chandef,
> + IEEE80211_CHAN_DISABLED)) {
> + sdata_info(sdata,
> + "mesh STA %pM switches to unsupported channel (%d MHz, width:%d, CF1/2: %d/%d MHz), aborting\n",
> + sdata->vif.addr,
> + params.chandef.chan->center_freq,
> + params.chandef.width,
> + params.chandef.center_freq1,
> + params.chandef.center_freq2);
> + }
Seems like you should *do* something here, like return false?
johannes
^ permalink raw reply
* Re: [PATCH 4/5] {nl,cfg,mac}80211: finalizing mesh channel switching
From: Johannes Berg @ 2013-10-01 11:27 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-5-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-09-13 at 16:36 -0700, Chun-Yeow Yeoh wrote:
> Finalizing the requried procedures for channel switching completion and
typo: required
> also adding the function for updating the beacon and probe response frames
> with CSA and MCSP elements. Once the channel switching is completed, the
> CSA and MCSP elements are removed from the beacon or probe response frames
> as defined in the IEEE Std 802.11-2012 section 10.9.8.4.3.
I'd prefer you rewrote this to be more active ... this seems rather
observer style :)
> +int ieee80211_mesh_finish_csa(struct ieee80211_sub_if_data *sdata)
> +{
> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> + int ret = 0;
> +
> + /* Remove the CSA and MCSP elements from the beacon */
> + kfree(ifmsh->csa_settings);
> + ifmsh->csa_settings = NULL;
> + ret = ieee80211_mesh_rebuild_beacon(sdata);
> + if (ret)
> + return -EINVAL;
This seems totally racy with what I pointed out in the other patch ...
> + /* Reset the TTL value and Initiator flag */
> + ifmsh->chsw_init = false;
> + ifmsh->chsw_ttl = 0;
> +
> + ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
> +
> + mcsa_dbg(sdata, "complete switching to center freq %d MHz",
> + sdata->vif.bss_conf.chandef.chan->center_freq);
> + return ret;
return 0
> + tmp_csa_settings = kmalloc(sizeof(struct cfg80211_csa_settings),
> + GFP_ATOMIC);
> + if (!tmp_csa_settings) {
> + mcsa_dbg(sdata, "could not allocate memory for csa beaconing");
You should never print a message for memory allocation failures, they
already give very verbose output.
> + ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
> + return ret;
return 0
johannes
^ permalink raw reply
* Re: [PATCH 3/5] mac80211: adding the CSA and MCSP elements in mesh beaconing
From: Johannes Berg @ 2013-10-01 11:25 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-4-git-send-email-yeohchunyeow@cozybit.com>
Subject should probably just say "add", not "adding".
Should this patch be before the other one so userspace can't trigger an
invalid CSA thing inbetween the two patches?
> + if (ifmsh->csa_settings) {
> + *pos++ = ieee80211_frequency_to_channel(
> + ifmsh->csa_settings->chandef.chan->center_freq);
Why is that csa_settings access not racy?
johannes
^ permalink raw reply
* Re: [PATCH 2/5] {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
From: Johannes Berg @ 2013-10-01 11:24 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-3-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-09-13 at 16:36 -0700, Chun-Yeow Yeoh wrote:
> + skb = dev_alloc_skb(local->tx_headroom + hdr_len +
> + 5 + /* channel switch announcement element */
> + 3 + /* secondary channel offset element */
> + 8); /* mesh channel switch parameters element */
> + if (!skb)
> + return -1;
please fix that to -ENOMEM while at it
> +}
> +
Please no blank line at EOF
johannes
^ permalink raw reply
* Re: [PATCH 1/5] mac80211: process the CSA frame for mesh accordingly
From: Johannes Berg @ 2013-10-01 11:21 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1379115372-28426-2-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-09-13 at 16:36 -0700, Chun-Yeow Yeoh wrote:
> + skb = dev_alloc_skb(local->tx_headroom + len);
> + if (!skb)
> + return -1;
-ENOMEM ?
> + skb_reserve(skb, local->tx_headroom);
> + mgmt_fwd = (struct ieee80211_mgmt *) skb_put(skb, len);
> +
> + /* offset_ttl is based on whether the secondary channel
> + * offset is available or not. Substract 1 from the mesh TTL
> + * and disable the initiator flag before forwarding.
> + */
> + offset_ttl = (len < 42) ? 7 : 10;
> + *(pos + offset_ttl) -= 1;
> + *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
That's somewhat ugly, is there no better way to express that? Maybe with
different structs or something? I guess I can live with it, just asking
though.
> + /* forward or re-broadcast the CSA frame */
> + if (fwd_csa) {
> + if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
> + mcsa_dbg(sdata, "Failed to forward the CSA frame");
> + }
> +
> + /* block the Tx only after fowarding the CSA frame if required */
typo: forwarding
> + block_tx = !!(elems.mesh_chansw_params_ie->mesh_flags
> + & WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT);
No need for !! with bool variables
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Felix Fietkau @ 2013-10-01 11:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380625512.14430.19.camel@jlt4.sipsolutions.net>
On 2013-10-01 1:05 PM, Johannes Berg wrote:
> On Fri, 2013-09-06 at 15:06 +0200, Felix Fietkau wrote:
>> Report the maximum allowable extra antenna gain to the driver to allow
>> it to reduce the tx power even further based on internal data
>
> I don't quite understand the maximum thing here - what's a user to do
> who has an antenna that goes over? Is that then intended to not be
> supported? That seems odd. A very high gain antenna might just result in
> signal distortions, but what's the reason for limiting it this way?
Very high gain antennas are useful for long distance links.
The signal is not distorted, but focused directionally, which can easily
make it exceed regulatory EIRP limits, unless tx power is reduced
appropriately.
If the user explicitly configures the gain of the directional antenna
using this patch, mac80211 will reduce the maximum allowed tx power
setting to stay within the legal limit.
- Felix
^ permalink raw reply
* Re: [PATCH v5 1/2] Bluetooth: btmrvl: add setup handler
From: Johan Hedberg @ 2013-10-01 11:13 UTC (permalink / raw)
To: Bing Zhao
Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org development,
Gustavo F. Padovan, linux-wireless@vger.kernel.org Wireless,
Mike Frysinger, Hyuckjoo Lee, Amitkumar Karwar
In-Reply-To: <B3090D30-6F81-4E12-8F58-E650F77BB72E@holtmann.org>
Hi Marcel & Bing,
On Thu, Sep 26, 2013, Marcel Holtmann wrote:
> >> You're right that we're missing the clearing of the HCI_SETUP flag for
> >> such a scenario. Could you try the attached patch. It should fix the
> >
> > We have tested your patch. Yes, it fixes the problem. Thanks!
>
> then lets get a proper version with full commit message explaining the
> issue merged upstream. As I said, this is a real bug we need to fix.
I've just sent a new patch set titled "[PATCH 0/2] Bluetooth: Fix
hci_dev_open race condition". Bing, could you please test this with your
original setup so we ensure that the issue is still properly handled.
Johan
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Johannes Berg @ 2013-10-01 11:09 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1378230201-25446-3-git-send-email-siwu@hrz.tu-chemnitz.de>
On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote:
> To use DFS in IBSS mode, userspace is required to react to radar events.
> It can inform nl80211 that it is capable of doing so by adding a
> NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
I don't like that name, it makes no sense. This has nothing to do with
the port control (802.1X-style) at all.
> If this attribute is supplied, DFS channels may be used if the driver
> supports it. Support will be checked even if a channel without DFS will
> be joined, as the channel might change later due to scan activity or
> channel switch announcements.
You also really should document *what* is required of userspace here.
You're kinda saying this needs to be implemented, but not saying what
needs to be done. I can't even tell - what does it really have to do?
Don't you implement most of it in patches 3 and 4 anyway in the kernel?
johannes
^ permalink raw reply
* Re: [PATCH 1/4] nl80211: allow CAC only if no operation is going on
From: Johannes Berg @ 2013-10-01 11:06 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1378230201-25446-2-git-send-email-siwu@hrz.tu-chemnitz.de>
On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote:
> A CAC should fail if it is triggered while the interface is already
> running.
Applied, though this is a bit questionable - it forces every driver
implementing this to have the same carrier semantics as mac80211. That
might very well be a good thing, but those semantics aren't really
documented.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Johannes Berg @ 2013-10-01 11:05 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1378472763-36062-2-git-send-email-nbd@openwrt.org>
On Fri, 2013-09-06 at 15:06 +0200, Felix Fietkau wrote:
> Report the maximum allowable extra antenna gain to the driver to allow
> it to reduce the tx power even further based on internal data
I don't quite understand the maximum thing here - what's a user to do
who has an antenna that goes over? Is that then intended to not be
supported? That seems odd. A very high gain antenna might just result in
signal distortions, but what's the reason for limiting it this way?
johannes
^ permalink raw reply
* Re: [PATCH] Don't get iw version from git if there is no .git/
From: Johannes Berg @ 2013-10-01 11:03 UTC (permalink / raw)
To: Florian Schmaus; +Cc: linux-wireless
In-Reply-To: <1378482070-8863-1-git-send-email-fschmaus@gmail.com>
On Fri, 2013-09-06 at 17:41 +0200, Florian Schmaus wrote:
> The version.sh script should only try to get the version from git if the
> source actually resides in a git repository, i.e. .git/ exists. Doing
> otherwise in a non-git source repo results in git ascending until it
> finds a .git directory, which will cause problems in some source-based
> distributions ( https://bugs.gentoo.org/show_bug.cgi?id=482334 ).
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: improve default WMM parameter setting
From: Johannes Berg @ 2013-10-01 10:25 UTC (permalink / raw)
To: Fred Zhou; +Cc: linux-wireless
In-Reply-To: <1378739021-3072-1-git-send-email-fred.zy@gmail.com>
On Mon, 2013-09-09 at 23:03 +0800, Fred Zhou wrote:
> Move the default setting for WMM parameters outside the for loop
> to avoid redundant assignment multiple times.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] doc: fix some typos in documentations
From: Johannes Berg @ 2013-10-01 10:24 UTC (permalink / raw)
To: Xishi Qiu; +Cc: rob, Andrew Morton, linux-doc, LKML, linux-wireless
In-Reply-To: <523921BD.3030205@huawei.com>
On Wed, 2013-09-18 at 11:45 +0800, Xishi Qiu wrote:
>
> to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
> -case allows the driver to be built when rfkill is not configured, which which
> +case allows the driver to be built when rfkill is not configured, which
> case all rfkill API can still be used but will be provided by static inlines
> which compile to almost nothing.
It looks like this was intended to say "in which" instead of the "which
which" you remove, rather than just "which".
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: support reporting A-MSDU subframes individually
From: Johannes Berg @ 2013-10-01 10:22 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <1379943278-1014-1-git-send-email-michal.kazior@tieto.com>
On Mon, 2013-09-23 at 15:34 +0200, Michal Kazior wrote:
> Some devices may not be able to report A-MSDUs in
> single buffers. Drivers for such devices were
> forced to re-assemble A-MSDUs which would then
> be eventually disassembled by mac80211. This could
> lead to CPU cache thrashing and poor performance.
>
> Since A-MSDU has a single sequence number all
> subframes share it. This was in conflict with
> retransmission/duplication recovery
> (IEEE802.11-2012: 9.3.2.10).
>
> Patch introduces a new flag that is meant to be
> set for all individually reported A-MSDU subframes
> except the last one. This ensures the
> last_seq_ctrl is updated after the last subframe
> is processed. If an A-MSDU is actually a duplicate
> transmission all reported subframes will be
> properly discarded.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: use exact-size allocation for authentication frame
From: Johannes Berg @ 2013-10-01 10:20 UTC (permalink / raw)
To: Fred Zhou; +Cc: linux-wireless
In-Reply-To: <1379989981-3440-1-git-send-email-fred.zy@gmail.com>
On Tue, 2013-09-24 at 10:33 +0800, Fred Zhou wrote:
> The authentication frame has a fixied size of 30 bytes
> (including header, algo num, trans seq num, and status)
> followed by a variable challenge text.
> Allocate using exact size, instead of over-allocation
> by sizeof(ieee80211_mgmt).
Applied (a slightly modified version)
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: parse dfs region for internal regdb option
From: Johannes Berg @ 2013-10-01 10:18 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless, linville, rodrigue
In-Reply-To: <1379399136-3181-1-git-send-email-janusz.dziedzic@tieto.com>
On Tue, 2013-09-17 at 08:25 +0200, Janusz Dziedzic wrote:
> Add support for parsing and setting the dfs region (ETSI, FCC, JP)
> when the internal regulatory database is used. Before this
> the DFS region was being ignored even if present on the used
> db.txt
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: add explicit IBSS driver operations
From: Johannes Berg @ 2013-10-01 10:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1378824794-16689-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-09-10 at 16:53 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This can be useful for drivers if they have any failure cases
> when joining an IBSS. Also move setting the queue parameters
> to before this new call, in case the new driver op needs them
> already.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: allow configuring smps_mode_in_ps
From: Johannes Berg @ 2013-10-01 10:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Eliad Peller
In-Reply-To: <1377852561-16754-3-git-send-email-johannes@sipsolutions.net>
On Fri, 2013-08-30 at 10:49 +0200, Johannes Berg wrote:
> From: Eliad Peller <eliad@wizery.com>
>
> When in automatic smps mode (default for station mode),
> mac80211 configures dynamic smps when the station enters
> powersave.
>
> However, drivers might prefer using different modes in this
> case (e.g. due to major throughput degradation).
>
> Add a new hw->smps_mode_in_ps field that can be configured
> by the driver in order to override the default smps dynamic mode.
Dropping this, we ended up not wanting/needing it.
johannes
^ permalink raw reply
* Re: [PATCH 2/3] ieee80211: fix vht cap definitions
From: Johannes Berg @ 2013-10-01 10:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Eliad Peller
In-Reply-To: <1377852561-16754-2-git-send-email-johannes@sipsolutions.net>
On Fri, 2013-08-30 at 10:49 +0200, Johannes Berg wrote:
> From: Eliad Peller <eliad@wizery.com>
>
> VHT_CAP_BEAMFORMER_ANTENNAS cap is actually defined in the draft as
> VHT_CAP_BEAMFORMEE_STS_MAX, and its size is 3 bits long.
>
> VHT_CAP_SOUNDING_DIMENSIONS is also 3 bits long.
>
> Fix the definitions and change the cap masking accordingly.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 1/3] mac80211: fix some snprintf misuses
From: Johannes Berg @ 2013-10-01 10:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Eliad Peller
In-Reply-To: <1377852561-16754-1-git-send-email-johannes@sipsolutions.net>
On Fri, 2013-08-30 at 10:49 +0200, Johannes Berg wrote:
> From: Eliad Peller <eliad@wizery.com>
>
> In some debugfs related functions snprintf was used
> while scnprintf should have been used instead.
>
> (blindly adding the return value of snprintf and supplying
> it to the next snprintf might result in buffer overflow when
> the input is too big)
Applied.
johannes
^ 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