Re: [ANNOUNCE] 3.12.6-rt9
On Sat, 28 Dec 2013, Mike Galbraith wrote: > On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote: > > > (Less than wonderful changelogs probably comes from the fact that > > maintaining -rt out of tree is time consuming as all hell. Everybody > > gets to breaks it, a couple guys get to fix it up again and again.) > > P.S. try rolling your tree forward to master or tip for entertainment, > you'll see what I mean. Hi Peter, Rik.. other breakers of worlds :) > protesting exernal breakage by ameding -rt with home-made landmines does sound like an optimized entertainment strategy... This type of blowups will not help to go mainline (refereing to 3.12.X here, 3.4/6/8/10 is a different story). thx! hofrat -- 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 net-next v2 20/20] net: caif: slight optimization of addr compare
On Sat, 2013-12-28 at 14:18 +0800, Ding Tianhong wrote: > Use possibly more efficient ether_addr_equal > to instead of memcmp. This may be a distinction without difference, but is a CAIF seghead also an ethernet address? > diff --git a/net/caif/cfrfml.c b/net/caif/cfrfml.c [] > @@ -79,7 +79,7 @@ static struct cfpkt *rfm_append(struct cfrfml *rfml, char > *seghead, [] > /* Verify correct header */ > - if (memcmp(seghead, rfml->seghead, 6) != 0) > + if (!ether_addr_equal(seghead, rfml->seghead)) -- 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 net-next v2 03/20] net: cxgb3: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Santosh Raspatur
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 2 +-
drivers/net/ethernet/chelsio/cxgb3/l2t.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
index 76ae0999..c0a9dd5 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
@@ -182,7 +182,7 @@ static struct net_device *get_iff_from_mac(struct adapter
*adapter,
for_each_port(adapter, i) {
struct net_device *dev = adapter->port[i];
- if (!memcmp(dev->dev_addr, mac, ETH_ALEN)) {
+ if (ether_addr_equal(dev->dev_addr, mac)) {
rcu_read_lock();
if (vlan && vlan != VLAN_VID_MASK) {
dev = __vlan_find_dev_deep(dev,
htons(ETH_P_8021Q), vlan);
diff --git a/drivers/net/ethernet/chelsio/cxgb3/l2t.c
b/drivers/net/ethernet/chelsio/cxgb3/l2t.c
index 8d53438..5f226ed 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/l2t.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/l2t.c
@@ -429,7 +429,7 @@ found:
} else {
e->state = neigh->nud_state & NUD_CONNECTED ?
L2T_STATE_VALID : L2T_STATE_STALE;
- if (memcmp(e->dmac, neigh->ha, 6))
+ if (!ether_addr_equal(e->dmac, neigh->ha))
setup_l2e_send_pending(dev, NULL, e);
}
}
--
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: [BUGREPORT] Linux USB 3.0
just received following log snippset: Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.177695] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.217966] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.277473] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.317753] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.377242] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.417514] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.477000] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.517279] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.576761] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.617074] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.676581] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.716852] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.776340] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.816589] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:51 solist kernel: [ 36.876117] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr the previous bug report of that user: https://bugzilla.kernel.org/show_bug.cgi?id=65021 xhci: complete USB freeze On Fri, Dec 27, 2013 at 8:59 PM, Markus Rechberger wrote: > Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately > we don't have such a board for testing and customer patience is > limited to bisect the kernel. > > Does anyone have a clue what modification could have killed USB 3.0 > support within those releases? > It does not seem to be SG support. > > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger > wrote: >> I just got another USB 3.0 bugreport, the entire system crashed. That >> particular customer already filed a bugreport in November 2013 that >> his system is in a bad state when using some USB 2.0 media devices >> which even have opensource drivers built into the kernel. >> >> USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. >> The affected board is an Intel DH87RL board. >> >> On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger >> wrote: >>> 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
[PATCH net-next v2 00/20] slight optimization of addr compare for net modules
This is the second patchset for slight optimization of address compare, mainly for net tree, just following the Joe's opinion, it will help review the code for maintainers and supports. v2: Change some style for patch 2. According Eric's suggestion, use the ether_addr_equal_64bits to instead of ether_addr_equal for patch 19. In fact, there are a lot of places which could use ether_addr_equal_64bits to instead of ether_addr_equal, but not this time, thanks for Joe's opinion. Best Regards Ding Ding Tianhong (20): net: 3com: slight optimization of addr compare net: bnx2x: slight optimization of addr compare net: cxgb3: slight optimization of addr compare net: enic: slight optimization of addr compare net: benet: slight optimization of addr compare net: igbvf: slight optimization of addr compare net: ixgbe: slight optimization of addr compare net: mlx4: slight optimization of addr compare net: ksz884x: slight optimization of addr compare net: vxge: slight optimization of addr compare net: packetengines: slight optimization of addr compare net: netxen: slight optimization of addr compare net: qlcnic: slight optimization of addr compare net: renesas: slight optimization of addr compare net: seeq: slight optimization of addr compare net: sun: optimization of addr compare net: ti: slight optimization of addr compare net: fddi: slight optimization of addr compare net: plip: slight optimization of addr compare net: caif: slight optimization of addr compare 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 +- 26 files changed, 38 insertions(+), 46 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 net-next v2 02/20] net: bnx2x: slight optimization of addr compare
Use the possibly more efficient ether_addr_equal or
ether_addr_equal_unaligned to instead of memcmp.
Cc: Ariel Elior
Cc: Sergei Shtylyov
Signed-off-by: Ding Tianhong
---
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 +-
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
index 32c92ab..a83c67c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
@@ -663,7 +663,7 @@ static int bnx2x_check_mac_add(struct bnx2x *bp,
/* Check if a requested MAC already exists */
list_for_each_entry(pos, >head, link)
- if (!memcmp(data->mac.mac, pos->u.mac.mac, ETH_ALEN) &&
+ if (ether_addr_equal(data->mac.mac, pos->u.mac.mac) &&
(data->mac.is_inner_mac == pos->u.mac.is_inner_mac))
return -EEXIST;
@@ -696,8 +696,7 @@ static int bnx2x_check_vlan_mac_add(struct bnx2x *bp,
list_for_each_entry(pos, >head, link)
if ((data->vlan_mac.vlan == pos->u.vlan_mac.vlan) &&
- (!memcmp(data->vlan_mac.mac, pos->u.vlan_mac.mac,
- ETH_ALEN)) &&
+ ether_addr_equal_unaligned(data->vlan_mac.mac,
pos->u.vlan_mac.mac) &&
(data->vlan_mac.is_inner_mac ==
pos->u.vlan_mac.is_inner_mac))
return -EEXIST;
@@ -716,7 +715,7 @@ static struct bnx2x_vlan_mac_registry_elem *
DP(BNX2X_MSG_SP, "Checking MAC %pM for DEL command\n", data->mac.mac);
list_for_each_entry(pos, >head, link)
- if ((!memcmp(data->mac.mac, pos->u.mac.mac, ETH_ALEN)) &&
+ if (ether_addr_equal(data->mac.mac, pos->u.mac.mac) &&
(data->mac.is_inner_mac == pos->u.mac.is_inner_mac))
return pos;
@@ -751,8 +750,7 @@ static struct bnx2x_vlan_mac_registry_elem *
list_for_each_entry(pos, >head, link)
if ((data->vlan_mac.vlan == pos->u.vlan_mac.vlan) &&
- (!memcmp(data->vlan_mac.mac, pos->u.vlan_mac.mac,
-ETH_ALEN)) &&
+ ether_addr_equal_unaligned(data->vlan_mac.mac,
pos->u.vlan_mac.mac) &&
(data->vlan_mac.is_inner_mac ==
pos->u.vlan_mac.is_inner_mac))
return pos;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 2e46c28..040276b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -3605,7 +3605,7 @@ enum sample_bulletin_result bnx2x_sample_bulletin(struct
bnx2x *bp)
/* the mac address in bulletin board is valid and is new */
if (bulletin.valid_bitmap & 1 << MAC_ADDR_VALID &&
- memcmp(bulletin.mac, bp->old_bulletin.mac, ETH_ALEN)) {
+ !ether_addr_equal(bulletin.mac, bp->old_bulletin.mac)) {
/* update new mac to net device */
memcpy(bp->dev->dev_addr, bulletin.mac, ETH_ALEN);
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index efa8a15..4d2ae15 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -1702,7 +1702,7 @@ static void bnx2x_vf_mbx_set_q_filters(struct bnx2x *bp,
/* ...and only the mac set by the ndo */
if (filters->n_mac_vlan_filters == 1 &&
- memcmp(filters->filters->mac, bulletin->mac, ETH_ALEN)) {
+ !ether_addr_equal(filters->filters->mac, bulletin->mac)) {
BNX2X_ERR("VF[%d] requested the addition of a mac
address not matching the one configured by set_vf_mac ndo\n",
vf->abs_vfid);
--
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 net-next v2 06/20] net: igbvf: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: Jeff Kirsher Cc: Jesse Brandeburg Cc: Carolyn Wyborny Cc: Don Skidmore Signed-off-by: Ding Tianhong --- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c index 04bf22e..675435f 100644 --- a/drivers/net/ethernet/intel/igbvf/netdev.c +++ b/drivers/net/ethernet/intel/igbvf/netdev.c @@ -1745,7 +1745,7 @@ static int igbvf_set_mac(struct net_device *netdev, void *p) hw->mac.ops.rar_set(hw, hw->mac.addr, 0); - if (memcmp(addr->sa_data, hw->mac.addr, 6)) + if (!ether_addr_equal(addr->sa_data, hw->mac.addr)) return -EADDRNOTAVAIL; memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len); -- 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 net-next v2 07/20] net: ixgbe: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Jeff Kirsher
Cc: Jesse Brandeburg
Cc: Bruce Allan
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index d6f0c0d..9ce07f3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -715,8 +715,7 @@ static int ixgbe_set_vf_mac_addr(struct ixgbe_adapter
*adapter,
}
if (adapter->vfinfo[vf].pf_set_mac &&
- memcmp(adapter->vfinfo[vf].vf_mac_addresses, new_mac,
- ETH_ALEN)) {
+ !ether_addr_equal(adapter->vfinfo[vf].vf_mac_addresses, new_mac)) {
e_warn(drv,
"VF %d attempted to override administratively set MAC
address\n"
"Reload the VF driver to resume operations\n",
--
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 net-next v2 09/20] net: ksz884x: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/micrel/ksz884x.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ksz884x.c
b/drivers/net/ethernet/micrel/ksz884x.c
index ddd252a..8e9dad7 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -4128,10 +4128,10 @@ static int hw_add_addr(struct ksz_hw *hw, u8 *mac_addr)
int i;
int j = ADDITIONAL_ENTRIES;
- if (!memcmp(hw->override_addr, mac_addr, ETH_ALEN))
+ if (ether_addr_equal(hw->override_addr, mac_addr))
return 0;
for (i = 0; i < hw->addr_list_size; i++) {
- if (!memcmp(hw->address[i], mac_addr, ETH_ALEN))
+ if (ether_addr_equal(hw->address[i], mac_addr))
return 0;
if (ADDITIONAL_ENTRIES == j && empty_addr(hw->address[i]))
j = i;
@@ -4149,7 +4149,7 @@ static int hw_del_addr(struct ksz_hw *hw, u8 *mac_addr)
int i;
for (i = 0; i < hw->addr_list_size; i++) {
- if (!memcmp(hw->address[i], mac_addr, ETH_ALEN)) {
+ if (ether_addr_equal(hw->address[i], mac_addr)) {
memset(hw->address[i], 0, ETH_ALEN);
writel(0, hw->io + ADD_ADDR_INCR * i +
KS_ADD_ADDR_0_HI);
@@ -7104,8 +7104,7 @@ static int pcidev_init(struct pci_dev *pdev, const struct
pci_device_id *id)
ETH_ALEN);
else {
memcpy(dev->dev_addr, sw->other_addr, ETH_ALEN);
- if (!memcmp(sw->other_addr, hw->override_addr,
- ETH_ALEN))
+ if (ether_addr_equal(sw->other_addr, hw->override_addr))
dev->dev_addr[5] += port->first_port;
}
--
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 net-next v2 05/20] net: benet: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Sathya Perla
Cc: Subbu Seetharaman
Cc: Ajit Khaparde
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index f67586a..b5c238a 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -287,7 +287,7 @@ static int be_mac_addr_set(struct net_device *netdev, void
*p)
/* The MAC change did not happen, either due to lack of privilege
* or PF didn't pre-provision.
*/
- if (memcmp(addr->sa_data, mac, ETH_ALEN)) {
+ if (!ether_addr_equal(addr->sa_data, mac)) {
status = -EPERM;
goto err;
}
--
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 net-next v2 10/20] net: vxge: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Jon Mason
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/neterion/vxge/vxge-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c
b/drivers/net/ethernet/neterion/vxge/vxge-main.c
index 11b1c70..6eae216 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
@@ -1430,7 +1430,7 @@ vxge_search_mac_addr_in_da_table(struct vxge_vpath
*vpath, struct macInfo *mac)
return status;
}
- while (memcmp(mac->macaddr, macaddr, ETH_ALEN)) {
+ while (!ether_addr_equal(mac->macaddr, macaddr)) {
status = vxge_hw_vpath_mac_addr_get_next(vpath->handle,
macaddr, macmask);
if (status != VXGE_HW_OK)
--
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 net-next v2 12/20] net: netxen: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Manish Chopra
Cc: Sony Chacko
Cc: Rajesh Borundia
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index b72b6be..db4280c 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -661,7 +661,7 @@ static int nx_p3_nic_add_mac(struct netxen_adapter *adapter,
list_for_each(head, del_list) {
cur = list_entry(head, nx_mac_list_t, list);
- if (memcmp(addr, cur->mac_addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(addr, cur->mac_addr)) {
list_move_tail(head, >mac_list);
return 0;
}
--
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 net-next v2 16/20] net: sun: optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/sun/sunvnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c
b/drivers/net/ethernet/sun/sunvnet.c
index 3df5684..1c24a8f 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -751,7 +751,7 @@ static struct vnet_mcast_entry *__vnet_mc_find(struct vnet
*vp, u8 *addr)
struct vnet_mcast_entry *m;
for (m = vp->mcast_list; m; m = m->next) {
- if (!memcmp(m->addr, addr, ETH_ALEN))
+ if (ether_addr_equal(m->addr, addr))
return m;
}
return NULL;
--
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 net-next v2 14/20] net: renesas: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers/net/ethernet/renesas/sh_eth.c
index ca742e1..2d00bce 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2207,7 +2207,7 @@ static int sh_eth_tsu_find_entry(struct net_device *ndev,
const u8 *addr)
for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES; i++, reg_offset += 8) {
sh_eth_tsu_read_entry(reg_offset, c_addr);
- if (memcmp(addr, c_addr, ETH_ALEN) == 0)
+ if (ether_addr_equal(addr, c_addr))
return 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 net-next v2 17/20] net: ti: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: "David S. Miller" Signed-off-by: Ding Tianhong --- drivers/net/ethernet/ti/cpsw_ale.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c index 7fa60d6..63e9819 100644 --- a/drivers/net/ethernet/ti/cpsw_ale.c +++ b/drivers/net/ethernet/ti/cpsw_ale.c @@ -163,7 +163,7 @@ int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid) if (cpsw_ale_get_vlan_id(ale_entry) != vid) continue; cpsw_ale_get_addr(ale_entry, entry_addr); - if (memcmp(entry_addr, addr, 6) == 0) + if (ether_addr_equal(entry_addr, addr)) return idx; } return -ENOENT; -- 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 net-next v2 13/20] net: qlcnic: slight optimization of addr compare
Use the possibly more efficient ether_addr_equal or
ether_addr_equal_unaligned to instead of memcmp.
Cc: Himanshu Madhani
Cc: Rajesh Borundia
Signed-off-by: Ding Tianhong
---
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 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index 3fe971c..a9a149b 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -462,7 +462,7 @@ int qlcnic_nic_del_mac(struct qlcnic_adapter *adapter,
const u8 *addr)
/* Delete MAC from the existing list */
list_for_each(head, >mac_list) {
cur = list_entry(head, struct qlcnic_mac_vlan_list, list);
- if (memcmp(addr, cur->mac_addr, ETH_ALEN) == 0) {
+ if (ether_addr_equal(addr, cur->mac_addr)) {
err = qlcnic_sre_macaddr_change(adapter, cur->mac_addr,
0, QLCNIC_MAC_DEL);
if (err)
@@ -483,7 +483,7 @@ int qlcnic_nic_add_mac(struct qlcnic_adapter *adapter,
const u8 *addr, u16 vlan)
/* look up if already exists */
list_for_each(head, >mac_list) {
cur = list_entry(head, struct qlcnic_mac_vlan_list, list);
- if (memcmp(addr, cur->mac_addr, ETH_ALEN) == 0 &&
+ if (ether_addr_equal(addr, cur->mac_addr) &&
cur->vlan_id == vlan)
return 0;
}
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 0538022..a215e0f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -202,7 +202,7 @@ static struct qlcnic_filter *qlcnic_find_mac_filter(struct
hlist_head *head,
struct hlist_node *n;
hlist_for_each_entry_safe(tmp_fil, n, head, fnode) {
- if (!memcmp(tmp_fil->faddr, addr, ETH_ALEN) &&
+ if (ether_addr_equal(tmp_fil->faddr, addr) &&
tmp_fil->vlan_id == vlan_id)
return tmp_fil;
}
@@ -346,7 +346,7 @@ static void qlcnic_send_filter(struct qlcnic_adapter
*adapter,
head = &(adapter->fhash.fhead[hindex]);
hlist_for_each_entry_safe(tmp_fil, n, head, fnode) {
- if (!memcmp(tmp_fil->faddr, _addr, ETH_ALEN) &&
+ if (ether_addr_equal(tmp_fil->faddr, _addr) &&
tmp_fil->vlan_id == vlan_id) {
if (jiffies > (QLCNIC_READD_AGE * HZ + tmp_fil->ftime))
qlcnic_change_filter(adapter, _addr,
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index bf132c9..d131ec1 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -313,7 +313,7 @@ static void qlcnic_delete_adapter_mac(struct qlcnic_adapter
*adapter)
list_for_each(head, >mac_list) {
cur = list_entry(head, struct qlcnic_mac_vlan_list, list);
- if (!memcmp(adapter->mac_addr, cur->mac_addr, ETH_ALEN)) {
+ if (ether_addr_equal_unaligned(adapter->mac_addr,
cur->mac_addr)) {
qlcnic_sre_macaddr_change(adapter, cur->mac_addr,
0, QLCNIC_MAC_DEL);
list_del(>list);
@@ -337,7 +337,7 @@ static int qlcnic_set_mac(struct net_device *netdev, void
*p)
if (!is_valid_ether_addr(addr->sa_data))
return -EINVAL;
- if (!memcmp(adapter->mac_addr, addr->sa_data, ETH_ALEN))
+ if (ether_addr_equal_unaligned(adapter->mac_addr, addr->sa_data))
return 0;
if (test_bit(__QLCNIC_DEV_UP, >state)) {
--
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 net-next v2 18/20] net: fddi: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: "David S. Miller" Signed-off-by: Ding Tianhong --- drivers/net/fddi/skfp/fplustm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/fddi/skfp/fplustm.c b/drivers/net/fddi/skfp/fplustm.c index d918d8a..7d3779a 100644 --- a/drivers/net/fddi/skfp/fplustm.c +++ b/drivers/net/fddi/skfp/fplustm.c @@ -23,6 +23,7 @@ #include "h/smc.h" #include "h/supern_2.h" #include +#include #ifndeflint static const char ID_sccs[] = "@(#)fplustm.c 1.32 99/02/23 (C) SK " ; @@ -1082,7 +1083,7 @@ static struct s_fpmc* mac_get_mc_table(struct s_smc *smc, slot = tb ; continue ; } - if (memcmp((char *)>a,(char *)own,6)) + if (!ether_addr_equal((char *)>a, (char *)own)) continue ; return tb; } -- 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 net-next v2 15/20] net: seeq: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/seeq/sgiseeq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
b/drivers/net/ethernet/seeq/sgiseeq.c
index c765718..ced5b13 100644
--- a/drivers/net/ethernet/seeq/sgiseeq.c
+++ b/drivers/net/ethernet/seeq/sgiseeq.c
@@ -356,7 +356,7 @@ static inline void sgiseeq_rx(struct net_device *dev,
struct sgiseeq_private *sp
if (pkt_status & SEEQ_RSTAT_FIG) {
/* Packet is OK. */
/* We don't want to receive our own packets */
- if (memcmp(rd->skb->data + 6, dev->dev_addr, ETH_ALEN))
{
+ if (!ether_addr_equal(rd->skb->data + 6,
dev->dev_addr)) {
if (len > rx_copybreak) {
skb = rd->skb;
newskb = netdev_alloc_skb(dev,
PKT_BUF_SZ);
--
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 net-next v2 19/20] net: plip: slight optimization of addr compare
Use possibly more efficient ether_addr_equal_64bits
to instead of memcmp.
Cc: "David S. Miller"
Suggested-by: Eric Dumazet
Signed-off-by: Ding Tianhong
---
drivers/net/plip/plip.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index 7b4ff35..040b897 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -547,9 +547,9 @@ static __be16 plip_type_trans(struct sk_buff *skb, struct
net_device *dev)
skb_pull(skb,dev->hard_header_len);
eth = eth_hdr(skb);
- if(*eth->h_dest&1)
+ if(is_multicast_ether_addr(eth->h_dest))
{
- if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
+ if(ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
skb->pkt_type=PACKET_BROADCAST;
else
skb->pkt_type=PACKET_MULTICAST;
--
1.6.0.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 net-next v2 20/20] net: caif: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: Dmitry Tarnyagin Cc: "David S. Miller" Signed-off-by: Ding Tianhong --- net/caif/cfrfml.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/caif/cfrfml.c b/net/caif/cfrfml.c index 61d7617..c680414 100644 --- a/net/caif/cfrfml.c +++ b/net/caif/cfrfml.c @@ -79,7 +79,7 @@ static struct cfpkt *rfm_append(struct cfrfml *rfml, char *seghead, return NULL; /* Verify correct header */ - if (memcmp(seghead, rfml->seghead, 6) != 0) + if (!ether_addr_equal(seghead, rfml->seghead)) return NULL; tmppkt = cfpkt_append(rfml->incomplete_frm, pkt, -- 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 net-next v2 08/20] net: mlx4: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: Amir Vadai
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c| 4 ++--
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 6f92090..7e43858 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -782,7 +782,7 @@ static void update_mclist_flags(struct mlx4_en_priv *priv,
list_for_each_entry(dst_tmp, dst, list) {
found = false;
list_for_each_entry(src_tmp, src, list) {
- if (!memcmp(dst_tmp->addr, src_tmp->addr, ETH_ALEN)) {
+ if (ether_addr_equal(dst_tmp->addr, src_tmp->addr)) {
found = true;
break;
}
@@ -797,7 +797,7 @@ static void update_mclist_flags(struct mlx4_en_priv *priv,
list_for_each_entry(src_tmp, src, list) {
found = false;
list_for_each_entry(dst_tmp, dst, list) {
- if (!memcmp(dst_tmp->addr, src_tmp->addr, ETH_ALEN)) {
+ if (ether_addr_equal(dst_tmp->addr, src_tmp->addr)) {
dst_tmp->action = MCLIST_NONE;
found = true;
break;
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 2f3f2bc..2e3232c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -3634,7 +3634,7 @@ static int validate_eth_header_mac(int slave, struct
_rule_hw *eth_header,
!is_broadcast_ether_addr(eth_header->eth.dst_mac)) {
list_for_each_entry_safe(res, tmp, rlist, list) {
be_mac = cpu_to_be64(res->mac << 16);
- if (!memcmp(_mac, eth_header->eth.dst_mac, ETH_ALEN))
+ if (ether_addr_equal((u8 *)_mac,
eth_header->eth.dst_mac))
return 0;
}
pr_err("MAC %pM doesn't belong to VF %d, Steering rule
rejected\n",
--
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 net-next v2 01/20] net: 3com: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/3com/3c509.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c509.c
b/drivers/net/ethernet/3com/3c509.c
index ede8daa..9142b47 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -252,8 +252,7 @@ static int el3_isa_id_sequence(__be16 *phys_addr)
for (i = 0; i < el3_cards; i++) {
struct el3_private *lp = netdev_priv(el3_devs[i]);
if (lp->type == EL3_PNP &&
- !memcmp(phys_addr, el3_devs[i]->dev_addr,
- ETH_ALEN)) {
+ ether_addr_equal(phys_addr, el3_devs[i]->dev_addr))
{
if (el3_debug > 3)
pr_debug("3c509 with address %02x %02x
%02x %02x %02x %02x was found by ISAPnP\n",
phys_addr[0] & 0xff,
phys_addr[0] >> 8,
--
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 net-next v2 04/20] net: enic: slight optimization of addr compare
Use possibly more efficient ether_addr_equal to instead of memcmp. Cc: Christian Benvenuti Cc: Sujith Sankar Cc: Govindarajulu Varadarajan Cc: Neel Patel Cc: Nishank Trivedi Signed-off-by: Ding Tianhong --- drivers/net/ethernet/cisco/enic/enic_pp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cisco/enic/enic_pp.c b/drivers/net/ethernet/cisco/enic/enic_pp.c index 43464f0..e6a8319 100644 --- a/drivers/net/ethernet/cisco/enic/enic_pp.c +++ b/drivers/net/ethernet/cisco/enic/enic_pp.c @@ -162,7 +162,7 @@ static int enic_are_pp_different(struct enic_port_profile *pp1, return strcmp(pp1->name, pp2->name) | !!memcmp(pp1->instance_uuid, pp2->instance_uuid, PORT_UUID_MAX) | !!memcmp(pp1->host_uuid, pp2->host_uuid, PORT_UUID_MAX) | - !!memcmp(pp1->mac_addr, pp2->mac_addr, ETH_ALEN); + !ether_addr_equal(pp1->mac_addr, pp2->mac_addr); } static int enic_pp_preassociate(struct enic *enic, int vf, -- 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 net-next v2 11/20] net: packetengines: slight optimization of addr
Use possibly more efficient ether_addr_equal
to instead of memcmp.
Cc: "David S. Miller"
Signed-off-by: Ding Tianhong
---
drivers/net/ethernet/packetengines/yellowfin.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/packetengines/yellowfin.c
b/drivers/net/ethernet/packetengines/yellowfin.c
index d28593b..b83ac0e 100644
--- a/drivers/net/ethernet/packetengines/yellowfin.c
+++ b/drivers/net/ethernet/packetengines/yellowfin.c
@@ -1097,12 +1097,12 @@ static int yellowfin_rx(struct net_device *dev)
if (status2 & 0x80) dev->stats.rx_dropped++;
#ifdef YF_PROTOTYPE/* Support for prototype hardware errata. */
} else if ((yp->flags & HasMACAddrBug) &&
- memcmp(le32_to_cpu(yp->rx_ring_dma +
- entry*sizeof(struct yellowfin_desc)),
- dev->dev_addr, 6) != 0 &&
- memcmp(le32_to_cpu(yp->rx_ring_dma +
- entry*sizeof(struct yellowfin_desc)),
- "\377\377\377\377\377\377", 6) != 0) {
+ !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
+ entry * sizeof(struct
yellowfin_desc)),
+ dev->dev_addr) &&
+ !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
+ entry * sizeof(struct
yellowfin_desc)),
+
"\377\377\377\377\377\377")) {
if (bogus_rx++ == 0)
netdev_warn(dev, "Bad frame to %pM\n",
buf_addr);
--
1.7.1
--
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 net-next 19/20] net: plip: slight optimization of addr compare
On 2013/12/28 13:11, Joe Perches wrote:
> On Sat, 2013-12-28 at 13:07 +0800, Ding Tianhong wrote:
>> On 2013/12/28 1:06, Joe Perches wrote:
>>> On Fri, 2013-12-27 at 07:48 -0800, Eric Dumazet wrote:
On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
> Use possibly more efficient ether_addr_equal
> to instead of memcmp.
>>> []
> diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
>>> []
> @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff *skb,
> struct net_device *dev)
>
> 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;
What about :
if (is_multicast_ether_addr(eth->h_dest)) {
if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
skb->pkt_type = PACKET_BROADCAST;
else
skb->pkt_type = PACKET_MULTICAST;
}
>>>
>>> That is better though I wonder how many systems are
>>> still using laplink via parallel null-printer cables.
>>>
>>> No matter, better is better.
>>>
>>> The same optimization using ether_addr_equal_64bits
>>> may be possible to do in other places given other
>>> structs too.
>>>
>>> Perhaps it's a possible spatch/coccinelle conversion,
>>>
>>> I don't know spatch well enough to know if a
>>> mechanism to check if structure members have other
>>> fields that follow them in the structure or if the
>>> structure member is an array of a minimum size.
>>>
>>> Maybe Julia does. (cc'd)
>>>
>>>
>> As the below patch said, that a lot of ether_addr_equal
>> could be instead of ether_addr_equal_64bits, and I need to
>> review them and resend.
>
> I don't think so.
>
> I think what you've done so far is fine.
>
> Any conversions to ether_addr_equal_64bit
> can be done later.
>
Ok, thanks.
Regards
Ding
>
>
>
--
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 net-next 19/20] net: plip: slight optimization of addr compare
On Sat, 2013-12-28 at 13:07 +0800, Ding Tianhong wrote:
> On 2013/12/28 1:06, Joe Perches wrote:
> > On Fri, 2013-12-27 at 07:48 -0800, Eric Dumazet wrote:
> >> On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
> >>> Use possibly more efficient ether_addr_equal
> >>> to instead of memcmp.
> > []
> >>> diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
> > []
> >>> @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff *skb,
> >>> struct net_device *dev)
> >>>
> >>> 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;
> >>
> >> What about :
> >>
> >> if (is_multicast_ether_addr(eth->h_dest)) {
> >> if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
> >> skb->pkt_type = PACKET_BROADCAST;
> >> else
> >> skb->pkt_type = PACKET_MULTICAST;
> >> }
> >
> > That is better though I wonder how many systems are
> > still using laplink via parallel null-printer cables.
> >
> > No matter, better is better.
> >
> > The same optimization using ether_addr_equal_64bits
> > may be possible to do in other places given other
> > structs too.
> >
> > Perhaps it's a possible spatch/coccinelle conversion,
> >
> > I don't know spatch well enough to know if a
> > mechanism to check if structure members have other
> > fields that follow them in the structure or if the
> > structure member is an array of a minimum size.
> >
> > Maybe Julia does. (cc'd)
> >
> >
> As the below patch said, that a lot of ether_addr_equal
> could be instead of ether_addr_equal_64bits, and I need to
> review them and resend.
I don't think so.
I think what you've done so far is fine.
Any conversions to ether_addr_equal_64bit
can be done later.
--
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 net-next 19/20] net: plip: slight optimization of addr compare
On 2013/12/28 1:06, Joe Perches wrote:
> On Fri, 2013-12-27 at 07:48 -0800, Eric Dumazet wrote:
>> On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
>>> Use possibly more efficient ether_addr_equal
>>> to instead of memcmp.
> []
>>> diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
> []
>>> @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff *skb,
>>> struct net_device *dev)
>>>
>>> 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;
>>
>> What about :
>>
>> if (is_multicast_ether_addr(eth->h_dest)) {
>> if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
>> skb->pkt_type = PACKET_BROADCAST;
>> else
>> skb->pkt_type = PACKET_MULTICAST;
>> }
>
> That is better though I wonder how many systems are
> still using laplink via parallel null-printer cables.
>
> No matter, better is better.
>
> The same optimization using ether_addr_equal_64bits
> may be possible to do in other places given other
> structs too.
>
> Perhaps it's a possible spatch/coccinelle conversion,
>
> I don't know spatch well enough to know if a
> mechanism to check if structure members have other
> fields that follow them in the structure or if the
> structure member is an array of a minimum size.
>
> Maybe Julia does. (cc'd)
>
>
As the below patch said, that a lot of ether_addr_equal
could be instead of ether_addr_equal_64bits, and I need to
review them and resend.
Regards
Ding
>
--
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 net-next 19/20] net: plip: slight optimization of addr compare
On 2013/12/27 23:48, Eric Dumazet wrote:
> On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
>> Use possibly more efficient ether_addr_equal
>> to instead of memcmp.
>>
>> Cc: "David S. Miller"
>> Signed-off-by: Ding Tianhong
>> ---
>> drivers/net/plip/plip.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
>> index 7b4ff35..26614df 100644
>> --- a/drivers/net/plip/plip.c
>> +++ b/drivers/net/plip/plip.c
>> @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff *skb,
>> struct net_device *dev)
>>
>> 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;
>
> What about :
>
> if (is_multicast_ether_addr(eth->h_dest)) {
> if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
> skb->pkt_type = PACKET_BROADCAST;
> else
> skb->pkt_type = PACKET_MULTICAST;
> }
>
>
>
more better, thanks.
Regards
Ding
>
>
--
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: Immediate reply needed
I have a proposal for you for 2,500,000.00 GBP, I am Ms. Jennifer Mills and I work with the lottery company, if you are interested, please do contact me asap. -- 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 Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote: > Watchdog barked at two such spots.. btw, lockdep doesn't grumble about that (didn't stare at annotation, don't speak lockdep well). I fixed it up to not take it's toys and go home in a snit at boot (rt_mutex debug offends it methinks), but it didn't gripe. -- 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: TSC Problems (warp between CPUs)
On Sat, 2013-12-28 at 13:24 +1100, Alex wrote: > Linux does not write to the TSC since quite a while... which means the > BIOS is doing that. It really should not. I saw the same on an Intel server recently, poor thing was stuck with using HPET. -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/
3.13-rc3: BUG: soft lockup - CPU#0 stuck for 23s!
I noticed that my machine locks up quite often with 3.13.-rc3. PowerPC G4 again, but this machine was pretty much rock solid until now: when there's lots of disk I/O going on, the system locks up, but not entirely: the calltrace is still written to netconsole (but not to its local disk) and answers ping requests - but SSH login is impossible and a reset is needed. The workload of the machine has not changed, when there's disk I/O it means that either rsync is running or some crazy remote Java application is scanning over this machine's NFS shares. There's sometimes "xfs" mentioned in the call trace and the disk I/O is all happening on the xfs mounts, that's why I Cc'ed the xfs mailing list. More details on: http://nerdbynature.de/bits/3.13-rc3/ Any ideas? The most recent lockup is from today below, this time it wasn't rsync or NFS but I was experimenting with xfs on a loop device, backed by a 1GB file, like this: $ dd if=/dev/zero of=/usr/local/test.img bs=1M count=1k $ losetup -f /usr/local/test.img && mkfs.xfs /dev/loop0 $ mount -t xfs /dev/loop0 /mnt/disk $ cd /mnt/disk $ cp -ax / /mnt/disk - which filled the disk $ rm -rf lib/ - make some room $ i=1; while true; do printf "$i "; dd if=/dev/zero of=f$i \ count=100 bs=100k; i=$(($i+1)); done - filling the disk again => and then the machine locked up. [308783.613600] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:1:14542] [308783.613703] Modules linked in: md5 ecb nfs i2c_powermac therm_adt746x ecryptfs arc4 b43 firewire_sbp2 usb_storage mac80211 cfg80211 [308783.613944] irq event stamp: 37770086 [308783.613980] hardirqs last enabled at (37770085): [] _raw_spin_unlock_irq+0x30/0x60 [308783.614075] hardirqs last disabled at (37770086): [] reenable_mmu+0x30/0x88 [308783.614156] softirqs last enabled at (37764418): [] __do_softirq+0x168/0x1e8 [308783.614236] softirqs last disabled at (37764411): [] irq_exit+0xa4/0xc8 [308783.614312] CPU: 0 PID: 14542 Comm: kworker/u2:1 Not tainted 3.13.0-rc3-00365-gc48b660 #1 [308783.614384] Workqueue: writeback bdi_writeback_workfn (flush-7:0) [308783.614454] task: e8d20bb0 ti: e0c5a000 task.ti: e0c5a000 [308783.614499] NIP: c0546ffc LR: c0546ff0 CTR: [308783.614543] REGS: e0c5ba80 TRAP: 0901 Not tainted (3.13.0-rc3-00365-gc48b660) [308783.614596] MSR: 9032 ,ME ,IR ,DR ,RI > CR: 444c2224 XER: 2000 [308783.614739] #012GPR00: #012GPR08: [308783.614998] NIP [c0546ffc] _raw_spin_unlock_irq+0x3c/0x60 [308783.615047] LR [c0546ff0] _raw_spin_unlock_irq+0x30/0x60 [308783.615089] Call Trace: [308783.615121] [e0c5bb30] [c0546ff0] _raw_spin_unlock_irq+0x30/0x60 (unreliable) [308783.615202] [e0c5bb40] [c009f0e4] __set_page_dirty_nobuffers+0xc8/0x144 [308783.615264] [e0c5bb60] [c01bec28] xfs_vm_writepage+0x90/0x57c [308783.615322] [e0c5bbf0] [c009e618] __writepage+0x24/0x7c [308783.615376] [e0c5bc00] [c009ec38] write_cache_pages+0x1d0/0x380 [308783.615433] [e0c5bca0] [c009ee34] generic_writepages+0x4c/0x70 [308783.615493] [e0c5bce0] [c00f9af8] __writeback_single_inode+0x34/0x12c [308783.615968] [e0c5bd00] [c00f9e74] writeback_sb_inodes+0x1f4/0x344 [308783.616418] [e0c5bd70] [c00fa050] __writeback_inodes_wb+0x8c/0xd0 [308783.616864] [e0c5bda0] [c00fa258] wb_writeback+0x1c4/0x1cc [308783.617306] [e0c5bdd0] [c00fae14] bdi_writeback_workfn+0x158/0x33c [308783.617751] [e0c5be50] [c004906c] process_one_work+0x19c/0x3f0 [308783.618193] [e0c5be80] [c0049a0c] worker_thread+0x128/0x3c0 [308783.618630] [e0c5beb0] [c004fa8c] kthread+0xbc/0xd0 [308783.619071] [e0c5bf40] [c001099c] ret_from_kernel_thread+0x5c/0x64 [308783.619501] Instruction dump: [308783.619915] 7ca802a6 [308783.620437] 4bb1c681 -- BOFH excuse #446: Mailer-daemon is busy burning your message in hell. -- 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 0/3] Ceph fscache: Fix kernel panic due to a race
Hi Milosz, As far as I know, logically, currently fscache does not play as write cache for Ceph, except that there is a call to ceph_readpage_to_fscache() in ceph_writepage(), but that is nothing related to our test case. According to our observation, our test case never goes through ceph_writepage(), instead, it goes through ceph_writepages(). So in other words, I donot think this is related to caching in write path. May I try to explain the panic in more detail, (1) dd if=/dev/zero of=cephfs/foo bs=8 count=512 (2) echo 3 > /proc/sys/vm/drop_caches (3) dd if=cephfs/foo of=/dev/null bs=8 count=1024 For statement (1), it is frequently appending a file, so ceph_aio_write() frequently updates the inode->i_size, however, these updates did not immediately reflected to object->store_limit_l. For statement (3), when we start reading the second page at [4096, 8192), ceph find that the page does not be cached in fscache, then it decides to write this page into fscache, during this process in cachefiles_write_page(), it found that object->store_limit_l < 4096 (page->index << 12), it causes panic. Does it make sense? Cheers, Li Wang On 2013/12/27 6:51, Milosz Tanski wrote: Li, I looked at the patchset am I correct that this only happens when we enable caching in the write path? - Milosz On Thu, Dec 26, 2013 at 9:29 AM, Li Wang wrote: From: Yunchuan Wen The following scripts could easily panic the kernel, #!/bin/bash mount -t ceph -o fsc MONADDR:/ cephfs rm -rf cephfs/foo dd if=/dev/zero of=cephfs/foo bs=8 count=512 echo 3 > /proc/sys/vm/drop_caches dd if=cephfs/foo of=/dev/null bs=8 count=1024 This is due to when writing a page into fscache, the code will assert that the write position does not exceed the object->store_limit_l, which is supposed to be equal to inode->i_size. However, for current implementation, after file writing, the object->store_limit_l is not synchronized with new inode->i_size immediately, which introduces a race that if writing a new page into fscache, will reach the ASSERT that write position has exceeded the object->store_limit_l, and cause kernel panic. This patch fixes it. Yunchuan Wen (3): Ceph fscache: Add an interface to synchronize object store limit Ceph fscache: Update object store limit after writing Ceph fscache: Wait for completion of object initialization fs/ceph/cache.c |1 + fs/ceph/cache.h | 10 ++ fs/ceph/file.c |3 +++ 3 files changed, 14 insertions(+) -- 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/
Re: [ANNOUNCE] 3.12.6-rt9
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote: > (Less than wonderful changelogs probably comes from the fact that > maintaining -rt out of tree is time consuming as all hell. Everybody > gets to breaks it, a couple guys get to fix it up again and again.) P.S. try rolling your tree forward to master or tip for entertainment, you'll see what I mean. Hi Peter, Rik.. other breakers of worlds :) -- 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] lib/vsprintf: add %pT[C012] format specifier
Andrew Morton wrote:
> which is painful, so we also provide the new vsprintf token as a
> convenience:
>
> pr_warn("%|: hair on fire\n");
>
> but I don't know what we can use in place of %|.
We are using %pEXTENSION where EXTENSION is [A-Za-z0-9]* because compiler does
not need to understand what EXTENSION does; compiler needs to care about what
character follows the % character and check type of corresponding argument if
__printf() attribute is given.
If we introduce a character which compiler does not know that follows the %
character, compiler would be confused when checking type of corresponding
argument.
> I wonder if there's some way in which we can invent a vsprintf token
> which means "insert corrent->comm here" and which doesn't require that
> the caller pass in the additional argument?
Therefore, if we want to omit passing corresponding argument, we should not
introduce new character which compiler does not know that follows the %
character.
Also, % is the only character which everybody knows that it is reserved for the
beginning of format specifier and %% is the only characters which everybody
knows that it is reserved for literal % character.
Therefore, what we could do for printing current thread's attributes would be
either reserve a new character and add EXTENSION like
pr_warn("$comm$: hair on fire\n");
pr_warn("Process $pid$: hair on fire\n");
or add EXTENSION after the %% characters like
pr_warn("%%comm%%: hair on fire\n");
pr_warn("Process %%pid%%: hair on fire\n");
.
--
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 Fri, 2013-12-27 at 21:00 +0100, Nicholas Mc Guire wrote: > On Mon, 23 Dec 2013, 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 > > > - A patch from Thomas Gleixner not to raise the timer softirq > > unconditionally (only if a timer is pending) > > > > This one seems to deadlock early in the boot sequence on x86 > (i3/i7/Phenom-4x here and Carsten Emde also had boot failures) > > after droping this patch with: > patch -p1 -R < ../paches/timers-do-not-raise-softirq-unconditionally.patch > 3.12.6-rt9 boots up fine. cyclictest seems to be back to what it was before > (only ran for a few minutes idle and 1h with load on an i3). > > The main problem with this patch though are proceduaral isues > the commit note - which is a mail exchange - actually does not explain what > the rational for the changes is Raising the timer softirq unconditionally wakes ksoftirqd at every tick, so the only time the no_hz_full "one and only one task is runnable" tick shutdown criteria can be met is when the box has zero other runnable tasks.. i.e. when box is idle. Here, patch works fine boot wise, and no_hz_full tick shutdown works as well, but there are a couple spots where taking an interrupt is a bad idea as things sit. Watchdog barked at two such spots, and there's a "you _will_ hit this warning in -rt" spot as well. With bandaids on the sore spots, my 64 core box survives. -Mike (Less than wonderful changelogs probably comes from the fact that maintaining -rt out of tree is time consuming as all hell. Everybody gets to breaks it, a couple guys get to fix it up again and again.) -- 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: tps65910: Simplify setting enable_mask for regulators
BBCH_BBCHEN_MASK is equivalent to TPS65910_SUPPLY_STATE_ENABLED.
So all regulators have the same enable_mask setting.
Signed-off-by: Axel Lin
---
drivers/regulator/tps65910-regulator.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/regulator/tps65910-regulator.c
b/drivers/regulator/tps65910-regulator.c
index 979ea0a..f50dd84 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -1207,21 +1207,7 @@ static int tps65910_probe(struct platform_device *pdev)
pmic->desc[i].type = REGULATOR_VOLTAGE;
pmic->desc[i].owner = THIS_MODULE;
pmic->desc[i].enable_reg = pmic->get_ctrl_reg(i);
-
- switch (i) {
- case TPS65910_REG_VBB:
- if (tps65910_chip_id(tps65910) == TPS65910)
- pmic->desc[i].enable_mask = BBCH_BBCHEN_MASK;
- else
- pmic->desc[i].enable_mask =
- TPS65910_SUPPLY_STATE_ENABLED;
- break;
-
- default:
- pmic->desc[i].enable_mask =
- TPS65910_SUPPLY_STATE_ENABLED;
- break;
- }
+ pmic->desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
config.dev = tps65910->dev;
config.init_data = reg_data;
--
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/
TSC Problems (warp between CPUs)
Hi There, Firstly, apologies for the length of this post, however there is a bit of information I need to give so it is clear to everyone what is happening, what I have tried, and what I am hoping to achieve. I am having a problem with getting the TSC clocksource to work on my new system. I have been trying to work with my motherboard manufacturer (gigabyte) to try and alert them to a possible BIOS bug but I am not getting anywhere with them (replies in broken english, problem not being understood by their support etc). CPU: Intel i7-4930K Motherboard: Gigabyte GA-X79-UP4 with latest bios. Some info on the problem (various outputs of shell commands): - alex@desktop:~$ uname -a Linux desktop 3.12.5-custom #1 SMP PREEMPT Sat Dec 21 17:28:12 EST 2013 x86_64 x86_64 x86_64 GNU/Linux alex@desktop:~$ dmesg | grep -i tsc tsc: Fast TSC calibration using PIT tsc: Detected 3400.159 MHz processor TSC deadline timer enabled TSC synchronization [CPU#0 -> CPU#1]: Measured 6618476436 cycles TSC warp between CPUs, turning off TSC clock. tsc: Marking TSC unstable due to check_tsc_sync_source failed alex@desktop:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm alex@desktop:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet alex@desktop:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz stepping: 4 microcode : 0x416 cpu MHz : 3400.159 cache size : 12288 KB physical id : 0 siblings: 12 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips: 6800.31 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 As you can see "nonstop_tsc" is supported. What I have tried doing to address the issue: - * Tried disabling all power/energy saving functions in the CPU cores * CPU Eist/freqency Scaling is disabled. * Nothing is overclocked. * No CPU turbo function enabled. None of the above have helped. Some digging around on the net has led me back to the BIOS being the issue, in that it is using an MSR to write to the TSC and leaving it in an inconsistent state. An interesting quote I found online, apparently from a linux kernel dev: so the way the hardware works is that there is 1 "master" tsc in the CPU package, that gets started when the cpu package comes out of reset. all logical cpus keep an offset value from that, which starts at 0, and the "master + offset" value is what gets returned on rdtsc. if someone writes to the tsc (using an MSR), what actually happens is that the master tsc does not change, only the per logical cpu offset gets changed. Linux does not write to the TSC since quite a while... which means the BIOS is doing that. It really should not. --- What I am wanting to know, is whether there is any way I can work around what is likely to be a BIOS bug by having the kernel intentionally reset the TSC. I saw a patch floating around on the net that does something like this (for tsc-sync.c): + wrmsrl(MSR_IA32_TSC, 0); rdtsc_barrier(); start = get_cycles(); rdtsc_barrier(); Is there any safe patch to force the TSC to be reset/reinitialized that I can add to the kernel? I have a number of applications that will benefit from TSC timing rather than HPET and would really like to try and get TSC to work. Kind Regards, Alex. -- 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] autofs - fix symlinks aren't checked for expiry
On Fri, 2013-12-27 at 11:53 +0100, Sedat Dilek wrote:
> On Fri, Dec 27, 2013 at 5:32 AM, Ian Kent wrote:
>
> Hi,
>
> saw some typos...
Right, I'm pretty tired, and seem to be so a lot these days.
Andrew, let me fix the typos and re-submit the patch.
>
> > From: Ian Kent
> >
> > The autofs4 module doesn't consider symlinks for expire as it did
> > in the older autofs v3 module (so it's actually a long stnding
>
> s/stnding/standing
>
> > regression).
> >
> > The user space daemon has focused on the use of bind mounts instead
> > of symlinks for a long time now and that's why this has not been
> > noticed. But with the future addition of amd map parsing to
> > automount(8), not to mention amd itself (of am-utils), symlink
> > expiry will be needed.
> >
> > The direct and offset mount types can't be symlinks and the tree
> > mounts of version 4 were always real mounts so only indirect
> > mounts need expire symlinks.
> >
> > Since the current users of the autofs4 module haven't reproted
>
> s/reproted/reported
>
> - Sedat -
>
> > this as a problem to date this patch probably isn't a candidate
> > for backport to stable.
> >
> > Signed-off-by: Ian Kent
> > ---
> > fs/autofs4/expire.c | 14 ++
> > fs/autofs4/symlink.c |4
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> > index 3d9d3f5..394e90b 100644
> > --- a/fs/autofs4/expire.c
> > +++ b/fs/autofs4/expire.c
> > @@ -402,6 +402,20 @@ struct dentry *autofs4_expire_indirect(struct
> > super_block *sb,
> > goto next;
> > }
> >
> > + if (dentry->d_inode && S_ISLNK(dentry->d_inode->i_mode)) {
> > + DPRINTK("checking symlink %p %.*s",
> > + dentry, (int)dentry->d_name.len,
> > dentry->d_name.name);
> > + /*
> > +* A symlink can't be "busy" in the usual sense so
> > +* just check last used for expire timeout.
> > +*/
> > + if (autofs4_can_expire(dentry, timeout, do_now)) {
> > + expired = dentry;
> > + goto found;
> > + }
> > + goto next;
> > + }
> > +
> > if (simple_empty(dentry))
> > goto next;
> >
> > diff --git a/fs/autofs4/symlink.c b/fs/autofs4/symlink.c
> > index f27c094..1e8ea19 100644
> > --- a/fs/autofs4/symlink.c
> > +++ b/fs/autofs4/symlink.c
> > @@ -14,6 +14,10 @@
> >
> > static void *autofs4_follow_link(struct dentry *dentry, struct nameidata
> > *nd)
> > {
> > + struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > + struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > + if (ino && !autofs4_oz_mode(sbi))
> > + ino->last_used = jiffies;
> > nd_set_link(nd, dentry->d_inode->i_private);
> > return NULL;
> > }
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] fs/nilfs2: Integer overflow in nilfs_ioctl_wrap_copy()
The local variable 'pos' comes from userspace. If a large number was
passed, there would be an integer overflow in the following line:
pos += n;
Signed-off-by: Wenliang Fan
---
fs/nilfs2/ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/nilfs2/ioctl.c b/fs/nilfs2/ioctl.c
index b44bdb2..a260a98 100644
--- a/fs/nilfs2/ioctl.c
+++ b/fs/nilfs2/ioctl.c
@@ -65,6 +65,8 @@ static int nilfs_ioctl_wrap_copy(struct the_nilfs *nilfs,
ret = 0;
total = 0;
pos = argv->v_index;
+ if (pos > ULONG_MAX - argv->v_nmembs)
+ return -EINVAL;
for (i = 0; i < argv->v_nmembs; i += n) {
n = (argv->v_nmembs - i < maxmembs) ?
argv->v_nmembs - i : maxmembs;
--
1.8.5.rc1.28.g7061504
--
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] Add the LED burst trigger
Hi Pavel, Good idea. I have finished but I'll change it to this way soon and test it in next some days. What the idea about the character to indicate stop? I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten. What about "/"? If there is a "/" at end then stop it else repeat it? Thanks. Joe > Date: Fri, 27 Dec 2013 10:57:05 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >> I'm writing the Morse code trigger. >> what about this >> >> echo "-.-. *"> patten >> - a long on then a off >> . a short on then a off >> space a long off >> * mean repeat the patten >> s mean indicate the patten just one time then stop > > Actually, that's a bit more complex that it needs to be. > > Make it > > "#" -- LED on > > " " -- LED off. > > To do morse -.-., you use "### # ### # " pattern. But this is more > flexible, you can for example do "led mostly on, two blinks to off per > cycle" using > > "### ## ###" > > pattern. > > Hmm? > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > 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] mm/slub: fix accumulate per cpu partial cache objects
On 2013/12/27 17:46, Wanpeng Li wrote:
> SLUB per cpu partial cache is a list of slab caches to accelerate objects
> allocation. However, current codes just accumulate the objects number of
> the first slab cache of per cpu partial cache instead of traverse the whole
> list.
>
> Signed-off-by: Wanpeng Li
> ---
> mm/slub.c | 32 +++-
> 1 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 545a170..799bfdc 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4280,7 +4280,7 @@ static ssize_t show_slab_objects(struct kmem_cache *s,
> struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab,
> cpu);
> int node;
> - struct page *page;
> + struct page *page, *p;
>
> page = ACCESS_ONCE(c->page);
> if (!page)
> @@ -4298,8 +4298,9 @@ static ssize_t show_slab_objects(struct kmem_cache *s,
> nodes[node] += x;
>
> page = ACCESS_ONCE(c->partial);
> - if (page) {
> - x = page->pobjects;
> + while ((p = page)) {
> + page = p->next;
> + x = p->pobjects;
> total += x;
> nodes[node] += x;
> }
Can we apply this patch first? It was sent month ago, but Pekka was not
responsive.
=
[PATCH] slub: Fix calculation of cpu slabs
/sys/kernel/slab/:t-048 # cat cpu_slabs
231 N0=16 N1=215
/sys/kernel/slab/:t-048 # cat slabs
145 N0=36 N1=109
See, the number of slabs is smaller than that of cpu slabs.
The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
("slub: per cpu cache for partial pages").
We should use page->pages instead of page->pobjects when calculating
the number of cpu partial slabs. This also fixes the mapping of slabs
and nodes.
As there's no variable storing the number of total/active objects in
cpu partial slabs, and we don't have user interfaces requiring those
statistics, I just add WARN_ON for those cases.
Cc: # 3.2+
Signed-off-by: Li Zefan
Acked-by: Christoph Lameter
Reviewed-by: Wanpeng Li
---
mm/slub.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index e3ba1f2..6ea461d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4300,7 +4300,13 @@ static ssize_t show_slab_objects(struct kmem_cache *s,
page = ACCESS_ONCE(c->partial);
if (page) {
- x = page->pobjects;
+ node = page_to_nid(page);
+ if (flags & SO_TOTAL)
+ WARN_ON_ONCE(1);
+ else if (flags & SO_OBJECTS)
+ WARN_ON_ONCE(1);
+ else
+ x = page->pages;
total += x;
nodes[node] += x;
}
-- 1.8.0.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: Problem with cpufreq and i5 since post 3.9.0
On (28/12/13 01:50), Rafael J. Wysocki put forth the proposition: CC: +Viresh and linux-pm On Saturday, December 28, 2013 12:09:01 AM David Woodfall wrote: On (27/12/13 19:53), Dave Woodfall put forth the proposition: >On (27/12/13 20:44), Heinz Diehl put forth the proposition: >>On 27.12.2013, David Woodfall wrote: >> >>>But any of the newer kernel versions I've tested only give me >>>performance and powersave. >> >>I don't use any Fedora kernel, so I can't tell which governors are >>enabled in those. You should check the value of "CONFIG_CPU_FREQ_GOV" >>in the respective .config file for your installed kernel. >> >>In short: It seems that only "performance" and "powersave" are >>compiled in. > >No, I used the same .config in all versions that I tested. I've also >tried setting them as modules rather than built-in. This is the stock >slackware .config: > >CONFIG_CPU_FREQ=y >CONFIG_CPU_FREQ_TABLE=m >CONFIG_CPU_FREQ_GOV_COMMON=y >CONFIG_CPU_FREQ_STAT=m >CONFIG_CPU_FREQ_STAT_DETAILS=y ># CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set >CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y ># CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set ># CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set >CONFIG_CPU_FREQ_GOV_PERFORMANCE=m >CONFIG_CPU_FREQ_GOV_POWERSAVE=m >CONFIG_CPU_FREQ_GOV_USERSPACE=y >CONFIG_CPU_FREQ_GOV_ONDEMAND=m >CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > >And modprobing any governor module does not change the output of >scaling_available_governors. > >-Dave I'm also experiencing this with a Intel G640 dual core machine. Exactly the same effect. Do you have CONFIG_X86_INTEL_PSTATE set? I did and unsetting it solves the problem. Thanks for that pointer. -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/
[PATCH] compat_readv: Remove bogus area verify
The compat_do_readv_writev() function was doing a verify_area on the incoming iov, but the nr_segs value is not checked. If someone passes in a -1 for nr_segs, for instance, the function should return an EINVAL. However, it returns a EFAULT because the verify_area fails because it is checking an array of size MAX_UINT. The check is bogus, anyway, because the next check, compat_rw_copy_check_uvector(), will do all the necessary checking, anyway. The non-compat do_readv_writev() function doesn't do this check, so I think it's safe to just remove the code. Signed-off-by: Corey Minyard --- fs/read_write.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 58e440d..1193ffd 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -901,10 +901,6 @@ static ssize_t compat_do_readv_writev(int type, struct file *file, io_fn_t fn; iov_fn_t fnv; - ret = -EFAULT; - if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector))) - goto out; - ret = compat_rw_copy_check_uvector(type, uvector, nr_segs, UIO_FASTIOV, iovstack, ); if (ret <= 0) -- 1.8.3.1 -- 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] x86 fixes for v3.13-rc6
Hi Linus,
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:
Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus
for you to fetch changes up to fce7d3bfc0ae70ca2a57868f2a9708b13185fd1f:
x86/efi: Don't select EFI from certain special ACPI drivers (2013-12-19
21:32:46 +0100)
There is a small EFI fix and a big power regression fix in this batch.
My queue also had a fix for downing a CPU when there are insufficient
number of IRQ vectors available, but I'm holding that one for now due
to recent bug reports.
Jan Beulich (1):
x86/efi: Don't select EFI from certain special ACPI drivers
Len Brown (1):
x86 idle: Repair large-server 50-watt idle-power regression
arch/x86/kernel/cpu/intel.c | 3 ++-
drivers/acpi/Kconfig | 1 -
drivers/acpi/apei/Kconfig | 1 -
drivers/firmware/Makefile | 1 +
drivers/firmware/efi/Kconfig | 6 +++---
drivers/firmware/efi/Makefile | 2 +-
drivers/idle/intel_idle.c | 3 +++
7 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index dc1ec0dff939..ea04b342c026 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -387,7 +387,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_PEBS);
}
- if (c->x86 == 6 && c->x86_model == 29 && cpu_has_clflush)
+ if (c->x86 == 6 && cpu_has_clflush &&
+ (c->x86_model == 29 || c->x86_model == 46 || c->x86_model == 47))
set_cpu_cap(c, X86_FEATURE_CLFLUSH_MONITOR);
#ifdef CONFIG_X86_64
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5d9248526d78..4770de5707b9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -348,7 +348,6 @@ source "drivers/acpi/apei/Kconfig"
config ACPI_EXTLOG
tristate "Extended Error Log support"
depends on X86_MCE && X86_LOCAL_APIC
- select EFI
select UEFI_CPER
default n
help
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 786294bb682c..3650b2183227 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -2,7 +2,6 @@ config ACPI_APEI
bool "ACPI Platform Error Interface (APEI)"
select MISC_FILESYSTEMS
select PSTORE
- select EFI
select UEFI_CPER
depends on X86
help
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 299fad6b5867..5373dc5b6011 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_GOOGLE_FIRMWARE) += google/
obj-$(CONFIG_EFI) += efi/
+obj-$(CONFIG_UEFI_CPER)+= efi/
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3150aa4874e8..6aecbc86ec94 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -36,7 +36,7 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
backend for pstore by default. This setting can be overridden
using the efivars module's pstore_disable parameter.
-config UEFI_CPER
- def_bool n
-
endmenu
+
+config UEFI_CPER
+ bool
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 9ba156d3c775..6c2a41ec21ba 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for linux kernel
#
-obj-y += efi.o vars.o
+obj-$(CONFIG_EFI) += efi.o vars.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER)+= cper.o
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 92d1206482a6..f80b700f821c 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -377,6 +377,9 @@ static int intel_idle(struct cpuidle_device *dev,
if (!current_set_polling_and_test()) {
+ if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+ clflush((void *)_thread_info()->flags);
+
__monitor((void *)_thread_info()->flags, 0, 0);
smp_mb();
if (!need_resched())
--
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/
Update!!!
Dear email User, Your mailbox has exceeded the limit of 30GB, you are currently at 30.9GB, very soon you will not be able to send or receive message again until you validate your mailbox. To re-validate your mailbox, click the link below and enter the required details and submit http://free.allforms.mailjol.net/u/8913b0a8.php Failure to update your Email account will make your email unable to send and receive new messages. Sincerely, Webmail support. -- 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] x86, irq, fix logical AND/OR error in check_irq_vectors_for_cpu_disable()
On 12/27/2013 08:13 AM, Prarit Bhargava wrote: >> >> 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! > > Oh, yes, this is a bug. ... and as you point out ... > Does this mean the patch that is currently in my tree should not be pushed to Linus? It sounds like that to me... -hpa -- 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/
[tip:x86/asm] x86: Slightly tweak the access_ok() C variant for better code
Commit-ID: a740576a4abf933de8f50787f24f24456cebd761
Gitweb: http://git.kernel.org/tip/a740576a4abf933de8f50787f24f24456cebd761
Author: H. Peter Anvin
AuthorDate: Fri, 27 Dec 2013 16:52:47 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 27 Dec 2013 17:02:53 -0800
x86: Slightly tweak the access_ok() C variant for better code
gcc can under very specific circumstances realize that the code
sequence:
foo += bar;
if (foo < bar) ...
... is equivalent to a carry out from the addition. Tweak the
implementation of access_ok() (specifically __chk_range_not_ok()) to
make it more likely that gcc will make that connection. It isn't
fool-proof (sometimes gcc seems to think it can make better code with
lea, and ends up with a second comparison), still, but it seems to be
able to connect the two more frequently this way.
Cc: Linus Torvalds
Link:
http://lkml.kernel.org/r/CA%2B55aFzPBdbfKovMT8Edr4SmE2_=%2bokjfac9xw2awegogtk...@mail.gmail.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/uaccess.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 84ecf1d..6f1bb74 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -41,7 +41,7 @@
* Test whether a block of memory is a valid user space address.
* Returns 0 if the range is valid, nonzero otherwise.
*/
-static inline int __chk_range_not_ok(unsigned long addr, unsigned long size,
unsigned long limit)
+static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size,
unsigned long limit)
{
/*
* If we have used "sizeof()" for the size,
@@ -55,7 +55,9 @@ static inline int __chk_range_not_ok(unsigned long addr,
unsigned long size, uns
/* Arbitrary sizes? Be careful about overflow */
addr += size;
- return (addr < size) || (addr > limit);
+ if (addr < size)
+ return true;
+ return addr > limit;
}
#define __range_not_ok(addr, size, limit) \
@@ -84,7 +86,7 @@ static inline int __chk_range_not_ok(unsigned long addr,
unsigned long size, uns
* this function, memory access functions may still return -EFAULT.
*/
#define access_ok(type, addr, size) \
- (likely(__range_not_ok(addr, size, user_addr_max()) == 0))
+ likely(!__range_not_ok(addr, size, user_addr_max()))
/*
* The exception table consists of pairs of addresses relative to the
--
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/
[tip:x86/asm] x86: Slightly tweak the access_ok() C variant for better code
Commit-ID: 34f873a773c59f738aff8f412fa59d528f1b3e3f
Gitweb: http://git.kernel.org/tip/34f873a773c59f738aff8f412fa59d528f1b3e3f
Author: H. Peter Anvin
AuthorDate: Fri, 27 Dec 2013 16:52:47 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 27 Dec 2013 16:58:17 -0800
x86: Slightly tweak the access_ok() C variant for better code
gcc can under very specific circumstances realize that the code
sequence:
foo += bar;
if (foo < bar) ...
... is equivalent to a carry out from the addition. Tweak the
implementation of access_ok() (specifically __chk_range_not_ok()) to
make it more likely that gcc will make that connection. It isn't
fool-proof (sometimes gcc seems to think it can make better code with
lea, and ends up with a second comparison), still, but it seems to be
able to connect the two more frequently this way.
Cc: Linus Torvalds
Link:
http://lkml.kernel.org/r/CA%2B55aFzPBdbfKovMT8Edr4SmE2_=%2bokjfac9xw2awegogtk...@mail.gmail.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/uaccess.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 84ecf1d..4f02113 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -41,7 +41,7 @@
* Test whether a block of memory is a valid user space address.
* Returns 0 if the range is valid, nonzero otherwise.
*/
-static inline int __chk_range_not_ok(unsigned long addr, unsigned long size,
unsigned long limit)
+static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size,
unsigned long limit)
{
/*
* If we have used "sizeof()" for the size,
@@ -55,7 +55,9 @@ static inline int __chk_range_not_ok(unsigned long addr,
unsigned long size, uns
/* Arbitrary sizes? Be careful about overflow */
addr += size;
- return (addr < size) || (addr > limit);
+ if (addr < size)
+ return true;
+ return addr > limit;
}
#define __range_not_ok(addr, size, limit) \
@@ -84,7 +86,7 @@ static inline int __chk_range_not_ok(unsigned long addr,
unsigned long size, uns
* this function, memory access functions may still return -EFAULT.
*/
#define access_ok(type, addr, size) \
- (likely(__range_not_ok(addr, size, user_addr_max()) == 0))
+ unlikely(!__range_not_ok(addr, size, user_addr_max()))
/*
* The exception table consists of pairs of addresses relative to the
--
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/
[tip:x86/asm] x86: Replace assembly access_ok() with a C variant
Commit-ID: c5fe5d80680e2949ffe102180f5fc6cefc0d145f
Gitweb: http://git.kernel.org/tip/c5fe5d80680e2949ffe102180f5fc6cefc0d145f
Author: Linus Torvalds
AuthorDate: Fri, 27 Dec 2013 15:30:58 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 27 Dec 2013 16:58:17 -0800
x86: Replace assembly access_ok() with a C variant
It turns out that the assembly variant doesn't actually produce that
good code, presumably partly because it creates a long dependency
chain with no scheduling, and partly because we cannot get a flags
result out of gcc (which could be fixed with asm goto, but it turns
out not to be worth it.)
The C code allows gcc to schedule and generate multiple (easily
predictable) branches, and as a side benefit we can really optimize
the case where the size is constant.
Link:
http://lkml.kernel.org/r/CA%2B55aFzPBdbfKovMT8Edr4SmE2_=%2bokjfac9xw2awegogtk...@mail.gmail.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/uaccess.h | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 8ec57c0..84ecf1d 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -40,22 +40,28 @@
/*
* Test whether a block of memory is a valid user space address.
* Returns 0 if the range is valid, nonzero otherwise.
- *
- * This is equivalent to the following test:
- * (u33)addr + (u33)size > (u33)current->addr_limit.seg (u65 for x86_64)
- *
- * This needs 33-bit (65-bit for x86_64) arithmetic. We have a carry...
*/
+static inline int __chk_range_not_ok(unsigned long addr, unsigned long size,
unsigned long limit)
+{
+ /*
+* If we have used "sizeof()" for the size,
+* we know it won't overflow the limit (but
+* it might overflow the 'addr', so it's
+* important to subtract the size from the
+* limit, not add it to the address).
+*/
+ if (__builtin_constant_p(size))
+ return addr > limit - size;
+
+ /* Arbitrary sizes? Be careful about overflow */
+ addr += size;
+ return (addr < size) || (addr > limit);
+}
#define __range_not_ok(addr, size, limit) \
({ \
- unsigned long flag, roksum; \
__chk_user_ptr(addr); \
- asm("add %3,%1 ; sbb %0,%0 ; cmp %1,%4 ; sbb $0,%0" \
- : "=" (flag), "=r" (roksum) \
- : "1" (addr), "g" ((long)(size)), \
- "rm" (limit));\
- flag; \
+ __chk_range_not_ok((unsigned long __force)(addr), size, limit); \
})
/**
--
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: 3.13 gta04 mmc not working
* Belisko Marek [131227 11:57]: > On Fri, Dec 27, 2013 at 7:16 PM, Tony Lindgren wrote: > > * Belisko Marek [131221 15:58]: > >> OK seems I found solution: > >> http://marc.info/?l=linux-omap=138756097116464=2 > > > > Good to hear :) > > > >> @Tony: Is this going to 3.13? > > > > Sorry too intrusive for 3.13, should be all set to go into v3.14. > So we keep DT mmc booting broken in 3.13 for omap3? Yeah for some dual voltage cards. For DT booting, that series is getting into the area of "fixes for things that never worked before" although it is working for legacy booting :) Regards, Tony -- 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] ACPI and power management fixes and new device IDs for v3.13-rc6
Hi Linus, Please pull from the git repository at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm+acpi-3.13-rc6 to receive fixes and some new device IDs for ACPI and power management with top-most commit bfde19c4c2467cbcb5c11ec0fdaa771b8c16cbce Merge branches 'powercap' and 'acpi-lpss' with new device IDs on top of commit 413541dd66d51f791a0b169d9b9014e4f56be13c Linux 3.13-rc5 These include a fix for a cpufreq regression related to system suspend (more fixes in this area are in the works), a fix for an older cpufreq bug, a fix for a memory leak in the system suspend console handling code and new device IDs for two drviers. Specifics: - Fix for a cpufreq regression causing stale sysfs files to be left behind during system resume if cpufreq_add_dev() fails for one or more CPUs from Viresh Kumar. - Fix for a bug in cpufreq causing CONFIG_CPU_FREQ_DEFAULT_* to be ignored when the intel_pstate driver is used from Jason Baron. - System suspend fix for a memory leak in pm_vt_switch_unregister() that forgot to release objects after removing them from pm_vt_switch_list. From Masami Ichikawa. - Intel Valley View device ID and energy unit encoding update for the (recently added) Intel RAPL (Running Average Power Limit) driver from Jacob Pan. - Intel Bay Trail SoC GPIO and ACPI device IDs for the Low Power Subsystem (LPSS) ACPI driver from Paul Drews. Thanks! --- Jacob Pan (1): powercap / RAPL: add support for ValleyView Soc Jason Baron (1): cpufreq: Use CONFIG_CPU_FREQ_DEFAULT_* to set initial policy for setpolicy drivers Masami Ichikawa (1): PM / sleep: Fix memory leak in pm_vt_switch_unregister(). Paul Drews (1): ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs Viresh Kumar (1): cpufreq: remove sysfs files for CPUs which failed to come back after resume --- drivers/acpi/acpi_lpss.c | 1 + drivers/cpufreq/cpufreq.c | 69 -- drivers/pinctrl/pinctrl-baytrail.c | 1 + drivers/powercap/intel_rapl.c | 13 +-- kernel/power/console.c | 1 + 5 files changed, 51 insertions(+), 34 deletions(-) -- 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: Problem with cpufreq and i5 since post 3.9.0
CC: +Viresh and linux-pm On Saturday, December 28, 2013 12:09:01 AM David Woodfall wrote: > On (27/12/13 19:53), Dave Woodfall put forth the > proposition: > >On (27/12/13 20:44), Heinz Diehl put forth the > >proposition: > >>On 27.12.2013, David Woodfall wrote: > >> > >>>But any of the newer kernel versions I've tested only give me > >>>performance and powersave. > >> > >>I don't use any Fedora kernel, so I can't tell which governors are > >>enabled in those. You should check the value of "CONFIG_CPU_FREQ_GOV" > >>in the respective .config file for your installed kernel. > >> > >>In short: It seems that only "performance" and "powersave" are > >>compiled in. > > > >No, I used the same .config in all versions that I tested. I've also > >tried setting them as modules rather than built-in. This is the stock > >slackware .config: > > > >CONFIG_CPU_FREQ=y > >CONFIG_CPU_FREQ_TABLE=m > >CONFIG_CPU_FREQ_GOV_COMMON=y > >CONFIG_CPU_FREQ_STAT=m > >CONFIG_CPU_FREQ_STAT_DETAILS=y > ># CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > >CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > ># CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > ># CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set > >CONFIG_CPU_FREQ_GOV_PERFORMANCE=m > >CONFIG_CPU_FREQ_GOV_POWERSAVE=m > >CONFIG_CPU_FREQ_GOV_USERSPACE=y > >CONFIG_CPU_FREQ_GOV_ONDEMAND=m > >CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > > >And modprobing any governor module does not change the output of > >scaling_available_governors. > > > >-Dave > > I'm also experiencing this with a Intel G640 dual core machine. > Exactly the same effect. Do you have CONFIG_X86_INTEL_PSTATE set? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: perf and Kconfig
Hi, I just checked your branch perf/kbuild9. Your work is far more elaborate than mine. In my branch, I just reused the *config targets so as to generate the files .config include/config/auto.conf(.cmd), ...; after that, I manually modified Makefile.perf with the variables CONFIG_* instead of using the whole Kbuild system. Thank you for your mail, it helped me a lot. Alexis. On Mon, Dec 23, 2013 at 12:54 PM, Jiri Olsa wrote: > On Fri, Dec 20, 2013 at 06:00:05PM -0700, David Ahern wrote: >> [adding perf maintainers] >> >> On 12/20/13, 5:39 PM, Alexis Berlemont wrote: >> >Hi, >> > >> >Here is a proposal of a small contribution which tries to fulfill the >> >task "Use Kconfig to allow selecting features and build minimal >> >version of perf,..." displayed on the todo page of the perf >> >wiki (https://perf.wiki.kernel.org/index.php/Todo). >> > >> >I tried to continue the work started by David Ahern >> >(https://github.com/dsahern/linux.git branch:perf-config). This >> >version relies on the features detection tests available in >> >linux/tools/perf/config/feature-checks so as to enable some >> >configuration options (at least by default). >> > >> >This little task is not complete; more Kconfig options should be added >> >for each perf tool (top, record, report, ...). >> > >> >I just wanted to ask whether you consider this proposal as interesting >> >enough for inclusion and if you are ok with the way it is implemented. >> > >> >The code is available here: https://github.com/aberlemont/linux.git >> >- branch: perf-config. >> >> I know Jiri has an attempt in his tree and there have been a few >> discussions since then as well. I'll take a look at it next week. I >> would like to see it completed; I just don't have the time to do it. > > hi, > my latest branch (out of sync for long time) for kbuild: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/kbuild9 > > I'll check your changes ;-) > > jirka -- 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: Problem with cpufreq and i5 since post 3.9.0
On (27/12/13 19:53), Dave Woodfall put forth the proposition: On (27/12/13 20:44), Heinz Diehl put forth the proposition: On 27.12.2013, David Woodfall wrote: But any of the newer kernel versions I've tested only give me performance and powersave. I don't use any Fedora kernel, so I can't tell which governors are enabled in those. You should check the value of "CONFIG_CPU_FREQ_GOV" in the respective .config file for your installed kernel. In short: It seems that only "performance" and "powersave" are compiled in. No, I used the same .config in all versions that I tested. I've also tried setting them as modules rather than built-in. This is the stock slackware .config: CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m And modprobing any governor module does not change the output of scaling_available_governors. -Dave I'm also experiencing this with a Intel G640 dual core machine. Exactly the same effect. -- 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/1] USB: Nokia 502 is an unusual device
The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by: Mikhail Zolotaryov --- drivers/usb/storage/unusual_devs.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index de32cfa..ad06255 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -234,6 +234,13 @@ UNUSUAL_DEV( 0x0421, 0x0495, 0x0370, 0x0370, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_MAX_SECTORS_64 ), +/* Patch submitted by Mikhail Zolotaryov */ +UNUSUAL_DEV( 0x0421, 0x06aa, 0x1110, 0x1110, + "Nokia", + "502", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_MAX_SECTORS_64 ), + #ifdef NO_SDDR09 UNUSUAL_DEV( 0x0436, 0x0005, 0x0100, 0x0100, "Microtech", -- 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: [RFC] speeding up the stat() family of system calls...
On 12/26/2013 10:09 PM, H. Peter Anvin wrote: > On 12/26/2013 11:00 AM, Linus Torvalds wrote: >> >> Interestingly, looking at the cp_new_stat() profiles, the games we >> play to get efficient range checking seem to actually hurt us. Maybe >> it's the "sbb" that is just expensive, or maybe it's turning a (very >> predictable) conditional branch into a data dependency chain instead. >> Or maybe it's just random noise in my profiles that happened to make >> those sbb's look bad. >> > > Much to my surprise, this patch adds almost 10K of text to an > "allyesconfig" build. I wouldn't have expected it. I'll look at it > some more tomorrow. > Mystery solved... it is all code added by gcov because a new (inline) function is added to the code base. So it is fluff, not real. -hpa -- 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: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE
On 12/26/2013 10:20 PM, Sasha Levin wrote: Most of the VM_BUG_ON assertions are performed on a page. Usually, when one of these assertions fails we'll get a BUG_ON with a call stack and the registers. I've recently noticed based on the requests to add a small piece of code that dumps the page to various VM_BUG_ON sites that the page dump is quite useful to people debugging issues in mm. This patch adds a VM_BUG_ON_PAGE(cond, page) which beyond doing what VM_BUG_ON() does, also dumps the page before executing the actual BUG_ON. Somewhat related to that, I've tried adding a VM_BUG_ON_PAGE in SetPageXXX() and ClearPageXXX macros to catch cases where page flags are being set or cleared twice. There seems to be a lot of those... Is that a valid use? Or should it be fixed? 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] lib/vsprintf: add %pT[C012] format specifier
On Wed, 25 Dec 2013 21:37:33 +0900 Tetsuo Handa
wrote:
> Some examples for converting direct ->comm users are shown below.
>
> pr_info("comm=%s\n", p->comm);=> pr_info("comm=%pTC\n", p);
> pr_info("%s[%u]\n", p->comm, p->pid); => pr_info("%pT0\n", p);
> pr_info("%s[%u]\n", p->comm, task_pid_nr(p)); => pr_info("%pT0\n", p);
> pr_info("%s/%u\n", p->comm, p->pid); => pr_info("%pT1\n", p);
> pr_info("%s,%u\n", p->comm, p->pid); => pr_info("%pT2\n", p);
Places where one task accesses a different tasks's ->comm are rare, and
those places damn well better have a lot of locking in place -
otherwise they are racy against much more serious things than prctl().
The vast majority of ->comm accesses are accessing current->comm, for
debug reasons. I'm counting 350-odd sites. At all these sites it's
pointless passing `current' to the printk function at all!
I wonder if there's some way in which we can invent a vsprintf token
which means "insert corrent->comm here" and which doesn't require that
the caller pass in the additional argument?
That being said.
current->comm isn't a terribly good way of identifying a task - it's
unaware of namespaces, is non-unique, userspace can overwrite ->comm[]
to anything it wants and evil users can probably write silly stuff into
->comm[] to confuse sysadmin tools.
So perhaps the world would be a better place if we were to invent a
standard kernel-wide way of identifying a process within a debug
printk. Presumably it would include ->comm and the pid, but other
things can be added later if needed.
So a usage site would look like:
pr_warn("%s: hair on fire\n", this_task_id());
but we need storage so it's really
char b[THIS_TASK_ID_SIZE];
pr_warn("%s: hair on fire\n", this_task_id(b));
which is painful, so we also provide the new vsprintf token as a
convenience:
pr_warn("%|: hair on fire\n");
but I don't know what we can use in place of %|.
--
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] Add the LED burst trigger
On Fri, 2013-12-27 at 18:13 +, One Thousand Gnomes wrote: > > Well, this one will be really smaller. And yes, it will make some > > memory non-swappable, but I believe with triggers and infrastructure > > for N900 (and similar) it will be worth it. > > Ah yes thats such a major proportion of platforms > > > Plus, it will actually save CPU cycles, and thus significant power. > > All of which will be totally wiped out if you bump all the millions of > x86 server boxes in the world up by one page of kernel space and cause a > few disk I/Os FWIW the LED subsystem was designed to take advantage of kernel modules. If you don't use a given trigger, it needn't be in memory, loaded or even built at all. If something changed there which made that not possible, that would be rather sad. I agree with you that we shouldn't bump the kernel size unnecessarily but I don't think triggers should do so. I actually think the kernel could do with going on a diet and at least made so you can untangle more of the pieces you don't want/need. Cheers, Richard -- 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 net-next 19/20] net: plip: slight optimization of addr compare
> Hi Julia.
>
> Maybe this explanation is helpful?
>
> ethernet addresses are u8[6] (48 bits)
>
> ether_addr_equal_64bits gets passed a pointer to u8[8]
> and is more efficient on 64 bit architectures than
> ether_addr_equal because the test can be done with a
> single compare and shift.
>
> The idea is not to access past the end of the ethernet
> address as appropriate (think pointer to eeprom or other
> such end-of-addressable memory conditions)
>
> If a struct containing an ethernet address has additional
> members after the ethernet address, or the u8[6] address
> passed to ether_addr_equal is not going to access past
> the end of memory or the structure, then
> ether_addr_equal_64bits should be used in lieu of
> ether_addr_equal.
I tried the following semantic patch:
@r@
type T;
T *eth;
identifier fld;
type T1;
T1 *eth1;
identifier fld1;
expression e1;
position p;
@@
ether_addr_equal@p(eth->fld, eth1->fld1)
@ok@
type r.T, t1, t2;
identifier r.fld, fld2;
@@
T { ...
t1 fld[...];
t2 fld2;
...
};
@ok1@
type r.T1, t1, t2;
identifier r.fld1, fld2;
@@
T1 { ...
t1 fld1[...];
t2 fld2;
...
};
@depends on ok && ok1@
position r.p;
@@
*ether_addr_equal@p(...)
The first rule finds an existing call to ether_addr_equal where both
arguments are structure field references. It gets the type of the
structure in each case, and notes the field name. The next two rules
check each of the structure declarations to ensure that the field is
declared as an array and it is followed by at least one other field. The
last rule generates some output for cases where both fields pass the test.
Note that this is not at all exhaustive, because it is not checking cases
where one argument is a parameter that is passed from some call site where
the argument is a field that has this property. Thus, it does not find
the case in drivers/net/ethernet/intel/i40e/i40e_main.c. Nevertheless, it
does find a few occurrences, as shown below. In this output, - indicates
an item of interest, not something to be removed. It is not a patch, even
though it looks like one.
One can get quite a lot more results if one doesn't require that both
arguments satisfy the property, ie allowing one argument to be a function
parameter rather than a structure field reference. So perhaps it would be
worth making a (more complicated) semantic patch to find such cases.
julia
diff -u -p /var/linuxes/linux-next/drivers/net/wireless/ipw2x00/libipw_rx.c
/tmp/nothing/drivers/net/wireless/ipw2x00/libipw_rx.c
--- /var/linuxes/linux-next/drivers/net/wireless/ipw2x00/libipw_rx.c
+++ /tmp/nothing/drivers/net/wireless/ipw2x00/libipw_rx.c
@@ -1468,7 +1468,6 @@ static inline int is_same_network(struct
* as one network */
return ((src->ssid_len == dst->ssid_len) &&
(src->channel == dst->channel) &&
- ether_addr_equal(src->bssid, dst->bssid) &&
!memcmp(src->ssid, dst->ssid, src->ssid_len));
}
diff -u -p /var/linuxes/linux-next/drivers/scsi/fcoe/fcoe_ctlr.c
/tmp/nothing/drivers/scsi/fcoe/fcoe_ctlr.c
--- /var/linuxes/linux-next/drivers/scsi/fcoe/fcoe_ctlr.c
+++ /tmp/nothing/drivers/scsi/fcoe/fcoe_ctlr.c
@@ -339,7 +339,6 @@ static void fcoe_ctlr_announce(struct fc
spin_unlock_bh(>ctlr_lock);
sel = fip->sel_fcf;
- if (sel && ether_addr_equal(sel->fcf_mac, fip->dest_addr))
goto unlock;
if (!is_zero_ether_addr(fip->dest_addr)) {
printk(KERN_NOTICE "libfcoe: host%d: "
diff -u -p /var/linuxes/linux-next/drivers/scsi/fcoe/fcoe_sysfs.c
/tmp/nothing/drivers/scsi/fcoe/fcoe_sysfs.c
--- /var/linuxes/linux-next/drivers/scsi/fcoe/fcoe_sysfs.c
+++ /tmp/nothing/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -657,7 +657,6 @@ static int fcoe_fcf_device_match(struct
if (new->switch_name == old->switch_name &&
new->fabric_name == old->fabric_name &&
new->fc_map == old->fc_map &&
- ether_addr_equal(new->mac, old->mac))
return 1;
return 0;
}
diff -u -p /var/linuxes/linux-next/drivers/staging/slicoss/slicoss.c
/tmp/nothing/drivers/staging/slicoss/slicoss.c
--- /var/linuxes/linux-next/drivers/staging/slicoss/slicoss.c
+++ /tmp/nothing/drivers/staging/slicoss/slicoss.c
@@ -787,8 +787,6 @@ static bool slic_mac_filter(struct adapt
struct mcast_address *mcaddr = adapter->mcastaddrs;
while (mcaddr) {
- if (ether_addr_equal(mcaddr->address,
-ether_frame->ether_dhost))
{
adapter->rcv_multicasts++;
netdev->stats.multicast++;
return true;
diff -u -p /var/linuxes/linux-next/drivers/staging/vt6655/wpactl.c
/tmp/nothing/drivers/staging/vt6655/wpactl.c
--- /var/linuxes/linux-next/drivers/staging/vt6655/wpactl.c
+++
Good day
Can we invest in your country.My name is Mr.Tom Hook a banker here; there is an unfinished business transaction in my branch. This is a business that will profit both of us, if you are interested get back to me for more details please because the money needs to invest outside my country. I wait for your quick response Mr. Tom Hook -- 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] mm: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE fix
I messed up and forgot to commit this fix before sending out the original
patch.
It fixes build issues in various files using VM_BUG_ON_PAGE.
Signed-off-by: Sasha Levin
---
include/linux/mmdebug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index e522734..8bb6490 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -2,6 +2,7 @@
#define LINUX_MM_DEBUG_H 1
#ifdef CONFIG_DEBUG_VM
+extern void dump_page(struct page *page);
#define VM_BUG_ON(cond) BUG_ON(cond)
#define VM_BUG_ON_PAGE(cond, page) \
do { if (unlikely(cond)) { dump_page(page); BUG(); } } while(0)
--
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 1/1] selftests : Adding symbolic link limits test script
On Wed, 25 Dec 2013 17:23:10 +0100 Fabian Frederick wrote: > This patch adds fs directory in selftests and a script to explain recursive > and consecutive symbolic linking limits who have been debated > so many times. hm, it's a "test" which doesn't really test anything - it always succeeds. Why do you think the kernel needs this? -- 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: question about drivers/rtc/rtc-cmos.c
On Fri, 27 Dec 2013, Andrew Morton wrote:
> On Wed, 25 Dec 2013 20:32:12 +0100 (CET) Julia Lawall
> wrote:
>
> > The function cmos_do_probe contains the code:
> >
> > if (is_hpet_enabled()) {
> > int err;
> >
> > rtc_cmos_int_handler = hpet_rtc_interrupt;
> > err = hpet_register_irq_handler(cmos_interrupt);
> > if (err != 0) {
> > dev_warn(dev, "hpet_register_irq_handler "
> > " failed in rtc_init().");
> > goto cleanup1;
> > }
> > }
> >
> > Is it intentional that the error code returned by
> > hpet_register_irq_handler is put ina local variable that will not be seen
> > at label cleanup1? The return value is retval, which is 0 at this point.
>
> No, I'd say that's a bug. How does this look?
That is what I was going to propose.
julia
>
>
> From: Andrew Morton
> Subject: drivers/rtc/rtc-cmos.c: propagate hpet_register_irq_handler() failure
>
> If hpet_register_irq_handler() fails, cmos_do_probe() will incorrectly
> return 0.
>
> Reported-by: Julia Lawall
> Cc: John Stultz
> Cc: Grant Likely
> Cc: Rob Herring
> Signed-off-by: Andrew Morton
> ---
>
> drivers/rtc/rtc-cmos.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff -puN
> drivers/rtc/rtc-cmos.c~drivers-rtc-rtc-cmosc-propagate-hpet_register_irq_handler-failure
> drivers/rtc/rtc-cmos.c
> ---
> a/drivers/rtc/rtc-cmos.c~drivers-rtc-rtc-cmosc-propagate-hpet_register_irq_handler-failure
> +++ a/drivers/rtc/rtc-cmos.c
> @@ -708,11 +708,9 @@ cmos_do_probe(struct device *dev, struct
> irq_handler_t rtc_cmos_int_handler;
>
> if (is_hpet_enabled()) {
> - int err;
> -
> rtc_cmos_int_handler = hpet_rtc_interrupt;
> - err = hpet_register_irq_handler(cmos_interrupt);
> - if (err != 0) {
> + retval = hpet_register_irq_handler(cmos_interrupt);
> + if (retval) {
> dev_warn(dev, "hpet_register_irq_handler "
> " failed in rtc_init().");
> goto cleanup1;
> _
>
>
--
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: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE
On Fri, 27 Dec 2013 17:19:44 -0500 Sasha Levin wrote: > On 12/27/2013 05:38 AM, Kirill A. Shutemov wrote: > > On Thu, Dec 26, 2013 at 10:20:52PM -0500, Sasha Levin wrote: > >> Most of the VM_BUG_ON assertions are performed on a page. Usually, when > >> one of these assertions fails we'll get a BUG_ON with a call stack and > >> the registers. > >> > >> I've recently noticed based on the requests to add a small piece of code > >> that dumps the page to various VM_BUG_ON sites that the page dump is quite > >> useful to people debugging issues in mm. > >> > >> This patch adds a VM_BUG_ON_PAGE(cond, page) which beyond doing what > >> VM_BUG_ON() does, also dumps the page before executing the actual BUG_ON. > >> > >> Signed-off-by: Sasha Levin > > > > I like the idea. One thing I've noticed you have a lot of page flag based > > asserts, like: > > > > VM_BUG_ON_PAGE(PageLRU(page), page); > > VM_BUG_ON_PAGE(!PageLocked(page), page); > > > > What about adding per-page-flag assert macros, like: > > > > PageNotLRU_assert(page); > > PageLocked_assert(page); > > > > ? This way we will always dump right page on bug. > > > > Sure, sounds good. > > I'll send another patch on top of this one. I think I prefer the patch as-is. To do what Kirill suggests we'd have to add a heck of a lot more macros and they add little value. And the suggested names of those macros aren't very good - there's nothing in "PageNotLRU_assert" which tells the reader that this code is conditional on CONFIG_DEBUG_VM, which is a somewhat important thing. -- 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: question about drivers/rtc/rtc-cmos.c
On Wed, 25 Dec 2013 20:32:12 +0100 (CET) Julia Lawall
wrote:
> The function cmos_do_probe contains the code:
>
> if (is_hpet_enabled()) {
> int err;
>
> rtc_cmos_int_handler = hpet_rtc_interrupt;
> err = hpet_register_irq_handler(cmos_interrupt);
> if (err != 0) {
> dev_warn(dev, "hpet_register_irq_handler "
> " failed in rtc_init().");
> goto cleanup1;
> }
> }
>
> Is it intentional that the error code returned by
> hpet_register_irq_handler is put ina local variable that will not be seen
> at label cleanup1? The return value is retval, which is 0 at this point.
No, I'd say that's a bug. How does this look?
From: Andrew Morton
Subject: drivers/rtc/rtc-cmos.c: propagate hpet_register_irq_handler() failure
If hpet_register_irq_handler() fails, cmos_do_probe() will incorrectly
return 0.
Reported-by: Julia Lawall
Cc: John Stultz
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Andrew Morton
---
drivers/rtc/rtc-cmos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -puN
drivers/rtc/rtc-cmos.c~drivers-rtc-rtc-cmosc-propagate-hpet_register_irq_handler-failure
drivers/rtc/rtc-cmos.c
---
a/drivers/rtc/rtc-cmos.c~drivers-rtc-rtc-cmosc-propagate-hpet_register_irq_handler-failure
+++ a/drivers/rtc/rtc-cmos.c
@@ -708,11 +708,9 @@ cmos_do_probe(struct device *dev, struct
irq_handler_t rtc_cmos_int_handler;
if (is_hpet_enabled()) {
- int err;
-
rtc_cmos_int_handler = hpet_rtc_interrupt;
- err = hpet_register_irq_handler(cmos_interrupt);
- if (err != 0) {
+ retval = hpet_register_irq_handler(cmos_interrupt);
+ if (retval) {
dev_warn(dev, "hpet_register_irq_handler "
" failed in rtc_init().");
goto cleanup1;
_
--
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: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE
On 12/27/2013 05:38 AM, Kirill A. Shutemov wrote: On Thu, Dec 26, 2013 at 10:20:52PM -0500, Sasha Levin wrote: Most of the VM_BUG_ON assertions are performed on a page. Usually, when one of these assertions fails we'll get a BUG_ON with a call stack and the registers. I've recently noticed based on the requests to add a small piece of code that dumps the page to various VM_BUG_ON sites that the page dump is quite useful to people debugging issues in mm. This patch adds a VM_BUG_ON_PAGE(cond, page) which beyond doing what VM_BUG_ON() does, also dumps the page before executing the actual BUG_ON. Signed-off-by: Sasha Levin I like the idea. One thing I've noticed you have a lot of page flag based asserts, like: VM_BUG_ON_PAGE(PageLRU(page), page); VM_BUG_ON_PAGE(!PageLocked(page), page); What about adding per-page-flag assert macros, like: PageNotLRU_assert(page); PageLocked_assert(page); ? This way we will always dump right page on bug. Sure, sounds good. I'll send another patch on top of this one. 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/
[PATCH 0/8] Update kernel uabi header files for x32
X32 uses the same kernel system call interface as x86-64 for many system calls. However, "long" is 64-bit for x86-64 and is 32-bit for x32. Where long or unsigned long are used in struct types for such system calls, they are wrong for x32. __kernel_[u]long_t is [unsigned] long for all ABIs other than x32. I am submitting 8 patches to replace long or unsigned long with __kernel_[u]long_t so that those struct types can be used with x32 system calls. H.J. Lu (8): Use __kernel_long_t in struct timex Use __kernel_long_t/__kernel_ulong_t in Use __kernel_ulong_t in uapi struct ipc64_perm Use __kernel_long_t in struct msgbuf Use __kernel_ulong_t in struct msqid64_ds Use __kernel_ulong_t in x86 struct semid64_ds Use __kernel_ulong_t in shmid64_ds/shminfo64/shm_info Use __kernel_long_t in struct mq_attr arch/x86/include/uapi/asm/sembuf.h | 10 - include/uapi/asm-generic/ipcbuf.h | 5 + include/uapi/asm-generic/msgbuf.h | 19 +++- include/uapi/asm-generic/shmbuf.h | 36 + include/uapi/linux/mqueue.h| 18 ++- include/uapi/linux/msg.h | 8 +-- include/uapi/linux/resource.h | 26 +++-- include/uapi/linux/shm.h | 14 +--- include/uapi/linux/timex.h | 46 +++--- 9 files changed, 143 insertions(+), 39 deletions(-) -- 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 1/2] ACPI / hotplug: Add demand_offline hotplug profile flag
From: Rafael J. Wysocki
Add a new ACPI hotplug profile flag, demand_offline, such that if
set for the given ACPI device object's scan handler, it will cause
acpi_scan_hot_remove() to check if that device object's physical
companions are offline upfront and fail the hot removal if that
is not the case.
That flag will be useful to overcome a problem with containers on
some system where they can only be hot-removed after some cleanup
operations carried out by user space, which needs to be notified
of the container hot-removal before the kernel attempts to offline
devices in the container. In those cases the current implementation
of acpi_scan_hot_remove() is not sufficient, because it first tries
to offline the devices in the container and only if that is
suffcessful it tries to offline the container itself. As a result,
the container hot-removal notification is not delivered to user space
at the right time.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 41 +
include/acpi/acpi_bus.h |3 ++-
2 files changed, 39 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -126,6 +126,24 @@ acpi_device_modalias_show(struct device
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
+static bool acpi_scan_is_offline(struct acpi_device *adev)
+{
+ struct acpi_device_physical_node *pn;
+ bool offline = true;
+
+ mutex_lock(>physical_node_lock);
+
+ list_for_each_entry(pn, >physical_node_list, node)
+ if (device_supports_offline(pn->dev) && !pn->dev->offline) {
+ kobject_uevent(>dev->kobj, KOBJ_CHANGE);
+ offline = false;
+ break;
+ }
+
+ mutex_unlock(>physical_node_lock);
+ return offline;
+}
+
static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
void **ret_p)
{
@@ -196,12 +214,11 @@ static acpi_status acpi_bus_online(acpi_
return AE_OK;
}
-static int acpi_scan_hot_remove(struct acpi_device *device)
+static int acpi_scan_try_to_offline(struct acpi_device *device)
{
acpi_handle handle = device->handle;
- struct device *errdev;
+ struct device *errdev = NULL;
acpi_status status;
- unsigned long long sta;
/*
* Carry out two passes here and ignore errors in the first pass,
@@ -212,7 +229,6 @@ static int acpi_scan_hot_remove(struct a
*
* If the first pass is successful, the second one isn't needed, though.
*/
- errdev = NULL;
status = acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
NULL, acpi_bus_offline, (void *)false,
(void **));
@@ -241,6 +257,23 @@ static int acpi_scan_hot_remove(struct a
return -EBUSY;
}
}
+ return 0;
+}
+
+static int acpi_scan_hot_remove(struct acpi_device *device)
+{
+ acpi_handle handle = device->handle;
+ unsigned long long sta;
+ acpi_status status;
+
+ if (device->handler->hotplug.demand_offline && !acpi_force_hot_remove) {
+ if (!acpi_scan_is_offline(device))
+ return -EBUSY;
+ } else {
+ int error = acpi_scan_try_to_offline(device);
+ if (error)
+ return error;
+ }
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(>dev)));
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -91,8 +91,9 @@ struct acpi_device;
struct acpi_hotplug_profile {
struct kobject kobj;
- bool enabled:1;
int (*scan_dependent)(struct acpi_device *adev);
+ bool enabled:1;
+ bool demand_offline:1;
};
static inline struct acpi_hotplug_profile *to_acpi_hotplug_profile(
--
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 4/8] Use __kernel_long_t in struct msgbuf
X32 msgsnd/msgrcv system calls are the same as x86-64 msgsnd/msgrcv system
calls, which use 64-bit integer for long in struct msgbuf . But x32 long
is 32 bit. This patch replaces long in struct msgbuf with __kernel_long_t.
Signed-off-by: H.J. Lu
---
include/uapi/linux/msg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/msg.h b/include/uapi/linux/msg.h
index 22d95c6..a703755 100644
--- a/include/uapi/linux/msg.h
+++ b/include/uapi/linux/msg.h
@@ -34,8 +34,8 @@ struct msqid_ds {
/* message buffer for msgsnd and msgrcv calls */
struct msgbuf {
- long mtype; /* type of message */
- char mtext[1]; /* message text */
+ __kernel_long_t mtype; /* type of message */
+ char mtext[1]; /* message text */
};
/* buffer for msgctl calls IPC_INFO, MSG_INFO */
--
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 0/2] ACPI / hotplug / driver core: Special handling for container devices
Hi Greg, The following series of 2 patches (patch [2/2] in particular) make changes needed to handle hot-removal of system container devices (represented by ACPI container and module device objects) on Fujitsu systems. Those devices represent things like CPU packages, so we need to be able to take care of them cleanly for things like in-the-field CPU socked replacement to work. The problem being addressed here is that on the systems in question the removal of container devices has to be carried out with the help of user space that needs to be notified of the container removal before the kernel attempts to offline any devices below the container (e.g. in the package represented by the container device object in the ACPI tables). However, our current code works the other way around and the entire thing is messed up. This patchset adds the bare bones of what's needed to address that issue and it should be possible to build on top of the code added by it in the future if need be. Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile that makes acpi_scan_hot_remove() check the offline status of the device object's companion physical devices to start with and return -EBUSY if at least one of them is not offline. Patch [2/2] uses that flag to implement the container handling. The details are in the changelog, but that's how it works. During the initial namespace scan the container ACPI scan handler creates "physical" system container device under /sys/devices/system/container/ for each ACPI container object whose status is "present" at that time (the sysfs name of that device is the same as the sysfs name of the corresponding container object and they are linked to each other via the firmware_node and physical_node symbolic links, respectively). Those system container devices are initially online. The container ACPI scan handler has the demand_offline flag set in its hotplug profile, so when a container eject event happens, acpi_scan_hot_remove() will notice that the flag is set in the device object's scan handler and will check the online status of its "physical" companion device, which is online (that is the system container device the above paragraph is about). That will cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to be returned by acpi_scan_hot_remove(). User space is expected to respond to that KOBJ_CHANGE by doing what's necessary to remove the container. To that end, it needs to offline the system container device through its online sysfs attribute (which is present, because the bus type for containers provides the online and offline callbacks). However, the offline for system container devices will only succeed if the physical devices right below the container (e.g. in the package represented by it) are all offline, so user space will have to offline those devices before attempting to offline the system container device itself. When finished, user space can trigger the container removal with the help of the eject sysfs attribute of the ACPI container object pointed to by the system container device's firmware_node link (this time the check in acpi_scan_hot_remove() will succeed, because the system container device in question is now offline). Please let me know if you have any objections. If not, I'd like to queue up these patches for 3.14. Thanks, Rafael -- 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/8] 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 3/8] Use __kernel_ulong_t in uapi struct ipc64_perm
X32 IPC system call is the same as x86-64 IPC system call, which uses
64-bit integer for unsigned long in struct ipc64_perm. But x32 long is
32 bit. This patch replaces unsigned long in uapi struct ipc64_perm with
__kernel_ulong_t.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/ipcbuf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/asm-generic/ipcbuf.h
b/include/uapi/asm-generic/ipcbuf.h
index 76982b2..3dbcc1e 100644
--- a/include/uapi/asm-generic/ipcbuf.h
+++ b/include/uapi/asm-generic/ipcbuf.h
@@ -27,8 +27,8 @@ struct ipc64_perm {
unsigned char __pad1[4 - sizeof(__kernel_mode_t)];
unsigned short seq;
unsigned short __pad2;
- unsigned long __unused1;
- unsigned long __unused2;
+ __kernel_ulong_t__unused1;
+ __kernel_ulong_t__unused2;
};
#endif /* __ASM_GENERIC_IPCBUF_H */
--
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 2/8] Use __kernel_long_t/__kernel_ulong_t in
Both x32 and x86-64 use the same struct rusage and struct rlimit for
system calls. But x32 log is 32-bit. This patch change uapi
to use __kernel_long_t in struct rusage and
__kernel_ulong_t in and struct rlimit.
Signed-off-by: H.J. Lu
---
include/uapi/linux/resource.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/uapi/linux/resource.h b/include/uapi/linux/resource.h
index e0ed284..36fb3b5 100644
--- a/include/uapi/linux/resource.h
+++ b/include/uapi/linux/resource.h
@@ -23,25 +23,25 @@
struct rusage {
struct timeval ru_utime;/* user time used */
struct timeval ru_stime;/* system time used */
- longru_maxrss; /* maximum resident set size */
- longru_ixrss; /* integral shared memory size */
- longru_idrss; /* integral unshared data size */
- longru_isrss; /* integral unshared stack size */
- longru_minflt; /* page reclaims */
- longru_majflt; /* page faults */
- longru_nswap; /* swaps */
- longru_inblock; /* block input operations */
- longru_oublock; /* block output operations */
- longru_msgsnd; /* messages sent */
- longru_msgrcv; /* messages received */
- longru_nsignals;/* signals received */
- longru_nvcsw; /* voluntary context switches */
- longru_nivcsw; /* involuntary " */
+ __kernel_long_t ru_maxrss; /* maximum resident set size */
+ __kernel_long_t ru_ixrss; /* integral shared memory size */
+ __kernel_long_t ru_idrss; /* integral unshared data size */
+ __kernel_long_t ru_isrss; /* integral unshared stack size */
+ __kernel_long_t ru_minflt; /* page reclaims */
+ __kernel_long_t ru_majflt; /* page faults */
+ __kernel_long_t ru_nswap; /* swaps */
+ __kernel_long_t ru_inblock; /* block input operations */
+ __kernel_long_t ru_oublock; /* block output operations */
+ __kernel_long_t ru_msgsnd; /* messages sent */
+ __kernel_long_t ru_msgrcv; /* messages received */
+ __kernel_long_t ru_nsignals;/* signals received */
+ __kernel_long_t ru_nvcsw; /* voluntary context switches */
+ __kernel_long_t ru_nivcsw; /* involuntary " */
};
struct rlimit {
- unsigned long rlim_cur;
- unsigned long rlim_max;
+ __kernel_ulong_trlim_cur;
+ __kernel_ulong_trlim_max;
};
#define RLIM64_INFINITY(~0ULL)
--
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 2/2] ACPI / hotplug / driver core: Handle containers in a special way
From: Rafael J. Wysocki
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.
Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.
The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.
For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
device cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.
Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.
Signed-off-by: Rafael J. Wysocki
Tested-by: Yasuaki Ishimatsu
---
drivers/acpi/container.c | 48 ++
drivers/acpi/internal.h |1
drivers/acpi/scan.c |8 ---
drivers/base/Makefile |2 -
drivers/base/base.h |1
drivers/base/container.c | 44 ++
drivers/base/init.c |1
include/linux/container.h | 25 +++
8 files changed, 122 insertions(+), 8 deletions(-)
Index: linux-pm/include/linux/container.h
===
--- /dev/null
+++ linux-pm/include/linux/container.h
@@ -0,0 +1,25 @@
+/*
+ * Definitions for container bus type.
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Rafael J. Wysocki
+ *
+ * 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.
+ */
+
+#include
+
+/* drivers/base/power/container.c */
+extern struct bus_type container_subsys;
+
+struct container_dev {
+ struct device dev;
+ int (*offline)(struct container_dev *cdev);
+};
+
+static inline struct container_dev *to_container_dev(struct device *dev)
+{
+ return container_of(dev, struct container_dev, dev);
+}
Index: linux-pm/drivers/base/container.c
===
--- /dev/null
+++ linux-pm/drivers/base/container.c
@@ -0,0 +1,44 @@
+/*
+ * System bus type for containers.
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Rafael J. Wysocki
+ *
+ * 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.
+ */
+
+#include
+
+#include "base.h"
+
+#define CONTAINER_BUS_NAME "container"
+
+static int trivial_online(struct device *dev)
+{
+ return 0;
+}
+
+static int container_offline(struct device *dev)
+{
+ struct container_dev *cdev = to_container_dev(dev);
+
+ return cdev->offline ? cdev->offline(cdev) : 0;
+}
+
+struct bus_type container_subsys = {
+ .name =
[PATCH 7/8] Use __kernel_ulong_t in shmid64_ds/shminfo64/shm_info
Both x32 and x86-64 use the same struct shmid64_ds/shminfo64/shm_info for
system calls. But x32 long is 32-bit. This patch replaces unsigned long
with __kernel_ulong_t in struct shmid64_ds/shminfo64/shm_info.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/shmbuf.h | 24
include/uapi/linux/shm.h | 10 +-
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/include/uapi/asm-generic/shmbuf.h
b/include/uapi/asm-generic/shmbuf.h
index 5768fa6..7e9fb2f 100644
--- a/include/uapi/asm-generic/shmbuf.h
+++ b/include/uapi/asm-generic/shmbuf.h
@@ -39,21 +39,21 @@ struct shmid64_ds {
#endif
__kernel_pid_t shm_cpid; /* pid of creator */
__kernel_pid_t shm_lpid; /* pid of last operator */
- unsigned long shm_nattch; /* no. of current attaches */
- unsigned long __unused4;
- unsigned long __unused5;
+ __kernel_ulong_tshm_nattch; /* no. of current attaches */
+ __kernel_ulong_t__unused4;
+ __kernel_ulong_t__unused5;
};
struct shminfo64 {
- unsigned long shmmax;
- unsigned long shmmin;
- unsigned long shmmni;
- unsigned long shmseg;
- unsigned long shmall;
- unsigned long __unused1;
- unsigned long __unused2;
- unsigned long __unused3;
- unsigned long __unused4;
+ __kernel_ulong_tshmmax;
+ __kernel_ulong_tshmmin;
+ __kernel_ulong_tshmmni;
+ __kernel_ulong_tshmseg;
+ __kernel_ulong_tshmall;
+ __kernel_ulong_t__unused1;
+ __kernel_ulong_t__unused2;
+ __kernel_ulong_t__unused3;
+ __kernel_ulong_t__unused4;
};
#endif /* __ASM_GENERIC_SHMBUF_H */
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index ec36fa1..78b6941 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -68,11 +68,11 @@ struct shminfo {
struct shm_info {
int used_ids;
- unsigned long shm_tot; /* total allocated shm */
- unsigned long shm_rss; /* total resident shm */
- unsigned long shm_swp; /* total swapped shm */
- unsigned long swap_attempts;
- unsigned long swap_successes;
+ __kernel_ulong_t shm_tot; /* total allocated shm */
+ __kernel_ulong_t shm_rss; /* total resident shm */
+ __kernel_ulong_t shm_swp; /* total swapped shm */
+ __kernel_ulong_t swap_attempts;
+ __kernel_ulong_t swap_successes;
};
--
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 8/8] Use __kernel_long_t in struct mq_attr
Both x32 and x86-64 use the same struct mq_attr for system calls. But
x32 long is 32-bit. This patch replaces long with __kernel_long_t in
struct mq_attr.
Signed-off-by: H.J. Lu
---
include/uapi/linux/mqueue.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/mqueue.h b/include/uapi/linux/mqueue.h
index 8b5a796..d0a2b8e 100644
--- a/include/uapi/linux/mqueue.h
+++ b/include/uapi/linux/mqueue.h
@@ -23,11 +23,11 @@
#define MQ_BYTES_MAX 819200
struct mq_attr {
- longmq_flags; /* message queue flags */
- longmq_maxmsg; /* maximum number of messages */
- longmq_msgsize; /* maximum message size */
- longmq_curmsgs; /* number of messages currently queued */
- long__reserved[4]; /* ignored for input, zeroed for output */
+ __kernel_long_t mq_flags; /* message queue flags
*/
+ __kernel_long_t mq_maxmsg; /* maximum number of messages
*/
+ __kernel_long_t mq_msgsize; /* maximum message size
*/
+ __kernel_long_t mq_curmsgs; /* number of messages currently queued
*/
+ __kernel_long_t __reserved[4]; /* ignored for input, zeroed for output
*/
};
/*
--
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 6/8] Use __kernel_ulong_t in x86 struct semid64_ds
Both x32 and x86-64 use the same struct semid64_ds for system calls.
But x32 long is 32-bit. This patch replaces unsigned long with
__kernel_ulong_t in x86 struct semid64_ds.
Signed-off-by: H.J. Lu
---
arch/x86/include/uapi/asm/sembuf.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/uapi/asm/sembuf.h
b/arch/x86/include/uapi/asm/sembuf.h
index ee50c80..cc2d6a3 100644
--- a/arch/x86/include/uapi/asm/sembuf.h
+++ b/arch/x86/include/uapi/asm/sembuf.h
@@ -13,12 +13,12 @@
struct semid64_ds {
struct ipc64_perm sem_perm; /* permissions .. see ipc.h */
__kernel_time_t sem_otime; /* last semop time */
- unsigned long __unused1;
+ __kernel_ulong_t __unused1;
__kernel_time_t sem_ctime; /* last change time */
- unsigned long __unused2;
- unsigned long sem_nsems; /* no. of semaphores in array */
- unsigned long __unused3;
- unsigned long __unused4;
+ __kernel_ulong_t __unused2;
+ __kernel_ulong_t sem_nsems; /* no. of semaphores in array */
+ __kernel_ulong_t __unused3;
+ __kernel_ulong_t __unused4;
};
#endif /* _ASM_X86_SEMBUF_H */
--
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 5/8] Use __kernel_ulong_t in struct msqid64_ds
Both x32 and x86-64 use the same struct msqid64_ds for system calls.
But x32 long is 32-bit. This patch replaces unsigned long with
__kernel_ulong_t in struct msqid64_ds.
Signed-off-by: H.J. Lu
---
include/uapi/asm-generic/msgbuf.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/asm-generic/msgbuf.h
b/include/uapi/asm-generic/msgbuf.h
index aec850d..f55ecc4 100644
--- a/include/uapi/asm-generic/msgbuf.h
+++ b/include/uapi/asm-generic/msgbuf.h
@@ -35,13 +35,13 @@ struct msqid64_ds {
#if __BITS_PER_LONG != 64
unsigned long __unused3;
#endif
- unsigned long msg_cbytes; /* current number of bytes on queue */
- unsigned long msg_qnum;/* number of messages in queue */
- unsigned long msg_qbytes; /* max number of bytes on queue */
+ __kernel_ulong_t msg_cbytes;/* current number of bytes on queue */
+ __kernel_ulong_t msg_qnum; /* number of messages in queue */
+ __kernel_ulong_t msg_qbytes;/* max number of bytes on queue */
__kernel_pid_t msg_lspid; /* pid of last msgsnd */
__kernel_pid_t msg_lrpid; /* last receive pid */
- unsigned long __unused4;
- unsigned long __unused5;
+ __kernel_ulong_t __unused4;
+ __kernel_ulong_t __unused5;
};
#endif /* __ASM_GENERIC_MSGBUF_H */
--
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/
Re: [PATCH 1/8] Use __kernel_long_t in struct timex
On 12/27/2013 09:25 AM, H.J. Lu wrote:
> 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
> if __BITS_PER_LONG == 64.
>
> Signed-off-by: H.J. Lu
> ---
> include/uapi/linux/timex.h | 46
> ++
> 1 file changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
> index a7ea81f..98314e9 100644
> --- a/include/uapi/linux/timex.h
> +++ b/include/uapi/linux/timex.h
> @@ -63,28 +63,58 @@
> */
> struct timex {
> unsigned int modes; /* mode selector */
> +#if __BITS_PER_LONG == 64
> + __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) */
> +#else
> long offset;/* time offset (usec) */
> long freq; /* frequency offset (scaled ppm) */
> long maxerror; /* maximum error (usec) */
> long esterror; /* estimated error (usec) */
> +#endif
> int status; /* clock command/status */
I thought we already discussed this? No __BITS_PER_LONG conditionals,
please, unless you can strongly motivate them... and if so, we probably
should introduce another __kernel type instead.
-hpa
--
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] x86, irq, fix logical AND/OR error in check_irq_vectors_for_cpu_disable()
On 12/23/2013 06:39 AM, Prarit Bhargava wrote: > Patch is against linux-tip.git and was tested on both linux.git and tip > without > any issues. As expected, the number of required vectors for the down'd cpu > drops from 202 to 181 on my test system (which has 509 vectors assigned in > total). > > Many thanks to Gong Chen for catching this. > > P. > > 8< > > Gong Chen caught this coding error during inspection of the patch. The > code should be AND not OR. > Please include a description that is understandable by someone who isn't familiar with the back story to this patch. The patch descriptions become part of the permanent record of the history of the Linux kernel and are critical to it being understandable. -hpa -- 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] i40e: use ether_addr_equal_64bits
On Fri, 2013-12-27 at 13:56 -0800, Joe Perches wrote:
> All ether_addr_equal tests in i40e can use the
> slightly more efficient ether_addr_equal_64bits.
>
> All addresses passed to the various functions that
> use ether_addr_equal are using structs that have 2
> or more bytes of additional data after the mac addr
> being tested.
>
> struct i40e_mac_filter.macaddr[6] (followed by s16 vlan)
> struct net_device.dev_addr (pointer to char array of MAX_ADDR_LEN)
> struct sockaddr.sa_data (array of 14 bytes)
> struct netdev_hw_addr.addr (pointer to char array of MAX_ADDR_LEN)
>
> Signed-off-by: Joe Perches
It looks good, but I would like Jesse and Shannon to review it since we
just were talking about a similar patch last week.
I will add the patch to my queue for now, thanks Joe.
> ---
>
> On Fri, 2013-12-27 at 12:46 -0800, Joe Perches wrote:
> > On Fri, 2013-12-27 at 21:12 +0100, Julia Lawall wrote:
> > > On Fri, 27 Dec 2013, Joe Perches wrote:
> > >
> > > > On Fri, 2013-12-27 at 07:48 -0800, Eric Dumazet wrote:
> > > > > On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
> > > > > > Use possibly more efficient ether_addr_equal
> > > > > > to instead of memcmp.
> > > > []
> > > > > > diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
> > > > []
> > > > > > @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff
> > > > > > *skb, struct net_device *dev)
> > > > > >
> > > > > > 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;
> > > > >
> > > > > What about :
> > > > >
> > > > > if (is_multicast_ether_addr(eth->h_dest)) {
> > > > > if (ether_addr_equal_64bits(eth->h_dest,
> > > > > dev->broadcast))
> > > > > skb->pkt_type = PACKET_BROADCAST;
> > > > > else
> > > > > skb->pkt_type = PACKET_MULTICAST;
> > > > > }
> > > >
> > > > That is better though I wonder how many systems are
> > > > still using laplink via parallel null-printer cables.
> > > >
> > > > No matter, better is better.
> > > >
> > > > The same optimization using ether_addr_equal_64bits
> > > > may be possible to do in other places given other
> > > > structs too.
> > > >
> > > > Perhaps it's a possible spatch/coccinelle conversion,
> > > >
> > > > I don't know spatch well enough to know if a
> > > > mechanism to check if structure members have other
> > > > fields that follow them in the structure or if the
> > > > structure member is an array of a minimum size.
> > > >
> > > > Maybe Julia does. (cc'd)
> > >
> > > I'm not sure to competely understand the issues. Could you explain more?
> >
> > Hi Julia.
> >
> > Maybe this explanation is helpful?
> >
> > ethernet addresses are u8[6] (48 bits)
> >
> > ether_addr_equal_64bits gets passed a pointer to u8[8]
> > and is more efficient on 64 bit architectures than
> > ether_addr_equal because the test can be done with a
> > single compare and shift.
> >
> > The idea is not to access past the end of the ethernet
> > address as appropriate (think pointer to eeprom or other
> > such end-of-addressable memory conditions)
> >
> > If a struct containing an ethernet address has additional
> > members after the ethernet address, or the u8[6] addressa
> > passed to ether_addr_equal is not going to access past
> > the end of memory or the structure, then
> > ether_addr_equal_64bits should be used in lieu of
> > ether_addr_equal.
>
> I believe this is correct, but maybe the
> conditions for using ether_addr_equal_64bits
> could be documented a bit better.
>
> Jeff/Intel folk? What do you think?
>
> drivers/net/ethernet/intel/i40e/i40e_main.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index efdf8a2..4c1d35c 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -992,7 +992,7 @@ static struct i40e_mac_filter *i40e_find_filter(struct
> i40e_vsi *vsi,
> return NULL;
>
> list_for_each_entry(f, >mac_filter_list, list) {
> - if ((ether_addr_equal(macaddr, f->macaddr)) &&
> + if (ether_addr_equal_64bits(macaddr, f->macaddr) &&
> (vlan == f->vlan)&&
> (!is_vf || f->is_vf) &&
> (!is_netdev || f->is_netdev))
> @@ -1020,7 +1020,7 @@ struct i40e_mac_filter *i40e_find_mac(struct i40e_vsi
> *vsi, u8 *macaddr,
> return NULL;
>
> list_for_each_entry(f, >mac_filter_list, list) {
> - if ((ether_addr_equal(macaddr, f->macaddr)) &&
> + if
[PATCH] i40e: use ether_addr_equal_64bits
All ether_addr_equal tests in i40e can use the
slightly more efficient ether_addr_equal_64bits.
All addresses passed to the various functions that
use ether_addr_equal are using structs that have 2
or more bytes of additional data after the mac addr
being tested.
struct i40e_mac_filter.macaddr[6] (followed by s16 vlan)
struct net_device.dev_addr (pointer to char array of MAX_ADDR_LEN)
struct sockaddr.sa_data (array of 14 bytes)
struct netdev_hw_addr.addr (pointer to char array of MAX_ADDR_LEN)
Signed-off-by: Joe Perches
---
On Fri, 2013-12-27 at 12:46 -0800, Joe Perches wrote:
> On Fri, 2013-12-27 at 21:12 +0100, Julia Lawall wrote:
> > On Fri, 27 Dec 2013, Joe Perches wrote:
> >
> > > On Fri, 2013-12-27 at 07:48 -0800, Eric Dumazet wrote:
> > > > On Fri, 2013-12-27 at 14:49 +0800, Ding Tianhong wrote:
> > > > > Use possibly more efficient ether_addr_equal
> > > > > to instead of memcmp.
> > > []
> > > > > diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
> > > []
> > > > > @@ -549,7 +549,7 @@ static __be16 plip_type_trans(struct sk_buff
> > > > > *skb, struct net_device *dev)
> > > > >
> > > > > 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;
> > > >
> > > > What about :
> > > >
> > > > if (is_multicast_ether_addr(eth->h_dest)) {
> > > > if (ether_addr_equal_64bits(eth->h_dest,
> > > > dev->broadcast))
> > > > skb->pkt_type = PACKET_BROADCAST;
> > > > else
> > > > skb->pkt_type = PACKET_MULTICAST;
> > > > }
> > >
> > > That is better though I wonder how many systems are
> > > still using laplink via parallel null-printer cables.
> > >
> > > No matter, better is better.
> > >
> > > The same optimization using ether_addr_equal_64bits
> > > may be possible to do in other places given other
> > > structs too.
> > >
> > > Perhaps it's a possible spatch/coccinelle conversion,
> > >
> > > I don't know spatch well enough to know if a
> > > mechanism to check if structure members have other
> > > fields that follow them in the structure or if the
> > > structure member is an array of a minimum size.
> > >
> > > Maybe Julia does. (cc'd)
> >
> > I'm not sure to competely understand the issues. Could you explain more?
>
> Hi Julia.
>
> Maybe this explanation is helpful?
>
> ethernet addresses are u8[6] (48 bits)
>
> ether_addr_equal_64bits gets passed a pointer to u8[8]
> and is more efficient on 64 bit architectures than
> ether_addr_equal because the test can be done with a
> single compare and shift.
>
> The idea is not to access past the end of the ethernet
> address as appropriate (think pointer to eeprom or other
> such end-of-addressable memory conditions)
>
> If a struct containing an ethernet address has additional
> members after the ethernet address, or the u8[6] addressa
> passed to ether_addr_equal is not going to access past
> the end of memory or the structure, then
> ether_addr_equal_64bits should be used in lieu of
> ether_addr_equal.
I believe this is correct, but maybe the
conditions for using ether_addr_equal_64bits
could be documented a bit better.
Jeff/Intel folk? What do you think?
drivers/net/ethernet/intel/i40e/i40e_main.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index efdf8a2..4c1d35c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -992,7 +992,7 @@ static struct i40e_mac_filter *i40e_find_filter(struct
i40e_vsi *vsi,
return NULL;
list_for_each_entry(f, >mac_filter_list, list) {
- if ((ether_addr_equal(macaddr, f->macaddr)) &&
+ if (ether_addr_equal_64bits(macaddr, f->macaddr) &&
(vlan == f->vlan)&&
(!is_vf || f->is_vf) &&
(!is_netdev || f->is_netdev))
@@ -1020,7 +1020,7 @@ struct i40e_mac_filter *i40e_find_mac(struct i40e_vsi
*vsi, u8 *macaddr,
return NULL;
list_for_each_entry(f, >mac_filter_list, list) {
- if ((ether_addr_equal(macaddr, f->macaddr)) &&
+ if (ether_addr_equal_64bits(macaddr, f->macaddr) &&
(!is_vf || f->is_vf) &&
(!is_netdev || f->is_netdev))
return f;
@@ -1209,7 +1209,7 @@ static int i40e_set_mac(struct net_device *netdev, void
*p)
netdev_info(netdev, "set mac address=%pM\n", addr->sa_data);
- if (ether_addr_equal(netdev->dev_addr, addr->sa_data))
+ if
Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad
On Friday, December 27, 2013 06:17:47 PM Kashyap Chamarthy wrote:
> On 12/27/2013 06:01 PM, Gleb Natapov wrote:
> > On Fri, Dec 27, 2013 at 06:52:48PM +0200, Gleb Natapov wrote:
> >> On Fri, Dec 27, 2013 at 03:15:39PM +0100, Kashyap Chamarthy wrote:
> >>> [. . .]
> >>>
> > KVM does not emulate P-states at all. intel_pstate_init() calls
> > intel_pstate_msrs_not_valid() before printing "Intel P-state driver
> > initializing." which suppose to fail since it checks that two reads of
> > MSR_IA32_APERF return different values, but KVM does not emulate this
> > msr
> > at all, so both calls should return zero (KVM suppose to inject #GP,
> > all rdmsrl
> > are patched to be rdmsrl_safe in a guest).
> >
> > Anything interesting in host dmesg?
> >>>
> >>> Heya Gleb,
> >>>
> >>> Here's the relevant dmesg snippet (full dmesg, refer the attachment
> >>> below):
> >> That's guest dmesg. What about host one?
>
> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
>
> >> Can you ftrace the failure?
>
> Can try, need some time (rest of the day I'll be away travelling,
> will try to do it over the weekend, and update the Kernel
> bugzilla with observations).
>
> >>
> > Ugh, it looks like guest dmesg but there are KVM messages there too ("[
> > 281.443662] kvm [2452]: vcpu0 unhandled rdmsr: 0xe8" is unhandled access
> > to MSR_IA32_APERF I was talking about above), so I guess this is nested
> > guest invocation?
>
> Yeah -- sorry, I forgot to note it's in a nested environment :(
>
> > Does it happen in non nested guest?
>
> I need to that.
>
> Note to self: Also try with a newer Kernel on the host.
Please try the patch I posted earlier today when you're at it:
https://patchwork.kernel.org/patch/3411991/
Rafael
--
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] mtd: nand: remove pasemi_nand driver
On Fri, Dec 27, 2013 at 1:10 AM, Paul Bolle wrote: > On Thu, 2013-12-26 at 21:52 -0800, Olof Johansson wrote: >> The PA Semi platform is sparsely used these days (with just a handful >> of known users out there). I'm 100% sure none of them use the MTD NAND >> driver -- most standard use cases include PCI-e SATA controllers for >> storage instead, and boot is done from LPC NOR flash. >> >> So, there's little reason to keep carrying a driver that's not used by >> anybody and that just gets hit by some tree-wide or tools-based changes >> every now and then. >> >> Signed-off-by: Olof Johansson >> --- >> drivers/mtd/nand/pasemi_nand.c | 238 >> >> 1 file changed, 238 deletions(-) >> delete mode 100644 drivers/mtd/nand/pasemi_nand.c > > If this gets accepted we should remove the related entry in > drivers/mtd/nand/Kconfig and the related line in > drivers/mtd/nand/Makefile too, shouldn't we? D'oh. Yes, of course. v2 coming. -Olof -- 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] [media] as102: fix leaks at failure paths in as102_usb_probe()
Failure handling is incomplete in as102_usb_probe(). The patch implements proper resource deallocations. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/staging/media/as102/as102_usb_drv.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/as102/as102_usb_drv.c b/drivers/staging/media/as102/as102_usb_drv.c index 9f275f020150..c1c6152d1ab4 100644 --- a/drivers/staging/media/as102/as102_usb_drv.c +++ b/drivers/staging/media/as102/as102_usb_drv.c @@ -419,15 +419,22 @@ static int as102_usb_probe(struct usb_interface *intf, /* request buffer allocation for streaming */ ret = as102_alloc_usb_stream_buffer(as102_dev); if (ret != 0) - goto failed; + goto failed_stream; /* register dvb layer */ ret = as102_dvb_register(as102_dev); + if (ret != 0) + goto failed_dvb; LEAVE(); return ret; +failed_dvb: + as102_free_usb_stream_buffer(as102_dev); +failed_stream: + usb_deregister_dev(intf, _usb_class_driver); failed: + usb_put_dev(as102_dev->bus_adap.usb_dev); usb_set_intfdata(intf, NULL); kfree(as102_dev); return ret; -- 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/
[PATCH 45/49] perf ui/tui: Split help message for perf top and report
From: Namhyung Kim
Some hotkeys don't work for perf top so split help messages for them.
It'll be helpful to a future modification. Also sort the message by
alphabetical order of the hotkey.
Signed-off-by: Namhyung Kim
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1388036284-32342-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 49 ++
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a440e03cd8c2..d43ec79ea4e3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1400,6 +1400,35 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
char script_opt[64];
int delay_secs = hbt ? hbt->refresh : 0;
+#define HIST_BROWSER_HELP_COMMON \
+ "h/?/F1Show this window\n" \
+ "UP/DOWN/PGUP\n"\
+ "PGDN/SPACENavigate\n" \
+ "q/ESC/CTRL+C Exit browser\n\n"\
+ "For multiple event sessions:\n\n" \
+ "TAB/UNTAB Switch events\n\n" \
+ "For symbolic views (--sort has sym):\n\n" \
+ "->Zoom into DSO/Threads & Annotate current symbol\n" \
+ "<-Zoom out\n" \
+ "a Annotate current symbol\n" \
+ "C Collapse all callchains\n" \
+ "d Zoom into current DSO\n" \
+ "E Expand all callchains\n" \
+
+ /* help messages are sorted by lexical order of the hotkey */
+ const char report_help[] = HIST_BROWSER_HELP_COMMON
+ "P Print histograms to perf.hist.N\n"
+ "r Run available scripts\n"
+ "s Switch to another data file in PWD\n"
+ "t Zoom into current Thread\n"
+ "V Verbose (DSO names in callchains, etc)\n"
+ "/ Filter symbol by name";
+ const char top_help[] = HIST_BROWSER_HELP_COMMON
+ "P Print histograms to perf.hist.N\n"
+ "t Zoom into current Thread\n"
+ "V Verbose (DSO names in callchains, etc)\n"
+ "/ Filter symbol by name";
+
if (browser == NULL)
return -1;
@@ -1488,25 +1517,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
case 'h':
case '?':
ui_browser__help_window(>b,
- "h/?/F1Show this window\n"
- "UP/DOWN/PGUP\n"
- "PGDN/SPACENavigate\n"
- "q/ESC/CTRL+C Exit browser\n\n"
- "For multiple event sessions:\n\n"
- "TAB/UNTAB Switch events\n\n"
- "For symbolic views (--sort has
sym):\n\n"
- "->Zoom into DSO/Threads &
Annotate current symbol\n"
- "<-Zoom out\n"
- "a Annotate current
symbol\n"
- "C Collapse all
callchains\n"
- "E Expand all callchains\n"
- "d Zoom into current DSO\n"
- "t Zoom into current
Thread\n"
- "r Run available
scripts('perf report' only)\n"
- "s Switch to another data
file in PWD ('perf report' only)\n"
- "P Print histograms to
perf.hist.N\n"
- "V Verbose (DSO names in
callchains, etc)\n"
- "/ Filter symbol by name");
+ is_report_browser(hbt) ? report_help :
top_help);
continue;
case K_ENTER:
case K_RIGHT:
--
1.8.1.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 46/49] perf ui/tui: Implement header window
From: Namhyung Kim
Implement a simple, full-screen header window which shows session header
(metadata) information. Press 'i' key to display the header window.
Signed-off-by: Namhyung Kim
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1388036284-32342-4-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Makefile.perf| 1 +
tools/perf/ui/browser.h | 2 +
tools/perf/ui/browsers/header.c | 127
tools/perf/ui/browsers/hists.c | 6 ++
4 files changed, 136 insertions(+)
create mode 100644 tools/perf/ui/browsers/header.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 97a2145e4cc6..3638b0bd20dc 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -489,6 +489,7 @@ ifndef NO_SLANG
LIB_OBJS += $(OUTPUT)ui/browsers/hists.o
LIB_OBJS += $(OUTPUT)ui/browsers/map.o
LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
+ LIB_OBJS += $(OUTPUT)ui/browsers/header.o
LIB_OBJS += $(OUTPUT)ui/tui/setup.o
LIB_OBJS += $(OUTPUT)ui/tui/util.o
LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
diff --git a/tools/perf/ui/browser.h b/tools/perf/ui/browser.h
index 7d45d2f53601..118cca29dd26 100644
--- a/tools/perf/ui/browser.h
+++ b/tools/perf/ui/browser.h
@@ -59,6 +59,8 @@ int ui_browser__help_window(struct ui_browser *browser, const
char *text);
bool ui_browser__dialog_yesno(struct ui_browser *browser, const char *text);
int ui_browser__input_window(const char *title, const char *text, char *input,
const char *exit_msg, int delay_sec);
+struct perf_session_env;
+int tui__header_window(struct perf_session_env *env);
void ui_browser__argv_seek(struct ui_browser *browser, off_t offset, int
whence);
unsigned int ui_browser__argv_refresh(struct ui_browser *browser);
diff --git a/tools/perf/ui/browsers/header.c b/tools/perf/ui/browsers/header.c
new file mode 100644
index ..89c16b988618
--- /dev/null
+++ b/tools/perf/ui/browsers/header.c
@@ -0,0 +1,127 @@
+#include "util/cache.h"
+#include "util/debug.h"
+#include "ui/browser.h"
+#include "ui/ui.h"
+#include "ui/util.h"
+#include "ui/libslang.h"
+#include "util/header.h"
+#include "util/session.h"
+
+static void ui_browser__argv_write(struct ui_browser *browser,
+ void *entry, int row)
+{
+ char **arg = entry;
+ char *str = *arg;
+ char empty[] = " ";
+ bool current_entry = ui_browser__is_current_entry(browser, row);
+ unsigned long offset = (unsigned long)browser->priv;
+
+ if (offset >= strlen(str))
+ str = empty;
+ else
+ str = str + offset;
+
+ ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
+ HE_COLORSET_NORMAL);
+
+ slsmg_write_nstring(str, browser->width);
+}
+
+static int list_menu__run(struct ui_browser *menu)
+{
+ int key;
+ unsigned long offset;
+ const char help[] =
+ "h/?/F1Show this window\n"
+ "UP/DOWN/PGUP\n"
+ "PGDN/SPACE\n"
+ "LEFT/RIGHTNavigate\n"
+ "q/ESC/CTRL+C Exit browser";
+
+ if (ui_browser__show(menu, "Header information", "Press 'q' to exit") <
0)
+ return -1;
+
+ while (1) {
+ key = ui_browser__run(menu, 0);
+
+ switch (key) {
+ case K_RIGHT:
+ offset = (unsigned long)menu->priv;
+ offset += 10;
+ menu->priv = (void *)offset;
+ continue;
+ case K_LEFT:
+ offset = (unsigned long)menu->priv;
+ if (offset >= 10)
+ offset -= 10;
+ menu->priv = (void *)offset;
+ continue;
+ case K_F1:
+ case 'h':
+ case '?':
+ ui_browser__help_window(menu, help);
+ continue;
+ case K_ESC:
+ case 'q':
+ case CTRL('c'):
+ key = -1;
+ break;
+ default:
+ continue;
+ }
+
+ break;
+ }
+
+ ui_browser__hide(menu);
+ return key;
+}
+
+static int ui__list_menu(int argc, char * const argv[])
+{
+ struct ui_browser menu = {
+ .entries= (void *)argv,
+ .refresh= ui_browser__argv_refresh,
+ .seek = ui_browser__argv_seek,
+ .write = ui_browser__argv_write,
+ .nr_entries = argc,
+ };
+
+ return list_menu__run();
+}
+
+int tui__header_window(struct perf_session_env *env)
+{
+ int i, argc = 0;
+ char **argv;
+ struct perf_session
[PATCH 35/49] perf kvm: Fix kvm report without guestmount.
From: Dongsheng Yang
Currently, if we use perf kvm --guestkallsyms --guestmodules report, we
can not get the perf information from perf data file. All sample are
shown as unknown.
Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules
record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260
samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules
report |grep %
100.00% [guest/6471] [unknown] [g] 0x8164f330
This bug was introduced by 207b57926 (perf kvm: Fix regression with guest
machine creation).
In original code, it uses perf_session__find_machine(), it means we deliver
symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But
if we use
perf_session__findnew_machine() here, if no machine was found, new machine with
pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.
And because the new machine initialized here has no kernel map created, the
symbol delivered to
it will be marked as "unknown".
This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in
another way.
Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules
/home/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437
samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules
/home/modules report |grep %
22.64%:6471 [guest.kernel.kallsyms] [g]
update_rq_clock.part.70
19.99%:6471 [guest.kernel.kallsyms] [g] d_free
18.46%:6471 [guest.kernel.kallsyms] [g] bio_phys_segments
16.25%:6471 [guest.kernel.kallsyms] [g] dequeue_task
12.78%:6471 [guest.kernel.kallsyms] [g] __switch_to
7.91%:6471 [guest.kernel.kallsyms] [g] scheduler_tick
1.75%:6471 [guest.kernel.kallsyms] [g] native_apic_mem_write
0.21%:6471 [guest.kernel.kallsyms] [g] apic_timer_interrupt
Signed-off-by: Dongsheng Yang
Acked-by: David Ahern
Cc: sta...@vger.kernel.org # 3.3+
Cc: David Ahern
Link:
http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.f...@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/session.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index cbacaab3e9c4..d3a857be9682 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -830,6 +830,7 @@ static struct machine *
struct perf_sample *sample)
{
const u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+ struct machine *machine;
if (perf_guest &&
((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -842,7 +843,11 @@ static struct machine *
else
pid = sample->pid;
- return perf_session__findnew_machine(session, pid);
+ machine = perf_session__find_machine(session, pid);
+ if (!machine)
+ machine = perf_session__findnew_machine(session,
+ DEFAULT_GUEST_KERNEL_ID);
+ return machine;
}
return >machines.host;
--
1.8.1.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 44/49] perf ui/tui: Protect windows by ui__lock
From: Namhyung Kim
Sometimes perf top TUI breaks display with concurrent help/input window
and pr_* messages since they're not protected by ui__lock.
You can check it by pressing (and not releasing) 'h' key on a "perf top
-vvv" TUI session.
Signed-off-by: Namhyung Kim
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1388036284-32342-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/tui/util.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/tools/perf/ui/tui/util.c b/tools/perf/ui/tui/util.c
index 092902e30cee..bf890f72fe80 100644
--- a/tools/perf/ui/tui/util.c
+++ b/tools/perf/ui/tui/util.c
@@ -92,6 +92,8 @@ int ui_browser__input_window(const char *title, const char
*text, char *input,
t = sep + 1;
}
+ pthread_mutex_lock(__lock);
+
max_len += 2;
nr_lines += 8;
y = SLtt_Screen_Rows / 2 - nr_lines / 2;
@@ -120,13 +122,19 @@ int ui_browser__input_window(const char *title, const
char *text, char *input,
SLsmg_write_nstring((char *)exit_msg, max_len);
SLsmg_refresh();
+ pthread_mutex_unlock(__lock);
+
x += 2;
len = 0;
key = ui__getch(delay_secs);
while (key != K_TIMER && key != K_ENTER && key != K_ESC) {
+ pthread_mutex_lock(__lock);
+
if (key == K_BKSPC) {
- if (len == 0)
+ if (len == 0) {
+ pthread_mutex_unlock(__lock);
goto next_key;
+ }
SLsmg_gotorc(y, x + --len);
SLsmg_write_char(' ');
} else {
@@ -136,6 +144,8 @@ int ui_browser__input_window(const char *title, const char
*text, char *input,
}
SLsmg_refresh();
+ pthread_mutex_unlock(__lock);
+
/* XXX more graceful overflow handling needed */
if (len == sizeof(buf) - 1) {
ui_helpline__push("maximum size of symbol name
reached!");
@@ -174,6 +184,8 @@ int ui__question_window(const char *title, const char *text,
t = sep + 1;
}
+ pthread_mutex_lock(__lock);
+
max_len += 2;
nr_lines += 4;
y = SLtt_Screen_Rows / 2 - nr_lines / 2,
@@ -195,6 +207,9 @@ int ui__question_window(const char *title, const char *text,
SLsmg_gotorc(y + nr_lines - 1, x);
SLsmg_write_nstring((char *)exit_msg, max_len);
SLsmg_refresh();
+
+ pthread_mutex_unlock(__lock);
+
return ui__getch(delay_secs);
}
@@ -215,9 +230,7 @@ static int __ui__warning(const char *title, const char
*format, va_list args)
if (vasprintf(, format, args) > 0) {
int key;
- pthread_mutex_lock(__lock);
key = ui__question_window(title, s, "Press any key...", 0);
- pthread_mutex_unlock(__lock);
free(s);
return key;
}
--
1.8.1.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 41/49] perf config: Ignore generated files in feature-checks
From: Chunwei Chen 1. Rename the test-* binary files to test-*.bin for easier pattern matching as suggested by Ingo. 2. Ignore *.bin and *.d files. Signed-off-by: Chunwei Chen Reviewed-by: Ingo Molnar Acked-by: Jiri Olsa Cc: Ingo Molnar Cc: Jiri Olsa Link: http://lkml.kernel.org/r/52b52b9b.50...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/config/Makefile | 6 +- tools/perf/config/feature-checks/.gitignore | 2 + tools/perf/config/feature-checks/Makefile | 110 ++-- 3 files changed, 60 insertions(+), 58 deletions(-) create mode 100644 tools/perf/config/feature-checks/.gitignore diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 5a1f4df3c3a8..14faeeb0d752 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -126,7 +126,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1.bin >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -173,7 +173,7 @@ CORE_FEATURE_TESTS =\ # to skip the print-out of the long features list if the file # existed before and after it was built: # -ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),) +ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all.bin),) test-all-failed := 1 else test-all-failed := 0 @@ -203,7 +203,7 @@ ifeq ($(feature-all), 1) # $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat))) else - $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) + $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(addsuffix .bin,$(CORE_FEATURE_TESTS)) >/dev/null 2>&1) $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat))) endif diff --git a/tools/perf/config/feature-checks/.gitignore b/tools/perf/config/feature-checks/.gitignore new file mode 100644 index ..80f3da0c3515 --- /dev/null +++ b/tools/perf/config/feature-checks/.gitignore @@ -0,0 +1,2 @@ +*.d +*.bin diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index bc86462e80a2..7cf6fcdacebe 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -1,90 +1,90 @@ FILES= \ - test-all\ - test-backtrace \ - test-bionic \ - test-dwarf \ - test-fortify-source \ - test-glibc \ - test-gtk2 \ - test-gtk2-infobar \ - test-hello \ - test-libaudit \ - test-libbfd \ - test-liberty\ - test-liberty-z \ - test-cplus-demangle \ - test-libelf \ - test-libelf-getphdrnum \ - test-libelf-mmap\ - test-libnuma\ - test-libperl\ - test-libpython \ - test-libpython-version \ - test-libslang \ - test-libunwind \ - test-libunwind-debug-frame \ - test-on-exit\ - test-stackprotector-all \ - test-timerfd + test-all.bin\ + test-backtrace.bin \ + test-bionic.bin \ + test-dwarf.bin \ + test-fortify-source.bin \ + test-glibc.bin \ + test-gtk2.bin \ + test-gtk2-infobar.bin \ + test-hello.bin \ + test-libaudit.bin \ + test-libbfd.bin \ + test-liberty.bin\ + test-liberty-z.bin \ + test-cplus-demangle.bin \ + test-libelf.bin \ + test-libelf-getphdrnum.bin \ + test-libelf-mmap.bin\ + test-libnuma.bin\ + test-libperl.bin\ + test-libpython.bin \ + test-libpython-version.bin \ + test-libslang.bin \ +
[PATCH 39/49] perf tools: Use machine->pid for tgid if machine is guest.
From: Dongsheng Yang When we synthesize an comm event, if machine is guest, we should use the pid of machine as the event->comm.pid, rather than tgid of thread. Signed-off-by: Dongsheng Yang Cc: David Ahern Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/22455abe107c618a361e7b667ad0f098f7c9b4a3.1387572416.git.yangds.f...@cn.fujitsu.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/event.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 07c07833de53..2905771a1f49 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -106,8 +106,12 @@ static pid_t perf_event__synthesize_comm(struct perf_tool *tool, memset(>comm, 0, sizeof(event->comm)); - tgid = perf_event__get_comm_tgid(pid, event->comm.comm, -sizeof(event->comm.comm)); + if (machine__is_host(machine)) + tgid = perf_event__get_comm_tgid(pid, event->comm.comm, +sizeof(event->comm.comm)); + else + tgid = machine->pid; + if (tgid < 0) goto out; -- 1.8.1.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 36/49] perf tools: Add support for PERF_RECORD_MISC_GUEST_USER in thread__find_addr_map().
From: Dongsheng Yang
This patch remove a TODO in thread__find_addr_map() and add support of
PERF_RECORD_MISC_GUEST_USER.
Signed-off-by: Dongsheng Yang
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/3dd652201171a19c910b500984c7c3590e77603b.1387572416.git.yangds.f...@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/event.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index fe2022799161..484e99464a00 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -659,15 +659,10 @@ void thread__find_addr_map(struct thread *thread,
al->level = 'g';
mg = >kmaps;
load_map = true;
+ } else if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest) {
+ al->level = 'u';
} else {
- /*
-* 'u' means guest os user space.
-* TODO: We don't support guest user space. Might support late.
-*/
- if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest)
- al->level = 'u';
- else
- al->level = 'H';
+ al->level = 'H';
al->map = NULL;
if ((cpumode == PERF_RECORD_MISC_GUEST_USER ||
--
1.8.1.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 48/49] perf tools: Introduce zfree
From: Arnaldo Carvalho de Melo
For the frequent idiom of:
free(ptr);
ptr = NULL;
Make it expect a pointer to the pointer being freed, so that it becomes
clear at first sight that the variable being freed is being modified.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-pfw02ezuab37kha18wlut...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/common.c | 3 +--
tools/perf/builtin-annotate.c | 3 +--
tools/perf/builtin-stat.c | 6 ++
tools/perf/builtin-timechart.c | 3 +--
tools/perf/builtin-trace.c | 12
tools/perf/ui/browser.c| 6 ++
tools/perf/ui/browsers/hists.c | 6 ++
tools/perf/ui/gtk/util.c | 3 +--
tools/perf/util/alias.c| 6 ++
tools/perf/util/annotate.c | 12
tools/perf/util/dso.c | 9 +++--
tools/perf/util/evlist.c | 9 +++--
tools/perf/util/evsel.c| 6 ++
tools/perf/util/header.c | 3 +--
tools/perf/util/help.c | 3 +--
tools/perf/util/machine.c | 12 +---
tools/perf/util/probe-event.c | 6 ++
tools/perf/util/probe-finder.c | 24
tools/perf/util/symbol.c | 9 +++--
tools/perf/util/thread_map.c | 10 --
tools/perf/util/trace-event-info.c | 6 ++
tools/perf/util/util.h | 2 ++
22 files changed, 56 insertions(+), 103 deletions(-)
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index aacef07ebf31..42faf369211c 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -154,8 +154,7 @@ static int perf_session_env__lookup_binutils_path(struct
perf_session_env *env,
}
if (lookup_path(buf))
goto out;
- free(buf);
- buf = NULL;
+ zfree();
}
if (!strcmp(arch, "arm"))
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 4136f9970fd5..ab65057a0317 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -180,8 +180,7 @@ find_next:
* symbol, free he->ms.sym->src to signal we already
* processed this symbol.
*/
- free(notes->src);
- notes->src = NULL;
+ zfree(>src);
}
}
}
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index dab98b50c9fe..106a5e5b7842 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -185,8 +185,7 @@ static int perf_evsel__alloc_stat_priv(struct perf_evsel
*evsel)
static void perf_evsel__free_stat_priv(struct perf_evsel *evsel)
{
- free(evsel->priv);
- evsel->priv = NULL;
+ zfree(>priv);
}
static int perf_evsel__alloc_prev_raw_counts(struct perf_evsel *evsel)
@@ -208,8 +207,7 @@ static int perf_evsel__alloc_prev_raw_counts(struct
perf_evsel *evsel)
static void perf_evsel__free_prev_raw_counts(struct perf_evsel *evsel)
{
- free(evsel->prev_raw_counts);
- evsel->prev_raw_counts = NULL;
+ zfree(>prev_raw_counts);
}
static void perf_evlist__free_stats(struct perf_evlist *evlist)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 20d4212fa337..652af0b66a62 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -488,8 +488,7 @@ static const char *cat_backtrace(union perf_event *event,
* It seems the callchain is corrupted.
* Discard all.
*/
- free(p);
- p = NULL;
+ zfree();
goto exit;
}
continue;
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index f64b5b0aa8b1..c5b4bc51175c 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -146,8 +146,7 @@ static int perf_evsel__init_tp_ptr_field(struct perf_evsel
*evsel,
static void perf_evsel__delete_priv(struct perf_evsel *evsel)
{
- free(evsel->priv);
- evsel->priv = NULL;
+ zfree(>priv);
perf_evsel__delete(evsel);
}
@@ -165,8 +164,7 @@ static int perf_evsel__init_syscall_tp(struct perf_evsel
*evsel, void *handler)
return -ENOMEM;
out_delete:
- free(evsel->priv);
- evsel->priv = NULL;
+ zfree(>priv);
return -ENOENT;
}
@@ -1278,10 +1276,8 @@ static size_t syscall_arg__scnprintf_close_fd(char *bf,
size_t size,
size_t printed =
[PATCH 42/49] perf probe: Expand given path to absolute path
From: Masami Hiramatsu
Expand given path to absolute path in the option parser, except for a
module name.
Since realpath at later stage in processing several probe point, can be
called several times (even if currently doesn't, it can happen when we
expands the feature), it is waste of the performance.
Processing it once at the early stage can avoid that.
Changes from previous one:
- Fix not to print null string.
- Allocate memory for given path/module name everytime.
Signed-off-by: Masami Hiramatsu
Cc: "David A. Long"
Cc: "Steven Rostedt (Red Hat)"
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Cc: system...@sourceware.org
Cc: yrl.pp-manager...@hitachi.com
Link:
http://lkml.kernel.org/r/20131226054150.22364.12187.stgit@kbuild-fedora.novalocal
[ Clarified the pr_warning message as per David Ahern's suggestion ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-probe.c| 15 ++-
tools/perf/util/probe-event.c | 11 ++-
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index c98ccb570509..1792a3f1f4ce 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -169,6 +169,7 @@ static int opt_set_target(const struct option *opt, const
char *str,
int unset __maybe_unused)
{
int ret = -ENOENT;
+ char *tmp;
if (str && !params.target) {
if (!strcmp(opt->long_name, "exec"))
@@ -180,7 +181,19 @@ static int opt_set_target(const struct option *opt, const
char *str,
else
return ret;
- params.target = str;
+ /* Expand given path to absolute path, except for modulename */
+ if (params.uprobes || strchr(str, '/')) {
+ tmp = realpath(str, NULL);
+ if (!tmp) {
+ pr_warning("Failed to get the absolute path of
%s: %m\n", str);
+ return ret;
+ }
+ } else {
+ tmp = strdup(str);
+ if (!tmp)
+ return -ENOMEM;
+ }
+ params.target = tmp;
ret = 0;
}
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 544ac1898a9f..68013b91377c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2281,7 +2281,7 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
struct perf_probe_point *pp = >point;
struct symbol *sym;
struct map *map = NULL;
- char *function = NULL, *name = NULL;
+ char *function = NULL;
int ret = -EINVAL;
unsigned long long vaddr = 0;
@@ -2297,12 +2297,7 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
goto out;
}
- name = realpath(exec, NULL);
- if (!name) {
- pr_warning("Cannot find realpath for %s.\n", exec);
- goto out;
- }
- map = dso__new_map(name);
+ map = dso__new_map(exec);
if (!map) {
pr_warning("Cannot find appropriate DSO for %s.\n", exec);
goto out;
@@ -2367,7 +2362,5 @@ out:
}
if (function)
free(function);
- if (name)
- free(name);
return ret;
}
--
1.8.1.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 43/49] perf probe: Support basic dwarf-based operations on uprobe events
From: Masami Hiramatsu
Support basic dwarf(debuginfo) based operations for uprobe events. With
this change, perf probe can analyze debuginfo of user application binary
to set up new uprobe event.
This allows perf-probe --add(with local variables, line numbers) and
--line works with -x option. (Actually, --vars has already accepted -x
option)
For example, the following command shows the probe-able lines of a given
user space function. Something that so far was only available in the
'perf probe' tool for kernel space functions:
# ./perf probe -x perf --line map__load
0 int map__load(struct map *map, symbol_filter_t filter)
1 {
2 const char *name = map->dso->long_name;
int nr;
5 if (dso__loaded(map->dso, map->type))
6 return 0;
8 nr = dso__load(map->dso, map, filter);
9 if (nr < 0) {
10 if (map->dso->has_build_id) {
And this shows the available variables at the given line of the
function.
# ./perf probe -x perf --vars map__load:8
Available variables at map__load:8
@
char* name
struct map* map
symbol_filter_t filter
@
char* name
symbol_filter_t filter
@
char* name
symbol_filter_t filter
@
char* name
struct map* map
symbol_filter_t filter
And lastly, we can now define probe(s) with all available
variables on the given line:
# ./perf probe -x perf --add 'map__load:8 $vars'
Added new events:
probe_perf:map__load (on map__load:8 with $vars)
probe_perf:map__load_1 (on map__load:8 with $vars)
probe_perf:map__load_2 (on map__load:8 with $vars)
probe_perf:map__load_3 (on map__load:8 with $vars)
You can now use it in all perf tools, such as:
perf record -e probe_perf:map__load_3 -aR sleep 1
Changes from previous version:
- Add examples in the patch description.
- Use .text section start address and dwarf symbol address
for calculating the offset of given symbol, instead of
searching the symbol in symtab again.
With this change, we can safely handle multiple local
function instances (e.g. scnprintf in perf).
Signed-off-by: Masami Hiramatsu
Cc: David Ahern
Cc: David A. Long
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Cc: Steven Rostedt
Cc: system...@sourceware.org
Cc: yrl.pp-manager...@hitachi.com
Link:
http://lkml.kernel.org/r/20131226054152.22364.47021.stgit@kbuild-fedora.novalocal
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-probe.c | 2 +-
tools/perf/util/probe-event.c | 151 -
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-finder.c | 1 +
4 files changed, 138 insertions(+), 17 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 1792a3f1f4ce..43ff33d0007b 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -424,7 +424,7 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
}
#ifdef HAVE_DWARF_SUPPORT
- if (params.show_lines && !params.uprobes) {
+ if (params.show_lines) {
if (params.mod_events) {
pr_err(" Error: Don't use --line with"
" --add/--del.\n");
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 68013b91377c..72b56aef105e 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -172,6 +172,52 @@ const char *kernel_get_module_path(const char *module)
return (dso) ? dso->long_name : NULL;
}
+/* Copied from unwind.c */
+static Elf_Scn *elf_section_by_name(Elf *elf, GElf_Ehdr *ep,
+ GElf_Shdr *shp, const char *name)
+{
+ Elf_Scn *sec = NULL;
+
+ while ((sec = elf_nextscn(elf, sec)) != NULL) {
+ char *str;
+
+ gelf_getshdr(sec, shp);
+ str = elf_strptr(elf, ep->e_shstrndx, shp->sh_name);
+ if (!strcmp(name, str))
+ break;
+ }
+
+ return sec;
+}
+
+static int get_text_start_address(const char *exec, unsigned long *address)
+{
+ Elf *elf;
+ GElf_Ehdr ehdr;
+ GElf_Shdr shdr;
+ int fd, ret = -ENOENT;
+
+ fd = open(exec, O_RDONLY);
+ if (fd < 0)
+ return -errno;
+
+ elf = elf_begin(fd, PERF_ELF_C_READ_MMAP, NULL);
+ if (elf == NULL)
+ return -EINVAL;
+
+ if (gelf_getehdr(elf, ) == NULL)
+ goto out;
+
+ if (!elf_section_by_name(elf, , , ".text"))
+ goto out;
+
+ *address = shdr.sh_addr - shdr.sh_offset;
+ ret = 0;
+out:
+
[PATCH 47/49] perf tools: No need to test against NULL before calling free()
From: Arnaldo Carvalho de Melo
Its perfectly fine to call free(NULL), so no need to clutter the source
code with all those superfluous testing.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-uux5wpvevlerd42gqer13...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kvm.c | 4 +-
tools/perf/ui/browsers/scripts.c | 3 +-
tools/perf/util/header.c | 6 +--
tools/perf/util/probe-event.c | 62 --
tools/perf/util/probe-finder.c | 12 ++---
.../perf/util/scripting-engines/trace-event-perl.c | 3 +-
.../util/scripting-engines/trace-event-python.c| 3 +-
7 files changed, 31 insertions(+), 62 deletions(-)
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 5a80da6ba413..a6ec1052c291 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1158,9 +1158,7 @@ out:
if (kvm->timerfd >= 0)
close(kvm->timerfd);
- if (pollfds)
- free(pollfds);
-
+ free(pollfds);
return err;
}
diff --git a/tools/perf/ui/browsers/scripts.c b/tools/perf/ui/browsers/scripts.c
index d63c68ea02a8..402d2bd30b09 100644
--- a/tools/perf/ui/browsers/scripts.c
+++ b/tools/perf/ui/browsers/scripts.c
@@ -173,8 +173,7 @@ int script_browse(const char *script_opt)
if (script.b.width > AVERAGE_LINE_LEN)
script.b.width = AVERAGE_LINE_LEN;
- if (line)
- free(line);
+ free(line);
pclose(fp);
script.nr_lines = nr_entries;
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 61c54213704b..10730b0af804 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1232,10 +1232,8 @@ static void free_event_desc(struct perf_evsel *events)
return;
for (evsel = events; evsel->attr.size; evsel++) {
- if (evsel->name)
- free(evsel->name);
- if (evsel->id)
- free(evsel->id);
+ free(evsel->name);
+ free(evsel->id);
}
free(events);
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 72b56aef105e..095a98ec7444 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -401,9 +401,7 @@ static int add_module_to_probe_trace_events(struct
probe_trace_event *tevs,
}
}
- if (tmp)
- free(tmp);
-
+ free(tmp);
return ret;
}
@@ -1382,8 +1380,7 @@ static char *synthesize_perf_probe_point(struct
perf_probe_point *pp)
error:
pr_debug("Failed to synthesize perf probe point: %s\n",
strerror(-ret));
- if (buf)
- free(buf);
+ free(buf);
return NULL;
}
@@ -1584,34 +1581,25 @@ void clear_perf_probe_event(struct perf_probe_event
*pev)
struct perf_probe_arg_field *field, *next;
int i;
- if (pev->event)
- free(pev->event);
- if (pev->group)
- free(pev->group);
- if (pp->file)
- free(pp->file);
- if (pp->function)
- free(pp->function);
- if (pp->lazy_line)
- free(pp->lazy_line);
+ free(pev->event);
+ free(pev->group);
+ free(pp->file);
+ free(pp->function);
+ free(pp->lazy_line);
+
for (i = 0; i < pev->nargs; i++) {
- if (pev->args[i].name)
- free(pev->args[i].name);
- if (pev->args[i].var)
- free(pev->args[i].var);
- if (pev->args[i].type)
- free(pev->args[i].type);
+ free(pev->args[i].name);
+ free(pev->args[i].var);
+ free(pev->args[i].type);
field = pev->args[i].field;
while (field) {
next = field->next;
- if (field->name)
- free(field->name);
+ free(field->name);
free(field);
field = next;
}
}
- if (pev->args)
- free(pev->args);
+ free(pev->args);
memset(pev, 0, sizeof(*pev));
}
@@ -1620,21 +1608,14 @@ static void clear_probe_trace_event(struct
probe_trace_event *tev)
struct probe_trace_arg_ref *ref, *next;
int i;
- if (tev->event)
- free(tev->event);
- if (tev->group)
- free(tev->group);
- if (tev->point.symbol)
- free(tev->point.symbol);
- if (tev->point.module)
- free(tev->point.module);
+ free(tev->event);
[PATCH 49/49] perf tools: Use zfree to help detect use after free bugs
From: Arnaldo Carvalho de Melo
Several areas already used this technique, so do some audit to
consistently use it elsewhere.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-9sbere0kkplwe45ak6rk4...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-diff.c | 2 +-
tools/perf/builtin-sched.c | 2 +-
tools/perf/builtin-script.c| 6 +++---
tools/perf/ui/browsers/hists.c | 2 +-
tools/perf/ui/stdio/hist.c | 2 +-
tools/perf/util/annotate.c | 20 ++--
tools/perf/util/cgroup.c | 2 +-
tools/perf/util/comm.c | 2 +-
tools/perf/util/evsel.c| 8
tools/perf/util/header.c | 10 +-
tools/perf/util/help.c | 4 ++--
tools/perf/util/hist.c | 6 +++---
tools/perf/util/parse-events.c | 8
tools/perf/util/pmu.c | 2 +-
tools/perf/util/probe-event.c | 8
tools/perf/util/probe-finder.c | 2 +-
tools/perf/util/session.c | 24
tools/perf/util/srcline.c | 6 +++---
tools/perf/util/strbuf.c | 2 +-
tools/perf/util/strfilter.c| 2 +-
tools/perf/util/string.c | 2 +-
tools/perf/util/strlist.c | 3 ++-
tools/perf/util/svghelper.c| 5 +++--
tools/perf/util/symbol-elf.c | 2 +-
tools/perf/util/symbol-minimal.c | 3 ++-
tools/perf/util/symbol.c | 2 +-
tools/perf/util/thread_map.c | 10 +-
tools/perf/util/trace-event-info.c | 4 ++--
tools/perf/util/values.c | 14 +++---
29 files changed, 84 insertions(+), 81 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 2a85cc9a2d09..e6a0844bc2f0 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -654,7 +654,7 @@ static void data__free(struct data__file *d)
for (col = 0; col < PERF_HPP_DIFF__MAX_INDEX; col++) {
struct diff_hpp_fmt *fmt = >fmt[col];
- free(fmt->header);
+ zfree(>header);
}
}
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0f3c65518a2c..6a76a07b6789 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -469,7 +469,7 @@ static void *thread_func(void *ctx)
char comm2[22];
int fd;
- free(parms);
+ zfree();
sprintf(comm2, ":%s", this_task->comm);
prctl(PR_SET_NAME, comm2);
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 62ef190c4320..604bdfa6 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1102,9 +1102,9 @@ static struct script_desc *script_desc__new(const char
*name)
static void script_desc__delete(struct script_desc *s)
{
- free(s->name);
- free(s->half_liner);
- free(s->args);
+ zfree(>name);
+ zfree(>half_liner);
+ zfree(>args);
free(s);
}
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 022d1731b801..a7045ea6d1d5 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1327,7 +1327,7 @@ static int switch_data_file(void)
abs_path[nr_options] = strdup(path);
if (!abs_path[nr_options]) {
- free(options[nr_options]);
+ zfree([nr_options]);
ui__warning("Can't search all data files due to
memory shortage.\n");
fclose(file);
break;
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index c244cb524ef2..831fbb77d1ff 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -510,7 +510,7 @@ print_entries:
free(line);
out:
- free(rem_sq_bracket);
+ zfree(_sq_bracket);
return ret;
}
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index a78721d14694..469eb679fb9d 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -26,10 +26,10 @@ static int disasm_line__parse(char *line, char **namep,
char **rawp);
static void ins__delete(struct ins_operands *ops)
{
- free(ops->source.raw);
- free(ops->source.name);
- free(ops->target.raw);
- free(ops->target.name);
+ zfree(>source.raw);
+ zfree(>source.name);
+ zfree(>target.raw);
+ zfree(>target.name);
}
static int ins__raw_scnprintf(struct ins *ins, char *bf, size_t size,
@@ -204,9 +204,9 @@ static int lock__scnprintf(struct ins *ins, char *bf,
size_t size,
static void lock__delete(struct ins_operands *ops)
{
- free(ops->locked.ops);
-
[PATCH 38/49] perf tools: Set event->header.misc to PERF_RECORD_MISC_GUEST_USER if machine is guest.
From: Dongsheng Yang
When we synthesize the mmap events of user space, if machine is guest,
we should set the event->header.misc to PERF_RECORD_MISC_GUEST_USER,
rather than PERF_RECORD_MISC_USER.
Signed-off-by: Dongsheng Yang
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/e6f8ff6505d2db8a4b21bff8e448bb9be0bcff35.1387572416.git.yangds.f...@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/event.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index a61726ea01a9..07c07833de53 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -220,7 +220,10 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
/*
* Just like the kernel, see __perf_event_mmap in
kernel/perf_event.c
*/
- event->header.misc = PERF_RECORD_MISC_USER;
+ if (machine__is_host(machine))
+ event->header.misc = PERF_RECORD_MISC_USER;
+ else
+ event->header.misc = PERF_RECORD_MISC_GUEST_USER;
if (prot[2] != 'x') {
if (!mmap_data || prot[0] != 'r')
--
1.8.1.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/
