Re: [PATCH] rcu: Eliminate softirq processing from rcutree
On Wed, Dec 25, 2013 at 04:07:34AM +0100, Mike Galbraith wrote: > On Tue, 2013-12-24 at 11:36 -0800, Paul E. McKenney wrote: > > On Mon, Dec 23, 2013 at 05:38:53AM +0100, Mike Galbraith wrote: > > > On Sun, 2013-12-22 at 09:57 +0100, Mike Galbraith wrote: > > > > I'll let the box give > > > > RCU something to do for a couple days. No news is good news. > > > > > > Ho ho hum, merry christmas, gift attached. > > > > Hmmm... I guess I should take a moment to work out who has been > > naughty and nice... > > > > > I'll beat on virgin -rt7, see if it survives, then re-apply RCU patch > > > and retest. This kernel had nohz_full enabled, along with Sebastian's > > > pending -rt fix for same, so RCU patch was not only not running solo, > > > box was running a known somewhat buggy config as well. Box was doing > > > endless tbench 64 when it started stalling fwiw. > > > > [72788.040872] NMI backtrace for cpu 31 > > [72788.040874] CPU: 31 PID: 13975 Comm: tbench Tainted: GW > > 3.12.6-rt7-nohz #192 > > [72788.040874] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 > > 07/07/2010 > > [72788.040875] task: 8802728e3db0 ti: 88026deb2000 task.ti: > > 88026deb2000 > > [72788.040877] RIP: 0010:[] [] > > _raw_spin_trylock+0x14/0x80 > > [72788.040878] RSP: 0018:8802769e3e58 EFLAGS: 0002 > > [72788.040879] RAX: 88026deb3fd8 RBX: 880273544000 RCX: > > 7bc87bc6 > > [72788.040879] RDX: RSI: 8802728e3db0 RDI: > > 880273544000 > > [72788.040880] RBP: 88026deb39f8 R08: 063c14effd0f R09: > > 0119 > > [72788.040881] R10: 0005 R11: 8802769f2260 R12: > > 8802728e3db0 > > [72788.040881] R13: 001f R14: 8802769ebcc0 R15: > > 810c4730 > > [72788.040883] FS: 7f7cd380a700() GS:8802769e() > > knlGS: > > [72788.040883] CS: 0010 DS: ES: CR0: 80050033 > > [72788.040884] CR2: 0068a0e8 CR3: 000267ba4000 CR4: > > 07e0 > > [72788.040885] Stack: > > [72788.040886] 88026deb39f8 815e2aa0 > > 8106711a > > [72788.040887] 8802769ec4e0 8802769ec4e0 8802769e3f58 > > 810c44bd > > [72788.040888] 88026deb39f8 88026deb39f8 15ed4f5ff89b > > 810c476e > > [72788.040889] Call Trace: > > [72788.040889] > > [72788.040891] [] ? > > rt_spin_lock_slowunlock_hirq+0x10/0x20 > > [72788.040893] [] ? update_process_times+0x3a/0x60 > > [72788.040895] [] ? tick_sched_handle+0x2d/0x70 > > [72788.040896] [] ? tick_sched_timer+0x3e/0x70 > > [72788.040898] [] ? __run_hrtimer+0x13d/0x260 > > [72788.040900] [] ? hrtimer_interrupt+0x12c/0x310 > > [72788.040901] [] ? vtime_account_system+0x4e/0xf0 > > [72788.040903] [] ? smp_apic_timer_interrupt+0x36/0x50 > > [72788.040904] [] ? apic_timer_interrupt+0x6d/0x80 > > [72788.040905] > > [72788.040906] [] ? _raw_spin_lock+0x2a/0x40 > > [72788.040908] [] ? rt_spin_lock_slowlock+0x33/0x2d0 > > [72788.040910] [] ? migrate_enable+0xc4/0x220 > > [72788.040911] [] ? ip_finish_output+0x258/0x450 > > [72788.040913] [] ? lock_timer_base+0x41/0x80 > > [72788.040914] [] ? mod_timer+0x66/0x290 > > [72788.040916] [] ? sk_reset_timer+0xf/0x20 > > [72788.040917] [] ? tcp_write_xmit+0x1cf/0x5d0 > > [72788.040919] [] ? __tcp_push_pending_frames+0x25/0x60 > > [72788.040921] [] ? tcp_sendmsg+0x114/0xbb0 > > [72788.040923] [] ? sock_sendmsg+0xaf/0xf0 > > [72788.040925] [] ? touch_atime+0x65/0x150 > > [72788.040927] [] ? SyS_sendto+0x118/0x190 > > [72788.040929] [] ? vtime_account_user+0x66/0x100 > > [72788.040930] [] ? syscall_trace_enter+0x2a/0x260 > > [72788.040932] [] ? tracesys+0xdd/0xe2 > > > > The most likely suspect is the rt_spin_lock_slowlock() that is apparently > > being acquired by migrate_enable(). This could be due to: > > > > 1. Massive contention on that lock. > > > > 2. Someone else holding that lock for excessive time periods. > > Evidence in favor: CPU 0 appears to be running within > > migrate_enable(). But isn't migrate_enable() really quite > > lightweight? > > > > 3. Possible looping in the networking stack -- but this seems > > unlikely given that we appear to have caught a lock acquisition > > in the act. (Not impossible, however, if there are lots of > > migrate_enable() calls in the networking stack, which there > > are due to all the per-CPU work.) > > > > So which code do you think deserves the big lump of coal? ;-) > > Sebastian's NO_HZ_FULL locking fixes. Locking is hard, and rt sure > doesn't make it any easier, so lets give him a cookie or three to nibble > on while he ponders that trylock stuff again instead :) Fair enough. Does Sebastian prefer milk and cookies or the other tradition of beer and a cigar? ;-) Thanx, Paul -- To unsubscribe from this list: send the
Re: tg3 and sd card reader at acer aspire
2013/12/25 Robert Hancock : > So apparently this machine got broken when we changed the behavior for the > ACPI ASPM-not-supported bit from forcing ASPM off for everything to leaving > ASPM in whatever state the BIOS left it in. And apparently for some reason > the device (devices?) doesn't work with ASPM enabled in Linux but does in > Windows. It's possible that some other workaround is being applied by the > Windows driver that allows it to work there. > > I'm not too sure what the next step to debug that would be, unless maybe > someone has a contact at Broadcom. We could conceivably add a quirk to force > ASPM off for this device regardless of what the BIOS says, though. Thanks! I can contact with broadcom, but i don't known email address. Last my attempt then i have problems with their wifi card not successful =(. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tg3 and sd card reader at acer aspire
2013/12/24 Bjorn Helgaas : > [+cc linux-pci because I think this is related to PCI ASPM] > > I'm afraid nobody wants to touch ASPM because it's such a mess, but I > hope somebody will step up and investigate this. Thank you! -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tg3 and sd card reader at acer aspire
On 12/24/2013 11:52 AM, Bjorn Helgaas wrote: [+cc linux-pci because I think this is related to PCI ASPM] I'm afraid nobody wants to touch ASPM because it's such a mess, but I hope somebody will step up and investigate this. So apparently this machine got broken when we changed the behavior for the ACPI ASPM-not-supported bit from forcing ASPM off for everything to leaving ASPM in whatever state the BIOS left it in. And apparently for some reason the device (devices?) doesn't work with ASPM enabled in Linux but does in Windows. It's possible that some other workaround is being applied by the Windows driver that allows it to work there. I'm not too sure what the next step to debug that would be, unless maybe someone has a contact at Broadcom. We could conceivably add a quirk to force ASPM off for this device regardless of what the BIOS says, though. On Tue, Dec 24, 2013 at 1:27 AM, Vasiliy Tolstov wrote: Hi all and sorry for may be spamming mailing list. I have acer aspire v5-17 with broadcom card reader and ethernet card. I'm affecting on this ubuntu bugs. But bug is present in vanilla linux current git and stable lts. Can somebody helps me and say - where i can post message and discuss this problem. As i see ubuntu team can't solve this problem (bug present is about 1 year and nothing changed). One ubuntu user wia bisecting find broken commit - https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6cac12dfab9c57a4f76821412224b226a9b08dff Relevant ubuntu bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178131 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1067222 Thanks! -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUGREPORT] Linux USB 3.0
A customer using a device with USBDEVFS is reporting following backtrace (it seems to be a rather generic issue related to linux usb 3.0 in general): According to him this problem is reproducible as soon as he starts the data transfer, is there anything known about that? He is using 3.12.0-031200-generic Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: last message repeated 16 times Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: URB transfer length is wrong, xHC issue? req. len = 46080, act. len = 1382400 Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle kernel NULL pointer dereference at 0004 Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] Oops: [#1] SMP Dec 24 14:30:39 homenas kernel: [ 1469.822450] Modules linked in: videodev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) dm_crypt snd_hda_codec_ca0132 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi dm_multipath psmouse scsi_dh snd_rawmidi serio_raw sb_edac snd_seq_midi_event edac_core snd_seq snd_timer snd_seq_device lpc_ich snd bnep rfcomm soundcore snd_page_alloc bluetooth mei_me mei mac_hid ppdev nfsd w83627ehf hwmon_vid nfs_acl auth_rpcgss coretemp nfs fscache lockd lp parport sunrpc raid10 raid456 async_pq async_xor async_memcpy async_raid6_recov async_tx raid0 multipath linear btrfs raid6_pq xor libcrc32c osst st raid1 tg3 mptsas firewire_ohci ptp mxm_wmi firewire_core ahci mptscsih pps_core crc_itu_t libahci mpt2sas mptbase wmi scsi_transport_sas raid_class [last unloaded: vmnet] Dec 24 14:30:39 homenas kernel: [ 1469.822450] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GF O 3.12.0-031200-generic #201311031935 Dec 24 14:30:39 homenas kernel: [ 1469.822450] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme9, BIOS P3.30 01/28/2013 Dec 24 14:30:39 homenas kernel: [ 1469.822450] task: 81c144a0 ti: 81c0 task.ti: 81c0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] RIP: 0010:[] [] finish_td+0x13f/0x250 Dec 24 14:30:39 homenas kernel: [ 1469.822450] RSP: 0018:88102fc03ca8 EFLAGS: 00010046 Dec 24 14:30:39 homenas kernel: [ 1469.822450] RAX: 880f865d2b10 RBX: 880f865d2b00 RCX: 0006 Dec 24 14:30:39 homenas kernel: [ 1469.822450] RDX: 880f865d2b10 RSI: 0007 RDI: 0046 Dec 24 14:30:39 homenas kernel: [ 1469.822450] RBP: 88102fc03d08 R08: 000a R09: Dec 24 14:30:39 homenas kernel: [ 1469.822450] R10: 06fd R11: 06fc R12: 880fd2de Dec 24 14:30:39 homenas kernel: [ 1469.822450] R13: 880fd32b1780 R14: R15: 880fd5c5f000 Dec 24 14:30:39 homenas kernel: [ 1469.822450] FS: () GS:88102fc0() knlGS: Dec 24 14:30:39 homenas kernel: [ 1469.822450] CS: 0010 DS: ES: CR0: 80050033 Dec 24 14:30:39 homenas kernel: [ 1469.822450] CR2: 0004 CR3: 01c0d000 CR4: 000407f0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] Stack: Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03ce8 880fd0bc8000 88102fc03d00 880fd268d1a0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03df4 00010002 880fd32b1780 880f865d2b00 Dec 24 14:30:39 homenas kernel: [ 1469.822450] 880fd268d1a0 880fd5c5f000 880fd2de 880fd2c497b0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] Call Trace: Dec 24 14:30:39 homenas kernel: [ 1469.822450] Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] process_bulk_intr_td+0x116/0x2d0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] handle_tx_event+0x656/0xb50 Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] ? __queue_work+0x3b0/0x3c0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] ? call_timer_fn+0x46/0x160 Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] xhci_handle_event+0x1db/0x2a0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] ? run_timer_softirq+0x1b2/0x300 Dec 24 14:30:39 homenas kernel: [ 1470.312076] [] xhci_irq+0x120/0x1f0 Dec 24 14:30:39 homenas kernel: [ 1470.312076] [] xhci_msi_irq+0x11/0x20 Dec 24 14:30:39 homenas kernel: [ 1470.312076] [] handle_irq_event_percpu+0x5d/0x210 Dec 24 14:30:39 homenas kernel: [ 1470.312076] [] handle_irq_event+0x48/0x70 Dec 24 14:30:39 homenas kernel: [
[PATCH v3 15/19] cw1200: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Solomon Peachy
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/cw1200/sta.c | 5 +++--
drivers/net/wireless/cw1200/txrx.c | 3 +--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/cw1200/sta.c
b/drivers/net/wireless/cw1200/sta.c
index 010b252..103f7bc 100644
--- a/drivers/net/wireless/cw1200/sta.c
+++ b/drivers/net/wireless/cw1200/sta.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "cw1200.h"
#include "sta.h"
@@ -555,8 +556,8 @@ u64 cw1200_prepare_multicast(struct ieee80211_hw *hw,
pr_debug("[STA] multicast: %pM\n", ha->addr);
memcpy(>multicast_filter.macaddrs[count],
ha->addr, ETH_ALEN);
- if (memcmp(ha->addr, broadcast_ipv4, ETH_ALEN) &&
- memcmp(ha->addr, broadcast_ipv6, ETH_ALEN))
+ if (!ether_addr_equal(ha->addr, broadcast_ipv4) &&
+ !ether_addr_equal(ha->addr, broadcast_ipv6))
priv->has_multicast_subscription = true;
count++;
}
diff --git a/drivers/net/wireless/cw1200/txrx.c
b/drivers/net/wireless/cw1200/txrx.c
index e824d4d..0bd5411 100644
--- a/drivers/net/wireless/cw1200/txrx.c
+++ b/drivers/net/wireless/cw1200/txrx.c
@@ -1166,8 +1166,7 @@ void cw1200_rx_cb(struct cw1200_common *priv,
return;
} else if (ieee80211_is_beacon(frame->frame_control) &&
!arg->status && priv->vif &&
- !memcmp(ieee80211_get_SA(frame), priv->vif->bss_conf.bssid,
- ETH_ALEN)) {
+ ether_addr_equal(ieee80211_get_SA(frame),
priv->vif->bss_conf.bssid)) {
const u8 *tim_ie;
u8 *ies = ((struct ieee80211_mgmt *)
(skb->data))->u.beacon.variable;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 14/19] hostap: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Jouni Malinen
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/hostap/hostap_80211_tx.c | 4 ++--
drivers/net/wireless/hostap/hostap_ap.c | 28 +--
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
drivers/net/wireless/hostap/hostap_ioctl.c| 4 ++--
drivers/net/wireless/hostap/hostap_main.c | 8 +++-
5 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_80211_tx.c
b/drivers/net/wireless/hostap/hostap_80211_tx.c
index 344a981..8bde776 100644
--- a/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ b/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -1,5 +1,6 @@
#include
#include
+#include
#include "hostap_80211.h"
#include "hostap_common.h"
@@ -103,8 +104,7 @@ netdev_tx_t hostap_data_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
} else if (local->iw_mode == IW_MODE_INFRA &&
(local->wds_type & HOSTAP_WDS_AP_CLIENT) &&
- memcmp(skb->data + ETH_ALEN, dev->dev_addr,
- ETH_ALEN) != 0) {
+ !ether_addr_equal(skb->data + ETH_ALEN,
dev->dev_addr)) {
/* AP client mode: send frames with foreign src addr
* using 4-addr WDS frames */
use_wds = WDS_COMPLIANT_FRAME;
diff --git a/drivers/net/wireless/hostap/hostap_ap.c
b/drivers/net/wireless/hostap/hostap_ap.c
index d6033a8..d36e252 100644
--- a/drivers/net/wireless/hostap/hostap_ap.c
+++ b/drivers/net/wireless/hostap/hostap_ap.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "hostap_wlan.h"
#include "hostap.h"
@@ -106,13 +107,12 @@ static void ap_sta_hash_del(struct ap_data *ap, struct
sta_info *sta)
s = ap->sta_hash[STA_HASH(sta->addr)];
if (s == NULL) return;
- if (memcmp(s->addr, sta->addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(s->addr, sta->addr)) {
ap->sta_hash[STA_HASH(sta->addr)] = s->hnext;
return;
}
- while (s->hnext != NULL && memcmp(s->hnext->addr, sta->addr, ETH_ALEN)
- != 0)
+ while (s->hnext != NULL && !ether_addr_equal(s->hnext->addr, sta->addr))
s = s->hnext;
if (s->hnext != NULL)
s->hnext = s->hnext->hnext;
@@ -435,7 +435,7 @@ int ap_control_del_mac(struct mac_restrictions
*mac_restrictions, u8 *mac)
ptr != _restrictions->mac_list; ptr = ptr->next) {
entry = list_entry(ptr, struct mac_entry, list);
- if (memcmp(entry->addr, mac, ETH_ALEN) == 0) {
+ if (ether_addr_equal(entry->addr, mac)) {
list_del(ptr);
kfree(entry);
mac_restrictions->entries--;
@@ -459,7 +459,7 @@ static int ap_control_mac_deny(struct mac_restrictions
*mac_restrictions,
spin_lock_bh(_restrictions->lock);
list_for_each_entry(entry, _restrictions->mac_list, list) {
- if (memcmp(entry->addr, mac, ETH_ALEN) == 0) {
+ if (ether_addr_equal(entry->addr, mac)) {
found = 1;
break;
}
@@ -957,7 +957,7 @@ static struct sta_info* ap_get_sta(struct ap_data *ap, u8
*sta)
struct sta_info *s;
s = ap->sta_hash[STA_HASH(sta)];
- while (s != NULL && memcmp(s->addr, sta, ETH_ALEN) != 0)
+ while (s != NULL && !ether_addr_equal(s->addr, sta))
s = s->hnext;
return s;
}
@@ -1391,7 +1391,7 @@ static void handle_authen(local_info_t *local, struct
sk_buff *skb,
status_code = __le16_to_cpu(*pos);
pos++;
- if (memcmp(dev->dev_addr, hdr->addr2, ETH_ALEN) == 0 ||
+ if (ether_addr_equal(dev->dev_addr, hdr->addr2) ||
ap_control_mac_deny(>mac_restrictions, hdr->addr2)) {
txt = "authentication denied";
resp = WLAN_STATUS_UNSPECIFIED_FAILURE;
@@ -1935,7 +1935,7 @@ static void handle_pspoll(local_info_t *local,
PDEBUG(DEBUG_PS2, "handle_pspoll: BSSID=%pM, TA=%pM PWRMGT=%d\n",
hdr->addr1, hdr->addr2, !!ieee80211_has_pm(hdr->frame_control));
- if (memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN)) {
+ if (!ether_addr_equal(hdr->addr1, dev->dev_addr)) {
PDEBUG(DEBUG_AP,
"handle_pspoll - addr1(BSSID)=%pM not own MAC\n",
hdr->addr1);
@@ -2230,7 +2230,7 @@ static void handle_ap_item(local_info_t *local, struct
sk_buff *skb,
goto done;
}
- if (memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN)) {
+
Re: [sched] perf-stat.cpu-migrations changes in dd write test
On 12/25/2013 11:56 AM, Fengguang Wu wrote: > On Wed, Dec 25, 2013 at 11:30:27AM +0800, Alex Shi wrote: >> On 12/23/2013 01:24 PM, Fengguang Wu wrote: >>> On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote: On 12/22/2013 08:30 AM, fengguang...@intel.com wrote: > Alex, > > We noticed some perf-stat.cpu-migrations changes by your commit Thanks for your wonder testing, Fengguang! How many CPU in your system and how many dd task running? >>> >>> For the case >>> >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd >>> >>> It's a KVM with 4 CPUs, 16G memory. There are 4 virtual disks, on top >>> of each disk there runs 10 dd tasks. >> >> I don't know much of kvm. Where the data get from, VM guest or VM host? > > The data are collected in the VM guest. do you have similar testing on native linux? > > Thanks, > Fengguang > >> Looks like any guest cpu usage will be counted as user usage in vmstat. >> and Does the CS and cpu migration reducing cause dd performance increase? >>> >>> Thanks, >>> Fengguang >>> > > 6eb8b571283e64e96ca1a91aad085f9e08f857f0 is the first bad commit > commit 6eb8b571283e64e96ca1a91aad085f9e08f857f0 > Author: Alex Shi > Date: Tue Nov 19 20:29:51 2013 +0800 > > sched: remove rq->cpu_load[load_idx] array > > Since load_idx effect removed in load balance, we don't need the > load_idx decays in scheduler. that will save some process in > sched_tick > and others places. > > Signed-off-by: Alex Shi > > > Here are the changed stats comparing to its parent commit: > > 1de157d718f6494 6eb8b571283e64e96ca1 > --- - > 37779 ~40%+115.2% 81288 ~50% > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > 37779 +115.2% 81288 TOTAL > proc-vmstat.pgscan_direct_normal > > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: > proc-vmstat.pgscan_direct_normal > >16 > +++ > | > | >14 ++ > O > | > | >12 ++ > | > |O > | >10 ++ > | > | > | > 8 ++ O > | > | > ..* > 6 ++ > | > | > | > 4 *+... O > | > O*... *. > | > 2 > ++---*+ > > > 1de157d718f6494 6eb8b571283e64e96ca1 > --- - > 121579 ~ 6% -50.8% 59852 ~13% > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > 121579 -50.8% 59852 TOTAL softirqs.SCHED > > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: softirqs.SCHED > >14 > +++ >13 ++ *... *... > | > | > .. | >12 *+...* > ..| >11 ++ > * > | > | >10 ++ > | > 9 ++ > | > 8 ++ > | > | > | > 7 ++ OO > | > 6 ++ O > | > | > O >
[PATCH v3 6/6] fat: update the limitation for fat fallocate
From: Namjae Jeon update the limitation for fat fallocate. Signed-off-by: Namjae Jeon Signed-off-by: Amit Sahrawat --- Documentation/filesystems/vfat.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 4a93e98..5cf57b3 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -175,6 +175,16 @@ nfs=stale_rw|nostale_ro : 0,1,yes,no,true,false +LIMITATION +- +* The fallocated region of file is discarded at umount/evict time + when using fallocate with FALLOC_FL_KEEP_SIZE. + So, User should assume that fallocated region can be discarded at + last close if there is memory pressure resulting in eviction of + the inode from the memory. As a result, for any dependency on + the fallocated region, user should make sure to recheck fallocate + after reopening the file. + TODO -- * Need to get rid of the raw scanning stuff. Instead, always use -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/6] fat: add i_disksize to represent uninitialized size
From: Namjae Jeon
Add i_disksize to represent uninitialized allocated size.
And mmu_private represent initialized allocated size.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/fat/cache.c |6 +++---
fs/fat/fat.h |3 ++-
fs/fat/file.c |4 +++-
fs/fat/inode.c |4
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/fat/cache.c b/fs/fat/cache.c
index 91ad9e1..a132666 100644
--- a/fs/fat/cache.c
+++ b/fs/fat/cache.c
@@ -329,10 +329,10 @@ int fat_bmap(struct inode *inode, sector_t sector,
sector_t *phys,
return 0;
/*
-* ->mmu_private can access on only allocation path.
-* (caller must hold ->i_mutex)
+* Both ->mmu_private and ->i_disksize can access
+* on only allocation path. (caller must hold ->i_mutex)
*/
- last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
+ last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>> blocksize_bits;
if (sector >= last_block)
return 0;
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 7c31f4b..7b5851f 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -118,7 +118,8 @@ struct msdos_inode_info {
unsigned int cache_valid_id;
/* NOTE: mmu_private is 64bits, so must hold ->i_mutex to access */
- loff_t mmu_private; /* physically allocated size */
+ loff_t mmu_private; /* physically allocated size (initialized) */
+ loff_t i_disksize; /* physically allocated size (uninitialized) */
int i_start;/* first cluster or 0 */
int i_logstart; /* logical first cluster */
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 9b104f5..0bf0d28 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -300,8 +300,10 @@ void fat_truncate_blocks(struct inode *inode, loff_t
offset)
* This protects against truncating a file bigger than it was then
* trying to write into the hole.
*/
- if (MSDOS_I(inode)->mmu_private > offset)
+ if (MSDOS_I(inode)->i_disksize > offset) {
MSDOS_I(inode)->mmu_private = offset;
+ MSDOS_I(inode)->i_disksize = offset;
+ }
nr_clusters = (offset + (cluster_size - 1)) >> sbi->cluster_bits;
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 854b578..7e5531a 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -93,6 +93,7 @@ static inline int __fat_get_block(struct inode *inode,
sector_t iblock,
*max_blocks = min(mapped_blocks, *max_blocks);
MSDOS_I(inode)->mmu_private += *max_blocks << sb->s_blocksize_bits;
+ MSDOS_I(inode)->i_disksize = MSDOS_I(inode)->mmu_private;
err = fat_bmap(inode, iblock, , _blocks, create);
if (err)
@@ -408,6 +409,7 @@ int fat_fill_inode(struct inode *inode, struct
msdos_dir_entry *de)
if (error < 0)
return error;
MSDOS_I(inode)->mmu_private = inode->i_size;
+ MSDOS_I(inode)->i_disksize = inode->i_size;
set_nlink(inode, fat_subdirs(inode));
} else { /* not a directory */
@@ -423,6 +425,7 @@ int fat_fill_inode(struct inode *inode, struct
msdos_dir_entry *de)
inode->i_fop = _file_operations;
inode->i_mapping->a_ops = _aops;
MSDOS_I(inode)->mmu_private = inode->i_size;
+ MSDOS_I(inode)->i_disksize = inode->i_size;
}
if (de->attr & ATTR_SYS) {
if (sbi->options.sys_immutable)
@@ -1223,6 +1226,7 @@ static int fat_read_root(struct inode *inode)
& ~((loff_t)sbi->cluster_size - 1)) >> 9;
MSDOS_I(inode)->i_logstart = 0;
MSDOS_I(inode)->mmu_private = inode->i_size;
+ MSDOS_I(inode)->i_disksize = inode->i_size;
fat_save_attrs(inode, ATTR_DIR);
inode->i_mtime.tv_sec = inode->i_atime.tv_sec = inode->i_ctime.tv_sec =
0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/6] fat: fallback to buffered write in case of fallocated region on direct IO
From: Namjae Jeon For normal cases of direct IO write, trying to seek to location greater than file size, makes it fall back to buffered write to fill that region. Similarly, in case for write in Fallocated region, make it fall to buffered write. Signed-off-by: Namjae Jeon Signed-off-by: Amit Sahrawat --- fs/fat/inode.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/fs/fat/inode.c b/fs/fat/inode.c index 8415807..3636617 100644 --- a/fs/fat/inode.c +++ b/fs/fat/inode.c @@ -229,6 +229,13 @@ static ssize_t fat_direct_IO(int rw, struct kiocb *iocb, loff_t size = offset + iov_length(iov, nr_segs); if (MSDOS_I(inode)->mmu_private < size) return 0; + + /* +* In case of writing in fallocated region, return 0 and +* fallback to buffered write. +*/ + if (MSDOS_I(inode)->i_disksize > MSDOS_I(inode)->mmu_private) + return 0; } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/6] fat: permit to return phy block number by fibmap in fallocated region
From: Namjae Jeon
Make the fibmap call the return the proper physical block number for any
offset request in the fallocated range.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/fat/cache.c | 13 ++---
fs/fat/fat.h |3 +++
fs/fat/inode.c |3 +++
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/fat/cache.c b/fs/fat/cache.c
index a132666..d22c1a2 100644
--- a/fs/fat/cache.c
+++ b/fs/fat/cache.c
@@ -325,19 +325,26 @@ int fat_bmap(struct inode *inode, sector_t sector,
sector_t *phys,
last_block = (i_size_read(inode) + (blocksize - 1)) >> blocksize_bits;
if (sector >= last_block) {
- if (!create)
- return 0;
-
/*
* Both ->mmu_private and ->i_disksize can access
* on only allocation path. (caller must hold ->i_mutex)
*/
last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>> blocksize_bits;
+ if (!create) {
+ /* Map a block in fallocated region */
+ if (atomic_read(_I(inode)->beyond_isize))
+ if (sector < last_block)
+ goto out_map_cluster;
+
+ return 0;
+ }
+
if (sector >= last_block)
return 0;
}
+out_map_cluster:
cluster = sector >> (sbi->cluster_bits - sb->s_blocksize_bits);
offset = sector & (sbi->sec_per_clus - 1);
cluster = fat_bmap_cluster(inode, cluster);
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 7b5851f..b884276 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -129,6 +129,9 @@ struct msdos_inode_info {
struct hlist_node i_dir_hash; /* hash by i_logstart */
struct rw_semaphore truncate_lock; /* protect bmap against truncate */
struct inode vfs_inode;
+
+ /* for getting block number beyond file size in case of fallocate */
+ atomic_t beyond_isize;
};
struct fat_slot_info {
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3636617..1c3192b 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -256,7 +256,10 @@ static sector_t _fat_bmap(struct address_space *mapping,
sector_t block)
/* fat_get_cluster() assumes the requested blocknr isn't truncated. */
down_read(_I(mapping->host)->truncate_lock);
+ /* To get block number beyond file size in fallocated region */
+ atomic_set(_I(mapping->host)->beyond_isize, 1);
blocknr = generic_block_bmap(mapping, block, fat_get_block);
+ atomic_set(_I(mapping->host)->beyond_isize, 0);
up_read(_I(mapping->host)->truncate_lock);
return blocknr;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/6] fat: zero out seek range on _fat_get_block
From: Namjae Jeon
For normal buffered write operations, normally if we try to write to an
offset > than file size, it does a cont_expand_zero till that offset.
Now, in case of fallocated regions, since the blocks are already allocated.
So, make it zero out that buffers for those blocks till the seek'ed offset.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/fat/inode.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 2674c57..8415807 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -54,6 +54,25 @@ static int fat_add_cluster(struct inode *inode)
return err;
}
+static void check_fallocated_region(struct inode *inode, sector_t iblock,
+ unsigned long *max_blocks, struct buffer_head *bh_result)
+{
+ struct super_block *sb = inode->i_sb;
+ sector_t last_block, disk_block;
+ const unsigned long blocksize = sb->s_blocksize;
+ const unsigned char blocksize_bits = sb->s_blocksize_bits;
+
+ last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
+ >> blocksize_bits;
+ disk_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
+ >> blocksize_bits;
+ if (iblock >= last_block && iblock <= disk_block) {
+ MSDOS_I(inode)->mmu_private += *max_blocks << blocksize_bits;
+ set_buffer_new(bh_result);
+ }
+
+}
+
static inline int __fat_get_block(struct inode *inode, sector_t iblock,
unsigned long *max_blocks,
struct buffer_head *bh_result, int create)
@@ -68,8 +87,11 @@ static inline int __fat_get_block(struct inode *inode,
sector_t iblock,
if (err)
return err;
if (phys) {
- map_bh(bh_result, sb, phys);
*max_blocks = min(mapped_blocks, *max_blocks);
+ if (create)
+ check_fallocated_region(inode, iblock, max_blocks,
+ bh_result);
+ map_bh(bh_result, sb, phys);
return 0;
}
if (!create)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/6] fat: additions to support fat_fallocate
From: Namjae Jeon This patch set provides support for doing fallocate operation on FAT filesystem. After series of review for the the feature The complete functionality is broken down into smaller subsets. v3: - fix i_disksize and mmu_private comments(uninit/initialized) - remove unneeded condition in fat_bmap. - use mmu_private instead of fclus in fat_fallocate. - make function mark buffer new for block in fallocated region. - use flags for bmap. - use mmu_private instead of i_size in direct_IO. - use flags and remove i_mutex in bmap. - update vfat documentation. v2: - remove a stary unlock(from Dan Carpenter) - check ->mmu_private and ->i_disksize to truncate uninitialized data. Namjae Jeon (6): fat: add i_disksize to represent uninitialized size fat: add fat_fallocate operation fat: zero out seek range on _fat_get_block fat: fallback to buffered write in case of fallocatded region on direct IO fat: permit to return phy block number by fibmap in fallocated region fat: update the limitation for fat fallocate -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/6] fat: add fat_fallocate operation
From: Namjae Jeon
Implement preallocation via the fallocate syscall on VFAT partitions.
This patch is based on an earlier patch of the same name which had some
issues detailed below and did not get accepted.
Refer https://lkml.org/lkml/2007/12/22/130.
a) The preallocated space was not persistent when the
FALLOC_FL_KEEP_SIZE flag was set. It will deallocate cluster at evict time.
b) There was no need to zero out the clusters when the flag was set
Instead of doing an expanding truncate, just allocate clusters and add
them to the fat chain. This reduces preallocation time.
Compatibility with windows:
There are no issues when FALLOC_FL_KEEP_SIZE is not set
because it just does an expanding truncate. Thus reading from the
preallocated area on windows returns null until data is written to it.
When a file with preallocated area using the FALLOC_FL_KEEP_SIZE was
written to on windows, the windows driver freed-up the preallocated
clusters and allocated new clusters for the new data. The freed up
clusters gets reflected in the free space available for the partition
which can be seen from the Volume properties.
The windows chkdsk tool also does not report any errors on a
disk containing files with preallocated space.
And there is also no issue using linux fat fsck.
because discard preallocated clusters at repair time.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/fat/file.c | 74
fs/fat/inode.c | 19 +++
2 files changed, 93 insertions(+)
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 0bf0d28..79db8b6 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -17,8 +17,12 @@
#include
#include
#include
+#include
#include "fat.h"
+static long fat_fallocate(struct file *file, int mode,
+ loff_t offset, loff_t len);
+
static int fat_ioctl_get_attributes(struct inode *inode, u32 __user *user_attr)
{
u32 attr;
@@ -182,6 +186,7 @@ const struct file_operations fat_file_operations = {
#endif
.fsync = fat_file_fsync,
.splice_read= generic_file_splice_read,
+ .fallocate = fat_fallocate,
};
static int fat_cont_expand(struct inode *inode, loff_t size)
@@ -220,6 +225,75 @@ out:
return err;
}
+/*
+ * Preallocate space for a file. This implements fat's fallocate file
+ * operation, which gets called from sys_fallocate system call. User
+ * space requests len bytes at offset. If FALLOC_FL_KEEP_SIZE is set
+ * we just allocate clusters without zeroing them out. Otherwise we
+ * allocate and zero out clusters via an expanding truncate.
+ */
+static long fat_fallocate(struct file *file, int mode,
+ loff_t offset, loff_t len)
+{
+ int cluster;
+ int nr_cluster; /* Number of clusters to be allocated */
+ loff_t mm_bytes; /* Number of bytes to be allocated for file */
+ struct inode *inode = file->f_mapping->host;
+ struct super_block *sb = inode->i_sb;
+ struct msdos_sb_info *sbi = MSDOS_SB(sb);
+ int err = 0;
+
+ /* No support for hole punch or other fallocate flags. */
+ if (mode & ~FALLOC_FL_KEEP_SIZE)
+ return -EOPNOTSUPP;
+
+ /* No support for dir */
+ if (!S_ISREG(inode->i_mode))
+ return -EOPNOTSUPP;
+
+ mutex_lock(>i_mutex);
+ if ((offset + len) <= MSDOS_I(inode)->i_disksize)
+ goto error;
+
+ err = inode_newsize_ok(inode, (len + offset));
+ if (err)
+ goto error;
+
+ if (mode & FALLOC_FL_KEEP_SIZE) {
+ /* First compute the number of clusters to be allocated */
+ mm_bytes = offset + len - round_up(MSDOS_I(inode)->mmu_private,
+ sbi->cluster_size);
+ nr_cluster = (mm_bytes + (sbi->cluster_size - 1)) >>
+ sbi->cluster_bits;
+
+ /* Start the allocation.We are not zeroing out the clusters */
+ while (nr_cluster-- > 0) {
+ err = fat_alloc_clusters(inode, , 1);
+ if (err) {
+ fat_msg(sb, KERN_ERR,
+ "fat_fallocate(): fat_alloc_clusters()
error");
+ goto error;
+ }
+ err = fat_chain_add(inode, cluster, 1);
+ if (err) {
+ fat_free_clusters(inode, cluster);
+ goto error;
+ }
+ MSDOS_I(inode)->i_disksize += sbi->cluster_size;
+ }
+ } else {
+ /* This is just an expanding truncate */
+ err = fat_cont_expand(inode, (offset + len));
+ if (err)
+ fat_msg(sb, KERN_ERR,
+ "fat_fallocate(): fat_cont_expand() error");
+ }
+
+error:
+
[PATCH v3 10/19] mac8011: slight optimization of addr compare
Use the possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Johannes Berg
Cc: John W. Linville
Cc: David Miller
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Wang Weidong
Signed-off-by: Ding Tianhong
---
net/mac80211/iface.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 7aa9f9d..a4f9812 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1497,8 +1497,8 @@ static void ieee80211_assign_perm_addr(struct
ieee80211_local *local,
bool used = false;
list_for_each_entry(sdata, >interfaces, list) {
- if (memcmp(local->hw.wiphy->addresses[i].addr,
- sdata->vif.addr, ETH_ALEN) == 0) {
+ if
(ether_addr_equal(local->hw.wiphy->addresses[i].addr,
+sdata->vif.addr)) {
used = true;
break;
}
@@ -1558,8 +1558,7 @@ static void ieee80211_assign_perm_addr(struct
ieee80211_local *local,
val += inc;
list_for_each_entry(sdata, >interfaces, list) {
- if (memcmp(tmp_addr, sdata->vif.addr,
- ETH_ALEN) == 0) {
+ if (ether_addr_equal(tmp_addr,
sdata->vif.addr)) {
used = true;
break;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] audit: correct a type mismatch in audit_syscall_exit()
audit_syscall_exit() saves a result of regs_return_value() in intermediate
"int" variable and passes it to __audit_syscall_exit(), which expects its
second argument as a "long" value.
This will result in truncating the value returned by a system call and
making a wrong audit record.
I don't know why gcc compiler doesn't complain about this, but anyway it
causes a problem at runtime on arm64 (and probably most 64-bit archs).
Signed-off-by: AKASHI Takahiro
---
include/linux/audit.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index c49a312..3dcb3f0 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -144,7 +144,7 @@ static inline void audit_syscall_exit(void *pt_regs)
{
if (unlikely(current->audit_context)) {
int success = is_syscall_success(pt_regs);
- int return_code = regs_return_value(pt_regs);
+ long return_code = regs_return_value(pt_regs);
__audit_syscall_exit(success, return_code);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 16/19] ipw2x00: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Stanislav Yakovlev
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/ipw2x00/ipw2200.c | 34
drivers/net/wireless/ipw2x00/libipw_rx.c | 10 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c
b/drivers/net/wireless/ipw2x00/ipw2200.c
index 9244b36..1393260 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -3012,7 +3012,7 @@ static void ipw_remove_current_network(struct ipw_priv
*priv)
spin_lock_irqsave(>ieee->lock, flags);
list_for_each_safe(element, safe, >ieee->network_list) {
network = list_entry(element, struct libipw_network, list);
- if (!memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+ if (ether_addr_equal(network->bssid, priv->bssid)) {
list_del(element);
list_add_tail(>list,
>ieee->network_free_list);
@@ -3921,7 +3921,7 @@ static u8 ipw_add_station(struct ipw_priv *priv, u8 *
bssid)
int i;
for (i = 0; i < priv->num_stations; i++) {
- if (!memcmp(priv->stations[i], bssid, ETH_ALEN)) {
+ if (ether_addr_equal(priv->stations[i], bssid)) {
/* Another node is active in network */
priv->missed_adhoc_beacons = 0;
if (!(priv->config & CFG_STATIC_CHANNEL))
@@ -3953,7 +3953,7 @@ static u8 ipw_find_station(struct ipw_priv *priv, u8 *
bssid)
int i;
for (i = 0; i < priv->num_stations; i++)
- if (!memcmp(priv->stations[i], bssid, ETH_ALEN))
+ if (ether_addr_equal(priv->stations[i], bssid))
return i;
return IPW_INVALID_STATION;
@@ -5622,7 +5622,7 @@ static int ipw_find_adhoc_network(struct ipw_priv *priv,
return 0;
}
- if (!memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+ if (ether_addr_equal(network->bssid, priv->bssid)) {
IPW_DEBUG_MERGE("Network '%s (%pM)' excluded "
"because of the same BSSID match: %pM"
".\n", print_ssid(ssid, network->ssid,
@@ -5849,7 +5849,7 @@ static int ipw_best_network(struct ipw_priv *priv,
}
if ((priv->config & CFG_STATIC_BSSID) &&
- memcmp(network->bssid, priv->bssid, ETH_ALEN)) {
+ !ether_addr_equal(network->bssid, priv->bssid)) {
IPW_DEBUG_ASSOC("Network '%s (%pM)' excluded "
"because of BSSID mismatch: %pM.\n",
print_ssid(ssid, network->ssid,
@@ -6988,7 +6988,7 @@ static int ipw_qos_handle_probe_response(struct ipw_priv
*priv,
}
if ((priv->status & STATUS_ASSOCIATED) &&
(priv->ieee->iw_mode == IW_MODE_ADHOC) && (active_network == 0)) {
- if (memcmp(network->bssid, priv->bssid, ETH_ALEN))
+ if (!ether_addr_equal(network->bssid, priv->bssid))
if (network->capability & WLAN_CAPABILITY_IBSS)
if ((network->ssid_len ==
priv->assoc_network->ssid_len) &&
@@ -8210,29 +8210,29 @@ static int is_network_packet(struct ipw_priv *priv,
switch (priv->ieee->iw_mode) {
case IW_MODE_ADHOC: /* Header: Dest. | Source| BSSID */
/* packets from our adapter are dropped (echo) */
- if (!memcmp(header->addr2, priv->net_dev->dev_addr, ETH_ALEN))
+ if (ether_addr_equal(header->addr2, priv->net_dev->dev_addr))
return 0;
/* {broad,multi}cast packets to our BSSID go through */
if (is_multicast_ether_addr(header->addr1))
- return !memcmp(header->addr3, priv->bssid, ETH_ALEN);
+ return ether_addr_equal(header->addr3, priv->bssid);
/* packets to our adapter go through */
- return !memcmp(header->addr1, priv->net_dev->dev_addr,
- ETH_ALEN);
+ return ether_addr_equal(header->addr1,
+ priv->net_dev->dev_addr);
case IW_MODE_INFRA: /* Header: Dest. | BSSID | Source */
/* packets from our adapter are dropped (echo) */
- if (!memcmp(header->addr3, priv->net_dev->dev_addr, ETH_ALEN))
+ if (ether_addr_equal(header->addr3, priv->net_dev->dev_addr))
return 0;
/* {broad,multi}cast packets to our BSS go through */
if
Re: [sched] perf-stat.cpu-migrations changes in dd write test
On Wed, Dec 25, 2013 at 11:30:27AM +0800, Alex Shi wrote: > On 12/23/2013 01:24 PM, Fengguang Wu wrote: > > On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote: > >> On 12/22/2013 08:30 AM, fengguang...@intel.com wrote: > >>> Alex, > >>> > >>> We noticed some perf-stat.cpu-migrations changes by your commit > >> > >> Thanks for your wonder testing, Fengguang! > >> How many CPU in your system and how many dd task running? > > > > For the case > > > > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > > > > It's a KVM with 4 CPUs, 16G memory. There are 4 virtual disks, on top > > of each disk there runs 10 dd tasks. > > I don't know much of kvm. Where the data get from, VM guest or VM host? The data are collected in the VM guest. Thanks, Fengguang > Looks like any guest cpu usage will be counted as user usage in vmstat. > and Does the CS and cpu migration reducing cause dd performance increase? > > > > Thanks, > > Fengguang > > > >>> > >>> 6eb8b571283e64e96ca1a91aad085f9e08f857f0 is the first bad commit > >>> commit 6eb8b571283e64e96ca1a91aad085f9e08f857f0 > >>> Author: Alex Shi > >>> Date: Tue Nov 19 20:29:51 2013 +0800 > >>> > >>> sched: remove rq->cpu_load[load_idx] array > >>> > >>> Since load_idx effect removed in load balance, we don't need the > >>> load_idx decays in scheduler. that will save some process in > >>> sched_tick > >>> and others places. > >>> > >>> Signed-off-by: Alex Shi > >>> > >>> > >>> Here are the changed stats comparing to its parent commit: > >>> > >>> 1de157d718f6494 6eb8b571283e64e96ca1 > >>> --- - > >>> 37779 ~40%+115.2% 81288 ~50% > >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > >>> 37779 +115.2% 81288 TOTAL > >>> proc-vmstat.pgscan_direct_normal > >>> > >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: > >>> proc-vmstat.pgscan_direct_normal > >>> > >>>16 > >>> +++ > >>> | > >>> | > >>>14 ++ > >>> O > >>> | > >>> | > >>>12 ++ > >>> | > >>> |O > >>> | > >>>10 ++ > >>> | > >>> | > >>> | > >>> 8 ++ O > >>> | > >>> | > >>> ..* > >>> 6 ++ > >>> | > >>> | > >>> | > >>> 4 *+... O > >>> | > >>> O*... *. > >>> | > >>> 2 > >>> ++---*+ > >>> > >>> > >>> 1de157d718f6494 6eb8b571283e64e96ca1 > >>> --- - > >>> 121579 ~ 6% -50.8% 59852 ~13% > >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > >>> 121579 -50.8% 59852 TOTAL softirqs.SCHED > >>> > >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: softirqs.SCHED > >>> > >>>14 > >>> +++ > >>>13 ++ *... *... > >>> | > >>> | > >>> .. | > >>>12 *+...* > >>> ..| > >>>11 ++ > >>> * > >>> | > >>> | > >>>10 ++ > >>> | > >>> 9 ++ > >>> | > >>> 8 ++ > >>> | > >>> | > >>> | > >>> 7 ++ OO > >>> | > >>> 6 ++ O > >>> | > >>> | > >>> O > >>> 5 O+ > >>> | > >>> 4 >
[PATCH v3 03/19] net: atl1: slight optimization of addr compare
Use the recently added and possibly more efficient
ether_addr_equal_unaligned to instead of memcmp.
Cc: Jay Cliburn
Cc: Chris Snook
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/atheros/atlx/atl1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c
b/drivers/net/ethernet/atheros/atlx/atl1.c
index 538211d..55d86ec 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -3122,7 +3122,8 @@ static void atl1_remove(struct pci_dev *pdev)
* from the BIOS during POST. If we've been messing with the MAC
* address, we need to save the permanent one.
*/
- if (memcmp(adapter->hw.mac_addr, adapter->hw.perm_mac_addr, ETH_ALEN)) {
+ if (!ether_addr_equal_unaligned(adapter->hw.mac_addr,
+ adapter->hw.perm_mac_addr)) {
memcpy(adapter->hw.mac_addr, adapter->hw.perm_mac_addr,
ETH_ALEN);
atl1_set_mac_addr(>hw);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.12.6-rt9
On Tue, 2013-12-24 at 20:39 +0400, Pavel Vasilyev wrote: > 24.12.2013 19:47, Mike Galbraith пишет: > > On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote: > > > crash> bt > > PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16" > > YES!!! And ARM code broke :) And NO_HZ_TICK config survived for only 4.5 hours. PID: 6948 TASK: 880272d1f1c0 CPU: 29 COMMAND: "tbench" #0 [8802769a6a40] machine_kexec at 8103bc07 #1 [8802769a6aa0] crash_kexec at 810d3e93 #2 [8802769a6b70] panic at 815bce70 #3 [8802769a6bf0] watchdog_overflow_callback at 810fd51d #4 [8802769a6c10] __perf_event_overflow at 8112f1f8 #5 [8802769a6ca0] perf_event_overflow at 8112fb14 #6 [8802769a6cb0] intel_pmu_handle_irq at 8102078f #7 [8802769a6de0] perf_event_nmi_handler at 815c2de5 #8 [8802769a6e10] nmi_handle at 815c2493 #9 [8802769a6ea0] default_do_nmi at 815c2623 #10 [8802769a6ed0] do_nmi at 815c2948 #11 [8802769a6ef0] end_repeat_nmi at 815c1931 [exception RIP: preempt_schedule+36] RIP: 815be944 RSP: 8802769a3d98 RFLAGS: 0002 RAX: 0010 RBX: 0010 RCX: 0002 RDX: 8802769a3d98 RSI: 0018 RDI: 0001 RBP: 815be944 R8: 815be944 R9: 0018 R10: 8802769a3d98 R11: 0002 R12: R13: 880273f74000 R14: 880272d1f1c0 R15: 880269cedfd8 ORIG_RAX: 880269cedfd8 CS: 0010 SS: 0018 --- --- #12 [8802769a3d98] preempt_schedule at 815be944 #13 [8802769a3db0] _raw_spin_trylock at 815c0d6e #14 [8802769a3dc0] rt_spin_lock_slowunlock_hirq at 815c0288 #15 [8802769a3de0] rt_spin_unlock_after_trylock_in_irq at 815c09e5 #16 [8802769a3df0] run_local_timers at 81068025 #17 [8802769a3e10] update_process_times at 810680ac #18 [8802769a3e40] tick_sched_handle at 810c3a92 #19 [8802769a3e60] tick_sched_timer at 810c3d2f #20 [8802769a3e90] __run_hrtimer at 8108471d #21 [8802769a3ed0] hrtimer_interrupt at 8108497a #22 [8802769a3f70] local_apic_timer_interrupt at 810349e6 #23 [8802769a3f90] smp_apic_timer_interrupt at 810358ee #24 [8802769a3fb0] apic_timer_interrupt at 815c955d --- --- #25 [880269ced848] apic_timer_interrupt at 815c955d [exception RIP: _raw_spin_lock+53] RIP: 815c0c05 RSP: 880269ced8f8 RFLAGS: 0202 RAX: 0b7b RBX: 0282 RCX: 880272d1f1c0 RDX: 0b7d RSI: 880269ceda38 RDI: 880273f74000 RBP: 880269ced8f8 R8: 0001 R9: b54d13a4 R10: 0001 R11: 0001 R12: 880269ced910 R13: 880276d32170 R14: 810c9030 R15: 880269ced8b8 ORIG_RAX: ff10 CS: 0010 SS: 0018 #26 [880269ced900] rt_spin_lock_slowlock at 815bfb51 #27 [880269ced9e0] rt_spin_lock at 815c0922 #28 [880269ced9f0] lock_timer_base at 81067f92 #29 [880269ceda20] mod_timer at 81069bcb #30 [880269ceda70] sk_reset_timer at 814d1e57 #31 [880269ceda90] inet_csk_reset_xmit_timer at 8152d4a8 #32 [880269cedac0] tcp_rearm_rto at 8152d583 #33 [880269cedae0] tcp_ack at 81534085 #34 [880269cedb60] tcp_rcv_established at 8153443d #35 [880269cedbb0] tcp_v4_do_rcv at 8153f56a #36 [880269cedbe0] __release_sock at 814d3891 #37 [880269cedc10] release_sock at 814d3942 #38 [880269cedc30] tcp_sendmsg at 8152b955 #39 [880269cedd00] inet_sendmsg at 8155350e #40 [880269cedd30] sock_sendmsg at 814cea87 #41 [880269cede40] sys_sendto at 814cebdf #42 [880269cedf80] tracesys at 815c8b09 (via system_call) RIP: 7f0441a1fc35 RSP: 7fffdea86130 RFLAGS: 0246 RAX: ffda RBX: 815c8b09 RCX: RDX: 248d RSI: 00607260 RDI: 0004 RBP: 248d R8: R9: R10: R11: 0246 R12: 7fffdea86a10 R13: 7fffdea86414 R14: 0004 R15: 00607260 ORIG_RAX: 002c CS: 0033 SS: 002b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/19] ozwpan: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Rupesh Gujare
Cc: Greg Kroah-Hartman
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tan Xiaojun
Signed-off-by: Ding Tianhong
---
drivers/staging/ozwpan/ozcdev.c | 2 +-
drivers/staging/ozwpan/ozproto.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 6ce0af9..c363f66 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -448,7 +448,7 @@ int oz_cdev_start(struct oz_pd *pd, int resume)
}
spin_lock(_cdev.lock);
if ((g_cdev.active_pd == NULL) &&
- (memcmp(pd->mac_addr, g_cdev.active_addr, ETH_ALEN) == 0)) {
+ (ether_addr_equal(pd->mac_addr, g_cdev.active_addr))) {
oz_pd_get(pd);
g_cdev.active_pd = pd;
oz_dbg(ON, "Active PD arrived\n");
diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index 88714ec..19a2521 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include "ozdbg.h"
@@ -180,7 +181,7 @@ static struct oz_pd *oz_connect_req(struct oz_pd *cur_pd,
struct oz_elt *elt,
spin_lock_bh(_polling_lock);
list_for_each(e, _pd_list) {
pd2 = container_of(e, struct oz_pd, link);
- if (memcmp(pd2->mac_addr, pd_addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(pd2->mac_addr, pd_addr)) {
free_pd = pd;
pd = pd2;
break;
@@ -597,7 +598,7 @@ struct oz_pd *oz_pd_find(const u8 *mac_addr)
spin_lock_bh(_polling_lock);
list_for_each(e, _pd_list) {
pd = container_of(e, struct oz_pd, link);
- if (memcmp(pd->mac_addr, mac_addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(pd->mac_addr, mac_addr)) {
atomic_inc(>ref_count);
spin_unlock_bh(_polling_lock);
return pd;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/19] atm: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Chas Williams
Cc: linux-atm-gene...@lists.sourceforge.net
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang
Signed-off-by: Ding Tianhong
---
drivers/atm/nicstar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 5aca5f4..9587e95 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include "nicstar.h"
#ifdef CONFIG_ATM_NICSTAR_USE_SUNI
#include "suni.h"
@@ -781,8 +782,7 @@ static int ns_init_card(int i, struct pci_dev *pcidev)
if (mac[i] == NULL || !mac_pton(mac[i], card->atmdev->esi)) {
nicstar_read_eprom(card->membase, NICSTAR_EPROM_MAC_ADDR_OFFSET,
card->atmdev->esi, 6);
- if (memcmp(card->atmdev->esi, "\x00\x00\x00\x00\x00\x00", 6) ==
- 0) {
+ if (ether_addr_equal(card->atmdev->esi,
"\x00\x00\x00\x00\x00\x00")) {
nicstar_read_eprom(card->membase,
NICSTAR_EPROM_MAC_ADDR_OFFSET_ALT,
card->atmdev->esi, 6);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 19/19] wireless: slight optimization of addr compare
Use possibly more efficient ether_addr_equal or
ether_addr_equal_unaligned instead of memcmp.
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/adm8211.c| 2 +-
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 7 +++
drivers/net/wireless/hostap/hostap_80211_rx.c | 8
drivers/net/wireless/prism54/isl_ioctl.c | 3 ++-
drivers/net/wireless/ti/wl1251/main.c | 2 +-
drivers/net/wireless/wl3501_cs.c | 4 ++--
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index cfce83e..1d40c69 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1314,7 +1314,7 @@ static void adm8211_bss_info_changed(struct ieee80211_hw
*dev,
if (!(changes & BSS_CHANGED_BSSID))
return;
- if (memcmp(conf->bssid, priv->bssid, ETH_ALEN)) {
+ if (!ether_addr_equal(conf->bssid, priv->bssid)) {
adm8211_set_bssid(dev, conf->bssid);
memcpy(priv->bssid, conf->bssid, ETH_ALEN);
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
index d318036..185af8a 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
@@ -1243,7 +1243,7 @@ bool brcmf_p2p_scan_finding_common_channel(struct
brcmf_cfg80211_info *cfg,
IEEE80211_P2P_ATTR_DEVICE_ID,
p2p_dev_addr, sizeof(p2p_dev_addr));
if ((err >= 0) &&
- (!memcmp(p2p_dev_addr, afx_hdl->tx_dst_addr, ETH_ALEN))) {
+ (ether_addr_equal(p2p_dev_addr, afx_hdl->tx_dst_addr))) {
if (!bi->ctl_ch) {
ch.chspec = le16_to_cpu(bi->chanspec);
cfg->d11inf.decchspec();
@@ -1380,8 +1380,7 @@ int brcmf_p2p_notify_action_frame_rx(struct brcmf_if *ifp,
(brcmf_p2p_gon_req_collision(p2p, (u8 *)e->addr))) {
if (test_bit(BRCMF_P2P_STATUS_FINDING_COMMON_CHANNEL,
>status) &&
- (memcmp(afx_hdl->tx_dst_addr, e->addr,
- ETH_ALEN) == 0)) {
+ (ether_addr_equal(afx_hdl->tx_dst_addr, e->addr))) {
afx_hdl->peer_chan = ch.chnum;
brcmf_dbg(INFO, "GON request: Peer found,
channel=%d\n",
afx_hdl->peer_chan);
@@ -1865,7 +1864,7 @@ s32 brcmf_p2p_notify_rx_mgmt_p2p_probereq(struct brcmf_if
*ifp,
cfg->d11inf.decchspec();
if (test_bit(BRCMF_P2P_STATUS_FINDING_COMMON_CHANNEL, >status) &&
- (memcmp(afx_hdl->tx_dst_addr, e->addr, ETH_ALEN) == 0)) {
+ (ether_addr_equal(afx_hdl->tx_dst_addr, e->addr))) {
afx_hdl->peer_chan = ch.chnum;
brcmf_dbg(INFO, "PROBE REQUEST: Peer found, channel=%d\n",
afx_hdl->peer_chan);
diff --git a/drivers/net/wireless/hostap/hostap_80211_rx.c
b/drivers/net/wireless/hostap/hostap_80211_rx.c
index d39e3e2..599f30f 100644
--- a/drivers/net/wireless/hostap/hostap_80211_rx.c
+++ b/drivers/net/wireless/hostap/hostap_80211_rx.c
@@ -563,7 +563,7 @@ hostap_rx_frame_wds(local_info_t *local, struct
ieee80211_hdr *hdr, u16 fc,
/* Possible WDS frame: either IEEE 802.11 compliant (if FromDS)
* or own non-standard frame with 4th address after payload */
- if (memcmp(hdr->addr1, local->dev->dev_addr, ETH_ALEN) != 0 &&
+ if (!ether_addr_equal(hdr->addr1, local->dev->dev_addr) &&
(hdr->addr1[0] != 0xff || hdr->addr1[1] != 0xff ||
hdr->addr1[2] != 0xff || hdr->addr1[3] != 0xff ||
hdr->addr1[4] != 0xff || hdr->addr1[5] != 0xff)) {
@@ -622,12 +622,12 @@ static int hostap_is_eapol_frame(local_info_t *local,
struct sk_buff *skb)
/* check that the frame is unicast frame to us */
if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
IEEE80211_FCTL_TODS &&
- memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 &&
- memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) {
+ ether_addr_equal(hdr->addr1, dev->dev_addr) &&
+ ether_addr_equal(hdr->addr3, dev->dev_addr)) {
/* ToDS frame with own addr BSSID and DA */
} else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
IEEE80211_FCTL_FROMDS &&
- memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) {
+ ether_addr_equal(hdr->addr1, dev->dev_addr)) {
/* FromDS frame with own addr as DA */
} else
return 0;
diff --git
Re: [PATCH v7 09/12] efi: passing kexec necessary efi data via setup_data
On 12/25/13 at 11:12am, Dave Young wrote:
> On 12/23/13 at 08:07am, Matt Fleming wrote:
> > On Mon, 23 Dec, at 10:09:58AM, Dave Young wrote:
> > > On 12/21/13 at 04:06pm, Matt Fleming wrote:
> > > > On Fri, 20 Dec, at 06:02:19PM, Dave Young wrote:
> > > > > @@ -133,6 +133,19 @@ extern void efi_sync_low_kernel_mappings(void);
> > > > > extern void efi_setup_page_tables(void);
> > > > > extern void __init old_map_region(efi_memory_desc_t *md);
> > > > >
> > > > > +struct efi_setup_data {
> > > > > + u64 fw_vendor;
> > > > > + u64 runtime;
> > > > > + u64 tables;
> > > > > + u64 smbios;
> > > > > + u64 reserved[8];
> > > > > + efi_memory_desc_t map[0];
> > > > > +};
> > > >
> > > > [...]
> > > >
> > > > > +static void get_nr_runtime_map(void)
> > > > > +{
> > > > > + if (!efi_setup)
> > > > > + return;
> > > > > +
> > > > > + nr_efi_runtime_map = (efi_data_len - sizeof(struct
> > > > > efi_setup_data)) /
> > > > > + sizeof(efi_memory_desc_t);
> > > > > +}
> > > >
> > > > Do we actually need the 'map' entry in efi_setup_data now that you're
> > > > passing it via efi_info (which is much better approach!)? Also, we don't
> > > > need the global nr_efi_runtime_map or efi_runtime_map variables now,
> > > > right?
> > >
> > > The map is still necessary because we need store the map somewhere and
> > > pass
> > > the physicall address to kexec kernel. Passing them in setup_data is the
> > > only better way currently...
> > >
> > > In efi_info there's only an entry for the map physical address, the
> > > original
> > > map area is not valid any more.
> >
> > Where do you dereference efi_setup_data.map* in the kexec kernel?
>
> The field itself is not dereferenced in kernel but it's still used in
> userspace
> code for collecting and saving runtime maps. Since I still append the map at
> the
> end of efi_setup_data so I think keep the map[0] is ok. What's your opinion?
Matt, if you want to remove the map[0] please fold below one line patch? I have
no
strong opinion.
Index: linux/arch/x86/include/asm/efi.h
===
--- linux.orig/arch/x86/include/asm/efi.h
+++ linux/arch/x86/include/asm/efi.h
@@ -139,7 +139,6 @@ struct efi_setup_data {
u64 tables;
u64 smbios;
u64 reserved[8];
- efi_memory_desc_t map[0];
};
extern u64 efi_setup;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 18/19] rtlwifi: slight optimization of addr compare
Use possibly more efficient ether_addr_equal_unaligned
instead of memcmp.
Cc: Larry Finger
Cc: Chaoming Li
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/rtlwifi/cam.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/cam.c
b/drivers/net/wireless/rtlwifi/cam.c
index 0e510f7..0276153 100644
--- a/drivers/net/wireless/rtlwifi/cam.c
+++ b/drivers/net/wireless/rtlwifi/cam.c
@@ -295,7 +295,7 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw, u8
*sta_addr)
/* Does STA already exist? */
for (i = 4; i < TOTAL_CAM_ENTRY; i++) {
addr = rtlpriv->sec.hwsec_cam_sta_addr[i];
- if (memcmp(addr, sta_addr, ETH_ALEN) == 0)
+ if (ether_addr_equal_unaligned(addr, sta_addr))
return i;
}
/* Get a free CAM entry. */
@@ -335,7 +335,7 @@ void rtl_cam_del_entry(struct ieee80211_hw *hw, u8
*sta_addr)
addr = rtlpriv->sec.hwsec_cam_sta_addr[i];
bitmap = (rtlpriv->sec.hwsec_cam_bitmap) >> i;
if (((bitmap & BIT(0)) == BIT(0)) &&
- (memcmp(addr, sta_addr, ETH_ALEN) == 0)) {
+ (ether_addr_equal_unaligned(addr, sta_addr))) {
/* Remove from HW Security CAM */
eth_zero_addr(rtlpriv->sec.hwsec_cam_sta_addr[i]);
rtlpriv->sec.hwsec_cam_bitmap &= ~(BIT(0) << i);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT] regulator: act8865: Remove set_suspend_[en|dis]able implementation
There is no suspend enable/disable settings mentioned in datasheet,
so just don't implement .set_suspend_[en|dis]able callbacks.
Signed-off-by: Axel Lin
---
drivers/regulator/act8865-regulator.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index dfae294..e7dbdc0 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -85,8 +85,6 @@ static struct regulator_ops act8865_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
- .set_suspend_enable = regulator_enable_regmap,
- .set_suspend_disable= regulator_disable_regmap,
};
static const struct regulator_desc act8865_reg[] = {
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [sched] perf-stat.cpu-migrations changes in dd write test
On 12/23/2013 01:24 PM, Fengguang Wu wrote: > On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote: >> On 12/22/2013 08:30 AM, fengguang...@intel.com wrote: >>> Alex, >>> >>> We noticed some perf-stat.cpu-migrations changes by your commit >> >> Thanks for your wonder testing, Fengguang! >> How many CPU in your system and how many dd task running? > > For the case > > kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd > > It's a KVM with 4 CPUs, 16G memory. There are 4 virtual disks, on top > of each disk there runs 10 dd tasks. I don't know much of kvm. Where the data get from, VM guest or VM host? Looks like any guest cpu usage will be counted as user usage in vmstat. and Does the CS and cpu migration reducing cause dd performance increase? > > Thanks, > Fengguang > >>> >>> 6eb8b571283e64e96ca1a91aad085f9e08f857f0 is the first bad commit >>> commit 6eb8b571283e64e96ca1a91aad085f9e08f857f0 >>> Author: Alex Shi >>> Date: Tue Nov 19 20:29:51 2013 +0800 >>> >>> sched: remove rq->cpu_load[load_idx] array >>> >>> Since load_idx effect removed in load balance, we don't need the >>> load_idx decays in scheduler. that will save some process in sched_tick >>> and others places. >>> >>> Signed-off-by: Alex Shi >>> >>> >>> Here are the changed stats comparing to its parent commit: >>> >>> 1de157d718f6494 6eb8b571283e64e96ca1 >>> --- - >>> 37779 ~40%+115.2% 81288 ~50% >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd >>> 37779 +115.2% 81288 TOTAL >>> proc-vmstat.pgscan_direct_normal >>> >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: >>> proc-vmstat.pgscan_direct_normal >>> >>>16 >>> +++ >>> | >>> | >>>14 ++ >>> O >>> | >>> | >>>12 ++ >>> | >>> |O >>> | >>>10 ++ >>> | >>> | >>> | >>> 8 ++ O >>> | >>> | >>> ..* >>> 6 ++ >>> | >>> | >>> | >>> 4 *+... O >>> | >>> O*... *. >>> | >>> 2 >>> ++---*+ >>> >>> >>> 1de157d718f6494 6eb8b571283e64e96ca1 >>> --- - >>> 121579 ~ 6% -50.8% 59852 ~13% >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd >>> 121579 -50.8% 59852 TOTAL softirqs.SCHED >>> >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd: softirqs.SCHED >>> >>>14 >>> +++ >>>13 ++ *... *... >>> | >>> | .. >>> | >>>12 *+...* >>> ..| >>>11 ++ >>> * >>> | >>> | >>>10 ++ >>> | >>> 9 ++ >>> | >>> 8 ++ >>> | >>> | >>> | >>> 7 ++ OO >>> | >>> 6 ++ O >>> | >>> | >>> O >>> 5 O+ >>> | >>> 4 >>> +++ >>> >>> >>> 1de157d718f6494 6eb8b571283e64e96ca1 >>> --- - >>> 5636 ~ 4% -22.1% 4392 ~17% >>> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd >>> 5636 -22.1% 4392 TOTAL >>>
Re: [PATCH] x86, irq, fix logical AND/OR error in check_irq_vectors_for_cpu_disable()
On Tue, Dec 24, 2013 at 08:19:09AM -0500, Prarit Bhargava wrote:
> On 12/23/2013 09:51 PM, Chen, Gong wrote:
> > On Mon, Dec 23, 2013 at 09:39:12AM -0500, Prarit Bhargava wrote:
> >> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> >> index 7d40698..aed7acc 100644
> >> --- a/arch/x86/kernel/irq.c
> >> +++ b/arch/x86/kernel/irq.c
> >> @@ -281,7 +281,7 @@ int check_irq_vectors_for_cpu_disable(void)
> >>desc = irq_to_desc(irq);
> >>data = irq_desc_get_irq_data(desc);
> >>affinity = data->affinity;
> >> - if (irq_has_action(irq) || !irqd_is_per_cpu(data) ||
> >> + if (irq_has_action(irq) && !irqd_is_per_cpu(data) &&
> >>!cpumask_subset(affinity, cpu_online_mask))
> >>this_count++;
> > Hi, Prarit
> >
> > I noticed that you don't mention another question I asked in last mail.
> >
> > "It looks like cpu_online_mask will be updated until cpu_disable_common
> > is called, but your check_vectors is called before that."
>
> Oh, I'm sorry ... Yes, check_irq_vectors_for_cpu_disable() is called before we
> remove the CPU from the maps. If there is an error then we have to do much
> less
> clean up of the code. I explicitly take into account the cpu that is being
> downed into the check vectors code.
>
Here is my question: How to decide this_count can be incrased?
1) it is a valid irq(irq_has_action) 2) it is not percpu irq(!irqd_is_per_cpu)
3) it is not shared with left online cpus(!cpumask_subset)
For item 3, I have some concerns.
Your current codes are called before cpu_disable_common, so affinity and
cpu_online_mask are both not updated. BTW, it means your calculation
for count is not correct because it concludes one to-be-off-lined cpu
+ for_each_online_cpu(cpu) {
+ if (cpu == smp_processor_id())
+ continue;
+ for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS;
+vector++) {
+ if (per_cpu(vector_irq, cpu)[vector] < 0)
+ count++;
+ }
+ }
Back to my question, assume cpu1 will be off-lined and one irq affinity is
set as (1, 2) -- this irq will be bypassed. Looks good. But if one irq
affinity is set as only (1), -- this irq is bypassed, too. Not right!
Furthermore, you even can't use cpumask_subset as evaluation condition,
whatever affinity/cpu_online_mask is updated or not. Let me paste the
comment of cpumask_subset:
/**
* cpumask_subset - (*src1p & ~*src2p) == 0
* @src1p: the first input
* @src2p: the second input
*
* Returns 1 if *@src1p is a subset of *@src2p, else returns 0
*/
Here we can see, even if src1p is an empty set, it still can be considered
as the subset of src2p. For our this special case, I mean cpu1 will
be off-lined and one irq affinity is set as (1). If this irq affinity
is updated to (0), it means no cpu is bound to this irq, but the
calculation of cpumask_subset will return true and this irq will be
bypassed. For this case, cpumask_empty should be more suitable.
signature.asc
Description: Digital signature
[PATCH v3 17/19] mwifiex: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Bing Zhao
Cc: John W. Linville
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Weilong Chen
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/mwifiex/11n.c | 2 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 3 +--
drivers/net/wireless/mwifiex/sta_rx.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/11n.c
b/drivers/net/wireless/mwifiex/11n.c
index 0b803c0..6261f8c 100644
--- a/drivers/net/wireless/mwifiex/11n.c
+++ b/drivers/net/wireless/mwifiex/11n.c
@@ -483,7 +483,7 @@ mwifiex_get_ba_tbl(struct mwifiex_private *priv, int tid,
u8 *ra)
spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
list_for_each_entry(tx_ba_tsr_tbl, >tx_ba_stream_tbl_ptr, list) {
- if (!memcmp(tx_ba_tsr_tbl->ra, ra, ETH_ALEN) &&
+ if (ether_addr_equal_unaligned(tx_ba_tsr_tbl->ra, ra) &&
tx_ba_tsr_tbl->tid == tid) {
spin_unlock_irqrestore(>tx_ba_stream_tbl_lock,
flags);
diff --git a/drivers/net/wireless/mwifiex/sta_cmdresp.c
b/drivers/net/wireless/mwifiex/sta_cmdresp.c
index 5511946..24523e4 100644
--- a/drivers/net/wireless/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/mwifiex/sta_cmdresp.c
@@ -782,8 +782,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct
mwifiex_private *priv,
}
/* If BSSID is diff, modify current BSS parameters */
- if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
- ibss_coal_resp->bssid, ETH_ALEN)) {
+ if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address,
ibss_coal_resp->bssid)) {
/* BSSID */
memcpy(priv->curr_bss_params.bss_descriptor.mac_address,
ibss_coal_resp->bssid, ETH_ALEN);
diff --git a/drivers/net/wireless/mwifiex/sta_rx.c
b/drivers/net/wireless/mwifiex/sta_rx.c
index 0bb510d..4651d67 100644
--- a/drivers/net/wireless/mwifiex/sta_rx.c
+++ b/drivers/net/wireless/mwifiex/sta_rx.c
@@ -224,7 +224,7 @@ int mwifiex_process_sta_rx_packet(struct mwifiex_private
*priv,
* directly to os. Don't pass thru rx reordering
*/
if (!IS_11N_ENABLED(priv) ||
- memcmp(priv->curr_addr, rx_pkt_hdr->eth803_hdr.h_dest, ETH_ALEN)) {
+ !ether_addr_equal_unaligned(priv->curr_addr,
rx_pkt_hdr->eth803_hdr.h_dest)) {
mwifiex_process_rx_packet(priv, skb);
return ret;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 01/19] net: freescale: remove unused compare_addr()
The function did not be used any more, so remove it.
Cc: Li Yang
Cc: net...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/freescale/ucc_geth.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 5548b6d..72291a8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -435,11 +435,6 @@ static void hw_add_addr_in_hash(struct ucc_geth_private
*ugeth,
QE_CR_PROTOCOL_ETHERNET, 0);
}
-static inline int compare_addr(u8 **addr1, u8 **addr2)
-{
- return memcmp(addr1, addr2, ETH_ALEN);
-}
-
#ifdef DEBUG
static void get_statistics(struct ucc_geth_private *ugeth,
struct ucc_geth_tx_firmware_statistics *
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 02/19] net: pcnet: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Don Fry
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/amd/pcnet32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 38492e0..9339ccc 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1668,7 +1668,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
for (i = 0; i < ETH_ALEN; i++)
promaddr[i] = inb(ioaddr + i);
- if (memcmp(promaddr, dev->dev_addr, ETH_ALEN) ||
+ if (!ether_addr_equal(promaddr, dev->dev_addr) ||
!is_valid_ether_addr(dev->dev_addr)) {
if (is_valid_ether_addr(promaddr)) {
if (pcnet32_debug & NETIF_MSG_PROBE) {
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/19] zd1211rw: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Daniel Drake
Cc: Ulrich Kunitz
Cc: "John W. Linville"
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tan Xiaojun
Signed-off-by: Ding Tianhong
---
drivers/net/wireless/zd1211rw/zd_mac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
b/drivers/net/wireless/zd1211rw/zd_mac.c
index eff79a3..e7af261 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -532,9 +532,8 @@ void zd_mac_tx_failed(struct urb *urb)
tx_hdr = (struct ieee80211_hdr *)skb->data;
/* we skip all frames not matching the reported destination */
- if (unlikely(memcmp(tx_hdr->addr1, tx_status->mac, ETH_ALEN))) {
+ if (unlikely(!ether_addr_equal(tx_hdr->addr1, tx_status->mac)))
continue;
- }
/* we skip all frames not matching the reported final rate */
@@ -997,7 +996,7 @@ static int filter_ack(struct ieee80211_hw *hw, struct
ieee80211_hdr *rx_hdr,
continue;
tx_hdr = (struct ieee80211_hdr *)skb->data;
- if (likely(!memcmp(tx_hdr->addr2, rx_hdr->addr1, ETH_ALEN)))
+ if (likely(ether_addr_equal(tx_hdr->addr2, rx_hdr->addr1)))
{
found = 1;
break;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/19] ppp: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Michal Ostrowski
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong
---
drivers/net/ppp/pppoe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 82ee6ed..2ea7efd 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -131,12 +131,12 @@ static inline struct pppoe_net *pppoe_pernet(struct net
*net)
static inline int cmp_2_addr(struct pppoe_addr *a, struct pppoe_addr *b)
{
- return a->sid == b->sid && !memcmp(a->remote, b->remote, ETH_ALEN);
+ return a->sid == b->sid && ether_addr_equal(a->remote, b->remote);
}
static inline int cmp_addr(struct pppoe_addr *a, __be16 sid, char *addr)
{
- return a->sid == sid && !memcmp(a->remote, addr, ETH_ALEN);
+ return a->sid == sid && ether_addr_equal(a->remote, addr);
}
#if 8 % PPPOE_HASH_BITS
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 04/19] hamradio: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: Joerg Reuter Cc: linux-h...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ding Tianhong --- drivers/net/hamradio/bpqether.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c index f91bf0d..d50b23c 100644 --- a/drivers/net/hamradio/bpqether.c +++ b/drivers/net/hamradio/bpqether.c @@ -208,7 +208,7 @@ static int bpq_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_ty eth = eth_hdr(skb); if (!(bpq->acpt_addr[0] & 0x01) && - memcmp(eth->h_source, bpq->acpt_addr, ETH_ALEN)) + !ether_addr_equal(eth->h_source, bpq->acpt_addr)) goto drop_unlock; if (skb_cow(skb, sizeof(struct ethhdr))) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/19] slight optimization of addr compare for some modules
Joe Perches add ether_addr_equal_unaligned to test if possibly unaligned to u16 Ethernet addresses are equal. If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set, this uses the slightly faster generic routine ether_addr_equal, otherwise this uses memcmp. So I use the recently added and possibly more efficient ether_addr_equal_unaligned to instead of memcmp for slight optimization. v2: Because a lot of places are already using 16b aligned MAC address for both operands, so use the ether_addr_equal to instead of ether_addr_equal_unaligned.Thanks for Joe, Alex and Antonio's opinions. Also remove the patch for bridge. v3: According Joe's suggestion, the patch (net: slight optimization of addr compare for some modules) should be broken into several patches, and it will be good to review for maintainers. So I will send rest of the patches for first step, and next step, I will seperate the netdev patch and send them by another patchset for net-next. also fix some changelog. Best Regards Ding Ding Tianhong (5): net: freescale: remove unused compare_addr() net: pcnet: slight optimization of addr compare net: atl1: slight optimization of addr compare hamradio: slight optimization of addr compare ppp: slight optimization of addr compare Tan Xiaojun (3): batman-adv: use batadv_compare_eth for concise zd1211rw: slight optimization of addr compare ozwpan: slight optimization of addr compare Wang Weidong (2): infiniband: slight optimization of addr compare mac8011: slight optimization of addr compare Weilong Chen (6): hostap: slight optimization of addr compare cw1200: slight optimization of addr compare ipw2x00: slight optimization of addr compare mwifiex: slight optimization of addr compare rtlwifi: slight optimization of addr compare wireless: slight optimization of addr compare Yang Yingliang (3): atm: slight optimization of addr compare isdn: slight optimization of addr compare media: dvb_core: slight optimization of addr compare drivers/atm/nicstar.c | 4 ++-- drivers/infiniband/hw/nes/nes_cm.c| 3 +-- drivers/isdn/i4l/isdn_net.c | 4 ++-- drivers/media/dvb-core/dvb_net.c | 8 +++ drivers/net/ethernet/amd/pcnet32.c| 2 +- drivers/net/ethernet/atheros/atlx/atl1.c | 3 ++- drivers/net/ethernet/freescale/ucc_geth.c | 5 drivers/net/hamradio/bpqether.c | 2 +- drivers/net/ppp/pppoe.c | 4 ++-- drivers/net/wireless/adm8211.c| 2 +- drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 7 +++--- drivers/net/wireless/cw1200/sta.c | 5 ++-- drivers/net/wireless/cw1200/txrx.c| 3 +-- drivers/net/wireless/hostap/hostap_80211_rx.c | 8 +++ drivers/net/wireless/hostap/hostap_80211_tx.c | 4 ++-- drivers/net/wireless/hostap/hostap_ap.c | 28 +++--- drivers/net/wireless/hostap/hostap_hw.c | 2 +- drivers/net/wireless/hostap/hostap_ioctl.c| 4 ++-- drivers/net/wireless/hostap/hostap_main.c | 8 +++ drivers/net/wireless/ipw2x00/ipw2200.c| 34 +-- drivers/net/wireless/ipw2x00/libipw_rx.c | 10 drivers/net/wireless/mwifiex/11n.c| 2 +- drivers/net/wireless/mwifiex/sta_cmdresp.c| 3 +-- drivers/net/wireless/mwifiex/sta_rx.c | 2 +- drivers/net/wireless/prism54/isl_ioctl.c | 3 ++- drivers/net/wireless/rtlwifi/cam.c| 4 ++-- drivers/net/wireless/ti/wl1251/main.c | 2 +- drivers/net/wireless/wl3501_cs.c | 4 ++-- drivers/net/wireless/zd1211rw/zd_mac.c| 5 ++-- drivers/staging/ozwpan/ozcdev.c | 2 +- drivers/staging/ozwpan/ozproto.c | 5 ++-- net/batman-adv/originator.c | 2 +- net/batman-adv/translation-table.c| 2 +- net/mac80211/iface.c | 7 +++--- 34 files changed, 92 insertions(+), 101 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/19] infiniband: slight optimization of addr compare
Use the possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Faisal Latif
Cc: linux-r...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Wang Weidong
Signed-off-by: Ding Tianhong
---
drivers/infiniband/hw/nes/nes_cm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes_cm.c
b/drivers/infiniband/hw/nes/nes_cm.c
index 6b29249..9c9f2f5 100644
--- a/drivers/infiniband/hw/nes/nes_cm.c
+++ b/drivers/infiniband/hw/nes/nes_cm.c
@@ -1354,8 +1354,7 @@ static int nes_addr_resolve_neigh(struct nes_vnic
*nesvnic, u32 dst_ip, int arpi
neigh->ha, ntohl(rt->rt_gateway));
if (arpindex >= 0) {
- if
(!memcmp(nesadapter->arp_table[arpindex].mac_addr,
- neigh->ha, ETH_ALEN)) {
+ if
(ether_addr_equal(nesadapter->arp_table[arpindex].mac_addr, neigh->ha)) {
/* Mac address same as in nes_arp_table
*/
goto out;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/19] batman-adv: use batadv_compare_eth for concise
It is better to use batadv_compate_eth instead of memcpy for concise style. Cc: Marek Lindner Cc: Simon Wunderlich Cc: Antonio Quartulli Cc: "David S. Miller" Cc: b.a.t.m@lists.open-mesh.org Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tan Xiaojun Signed-off-by: Ding Tianhong Acked-by: Antonio Quartulli --- net/batman-adv/originator.c| 2 +- net/batman-adv/translation-table.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index 8ab1434..803ab4b 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -41,7 +41,7 @@ int batadv_compare_orig(const struct hlist_node *node, const void *data2) const void *data1 = container_of(node, struct batadv_orig_node, hash_entry); - return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0); + return batadv_compare_eth(data1, data2); } /** diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c index 4add57d..06506e6 100644 --- a/net/batman-adv/translation-table.c +++ b/net/batman-adv/translation-table.c @@ -51,7 +51,7 @@ static int batadv_compare_tt(const struct hlist_node *node, const void *data2) const void *data1 = container_of(node, struct batadv_tt_common_entry, hash_entry); - return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0); + return batadv_compare_eth(data1, data2); } /** -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 13/19] media: dvb_core: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang
Signed-off-by: Ding Tianhong
---
drivers/media/dvb-core/dvb_net.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index f91c80c..3dfc33b 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -179,7 +179,7 @@ static __be16 dvb_net_eth_type_trans(struct sk_buff *skb,
eth = eth_hdr(skb);
if (*eth->h_dest & 1) {
- if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
+ if(ether_addr_equal(eth->h_dest,dev->broadcast))
skb->pkt_type=PACKET_BROADCAST;
else
skb->pkt_type=PACKET_MULTICAST;
@@ -674,11 +674,11 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
if (priv->rx_mode != RX_MODE_PROMISC) {
if (priv->ule_skb->data[0] &
0x01) {
/* multicast or
broadcast */
- if
(memcmp(priv->ule_skb->data, bc_addr, ETH_ALEN)) {
+ if
(!ether_addr_equal(priv->ule_skb->data, bc_addr)) {
/* multicast */
if
(priv->rx_mode == RX_MODE_MULTI) {
int i;
- for(i =
0; i < priv->multi_num && memcmp(priv->ule_skb->data, priv->multi_macs[i],
ETH_ALEN); i++)
+ for(i =
0; i < priv->multi_num && !ether_addr_equal(priv->ule_skb->data,
priv->multi_macs[i]); i++)
;
if (i
== priv->multi_num)
drop = 1;
@@ -688,7 +688,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
}
/* else: broadcast */
}
- else if
(memcmp(priv->ule_skb->data, dev->dev_addr, ETH_ALEN))
+ else if
(!ether_addr_equal(priv->ule_skb->data, dev->dev_addr))
drop = 1;
/* else: destination address
matches the MAC address of our receiver device */
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/12] kexec kernel efi runtime support
On 12/23/13 at 07:36am, Matt Fleming wrote:
> On Sun, 22 Dec, at 02:27:01PM, Toshi Kani wrote:
> >
> > The kexec branch is missing the following change, which is required for
> > fast reboot with multi-cpus.
> >
> >commit 279f1df915c3a6ed3075d98a849705bf53851f99
> >Author: Vivek Goyal
> >Date: Tue Nov 26 10:25:28 2013 +0800
> >
> >kexec: migrate to reboot cpu
> >
> > With this change added, I confirmed that the branch kernel works fine.
>
> I can't find that commit in Linus' tree. Where is it from?
Previously it was in Andrew's mm tree, currently it's below commit in linus
tree:
commit c97102ba96324da330078ad8619ba4dfe840dbe3
Author: Vivek Goyal
Date: Wed Dec 18 17:08:31 2013 -0800
kexec: migrate to reboot cpu
Commit 1b3a5d02ee07 ("reboot: move arch/x86 reboot= handling to generic
kernel") moved reboot= handling to generic code. In the process it also
removed the code in native_machine_shutdown() which are moving reboot
process to reboot_cpu/cpu0.
I guess that thought must have been that all reboot paths are calling
migrate_to_reboot_cpu(), so we don't need this special handling. But
kexec reboot path (kernel_kexec()) is not calling
migrate_to_reboot_cpu() so above change broke kexec. Now reboot can
happen on non-boot cpu and when INIT is sent in second kerneo to bring
up BP, it brings down the machine.
So start calling migrate_to_reboot_cpu() in kexec reboot path to avoid
this problem.
Bisected by WANG Chao.
Reported-by: Matthew Whitehead
Reported-by: Dave Young
Signed-off-by: Vivek Goyal
Tested-by: Baoquan He
Tested-by: WANG Chao
Acked-by: H. Peter Anvin
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 09/12] efi: passing kexec necessary efi data via setup_data
On 12/23/13 at 08:07am, Matt Fleming wrote:
> On Mon, 23 Dec, at 10:09:58AM, Dave Young wrote:
> > On 12/21/13 at 04:06pm, Matt Fleming wrote:
> > > On Fri, 20 Dec, at 06:02:19PM, Dave Young wrote:
> > > > @@ -133,6 +133,19 @@ extern void efi_sync_low_kernel_mappings(void);
> > > > extern void efi_setup_page_tables(void);
> > > > extern void __init old_map_region(efi_memory_desc_t *md);
> > > >
> > > > +struct efi_setup_data {
> > > > + u64 fw_vendor;
> > > > + u64 runtime;
> > > > + u64 tables;
> > > > + u64 smbios;
> > > > + u64 reserved[8];
> > > > + efi_memory_desc_t map[0];
> > > > +};
> > >
> > > [...]
> > >
> > > > +static void get_nr_runtime_map(void)
> > > > +{
> > > > + if (!efi_setup)
> > > > + return;
> > > > +
> > > > + nr_efi_runtime_map = (efi_data_len - sizeof(struct
> > > > efi_setup_data)) /
> > > > +sizeof(efi_memory_desc_t);
> > > > +}
> > >
> > > Do we actually need the 'map' entry in efi_setup_data now that you're
> > > passing it via efi_info (which is much better approach!)? Also, we don't
> > > need the global nr_efi_runtime_map or efi_runtime_map variables now,
> > > right?
> >
> > The map is still necessary because we need store the map somewhere and pass
> > the physicall address to kexec kernel. Passing them in setup_data is the
> > only better way currently...
> >
> > In efi_info there's only an entry for the map physical address, the original
> > map area is not valid any more.
>
> Where do you dereference efi_setup_data.map* in the kexec kernel?
The field itself is not dereferenced in kernel but it's still used in userspace
code for collecting and saving runtime maps. Since I still append the map at the
end of efi_setup_data so I think keep the map[0] is ok. What's your opinion?
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup
On 12/20/2013 08:36 PM, Davidlohr Bueso wrote: On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote: On Thu, Dec 19, 2013 at 10:45 AM, Davidlohr Bueso wrote: - increment the counter at queue_lock() as we always end up calling queue_me() which adds the element to the list. Upon any error, queue_unlock() is called for housekeeping, for which we decrement to mach the increment done in queue_lock(). - decrement the counter at __unqueue_me() to reflect when an element is removed from the queue for wakeup related purposes. I still hate this whole separate counter thing. It seems really annoying. If re-ordering things didn't work out, then why can't just the counter we *already* have in the spinlock itself work as the counter? Your counter update logic seems to basically match when you take the spinlock anyway. So the following has passed all testing, just like the atomics variant. Thoughts? Thanks, Davidlohr diff --git a/kernel/futex.c b/kernel/futex.c index fcc6850..c8c7ce5 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -73,19 +73,22 @@ * Basic futex operation and ordering guarantees: * * The waiter reads the futex value in user space and calls - * futex_wait(). This function computes the hash bucket and acquires - * the hash bucket lock. After that it reads the futex user space value - * again and verifies that the data has not changed. If it has not - * changed it enqueues itself into the hash bucket, releases the hash + * futex_wait(). It computes the hash bucket and acquires the hash + * bucket lock. After that it reads the futex user space value again + * and verifies that the data has not changed. If it has not changed + * it enqueues itself into the hash bucket, releases the hash * bucket lock and schedules. * * The waker side modifies the user space value of the futex and calls - * futex_wake(). This functions computes the hash bucket and acquires - * the hash bucket lock. Then it looks for waiters on that futex in the - * hash bucket and wakes them. + * futex_wake(). It computes the hash bucket and acquires the hash + * bucket lock. Then it looks for waiters on that futex in the hash + * bucket and wakes them. * - * Note that the spin_lock serializes waiters and wakers, so that the - * following scenario is avoided: + * In scenarios where wakeups are called and no tasks are blocked on a futex, + * taking the hb spinlock can be avoided and simply return. In order for this + * optimization to work, ordering guarantees must exist so that the waiter + * being added to the list is acknowledged when the list is concurrently being + * checked by the waker, avoiding scenarios like the following: * * CPU 0 CPU 1 * val = *futex; @@ -106,24 +109,50 @@ * This would cause the waiter on CPU 0 to wait forever because it * missed the transition of the user space value from val to newval * and the waker did not find the waiter in the hash bucket queue. - * The spinlock serializes that: + * + * The correct serialization ensures that a waiter either observes + * the changed user space value before blocking or is woken by a + * concurrent waker: * * CPU 0 CPU 1 * val = *futex; * sys_futex(WAIT, futex, val); * futex_wait(futex, val); - * lock(hash_bucket(futex)); - * uval = *futex; - * *futex = newval; - * sys_futex(WAKE, futex); - * futex_wake(futex); - * lock(hash_bucket(futex)); + * + * waiters++; + * mb(); (A)<-- paired with -. + * | + * lock(hash_bucket(futex)); | + * | + * uval = *futex; | + * |*futex = newval; + * |sys_futex(WAKE, futex); + * | futex_wake(futex); + * | + * `--->mb(); (B) Checking the state of the spinlock counter isn't the same as incrementing a waiter count. So your pseudo code here is misleading. See further explanation below. * if (uval == val) - * queue(); + * queue(); * unlock(hash_bucket(futex)); - * schedule(); if (!queue_empty()) - * wake_waiters(futex); - * unlock(hash_bucket(futex)); + * schedule(); if (waiters) + * lock(hash_bucket(futex)); + * wake_waiters(futex); + * unlock(hash_bucket(futex)); + * + * Where (A) orders the waiters increment and the futex value read -- this + * is guaranteed by the head counter in the hb spinlock; and where (B) + * orders the
Re: [PATCH] rcu: Eliminate softirq processing from rcutree
On Tue, 2013-12-24 at 11:36 -0800, Paul E. McKenney wrote: > On Mon, Dec 23, 2013 at 05:38:53AM +0100, Mike Galbraith wrote: > > On Sun, 2013-12-22 at 09:57 +0100, Mike Galbraith wrote: > > > I'll let the box give > > > RCU something to do for a couple days. No news is good news. > > > > Ho ho hum, merry christmas, gift attached. > > Hmmm... I guess I should take a moment to work out who has been > naughty and nice... > > > I'll beat on virgin -rt7, see if it survives, then re-apply RCU patch > > and retest. This kernel had nohz_full enabled, along with Sebastian's > > pending -rt fix for same, so RCU patch was not only not running solo, > > box was running a known somewhat buggy config as well. Box was doing > > endless tbench 64 when it started stalling fwiw. > > [72788.040872] NMI backtrace for cpu 31 > [72788.040874] CPU: 31 PID: 13975 Comm: tbench Tainted: GW > 3.12.6-rt7-nohz #192 > [72788.040874] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 > 07/07/2010 > [72788.040875] task: 8802728e3db0 ti: 88026deb2000 task.ti: > 88026deb2000 > [72788.040877] RIP: 0010:[] [] > _raw_spin_trylock+0x14/0x80 > [72788.040878] RSP: 0018:8802769e3e58 EFLAGS: 0002 > [72788.040879] RAX: 88026deb3fd8 RBX: 880273544000 RCX: > 7bc87bc6 > [72788.040879] RDX: RSI: 8802728e3db0 RDI: > 880273544000 > [72788.040880] RBP: 88026deb39f8 R08: 063c14effd0f R09: > 0119 > [72788.040881] R10: 0005 R11: 8802769f2260 R12: > 8802728e3db0 > [72788.040881] R13: 001f R14: 8802769ebcc0 R15: > 810c4730 > [72788.040883] FS: 7f7cd380a700() GS:8802769e() > knlGS: > [72788.040883] CS: 0010 DS: ES: CR0: 80050033 > [72788.040884] CR2: 0068a0e8 CR3: 000267ba4000 CR4: > 07e0 > [72788.040885] Stack: > [72788.040886] 88026deb39f8 815e2aa0 > 8106711a > [72788.040887] 8802769ec4e0 8802769ec4e0 8802769e3f58 > 810c44bd > [72788.040888] 88026deb39f8 88026deb39f8 15ed4f5ff89b > 810c476e > [72788.040889] Call Trace: > [72788.040889] > [72788.040891] [] ? rt_spin_lock_slowunlock_hirq+0x10/0x20 > [72788.040893] [] ? update_process_times+0x3a/0x60 > [72788.040895] [] ? tick_sched_handle+0x2d/0x70 > [72788.040896] [] ? tick_sched_timer+0x3e/0x70 > [72788.040898] [] ? __run_hrtimer+0x13d/0x260 > [72788.040900] [] ? hrtimer_interrupt+0x12c/0x310 > [72788.040901] [] ? vtime_account_system+0x4e/0xf0 > [72788.040903] [] ? smp_apic_timer_interrupt+0x36/0x50 > [72788.040904] [] ? apic_timer_interrupt+0x6d/0x80 > [72788.040905] > [72788.040906] [] ? _raw_spin_lock+0x2a/0x40 > [72788.040908] [] ? rt_spin_lock_slowlock+0x33/0x2d0 > [72788.040910] [] ? migrate_enable+0xc4/0x220 > [72788.040911] [] ? ip_finish_output+0x258/0x450 > [72788.040913] [] ? lock_timer_base+0x41/0x80 > [72788.040914] [] ? mod_timer+0x66/0x290 > [72788.040916] [] ? sk_reset_timer+0xf/0x20 > [72788.040917] [] ? tcp_write_xmit+0x1cf/0x5d0 > [72788.040919] [] ? __tcp_push_pending_frames+0x25/0x60 > [72788.040921] [] ? tcp_sendmsg+0x114/0xbb0 > [72788.040923] [] ? sock_sendmsg+0xaf/0xf0 > [72788.040925] [] ? touch_atime+0x65/0x150 > [72788.040927] [] ? SyS_sendto+0x118/0x190 > [72788.040929] [] ? vtime_account_user+0x66/0x100 > [72788.040930] [] ? syscall_trace_enter+0x2a/0x260 > [72788.040932] [] ? tracesys+0xdd/0xe2 > > The most likely suspect is the rt_spin_lock_slowlock() that is apparently > being acquired by migrate_enable(). This could be due to: > > 1.Massive contention on that lock. > > 2.Someone else holding that lock for excessive time periods. > Evidence in favor: CPU 0 appears to be running within > migrate_enable(). But isn't migrate_enable() really quite > lightweight? > > 3.Possible looping in the networking stack -- but this seems > unlikely given that we appear to have caught a lock acquisition > in the act. (Not impossible, however, if there are lots of > migrate_enable() calls in the networking stack, which there > are due to all the per-CPU work.) > > So which code do you think deserves the big lump of coal? ;-) Sebastian's NO_HZ_FULL locking fixes. Locking is hard, and rt sure doesn't make it any easier, so lets give him a cookie or three to nibble on while he ponders that trylock stuff again instead :) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: fsl_sai: Add disable operation for the corresponding data channel.
Enables/Disables the corresponding data channel for tx/rx operation.
A channel must be enabled before its FIFO is accessed, and then disable
it when tx/rx is stopped or idle.
Signed-off-by: Xiubo Li
---
sound/soc/fsl/fsl_sai.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 596aabb..af80246 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -124,20 +124,17 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
unsigned int fmt, int fsl_dir)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- u32 val_cr2, val_cr3, val_cr4, reg_cr2, reg_cr3, reg_cr4;
+ u32 val_cr2, val_cr4, reg_cr2, reg_cr4;
if (fsl_dir == FSL_FMT_TRANSMITTER) {
reg_cr2 = FSL_SAI_TCR2;
- reg_cr3 = FSL_SAI_TCR3;
reg_cr4 = FSL_SAI_TCR4;
} else {
reg_cr2 = FSL_SAI_RCR2;
- reg_cr3 = FSL_SAI_RCR3;
reg_cr4 = FSL_SAI_RCR4;
}
val_cr2 = sai_readl(sai, sai->base + reg_cr2);
- val_cr3 = sai_readl(sai, sai->base + reg_cr3);
val_cr4 = sai_readl(sai, sai->base + reg_cr4);
if (sai->big_endian_data)
@@ -188,13 +185,10 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
return -EINVAL;
}
- val_cr3 |= FSL_SAI_CR3_TRCE;
-
if (fsl_dir == FSL_FMT_RECEIVER)
val_cr2 |= FSL_SAI_CR2_SYNC;
sai_writel(sai, val_cr2, sai->base + reg_cr2);
- sai_writel(sai, val_cr3, sai->base + reg_cr3);
sai_writel(sai, val_cr4, sai->base + reg_cr4);
return 0;
@@ -278,7 +272,7 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
struct snd_soc_dai *cpu_dai)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- unsigned int tcsr, rcsr;
+ u32 tcsr, rcsr, val_cr3, reg_cr3;
tcsr = sai_readl(sai, sai->base + FSL_SAI_TCSR);
rcsr = sai_readl(sai, sai->base + FSL_SAI_RCSR);
@@ -286,17 +280,24 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
tcsr |= FSL_SAI_CSR_FRDE;
rcsr &= ~FSL_SAI_CSR_FRDE;
+ reg_cr3 = FSL_SAI_TCR3;
} else {
rcsr |= FSL_SAI_CSR_FRDE;
tcsr &= ~FSL_SAI_CSR_FRDE;
+ reg_cr3 = FSL_SAI_RCR3;
}
+ val_cr3 = sai_readl(sai, sai->base + reg_cr3);
+
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
tcsr |= FSL_SAI_CSR_TERE;
rcsr |= FSL_SAI_CSR_TERE;
+ val_cr3 |= FSL_SAI_CR3_TRCE;
+
+ sai_writel(sai, val_cr3, sai->base + reg_cr3);
sai_writel(sai, rcsr, sai->base + FSL_SAI_RCSR);
sai_writel(sai, tcsr, sai->base + FSL_SAI_TCSR);
break;
@@ -308,8 +309,12 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
tcsr &= ~FSL_SAI_CSR_TERE;
rcsr &= ~FSL_SAI_CSR_TERE;
}
+
+ val_cr3 &= ~FSL_SAI_CR3_TRCE;
+
sai_writel(sai, tcsr, sai->base + FSL_SAI_TCSR);
sai_writel(sai, rcsr, sai->base + FSL_SAI_RCSR);
+ sai_writel(sai, val_cr3, sai->base + reg_cr3);
break;
default:
return -EINVAL;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: fsl_sai: Move the global registers setting to _dai_probe()
Because we cannot make sure which one of _dai_fmt() and _dai_sysclk()
will be firstly called. So move the RCSR/TCSR and TCR1/RCR1's
initialization to _dai_probe(), and this can make sure that before any
of {T,R}CR{1~5} register to be set the RCSR/TCSR's RE/TE bit has been
cleared for the hareware limitation.
Signed-off-by: Xiubo Li
---
sound/soc/fsl/fsl_sai.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index b72132f..596aabb 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -100,11 +100,6 @@ static int fsl_sai_set_dai_sysclk(struct snd_soc_dai
*cpu_dai,
if (ret)
return ret;
- sai_writel(sai, 0x0, sai->base + FSL_SAI_RCSR);
- sai_writel(sai, 0x0, sai->base + FSL_SAI_TCSR);
- sai_writel(sai, FSL_SAI_MAXBURST_TX * 2, sai->base + FSL_SAI_TCR1);
- sai_writel(sai, FSL_SAI_MAXBURST_RX - 1, sai->base + FSL_SAI_RCR1);
-
ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
FSL_FMT_TRANSMITTER);
if (ret) {
@@ -351,6 +346,18 @@ static const struct snd_soc_dai_ops fsl_sai_pcm_dai_ops = {
static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
{
struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
+ int ret;
+
+ ret = clk_prepare_enable(sai->clk);
+ if (ret)
+ return ret;
+
+ sai_writel(sai, 0x0, sai->base + FSL_SAI_RCSR);
+ sai_writel(sai, 0x0, sai->base + FSL_SAI_TCSR);
+ sai_writel(sai, FSL_SAI_MAXBURST_TX * 2, sai->base + FSL_SAI_TCR1);
+ sai_writel(sai, FSL_SAI_MAXBURST_RX - 1, sai->base + FSL_SAI_RCR1);
+
+ clk_disable_unprepare(sai->clk);
snd_soc_dai_init_dma_data(cpu_dai, >dma_params_tx,
>dma_params_rx);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Add tests for function pointer style misuses
Kernel style uses function pointers in this form:
"type (*funcptr)(args...)"
Emit warnings when this function pointer form isn't used.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 59 +++
1 file changed, 59 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0fcbc5f..f5d4560 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2810,6 +2810,65 @@ sub process {
}
}
+# Function pointer declarations
+# check spacing between type, funcptr, and args
+# canonical declaration is "type (*funcptr)(args...)"
+#
+# the $Declare variable will capture all spaces after the type
+# so check it for trailing missing spaces or multiple spaces
+ if ($line =~
/^.\s*($Declare)\((\s*)\*(\s*)$Ident(\s*)\)(\s*)\(/) {
+ my $declare = $1;
+ my $pre_pointer_space = $2;
+ my $post_pointer_space = $3;
+ my $funcname = $4;
+ my $post_funcname_space = $5;
+ my $pre_args_space = $6;
+
+ if ($declare !~ /\s$/) {
+ WARN("SPACING",
+"missing space after return type\n" .
$herecurr);
+ }
+
+# unnecessary space "type (*funcptr)(args...)"
+ elsif ($declare =~ /\s{2,}$/) {
+ WARN("SPACING",
+"Multiple spaces after return type\n" .
$herecurr);
+ }
+
+# unnecessary space "type ( *funcptr)(args...)"
+ if (defined $pre_pointer_space &&
+ $pre_pointer_space =~ /^\s/) {
+ WARN("SPACING",
+"Unnecessary space after function pointer
open parenthesis\n" . $herecurr);
+ }
+
+# unnecessary space "type (* funcptr)(args...)"
+ if (defined $post_pointer_space &&
+ $post_pointer_space =~ /^\s/) {
+ WARN("SPACING",
+"Unnecessary space before function pointer
name\n" . $herecurr);
+ }
+
+# unnecessary space "type (*funcptr )(args...)"
+ if (defined $post_funcname_space &&
+ $post_funcname_space =~ /^\s/) {
+ WARN("SPACING",
+"Unnecessary space after function pointer
name\n" . $herecurr);
+ }
+
+# unnecessary space "type (*funcptr) (args...)"
+ if (defined $pre_args_space &&
+ $pre_args_space =~ /^\s/) {
+ WARN("SPACING",
+"Unnecessary space before function pointer
arguments\n" . $herecurr);
+ }
+
+ if (show_type("SPACING") && $fix) {
+ $fixed[$linenr - 1] =~
+
s/^(.\s*$Declare)\(\s*\*\s*($Ident)\s*\)\s*\(/rtrim($1) . " " . "\(\*$2\)\("/ex;
+ }
+ }
+
# check for spacing round square brackets; allowed:
# 1. with a type on the left -- int [] a;
# 2. at the beginning of a line for slice initialisers -- [0...10] = 5,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 12/19] isdn: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Karsten Keil
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Yang Yingliang
Signed-off-by: Ding Tianhong
---
drivers/isdn/i4l/isdn_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/i4l/isdn_net.c b/drivers/isdn/i4l/isdn_net.c
index 8b98d53..d9aebbc 100644
--- a/drivers/isdn/i4l/isdn_net.c
+++ b/drivers/isdn/i4l/isdn_net.c
@@ -1371,7 +1371,7 @@ isdn_net_type_trans(struct sk_buff *skb, struct
net_device *dev)
eth = eth_hdr(skb);
if (*eth->h_dest & 1) {
- if (memcmp(eth->h_dest, dev->broadcast, ETH_ALEN) == 0)
+ if (ether_addr_equal(eth->h_dest, dev->broadcast))
skb->pkt_type = PACKET_BROADCAST;
else
skb->pkt_type = PACKET_MULTICAST;
@@ -1382,7 +1382,7 @@ isdn_net_type_trans(struct sk_buff *skb, struct
net_device *dev)
*/
else if (dev->flags & (IFF_PROMISC /*| IFF_ALLMULTI*/)) {
- if (memcmp(eth->h_dest, dev->dev_addr, ETH_ALEN))
+ if (!ether_addr_equal(eth->h_dest, dev->dev_addr))
skb->pkt_type = PACKET_OTHERHOST;
}
if (ntohs(eth->h_proto) >= ETH_P_802_3_MIN)
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/20] net: pcnet: slight optimization of addr compare
On 2013/12/25 1:59, David Miller wrote: > From: Ding Tianhong > Date: Tue, 24 Dec 2013 21:47:30 +0800 > >> Oh， no, maybe I was dizzy by these patches, I should be more careful, >> sorry about that, I will resend this one. > > You must resend the entire patch series when you make any changes. > > Thank you. > > ok -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use __kernel_long_t in struct timex
X32 adjtimex system call is the same as x86-64 adjtimex system call,
which uses 64-bit integer for long in struct timex. But x32 long is
32 bit. This patch replaces long in struct timex with __kernel_long_t.
Signed-off-by: H.J. Lu
---
include/uapi/linux/timex.h | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
index a7ea81f..92685d8 100644
--- a/include/uapi/linux/timex.h
+++ b/include/uapi/linux/timex.h
@@ -63,27 +63,27 @@
*/
struct timex {
unsigned int modes; /* mode selector */
- long offset;/* time offset (usec) */
- long freq; /* frequency offset (scaled ppm) */
- long maxerror; /* maximum error (usec) */
- long esterror; /* estimated error (usec) */
+ __kernel_long_t offset; /* time offset (usec) */
+ __kernel_long_t freq; /* frequency offset (scaled ppm) */
+ __kernel_long_t maxerror;/* maximum error (usec) */
+ __kernel_long_t esterror;/* estimated error (usec) */
int status; /* clock command/status */
- long constant; /* pll time constant */
- long precision; /* clock precision (usec) (read only) */
- long tolerance; /* clock frequency tolerance (ppm)
-* (read only)
-*/
+ __kernel_long_t constant;/* pll time constant */
+ __kernel_long_t precision;/* clock precision (usec) (read only) */
+ __kernel_long_t tolerance;/* clock frequency tolerance (ppm)
+ * (read only)
+ */
struct timeval time;/* (read only, except for ADJ_SETOFFSET) */
- long tick; /* (modified) usecs between clock ticks */
+ __kernel_long_t tick; /* (modified) usecs between clock ticks */
- long ppsfreq; /* pps frequency (scaled ppm) (ro) */
- long jitter;/* pps jitter (us) (ro) */
+ __kernel_long_t ppsfreq;/* pps frequency (scaled ppm) (ro) */
+ __kernel_long_t jitter; /* pps jitter (us) (ro) */
int shift; /* interval duration (s) (shift) (ro) */
- long stabil;/* pps stability (scaled ppm) (ro) */
- long jitcnt;/* jitter limit exceeded (ro) */
- long calcnt;/* calibration intervals (ro) */
- long errcnt;/* calibration errors (ro) */
- long stbcnt;/* stability limit exceeded (ro) */
+ __kernel_long_t stabil;/* pps stability (scaled ppm) (ro) */
+ __kernel_long_t jitcnt; /* jitter limit exceeded (ro) */
+ __kernel_long_t calcnt; /* calibration intervals (ro) */
+ __kernel_long_t errcnt; /* calibration errors (ro) */
+ __kernel_long_t stbcnt; /* stability limit exceeded (ro) */
int tai;/* TAI offset (ro) */
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] regulator: act8865: Remove unneeded regulator_unregister() calls
This is not required because current code uses devm_regulator_register() to
register regulators.
Signed-off-by: Axel Lin
---
v2: Fix typo in subject line s/Rmove/Remove/
drivers/regulator/act8865-regulator.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index db048f2..dfae294 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -334,17 +334,6 @@ static int act8865_pmic_probe(struct i2c_client *client,
return 0;
}
-static int act8865_pmic_remove(struct i2c_client *client)
-{
- struct act8865 *act8865 = i2c_get_clientdata(client);
- int i;
-
- for (i = 0; i < ACT8865_REG_NUM; i++)
- regulator_unregister(act8865->rdev[i]);
-
- return 0;
-}
-
static const struct i2c_device_id act8865_ids[] = {
{ "act8865", 0 },
{ },
@@ -357,7 +346,6 @@ static struct i2c_driver act8865_pmic_driver = {
.owner = THIS_MODULE,
},
.probe = act8865_pmic_probe,
- .remove = act8865_pmic_remove,
.id_table = act8865_ids,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] drivers: firmware: edd: fixed coding style errors.
Fixed coding style errors. Fixed spacing, tab and parenthesis errors.
Signed-off-by: Derek Perrin
---
Changes since v1:
*cleaned up all checkpatch.pl errors
*changed function pointer prototype to preferred style from Joe Perches
*fixed edd_device *edev assignment in if condition
drivers/firmware/edd.c | 63 +-
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
index e229576..0e93659 100644
--- a/drivers/firmware/edd.c
+++ b/drivers/firmware/edd.c
@@ -62,8 +62,8 @@ struct edd_device {
struct edd_attribute {
struct attribute attr;
- ssize_t(*show) (struct edd_device * edev, char *buf);
- int (*test) (struct edd_device * edev);
+ ssize_t(*show)(struct edd_device *edev, char *buf);
+ int (*test)(struct edd_device *edev);
};
/* forward declarations */
@@ -72,7 +72,7 @@ static struct pci_dev *edd_get_pci_dev(struct edd_device
*edev);
static struct edd_device *edd_devices[EDD_MBR_SIG_MAX];
-#define EDD_DEVICE_ATTR(_name,_mode,_show,_test) \
+#define EDD_DEVICE_ATTR(_name, _mode, _show, _test) \
struct edd_attribute edd_attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.show = _show,\
@@ -107,11 +107,11 @@ edd_dev_set_info(struct edd_device *edev, int i)
edev->info = _info[i];
}
-#define to_edd_attr(_attr) container_of(_attr,struct edd_attribute,attr)
-#define to_edd_device(obj) container_of(obj,struct edd_device,kobj)
+#define to_edd_attr(_attr) container_of(_attr, struct edd_attribute, attr)
+#define to_edd_device(obj) container_of(obj, struct edd_device, kobj)
static ssize_t
-edd_attr_show(struct kobject * kobj, struct attribute *attr, char *buf)
+edd_attr_show(struct kobject *kobj, struct attribute *attr, char *buf)
{
struct edd_device *dev = to_edd_device(kobj);
struct edd_attribute *edd_attr = to_edd_attr(attr);
@@ -169,7 +169,7 @@ edd_show_host_bus(struct edd_device *edev, char *buf)
p += scnprintf(p, left, "\tunknown: %llx\n",
info->params.interface_path.unknown.reserved);
}
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -228,7 +228,7 @@ edd_show_interface(struct edd_device *edev, char *buf)
info->params.device_path.unknown.reserved2);
}
- return (p - buf);
+ return p - buf;
}
/**
@@ -272,7 +272,7 @@ edd_show_version(struct edd_device *edev, char *buf)
return -EINVAL;
p += scnprintf(p, left, "0x%02x\n", info->version);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -280,7 +280,7 @@ edd_show_mbr_signature(struct edd_device *edev, char *buf)
{
char *p = buf;
p += scnprintf(p, left, "0x%08x\n", edev->mbr_signature);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -306,7 +306,7 @@ edd_show_extensions(struct edd_device *edev, char *buf)
if (info->interface_support & EDD_EXT_64BIT_EXTENSIONS) {
p += scnprintf(p, left, "64-bit extensions\n");
}
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -336,7 +336,7 @@ edd_show_info_flags(struct edd_device *edev, char *buf)
p += scnprintf(p, left, "no media present\n");
if (info->params.info_flags & EDD_INFO_USE_INT13_FN50)
p += scnprintf(p, left, "use int13 fn50\n");
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -351,7 +351,7 @@ edd_show_legacy_max_cylinder(struct edd_device *edev, char
*buf)
return -EINVAL;
p += snprintf(p, left, "%u\n", info->legacy_max_cylinder);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -366,7 +366,7 @@ edd_show_legacy_max_head(struct edd_device *edev, char *buf)
return -EINVAL;
p += snprintf(p, left, "%u\n", info->legacy_max_head);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -381,7 +381,7 @@ edd_show_legacy_sectors_per_track(struct edd_device *edev,
char *buf)
return -EINVAL;
p += snprintf(p, left, "%u\n", info->legacy_sectors_per_track);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -396,7 +396,7 @@ edd_show_default_cylinders(struct edd_device *edev, char
*buf)
return -EINVAL;
p += scnprintf(p, left, "%u\n", info->params.num_default_cylinders);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -411,7 +411,7 @@ edd_show_default_heads(struct edd_device *edev, char *buf)
return -EINVAL;
p += scnprintf(p, left, "%u\n", info->params.num_default_heads);
- return (p - buf);
+ return p - buf;
}
static ssize_t
@@ -426,7 +426,7 @@ edd_show_default_sectors_per_track(struct
Re: [GIT PULL] libata fixes for v3.13-rc5
On Tue, 24 Dec 2013, Tejun Heo wrote: > Hello, Linus. > > libata fixes for v3.13-rc5. There's one interseting commit - "libata, > freezer: avoid block device removal while system is frozen". It's an > ugly hack working around a deadlock condition between driver core > resume and block layer device removal paths through freezer which was > made more reproducible by writeback being converted to workqueue some > releases ago. The bug has nothing to do with libata but it's just an > workaround which is easy to backport. After discussion, Rafael and I > seem to agree that we don't really need kernel freezables - both > kthread and workqueue. There are few specific workqueues which > constitute PM operations and require freezing, which will be converted > to use workqueue_set_max_active() instead. All other kernel freezer > uses are planned to be removed, followed by the removal of kthread and > workqueue freezer support, hopefully. Wait a minute. I don't recall anybody mentioning this earlier. What about khubd? There isn't any plan to remove _it_. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb/core: fix NULL pointer dereference in recursively_mark_NOTATTACHED
On Tue, 24 Dec 2013, Du, ChangbinX wrote: > > > usb_hub_to_struct_hub() can return NULL if the hub without active > > > configuration. So the result must be checked. > > > > > > BUG: unable to handle kernel NULL pointer dereference at 015c > > > How did you manage to trigger this BUG? If hub is NULL then > > udev->maxchild should be 0. See the code in hub_disconnect(). > > > > Alan Stern > > Hello, Alan. The hub also should be null if actconfig is null. You can see it > in function > usb_hub_to_struct_hub(). Yes, I know. But if actconfig is NULL then udev->maxchild should be 0. > udev->maxchild will be set to 0 in hub_disconnect(). Note that hub_disconnect() runs _before_ actconfig is set to NULL. > But before that, > recursively_mark_NOTATTACHED may be called when calling usb_disconnect(). If this happens before hub_disconnect() has run then actconfig cannot be NULL, because hub_disconnect() runs _before_ actconfig is set to NULL. > So this issue > will happen when usb_disconnect a hub that not have a configuration yet. No, it won't. You can test this easily. Plug in a hub, write 0 to its /sys/bus/usb/devices/.../bConfigurationValue, and then unplug the hub. > It happened once here when unplugging otg cable from DUT(will cause hcd > removed) with > tiers of hub and devices. But it's not easy to reproduce it. > This is my analysis, how do you think? There is another reason why usb_hub_to_struct_hub() could return NULL: if usb_get_intfdata(hdev->actconfig->interface[0]) is NULL. This could happen if recursively_mark_NOTATTACHED() is called _while_ hub_disconnect() is running. There should be locking to prevent this, but there isn't. That's what we need to fix. It's not an easy problem. Can you figure out a correct solution? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] auxvec.h: account for AT_HWCAP2 in AT_VECTOR_SIZE_BASE
On 23.12.2013 [17:37:00 -0800], Linus Torvalds wrote: > Please cc the guilty parties when sending patches like this. > > Also, just out of interest, please describe how this bug affected > things. Did we overflow the saved_auxv[] array, or what? Also, how > does this change affect architectures that _don't_ have that > ELF_HWCAP2 thing, ie everything but powerpc? > > Acks, people? Acked-by: Nishanth Aravamudan I agree with Mikey that a comment might be useful. Thanks for the fix and sorry for the mistake! -Nish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] speeding up the stat() family of system calls...
* Linus Torvalds wrote: > Here's both x86 people and filesystem people involved, because this > hacky RFC patch touches both. > > NOTE NOTE NOTE! I've modified "cp_new_stat()" in place, in a way that > is x86-64 specific. So the attached patch *only* works on x86-64, and > will very actively break on anything else. That's intentional, because > that way it's more obvious how the code changes, but a real patch > would create a *new* cp_new_stat() for x86-64, and conditionalize the > existing generic "cp_new_stat()" on not already having an > architecture-optimized one. > > Basically, under some filesystem loads, "stat()" and friends are the > most common ops (think tree traversal, but also things like git > verifying the index). And our "cp_new_stat()" function (which is the > common interface, ignoring 32-bit legacy stuff) is generic, but > actually pretty disgusting. It copies things to a temporary 'struct > stat' buffer on the kernel stack, and then uses copy_to_user() to copy > it to user space. The double copy is quite noticeable in profiles, and > it generates a big stack frame too. > > By doing an architecture-specific cp_new_stat() function, we can > improve on that. > > HOWEVER. On x86, doing an efficient field-at-a-time copy also requires > us to use put_user_try() and put_user_catch() in order to not have > tons of clac/stac instructions for the extended permission testing. > And the implementation of that was actually fairly non-optimal, so to > actually get the code I wanted, I had to change how that all worked > too, using "asm_volatile_goto()". > > Thus both x86 and FS people on the list. > > Comments? This would obviously be a 3.14 issue, I'm not suggesting > we'd do this now. I just want to lay the ground-work.. > > It's tested in the sense that "it works for me", and profiles look > nice, but.. Looks cool - it looks rather similar to the try/catch model Richard Henderson came up with many eons ago when we implemented the original exception mechanism for Linux, which IIRC we decided wasn't safe due to lack of compiler support. Now we have compiler support ... written by Richard Henderson ;-) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/12] kexec kernel efi runtime support
On Mon, 2013-12-23 at 07:36 +, Matt Fleming wrote: > On Sun, 22 Dec, at 02:27:01PM, Toshi Kani wrote: > > > > The kexec branch is missing the following change, which is required for > > fast reboot with multi-cpus. > > > >commit 279f1df915c3a6ed3075d98a849705bf53851f99 > >Author: Vivek Goyal > >Date: Tue Nov 26 10:25:28 2013 +0800 > > > >kexec: migrate to reboot cpu > > > > With this change added, I confirmed that the branch kernel works fine. > > I can't find that commit in Linus' tree. Where is it from? Dave's git tree for the patchset has this change. This change was accepted by Vivek, so I think it is in his tree. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3] Add ff-memless-next
On 12/23/13 14:46, Michal Malý wrote: > --- > Documentation/input/ff-memless-next.txt | 145 ++ > drivers/input/Kconfig | 12 + > drivers/input/Makefile | 2 + > drivers/input/ff-memless-next.c | 786 > > include/linux/input/ff-memless-next.h | 31 ++ > 5 files changed, 976 insertions(+) > create mode 100644 Documentation/input/ff-memless-next.txt > create mode 100644 drivers/input/ff-memless-next.c > create mode 100644 include/linux/input/ff-memless-next.h > > diff --git a/Documentation/input/ff-memless-next.txt > b/Documentation/input/ff-memless-next.txt > new file mode 100644 > index 000..00f893d > --- /dev/null > +++ b/Documentation/input/ff-memless-next.txt > @@ -0,0 +1,145 @@ > +"ff-memless-next" force feedback module for memoryless devices. > +By Michal Malý on 2013/12/21 > + > + > +1. Introduction > +~~~ > +This document describes basic working principles of the "ff-memless-next" driver (or module) > +and its purpose. This document also contains summary of "ff-memless-next" API a summary of the > +and brief instructions on how to use it to write a hardware-specific backend > +with "ff-memless-next". Some specifics of ff-memless-next that might be of > +interest for userspace developers are also discussed. > diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig > index a11ff74..893ab00 100644 > --- a/drivers/input/Kconfig > +++ b/drivers/input/Kconfig > @@ -77,6 +77,18 @@ config INPUT_MATRIXKMAP > To compile this driver as a module, choose M here: the > module will be called matrix-keymap. > > +config INPUT_FF_MEMLESS_NEXT > + tristate "New version of support for memoryless force feedback devices" > + help > + Say Y here if you want to enable support for various memoryless > + force feedback devices (as of now there is no hardware-specific > + driver that supports this) this). > + > + If unsure, say N. > + > + To compile this driver as a module, choose M here: the > + module will be called ff-memless-next. > + > comment "Userland interfaces" > > config INPUT_MOUSEDEV -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcu: Eliminate softirq processing from rcutree
On Mon, Dec 23, 2013 at 05:38:53AM +0100, Mike Galbraith wrote: > On Sun, 2013-12-22 at 09:57 +0100, Mike Galbraith wrote: > > I'll let the box give > > RCU something to do for a couple days. No news is good news. > > Ho ho hum, merry christmas, gift attached. Hmmm... I guess I should take a moment to work out who has been naughty and nice... > I'll beat on virgin -rt7, see if it survives, then re-apply RCU patch > and retest. This kernel had nohz_full enabled, along with Sebastian's > pending -rt fix for same, so RCU patch was not only not running solo, > box was running a known somewhat buggy config as well. Box was doing > endless tbench 64 when it started stalling fwiw. [72788.040872] NMI backtrace for cpu 31 [72788.040874] CPU: 31 PID: 13975 Comm: tbench Tainted: GW 3.12.6-rt7-nohz #192 [72788.040874] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 [72788.040875] task: 8802728e3db0 ti: 88026deb2000 task.ti: 88026deb2000 [72788.040877] RIP: 0010:[] [] _raw_spin_trylock+0x14/0x80 [72788.040878] RSP: 0018:8802769e3e58 EFLAGS: 0002 [72788.040879] RAX: 88026deb3fd8 RBX: 880273544000 RCX: 7bc87bc6 [72788.040879] RDX: RSI: 8802728e3db0 RDI: 880273544000 [72788.040880] RBP: 88026deb39f8 R08: 063c14effd0f R09: 0119 [72788.040881] R10: 0005 R11: 8802769f2260 R12: 8802728e3db0 [72788.040881] R13: 001f R14: 8802769ebcc0 R15: 810c4730 [72788.040883] FS: 7f7cd380a700() GS:8802769e() knlGS: [72788.040883] CS: 0010 DS: ES: CR0: 80050033 [72788.040884] CR2: 0068a0e8 CR3: 000267ba4000 CR4: 07e0 [72788.040885] Stack: [72788.040886] 88026deb39f8 815e2aa0 8106711a [72788.040887] 8802769ec4e0 8802769ec4e0 8802769e3f58 810c44bd [72788.040888] 88026deb39f8 88026deb39f8 15ed4f5ff89b 810c476e [72788.040889] Call Trace: [72788.040889] [72788.040891] [] ? rt_spin_lock_slowunlock_hirq+0x10/0x20 [72788.040893] [] ? update_process_times+0x3a/0x60 [72788.040895] [] ? tick_sched_handle+0x2d/0x70 [72788.040896] [] ? tick_sched_timer+0x3e/0x70 [72788.040898] [] ? __run_hrtimer+0x13d/0x260 [72788.040900] [] ? hrtimer_interrupt+0x12c/0x310 [72788.040901] [] ? vtime_account_system+0x4e/0xf0 [72788.040903] [] ? smp_apic_timer_interrupt+0x36/0x50 [72788.040904] [] ? apic_timer_interrupt+0x6d/0x80 [72788.040905] [72788.040906] [] ? _raw_spin_lock+0x2a/0x40 [72788.040908] [] ? rt_spin_lock_slowlock+0x33/0x2d0 [72788.040910] [] ? migrate_enable+0xc4/0x220 [72788.040911] [] ? ip_finish_output+0x258/0x450 [72788.040913] [] ? lock_timer_base+0x41/0x80 [72788.040914] [] ? mod_timer+0x66/0x290 [72788.040916] [] ? sk_reset_timer+0xf/0x20 [72788.040917] [] ? tcp_write_xmit+0x1cf/0x5d0 [72788.040919] [] ? __tcp_push_pending_frames+0x25/0x60 [72788.040921] [] ? tcp_sendmsg+0x114/0xbb0 [72788.040923] [] ? sock_sendmsg+0xaf/0xf0 [72788.040925] [] ? touch_atime+0x65/0x150 [72788.040927] [] ? SyS_sendto+0x118/0x190 [72788.040929] [] ? vtime_account_user+0x66/0x100 [72788.040930] [] ? syscall_trace_enter+0x2a/0x260 [72788.040932] [] ? tracesys+0xdd/0xe2 The most likely suspect is the rt_spin_lock_slowlock() that is apparently being acquired by migrate_enable(). This could be due to: 1. Massive contention on that lock. 2. Someone else holding that lock for excessive time periods. Evidence in favor: CPU 0 appears to be running within migrate_enable(). But isn't migrate_enable() really quite lightweight? 3. Possible looping in the networking stack -- but this seems unlikely given that we appear to have caught a lock acquisition in the act. (Not impossible, however, if there are lots of migrate_enable() calls in the networking stack, which there are due to all the per-CPU work.) So which code do you think deserves the big lump of coal? ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm: kernel BUG at include/linux/swapops.h:131!
On 12/24/2013 01:07 AM, Joonsoo Kim wrote: On Mon, Dec 23, 2013 at 10:01:10PM -0500, Sasha Levin wrote: On 12/23/2013 09:51 PM, Joonsoo Kim wrote: On Mon, Dec 23, 2013 at 12:24:02PM -0500, Sasha Levin wrote: Ping? I've also Cc'ed the "this page shouldn't be locked at all" team. Hello, I can't find the reason of this problem. If it is reproducible, how about bisecting? While it reproduces under fuzzing it's pretty hard to bisect it with the amount of issues uncovered by trinity recently. I can add any debug code to the site of the BUG if that helps. Good! It will be helpful to add dump_page() in migration_entry_to_page(). [ 3800.520039] page:ea245800 count:12 mapcount:4 mapping:88001d0c3668 index:0x7de [ 3800.521404] page flags: 0x1f8038003c(referenced|uptodate|dirty|lru|swapbacked|unevictable|mlocked) [ 3800.522585] pc:88001ed91600 pc->flags:2 pc->mem_cgroup:c9c0a000 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iio_utils.h bug?
"Zubair Lutfullah :" wrote:
>Hi,
>
>A guy posted this fix on my blog. I couldn't make sense of it.
>
>Thought I'd post it here. I'll send a proper patch file if
>I knew what commit log I needed to write.
>And I can't exactly sign-off :s.
Yes you can. Patch routed through you, hence your sign is entirely correct. If
you have an email address for the author then the from field can be different
from the sign-off and you can add a reported-by as well to credit it as fully
as possible.
Will be the weekend at least before I actually look at the code!
>
>I asked him to post but he couldn't/wouldn't.
>
>Regards
>ZubairLK
>
>
>"Defend against buffer overflow of ci_array:
>
> code always overwrites one entry beyond end of array, now fixed
>--Craig Markwardt"
>
>iio_utils.h
>
>@@ -335,6 +335,7 @@ inline int build_channel_array(const char
>*device_dir,
> while (ent = readdir(dp), ent != NULL) {
> if (strcmp(ent->d_name + strlen(ent->d_name) - strlen("_en"),
> "_en") == 0) {
>+ int current_enabled = 0;
> current = &(*ci_array)[count++];
> ret = asprintf(,
>"%s/%s", scan_el_dir, ent->d_name);
> if (ret < 0) {
> ret = -ENOMEM;
> /* decrement count to avoid freeing name */
> count--;
> goto error_cleanup_array;
> }
>
> sysfsfp = fopen(filename, "r");
>
> if (sysfsfp == NULL) {
> free(filename);
> ret = -errno;
> goto error_cleanup_array;
> }
>
>- fscanf(sysfsfp, "%u", >enabled);
>+ fscanf(sysfsfp, "%u", _enabled);
> fclose(sysfsfp);
>
>- if (!current->enabled) {
>+ if (!current_enabled) {
> free(filename);
> count--;
> continue;
> }
>+ current->enabled = current_enabled;
> current->scale = 1.0;
> current->offset = 0;
> current->name = strndup(ent->d_name,
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2][TRIVIAL] x86/smpboot: fix cpu bootup message
On Tue, Dec 24, 2013 at 2:35 AM, Borislav Petkov wrote:
> On Tue, Dec 24, 2013 at 09:09:02AM +0800, Xie XiuQi wrote:
>> On 2013/12/23 21:34, Borislav Petkov wrote:
>> > On Mon, Dec 23, 2013 at 04:33:00PM +0800, Xie XiuQi wrote:
>> >> When CPU0 and CPU1 aren't in same package, we got message
>> >> like this:
>> >>
>>
>> [...]
>>
>> >>
>> >> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> >> index 85dc05a..9e82c1e 100644
>> >> --- a/arch/x86/kernel/smpboot.c
>> >> +++ b/arch/x86/kernel/smpboot.c
>> >> @@ -639,7 +639,7 @@ static void announce_cpu(int cpu, int apicid)
>> >> {
>> >>static int current_node = -1;
>> >>int node = early_cpu_to_node(cpu);
>> >> - static int width, node_width;
>> >> + static int width, node_width, padding;
>> >>
>> >>if (!width)
>> >>width = num_digits(num_possible_cpus()) + 1; /* + '#' sign */
>> >> @@ -658,11 +658,13 @@ static void announce_cpu(int cpu, int apicid)
>> >>
>> >>printk(KERN_INFO " node %*s#%d, CPUs: ",
>> >> node_width - num_digits(node), " ", node);
>> >> - }
>> >>
>> >> - /* Add padding for the BSP */
>> >> - if (cpu == 1)
>> >> - pr_cont("%*s", width + 1, " ");
>> >> + /* Add padding for the BSP */
>> >> + if (!padding && (early_cpu_to_node(0) ==
>> >> current_node)) {
>> >
>> > You don't need "padding".
>> >
>>
>> On another machine, the configuration is:
>>
>> xiexiuqi@localhost:~> lscpu
>> [...]
>> NUMA node0 CPU(s): 4-7,12-15
>> NUMA node1 CPU(s): 0-3,8-11
>>
>> Without "padding", we'll get message like this:
>>
>> [0.349339] x86: Booting SMP configuration:
>> [0.353504] node #1, CPUs:#1 #2 #3
>> [0.398812] node #0, CPUs:#4 #5 #6 #7
>> [0.535186] node #1, CPUs:#8 #9 #10 #11
>> [0.594312] node #0, CPUs: #12 #13 #14 #15
>> [0.652398] x86: Booted up 2 nodes, 16 CPUs
>
> Geez, is that box generating the cores to nodes groups at random during
> each boot?!
>
> Gotta admire bios dudes' "inventiveness".
>
> Ok, so Ingo, I guess we can take this -v2 version for now - I need to
> think of a way on how to address all that nonsense properly.
>
> Acked-by: Borislav "luvz BIOS people" Petkov
No, should just take out lines of padding for BSP.
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/20] net: pcnet: slight optimization of addr compare
From: Ding Tianhong Date: Tue, 24 Dec 2013 21:47:30 +0800 > Oh， no, maybe I was dizzy by these patches, I should be more careful, > sorry about that, I will resend this one. You must resend the entire patch series when you make any changes. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tg3 and sd card reader at acer aspire
[+cc linux-pci because I think this is related to PCI ASPM] I'm afraid nobody wants to touch ASPM because it's such a mess, but I hope somebody will step up and investigate this. On Tue, Dec 24, 2013 at 1:27 AM, Vasiliy Tolstov wrote: > Hi all and sorry for may be spamming mailing list. > > I have acer aspire v5-17 with broadcom card reader and ethernet card. > I'm affecting on this ubuntu bugs. But bug is present in vanilla linux > current git and stable lts. > > Can somebody helps me and say - where i can post message and discuss > this problem. As i see ubuntu team can't solve this problem (bug > present is about 1 year and nothing changed). > One ubuntu user wia bisecting find broken commit - > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6cac12dfab9c57a4f76821412224b226a9b08dff > > Relevant ubuntu bugs: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178131 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1067222 > > > Thanks! > -- > Vasiliy Tolstov, > e-mail: v.tols...@selfip.ru > jabber: v...@selfip.ru > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote: Hi Kishon, On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I wrote: Hi Vivek, On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote: Hi, On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote: On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I wrote: On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote: Hi Kishon, On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I wrote: Hi, sorry for the delayed response. On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han wrote: [.] USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block. This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block and 2.0 block, respectively. Conclusion: 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device Base address: 0x1213 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device) Base address: 0x1210 2.0 block(UTMI+) & 3.0 block(PIPE3) And this is of course the PHY used by DWC3 controller, which works at both High speed as well as Super Speed. Right ? Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3 phy present in this PHY block ? AFAICS the two phys (UTMI+ and PIPE3) do not really have separate registers to program, and that's the reason we program the entire PHY in a shot. you mean you program the same set of bits for UTMI+ and PIPE3? No, looking closely into PHY datasheet as well as Exynos5250 manual, i can see that UTMI+ and PIPE3 phys have separate bit settings. So i think we should be able to segregate the two PHYs (UTMI+ and PIPE3). Pardon me for my earlier observations. no problem.. Let me clarify more with our h/w team also on this and then i will confirm with this. Did you get more information on this? Yes, i have been in contact with our hardware team. The functionality of setting up UTMI+ and PIPE3 phys separately, and thereby using only one functionality of the two at some point of time (either high speed or super speed) hasn't been tested so far. Irrespective of whether we are able to test the functionality separately or not, we should model it as multiple PHYs since you have separate bit settings for UTMI+ and PIPE3. (I'll review your next patch version shortly). Cheers Kishon So i will be looking into this and try to find out proper init sequences for the two available PHYs separately and as soon as i get a working solution for this, i will update. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: spinlock_irqsave() && flags (Was: pm80xx: Spinlock fix)
On Tue, 2013-12-24 at 09:13 +, Suresh Thiagarajan wrote:
>
> On Tue, Dec 24, 2013 at 1:59 PM, Ingo Molnar wrote:
> >
> > * Oleg Nesterov wrote:
> >
> >> On 12/23, Ingo Molnar wrote:
> >> >
> >> > * Oleg Nesterov wrote:
> >> >
> >> > > Initially I thought that this is obviously wrong, irqsave/irqrestore
> >> > > assume that "flags" is owned by the caller, not by the lock. And
> >> > > iirc this was certainly wrong in the past.
> >> > >
> >> > > But when I look at spinlock.c it seems that this code can actually
> >> > > work. _irqsave() writes to FLAGS after it takes the lock, and
> >> > > _irqrestore() has a copy of FLAGS before it drops this lock.
> >> >
> >> > I don't think that's true: if it was then the lock would not be
> >> > irqsave, a hardware-irq could come in after the lock has been taken
> >> > and before flags are saved+disabled.
> >>
> >> I do agree that this pattern is not safe, that is why I decided to ask.
> >>
> >> But, unless I missed something, with the current implementation
> >> spin_lock_irqsave(lock, global_flags) does:
> >>
> >> unsigned long local_flags;
> >>
> >> local_irq_save(local_flags);
> >> spin_lock(lock);
> >>
> >> global_flags = local_flags;
> >>
> >> so the access to global_flags is actually serialized by lock.
>
> Below is a small pseudo code on protecting/serializing the flag for global
> access.
> struct temp
> {
> ...
> spinlock_t lock;
> unsigned long lock_flags;
> };
> void my_lock(struct temp *t)
> {
>unsigned long flag; // thread-private variable as suggested
>spin_lock_irqsave(>lock, flag);
>t->lock_flags = flag; //updating inside critical section now
> to serialize the access to flag
> }
>
> void my_unlock(struct temp *t)
> {
>unsigned long flag = t->lock_flags;
>t->lock_flags = 0; //clearing it before getting out of
> critical section
>spin_unlock_irqrestore(>lock, flag);
> }
>
> Here for unlocking, I could even use spin_unlock_irqrestore(>lock,
> t->lock_flags) directly instead of my_unlock() since t->lock_flags is
> updated only in my_lock and so there is no need to explicitly clear
> t->lock_flags. Please let me know if I miss anything here in
> serializing the global lock flag.
I don't think anyone's arguing that you can't do this. The argument is
more you shouldn't: Lock contention is one of the biggest killers of
performance and getting locking right (avoiding inversions, or even
nested locks at all) is hard. Therefore you need to keep the shortest
and clearest critical sections in Linux that you can, so the pattern for
locking is to lock and unlock in the same routine with a local flags
variable.
So, rather than develop a primitive that supports and encourages uses of
locking that violate the pattern and is far more likely to cause
performance and other problems, could you just audit the code to see if
the need to carry a lock across a routine could be eliminated (either by
shortening the critical section or by better nesting the calls).
Thanks,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Final block fixes for 3.13
Hi Linus, A smallish collection of fixes destined for the 3.13 kernel. The pull request contains: - Fix for a memory leak on certain unplug events. - A collection of bcache fixes from Kent and Nicolas. - A few null_blk fixes and updates form Matias. - A marking of static of functions in the stec pci-e driver. Please pull! git://git.kernel.dk/linux-block.git for-linus Andrey Vagin (1): block: fix memory leaks on unplugging block device Jens Axboe (1): Merge branch 'bcache-for-3.13' of git://evilpiepirate.org/~kent/linux-bcache into for-linus Kent Overstreet (4): bcache: Use uninterruptible sleep in writeback bcache: Fix dirty_data accounting bcache: bugfix for race between moving_gc and bucket_invalidate bcache: New writeback PD controller Matias Bjorling (4): null_blk: mem garbage on NUMA systems during init null_blk: documentation null_blk: refactor init and init errors code paths null_blk: warning on ignored submit_queues param Matias Bjørling (3): null_blk: corrections to documentation null_blk: set use_per_node_hctx param to false null_blk: support submit_queues on use_per_node_hctx Nicholas Swenson (5): bcache: Fix for can_attach_cache() bcache: Fix heap_peek() macro bcache: fix for gc crashing when no sectors are used bcache: bugfix - moving_gc now moves only correct buckets bcache: fix for gc and writeback race Rashika Kheria (1): drivers: block: Mark the functions as static in skd_main.c Stefan Priebe (1): bcache: kthread don't set writeback task to INTERUPTIBLE Wei Yongjun (1): bcache: fix sparse non static symbol warning Documentation/block/null_blk.txt | 72 ++ block/blk-mq-sysfs.c | 13 + drivers/block/null_blk.c | 107 --- drivers/block/skd_main.c | 4 +- drivers/md/bcache/alloc.c| 2 + drivers/md/bcache/bcache.h | 12 ++--- drivers/md/bcache/btree.c| 27 +- drivers/md/bcache/movinggc.c | 21 +--- drivers/md/bcache/super.c| 2 +- drivers/md/bcache/sysfs.c| 50 ++ drivers/md/bcache/util.c | 8 ++- drivers/md/bcache/util.h | 2 +- drivers/md/bcache/writeback.c| 53 +-- 13 files changed, 275 insertions(+), 98 deletions(-) create mode 100644 Documentation/block/null_blk.txt -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
From: Nitesh A Jain
To: gre...@linuxfoundation.org
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org,
Nitesh A Jain
Subject: [PATCH] Staging: bcm: Bcmchar.c: fixed a space before semicolon coding
style issue
Date: Tue, 24 Dec 2013 22:51:14 +0530
Message-Id: <1387905674-27546-1-git-send-email-niteshjai...@gmail.com>
X-Mailer: git-send-email 1.8.5.1
Fixed a coding style issue
Signed-off-by: Nitesh A Jain
---
drivers/staging/bcm/Bcmchar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/bcm/Bcmchar.c b/drivers/staging/bcm/Bcmchar.c
index 87b74ca..25f910b03 100644
--- a/drivers/staging/bcm/Bcmchar.c
+++ b/drivers/staging/bcm/Bcmchar.c
@@ -1190,7 +1190,7 @@ cntrlEnd:
break;
case IOCTL_BCM_CAL_INIT: {
- UINT uiSectorSize = 0 ;
+ UINT uiSectorSize = 0;
if (Adapter->eNVMType == NVM_FLASH) {
if (copy_from_user(, argp, sizeof(struct
bcm_ioctl_buffer)))
return -EFAULT;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/20] ppp: slight optimization of addr compare
Hello.
On 24-12-2013 20:35, Joe Perches wrote:
[]
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
[]
@@ -131,12 +131,13 @@ static inline struct pppoe_net *pppoe_pernet(struct net
*net)
static inline int cmp_2_addr(struct pppoe_addr *a, struct pppoe_addr *b)
{
- return a->sid == b->sid && !memcmp(a->remote, b->remote, ETH_ALEN);
+ return a->sid == b->sid && ether_addr_equal(a->remote,
+ b->remote);
If it really doesn't fit insto single line, the continuation line should
start right under 'a->remote'.
Better still might be
return a->sid == b->sid &&
ether_addr_equal(a->remote, b->remote);
Actually, after the second look, I don't know why the line was broken at all.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.12.6-rt9
24.12.2013 19:47, Mike Galbraith пишет: > On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote: > crash> bt > PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16" YES!!! And ARM code broke :) -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 06/20] ppp: slight optimization of addr compare
On Tue, 2013-12-24 at 20:24 +0400, Sergei Shtylyov wrote:
> On 24-12-2013 15:28, Ding Tianhong wrote:
[]
> > diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
[]
> > @@ -131,12 +131,13 @@ static inline struct pppoe_net *pppoe_pernet(struct
> > net *net)
> >
> > static inline int cmp_2_addr(struct pppoe_addr *a, struct pppoe_addr *b)
> > {
> > - return a->sid == b->sid && !memcmp(a->remote, b->remote, ETH_ALEN);
> > + return a->sid == b->sid && ether_addr_equal(a->remote,
> > + b->remote);
>
> If it really doesn't fit insto single line, the continuation line should
> start right under 'a->remote'.
Better still might be
return a->sid == b->sid &&
ether_addr_equal(a->remote, b->remote);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] timerfd: show procfs fdinfo helper
| pos: 0
| flags:02004002
| clockid: 0
Cc: Thomas Gleixner
Cc: Alexander Viro
Signed-off-by: Shawn Landden
---
fs/timerfd.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index 9293121..e5fa587 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
struct timerfd_ctx {
union {
@@ -284,7 +285,23 @@ static ssize_t timerfd_read(struct file *file, char __user
*buf, size_t count,
return res;
}
+#ifdef CONFIG_PROC_FS
+static int timerfd_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct timerfd_ctx *ctx = f->private_data;
+ int clockid;
+
+ clockid = ctx->clockid;
+ seq_printf(m, "clockid:\t%d\n", clockid);
+
+ return 0;
+}
+#endif
+
static const struct file_operations timerfd_fops = {
+#ifdef CONFIG_PROC_FS
+ .show_fdinfo= timerfd_show_fdinfo,
+#endif
.release= timerfd_release,
.poll = timerfd_poll,
.read = timerfd_read,
--
1.8.5.2.297.g3e57c29
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/20] ppp: slight optimization of addr compare
Hello.
On 24-12-2013 15:28, Ding Tianhong wrote:
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Michal Ostrowski
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ding Tianhong
---
drivers/net/ppp/pppoe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 82ee6ed..1808a10 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -131,12 +131,13 @@ static inline struct pppoe_net *pppoe_pernet(struct net
*net)
static inline int cmp_2_addr(struct pppoe_addr *a, struct pppoe_addr *b)
{
- return a->sid == b->sid && !memcmp(a->remote, b->remote, ETH_ALEN);
+ return a->sid == b->sid && ether_addr_equal(a->remote,
+ b->remote);
If it really doesn't fit insto single line, the continuation line should
start right under 'a->remote'.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 v2] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
Because ixgbe driver limit the max number of VF functions could be enabled
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
v2: fix a typo.
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0ade0cd..47e9b44 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4818,7 +4818,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
#ifdef CONFIG_PCI_IOV
/* assign number of SR-IOV VFs */
if (hw->mac.type != ixgbe_mac_82598EB)
- adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
+ adapter->num_vfs = (max_vfs > IXGBE_MAX_VFS_DRV_LIMIT) ? 0 :
max_vfs;
#endif
/* enable itr by default in dynamic mode */
@@ -7640,7 +7640,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
ixgbe_init_mbx_params_pf(hw);
memcpy(>mbx.ops, ii->mbx_ops, sizeof(hw->mbx.ops));
ixgbe_enable_sriov(adapter);
- pci_sriov_set_totalvfs(pdev, 63);
+ pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT);
skip_sriov:
#endif
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 276d7b1..6925979 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -152,7 +152,8 @@ void ixgbe_enable_sriov(struct ixgbe_adapter *adapter)
* physical function. If the user requests greater thn
* 63 VFs then it is an error - reset to default of zero.
*/
- adapter->num_vfs = min_t(unsigned int, adapter->num_vfs, 63);
+ adapter->num_vfs = min_t(unsigned int,
+ adapter->num_vfs,
IXGBE_MAX_VFS_DRV_LIMIT);
err = pci_enable_sriov(adapter->pdev, adapter->num_vfs);
if (err) {
@@ -259,7 +260,7 @@ static int ixgbe_pci_sriov_enable(struct pci_dev *dev, int
num_vfs)
* PF. The PCI bus driver already checks for other values out of
* range.
*/
- if (num_vfs > 63) {
+ if (num_vfs > IXGBE_MAX_VFS_DRV_LIMIT) {
err = -EPERM;
goto err_out;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4713f9f..2593666 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -28,6 +28,11 @@
#ifndef _IXGBE_SRIOV_H_
#define _IXGBE_SRIOV_H_
+/* ixgbe driver limit the max number of VFs could be enabled to
+ * 63 (IXGBE_MAX_VF_FUNCTIONS－1)
+ */
+#define IXGBE_MAX_VFS_DRV_LIMIT (IXGBE_MAX_VF_FUNCTIONS－1)
+
void ixgbe_restore_vf_multicasts(struct ixgbe_adapter *adapter);
void ixgbe_msg_task(struct ixgbe_adapter *adapter);
int ixgbe_vf_configuration(struct pci_dev *pdev, unsigned int event_mask);
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ixgbe: set driver_max_VFs should be done before enabling SRIOV
commit 43dc4e01 Limit number of reported VFs to device specific value
It doesn't work and always returns -EBUSY because VFs ware already enabled.
ixgbe_enable_sriov()
pci_enable_sriov()
sriov_enable()
{
... ..
iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
pci_cfg_access_lock(dev);
... ...
}
pci_sriov_set_totalvfs()
{
... ...
if (dev->sriov->ctrl & PCI_SRIOV_CTRL_VFE)
return -EBUSY;
...
}
So should set driver_max_VFs with pci_sriov_set_totalvfs() before
enable VFs with ixgbe_enable_sriov().
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 47e9b44..bfc8e94 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7639,8 +7639,8 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* Mailbox */
ixgbe_init_mbx_params_pf(hw);
memcpy(>mbx.ops, ii->mbx_ops, sizeof(hw->mbx.ops));
- ixgbe_enable_sriov(adapter);
pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT);
+ ixgbe_enable_sriov(adapter);
skip_sriov:
#endif
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
Because ixgbe driver limit the max number of VF functions could be enalbed
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0ade0cd..47e9b44 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4818,7 +4818,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
#ifdef CONFIG_PCI_IOV
/* assign number of SR-IOV VFs */
if (hw->mac.type != ixgbe_mac_82598EB)
- adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
+ adapter->num_vfs = (max_vfs > IXGBE_MAX_VFS_DRV_LIMIT) ? 0 :
max_vfs;
#endif
/* enable itr by default in dynamic mode */
@@ -7640,7 +7640,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
ixgbe_init_mbx_params_pf(hw);
memcpy(>mbx.ops, ii->mbx_ops, sizeof(hw->mbx.ops));
ixgbe_enable_sriov(adapter);
- pci_sriov_set_totalvfs(pdev, 63);
+ pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT);
skip_sriov:
#endif
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 276d7b1..6925979 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -152,7 +152,8 @@ void ixgbe_enable_sriov(struct ixgbe_adapter *adapter)
* physical function. If the user requests greater thn
* 63 VFs then it is an error - reset to default of zero.
*/
- adapter->num_vfs = min_t(unsigned int, adapter->num_vfs, 63);
+ adapter->num_vfs = min_t(unsigned int,
+ adapter->num_vfs,
IXGBE_MAX_VFS_DRV_LIMIT);
err = pci_enable_sriov(adapter->pdev, adapter->num_vfs);
if (err) {
@@ -259,7 +260,7 @@ static int ixgbe_pci_sriov_enable(struct pci_dev *dev, int
num_vfs)
* PF. The PCI bus driver already checks for other values out of
* range.
*/
- if (num_vfs > 63) {
+ if (num_vfs > IXGBE_MAX_VFS_DRV_LIMIT) {
err = -EPERM;
goto err_out;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4713f9f..2593666 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -28,6 +28,11 @@
#ifndef _IXGBE_SRIOV_H_
#define _IXGBE_SRIOV_H_
+/* ixgbe driver limit the max number of VFs could be enabled to
+ * 63 (IXGBE_MAX_VF_FUNCTIONS－1)
+ */
+#define IXGBE_MAX_VFS_DRV_LIMIT (IXGBE_MAX_VF_FUNCTIONS－1)
+
void ixgbe_restore_vf_multicasts(struct ixgbe_adapter *adapter);
void ixgbe_msg_task(struct ixgbe_adapter *adapter);
int ixgbe_vf_configuration(struct pci_dev *pdev, unsigned int event_mask);
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad
Adding Dirk.. On 24 December 2013 20:06, Josh Boyer wrote: > Hi All, > > We've had a report [1] that the pstate driver causes KVM guests to > fail to boot because of a divide error. See the backtrace below. > > 4.839784] Intel P-state driver initializing. > [4.859972] Intel pstate controlling: cpu 0 > [4.867653] cpufreq: __cpufreq_add_dev: ->get() failed After a call to ->init(), ->get() is supposed to work. @Dirk: Any idea why it failed? And then I don't know what made this divide by zero to happen :) > [4.877269] divide error: [#1] SMP > [4.878127] Modules linked in: > [4.878127] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.13.0-0.rc4.git5.1.fc21.x86_64 #1 > [4.878127] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [4.878127] task: 88001ea2 ti: 88001e9bc000 task.ti: > 88001e9bc000 > [4.878127] RIP: 0010:[] [] > intel_pstate_timer_func+0x11d/0x2b0 > [4.878127] RSP: :88001ee03e18 EFLAGS: 00010246 > [4.878127] RAX: RBX: 88001a454348 RCX: > 6100 > [4.878127] RDX: RSI: RDI: > > [4.878127] RBP: 88001ee03e38 R08: R09: > > [4.878127] R10: 88001ea2 R11: R12: > 0c0a1ea2 > [4.878127] R13: 1ea21ea2 R14: 815c5400 R15: > 88001a454348 > [4.878127] FS: () GS:88001ee0() > knlGS: > [4.878127] CS: 0010 DS: ES: CR0: 8005003b > [4.878127] CR2: CR3: 01c0c000 CR4: > 06f0 > [4.878127] Stack: > [4.878127] fffb1a454390 821a4500 88001a454390 > 0100 > [4.878127] 88001ee03ea8 81083e9a 81083e15 > 82d5ed40 > [4.878127] 8258cc60 81ac39de > > [4.878127] Call Trace: > [4.878127] > [4.878127] [] call_timer_fn+0x8a/0x310 > [4.878127] [] ? call_timer_fn+0x5/0x310 > [4.878127] [] ? pid_param_set+0x130/0x130 > [4.878127] [] run_timer_softirq+0x234/0x380 > [4.878127] [] __do_softirq+0x104/0x430 > [4.878127] [] irq_exit+0xcd/0xe0 > [4.878127] [] smp_apic_timer_interrupt+0x45/0x60 > [4.878127] [] apic_timer_interrupt+0x72/0x80 > [4.878127] > [4.878127] [] ? vprintk_emit+0x1dd/0x5e0 > [4.878127] [] printk+0x67/0x69 > [4.878127] [] __cpufreq_add_dev.isra.13+0x883/0x8d0 > [4.878127] [] cpufreq_add_dev+0x10/0x20 > [4.878127] [] subsys_interface_register+0xb1/0xf0 > [4.878127] [] cpufreq_register_driver+0x9f/0x210 > [4.878127] [] intel_pstate_init+0x27d/0x3be > [4.878127] [] ? mutex_unlock+0xe/0x10 > [4.878127] [] ? cpufreq_gov_dbs_init+0x12/0x12 > [4.878127] [] do_one_initcall+0xfa/0x1b0 > [4.878127] [] ? parse_args+0x225/0x3f0 > [4.878127] [] kernel_init_freeable+0x1fc/0x287 > [4.878127] [] ? do_early_param+0x88/0x88 > [4.878127] [] ? rest_init+0x150/0x150 > [4.878127] [] kernel_init+0xe/0x130 > [4.878127] [] ret_from_fork+0x7c/0xb0 > [4.878127] [] ? rest_init+0x150/0x150 > [4.878127] Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 > 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 > e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa > 1f 89 > [4.878127] RIP [] intel_pstate_timer_func+0x11d/0x2b0 > [4.878127] RSP > [5.438189] ---[ end trace f166110ed22cc37a ]--- > [5.446428] Kernel panic - not syncing: Fatal exception in interrupt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip v6 06/22] [BUGFIX] x86: Prohibit probing on memcpy/memset
(2013/12/24 18:53), Jovi Zhangwei wrote: >>> Still no crash, use your kernel config. >>> memcpy and __memcpy have same address in /proc/kallsyms. >>> >>> Looks like a interesting problem. >> >> Agreed. In my case, those have same address, but only probing >> __memcpy caused a kernel crash. I'm not sure why, but it is >> safe to disable probing on it. >> > Shall we need dig further to address the root cause? IMO, the kprobe > should act same behavior when given same probe address, but it's look > so weird in your box. :) Hmm, right now, I tried it again and found the bug disappeared... I'm using the latest tip kernel for the test; 3ab838d7723e9fbfd49b2d395752bd68e1ef4b71 Should I remove this patch until it happens again? Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]
---
Staging: android: fix parenthesis coding style issue in alarm-dev.c
This is a patch to the alarm-dev.c file that fixes up a
parenthesis warning found by the checkpatch.pl tool.
Signed-off-by: Evan Hosseini
---
drivers/staging/android/alarm-dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/alarm-dev.c
b/drivers/staging/android/alarm-dev.c
index 647694f..893362f 100644
--- a/drivers/staging/android/alarm-dev.c
+++ b/drivers/staging/android/alarm-dev.c
@@ -68,7 +68,6 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
*/
static int is_wakeup(enum android_alarm_type type)
{
- return (type == ANDROID_ALARM_RTC_WAKEUP ||
- type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
+ return type == ANDROID_ALARM_RTC_WAKEUP ||
+ type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipc: whitespace cleanup
On 12/24/2013 10:02 AM, Manfred Spraul wrote: > The ipc code does not adhere the typical linux coding style. > This patch fixes lots of simple whitespace errors. > > - mostly autogenerated by > scripts/checkpatch.pl -f --fix \ > --types=pointer_location,spacing,space_before_tab > - one manual fixup (keep structure members tab-aligned) > - removal of additional space_before_tab that were not found by --fix > > diff -w is empty. > Tested with some of my msg and sem test apps. > > Andrew: Could you include it in -mm and move it towards Linus' tree? > > Signed-off-by: Manfred Spraul > Suggested-by: Li Bin > Cc: Joe Perches > Cc: linux-kernel@vger.kernel.org > Acked-by: Rafael Aquini Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.12.6-rt9
On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.6-rt9 patch set.
>
> Changes since v3.12.6-rt8
> - ARM's mach-sti is now using rawlock as boot_lock (like the other
> mach-*)
> - There was a callpath to rcu_preempt_qs() with interrupts enabled. Tiejun
> Chen posted a patch to call it with interrupt disabled like we always
> do.
> - A patch from Paul E. McKenney to not activate RCU core on NO_HZ_FULL
> CPUs
> - A patch from Thomas Gleixner not to raise the timer softirq
> unconditionally (only if a timer is pending)
>
>
> There is also a patch in the queue from Paul E. McKenney to move RCU
> processing from softirq into its own thread. After Mike Galbraith
> reported a few RCU stalls I decided to keep it disabled for now until I
> have some time to look at it.
I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
core box. I haven't seen RCU grip yet, but I just checked on it after
3.5 hours into this boot/beat (after fixing crash+kdump setup), and
found it in the process of dumping.
crash> bt
PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16"
#0 [880276806a40] machine_kexec at 8103bc07
#1 [880276806aa0] crash_kexec at 810d56b3
#2 [880276806b70] panic at 815bf8b0
#3 [880276806bf0] watchdog_overflow_callback at 810fed3d
#4 [880276806c10] __perf_event_overflow at 81131928
#5 [880276806ca0] perf_event_overflow at 81132254
#6 [880276806cb0] intel_pmu_handle_irq at 8102078f
#7 [880276806de0] perf_event_nmi_handler at 815c5825
#8 [880276806e10] nmi_handle at 815c4ed3
#9 [880276806ea0] default_do_nmi at 815c5063
#10 [880276806ed0] do_nmi at 815c5388
#11 [880276806ef0] end_repeat_nmi at 815c4371
[exception RIP: _raw_spin_trylock+48]
RIP: 815c3790 RSP: 880276803e28 RFLAGS: 0002
RAX: 0010 RBX: 0010 RCX: 0002
RDX: 880276803e28 RSI: 0018 RDI: 0001
RBP: 815c3790 R8: 815c3790 R9: 0018
R10: 880276803e28 R11: 0002 R12:
R13: 880273a0c000 R14: 8802739ba340 R15: 880273a03fd8
ORIG_RAX: 880273a03fd8 CS: 0010 SS: 0018
--- ---
#12 [880276803e28] _raw_spin_trylock at 815c3790
#13 [880276803e30] rt_spin_lock_slowunlock_hirq at 815c2cc8
#14 [880276803e50] rt_spin_unlock_after_trylock_in_irq at 815c3425
#15 [880276803e60] get_next_timer_interrupt at 810684a7
#16 [880276803ed0] tick_nohz_stop_sched_tick at 810c5f2e
#17 [880276803f50] tick_nohz_irq_exit at 810c6333
#18 [880276803f70] irq_exit at 81060065
#19 [880276803f90] smp_apic_timer_interrupt at 810358f5
#20 [880276803fb0] apic_timer_interrupt at 815cbf9d
--- ---
#21 [880273a03b28] apic_timer_interrupt at 815cbf9d
[exception RIP: _raw_spin_lock+50]
RIP: 815c3642 RSP: 880273a03bd8 RFLAGS: 0202
RAX: 8b49 RBX: 880272157290 RCX: 8802739ba340
RDX: 8b4a RSI: 0010 RDI: 880273a0c000
RBP: 880273a03bd8 R8: 0001 R9:
R10: R11: 0001 R12: 810927b5
R13: 880273a03b68 R14: 0010 R15: 0010
ORIG_RAX: ff10 CS: 0010 SS: 0018
#22 [880273a03be0] rt_spin_lock_slowlock at 815c2591
#23 [880273a03cc0] rt_spin_lock at 815c3362
#24 [880273a03cd0] run_timer_softirq at 81069002
#25 [880273a03d70] handle_softirq at 81060d0f
#26 [880273a03db0] do_current_softirqs at 81060f3c
#27 [880273a03e20] run_ksoftirqd at 81061045
#28 [880273a03e40] smpboot_thread_fn at 81089c31
#29 [880273a03ec0] kthread at 810807fe
#30 [880273a03f50] ret_from_fork at 815cb28c
crash> gdb list *0x815c2591
0x815c2591 is in rt_spin_lock_slowlock (kernel/rtmutex.c:109).
104 }
105 #endif
106
107 static inline void init_lists(struct rt_mutex *lock)
108 {
109 if (unlikely(!lock->wait_list.node_list.prev))
110 plist_head_init(>wait_list);
111 }
112
113 /*
crash> gdb list *0x815c2590
0x815c2590 is in rt_spin_lock_slowlock (kernel/rtmutex.c:744).
739 struct rt_mutex_waiter waiter, *top_waiter;
740 int ret;
741
742 rt_mutex_init_waiter(, true);
743
744 raw_spin_lock(>wait_lock);
745 init_lists(lock);
746
747 if (__try_to_take_rt_mutex(lock, self, NULL, STEAL_LATERAL)) {
748 raw_spin_unlock(>wait_lock);
crash> gdb list
Re: [Query]: trace-cmd crashing with '-e syscalls' on 3.13-rc1
On 24 December 2013 19:18, Steven Rostedt wrote: > Can you also produce this with just > "echo 1 > /sys/kernel/debug/tracing/events/syscalls/enable"? Will do that on 26th.. >> [ 299.998874] Unable to handle kernel NULL pointer dereference at >> virtual address 001b >> [ 300.005554] pgd = ed9fc000 >> [ 300.008201] [001b] *pgd=6eb1e831, *pte=, *ppte= >> [ 300.014428] Internal error: Oops: 17 [#1] PREEMPT SMP ARM >> [ 300.019812] Modules linked in: >> [ 300.022847] CPU: 0 PID: 2172 Comm: is-cpu-isolated Not tainted >> 3.13.0-rc1-00090-gd6eaf98-dirty #141 > > Are you running some isolated CPU test? Do you have NO_HZ_FULL enabled > too? Yeah, I am using NO_HZ_FULL with CPUSets. Only one task (stress) is running on CPU1 and CPU0 is running everything else.. > I Cc'd Frederic too. > > Note, I'm on PTO for two weeks (coming back Jan 6th), so I wont be > debugging this any time soon. My wife has me debugging house issues > (putting in a new floor for laundry room, painting, re-arranging > furniture, etc). (I have to sneak to the computer in order to goof off > and respond to this email ;-) :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: act8865: Rmove unneeded regulator_unregister() calls
This is not required because current code use devm_regulator_register() to
register regulators.
Signed-off-by: Axel Lin
---
drivers/regulator/act8865-regulator.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index db048f2..dfae294 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -334,17 +334,6 @@ static int act8865_pmic_probe(struct i2c_client *client,
return 0;
}
-static int act8865_pmic_remove(struct i2c_client *client)
-{
- struct act8865 *act8865 = i2c_get_clientdata(client);
- int i;
-
- for (i = 0; i < ACT8865_REG_NUM; i++)
- regulator_unregister(act8865->rdev[i]);
-
- return 0;
-}
-
static const struct i2c_device_id act8865_ids[] = {
{ "act8865", 0 },
{ },
@@ -357,7 +346,6 @@ static struct i2c_driver act8865_pmic_driver = {
.owner = THIS_MODULE,
},
.probe = act8865_pmic_probe,
- .remove = act8865_pmic_remove,
.id_table = act8865_ids,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/20] net: slight optimization of addr compare for some modules
于 2013/12/24 23:05, Joe Perches 写道: > On Tue, 2013-12-24 at 22:35 +0800, Ding Tianhong wrote: >> 于 2013/12/24 22:22, Joe Perches 写道: >>> On Tue, 2013-12-24 at 19:27 +0800, Ding Tianhong wrote: Use possibly more efficient ether_addr_equal_unaligned and ether_addr_equal to instead of memcmp. >>> >>> A negative of adding so many different drivers in a single >>> patch is that you miss sending patches to the named maintainers. >>> >>> Most of these below have separate individual maintainers. >> >> you mean that I should send below by separate patch? > > I think yes, > > You can send them to netdev, but cc'ing the named > maintainers is a polite thing to do. > > Sending individual patches can make it easier for > maintainers to review the bits that are specific > to their projects without having to wade through > other changes that aren't relevant to them. > OK, I will rebuild the 01/20 patch and make it to seperate patches follow your opinion. and the rest of the patches I think is fit and no need to modify, if you agree with me, I will send the rest 19 patch as the first step, and then seperate this patch as the second step, send them in net-next. Regards Ding >> It seemed that I >> misunderstood, I use the ./script/getmainter and found the only maintainer >> is David, and others are support, so maybe I was wrong, but it really a big >> patchset, could I send them by seperate patchset? I think it could be more >> clearly. > >>From the MAINTAINERS file: > S: Status, one of the following: > Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. > Odd Fixes: It has a maintainer but they don't have time to do > much other than throw the odd patch in. See below.. > Orphan: No current maintainer [but maybe you could take the > role as you write your new code]. > Obsolete:Old code. Something tagged obsolete generally means > it has been replaced by a better system and you > should be using that. > > So "supported" is "higher/better" than "maintained". > OK > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] softirq: Use const char * const for softirq_to_name, whitespace neatening
On Tue, 2013-12-24 at 23:19 +0800, Wang YanQing wrote:
> On Sun, Nov 17, 2013 at 01:55:12AM -0800, Joe Perches wrote:
> > Reduce data size a little.
> > Reduce checkpatch noise.
> >
> > $ size kernel/softirq.o*
> >textdata bss dec hex filename
> > 1155460134008 215755447 kernel/softirq.o.new
> > 1147460934008 215755447 kernel/softirq.o.old
>
> Hi, could you tell me why this patch could reduce data size?
It moves the softirq_to_name array of 10 char *
from data (non-const) to text (const).
-char *softirq_to_name[NR_SOFTIRQS] = {
+const char * const softirq_to_name[NR_SOFTIRQS] = {
"HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "BLOCK_IOPOLL",
"TASKLET", "SCHED", "HRTIMER", "RCU"
};
Use objdump or "make kernel/softirq.lst" and inspect
the object code produced to see for yourself.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/thp: fix vmas tear down race with thp splitting
On 12/23/2013 08:54 PM, Wanpeng Li wrote: Sasha reports unmap_page_range tears down pmd range which is race with thp splitting during page reclaim. Transparent huge page will be splitting during page reclaim. However, split pmd lock which held by __split_trans_huge_lock can't prevent __split_huge_page_refcount running in parallel. This patch fix it by hold compound lock to check if __split_huge_page_refcount is running underneath, in that case zap huge pmd range should be fallback. [ 265.474585] kernel BUG at mm/huge_memory.c:1440! [ 265.475129] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 265.476684] Dumping ftrace buffer: [ 265.477144](ftrace buffer empty) [ 265.478398] Modules linked in: [ 265.478807] CPU: 8 PID: 11344 Comm: trinity-c206 Tainted: GW 3.13.0-rc5-next-20131223-sasha-00015-gec22156-dirty #8 [ 265.480172] task: 8801cb573000 ti: 8801cbd3a000 task.ti: 8801cbd3a000 [ 265.480172] RIP: 0010:[] [] zap_huge_pmd+0x170/0x1f0 [ 265.480172] RSP: :8801cbd3bc78 EFLAGS: 00010246 [ 265.480172] RAX: 015f80090018 RBX: 8801cbd3bde8 RCX: ff9c [ 265.480172] RDX: RSI: 0008 RDI: 8800bffd2000 [ 265.480172] RBP: 8801cbd3bcb8 R08: R09: [ 265.480172] R10: 0001 R11: R12: ea0002856740 [ 265.480172] R13: ea0002d5 R14: 7ff91500 R15: 7ff930e48fff [ 265.480172] FS: 7ff934899700() GS:88014d40() knlGS: [ 265.480172] CS: 0010 DS: ES: CR0: 8005003b [ 265.480172] CR2: 7ff93428a000 CR3: 00010babe000 CR4: 06e0 [ 265.480172] Stack: [ 265.480172] 04dd 8801ccbfbb60 8801cbd3bcb8 8801cbb15540 [ 265.480172] 7ff91500 7ff930e49000 8801cbd3bde8 7ff930e48fff [ 265.480172] 8801cbd3bd48 812885b6 88005f5d20c0 7ff91520 [ 265.480172] Call Trace: [ 265.480172] [] unmap_page_range+0x2c6/0x410 [ 265.480172] [] unmap_single_vma+0x101/0x120 [ 265.480172] [] unmap_vmas+0x61/0xa0 [ 265.480172] [] exit_mmap+0xd0/0x170 [ 265.480172] [] mmput+0x70/0xe0 [ 265.480172] [] exit_mm+0x18d/0x1a0 [ 265.480172] [] ? acct_collect+0x175/0x1b0 [ 265.480172] [] do_exit+0x26f/0x520 [ 265.480172] [] do_group_exit+0xa9/0xe0 [ 265.480172] [] SyS_exit_group+0x17/0x20 [ 265.480172] [] tracesys+0xdd/0xe2 [ 265.480172] Code: 0f 0b 66 0f 1f 84 00 00 00 00 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 81 80 50 03 00 00 00 fe ff ff 49 8b 45 00 f6 c4 40 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 [ 265.480172] RIP [] zap_huge_pmd+0x170/0x1f0 [ 265.480172] RSP Reported-by: Sasha Levin Signed-off-by: Wanpeng Li --- Ran a round of testing overnight. While the BUG seems to be gone I'm now getting: [ 879.815434] BUG: Bad page state in process trinity-c115 pfn:29a00 [ 879.816430] page:eaa68000 count:0 mapcount:0 mapping: (null) index: 0x7f2f2 [ 879.817654] page flags: 0x5f81084008(uptodate|head|swapbacked|compound_lock) [ 879.818848] Modules linked in: [ 879.819340] CPU: 1 PID: 18824 Comm: trinity-c115 Tainted: GW 3.13.0-rc5-n ext-20131223-sasha-00016-g3010ae9-dirty #13 [ 879.821142] eaa68000 880188345a58 845e014c 0009 [ 879.822492] eaa68000 880188345a78 8125c301 880188345a78 [ 879.823858] 0200 880188345ac8 8125cd83 8801 [ 879.825128] Call Trace: [ 879.825568] [] dump_stack+0x52/0x7f [ 879.826425] [] bad_page+0xf1/0x120 [ 879.827296] [] free_pages_prepare+0x133/0x1f0 [ 879.828276] [] __free_pages_ok+0x24/0x150 [ 879.829267] [] free_compound_page+0x1b/0x20 [ 879.830547] [] __put_compound_page+0x1c/0x30 [ 879.831360] [] put_compound_page+0x60/0x2e0 [ 879.832284] [] release_pages+0x6b/0x230 [ 879.833230] [] free_pages_and_swap_cache+0xa6/0xd0 [ 879.834297] [] tlb_flush_mmu+0x6f/0x90 [ 879.835146] [] zap_huge_pmd+0x308/0x410 [ 879.836097] [] unmap_page_range+0x2c6/0x410 [ 879.837034] [] unmap_single_vma+0x101/0x120 [ 879.838027] [] unmap_vmas+0x61/0xa0 [ 879.838892] [] exit_mmap+0xd0/0x170 [ 879.839794] [] mmput+0x70/0xe0 [ 879.841079] [] exit_mm+0x18d/0x1a0 [ 879.841565] [] ? acct_collect+0x175/0x1b0 [ 879.842411] [] do_exit+0x26f/0x520 [ 879.843169] [] do_group_exit+0xa9/0xe0 [ 879.844033] [] SyS_exit_group+0x17/0x20 [ 879.844967] [] tracesys+0xdd/0xe2 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] softirq: Use const char * const for softirq_to_name, whitespace neatening
On Sun, Nov 17, 2013 at 01:55:12AM -0800, Joe Perches wrote: > Reduce data size a little. > Reduce checkpatch noise. > > $ size kernel/softirq.o* >text data bss dec hex filename > 11554 60134008 215755447 kernel/softirq.o.new > 11474 60934008 215755447 kernel/softirq.o.old Hi, could you tell me why this patch could reduce data size? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/15] clk: Add regmap core helpers for enable/disable/is_enabled
On Mon, Dec 23, 2013 at 17:12 -0800, Stephen Boyd wrote:
>
> The clock framework already has support for simple gate clocks
> but if drivers want to use the gate clock functionality they need
> to wrap the gate clock in another struct and chain the ops by
> calling the gate ops from their own custom ops. Plus the gate
> clock implementation only supports MMIO accessors so other bus
> type clocks don't benefit from the potential code reuse. Add some
> simple regmap helpers for enable/disable/is_enabled that drivers
> can use as drop in replacements for their clock ops or as simple
> functions they call from their own custom ops. This is based on
> similar helps in the regulator framework.
The same comment applies as to the previous version. Is it
useful to introduce copies of the gate handling while the
difference in only in how the hardware registers get accessed?
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -177,11 +177,21 @@ struct clk_init_data {
> [ ... ]
> @@ -447,6 +457,9 @@ struct clk *__clk_lookup(const char *name);
> long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *best_parent_rate,
> struct clk **best_parent_p);
> +int clk_is_enabled_regmap(struct clk_hw *hw);
> +int clk_enable_regmap(struct clk_hw *hw);
> +void clk_disable_regmap(struct clk_hw *hw);
Looking at the patch: Do you expect callers to remember whether
a clock gate is backed by mmio or by regmap access, to call a
different set of routines? Should this not be hidden behind the
API and be transparent after clock registration?
I'd suggest to fold regmap support into Tero Kristo's ll_ops
approach, and to discuss this in his v12 thread.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/20] net: slight optimization of addr compare for some modules
On Tue, 2013-12-24 at 22:35 +0800, Ding Tianhong wrote: > 于 2013/12/24 22:22, Joe Perches 写道: > > On Tue, 2013-12-24 at 19:27 +0800, Ding Tianhong wrote: > >> Use possibly more efficient ether_addr_equal_unaligned > >> and ether_addr_equal to instead of memcmp. > > > > A negative of adding so many different drivers in a single > > patch is that you miss sending patches to the named maintainers. > > > > Most of these below have separate individual maintainers. > > you mean that I should send below by separate patch? I think yes, You can send them to netdev, but cc'ing the named maintainers is a polite thing to do. Sending individual patches can make it easier for maintainers to review the bits that are specific to their projects without having to wade through other changes that aren't relevant to them. > It seemed that I > misunderstood, I use the ./script/getmainter and found the only maintainer > is David, and others are support, so maybe I was wrong, but it really a big > patchset, could I send them by seperate patchset? I think it could be more > clearly. >From the MAINTAINERS file: S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete:Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. So "supported" is "higher/better" than "maintained". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH -tip 3/3] perf-probe: Use the actual address as a hint for uprobes
(2013/12/24 17:46), Namhyung Kim wrote:
> On Tue, 24 Dec 2013 17:27:45 +0900, Masami Hiramatsu wrote:
>> (2013/12/24 16:54), Namhyung Kim wrote:
>>> Hi Masami,
>>>
>>> On Mon, 23 Dec 2013 19:50:10 +0900, Masami Hiramatsu wrote:
(2013/12/23 16:46), Namhyung Kim wrote:
> On Mon, 23 Dec 2013 06:54:38 +0900, Masami Hiramatsu wrote:
>> (2013/12/21 3:03), Arnaldo Carvalho de Melo wrote:
>>> Em Fri, Dec 20, 2013 at 10:03:02AM +, Masami Hiramatsu escreveu:
>> BTW, I'm not sure why debuginfo and nm shows symbol address + 0x40,
>> and why the perf's map/symbol can remove this offset. Could you tell me
>> how it works?
>> If I can get the offset (0x40) from binary, I don't need this kind
>> of ugly hacks...
>
> AFAIK the actual symbol address is what nm (and debuginfo) shows. But
> perf adjusts symbol address to have a relative address from the start of
> mapping (i.e. file offset) like below:
>
> sym.st_value -= shdr.sh_addr - shdr.sh_offset;
Thanks! this is what I really need!
>>
>> BTW, what I've found is that the perf's map has start, end and pgoffs
>> but those are not initialized when we load user-binary (see dso__load_sym).
>> I'm not sure why.
>
> It's only set from a mmap event either sent from kernel or synthesized
> using /proc//maps. We cannot know the load address of a library
> until it gets loaded but for an executable, we could use the address of
> ELF segments/sections.
I see, the problem is that the address recorded in the debuginfo
is not the relative address. Thus, I think I need to get the
".text" section offset by decoding elf file (not the debuginfo).
> This way, we can handle mmap and symbol address almost uniformly
> (i.e. ip = map->start + symbol->address). But this requires the mmap
> event during perf record. For perf probe, we might need to synthesize
> mapping info from the section/segment header since it doesn't have the
> mmap event. Currently, the dso__new_map() just creates a map starts
> from 0.
I think the uprobe requires only the relative address, doesn't that?
>>>
>>> Yes, but fetching arguments is little different than a normal relative
>>> address, I think.
>>
>> Is this for uprobe probing address? or fetching symbol(global variables)?
>> I'd like to support uprobes probing address first.
>
> It's for argument fetching. For probing, you can simply use a relative
> address.
Hm, OK.
BTW, I've found that current uprobe's address calculation routine is
trying to get the absolute address.
if (map->start > sym->start)
vaddr = map->start;
vaddr += sym->start + pp->offset + map->pgoff;
Currently it just returns a relative address because both of map->pgoff
and map->start are zero :) But I think it should be
vaddr = sym->start + pp->offset;
Since uprobe requires a simple relative offset.
>>> An offset of an argument bases on the mapping address of text segment.
>>> This fits naturally for a shared library case - base address is 0. So
>>> we can use the symbol address (st_value) directly. But for executables,
>>> the base address of text segment is 0x40 on x86-64 and data symbol
>>> is on 0x6X typically. So in this case the offset given to uprobe
>>> should be "@+0x2X" (st_value - text_base).
>>
>> Oh, I see. I'd better make a testcase for checking what the best
>> way to get such offsets.
>
> Okay, please share the result then. :)
I just wrote a short test program as below;
---
#include
int global_var = 0xbeef;
int target(int arg1i, char *arg2s)
{
printf("arg1=%d, arg2=%s\n", arg1i, arg2s);
return arg1i;
}
int main(int argc, char *argv[])
{
int ret;
ret = target(argc, argv[0]);
if (ret)
target(global_var, "test");
return 0;
}
And run nm and eu-readelf as below.
---
$ nm a.out | egrep "(target|global_var)"
00601034 D global_var
00400530 T target
$ eu-readelf -S a.out | egrep "\\.(text|data)"
[13] .textPROGBITS 00400440 0440 01b4 0 AX
0 0 16
[24] .dataPROGBITS 00601030 1030 0008 0 WA
0 0 4
---
As you can see, the .text and .data offsets will be calculated by
section start - section offset. Thus, we can do
Dwarf's global_var address - (.text start - .text offset)
for the relative global_var address (unless the kernel loads .data
section into different address.)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipc: whitespace cleanup
The ipc code does not adhere the typical linux coding style.
This patch fixes lots of simple whitespace errors.
- mostly autogenerated by
scripts/checkpatch.pl -f --fix \
--types=pointer_location,spacing,space_before_tab
- one manual fixup (keep structure members tab-aligned)
- removal of additional space_before_tab that were not found by --fix
diff -w is empty.
Tested with some of my msg and sem test apps.
Andrew: Could you include it in -mm and move it towards Linus' tree?
Signed-off-by: Manfred Spraul
Suggested-by: Li Bin
Cc: Joe Perches
Cc: linux-kernel@vger.kernel.org
Acked-by: Rafael Aquini
---
include/linux/msg.h | 2 +-
include/linux/shm.h | 2 +-
ipc/compat.c| 10 +++---
ipc/compat_mq.c | 2 +-
ipc/ipc_sysctl.c| 14
ipc/mqueue.c| 16 -
ipc/msg.c | 18 +-
ipc/sem.c | 98 ++---
ipc/shm.c | 32 -
ipc/util.c | 24 ++---
ipc/util.h | 14
11 files changed, 116 insertions(+), 116 deletions(-)
diff --git a/include/linux/msg.h b/include/linux/msg.h
index e21f9d4..f3f302f 100644
--- a/include/linux/msg.h
+++ b/include/linux/msg.h
@@ -9,7 +9,7 @@ struct msg_msg {
struct list_head m_list;
long m_type;
size_t m_ts;/* message text size */
- struct msg_msgseg* next;
+ struct msg_msgseg *next;
void *security;
/* the actual message follows immediately */
};
diff --git a/include/linux/shm.h b/include/linux/shm.h
index 429c199..1e2cd2e 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -9,7 +9,7 @@
struct shmid_kernel /* private to the kernel */
{
struct kern_ipc_permshm_perm;
- struct file * shm_file;
+ struct file *shm_file;
unsigned long shm_nattch;
unsigned long shm_segsz;
time_t shm_atim;
diff --git a/ipc/compat.c b/ipc/compat.c
index 892f658..ed0530b 100644
--- a/ipc/compat.c
+++ b/ipc/compat.c
@@ -197,7 +197,7 @@ static inline int __put_compat_ipc_perm(struct ipc64_perm
*p,
static inline int get_compat_semid64_ds(struct semid64_ds *s64,
struct compat_semid64_ds __user *up64)
{
- if (!access_ok (VERIFY_READ, up64, sizeof(*up64)))
+ if (!access_ok(VERIFY_READ, up64, sizeof(*up64)))
return -EFAULT;
return __get_compat_ipc64_perm(>sem_perm, >sem_perm);
}
@@ -205,7 +205,7 @@ static inline int get_compat_semid64_ds(struct semid64_ds
*s64,
static inline int get_compat_semid_ds(struct semid64_ds *s,
struct compat_semid_ds __user *up)
{
- if (!access_ok (VERIFY_READ, up, sizeof(*up)))
+ if (!access_ok(VERIFY_READ, up, sizeof(*up)))
return -EFAULT;
return __get_compat_ipc_perm(>sem_perm, >sem_perm);
}
@@ -215,7 +215,7 @@ static inline int put_compat_semid64_ds(struct semid64_ds
*s64,
{
int err;
- if (!access_ok (VERIFY_WRITE, up64, sizeof(*up64)))
+ if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64)))
return -EFAULT;
err = __put_compat_ipc64_perm(>sem_perm, >sem_perm);
err |= __put_user(s64->sem_otime, >sem_otime);
@@ -229,7 +229,7 @@ static inline int put_compat_semid_ds(struct semid64_ds *s,
{
int err;
- if (!access_ok (VERIFY_WRITE, up, sizeof(*up)))
+ if (!access_ok(VERIFY_WRITE, up, sizeof(*up)))
return -EFAULT;
err = __put_compat_ipc_perm(>sem_perm, >sem_perm);
err |= __put_user(s->sem_otime, >sem_otime);
@@ -376,7 +376,7 @@ COMPAT_SYSCALL_DEFINE6(ipc, u32, call, int, first, int,
second,
struct compat_ipc_kludge ipck;
if (!uptr)
return -EINVAL;
- if (copy_from_user (, uptr, sizeof(ipck)))
+ if (copy_from_user(, uptr, sizeof(ipck)))
return -EFAULT;
uptr = compat_ptr(ipck.msgp);
fifth = ipck.msgtyp;
diff --git a/ipc/compat_mq.c b/ipc/compat_mq.c
index 380ea4f..63d7c6de 100644
--- a/ipc/compat_mq.c
+++ b/ipc/compat_mq.c
@@ -64,7 +64,7 @@ asmlinkage long compat_sys_mq_open(const char __user *u_name,
return sys_mq_open(u_name, oflag, mode, p);
}
-static int compat_prepare_timeout(struct timespec __user * *p,
+static int compat_prepare_timeout(struct timespec __user **p,
const struct compat_timespec __user *u)
{
struct timespec ts;
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index b0e99de..1702864 100644
--- a/ipc/ipc_sysctl.c
+++ b/ipc/ipc_sysctl.c
@@ -164,21 +164,21 @@ static struct ctl_table ipc_kern_table[] = {
{
.procname = "shmmax",
.data =
Re: [PATCH v2 01/20] net: slight optimization of addr compare for some modules
于 2013/12/24 22:22, Joe Perches 写道:
> On Tue, 2013-12-24 at 19:27 +0800, Ding Tianhong wrote:
>> Use possibly more efficient ether_addr_equal_unaligned
>> and ether_addr_equal to instead of memcmp.
>
> A negative of adding so many different drivers in a single
> patch is that you miss sending patches to the named maintainers.
>
> Most of these below have separate individual maintainers.
> (a suggested patch below this too)
>
you mean that I should send below by separate patch? It seemed that I
misunderstood, I use the ./script/getmainter and found the only maintainer
is David, and others are support, so maybe I was wrong, but it really a big
patchset, could I send them by seperate patchset? I think it could be more
clearly.
>> drivers/net/bonding/bond_3ad.c| 2 +-
>> drivers/net/ethernet/3com/3c509.c | 3 +--
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c| 10 --
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 2 +-
>> drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c| 2 +-
>> drivers/net/ethernet/chelsio/cxgb3/l2t.c | 2 +-
>> drivers/net/ethernet/cisco/enic/enic_pp.c | 2 +-
>> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
>> drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 3 +--
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c| 4 ++--
>> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
>> drivers/net/ethernet/micrel/ksz884x.c | 9 -
>> drivers/net/ethernet/neterion/vxge/vxge-main.c| 2 +-
>> drivers/net/ethernet/packetengines/yellowfin.c| 8 ++--
>> drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c| 2 +-
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c| 4 ++--
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c| 4 ++--
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 4 ++--
>> drivers/net/ethernet/renesas/sh_eth.c | 2 +-
>> drivers/net/ethernet/seeq/sgiseeq.c | 2 +-
>> drivers/net/ethernet/sun/sunvnet.c| 2 +-
>> drivers/net/ethernet/ti/cpsw_ale.c| 2 +-
>> drivers/net/fddi/skfp/fplustm.c | 3 ++-
>> drivers/net/plip/plip.c | 2 +-
>> net/caif/cfrfml.c | 2 +-
>> 27 files changed, 39 insertions(+), 47 deletions(-)
>
> Also for bonding, my preference would be to rename
> the macro and use ether_addr_equal as it seems that
> all references are u16 aligned.
>
Agree, I make it in the early patchset, as same as yours,
[PATCH net-next 1/6] bonding: use ether_addr_equal_unaligned for bond addr
compare
in my opinion, I think it would be better in the bonding patchset,
because I am making a patchset for bonding.
Regards
Ding
> I also removed some superfluous parentheses.
> ---
> drivers/net/bonding/bond_3ad.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index 187b1b7..ae56983 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -91,7 +91,8 @@
> //endalloun
>
> // compare MAC addresses
> -#define MAC_ADDRESS_COMPARE(A, B) memcmp(A, B, ETH_ALEN)
> +#define MAC_ADDRESS_EQUAL(A, B) \
> + ether_addr_equal((const u8 *)A, (const u8 *)B)
>
> static struct mac_addr null_mac_addr = { { 0, 0, 0, 0, 0, 0 } };
> static u16 ad_ticks_per_sec;
> @@ -419,7 +420,7 @@ static void __choose_matched(struct lacpdu *lacpdu,
> struct port *port)
> // check if all parameters are alike
> if (((ntohs(lacpdu->partner_port) == port->actor_port_number) &&
>(ntohs(lacpdu->partner_port_priority) ==
> port->actor_port_priority) &&
> - !MAC_ADDRESS_COMPARE(&(lacpdu->partner_system),
> &(port->actor_system)) &&
> + MAC_ADDRESS_EQUAL(>partner_system, >actor_system) &&
>(ntohs(lacpdu->partner_system_priority) ==
> port->actor_system_priority) &&
>(ntohs(lacpdu->partner_key) == port->actor_oper_port_key) &&
>((lacpdu->partner_state & AD_STATE_AGGREGATION) ==
> (port->actor_oper_port_state & AD_STATE_AGGREGATION))) ||
> @@ -509,7 +510,7 @@ static void __update_selected(struct lacpdu *lacpdu,
> struct port *port)
> // check if any parameter is different
> if (ntohs(lacpdu->actor_port) != partner->port_number ||
> ntohs(lacpdu->actor_port_priority) !=
> partner->port_priority ||
> - MAC_ADDRESS_COMPARE(>actor_system,
> >system) ||
> + !MAC_ADDRESS_EQUAL(>actor_system, >system)
> ||
>
Re: [PATCH 1/2] TTY: pmac_zilog, check existence of ports in pmz_console_init()
On Fri, Nov 22, 2013 at 4:47 PM, Geert Uytterhoeven
wrote:
> When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
> on the kernel command line, it crashes with:
Can we please get this in stable, too?
commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a
Thanks!
> Unable to handle kernel NULL pointer dereference at virtual address (null)
> Oops:
> PC: [<0013ad28>] __pmz_startup+0x32/0x2a0
> ...
> Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4
>
> The normal tty driver doesn't crash, because init_pmz() checks
> pmz_ports_count again after calling pmz_probe().
>
> In the serial console initialization path, pmz_console_init() doesn't do
> this, causing the driver to crash later.
>
> Add a check for pmz_ports_count to fix this.
>
> Signed-off-by: Geert Uytterhoeven
> Cc: Finn Thain
> Cc: Benjamin Herrenschmidt
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add the LED burst trigger
From: Joe Xue
Allow LEDs blink in burst mode. Three parameters are exported to
sysfs: freq, delay_off and times.
new file: Documentation/leds/ledtrig-burst.txt
modified: drivers/leds/trigger/Kconfig
modified: drivers/leds/trigger/Makefile
new file: drivers/leds/trigger/ledtrig-burst.c
Signed-off-by: Joe Xue
---
Documentation/leds/ledtrig-burst.txt | 58
drivers/leds/trigger/Kconfig | 10 ++
drivers/leds/trigger/Makefile| 1 +
drivers/leds/trigger/ledtrig-burst.c | 250 +++
4 files changed, 319 insertions(+)
create mode 100644 Documentation/leds/ledtrig-burst.txt
create mode 100644 drivers/leds/trigger/ledtrig-burst.c
diff --git a/Documentation/leds/ledtrig-burst.txt
b/Documentation/leds/ledtrig-burst.txt
new file mode 100644
index 000..50a7955
--- /dev/null
+++ b/Documentation/leds/ledtrig-burst.txt
@@ -0,0 +1,58 @@
+LED Burst Trigger
+=
+
+0. Introduction
+
+Sometimes, the system has only one no-color led to indicate different stats.
+The LED timer trigger can let LEDs to blink in different frequency, but most
+people maybe just can discriminate two states, slow and fast.
+
+In this case, Morse code maybe is a good choice :-), but who can bear it.
+
+Besides the Morse code, another way is using burst mode. People can easily tell
+how many times the LED blinks in one cycle.
+
+Burst trigger is designed for this purpose.
+
+1. How to use
+
+Burst trigger can be enabled and disabled from user space on led class
+devices that support this trigger as shown below:
+
+ echo burst > trigger
+
+Three properties are exported. They are freq, times and delay_off.
+
+ freq - the blink frequency, default value is 3 means 3HZ
+ times - burst blink times in one cycle, no default value
+ delay_off - off time between two burst blinks, default value is 500 ms
+
+2. Case studies
+
+ Example 1
+
+ echo burst > trigger
+ echo 2 > times
+
+ The behaviour is like below:
+
+ on(1/6s)off(1/6s)on(1/6s)off(1/6m)
+ ...off 500ms...
+ on(1/6s)off(1/6s)on(1/3s)off(1/6m)
+ ...off 500ms
+ ...
+
+ Example 2
+
+ echo burst > trigger
+ echo 4 > freq
+ echo 3 > times
+ echo 1000 > delay_off
+
+ The behaviour is like below:
+
+ on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+ ...off 1s...
+ on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+ ...off 1s
+ ...
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 49794b4..8f4ebbf 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,14 @@ config LEDS_TRIGGER_CAMERA
This enables direct flash/torch on/off by the driver, kernel space.
If unsure, say Y.
+config LEDS_TRIGGER_BURST
+ tristate "LED Burst Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to blink in burst mode with parameters
+ controlled via sysfs. It's useful to notify different states
+ by using one led.
+ For more details read Documentation/leds/leds-burst.txt.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 1abf48d..6c48517 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_BURST) += ledtrig-burst.o
diff --git a/drivers/leds/trigger/ledtrig-burst.c
b/drivers/leds/trigger/ledtrig-burst.c
new file mode 100644
index 000..95eda2a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue
+ *
+ * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
+ * ledtrig-heartbeat.c and Shuah Khan's ledtrig-burst.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/*
+ * Burst trigger allows LEDs to blink in burst mode. The difference
+ * between burst trigger and timer trigger is timer trigger makes the
+ * LEDs blink continually in a frequency while burst trigger makes the
+ * LEDs blink some times in a special frequency then have a stop.
+ * Burst trigger allows LEDs to indicate different stats. Users can easy
+ * to describe it to support engineers by saying 3/4/5/X times burst
+ * blink.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../leds.h"
+
+struct burst_trig_data {
+ int state;
+ unsigned long freq;
+ unsigned long times;
+ unsigned
intel_pstate divide error with v3.13-rc4-256-gb7000ad
Hi All, We've had a report [1] that the pstate driver causes KVM guests to fail to boot because of a divide error. See the backtrace below. 4.839784] Intel P-state driver initializing. [4.859972] Intel pstate controlling: cpu 0 [4.867653] cpufreq: __cpufreq_add_dev: ->get() failed [4.877269] divide error: [#1] SMP [4.878127] Modules linked in: [4.878127] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1 [4.878127] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [4.878127] task: 88001ea2 ti: 88001e9bc000 task.ti: 88001e9bc000 [4.878127] RIP: 0010:[] [] intel_pstate_timer_func+0x11d/0x2b0 [4.878127] RSP: :88001ee03e18 EFLAGS: 00010246 [4.878127] RAX: RBX: 88001a454348 RCX: 6100 [4.878127] RDX: RSI: RDI: [4.878127] RBP: 88001ee03e38 R08: R09: [4.878127] R10: 88001ea2 R11: R12: 0c0a1ea2 [4.878127] R13: 1ea21ea2 R14: 815c5400 R15: 88001a454348 [4.878127] FS: () GS:88001ee0() knlGS: [4.878127] CS: 0010 DS: ES: CR0: 8005003b [4.878127] CR2: CR3: 01c0c000 CR4: 06f0 [4.878127] Stack: [4.878127] fffb1a454390 821a4500 88001a454390 0100 [4.878127] 88001ee03ea8 81083e9a 81083e15 82d5ed40 [4.878127] 8258cc60 81ac39de [4.878127] Call Trace: [4.878127] [4.878127] [] call_timer_fn+0x8a/0x310 [4.878127] [] ? call_timer_fn+0x5/0x310 [4.878127] [] ? pid_param_set+0x130/0x130 [4.878127] [] run_timer_softirq+0x234/0x380 [4.878127] [] __do_softirq+0x104/0x430 [4.878127] [] irq_exit+0xcd/0xe0 [4.878127] [] smp_apic_timer_interrupt+0x45/0x60 [4.878127] [] apic_timer_interrupt+0x72/0x80 [4.878127] [4.878127] [] ? vprintk_emit+0x1dd/0x5e0 [4.878127] [] printk+0x67/0x69 [4.878127] [] __cpufreq_add_dev.isra.13+0x883/0x8d0 [4.878127] [] cpufreq_add_dev+0x10/0x20 [4.878127] [] subsys_interface_register+0xb1/0xf0 [4.878127] [] cpufreq_register_driver+0x9f/0x210 [4.878127] [] intel_pstate_init+0x27d/0x3be [4.878127] [] ? mutex_unlock+0xe/0x10 [4.878127] [] ? cpufreq_gov_dbs_init+0x12/0x12 [4.878127] [] do_one_initcall+0xfa/0x1b0 [4.878127] [] ? parse_args+0x225/0x3f0 [4.878127] [] kernel_init_freeable+0x1fc/0x287 [4.878127] [] ? do_early_param+0x88/0x88 [4.878127] [] ? rest_init+0x150/0x150 [4.878127] [] kernel_init+0xe/0x130 [4.878127] [] ret_from_fork+0x7c/0xb0 [4.878127] [] ? rest_init+0x150/0x150 [4.878127] Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89 [4.878127] RIP [] intel_pstate_timer_func+0x11d/0x2b0 [4.878127] RSP [5.438189] ---[ end trace f166110ed22cc37a ]--- [5.446428] Kernel panic - not syncing: Fatal exception in interrupt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] dmaengine: Add support for BCM2835
Group: This is a request to augment with comments the DREQ explanation in the Broadcom BCM2835 pdf on page 61 regarding DMA peripheral mapping. Specifically, how to identify a pin on the 26 pin header to use for DMA reads. More specifically, if a clock signal, like GPCLK0 is output to the peripheral device (like an A/D converter) how we specify PERMAP in the DMA TI register. Your users would be infinitely grateful. thank you, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: firmware: new "platform microcode" warning in v3.13-rc1+
At Tue, 24 Dec 2013 09:15:09 +0800,
Ming Lei wrote:
>
> Hi,
>
> On Mon, Dec 2, 2013 at 1:32 AM, Paul Bolle wrote:
> > 0) Booting v3.13-rc1 and v3.13-rc2 triggers two new warnings on an
> > (outdated, I'm afraid) ThinkPad X41:
> > [...]
> > <6>[ 16.746119] libipw: 802.11 data/management/control stack,
> > git-1.1.13
> > <6>[ 16.746125] libipw: Copyright (C) 2004-2005 Intel Corporation
> >
> > <4>[ 16.761998] platform microcode: Direct firmware load failed with
> > error -2
> > <4>[ 16.762022] platform microcode: Falling back to user helper
> > <6>[ 16.787885] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network
> > Driver, 1.2.2kmprq
> > <6>[ 16.787895] ipw2200: Copyright(c) 2003-2006 Intel Corporation
> > <6>[ 16.788741] ipw2200: Detected Intel PRO/Wireless 2915ABG Network
> > Connection
> > [...]
> >
> > (I've added the surrounding lines because they suggest this is about the
> > firmware for that wireless device. Please note that this device appears
> > to work no worse than it did under v3.12.)
> >
> > 1) These warnings can be traced back to commit 3e358ac2bb5b ("firmware:
> > Be a bit more verbose about direct firmware loading failure").
>
> Yes, the warning was introduced in the commit since Neil thought it
> is needed.
The current behavior isn't much useful as is, unfortunately. It just
warns that the firmware loading failed, but it doesn't tell you
*which* firmware failed.
> > 2) Is there something I'm supposed to do to silence these warnings? If
> > so, what would that be? If not, can these messages perhaps be downgraded
> > to dev_info or dev_notice?
>
> Currently the messages are dumped via dev_warn(), and it is a bit difficult
> to make policy about the warning: sounds like Neil need them, and you
> don't like them, :-)
IMO, dev_warning() is too much in a case like Intel wifi driver. It
retries with different firmware revision when the latest firmware
doesn't exist, so the missing firmware isn't always a problem.
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] cgroup fixes for v3.13-rc5
Hey, Linus. Two fixes. One fixes a bug in the error path of cgroup_create(). The other changes cgrp->id lifetime rule so that the id doesn't get recycled before all controller states are destroyed. This premature id recycling made memcg malfunction. The following changes since commit e605b36575e896edd8161534550c9ea021b03bc0: cgroup: fix cgroup_subsys_state leak for seq_files (2013-11-27 18:16:21 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.13-fixes for you to fetch changes up to c1a71504e9715812a2d15e7c03b5aa147ae70ded: cgroup: don't recycle cgroup id until all csses' have been destroyed (2013-12-17 08:11:52 -0500) Thanks. Li Zefan (1): cgroup: don't recycle cgroup id until all csses' have been destroyed Tejun Heo (1): cgroup: fix cgroup_create() error handling path kernel/cgroup.c | 50 -- 1 file changed, 32 insertions(+), 18 deletions(-) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] percpu fixes for v3.13-rc5
Hello, Linus. A single commit to fix a spurious sparse warning coming from DEFINE_PER_CPU()'s hack to support the use of weak symbols. Shouldn't cause observable behavior change. The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-3.13-fixes for you to fetch changes up to b1a0fbfdde65dffd83c84c006f84fa12041907c5: percpu: fix spurious sparse warnings from DEFINE_PER_CPU() (2013-12-05 12:59:23 -0500) Thanks. Tejun Heo (1): percpu: fix spurious sparse warnings from DEFINE_PER_CPU() include/linux/percpu-defs.h | 1 + 1 file changed, 1 insertion(+) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/20] net: slight optimization of addr compare for some modules
On Tue, 2013-12-24 at 19:27 +0800, Ding Tianhong wrote:
> Use possibly more efficient ether_addr_equal_unaligned
> and ether_addr_equal to instead of memcmp.
A negative of adding so many different drivers in a single
patch is that you miss sending patches to the named maintainers.
Most of these below have separate individual maintainers.
(a suggested patch below this too)
> drivers/net/bonding/bond_3ad.c| 2 +-
> drivers/net/ethernet/3com/3c509.c | 3 +--
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c| 10 --
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c| 2 +-
> drivers/net/ethernet/chelsio/cxgb3/l2t.c | 2 +-
> drivers/net/ethernet/cisco/enic/enic_pp.c | 2 +-
> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
> drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 3 +--
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c| 4 ++--
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
> drivers/net/ethernet/micrel/ksz884x.c | 9 -
> drivers/net/ethernet/neterion/vxge/vxge-main.c| 2 +-
> drivers/net/ethernet/packetengines/yellowfin.c| 8 ++--
> drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c| 2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c| 4 ++--
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c| 4 ++--
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 4 ++--
> drivers/net/ethernet/renesas/sh_eth.c | 2 +-
> drivers/net/ethernet/seeq/sgiseeq.c | 2 +-
> drivers/net/ethernet/sun/sunvnet.c| 2 +-
> drivers/net/ethernet/ti/cpsw_ale.c| 2 +-
> drivers/net/fddi/skfp/fplustm.c | 3 ++-
> drivers/net/plip/plip.c | 2 +-
> net/caif/cfrfml.c | 2 +-
> 27 files changed, 39 insertions(+), 47 deletions(-)
Also for bonding, my preference would be to rename
the macro and use ether_addr_equal as it seems that
all references are u16 aligned.
I also removed some superfluous parentheses.
---
drivers/net/bonding/bond_3ad.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 187b1b7..ae56983 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -91,7 +91,8 @@
//endalloun
// compare MAC addresses
-#define MAC_ADDRESS_COMPARE(A, B) memcmp(A, B, ETH_ALEN)
+#define MAC_ADDRESS_EQUAL(A, B)\
+ ether_addr_equal((const u8 *)A, (const u8 *)B)
static struct mac_addr null_mac_addr = { { 0, 0, 0, 0, 0, 0 } };
static u16 ad_ticks_per_sec;
@@ -419,7 +420,7 @@ static void __choose_matched(struct lacpdu *lacpdu, struct
port *port)
// check if all parameters are alike
if (((ntohs(lacpdu->partner_port) == port->actor_port_number) &&
(ntohs(lacpdu->partner_port_priority) ==
port->actor_port_priority) &&
-!MAC_ADDRESS_COMPARE(&(lacpdu->partner_system),
&(port->actor_system)) &&
+MAC_ADDRESS_EQUAL(>partner_system, >actor_system) &&
(ntohs(lacpdu->partner_system_priority) ==
port->actor_system_priority) &&
(ntohs(lacpdu->partner_key) == port->actor_oper_port_key) &&
((lacpdu->partner_state & AD_STATE_AGGREGATION) ==
(port->actor_oper_port_state & AD_STATE_AGGREGATION))) ||
@@ -509,7 +510,7 @@ static void __update_selected(struct lacpdu *lacpdu, struct
port *port)
// check if any parameter is different
if (ntohs(lacpdu->actor_port) != partner->port_number ||
ntohs(lacpdu->actor_port_priority) !=
partner->port_priority ||
- MAC_ADDRESS_COMPARE(>actor_system,
>system) ||
+ !MAC_ADDRESS_EQUAL(>actor_system, >system)
||
ntohs(lacpdu->actor_system_priority) !=
partner->system_priority ||
ntohs(lacpdu->actor_key) != partner->key ||
(lacpdu->actor_state & AD_STATE_AGGREGATION) !=
(partner->port_state & AD_STATE_AGGREGATION)) {
@@ -540,7 +541,7 @@ static void __update_default_selected(struct port *port)
// check if any parameter is different
if (admin->port_number != oper->port_number ||
admin->port_priority != oper->port_priority ||
- MAC_ADDRESS_COMPARE(>system, >system) ||
+ !MAC_ADDRESS_EQUAL(>system, >system) ||
admin->system_priority != oper->system_priority ||
admin->key != oper->key ||
[GIT PULL] libata fixes for v3.13-rc5
Hello, Linus. libata fixes for v3.13-rc5. There's one interseting commit - "libata, freezer: avoid block device removal while system is frozen". It's an ugly hack working around a deadlock condition between driver core resume and block layer device removal paths through freezer which was made more reproducible by writeback being converted to workqueue some releases ago. The bug has nothing to do with libata but it's just an workaround which is easy to backport. After discussion, Rafael and I seem to agree that we don't really need kernel freezables - both kthread and workqueue. There are few specific workqueues which constitute PM operations and require freezing, which will be converted to use workqueue_set_max_active() instead. All other kernel freezer uses are planned to be removed, followed by the removal of kthread and workqueue freezer support, hopefully. Others are device-specific fixes. The most notable is the addition of NO_NCQ_TRIM which is used to disable queued TRIM commands to Micro M500 SSDs which otherwise suffers data corruption. The following changes since commit c5700766975c69d27150256444db63fbfd103791: ATA: Fix port removal ordering (2013-11-27 13:55:16 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.13-fixes for you to fetch changes up to 85fbd722ad0f5d64d1ad15888cd1eb2188bfb557: libata, freezer: avoid block device removal while system is frozen (2013-12-19 13:50:32 -0500) Thanks. Marc Carino (1): libata: implement ATA_HORKAGE_NO_NCQ_TRIM and apply it to Micro M500 SSDs Marek Vasut (1): ahci: imx: Explicitly clear IMX6Q_GPR13_SATA_MPLL_CLK_EN Michele Baldessari (1): libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 Paul Bolle (1): ahci: bail out on ICH6 before using AHCI BAR Robin H. Johnson (1): libata: disable a disk via libata.force params Tejun Heo (1): libata, freezer: avoid block device removal while system is frozen Documentation/kernel-parameters.txt | 2 ++ drivers/ata/ahci.c | 18 +- drivers/ata/ahci_imx.c | 3 ++- drivers/ata/libata-core.c | 19 +-- drivers/ata/libata-scsi.c | 21 + include/linux/libata.h | 1 + kernel/freezer.c| 6 ++ 7 files changed, 58 insertions(+), 12 deletions(-) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
