[PATCH v2 1/2] usb: dwc3: pci: PHY should be deleted later than dwc3 core
If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.
Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.
Signed-off-by: Peter Chen
Cc: stable@vger.kernel.org
---
Changes for v2:
- Add Cc: stable@vger.kernel.org [Needed after e3ec3eb7]
drivers/usb/dwc3/dwc3-pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 227d4a7..eba9e2b 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -196,9 +196,9 @@ static void dwc3_pci_remove(struct pci_dev *pci)
{
struct dwc3_pci *glue = pci_get_drvdata(pci);
+ platform_device_unregister(glue->dwc3);
platform_device_unregister(glue->usb2_phy);
platform_device_unregister(glue->usb3_phy);
- platform_device_unregister(glue->dwc3);
pci_set_drvdata(pci, NULL);
pci_disable_device(pci);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: dwc3: exynos: PHY should be deleted later than dwc3 core
If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.
Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.
Signed-off-by: Peter Chen
Cc: stable@vger.kernel.org
---
Changes for v2:
- Add Cc: Cc: stable@vger.kernel.org [Needed after d720f057]
drivers/usb/dwc3/dwc3-exynos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index a8afe6e..df6bd5c 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -164,9 +164,9 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
- device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);
clk_disable_unprepare(exynos->clk);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.9.2/3.9.3: stack overrun on s390x and ppc64 (WAS Re: 3.9.2: xfstests triggered panic)
OK, here is clearer stack output from the run. CAI Qian + ./check FSTYP -- xfs (non-debug) PLATFORM -- Linux/s390x ibm-z10-23 3.9.3 001 29s 002 3s 003 2s 004 [not run] this test requires a valid $SCRATCH_DEV 005 2s 006 9s 007 10s 008 7s 009 [not run] this test requires a valid $SCRATCH_DEV 010 [not run] dbtest was not built for this platform 011 9s 012 10s 013 35s 014 5s 015 [not run] this test requires a valid $SCRATCH_DEV 016 [not run] this test requires a valid $SCRATCH_DEV 017 [not run] this test requires a valid $SCRATCH_DEV 018 [not run] this test requires a valid $SCRATCH_DEV 019 [not run] this test requires a valid $SCRATCH_DEV 020 [ 1316.571227] XFS (dm-0): Mounting Filesystem [ 1316.697803] XFS (dm-0): Ending clean mount [ 1318.080615] XFS (dm-0): Ending clean mount [ 1348.791125] XFS (dm-0): Mounting Filesystem [ 1348.989166] XFS (dm-0): Ending clean mount [ 1353.335478] XFS (dm-0): Mounting Filesystem [ 1353.496364] XFS (dm-0): Ending clean mount [ 1357.495427] XFS (dm-0): Mounting Filesystem [ 1357.676971] XFS (dm-0): Ending clean mount [ 1361.646399] XFS (dm-0): Mounting Filesystem [ 1361.890426] XFS (dm-0): Ending clean mount [ 1371.798944] XFS (dm-0): Mounting Filesystem [ 1371.976922] XFS (dm-0): Ending clean mount [ 1384.559103] XFS (dm-0): Mounting Filesystem [ 1384.725657] XFS (dm-0): Ending clean mount [ 1393.131347] XFS (dm-0): Mounting Filesystem [ 1393.357927] XFS (dm-0): Ending clean mount [ 1407.282708] XFS (dm-0): Mounting Filesystem [ 1407.745176] XFS (dm-0): Ending clean mount [ 1422.927074] XFS (dm-0): Mounting Filesystem [ 1423.136266] XFS (dm-0): Ending clean mount [ 1425.500910] XFS (dm-0): Mounting Filesystem [ 1425.608851] XFS (dm-0): Ending clean mount [ 1450.978110] XFS (dm-0): Mounting Filesystem [ 1451.255368] XFS (dm-0): Ending clean mount [ 1453.603742] XFS (dm-0): Mounting Filesystem [ 1453.680657] XFS (dm-0): Ending clean mount [ 1456.262266] XFS (dm-0): Mounting Filesystem [ 1456.330515] XFS (dm-0): Ending clean mount [ 1457.053767] XFS (dm-0): Mounting Filesystem [ 1457.107258] XFS (dm-0): Ending clean mount [ 1462.049374] XFS (dm-0): Mounting Filesystem [ 1462.111389] XFS (dm-0): Ending clean mount [ 1471.109589] ODEBUG: deactivate not available (active state 0) object type: ti mer_list hint: process_timeout+0x0/0x8 [ 1471.109683] [ cut here ] [ 1471.109688] WARNING: at lib/debugobjects.c:260 [ 1471.109692] Modules linked in: lockd(F) sunrpc(F) nf_conntrack_netbios_ns(F) nf_conntrack_broadcast(F) ipt_MASQUERADE(F) ip6table_nat(F) nf_nat_ipv6(F) ip6ta ble_mangle(F) ip6t_REJECT(F) nf_conntrack_ipv6(F) nf_defrag_ipv6(F) iptable_nat( F) nf_nat_ipv4(F) nf_nat(F) iptable_mangle(F) ipt_REJECT(F) nf_conntrack_ipv4(F) nf_defrag_ipv4(F) xt_conntrack(F) nf_conntrack(F) ebtable_filter(F) ebtables(F) ip6table_filter(F) ip6_tables(F) iptable_filter(F) ip_tables(F) sg(F) qeth_l2(F ) vmur(F) xfs(F) libcrc32c(F) dasd_fba_mod(F) dasd_eckd_mod(F) lcs(F) dasd_mod(F ) ctcm(F) qeth(F) qdio(F) ccwgroup(F) fsm(F) dm_mirror(F) dm_region_hash(F) dm_l og(F) dm_mod(F) [ 1471.109848] CPU: 0 Tainted: GF3.9.3 #2 [ 1471.109858] Process swapper/0 (pid: 0, task: 00a2b4d0, ksp: 0 0a17d28) [ 1471.109868] Krnl PSW : 0404c0018000 0046c84a (debug_print_object+ 0xca/0xd8) [ 1471.114762]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA: 3 Krnl GPRS: 00a2b4d0 0067 0101f708 [ 1471.114769]0046c846 84a4d448 0086936a 000 001040700 [ 1471.114773]01a0f290 0401 00874cf8 000 000a395d8 [ 1471.114777]0195f820 0001bd20 0046c846 000 1bc20 [ 1471.114792] Krnl Code: 0046c83a: e3441004lg %r4,0(%r 4,%r1) 0046c840: c0e500139f88 brasl %r14,6e0750 #0046c846: a7f40001 brc 15,46c848 >0046c84a: a7f4ffc2 brc 15,46c7ce 0046c84e: a729 lghi%r2,0 0046c852: a7f4ffd7 brc 15,46c800 0046c856: 0707 bcr 0,%r7 0046c858: ebaff0680024 stmg%r10,%r15,104(%r15) [ 1471.114825] Call Trace: [ 1471.114828] ([<0046c846>] debug_print_object+0xc6/0xd8) [ 1471.114833] [<0046d35c>] debug_object_deactivate+0x15c/0x160 [ 1471.114838] [<00148244>] run_timer_softirq+0x180/0x464 [ 1471.114843] [<0013d8d6>] __do_softirq+0x112/0x42c [ 1471.114847] [<0013ddf8>] irq_exit+0xc8/0xe8 [ 1471.114851] [<0010d55e>] do_extint+0x25e/0x318 [ 1471.114859] [<006f0d90>] ext_skip+0x40/0x44 [ 1471.114866] [<006f05d6>] vtime_stop_cpu+0x52/0xbc [ 1471.114870] ([<006f05b4>] vtime_stop_c
[PATCH 3.9-stable] staging:iio:light:tsl2x7x: fix the error handling in tsl2x7x_probe()
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Wei Yongjun "
commit 3b813798aa7030f1beef638c75f8b0008f737a82 upstream
Fix to return -EINVAL in the i2c device found error handling
case instead of 0, as done elsewhere in this function.
And also correct the fail1 and fail2 lable to do the right thing.
Signed-off-by: Wei Yongjun
Signed-off-by: Jonathan Cameron
Signed-off-by: Jonghwan Choi
---
drivers/staging/iio/light/tsl2x7x_core.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2x7x_core.c
b/drivers/staging/iio/light/tsl2x7x_core.c
index a58731e..2d40c03 100644
--- a/drivers/staging/iio/light/tsl2x7x_core.c
+++ b/drivers/staging/iio/light/tsl2x7x_core.c
@@ -1869,6 +1869,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
dev_info(&chip->client->dev,
"%s: i2c device found does not match
expected id\n",
__func__);
+ ret = -EINVAL;
goto fail1;
}
@@ -1907,7 +1908,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret) {
dev_err(&clientp->dev,
"%s: irq request failed", __func__);
- goto fail2;
+ goto fail1;
}
}
@@ -1920,17 +1921,17 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret) {
dev_err(&clientp->dev,
"%s: iio registration failed\n", __func__);
- goto fail1;
+ goto fail2;
}
dev_info(&clientp->dev, "%s Light sensor found.\n", id->name);
return 0;
-fail1:
+fail2:
if (clientp->irq)
free_irq(clientp->irq, indio_dev);
-fail2:
+fail1:
iio_device_free(indio_dev);
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.9-stable] staging/iio/mxs-lradc: fix preenable for multiple
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Michał Mirosław "
commit c80712c793febdf1b13ad0e1c71a051e071b3fd8 upstream
This fixes 'preenable failed: -EINVAL' error when using this driver.
Signed-off-by: Michał Mirosław "
Signed-off-by: Jonathan Cameron
Signed-off-by: Jonghwan Choi
---
drivers/staging/iio/adc/mxs-lradc.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 55a459b..f5e9e55 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -693,7 +693,6 @@ static void mxs_lradc_trigger_remove(struct iio_dev
*iio)
static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
{
struct mxs_lradc *lradc = iio_priv(iio);
- struct iio_buffer *buffer = iio->buffer;
int ret = 0, chan, ofs = 0;
unsigned long enable = 0;
uint32_t ctrl4_set = 0;
@@ -701,7 +700,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev
*iio)
uint32_t ctrl1_irq = 0;
const uint32_t chan_value = LRADC_CH_ACCUMULATE |
((LRADC_DELAY_TIMER_LOOP - 1) <<
LRADC_CH_NUM_SAMPLES_OFFSET);
- const int len = bitmap_weight(buffer->scan_mask,
LRADC_MAX_TOTAL_CHANS);
+ const int len = bitmap_weight(iio->active_scan_mask,
LRADC_MAX_TOTAL_CHANS);
if (!len)
return -EINVAL;
@@ -728,7 +727,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev
*iio)
lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
- for_each_set_bit(chan, buffer->scan_mask, LRADC_MAX_TOTAL_CHANS) {
+ for_each_set_bit(chan, iio->active_scan_mask, LRADC_MAX_TOTAL_CHANS)
{
ctrl4_set |= chan << LRADC_CTRL4_LRADCSELECT_OFFSET(ofs);
ctrl4_clr |= LRADC_CTRL4_LRADCSELECT_MASK(ofs);
ctrl1_irq |= LRADC_CTRL1_LRADC_IRQ_EN(ofs);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] cgroup: fix a subtle bug in descendant pre-order walk
On Tue, May 21, 2013 at 10:50:21AM +0900, Tejun Heo wrote: > When cgroup_next_descendant_pre() initiates a walk, it checks whether > the subtree root doesn't have any children and if not returns NULL. > Later code assumes that the subtree isn't empty. This is broken > because the subtree may become empty inbetween, which can lead to the > traversal escaping the subtree by walking to the sibling of the > subtree root. > > There's no reason to have the early exit path. Remove it along with > the later assumption that the subtree isn't empty. This simplifies > the code a bit and fixes the subtle bug. > > While at it, fix the comment of cgroup_for_each_descendant_pre() which > was incorrectly referring to ->css_offline() instead of > ->css_online(). > > Signed-off-by: Tejun Heo > Cc: stable@vger.kernel.org Applied to cgroup/for-3.10-fixes. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap.patch added to -mm tree
Subject: +
ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap.patch
added to -mm tree
To:
joseph...@huawei.com,jeff@oracle.com,jl...@evilplan.org,mfas...@suse.com,stable@vger.kernel.org
From: a...@linux-foundation.org
Date: Thu, 23 May 2013 16:07:52 -0700
The patch titled
Subject: ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in
ocfs2_fiemap()
has been added to the -mm tree. Its filename is
ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Joseph Qi
Subject: ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in
ocfs2_fiemap()
Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and
then we did a thorough search for all lock resources in ocfs2_inode_info,
including rw, inode and open lockres and found this bug. My kernel
version is 3.0.13, and it is also in the lastest version 3.9. In
ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should goto
out_unlock instead of out, because we need release buffer head, up read
alloc sem and unlock inode.
Signed-off-by: Joseph Qi
Reviewed-by: Jie Liu
Cc: Mark Fasheh
Cc: Joel Becker
Cc:
Signed-off-by: Andrew Morton
---
fs/ocfs2/extent_map.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
fs/ocfs2/extent_map.c~ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap
fs/ocfs2/extent_map.c
---
a/fs/ocfs2/extent_map.c~ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap
+++ a/fs/ocfs2/extent_map.c
@@ -790,7 +790,7 @@ int ocfs2_fiemap(struct inode *inode, st
&hole_size, &rec, &is_last);
if (ret) {
mlog_errno(ret);
- goto out;
+ goto out_unlock;
}
if (rec.e_blkno == 0ULL) {
_
Patches currently in -mm which might be from joseph...@huawei.com are
ocfs2-unlock-rw-lock-if-inode-lock-failed.patch
ocfs2-goto-out_unlock-if-ocfs2_get_clusters_nocache-failed-in-ocfs2_fiemap.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86/PCI: setup data may be in highmem
On 05/22/2013 02:43 AM, Matt Fleming wrote: > From: Matt Fleming > > pcibios_add_device() assumes that the physical addresses stored in > setup_data are accessible via the direct kernel mapping, and that > calling phys_to_virt() is valid. This isn't guaranteed to be true on x86 > where the direct mapping range is much smaller than on x86-64. > > Calling phys_to_virt() on a highmem address results in the following, > Bjorn: yours or mine? -hpa -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.9] iwlwifi: mvm: remove P2P_DEVICE support
From: Johannes Berg
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it. For iwlmvm that implies disabling P2P completely
as it can't support P2P operation w/o P2P Device.
Signed-off-by: Johannes Berg
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index dd158ec..11dc7df 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -84,15 +84,6 @@ static const struct ieee80211_iface_limit iwl_mvm_limits[] =
{
.types = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_AP),
},
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_CLIENT) |
- BIT(NL80211_IFTYPE_P2P_GO),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
- },
};
static const struct ieee80211_iface_combination iwl_mvm_iface_combinations[] =
{
@@ -161,10 +152,7 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
hw->chanctx_data_size = sizeof(struct iwl_mvm_phy_ctxt);
hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
- BIT(NL80211_IFTYPE_P2P_CLIENT) |
- BIT(NL80211_IFTYPE_AP) |
- BIT(NL80211_IFTYPE_P2P_GO) |
- BIT(NL80211_IFTYPE_P2P_DEVICE);
+ BIT(NL80211_IFTYPE_AP);
hw->wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY |
WIPHY_FLAG_DISABLE_BEACON_HINTS |
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6-3.9] mac80211_hwsim: remove P2P_DEVICE support
From: Johannes Berg
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it.
Signed-off-by: Johannes Berg
---
drivers/net/wireless/mac80211_hwsim.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index cb34c78..69bbf6f 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2169,7 +2169,6 @@ static const struct ieee80211_iface_limit
hwsim_if_limits[] = {
#endif
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_P2P_GO) },
- { .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) },
};
static struct ieee80211_iface_combination hwsim_if_comb = {
@@ -2295,8 +2294,7 @@ static int __init init_mac80211_hwsim(void)
BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_ADHOC) |
- BIT(NL80211_IFTYPE_MESH_POINT) |
- BIT(NL80211_IFTYPE_P2P_DEVICE);
+ BIT(NL80211_IFTYPE_MESH_POINT);
hw->flags = IEEE80211_HW_MFP_CAPABLE |
IEEE80211_HW_SIGNAL_DBM |
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/21] 3.9.4-stable review
On Thu, May 23, 2013 at 04:52:48PM +, Shuah Khan wrote: > On Wed, 2013-05-22 at 15:10 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.9.4 release. > > There are 21 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri May 24 20:50:18 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.4-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Patches applied cleanly to 3.0.79, 3.4.46, and 3.9.3 > > Compiled and booted on the following systems: > > Samsung Series 9 900X4C Intel Corei5: > (3.4.47-rc1, and 3.9.4-rc1) > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: > (3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1) > > dmesgs for all releases look good. No regressions compared to the previous > dmesgs for each of these releases. Great, thanks for testing and letting us know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 0/3] 3.0.80-stable review
On Wed, 2013-05-22 at 15:19 -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.0.80 release.
> There are 3 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri May 24 22:11:00 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.80-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patches applied cleanly to 3.0.79, 3.4.46, and 3.9.3
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5:
(3.4.47-rc1, and 3.9.4-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)
dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.
Reviewed patches.
Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)
Cross-compile tests results:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y and 3.9.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group
Samsung Research America (Silicon Valley)
shuah...@samsung.com | (970) 672-0658
N�r��yb�X��ǧv�^�){.n�+��z)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [ 0/5] 3.4.47-stable review
On Wed, 2013-05-22 at 15:18 -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.47 release.
> There are 5 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri May 24 22:10:47 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.47-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patches applied cleanly to 3.0.79, 3.4.46, and 3.9.3
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5:
(3.4.47-rc1, and 3.9.4-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)
dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.
Reviewed patches.
Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1)
Cross-compile tests results:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y and 3.9.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group
Samsung Research America (Silicon Valley)
shuah...@samsung.com | (970) 672-0658
N�r��yb�X��ǧv�^�){.n�+��z)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [ 00/21] 3.9.4-stable review
On Wed, 2013-05-22 at 15:10 -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.9.4 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri May 24 20:50:18 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.4-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.79, 3.4.46, and 3.9.3 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.47-rc1, and 3.9.4-rc1) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. Reviewed patches. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.80-rc1, 3.4.47-rc1, and 3.9.4-rc1) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y and 3.9.y mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658
Re: https://lkml.org/lkml/2013/2/1/531
Am 23.05.2013 14:35, schrieb Matthew O'Connor: > On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote: >> Hm, i tried to apply it to 3.4.46 but it does not work: >> >> node02:/ocfs2/usr/src/linux-3.4.46# patch -p1 <../bridge-patch-3.4.46 >> patching file drivers/net/bonding/bond_alb.c >> Hunk #1 FAILED at 704. >> 1 out of 1 hunk FAILED -- saving rejects to file >> drivers/net/bonding/bond_alb.c.rej >> patching file drivers/net/bonding/bonding.h >> patching file include/linux/etherdevice.h >> Hunk #1 FAILED at 277. >> 1 out of 1 hunk FAILED -- saving rejects to file >> include/linux/etherdevice.h.rej > That is extremely odd, considering I applied this to a freshly > downloaded kernel source directly from kernel.org before resubmitting it: > > hv11:~/kernel/linux-3.4.46$ patch -p1 < > ../balance-alb-patches/balance-alb-3.4.patch > patching file drivers/net/bonding/bond_alb.c > patching file drivers/net/bonding/bonding.h > patching file include/linux/etherdevice.h > > > Here's the patch as an attachment instead; I suspect it keeps getting > damaged by my method of inclusion. Thank you, this now worked for me! -- Mit freundlichen Grüßen, Florian Wiessner Smart Weblications GmbH Martinsberger Str. 1 D-95119 Naila fon.: +49 9282 9638 200 fax.: +49 9282 9638 205 24/7: +49 900 144 000 00 - 0,99 EUR/Min* http://www.smart-weblications.de -- Sitz der Gesellschaft: Naila Geschäftsführer: Florian Wiessner HRB-Nr.: HRB 3840 Amtsgericht Hof *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel v3.2 used in SlackWare 14.00 please, backport all needed patches Re: [PATCH net, 1/2] hyperv: Fix a kernel warning from netvsc_linkstatus_callback()
Hi!
(the 3.2 version is different,
and it's instaging. (at not used by distros anyway))
No: used
Linux Kernel v3.2 used in:
-- SlackWare 14.00
This is actual stable version SlackWare
Please, backport all(!) needed patches
I'm download https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.45.tar.xz
File ata_piix.c ( SHA1 ceaf441142ad3f6768ff71f023e73d0695458e2c ) from
./linux-3.2.45/drivers/ata/
not contain:
( even not contain sub-string "Hyper-V")
== ( VVM: symbol TAB replaced by Space+Space -- special for users of MS IE, MS
OutLook [Express] )
static int prefer_ms_hyperv = 1;
module_param(prefer_ms_hyperv, int, 0);
MODULE_PARM_DESC(prefer_ms_hyperv,
"Prefer Hyper-V paravirtualization drivers instead of ATA, "
"0 - Use ATA drivers, "
"1 (Default) - Use the paravirtualization drivers.");
static void piix_ignore_devices_quirk(struct ata_host *host)
{
#if IS_ENABLED(CONFIG_HYPERV_STORAGE)
static const struct dmi_system_id ignore_hyperv[] = {
{
/* On Hyper-V hypervisors the disks are exposed on
* both the emulated SATA controller and on the
* paravirtualised drivers. The CD/DVD devices
* are only exposed on the emulated controller.
* Request we ignore ATA devices on this host.
*/
.ident = "Hyper-V Virtual Machine",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR,
"Microsoft Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
},
},
{ } /* terminate list */
};
static const struct dmi_system_id allow_virtual_pc[] = {
{
/* In MS Virtual PC guests the DMI ident is nearly
* identical to a Hyper-V guest. One difference is the
* product version which is used here to identify
* a Virtual PC guest. This entry allows ata_piix to
* drive the emulated hardware.
*/
.ident = "MS Virtual PC 2007",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR,
"Microsoft Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
DMI_MATCH(DMI_PRODUCT_VERSION, "VS2005R2"),
},
},
{ } /* terminate list */
};
const struct dmi_system_id *ignore = dmi_first_match(ignore_hyperv);
const struct dmi_system_id *allow = dmi_first_match(allow_virtual_pc);
if (ignore && !allow && prefer_ms_hyperv) {
host->flags |= ATA_HOST_IGNORE_ATA;
dev_info(host->dev, "%s detected, ATA device ignore set\n",
ignore->ident);
}
#endif
==
_Absolutly_ ( as _minimum_ for SlackWare 14.00 ) need backport requested at
2012-06-08(!) :
( look on sub-string "3.2")
==
- Original Message -
From: "Victor Miasnikov"
To: "Greg KH" ; "Jonathan Nieder" ; "Andy Whitcroft"
Cc: ; ; "KY Srinivasan"; "Mike
Sterling"
Sent: Friday, June 08, 2012 1:36 PM
Subject: Re: Re: ToDo: backport to v3.4 , v3.3 , v3.2 patches 1b) db63a4c8115a
libata 1) cd006086fa5d ata_piix: defer
disks to the Hyper-V drivers by default Fw: use hv_storvsc instead of ata_piix
for IDE disks ( but not for the CD-ROM)
. . .
{
> > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
> > Please, _fix_ errors related "use hv_storvsc instead of ata_piix to
> > handle the IDE disks devices ( but not for the CD-ROM)"
i.e. need backport to all actual version after 3.1
cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default
and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices
}
==
and not forget patch related Bug 52821 :
{{
== ==
- Original Message -
From: vvm
To: Andreas
Sent: Wednesday, January 30, 2013 4:20 PM
Subject: FIXed: ef773e1..bec35f4 Re: ata_piix.prefer_ms_hyperv=0 works Fw: Bug
52821 - ata_piix ATA_HOST_IGNORE_ATA for
Hyper-V also affects Virtual PC 7
https://bugzilla.novell.com/show_bug.cgi?id=737532 Or
https://bugzilla.kernel.org/show_bug.cgi?id=52821
Hi!
Short:
Still, if there is a way to cleanly identify Hyper-V but not Virtual PC 7, this
would be great!
FIXed: ef773e1..bec35f4
Write in
https://bugzilla.kernel.org/show_bug.cgi?id=52821
"please, backport to 3.4 . . . 3.6 . . . 3.7"
. . .
Full:
(
. . .
Still, if there is a way to cleanly identify Hyper-V but not Virtual PC 7, this
would be great!
FIXed: ef773e1..bec35f4
- Original Message -
From: "Jeff Garzik"
To: "Olaf Hering"
Cc: . . . ; "KY Srinivasan"
Sent: Wednesday, November 28, 2012 8:44 PM
Subject: Re: [PATCH] ata_piix: reenable MS Virtual PC guests
On 09/18/2012 11:48 AM, Olaf Hering wrote:
An earlier commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c ("ata_piix:
defer disks to the Hyper-V drivers by default") broke MS Virtual PC
guests. Hyper-V guests and Virtual PC guests have nearly identical DMI
info. As a result the driver does currently ignore the emulated hardware
in Virtual PC guests and defers the handling to hv_blkvsc [ VVM: in current ver
kernel -- hv_storvsc ] . Since Virtual
PC does not offer paravirtualized drivers no disks will be found in the
guest.
One difference in the DMI info is the product version. This
Re: https://lkml.org/lkml/2013/2/1/531
On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote:
> node02:/ocfs2/usr/src/linux-3.4.46# cat drivers/net/bonding/bond_alb.c.rej
My most sincere apologies - one more time, from a different mail server
that hopefully won't go around changing my attachments. If this doesn't
work I guess sendmail will be the next alternative.
-- Matthew
diff -uprN linux-3.4.28/drivers/net/bonding/bond_alb.c linux-3.4.28-patched/drivers/net/bonding/bond_alb.c
--- linux-3.4.28/drivers/net/bonding/bond_alb.c 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/drivers/net/bonding/bond_alb.c 2013-01-30 15:37:25.121708311 -0500
@@ -704,6 +704,12 @@ static struct slave *rlb_arp_xmit(struct
struct arp_pkt *arp = arp_pkt(skb);
struct slave *tx_slave = NULL;
+ /* Don't modify or load balance ARPs that do not originate locally
+ * (e.g.,arrive via a bridge).
+ */
+ if (!bond_slave_has_mac(bond, arp->mac_src))
+ return NULL;
+
if (arp->op_code == htons(ARPOP_REPLY)) {
/* the arp must be sent on the selected
* rx channel
diff -uprN linux-3.4.28/drivers/net/bonding/bonding.h linux-3.4.28-patched/drivers/net/bonding/bonding.h
--- linux-3.4.28/drivers/net/bonding/bonding.h 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/drivers/net/bonding/bonding.h 2013-01-30 15:37:25.121708311 -0500
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -450,6 +451,18 @@ static inline void bond_destroy_proc_dir
}
#endif
+static inline struct slave *bond_slave_has_mac(struct bonding *bond,
+ const u8 *mac)
+{
+ int i = 0;
+ struct slave *tmp;
+
+ bond_for_each_slave(bond, tmp, i)
+ if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
+ return tmp;
+
+ return NULL;
+}
/* exported from bond_main.c */
extern int bond_net_id;
diff -uprN linux-3.4.28/include/linux/etherdevice.h linux-3.4.28-patched/include/linux/etherdevice.h
--- linux-3.4.28/include/linux/etherdevice.h 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/include/linux/etherdevice.h 2013-01-30 15:37:25.121708311 -0500
@@ -277,4 +277,37 @@ static inline unsigned long compare_ethe
#endif
}
+/**
+ * ether_addr_equal_64bits - Compare two Ethernet addresses
+ * @addr1: Pointer to an array of 8 bytes
+ * @addr2: Pointer to an other array of 8 bytes
+ *
+ * Compare two Ethernet addresses, returns true if equal, false otherwise.
+ *
+ * The function doesn't need any conditional branches and possibly uses
+ * word memory accesses on CPU allowing cheap unaligned memory reads.
+ * arrays = { byte1, byte2, byte3, byte4, byte5, byte6, pad1, pad2 }
+ *
+ * Please note that alignment of addr1 & addr2 are only guaranteed to be 16 bits.
+ */
+
+static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
+ const u8 addr2[6+2])
+{
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+unsigned long fold = ((*(unsigned long *)addr1) ^
+ (*(unsigned long *)addr2));
+
+if (sizeof(fold) == 8)
+return zap_last_2bytes(fold) == 0;
+
+fold |= zap_last_2bytes((*(unsigned long *)(addr1 + 4)) ^
+(*(unsigned long *)(addr2 + 4)));
+return fold == 0;
+#else
+return ether_addr_equal(addr1, addr2);
+#endif
+}
+
+
#endif /* _LINUX_ETHERDEVICE_H */
Re: https://lkml.org/lkml/2013/2/1/531
On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote:
> Hm, i tried to apply it to 3.4.46 but it does not work:
>
> node02:/ocfs2/usr/src/linux-3.4.46# patch -p1 <../bridge-patch-3.4.46
> patching file drivers/net/bonding/bond_alb.c
> Hunk #1 FAILED at 704.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/bonding/bond_alb.c.rej
> patching file drivers/net/bonding/bonding.h
> patching file include/linux/etherdevice.h
> Hunk #1 FAILED at 277.
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/linux/etherdevice.h.rej
That is extremely odd, considering I applied this to a freshly
downloaded kernel source directly from kernel.org before resubmitting it:
hv11:~/kernel/linux-3.4.46$ patch -p1 <
../balance-alb-patches/balance-alb-3.4.patch
patching file drivers/net/bonding/bond_alb.c
patching file drivers/net/bonding/bonding.h
patching file include/linux/etherdevice.h
Here's the patch as an attachment instead; I suspect it keeps getting
damaged by my method of inclusion.
diff -uprN linux-3.4.28/drivers/net/bonding/bond_alb.c linux-3.4.28-patched/drivers/net/bonding/bond_alb.c
--- linux-3.4.28/drivers/net/bonding/bond_alb.c 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/drivers/net/bonding/bond_alb.c 2013-01-30 15:37:25.121708311 -0500
@@ -704,6 +704,12 @@ static struct slave *rlb_arp_xmit(struct
struct arp_pkt *arp = arp_pkt(skb);
struct slave *tx_slave = NULL;
+ /* Don't modify or load balance ARPs that do not originate locally
+ * (e.g.,arrive via a bridge).
+ */
+ if (!bond_slave_has_mac(bond, arp->mac_src))
+ return NULL;
+
if (arp->op_code == htons(ARPOP_REPLY)) {
/* the arp must be sent on the selected
* rx channel
diff -uprN linux-3.4.28/drivers/net/bonding/bonding.h linux-3.4.28-patched/drivers/net/bonding/bonding.h
--- linux-3.4.28/drivers/net/bonding/bonding.h 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/drivers/net/bonding/bonding.h 2013-01-30 15:37:25.121708311 -0500
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -450,6 +451,18 @@ static inline void bond_destroy_proc_dir
}
#endif
+static inline struct slave *bond_slave_has_mac(struct bonding *bond,
+ const u8 *mac)
+{
+ int i = 0;
+ struct slave *tmp;
+
+ bond_for_each_slave(bond, tmp, i)
+ if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
+ return tmp;
+
+ return NULL;
+}
/* exported from bond_main.c */
extern int bond_net_id;
diff -uprN linux-3.4.28/include/linux/etherdevice.h linux-3.4.28-patched/include/linux/etherdevice.h
--- linux-3.4.28/include/linux/etherdevice.h 2013-01-27 23:51:45.0 -0500
+++ linux-3.4.28-patched/include/linux/etherdevice.h 2013-01-30 15:37:25.121708311 -0500
@@ -277,4 +277,37 @@ static inline unsigned long compare_ethe
#endif
}
+/**
+ * ether_addr_equal_64bits - Compare two Ethernet addresses
+ * @addr1: Pointer to an array of 8 bytes
+ * @addr2: Pointer to an other array of 8 bytes
+ *
+ * Compare two Ethernet addresses, returns true if equal, false otherwise.
+ *
+ * The function doesn't need any conditional branches and possibly uses
+ * word memory accesses on CPU allowing cheap unaligned memory reads.
+ * arrays = { byte1, byte2, byte3, byte4, byte5, byte6, pad1, pad2 }
+ *
+ * Please note that alignment of addr1 & addr2 are only guaranteed to be 16 bits.
+ */
+
+static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
+ const u8 addr2[6+2])
+{
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+unsigned long fold = ((*(unsigned long *)addr1) ^
+ (*(unsigned long *)addr2));
+
+if (sizeof(fold) == 8)
+return zap_last_2bytes(fold) == 0;
+
+fold |= zap_last_2bytes((*(unsigned long *)(addr1 + 4)) ^
+(*(unsigned long *)(addr2 + 4)));
+return fold == 0;
+#else
+return ether_addr_equal(addr1, addr2);
+#endif
+}
+
+
#endif /* _LINUX_ETHERDEVICE_H */
Re: https://lkml.org/lkml/2013/2/1/531
Am 23.05.2013 01:17, schrieb Matthew O'Connor:
> This is the backported patch I submitted previously. Hopefully this
> time around it won't be too messed up, I'm using Thunderbird instead of
> the web interface. I have applied it successfully and without warnings
> against 3.4.46. It builds, but is otherwise untested beyond what I did
> when I originally submitted back in Feb. This patch applies only to the
> 3.4 series kernel, although with minor changes it will work for 3.0,
> 3.2, and 3.7. If you're interested, I can submit the other patches
> shortly. If this submission still does not conform to standards, please
> let me know where I went wrong. For what it's worth I dropped the patch
> contents directly into the email, but I can attach it instead if that
> would work better.
>
Hm, i tried to apply it to 3.4.46 but it does not work:
node02:/ocfs2/usr/src/linux-3.4.46# patch -p1 <../bridge-patch-3.4.46
patching file drivers/net/bonding/bond_alb.c
Hunk #1 FAILED at 704.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/bonding/bond_alb.c.rej
patching file drivers/net/bonding/bonding.h
patching file include/linux/etherdevice.h
Hunk #1 FAILED at 277.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/etherdevice.h.rej
node02:/ocfs2/usr/src/linux-3.4.46# cat drivers/net/bonding/bond_alb.c.rej
--- drivers/net/bonding/bond_alb.c 2013-01-27 23:51:45.0 -0500
+++ drivers/net/bonding/bond_alb.c 2013-01-30 15:37:25.121708311 -0500
@@ -704,6 +704,12 @@
struct arp_pkt *arp = arp_pkt(skb);
struct slave *tx_slave = NULL;
+/* Don't modify or load balance ARPs that do not originate locally
+ * (e.g.,arrive via a bridge).
+ */
+if (!bond_slave_has_mac(bond, arp->mac_src))
+return NULL;
+
if (arp->op_code == htons(ARPOP_REPLY)) {
/* the arp must be sent on the selected
* rx channel
node02:/ocfs2/usr/src/linux-3.4.46# cat include/linux/etherdevice.h.rej
--- include/linux/etherdevice.h 2013-01-27 23:51:45.0 -0500
+++ include/linux/etherdevice.h 2013-01-30 15:37:25.121708311 -0500
@@ -277,4 +277,37 @@
#endif
}
+/**
+ * ether_addr_equal_64bits - Compare two Ethernet addresses
+ * @addr1: Pointer to an array of 8 bytes
+ * @addr2: Pointer to an other array of 8 bytes
+ *
+ * Compare two Ethernet addresses, returns true if equal, false otherwise.
+ *
+ * The function doesn't need any conditional branches and possibly uses
+ * word memory accesses on CPU allowing cheap unaligned memory reads.
+ * arrays = { byte1, byte2, byte3, byte4, byte5, byte6, pad1, pad2 }
+ *
+ * Please note that alignment of addr1 & addr2 are only guaranteed to be 16
bits.
+ */
+
+static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
+ const u8 addr2[6+2])
+{
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+unsigned long fold = ((*(unsigned long *)addr1) ^
+ (*(unsigned long *)addr2));
+
+if (sizeof(fold) == 8)
+return zap_last_2bytes(fold) == 0;
+
+fold |= zap_last_2bytes((*(unsigned long *)(addr1 + 4)) ^
+(*(unsigned long *)(addr2 + 4)));
+return fold == 0;
+#else
+return ether_addr_equal(addr1, addr2);
+#endif
+}
+
+
#endif/* _LINUX_ETHERDEVICE_H */
>
> [ Upstream commit 567b871e503316b0927e54a3d7c86d50b722d955 ]
>
> bonding: rlb mode of bond should not alter ARP originating via bridge
>
> Do not modify or load balance ARP packets passing through balance-alb
> mode (wherein the ARP did not originate locally, and arrived via a bridge).
>
> Modifying pass-through ARP replies causes an incorrect MAC address
> to be placed into the ARP packet, rendering peers unable to communicate
> with the actual destination from which the ARP reply originated.
>
> Load balancing pass-through ARP requests causes an entry to be
> created for the peer in the rlb table, and bond_alb_monitor will
> occasionally issue ARP updates to all peers in the table instrucing them
> as to which MAC address they should communicate with; this occurs when
> some event sets rx_ntt. In the bridged case, however, the MAC address
> used for the update would be the MAC of the slave, not the actual source
> MAC of the originating destination. This would render peers unable to
> communicate with the destinations beyond the bridge.
>
> Signed-off-by: Matthew O'Connor
> CC: Zheng Li
> Cc: Jay Vosburgh
> Cc: Andy Gospodarek
> Cc: "David S. Miller"
>
>
> diff -uprN linux-3.4.28/drivers/net/bonding/bond_alb.c
> linux-3.4.28-patched/drivers/net/bonding/bond_alb.c
> --- linux-3.4.28/drivers/net/bonding/bond_alb.c2013-01-27
> 23:51:45.0 -0500
> +++ linux-3.4.28-patched/drivers/net/bonding/bond_alb.c2013-01-30
> 15:37:25.121708311 -0500
> @@ -704,6 +704,12 @@ static struct slave *rlb_arp_xmit(struct
> struct arp_pkt *arp = arp_pkt(skb);
> struct slave *tx_slave = NULL;
>
> +
[3.5.y.z extended stable] Linux 3.5.7.13
I am announcing the release of the 3.5.7.13 tree of stable patches. This tree picks up the latest 3.5 stable release upstream, and add patches on top that were later marked for stable but can't be added to 3.5, as it is not anymore an stable series maintained upstream. The tree is maintained by the Ubuntu Kernel Team, with the intention to continue to provide support for the 3.5 series. Anyone is welcomed on using it or contributing to this effort. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable The updated 3.5.y tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.5.y The diffstat and shortlog with changes since previous v3.5.7.12 release are shown below. -Luis -- Makefile | 2 +- arch/arm/configs/at91sam9g45_defconfig | 1 - arch/arm/include/asm/cmpxchg.h | 8 +- arch/arm/include/asm/hardware/iop3xx.h | 2 +- arch/arm/mach-at91/setup.c | 2 +- arch/arm/mach-exynos/include/mach/regs-pmu.h | 1 + arch/arm/mach-exynos/pmu.c | 5 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 4 +- arch/arm/mach-u300/include/mach/u300-regs.h | 2 +- arch/avr32/configs/favr-32_defconfig | 1 - arch/avr32/configs/merisc_defconfig | 1 - arch/powerpc/include/asm/ppc-opcode.h| 4 + arch/powerpc/include/asm/rtas.h | 2 + arch/powerpc/kernel/head_64.S| 1 + arch/powerpc/kernel/rtas.c | 113 +++ arch/powerpc/kernel/traps.c | 10 ++- arch/powerpc/mm/numa.c | 2 +- arch/powerpc/platforms/cell/spufs/inode.c| 1 + arch/powerpc/platforms/pseries/suspend.c | 22 ++ arch/s390/include/asm/pgtable.h | 4 + arch/tile/Kconfig| 14 +++- arch/tile/include/hv/hypervisor.h| 27 ++- arch/tile/kernel/head_32.S | 2 +- arch/tile/kernel/head_64.S | 12 ++- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 27 +-- arch/x86/kernel/irq.c| 4 - arch/x86/kvm/vmx.c | 6 ++ arch/x86/mm/init.c | 5 ++ arch/x86/xen/enlighten.c | 15 drivers/acpi/acpica/exfldio.c| 14 +++- drivers/acpi/ec.c| 4 +- drivers/block/drbd/drbd_receiver.c | 1 - drivers/char/ipmi/ipmi_bt_sm.c | 4 +- drivers/char/ipmi/ipmi_devintf.c | 14 +++- drivers/cpufreq/exynos-cpufreq.c | 4 +- drivers/cpufreq/longhaul.c | 10 ++- drivers/dma/pch_dma.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 + drivers/gpu/drm/ast/ast_fb.c | 43 +- drivers/gpu/drm/ast/ast_ttm.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.h | 2 + drivers/gpu/drm/cirrus/cirrus_fbdev.c| 38 - drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +- drivers/gpu/drm/drm_gem.c| 4 +- drivers/gpu/drm/drm_prime.c | 76 +- drivers/gpu/drm/gma500/psb_irq.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 28 +-- drivers/gpu/drm/i915/i915_gem_stolen.c | 81 +-- drivers/gpu/drm/i915/intel_display.c | 3 + drivers/gpu/drm/i915/intel_dp.c | 5 -- drivers/gpu/drm/i915/intel_dvo.c | 13 ++- drivers/gpu/drm/i915/intel_lvds.c| 10 ++- drivers/gpu/drm/i915/intel_panel.c | 7 +- drivers/gpu/drm/mgag200/mgag200_drv.h| 2 + drivers/gpu/drm/mgag200/mgag200_fb.c | 43 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 69 ++-- drivers/gpu/drm/mgag200/mgag200_ttm.c| 4 +- drivers/gpu/drm/radeon/atom.c| 6 +- drivers/gpu/drm/radeon/atombios_crtc.c | 3 + drivers/gpu/drm/radeon/evergreen.c | 67 +++- drivers/gpu/drm/radeon/evergreen_reg.h | 2 + drivers/gpu/drm/radeon/ni.c | 8 +- drivers/gpu/drm/radeon/nid.h | 4 + drivers/gpu/drm/radeon/r300_cmdbuf.c | 2 +- drivers/gpu/drm/radeon/r600_hdmi.c | 4 +- drivers/gpu/drm/radeon/radeon_atombios.c | 21 +++-- drivers/gpu/drm/radeon/radeon_kms.c | 4 + drivers/gpu/drm/radeon/radeon_pm.c | 6 +- drivers/gpu/drm/radeon/si.c | 3 +- drivers/gpu/drm/radeon/sid.h | 2 + drivers/i2c/busses/i2c-xiic.c| 6 +- drivers/md/dm-snap.c | 1 + drivers/md/dm-thin.c | 2 +- drivers/mfd/adp5520.c| 8 +- drivers/mmc/core/mmc.c
