exit
fi
done
+From 5d12f71723762a39435d054d02bbf5fb87c5cd14 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
+Date: Mon, 6 Feb 2017 14:45:15 +0100
+Subject: [PATCH] mac80211: Print text for disassociation reason
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
-diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
-index 7a0c800..ec5ebbb 100644
---- a/drivers/net/ethernet/realtek/r8169.c
-+++ b/drivers/net/ethernet/realtek/r8169.c
-@@ -6927,6 +6927,14 @@ rtl_init_one(struct pci_dev *pdev, const
- for (i = 0; i < ETH_ALEN; i++)
- dev->dev_addr[i] = RTL_R8(MAC0 + i);
-
-+ if (!is_valid_ether_addr(dev->dev_addr)) {
-+ /* Report it and use a random ethernet address instead */
-+ netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
-+ random_ether_addr(dev->dev_addr);
-+ netdev_info(dev, "Using random MAC address: %pM\n",
-+ dev->dev_addr);
-+ }
-+
- SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
- dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
-
-commit 110dc24ad2ae4e9b94b08632fe1eb2fcdff83045
-Author: Dave Chinner <dchinner@redhat.com>
-Date: Tue May 20 08:18:09 2014 +1000
+When disassociation happens only numeric reason is printed
+in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
- xfs: log vector rounding leaks log space
-
- The addition of direct formatting of log items into the CIL
- linear buffer added alignment restrictions that the start of each
- vector needed to be 64 bit aligned. Hence padding was added in
- xlog_finish_iovec() to round up the vector length to ensure the next
- vector started with the correct alignment.
-
- This adds a small number of bytes to the size of
- the linear buffer that is otherwise unused. The issue is that we
- then use the linear buffer size to determine the log space used by
- the log item, and this includes the unused space. Hence when we
- account for space used by the log item, it's more than is actually
- written into the iclogs, and hence we slowly leak this space.
-
- This results on log hangs when reserving space, with threads getting
- stuck with these stack traces:
-
- Call Trace:
- [<ffffffff81d15989>] schedule+0x29/0x70
- [<ffffffff8150d3a2>] xlog_grant_head_wait+0xa2/0x1a0
- [<ffffffff8150d55d>] xlog_grant_head_check+0xbd/0x140
- [<ffffffff8150ee33>] xfs_log_reserve+0x103/0x220
- [<ffffffff814b7f05>] xfs_trans_reserve+0x2f5/0x310
- .....
-
- The 4 bytes is significant. Brain Foster did all the hard work in
- tracking down a reproducable leak to inode chunk allocation (it went
- away with the ikeep mount option). His rough numbers were that
- creating 50,000 inodes leaked 11 log blocks. This turns out to be
- roughly 800 inode chunks or 1600 inode cluster buffers. That
- works out at roughly 4 bytes per cluster buffer logged, and at that
- I started looking for a 4 byte leak in the buffer logging code.
-
- What I found was that a struct xfs_buf_log_format structure for an
- inode cluster buffer is 28 bytes in length. This gets rounded up to
- 32 bytes, but the vector length remains 28 bytes. Hence the CIL
- ticket reservation is decremented by 32 bytes (via lv->lv_buf_len)
- for that vector rather than 28 bytes which are written into the log.
-
- The fix for this problem is to separately track the bytes used by
- the log vectors in the item and use that instead of the buffer
- length when accounting for the log space that will be used by the
- formatted log item.
-
- Again, thanks to Brian Foster for doing all the hard work and long
- hours to isolate this leak and make finding the bug relatively
- simple.
-
- Signed-off-by: Dave Chinner <dchinner@redhat.com>
- Reviewed-by: Christoph Hellwig <hch@lst.de>
- Reviewed-by: Brian Foster <bfoster@redhat.com>
- Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
+---
+ net/mac80211/mlme.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
-diff --git a/fs/xfs/xfs_log.h b/fs/xfs/xfs_log.h
-index 2c40044..84e0deb 100644
---- a/fs/xfs/xfs_log.h
-+++ b/fs/xfs/xfs_log.h
-@@ -24,7 +24,8 @@ struct xfs_log_vec {
- struct xfs_log_iovec *lv_iovecp; /* iovec array */
- struct xfs_log_item *lv_item; /* owner */
- char *lv_buf; /* formatted buffer */
-- int lv_buf_len; /* size of formatted buffer */
-+ int lv_bytes; /* accounted space in buffer */
-+ int lv_buf_len; /* aligned size of buffer */
- int lv_size; /* size of allocated lv */
- };
-
-@@ -52,15 +53,21 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
- return vec->i_addr;
- }
+diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
+index 098ce9b179ee..fcf8d0aa66ec 100644
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -2801,8 +2801,9 @@ static void ieee80211_rx_mgmt_disassoc(struct ieee80211_sub_if_data *sdata,
-+/*
-+ * We need to make sure the next buffer is naturally aligned for the biggest
-+ * basic data type we put into it. We already accounted for this padding when
-+ * sizing the buffer.
-+ *
-+ * However, this padding does not get written into the log, and hence we have to
-+ * track the space used by the log vectors separately to prevent log space hangs
-+ * due to inaccurate accounting (i.e. a leak) of the used log space through the
-+ * CIL context ticket.
-+ */
- static inline void
- xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec, int len)
- {
-- /*
-- * We need to make sure the next buffer is naturally aligned for the
-- * biggest basic data type we put into it. We already accounted for
-- * this when sizing the buffer.
-- */
- lv->lv_buf_len += round_up(len, sizeof(uint64_t));
-+ lv->lv_bytes += len;
- vec->i_len = len;
- }
+ reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
-diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
-index 7e54553..de835da 100644
---- a/fs/xfs/xfs_log_cil.c
-+++ b/fs/xfs/xfs_log_cil.c
-@@ -97,7 +97,7 @@ xfs_cil_prepare_item(
- {
- /* Account for the new LV being passed in */
- if (lv->lv_buf_len != XFS_LOG_VEC_ORDERED) {
-- *diff_len += lv->lv_buf_len;
-+ *diff_len += lv->lv_bytes;
- *diff_iovecs += lv->lv_niovecs;
- }
+- sdata_info(sdata, "disassociated from %pM (Reason: %u)\n",
+- mgmt->sa, reason_code);
++ sdata_info(sdata, "disassociated from %pM (Reason: %u=%s)\n",
++ mgmt->sa, reason_code,
++ ieee80211_get_reason_code_string(reason_code));
-@@ -111,7 +111,7 @@ xfs_cil_prepare_item(
- else if (old_lv != lv) {
- ASSERT(lv->lv_buf_len != XFS_LOG_VEC_ORDERED);
-
-- *diff_len -= old_lv->lv_buf_len;
-+ *diff_len -= old_lv->lv_bytes;
- *diff_iovecs -= old_lv->lv_niovecs;
- kmem_free(old_lv);
- }
-@@ -239,7 +239,7 @@ xlog_cil_insert_format_items(
- * that the space reservation accounting is correct.
- */
- *diff_iovecs -= lv->lv_niovecs;
-- *diff_len -= lv->lv_buf_len;
-+ *diff_len -= lv->lv_bytes;
- } else {
- /* allocate new data chunk */
- lv = kmem_zalloc(buf_size, KM_SLEEP|KM_NOFS);
-@@ -259,6 +259,7 @@ xlog_cil_insert_format_items(
-
- /* The allocated data region lies beyond the iovec region */
- lv->lv_buf_len = 0;
-+ lv->lv_bytes = 0;
- lv->lv_buf = (char *)lv + buf_size - nbytes;
- ASSERT(IS_ALIGNED((unsigned long)lv->lv_buf, sizeof(uint64_t)));
+ ieee80211_set_disassoc(sdata, 0, 0, false, NULL);
+--
+2.11.0
+
projects / packages / kernel.git / blobdiff