[59/74] unix: fix a race condition in unix_release()
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Paul Moore
[ Upstream commit ded34e0fe8fe8c2d595bfa30626654e4b87621e0 ]
As reported by Jan, and others over the past few years, there is a
race condition caused by unix_release setting the sock->sk pointer
to NULL before properly marking the socket as dead/orphaned. This
can cause a problem with the LSM hook security_unix_may_send() if
there is another socket attempting to write to this partially
released socket in between when sock->sk is set to NULL and it is
marked as dead/orphaned. This patch fixes this by only setting
sock->sk to NULL after the socket has been marked as dead; I also
take the opportunity to make unix_release_sock() a void function
as it only ever returned 0/success.
Dave, I think this one should go on the -stable pile.
Special thanks to Jan for coming up with a reproducer for this
problem.
Reported-by: Jan Stancek
Signed-off-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/unix/af_unix.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 317bfe3..18978b6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -371,7 +371,7 @@ static void unix_sock_destructor(struct sock *sk)
#endif
}
-static int unix_release_sock(struct sock *sk, int embrion)
+static void unix_release_sock(struct sock *sk, int embrion)
{
struct unix_sock *u = unix_sk(sk);
struct dentry *dentry;
@@ -444,8 +444,6 @@ static int unix_release_sock(struct sock *sk, int embrion)
if (unix_tot_inflight)
unix_gc(); /* Garbage collect fds */
-
- return 0;
}
static void init_peercred(struct sock *sk)
@@ -682,9 +680,10 @@ static int unix_release(struct socket *sock)
if (!sk)
return 0;
+ unix_release_sock(sk, 0);
sock->sk = NULL;
- return unix_release_sock(sk, 0);
+ return 0;
}
static int unix_autobind(struct socket *sock)
--
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/
[62/74] drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Mugunthan V N commit 7e51cde276ca820d526c6c21cf8147df595a36bf upstream. To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke Suggested-by: Sriramakrishnan A G Signed-off-by: Mugunthan V N Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/ti/davinci_emac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 22f2788..fd8115e 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1048,7 +1048,7 @@ static void emac_tx_handler(void *token, int len, int status) struct net_device *ndev = skb->dev; if (unlikely(netif_queue_stopped(ndev))) - netif_start_queue(ndev); + netif_wake_queue(ndev); ndev->stats.tx_packets++; ndev->stats.tx_bytes += len; dev_kfree_skb_any(skb); -- 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/
[46/74] ixgbe: fix registration order of driver and DCA nofitication
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jakub Kicinski
commit f01fc1a82c2ee68726b400fadb156bd623b5f2f1 upstream.
ixgbe_notify_dca cannot be called before driver registration
because it expects driver's klist_devices to be allocated and
initialized. While on it make sure debugfs files are removed
when registration fails.
Signed-off-by: Jakub Kicinski
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller
[bwh: Backported to 3.2: no debugfs support]
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8003,12 +8003,15 @@ static int __init ixgbe_init_module(void
pr_info("%s - version %s\n", ixgbe_driver_string, ixgbe_driver_version);
pr_info("%s\n", ixgbe_copyright);
+ ret = pci_register_driver(_driver);
+ if (ret)
+ return ret;
+
#ifdef CONFIG_IXGBE_DCA
dca_register_notify(_notifier);
#endif
- ret = pci_register_driver(_driver);
- return ret;
+ return 0;
}
module_init(ixgbe_init_module);
--
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/
[08/74] Bluetooth device 04ca:3008 should use ath3k
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sergio Cambra
commit f4d6f7dce71a5da93da50272ff1670bf2f1146b1 upstream.
Output of /sys/kernel/debug/usb/devices
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3008 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Sergio Cambra
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -77,6 +77,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
{ USB_DEVICE(0x04CA, 0x3006) },
+ { USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
@@ -108,6 +109,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -144,6 +144,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--
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/
[11/74] Bluetooth: Add support for Dell[QCA 0cf3:0036]
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ming Lei
commit d66629c1325399cf080ba8b2fb086c10e5439cdd upstream.
Add support for the AR9462 chip
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=0036 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Cc: Gustavo Padovan
Signed-off-by: Ming Lei
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -72,6 +72,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x03F0, 0x311D) },
/* Atheros AR3012 with sflash firmware*/
+ { USB_DEVICE(0x0CF3, 0x0036) },
{ USB_DEVICE(0x0CF3, 0x3004) },
{ USB_DEVICE(0x0CF3, 0x3008) },
{ USB_DEVICE(0x0CF3, 0x311D) },
@@ -106,6 +107,7 @@ MODULE_DEVICE_TABLE(usb, ath3k_table);
static struct usb_device_id ath3k_blist_tbl[] = {
/* Atheros AR3012 with sflash firmware*/
+ { USB_DEVICE(0x0CF3, 0x0036), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -139,6 +139,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
/* Atheros 3012 with sflash firmware */
+ { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
--
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/
[36/74] tg3: fix length overflow in VPD firmware parsing
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 715230a44310a8cf66fbfb5a46f9a62a9b2de424 upstream.
Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
when present") introduced VPD parsing that contained a potential length
overflow.
Limit the hardware's reported firmware string length (max 255 bytes) to
stay inside the driver's firmware string length (32 bytes). On overflow,
truncate the formatted firmware string instead of potentially overwriting
portions of the tg3 struct.
http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf
Signed-off-by: Kees Cook
Reported-by: Oded Horovitz
Reported-by: Brad Spengler
Cc: Matt Carlson
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/broadcom/tg3.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -13433,8 +13433,11 @@ static void __devinit tg3_read_vpd(struc
if (j + len > block_end)
goto partno;
- memcpy(tp->fw_ver, _data[j], len);
- strncat(tp->fw_ver, " bc ", vpdlen - len - 1);
+ if (len >= sizeof(tp->fw_ver))
+ len = sizeof(tp->fw_ver) - 1;
+ memset(tp->fw_ver, 0, sizeof(tp->fw_ver));
+ snprintf(tp->fw_ver, sizeof(tp->fw_ver), "%.*s bc ", len,
+_data[j]);
}
partno:
--
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/
[44/74] EISA/PCI: Init EISA early, before PNP
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Yinghai Lu
commit c5fb301ae83bec6892e54984e6ec765c47df8e10 upstream.
Matthew reported kernels fail the pci_eisa probe and are later successful
with the virtual_eisa_root_init force probe without slot0.
The reason for that is: PNP probing is before pci_eisa_init gets called
as pci_eisa_init is called via pci_driver.
pnp 00:0f has 0xc80 - 0xc84 reserved.
[9.700409] pnp 00:0f: [io 0x0c80-0x0c84]
so eisa_probe will fail from pci_eisa_init
==>eisa_root_register
==>eisa_probe path.
as force_probe is not set in pci_eisa_root, it will bail early when
slot0 is not probed and initialized.
Try to use subsys_initcall_sync instead, and will keep following sequence:
pci_subsys_init
pci_eisa_init_early
pnpacpi_init/isapnp_init
After this patch EISA can be initialized properly, and PNP overlapping
resource will not be reserved.
[ 10.104434] system 00:0f: [io 0x0c80-0x0c84] could not be reserved
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Ben Hutchings
---
drivers/eisa/pci_eisa.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
--- a/drivers/eisa/pci_eisa.c
+++ b/drivers/eisa/pci_eisa.c
@@ -19,8 +19,7 @@
/* There is only *one* pci_eisa device per machine, right ? */
static struct eisa_root_device pci_eisa_root;
-static int __init pci_eisa_init(struct pci_dev *pdev,
- const struct pci_device_id *ent)
+static int __init pci_eisa_init(struct pci_dev *pdev)
{
int rc;
@@ -45,22 +44,26 @@ static int __init pci_eisa_init(struct p
return 0;
}
-static struct pci_device_id pci_eisa_pci_tbl[] = {
- { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_EISA << 8, 0x00, 0 },
- { 0, }
-};
-
-static struct pci_driver __refdata pci_eisa_driver = {
- .name = "pci_eisa",
- .id_table = pci_eisa_pci_tbl,
- .probe = pci_eisa_init,
-};
-
-static int __init pci_eisa_init_module (void)
+/*
+ * We have to call pci_eisa_init_early() before pnpacpi_init()/isapnp_init().
+ * Otherwise pnp resource will get enabled early and could prevent eisa
+ * to be initialized.
+ * Also need to make sure pci_eisa_init_early() is called after
+ * x86/pci_subsys_init().
+ * So need to use subsys_initcall_sync with it.
+ */
+static int __init pci_eisa_init_early(void)
{
- return pci_register_driver (_eisa_driver);
-}
+ struct pci_dev *dev = NULL;
+ int ret;
+
+ for_each_pci_dev(dev)
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_EISA) {
+ ret = pci_eisa_init(dev);
+ if (ret)
+ return ret;
+ }
-device_initcall(pci_eisa_init_module);
-MODULE_DEVICE_TABLE(pci, pci_eisa_pci_tbl);
+ return 0;
+}
+subsys_initcall_sync(pci_eisa_init_early);
--
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/
[43/74] spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anatolij Gustschin
commit 1ad849aee5f53353ed88d9cd3d68a51b03a7d44f upstream.
Some SPI slave devices require asserted chip select signal across
multiple transfer segments of an SPI message. Currently the driver
always de-asserts the internal SS signal for every single transfer
segment of the message and ignores the 'cs_change' flag of the
transfer description. Disable the internal chip select (SS) only
if this is needed and indicated by the 'cs_change' flag.
Without this change, each partial transfer of a surrounding
multi-part SPI transaction might erroneously change the SS
signal, which might prevent slaves from answering the request
that was sent in a previous transfer segment because the
transaction could be considered aborted (SS was de-asserted
before reading the response).
Reported-by: Gerhard Sittig
Signed-off-by: Anatolij Gustschin
Signed-off-by: Mark Brown
Signed-off-by: Ben Hutchings
---
drivers/spi/spi-mpc512x-psc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -164,7 +164,7 @@ static int mpc512x_psc_spi_transfer_rxtx
for (i = count; i > 0; i--) {
data = tx_buf ? *tx_buf++ : 0;
- if (len == EOFBYTE)
+ if (len == EOFBYTE && t->cs_change)
setbits32(>txcmd, MPC512x_PSC_FIFO_EOF);
out_8(>txdata_8, data);
len--;
--
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/
[45/74] mm: prevent mmap_cache race in find_vma()
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jan Stancek
commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c upstream.
find_vma() can be called by multiple threads with read lock
held on mm->mmap_sem and any of them can update mm->mmap_cache.
Prevent compiler from re-fetching mm->mmap_cache, because other
readers could update it in the meantime:
thread 1 thread 2
|
find_vma()| find_vma()
struct vm_area_struct *vma = NULL; |
vma = mm->mmap_cache; |
if (!(vma && vma->vm_end > addr |
&& vma->vm_start <= addr)) {|
|mm->mmap_cache = vma;
return vma; |
^^ compiler may optimize this |
local variable out and re-read |
mm->mmap_cache |
This issue can be reproduced with gcc-4.8.0-1 on s390x by running
mallocstress testcase from LTP, which triggers:
kernel BUG at mm/rmap.c:1088!
Call Trace:
([<03d100c57000>] 0x3d100c57000)
[<0023a1c0>] do_wp_page+0x2fc/0xa88
[<0023baae>] handle_pte_fault+0x41a/0xac8
[<0023d832>] handle_mm_fault+0x17a/0x268
[<0060507a>] do_protection_exception+0x1e2/0x394
[<00603a04>] pgm_check_handler+0x138/0x13c
[<03fffcf1f07a>] 0x3fffcf1f07a
Last Breaking-Event-Address:
[<0024755e>] page_add_new_anon_rmap+0xc2/0x168
Thanks to Jakub Jelinek for his insight on gcc and helping to
track this down.
Signed-off-by: Jan Stancek
Acked-by: David Rientjes
Signed-off-by: Hugh Dickins
Signed-off-by: Linus Torvalds
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings
---
mm/mmap.c |2 +-
mm/nommu.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1573,7 +1573,7 @@ struct vm_area_struct *find_vma(struct m
if (mm) {
/* Check the cache first. */
/* (Cache hit rate is typically around 35%.) */
- vma = mm->mmap_cache;
+ vma = ACCESS_ONCE(mm->mmap_cache);
if (!(vma && vma->vm_end > addr && vma->vm_start <= addr)) {
struct rb_node * rb_node;
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -807,7 +807,7 @@ struct vm_area_struct *find_vma(struct m
struct vm_area_struct *vma;
/* check the cache first */
- vma = mm->mmap_cache;
+ vma = ACCESS_ONCE(mm->mmap_cache);
if (vma && vma->vm_start <= addr && vma->vm_end > addr)
return vma;
--
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/
[49/74] udf: Fix bitmap overflow on large filesystems with small block size
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit 89b1f39eb4189de745fae554b0d614d87c8d5c63 upstream.
For large UDF filesystems with 512-byte blocks the number of necessary
bitmap blocks is larger than 2^16 so s_nr_groups in udf_bitmap overflows
(the number will overflow for filesystems larger than 128 GB with
512-byte blocks). That results in ENOSPC errors despite the filesystem
has plenty of free space.
Fix the problem by changing s_nr_groups' type to 'int'. That is enough
even for filesystems 2^32 blocks (UDF maximum) and 512-byte blocksize.
Reported-and-tested-by: v10la...@myway.de
Signed-off-by: Jan Kara
Signed-off-by: Ben Hutchings
---
fs/udf/udf_sb.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 5f02722..8d1c9d4 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -82,7 +82,7 @@ struct udf_virtual_data {
struct udf_bitmap {
__u32 s_extLength;
__u32 s_extPosition;
- __u16 s_nr_groups;
+ int s_nr_groups;
struct buffer_head **s_block_bitmap;
};
--
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/
[09/74] Bluetooth: Add support for atheros 04ca:3004 device to ath3k
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Boyer
commit 3f63c340a72f2872a9362245cb2e03f3d2bb73a6 upstream.
Yet another version of the atheros bluetooth chipset
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3004 Rev=00.01
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
This resolves https://bugzilla.redhat.com/show_bug.cgi?id=844750
Reported-by: ni...@mail.ru
Signed-off-by: Josh Boyer
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -75,6 +75,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0CF3, 0x3004) },
{ USB_DEVICE(0x0CF3, 0x311D) },
{ USB_DEVICE(0x13d3, 0x3375) },
+ { USB_DEVICE(0x04CA, 0x3004) },
{ USB_DEVICE(0x04CA, 0x3005) },
{ USB_DEVICE(0x04CA, 0x3006) },
{ USB_DEVICE(0x04CA, 0x3008) },
@@ -107,6 +108,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -142,6 +142,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
--
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/
[63/74] aoe: reserve enough headroom on skbs
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 91c5746425aed8f7188a351f1224a26aa232e4b3 ]
Some network drivers use a non default hard_header_len
Transmitted skb should take into account dev->hard_header_len, or risk
crashes or expensive reallocations.
In the case of aoe, lets reserve MAX_HEADER bytes.
David reported a crash in defxx driver, solved by this patch.
Reported-by: David Oostdyk
Tested-by: David Oostdyk
Signed-off-by: Eric Dumazet
Cc: Ed Cashin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/block/aoe/aoecmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 887f68f..db30542 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -30,8 +30,9 @@ new_skb(ulong len)
{
struct sk_buff *skb;
- skb = alloc_skb(len, GFP_ATOMIC);
+ skb = alloc_skb(len + MAX_HEADER, GFP_ATOMIC);
if (skb) {
+ skb_reserve(skb, MAX_HEADER);
skb_reset_mac_header(skb);
skb_reset_network_header(skb);
skb->protocol = __constant_htons(ETH_P_AOE);
--
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/
[50/74] NFS: nfs_getaclargs.acl_len is a size_t
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Chuck Lever commit 56d08fef2369d5ca9ad2e1fc697f5379fd8af751 upstream. Squelch compiler warnings: fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’: fs/nfs/nfs4proc.c:3811:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] fs/nfs/nfs4proc.c:3818:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Introduced by commit bf118a34 "NFSv4: include bitmap in nfsv4 get acl data", Dec 7, 2011. Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings --- fs/nfs/nfs4proc.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -3578,7 +3578,8 @@ static ssize_t __nfs4_get_acl_uncached(s .rpc_argp = , .rpc_resp = , }; - int ret = -ENOMEM, npages, i, acl_len = 0; + int ret = -ENOMEM, npages, i; + size_t acl_len = 0; npages = (buflen + PAGE_SIZE - 1) >> PAGE_SHIFT; /* As long as we're doing a round trip to the server anyway, -- 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/
[12/74] tty: atmel_serial_probe(): index of atmel_ports[] fix
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Pawel Wieczorkiewicz
commit 503bded92da283b2f31d87e054c4c6d30c3c2340 upstream.
Index of atmel_ports[ATMEL_MAX_UART] should be smaller
than ATMEL_MAX_UART.
Signed-off-by: Pawel Wieczorkiewicz
Acked-by: Nicolas Ferre
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/serial/atmel_serial.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -159,7 +159,7 @@ struct atmel_uart_port {
};
static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
-static unsigned long atmel_ports_in_use;
+static DECLARE_BITMAP(atmel_ports_in_use, ATMEL_MAX_UART);
#ifdef SUPPORT_SYSRQ
static struct console atmel_console;
@@ -1784,15 +1784,14 @@ static int __devinit atmel_serial_probe(
if (ret < 0)
/* port id not found in platform data nor device-tree aliases:
* auto-enumerate it */
- ret = find_first_zero_bit(_ports_in_use,
- sizeof(atmel_ports_in_use));
+ ret = find_first_zero_bit(atmel_ports_in_use, ATMEL_MAX_UART);
- if (ret > ATMEL_MAX_UART) {
+ if (ret >= ATMEL_MAX_UART) {
ret = -ENODEV;
goto err;
}
- if (test_and_set_bit(ret, _ports_in_use)) {
+ if (test_and_set_bit(ret, atmel_ports_in_use)) {
/* port already in use */
ret = -EBUSY;
goto err;
@@ -1866,7 +1865,7 @@ static int __devexit atmel_serial_remove
/* "port" is allocated statically, so we shouldn't free it */
- clear_bit(port->line, _ports_in_use);
+ clear_bit(port->line, atmel_ports_in_use);
clk_put(atmel_port->clk);
--
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/
[13/74] HID: usbhid: quirk for Realtek Multi-card reader
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Boyer
commit 3d464d9b71ef2f2b40a4bc9dcf06794fd1be9d12 upstream.
This device needs to be added to the quirks list with HID_QUIRK_NO_INIT_REPORTS,
otherwise it causes 10 seconds timeout during report initialization.
This fixes Red Hat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=806587
Signed-off-by: Josh Boyer
Signed-off-by: Jiri Kosina
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/hid/hid-ids.h |3 +++
drivers/hid/usbhid/hid-quirks.c |1 +
2 files changed, 4 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -621,6 +621,9 @@
#define USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH 0x3000
#define USB_DEVICE_ID_PIXART_IMAGING_INC_OPTICAL_TOUCH_SCREEN 0x3001
+#define USB_VENDOR_ID_REALTEK 0x0bda
+#define USB_DEVICE_ID_REALTEK_READER 0x0152
+
#define USB_VENDOR_ID_ROCCAT 0x1e7d
#define USB_DEVICE_ID_ROCCAT_ARVO 0x30d4
#define USB_DEVICE_ID_ROCCAT_KONE 0x2ced
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -76,6 +76,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PRODIGE, USB_DEVICE_ID_PRODIGE_CORDLESS,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_QUANTA,
USB_DEVICE_ID_PIXART_IMAGING_INC_OPTICAL_TOUCH_SCREEN, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_REALTEK, USB_DEVICE_ID_REALTEK_READER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SUN, USB_DEVICE_ID_RARITAN_KVM_DONGLE, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_SYMBOL, USB_DEVICE_ID_SYMBOL_SCANNER_1, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_SYMBOL, USB_DEVICE_ID_SYMBOL_SCANNER_2, HID_QUIRK_NOGET
},
--
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/
[64/74] atl1e: drop pci-msi support because of packet corruption
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Hannes Frederic Sowa
[ Upstream commit 188ab1b105c96656f6bcfb49d0d8bb1b1936b632 ]
Usage of pci-msi results in corrupted dma packet transfers to the host.
Reported-by: rebelyouth
Cc: Huang, Xiong
Tested-by: Christian Sünkenberg
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/atheros/atl1e/atl1e.h | 1 -
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 22 ++
2 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e.h
b/drivers/net/ethernet/atheros/atl1e/atl1e.h
index 829b5ad..edfdf6b 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e.h
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e.h
@@ -438,7 +438,6 @@ struct atl1e_adapter {
struct atl1e_hwhw;
struct atl1e_hw_stats hw_stats;
- bool have_msi;
u32 wol;
u16 link_speed;
u16 link_duplex;
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 95483bc..c69dc29 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -1867,37 +1867,19 @@ static void atl1e_free_irq(struct atl1e_adapter
*adapter)
struct net_device *netdev = adapter->netdev;
free_irq(adapter->pdev->irq, netdev);
-
- if (adapter->have_msi)
- pci_disable_msi(adapter->pdev);
}
static int atl1e_request_irq(struct atl1e_adapter *adapter)
{
struct pci_dev*pdev = adapter->pdev;
struct net_device *netdev = adapter->netdev;
- int flags = 0;
int err = 0;
- adapter->have_msi = true;
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- netdev_dbg(adapter->netdev,
- "Unable to allocate MSI interrupt Error: %d\n", err);
- adapter->have_msi = false;
- } else
- netdev->irq = pdev->irq;
-
-
- if (!adapter->have_msi)
- flags |= IRQF_SHARED;
- err = request_irq(adapter->pdev->irq, atl1e_intr, flags,
- netdev->name, netdev);
+ err = request_irq(pdev->irq, atl1e_intr, IRQF_SHARED,
+ netdev->name, netdev);
if (err) {
netdev_dbg(adapter->netdev,
"Unable to allocate interrupt Error: %d\n", err);
- if (adapter->have_msi)
- pci_disable_msi(adapter->pdev);
return err;
}
netdev_dbg(adapter->netdev, "atl1e_request_irq OK\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/
[57/74] thermal: shorten too long mcast group name
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Masatake YAMATO
[ Upstream commits 73214f5d9f33b79918b1f7babddd5c8af28dd23d
and f1e79e208076ffe7bad97158275f1c572c04f5c7, the latter
adds an assertion to genetlink to prevent this from happening
again in the future. ]
The original name is too long.
Signed-off-by: Masatake YAMATO
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
include/linux/thermal.h | 2 +-
net/netlink/genetlink.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 47b4a27..5ef859a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -108,7 +108,7 @@ struct thermal_zone_device {
/* Adding event notification support elements */
#define THERMAL_GENL_FAMILY_NAME"thermal_event"
#define THERMAL_GENL_VERSION0x01
-#define THERMAL_GENL_MCAST_GROUP_NAME "thermal_mc_group"
+#define THERMAL_GENL_MCAST_GROUP_NAME "thermal_mc_grp"
enum events {
THERMAL_AUX0,
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 482fa57..874f8ff 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -134,6 +134,7 @@ int genl_register_mc_group(struct genl_family *family,
int err = 0;
BUG_ON(grp->name[0] == '\0');
+ BUG_ON(memchr(grp->name, '\0', GENL_NAMSIZ) == NULL);
genl_lock();
--
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/
[06/74] Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: AceLan Kao
commit 3a61eda81ebcfc006ebb1496764299d53e5bf67f upstream.
Add support for the AR9462 chip
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e04e Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: AceLan Kao
Signed-off-by: Gustavo Padovan
Signed-off-by: Ben Hutchings
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -82,6 +82,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x13d3, 0x3393) },
+ { USB_DEVICE(0x0489, 0xe04e) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -111,6 +112,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -149,6 +149,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
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/
[47/74] rt2x00: error in configurations with mesh support disabled
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Felix Fietkau commit 6ef9e2f6d12ce9e2120916804d2ddd46b954a70b upstream. If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising interface combinations with NL80211_IFTYPE_MESH_POINT present. Add appropriate ifdefs to avoid running into errors. Signed-off-by: Felix Fietkau Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville [lxiang: Backported for 3.4-stable. Removed code of simultaneous AP and mesh mode added in 4a5fc6d 3.9-rc1.] Signed-off-by: Lingzhu Xiang Reviewed-by: CAI Qian Signed-off-by: Ben Hutchings --- --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -1146,7 +1146,9 @@ int rt2x00lib_probe_dev(struct rt2x00_de rt2x00dev->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC) | BIT(NL80211_IFTYPE_AP) | +#ifdef CONFIG_MAC80211_MESH BIT(NL80211_IFTYPE_MESH_POINT) | +#endif BIT(NL80211_IFTYPE_WDS); /* -- 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/
[58/74] bonding: fix miimon and arp_interval delayed work race conditions
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: "niko...@redhat.com"
[ Upstream commit fbb0c41b814d497c656fc7be9e35456f139cb2fb ]
First I would give three observations which will be used later.
Observation 1: if (delayed_work_pending(wq)) cancel_delayed_work(wq)
This usage is wrong because the pending bit is cleared just before the
work's fn is executed and if the function re-arms itself we might end up
with the work still running. It's safe to call cancel_delayed_work_sync()
even if the work is not queued at all.
Observation 2: Use of INIT_DELAYED_WORK()
Work needs to be initialized only once prior to (de/en)queueing.
Observation 3: IFF_UP is set only after ndo_open is called
Related race conditions:
1. Race between bonding_store_miimon() and bonding_store_arp_interval()
Because of Obs.1 we can end up having both works enqueued.
2. Multiple races with INIT_DELAYED_WORK()
Since the works are not protected by anything between INIT_DELAYED_WORK()
and calls to (en/de)queue it is possible for races between the following
functions:
(races are also possible between the calls to INIT_DELAYED_WORK()
and workqueue code)
bonding_store_miimon() - bonding_store_arp_interval(), bond_close(),
bond_open(), enqueued functions
bonding_store_arp_interval() - bonding_store_miimon(), bond_close(),
bond_open(), enqueued functions
3. By Obs.1 we need to change bond_cancel_all()
Bugs 1 and 2 are fixed by moving all work initializations in bond_open
which by Obs. 2 and Obs. 3 and the fact that we make sure that all works
are cancelled in bond_close(), is guaranteed not to have any work
enqueued.
Also RTNL lock is now acquired in bonding_store_miimon/arp_interval so
they can't race with bond_close and bond_open. The opposing work is
cancelled only if the IFF_UP flag is set and it is cancelled
unconditionally. The opposing work is already cancelled if the interface
is down so no need to cancel it again. This way we don't need new
synchronizations for the bonding workqueue. These bugs (and fixes) are
tied together and belong in the same patch.
Note: I have left 1 line intentionally over 80 characters (84) because I
didn't like how it looks broken down. If you'd prefer it otherwise,
then simply break it.
v2: Make description text < 75 columns
Signed-off-by: Nikolay Aleksandrov
Signed-off-by: Jay Vosburgh
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/bonding/bond_main.c | 88
drivers/net/bonding/bond_sysfs.c | 34 +---
2 files changed, 36 insertions(+), 86 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 63e3c47..2d9faa1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3422,6 +3422,28 @@ static int bond_xmit_hash_policy_l2(struct sk_buff *skb,
int count)
/*-- Device entry points */
+static void bond_work_init_all(struct bonding *bond)
+{
+ INIT_DELAYED_WORK(>mcast_work,
+ bond_resend_igmp_join_requests_delayed);
+ INIT_DELAYED_WORK(>alb_work, bond_alb_monitor);
+ INIT_DELAYED_WORK(>mii_work, bond_mii_monitor);
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ INIT_DELAYED_WORK(>arp_work, bond_activebackup_arp_mon);
+ else
+ INIT_DELAYED_WORK(>arp_work, bond_loadbalance_arp_mon);
+ INIT_DELAYED_WORK(>ad_work, bond_3ad_state_machine_handler);
+}
+
+static void bond_work_cancel_all(struct bonding *bond)
+{
+ cancel_delayed_work_sync(>mii_work);
+ cancel_delayed_work_sync(>arp_work);
+ cancel_delayed_work_sync(>alb_work);
+ cancel_delayed_work_sync(>ad_work);
+ cancel_delayed_work_sync(>mcast_work);
+}
+
static int bond_open(struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
@@ -3444,41 +3466,27 @@ static int bond_open(struct net_device *bond_dev)
}
read_unlock(>lock);
- INIT_DELAYED_WORK(>mcast_work,
bond_resend_igmp_join_requests_delayed);
+ bond_work_init_all(bond);
if (bond_is_lb(bond)) {
/* bond_alb_initialize must be called before the timer
* is started.
*/
- if (bond_alb_initialize(bond, (bond->params.mode ==
BOND_MODE_ALB))) {
- /* something went wrong - fail the open operation */
+ if (bond_alb_initialize(bond, (bond->params.mode ==
BOND_MODE_ALB)))
return -ENOMEM;
- }
-
- INIT_DELAYED_WORK(>alb_work, bond_alb_monitor);
queue_delayed_work(bond->wq, >alb_work, 0);
}
- if (bond->params.miimon) { /* link check interval, in milliseconds. */
-
[01/74] clockevents: Don't allow dummy broadcast timers
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Mark Rutland
commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.
Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.
This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.
Signed-off-by: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jon Medhurst (Tixy)
Signed-off-by: Thomas Gleixner
Signed-off-by: Ben Hutchings
---
kernel/time/tick-broadcast.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -66,7 +66,8 @@ static void tick_broadcast_start_periodi
*/
int tick_check_broadcast_device(struct clock_event_device *dev)
{
- if ((tick_broadcast_device.evtdev &&
+ if ((dev->features & CLOCK_EVT_FEAT_DUMMY) ||
+ (tick_broadcast_device.evtdev &&
tick_broadcast_device.evtdev->rating >= dev->rating) ||
(dev->features & CLOCK_EVT_FEAT_C3STOP))
return 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/
[39/74] reiserfs: Fix warning and inode leak when deleting inode with xattrs
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit 35e5cbc0af240778e61113286c019837e06aeec6 upstream. After commit 21d8a15a (lookup_one_len: don't accept . and ..) reiserfs started failing to delete xattrs from inode. This was due to a buggy test for '.' and '..' in fill_with_dentries() which resulted in passing '.' and '..' entries to lookup_one_len() in some cases. That returned error and so we failed to iterate over all xattrs of and inode. Fix the test in fill_with_dentries() along the lines of the one in lookup_one_len(). Reported-by: Pawel Zawora Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings --- fs/reiserfs/xattr.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/reiserfs/xattr.c b/fs/reiserfs/xattr.c index c196369..4cce1d9 100644 --- a/fs/reiserfs/xattr.c +++ b/fs/reiserfs/xattr.c @@ -187,8 +187,8 @@ fill_with_dentries(void *buf, const char *name, int namelen, loff_t offset, if (dbuf->count == ARRAY_SIZE(dbuf->dentries)) return -ENOSPC; - if (name[0] == '.' && (name[1] == '\0' || - (name[1] == '.' && name[2] == '\0'))) + if (name[0] == '.' && (namelen < 2 || + (namelen == 2 && name[1] == '.'))) return 0; dentry = lookup_one_len(name, dbuf->xadir, namelen); -- 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/
[00/74] 3.2.43-rc1 review
This is the start of the stable review cycle for the 3.2.43 release. There are 74 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Apr 09 23:00:00 UTC 2013. Anything received after that time might be too late. A combined patch relative to 3.2.42 will be posted as an additional response to this. A shortlog and diffstat can be found below. Ben. - AceLan Kao (3): Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e] [3a61eda81ebcfc006ebb1496764299d53e5bf67f] Bluetooth: Add support for Foxconn / Hon Hai [0489:e056] [2582d529c44d12502a700f1c3db062b9f44679bc] Bluetooth: Add support for IMC Networks [13d3:3393] [eed307e290b96636def331375e065aca43f9069a] Al Viro (2): Nest rename_lock inside vfsmount_lock [7ea600b5314529f9d1b9d6d3c41cb26fce6a7a4a] vt: synchronize_rcu() under spinlock is not nice... [e8cd8169315db57d3c9aa7dd90eda4842874] Alan Cox (1): key: Fix resource leak [a84a921978b7d56e0e4b87ffaca6367429b4d8ff] Amit Shah (2): virtio: console: add locking around c_ovq operations [9ba5c80b1aea8648a3efe5f22dc1f7cacdfbeeb8] virtio: console: rename cvq_lock to c_ivq_lock [165b1b8bbc17c9469b053bab78b11b7cbce6d161] Anatol Pomozov (1): loop: prevent bdev freeing while device in use [c1681bf8a7b1b98edee8b862a42c19c4e53205fd] Anatolij Gustschin (1): spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts [1ad849aee5f53353ed88d9cd3d68a51b03a7d44f] Artem Bityutskiy (1): UBIFS: make space fixup work in the remount case [67e753ca41782913d805ff4a8a2b0f60b26b7915] Chris Metcalf (1): tile: expect new initramfs name from hypervisor file system [ff7f3efb9abf986f4ecd8793a9593f7ca4d6431a] Chuck Lever (1): NFS: nfs_getaclargs.acl_len is a size_t [56d08fef2369d5ca9ad2e1fc697f5379fd8af751] Cong Wang (1): 8021q: fix a potential use-after-free [4a7df340ed1bac190c124c1601bfc10cde9fb4fb] Daniel Schaal (1): Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k. [2c262b2a5235b7f5b18d4d58394511f76371d7cb] Eric Dumazet (3): aoe: reserve enough headroom on skbs [91c5746425aed8f7188a351f1224a26aa232e4b3] net: add a synchronize_net() in netdev_rx_handler_unregister() [00cfec37484761a44a3b6f4675a54caa618210ae] tcp: preserve ACK clocking in TSO [f4541d60a449afd40448b06496dcd510f505928e] Fanchaoting (1): pnfs-block: removing DM device maybe cause oops when call dev_remove [4376c94618c26225e69e17b7c91169c45a90b292] Felix Fietkau (2): ath9k_hw: revert chainmask to user configuration after calibration [74632d11a133b5baf6b9d622dd19d2f944d93d94] rt2x00: error in configurations with mesh support disabled [6ef9e2f6d12ce9e2120916804d2ddd46b954a70b] Hannes Frederic Sowa (3): atl1e: drop pci-msi support because of packet corruption [188ab1b105c96656f6bcfb49d0d8bb1b1936b632] ipv6: don't accept multicast traffic with scope 0 [20314092c1b41894d8c181bf9aa6f022be2416aa] ipv6: don't accept node local multicast traffic from the wire [1c4a154e5253687c51123956dfcee9e9dfa8542d] Hong Zhiguo (1): ipv6: fix bad free of addrconf_init_net [a79ca223e029aa4f09abb337accf1812c900a800] Ian Abbott (1): staging: comedi: s626: fix continuous acquisition [e4317ce877a31dbb9d96375391c1c4ad2210d637] Iestyn C. Elfick (1): b43: A fix for DMA transmission sequence errors [b251412db99ccd4495ce372fec7daee27bf06923] J. Bruce Fields (1): nfsd4: reject "negative" acl lengths [64a817cfbded8674f345d1117b117f942a351a69] Jakub Kicinski (1): ixgbe: fix registration order of driver and DCA nofitication [f01fc1a82c2ee68726b400fadb156bd623b5f2f1] Jan Beulich (1): xen-blkback: fix dispatch_rw_block_io() error path [0e5e098ac22dae38f957e951b70d3cf73beff0f7] Jan Kara (2): reiserfs: Fix warning and inode leak when deleting inode with xattrs [35e5cbc0af240778e61113286c019837e06aeec6] udf: Fix bitmap overflow on large filesystems with small block size [89b1f39eb4189de745fae554b0d614d87c8d5c63] Jan Stancek (1): mm: prevent mmap_cache race in find_vma() [b6a9b7f6b1f21735a7456d534dc0e68e61359d2c] Jiri Kosina (1): HID: usbhid: fix build problem [570637dc8eeb2faba06228d497ff40bb019bcc93] Jiri Slaby (1): HID: microsoft: do not use compound literal - fix build [6b90466cfec2a2fe027187d675d8d14217c12d82] Joerg Roedel (1): iommu/amd: Make sure dma_ops are set for hotplug devices [c2a2876e863356b092967ea62bebdb4dd663af80] Josef Bacik (1): Btrfs: limit the global reserve to 512mb
[24/74] NFSv4.1: Fix a race in pNFS layoutcommit
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit a073dbff359f4741013ae4b8395f5364c5e00b48 upstream.
We need to clear the NFS_LSEG_LAYOUTCOMMIT bits atomically with the
NFS_INO_LAYOUTCOMMIT bit, otherwise we may end up with situations
where the two are out of sync.
The first half of the problem is to ensure that pnfs_layoutcommit_inode
clears the NFS_LSEG_LAYOUTCOMMIT bit through pnfs_list_write_lseg.
We still need to keep the reference to those segments until the RPC call
is finished, so in order to make it clear _where_ those references come
from, we add a helper pnfs_list_write_lseg_done() that cleans up after
pnfs_list_write_lseg.
Signed-off-by: Trond Myklebust
Acked-by: Benny Halevy
[bwh: Backported to 3.2: s/pnfs_put_lseg/put_lseg/]
Signed-off-by: Ben Hutchings
---
fs/nfs/nfs4proc.c | 14 --
fs/nfs/pnfs.c | 19 ++-
2 files changed, 18 insertions(+), 15 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6108,22 +6108,8 @@ nfs4_layoutcommit_done(struct rpc_task *
static void nfs4_layoutcommit_release(void *calldata)
{
struct nfs4_layoutcommit_data *data = calldata;
- struct pnfs_layout_segment *lseg, *tmp;
- unsigned long *bitlock = _I(data->args.inode)->flags;
pnfs_cleanup_layoutcommit(data);
- /* Matched by references in pnfs_set_layoutcommit */
- list_for_each_entry_safe(lseg, tmp, >lseg_list, pls_lc_list) {
- list_del_init(>pls_lc_list);
- if (test_and_clear_bit(NFS_LSEG_LAYOUTCOMMIT,
- >pls_flags))
- put_lseg(lseg);
- }
-
- clear_bit_unlock(NFS_INO_LAYOUTCOMMITTING, bitlock);
- smp_mb__after_clear_bit();
- wake_up_bit(bitlock, NFS_INO_LAYOUTCOMMITTING);
-
put_rpccred(data->cred);
kfree(data);
}
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1356,11 +1356,27 @@ static void pnfs_list_write_lseg(struct
list_for_each_entry(lseg, _I(inode)->layout->plh_segs, pls_list) {
if (lseg->pls_range.iomode == IOMODE_RW &&
- test_bit(NFS_LSEG_LAYOUTCOMMIT, >pls_flags))
+ test_and_clear_bit(NFS_LSEG_LAYOUTCOMMIT, >pls_flags))
list_add(>pls_lc_list, listp);
}
}
+static void pnfs_list_write_lseg_done(struct inode *inode, struct list_head
*listp)
+{
+ struct pnfs_layout_segment *lseg, *tmp;
+ unsigned long *bitlock = _I(inode)->flags;
+
+ /* Matched by references in pnfs_set_layoutcommit */
+ list_for_each_entry_safe(lseg, tmp, listp, pls_lc_list) {
+ list_del_init(>pls_lc_list);
+ put_lseg(lseg);
+ }
+
+ clear_bit_unlock(NFS_INO_LAYOUTCOMMITTING, bitlock);
+ smp_mb__after_clear_bit();
+ wake_up_bit(bitlock, NFS_INO_LAYOUTCOMMITTING);
+}
+
void pnfs_set_lo_fail(struct pnfs_layout_segment *lseg)
{
if (lseg->pls_range.iomode == IOMODE_RW) {
@@ -1409,6 +1425,7 @@ void pnfs_cleanup_layoutcommit(struct nf
if (nfss->pnfs_curr_ld->cleanup_layoutcommit)
nfss->pnfs_curr_ld->cleanup_layoutcommit(data);
+ pnfs_list_write_lseg_done(data->args.inode, >lseg_list);
}
/*
--
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/
[17/74] ath9k_hw: revert chainmask to user configuration after calibration
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Felix Fietkau
commit 74632d11a133b5baf6b9d622dd19d2f944d93d94 upstream.
The commit 'ath9k_hw: fix calibration issues on chainmask that don't
include chain 0' changed the hardware chainmask to the chip chainmask
for the duration of the calibration, but the revert to user
configuration in the reset path runs too early.
That causes some issues with limiting the number of antennas (including
spurious failure in hardware-generated packets).
Fix this by reverting the chainmask after the essential parts of the
calibration that need the workaround, and before NF calibration is run.
Signed-off-by: Felix Fietkau
Reported-by: Wojciech Dubowik
Tested-by: Wojciech Dubowik
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c |4
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -946,6 +946,7 @@ static bool ar9003_hw_init_cal(struct at
AR_PHY_CL_TAB_1,
AR_PHY_CL_TAB_2 };
+ /* Use chip chainmask only for calibration */
ar9003_hw_set_chain_masks(ah, ah->caps.rx_chainmask,
ah->caps.tx_chainmask);
if (rtt) {
@@ -1087,6 +1088,9 @@ skip_tx_iqcal:
ar9003_hw_rtt_disable(ah);
}
+ /* Revert chainmask to runtime parameters */
+ ar9003_hw_set_chain_masks(ah, ah->rxchainmask, ah->txchainmask);
+
/* Initialize list pointers */
ah->cal_list = ah->cal_list_last = ah->cal_list_curr = NULL;
ah->supp_cals = IQ_MISMATCH_CAL;
--
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/
[RESEND PATCH 3.8-stable] ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Thomas Abraham "
commit 60db7e5f9c9a25a7a9b01007e6e3f5a93bc16a3a upstream
The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.
Signed-off-by: Thomas Abraham
Signed-off-by: Girish K S
Signed-off-by: Kukjin
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-exynos/common.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1a89824..3b6de7a 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,6 +299,7 @@ void exynos4_restart(char mode, const char *cmd)
void exynos5_restart(char mode, const char *cmd)
{
+ struct device_node *np;
u32 val;
void __iomem *addr;
@@ -306,8 +307,9 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
- val = (0x10 << 20) | (0x1 << 16);
- addr = EXYNOS5440_SWRESET;
+ np = of_find_compatible_node(NULL, NULL,
"samsung,exynos5440-clock");
+ addr = of_iomap(np, 0) + 0xcc;
+ val = (0xfff << 20) | (0x1 << 16);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
--
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/
[RESEND PATCH 3.8-stable] cpufreq: exynos: Get booting freq value in exynos_cpufreq_init
This patch looks like it should be in the 3.8-stable tree, should we
applyit?
--
From: "Jonghwan Choi "
commit 6e45eb12fd1c741d556bf264ee98853b5f3104e5 upstream
Boot_freq is for saving booting freq. But exynos_cpufreq_cpu_init
is called in hotplug. If boot_freq is existed in exynos_cpufreq_cpu_init,
boot_freq could be changed.
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..41fc550 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -222,8 +222,6 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
*policy)
cpufreq_frequency_table_get_attr(exynos_info->freq_table,
policy->cpu);
- locking_frequency = exynos_getspeed(0);
-
/* set the transition latency value */
policy->cpuinfo.transition_latency = 10;
@@ -288,6 +286,8 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ locking_frequency = exynos_getspeed(0);
+
register_pm_notifier(_cpufreq_nb);
if (cpufreq_register_driver(_driver)) {
--
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/
[56/74] 8021q: fix a potential use-after-free
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Cong Wang [ Upstream commit 4a7df340ed1bac190c124c1601bfc10cde9fb4fb ] vlan_vid_del() could possibly free ->vlan_info after a RCU grace period, however, we may still refer to the freed memory area by 'grp' pointer. Found by code inspection. This patch moves vlan_vid_del() as behind as possible. Cc: Patrick McHardy Cc: "David S. Miller" Signed-off-by: Cong Wang Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/8021q/vlan.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index 5471628..963f285 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -110,13 +110,6 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head) grp = rtnl_dereference(real_dev->vlgrp); BUG_ON(!grp); - /* Take it out of our own structures, but be sure to interlock with -* HW accelerating devices or SW vlan input packet processing if -* VLAN is not 0 (leave it there for 802.1p). -*/ - if (vlan_id && (real_dev->features & NETIF_F_HW_VLAN_FILTER)) - ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id); - grp->nr_vlans--; if (vlan->flags & VLAN_FLAG_GVRP) @@ -139,6 +132,13 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head) call_rcu(>rcu, vlan_rcu_free); } + /* Take it out of our own structures, but be sure to interlock with +* HW accelerating devices or SW vlan input packet processing if +* VLAN is not 0 (leave it there for 802.1p). +*/ + if (vlan_id && (real_dev->features & NETIF_F_HW_VLAN_FILTER)) + ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id); + /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); } -- 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/
[71/74] pch_gbe: fix ip_summed checksum reporting on rx
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Veaceslav Falico [ Upstream commit 76a0e68129d7d24eb995a6871ab47081bbfa0acc ] skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that checksums were correct and CHECKSUM_NONE in any other case. They're currently placed vice versa, which breaks the forwarding scenario. Fix it by placing them as described above. Signed-off-by: Veaceslav Falico Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c index 43c7b25..495d65c 100644 --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c @@ -1545,9 +1545,9 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter, skb_put(skb, length); skb->protocol = eth_type_trans(skb, netdev); if (tcp_ip_status & PCH_GBE_RXD_ACC_STAT_TCPIPOK) - skb->ip_summed = CHECKSUM_NONE; - else skb->ip_summed = CHECKSUM_UNNECESSARY; + else + skb->ip_summed = CHECKSUM_NONE; napi_gro_receive(>napi, skb); (*work_done)++; -- 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/
[73/74] bonding: get netdev_rx_handler_unregister out of locks
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Veaceslav Falico
commit fcd99434fb5c137274d2e15dd2a6a7455f0f29ff upstream.
Now that netdev_rx_handler_unregister contains synchronize_net(), we need
to call it outside of bond->lock, cause it might sleep. Also, remove the
already unneded synchronize_net().
Signed-off-by: Veaceslav Falico
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/bonding/bond_main.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1934,12 +1934,11 @@ int bond_release(struct net_device *bond
return -EINVAL;
}
+ write_unlock_bh(>lock);
/* unregister rx_handler early so bond_handle_frame wouldn't be called
* for this slave anymore.
*/
netdev_rx_handler_unregister(slave_dev);
- write_unlock_bh(>lock);
- synchronize_net();
write_lock_bh(>lock);
if (!bond->params.fail_over_mac) {
--
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-stable] bonding: remove sysfs before removing devices
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Veaceslav Falico " commit 4de79c737b200492195ebc54a887075327e1ec1d upstream We have a race condition if we try to rmmod bonding and simultaneously add a bond master through sysfs. In bonding_exit() we first remove the devices (through rtnl_link_unregister() ) and only after that we remove the sysfs. If we manage to add a device through sysfs after that the devices were removed - we'll end up with that device/sysfs structure and with the module unloaded. Fix this by first removing the sysfs and only after that calling rtnl_link_unregister(). Signed-off-by: Veaceslav Falico Signed-off-by: David S. Miller Signed-off-by: Jonghwan Choi --- drivers/net/bonding/bond_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 27cdf1f..fb6b559 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -4975,8 +4975,8 @@ static void __exit bonding_exit(void) bond_destroy_debugfs(); - rtnl_link_unregister(_link_ops); unregister_pernet_subsys(_net_ops); + rtnl_link_unregister(_link_ops); #ifdef CONFIG_NET_POLL_CONTROLLER /* -- 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/
[68/74] ipv6: don't accept node local multicast traffic from the wire
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Hannes Frederic Sowa [ Upstream commit 1c4a154e5253687c51123956dfcee9e9dfa8542d ] Erik Hugne's errata proposal (Errata ID: 3480) to RFC4291 has been verified: http://www.rfc-editor.org/errata_search.php?eid=3480 We have to check for pkt_type and loopback flag because either the packets are allowed to travel over the loopback interface (in which case pkt_type is PACKET_HOST and IFF_LOOPBACK flag is set) or they travel over a non-loopback interface back to us (in which case PACKET_TYPE is PACKET_LOOPBACK and IFF_LOOPBACK flag is not set). Cc: Erik Hugne Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/ipv6/ip6_input.c | 12 1 file changed, 12 insertions(+) diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c index 15295e9..6a4f4f3 100644 --- a/net/ipv6/ip6_input.c +++ b/net/ipv6/ip6_input.c @@ -111,6 +111,18 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt ipv6_addr_loopback(>daddr)) goto err; + /* RFC4291 Errata ID: 3480 +* Interface-Local scope spans only a single interface on a +* node and is useful only for loopback transmission of +* multicast. Packets with interface-local scope received +* from another node must be discarded. +*/ + if (!(skb->pkt_type == PACKET_LOOPBACK || + dev->flags & IFF_LOOPBACK) && + ipv6_addr_is_multicast(>daddr) && + IPV6_ADDR_MC_SCOPE(>daddr) == 1) + goto err; + /* RFC4291 2.7 * Nodes must not originate a packet to a multicast address whose scope * field contains the reserved value 0; if such a packet is received, it -- 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/
[67/74] ipv6: fix bad free of addrconf_init_net
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Hong Zhiguo
[ Upstream commit a79ca223e029aa4f09abb337accf1812c900a800 ]
Signed-off-by: Hong Zhiguo
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/addrconf.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index b27baed..8589c2d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4658,26 +4658,20 @@ static void addrconf_sysctl_unregister(struct inet6_dev
*idev)
static int __net_init addrconf_init_net(struct net *net)
{
- int err;
+ int err = -ENOMEM;
struct ipv6_devconf *all, *dflt;
- err = -ENOMEM;
- all = _devconf;
- dflt = _devconf_dflt;
+ all = kmemdup(_devconf, sizeof(ipv6_devconf), GFP_KERNEL);
+ if (all == NULL)
+ goto err_alloc_all;
- if (!net_eq(net, _net)) {
- all = kmemdup(all, sizeof(ipv6_devconf), GFP_KERNEL);
- if (all == NULL)
- goto err_alloc_all;
+ dflt = kmemdup(_devconf_dflt, sizeof(ipv6_devconf_dflt),
GFP_KERNEL);
+ if (dflt == NULL)
+ goto err_alloc_dflt;
- dflt = kmemdup(dflt, sizeof(ipv6_devconf_dflt), GFP_KERNEL);
- if (dflt == NULL)
- goto err_alloc_dflt;
- } else {
- /* these will be inherited by all namespaces */
- dflt->autoconf = ipv6_defaults.autoconf;
- dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
- }
+ /* these will be inherited by all namespaces */
+ dflt->autoconf = ipv6_defaults.autoconf;
+ dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
net->ipv6.devconf_all = all;
net->ipv6.devconf_dflt = dflt;
--
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/
[69/74] ks8851: Fix interpretation of rxlen field.
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: "max.neklu...@us.elster.com"
[ Upstream commit 14bc435ea54cb888409efb54fc6b76c13ef530e9 ]
According to the Datasheet (page 52):
15-12 Reserved
11-0 RXBC Receive Byte Count
This field indicates the present received frame byte size.
The code has a bug:
rxh = ks8851_rdreg32(ks, KS_RXFHSR);
rxstat = rxh & 0x;
rxlen = rxh >> 16; // BUG!!! 0xFFF mask should be applied
Signed-off-by: Max Nekludov
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index f56743a..115e374 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -490,7 +490,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
for (; rxfc != 0; rxfc--) {
rxh = ks8851_rdreg32(ks, KS_RXFHSR);
rxstat = rxh & 0x;
- rxlen = rxh >> 16;
+ rxlen = (rxh >> 16) & 0xfff;
netif_dbg(ks, rx_status, ks->netdev,
"rx: stat 0x%04x, len 0x%04x\n", rxstat, rxlen);
--
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/
[70/74] net: add a synchronize_net() in netdev_rx_handler_unregister()
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 00cfec37484761a44a3b6f4675a54caa618210ae ]
commit 35d48903e97819 (bonding: fix rx_handler locking) added a race
in bonding driver, reported by Steven Rostedt who did a very good
diagnosis :
I'm currently debugging a crash in an old 3.0-rt kernel that one of our
customers is seeing. The bug happens with a stress test that loads and
unloads the bonding module in a loop (I don't know all the details as
I'm not the one that is directly interacting with the customer). But the
bug looks to be something that may still be present and possibly present
in mainline too. It will just be much harder to trigger it in mainline.
In -rt, interrupts are threads, and can schedule in and out just like
any other thread. Note, mainline now supports interrupt threads so this
may be easily reproducible in mainline as well. I don't have the ability
to tell the customer to try mainline or other kernels, so my hands are
somewhat tied to what I can do.
But according to a core dump, I tracked down that the eth irq thread
crashed in bond_handle_frame() here:
slave = bond_slave_get_rcu(skb->dev);
bond = slave->bond; <--- BUG
the slave returned was NULL and accessing slave->bond caused a NULL
pointer dereference.
Looking at the code that unregisters the handler:
void netdev_rx_handler_unregister(struct net_device *dev)
{
ASSERT_RTNL();
RCU_INIT_POINTER(dev->rx_handler, NULL);
RCU_INIT_POINTER(dev->rx_handler_data, NULL);
}
Which is basically:
dev->rx_handler = NULL;
dev->rx_handler_data = NULL;
And looking at __netif_receive_skb() we have:
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
switch (rx_handler()) {
My question to all of you is, what stops this interrupt from happening
while the bonding module is unloading? What happens if the interrupt
triggers and we have this:
CPU0CPU1
rx_handler = skb->dev->rx_handler
netdev_rx_handler_unregister() {
dev->rx_handler = NULL;
dev->rx_handler_data = NULL;
rx_handler()
bond_handle_frame() {
slave = skb->dev->rx_handler;
bond = slave->bond; <-- NULL pointer dereference!!!
What protection am I missing in the bond release handler that would
prevent the above from happening?
We can fix bug this in two ways. First is adding a test in
bond_handle_frame() and others to check if rx_handler_data is NULL.
A second way is adding a synchronize_net() in
netdev_rx_handler_unregister() to make sure that a rcu protected reader
has the guarantee to see a non NULL rx_handler_data.
The second way is better as it avoids an extra test in fast path.
Reported-by: Steven Rostedt
Signed-off-by: Eric Dumazet
Cc: Jiri Pirko
Cc: Paul E. McKenney
Acked-by: Steven Rostedt
Reviewed-by: Paul E. McKenney
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/core/dev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index b23bbbf..720aea0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3193,6 +3193,7 @@ int netdev_rx_handler_register(struct net_device *dev,
if (dev->rx_handler)
return -EBUSY;
+ /* Note: rx_handler_data must be set before rx_handler */
rcu_assign_pointer(dev->rx_handler_data, rx_handler_data);
rcu_assign_pointer(dev->rx_handler, rx_handler);
@@ -3213,6 +3214,11 @@ void netdev_rx_handler_unregister(struct net_device *dev)
ASSERT_RTNL();
RCU_INIT_POINTER(dev->rx_handler, NULL);
+ /* a reader seeing a non NULL rx_handler in a rcu_read_lock()
+* section has a guarantee to see a non NULL rx_handler_data
+* as well.
+*/
+ synchronize_net();
RCU_INIT_POINTER(dev->rx_handler_data, NULL);
}
EXPORT_SYMBOL_GPL(netdev_rx_handler_unregister);
--
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/
[66/74] ipv6: don't accept multicast traffic with scope 0
3.2.43-rc1 review patch. If anyone has any objections, please let me know. -- From: Hannes Frederic Sowa [ Upstream commit 20314092c1b41894d8c181bf9aa6f022be2416aa ] v2: a) moved before multicast source address check b) changed comment to netdev style Cc: Erik Hugne Cc: YOSHIFUJI Hideaki Acked-by: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/ipv6/ip6_input.c | 9 + 1 file changed, 9 insertions(+) diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c index f8d24dd..15295e9 100644 --- a/net/ipv6/ip6_input.c +++ b/net/ipv6/ip6_input.c @@ -111,6 +111,15 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt ipv6_addr_loopback(>daddr)) goto err; + /* RFC4291 2.7 +* Nodes must not originate a packet to a multicast address whose scope +* field contains the reserved value 0; if such a packet is received, it +* must be silently dropped. +*/ + if (ipv6_addr_is_multicast(>daddr) && + IPV6_ADDR_MC_SCOPE(>daddr) == 0) + goto err; + /* * RFC4291 2.7 * Multicast addresses must not be used as source addresses in IPv6 -- 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/
[72/74] smsc75xx: fix jumbo frame support
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Steve Glendinning
[ Upstream commit 4c51e53689569398d656e631c17308d9b8e84650 ]
This patch enables RX of jumbo frames for LAN7500.
Previously the driver would transmit jumbo frames succesfully but
would drop received jumbo frames (incrementing the interface errors
count).
With this patch applied the device can succesfully receive jumbo
frames up to MTU 9000 (9014 bytes on the wire including ethernet
header).
Signed-off-by: Steve Glendinning
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/usb/smsc75xx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 7bd219b..f3d17f8 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -720,8 +720,12 @@ static int smsc75xx_set_rx_max_frame_length(struct usbnet
*dev, int size)
static int smsc75xx_change_mtu(struct net_device *netdev, int new_mtu)
{
struct usbnet *dev = netdev_priv(netdev);
+ int ret;
+
+ if (new_mtu > MAX_SINGLE_PACKET_SIZE)
+ return -EINVAL;
- int ret = smsc75xx_set_rx_max_frame_length(dev, new_mtu);
+ ret = smsc75xx_set_rx_max_frame_length(dev, new_mtu + ETH_HLEN);
check_warn_return(ret, "Failed to set mac rx frame length");
return usbnet_change_mtu(netdev, new_mtu);
@@ -965,7 +969,7 @@ static int smsc75xx_reset(struct usbnet *dev)
netif_dbg(dev, ifup, dev->net, "FCT_TX_CTL set to 0x%08x", buf);
- ret = smsc75xx_set_rx_max_frame_length(dev, 1514);
+ ret = smsc75xx_set_rx_max_frame_length(dev, dev->net->mtu + ETH_HLEN);
check_warn_return(ret, "Failed to set max rx frame length");
ret = smsc75xx_read_reg(dev, MAC_RX, );
@@ -1109,8 +1113,8 @@ static int smsc75xx_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
else if (rx_cmd_a & (RX_CMD_A_LONG | RX_CMD_A_RUNT))
dev->net->stats.rx_frame_errors++;
} else {
- /* ETH_FRAME_LEN + 4(CRC) + 2(COE) + 4(Vlan) */
- if (unlikely(size > (ETH_FRAME_LEN + 12))) {
+ /* MAX_SINGLE_PACKET_SIZE + 4(CRC) + 2(COE) + 4(Vlan) */
+ if (unlikely(size > (MAX_SINGLE_PACKET_SIZE + ETH_HLEN
+ 12))) {
netif_dbg(dev, rx_err, dev->net,
"size err rx_cmd_a=0x%08x", rx_cmd_a);
return 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/
[74/74] HID: microsoft: do not use compound literal - fix build
3.2.43-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby
commit 6b90466cfec2a2fe027187d675d8d14217c12d82 upstream.
In patch "HID: microsoft: fix invalid rdesc for 3k kbd" I fixed
support for MS 3k keyboards. However the added check using memcmp and
a compound statement breaks build on architectures where memcmp is a
macro with parameters.
hid-microsoft.c:51:18: error: macro "memcmp" passed 6 arguments, but takes just
3
On x86_64, memcmp is a function, so I did not see the error.
Signed-off-by: Jiri Slaby
Reported-by: Geert Uytterhoeven
Signed-off-by: Jiri Kosina
Signed-off-by: Ben Hutchings
---
drivers/hid/hid-microsoft.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -47,9 +47,9 @@ static __u8 *ms_report_fixup(struct hid_
rdesc[559] = 0x45;
}
/* the same as above (s/usage/physical/) */
- if ((quirks & MS_RDESC_3K) && *rsize == 106 &&
- !memcmp((char []){ 0x19, 0x00, 0x29, 0xff },
- [94], 4)) {
+ if ((quirks & MS_RDESC_3K) && *rsize == 106 && rdesc[94] == 0x19 &&
+ rdesc[95] == 0x00 && rdesc[96] == 0x29 &&
+ rdesc[97] == 0xff) {
rdesc[94] = 0x35;
rdesc[96] = 0x45;
}
--
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: [v5] clk: add si5351 i2c common clock driver
On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver supports
> DT kernels only and VXCO feature of si5351b is not implemented. DT
> bindings selectively allow to overwrite stored Si5351 configuration
> which is very helpful for clock generators with empty eeprom
> configuration. Corresponding device tree binding documentation is
> also added.
>
> Signed-off-by: Sebastian Hesselbarth
> Tested-by: Daniel Mack
>
[ ... ]
> +static inline void _si5351_msynth_set_pll_master(
> + struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> +{
> + unsigned long flags;
> +
> + if (num > 8 ||
> + (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
> + return;
> +
> + flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> + if (is_master)
> + flags |= CLK_SET_RATE_PARENT;
> + else
> + flags &= ~CLK_SET_RATE_PARENT;
> + __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> +}
> +
Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.
Did you try to build and load the driver as module ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] efivars: Check max_size only if it is non-zero.
Some EFI implementations return always a MaximumVariableSize of 0, check against max_size only if it is non-zero. Signed-off-by: Richard Weinberger --- drivers/firmware/efivars.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c index 7acafb8..60c9899 100644 --- a/drivers/firmware/efivars.c +++ b/drivers/firmware/efivars.c @@ -449,7 +449,11 @@ check_var_size_locked(struct efivars *efivars, u32 attributes, if (status != EFI_SUCCESS) return status; - if (!storage_size || size > remaining_size || size > max_size || + if (!max_size && remaining_size > size) + printk_once(KERN_ERR FW_BUG "Broken EFI implementation is returning MaxVariableSize=0\n"); + + if (!storage_size || size > remaining_size || + (max_size && size > max_size) || (remaining_size - size) < (storage_size / 2)) return EFI_OUT_OF_RESOURCES; -- 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 2/2] efivars: Implement no_storage_paranoia parameter
Using this parameter one can disable the storage_size/2 check if he is really sure that the UEFI does sane gc. Signed-off-by: Richard Weinberger --- drivers/firmware/efivars.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c index 60c9899..0926471 100644 --- a/drivers/firmware/efivars.c +++ b/drivers/firmware/efivars.c @@ -105,8 +105,10 @@ MODULE_VERSION(EFIVARS_VERSION); static bool efivars_pstore_disable = IS_ENABLED(CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE); +static bool efivars_no_storage_paranoia; module_param_named(pstore_disable, efivars_pstore_disable, bool, 0644); +module_param_named(no_storage_paranoia, efivars_no_storage_paranoia, bool, 0644); /* * The maximum size of VariableName + Data = 1024 @@ -453,7 +455,10 @@ check_var_size_locked(struct efivars *efivars, u32 attributes, printk_once(KERN_ERR FW_BUG "Broken EFI implementation is returning MaxVariableSize=0\n"); if (!storage_size || size > remaining_size || - (max_size && size > max_size) || + (max_size && size > max_size)) + return EFI_OUT_OF_RESOURCES; + + if (!efivars_no_storage_paranoia && (remaining_size - size) < (storage_size / 2)) return EFI_OUT_OF_RESOURCES; -- 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/
Re: IMX23 usb instability on 3.9-rc5
On Sat, Apr 6, 2013 at 4:44 PM, Fabio Estevam wrote: > Maybe bad DDR initialization? Are using U-boot or bootlets to setup the DDR? > > What is your DDR frequency: 133 or 96MHz? I saw some posts in the > olimex forum that people had to run it at 96MHz to get stable > operation. Thanks Fabio, That seems to be the case. I did two of the mods sugested on olimex forums. 1) Remove R17. 2) Drop DDR speed to 96MHZ. The first improved the behavior a lot, but still have crashes. The second have almost eliminated them. On Sat, Apr 6, 2013 at 4:44 PM, Fabio Estevam wrote: > Alexandre, > > On Sat, Apr 6, 2013 at 4:39 PM, Alexandre Pereira da Silva > wrote: >> Hello, >> >> I am testing a usb key connected on a IMX23-Olinuxino board. The >> kernel panics at heavy usb trafic. This was build with the mxs >> defconfig >> >> This happens everytime with "dd if=/dev/sda of=/dev/null bs=4k". The >> messages of the failure varies a lot from run to run. > > Maybe bad DDR initialization? Are using U-boot or bootlets to setup the DDR? > > What is your DDR frequency: 133 or 96MHz? I saw some posts in the > olimex forum that people had to run it at 96MHz to get stable > operation. -- 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 2/2] hfsplus: add printk to log allocation failure in hfs_find_init()
On Mon, 2013-04-08 at 01:21 +0400, Alexey Khoroshilov wrote:
> Add printk to log allocation failure in hfs_find_init(),
> "so that there is a sign in dmesg when the error condition is triggered".
> (per Hin-Tak Leung request)
Not needed. There already is a generic dump_stack
on all allocation failures without __GFP_NOWARN.
> diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
[]
> @@ -18,8 +18,10 @@ int hfs_find_init(struct hfs_btree *tree, struct
> hfs_find_data *fd)
> + if (!ptr) {
> + printk(KERN_ERR "hfs: allocation failed in hfs_find_init()\n");
> return -ENOMEM;
--
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: Excessive stall times on ext4 in 3.9-rc2
Hi -
tytso wrote:
> So I tried to reproduce the problem, and so I installed systemtap
> (bleeding edge, since otherwise it won't work with development
> kernel), and then rebuilt a kernel with all of the necessary CONFIG
> options enabled:
>
> CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_RELAY, CONFIG_DEBUG_FS,
> CONFIG_MODULES, CONFIG_MODULE_UNLOAD
> [...]
That sounds about right.
> I then pulled down mmtests, and tried running watch-dstate.pl, which
> is what I assume you were using [...]
I just took a look at the mmtests, particularly the stap-fix.sh stuff.
The heroics therein are really not called for. git kernel developers
should use git systemtap, as has always been the case. All
compatibility hacks in stap-fix.sh have already been merged, in many
cases for months.
> [...]
> semantic error: while resolving probe point: identifier 'kprobe' at
> /tmp/stapdjN4_l:18:7
> source: probe kprobe.function("get_request_wait")
> ^
> Pass 2: analysis failed. [man error::pass2]
> Unexpected exit of STAP script at ./watch-dstate.pl line 296.
> I have no clue what to do next. Can you give me a hint?
You should see the error::pass2 man page, which refers to
error::reporting, which refers to involving stap folks and running
stap-report to gather needed info.
But in this case, that's unnecessary: the problem is most likely that
the get_request_wait function does not actually exist any longer, since
commit a06e05e6afab70b4b23c0a7975aaeae24b195cd6
Author: Tejun Heo
Date: Mon Jun 4 20:40:55 2012 -0700
block: refactor get_request[_wait]()
Systemtap could endavour to list roughly-matching functions that do
exist, if you think that's be helpful.
- FChE
--
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: AMD Vi error and lost networking with r8169
David R : > I'm been seeing some problems with my new ish AMD motherboard/processor > combo and networking (r8169). I see the following page fault :- > > Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged > [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 > flags=0x0050] Can you give the hack below a try ? diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 28fb50a..ed8625d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -4125,6 +4125,8 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp) case RTL_GIGA_MAC_VER_23: case RTL_GIGA_MAC_VER_24: case RTL_GIGA_MAC_VER_34: + case RTL_GIGA_MAC_VER_35: + case RTL_GIGA_MAC_VER_36: RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST); break; default: -- 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] gpio: remove GENERIC_GPIO completely
Hi Chen,
Cool, thanks! Can you send a formatted patch to include in the series,
or do you prefer me to squash it in the relevant patch and add your
signoff for this file?
Alex.
2013/4/6 Chen Baozi :
> On Fri, Mar 29, 2013 at 06:11:15AM -0700, Alexandre Courbot wrote:
>> Another issue, I could not update the Chinese documentation in a satisfying
>> manner due to my absence of Chinese skills. Hope that will be forgiven.
>>
> Hi Alexandre,
>
> I have changed the Chinese documentation according to your update as
> follows. Hopefully it would be helpful, :)
>
> ---
> Documentation/zh_CN/gpio.txt | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
> index 4fa7b4e..d5b8f01 100644
> --- a/Documentation/zh_CN/gpio.txt
> +++ b/Documentation/zh_CN/gpio.txt
> @@ -84,10 +84,10 @@ GPIO 公约
> 控制器的抽象函数来实现它。(有一些可选的代码能支持这种策略的实现,本文档
> 后面会介绍，但作为 GPIO 接口的客户端驱动程序必须与它的实现无关。)
>
> -也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。平台
> -必须在 Kconfig 中声明对 GENERIC_GPIO的支持 (布尔型 true)，并提供
> -一个 文件。那些调用标准 GPIO 函数的驱动应该在 Kconfig
> -入口中声明依赖GENERIC_GPIO。当驱动包含文件:
> +也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。同时，平台
> +必须在 Kconfig 中选择 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB
> +选项。那些调用标准 GPIO 函数的驱动应该在 Kconfig
> 入口中声明依赖GENERIC_GPIO。
> +当驱动包含文件:
>
> #include
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
On Sun, Apr 7, 2013 at 12:41 AM, Michael S. Tsirkin wrote: > On Thu, Apr 04, 2013 at 04:32:01PM -0700, Christoffer Dall wrote: >> [...] >> >> >> >> to give us some idea how much performance we would gain from each >> >> >> approach? Thoughput should be completely unaffected anyway, since >> >> >> virtio just coalesces kicks internally. >> >> > >> >> > Latency is dominated by the scheduling latency. >> >> > This means virtio-net is not the best benchmark. >> >> >> >> So what is a good benchmark? >> > >> > E.g. ping pong stress will do but need to look at CPU utilization, >> > that's what is affected, not latency. >> > >> >> Is there any difference in speed at all? I strongly doubt it. One of >> >> virtio's main points is to reduce the number of kicks. >> > >> > For this stage of the project I think microbenchmarks are more appropriate. >> > Doubling the price of exit is likely to be measureable. 30 cycles likely >> > not ... >> > >> I don't quite understand this point here. If we don't have anything >> real-world where we can measure a decent difference, then why are we >> doing this? I would agree with Alex that the three test scenarios >> proposed by him should be tried out before adding this complexity, >> measured in CPU utilization or latency as you wish. > > Sure, plan to do real world benchmarks for PV MMIO versus PIO as well. > I don't see why I should bother implementing hypercalls given that the > kvm maintainer says they won't be merged. > the implementation effort to simply measure the hypercall performance should be minimal, no? If we can measure a true difference in performance, I'm sure we can revisit the issue of what will be merged and what won't be, but until we have those numbers it's all speculation. >> FWIW, ARM always uses MMIO and provides hardware decoding of all sane >> (not user register-writeback) instruction, but the hypercall vs. mmio >> looks like this: >> >> hvc: 4,917 >> mmio_kernel: 6,248 > > So 20% difference? That's not far from what happens on my intel laptop: > vmcall 1519 > outl_to_kernel 1745 > 10% difference here. > >> >> But I doubt that an hvc wrapper around mmio decoding would take care >> of all this difference, because the mmio operation needs to do other >> work not realated to emulating the instruction in software, which >> you'd have to do for an hvc anyway (populate kvm_mmio structure etc.) >> > > Instead of speculating, someone with relevant hardware > could just try this, but kvm unittest doesn't seem to have arm support > at the moment. Anyone working on this? > We have a branch called kvm-selftest that replicates much of the functionality, which is what I run to get these measurements. I can port it over to unittest at some point, but I'm not active working on that. I can measure it, but we have bigger fish to fry on the ARM side right now, so it'll be a while until I get to that. -- 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 PATCH arm: initial TI-Nspire support]
On Sunday 07 April 2013, Daniel Tang wrote: > Here's an updated patch that enables support for the LCD. > > I looked into drivers/video/of_display_timing.c but it doesn't have the > fields to describe the PL11x specific options needed in struct clcd_panel. At > the moment, it is implemented by hardcoding the values in the kernel and > using the device tree to select the correct configuration. > > Signed-off-by: Daniel Tang I think you should for now keep the clcd stuff in a separate file, since it will be replaced with DT logic eventually. For now, the auxdata method is ok, but Linus Walleij might already have thought about how pl111 should get all its data from the device tree. Arnd -- 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] hfsplus: add printk to log allocation failure in hfs_find_init()
Add printk to log allocation failure in hfs_find_init(),
"so that there is a sign in dmesg when the error condition is triggered".
(per Hin-Tak Leung request)
Signed-off-by: Alexey Khoroshilov
---
fs/hfsplus/bfind.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
index d73c98d..067ddb5 100644
--- a/fs/hfsplus/bfind.c
+++ b/fs/hfsplus/bfind.c
@@ -18,8 +18,10 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
fd->tree = tree;
fd->bnode = NULL;
ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL);
- if (!ptr)
+ if (!ptr) {
+ printk(KERN_ERR "hfs: allocation failed in hfs_find_init()\n");
return -ENOMEM;
+ }
fd->search_key = ptr;
fd->key = ptr + tree->max_key_len + 2;
dprint(DBG_BNODE_REFS, "find_init: %d (%p)\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hfsplus: add error propagation to __hfsplus_ext_write_extent()
__hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
The patch implements error code propagation.
Signed-off-by: Alexey Khoroshilov
---
fs/hfsplus/extents.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
index a94f0f7..fed73f7 100644
--- a/fs/hfsplus/extents.c
+++ b/fs/hfsplus/extents.c
@@ -83,7 +83,7 @@ static u32 hfsplus_ext_lastblock(struct hfsplus_extent *ext)
return be32_to_cpu(ext->start_block) + be32_to_cpu(ext->block_count);
}
-static void __hfsplus_ext_write_extent(struct inode *inode,
+static int __hfsplus_ext_write_extent(struct inode *inode,
struct hfs_find_data *fd)
{
struct hfsplus_inode_info *hip = HFSPLUS_I(inode);
@@ -98,13 +98,13 @@ static void __hfsplus_ext_write_extent(struct inode *inode,
res = hfs_brec_find(fd, hfs_find_rec_by_key);
if (hip->extent_state & HFSPLUS_EXT_NEW) {
if (res != -ENOENT)
- return;
+ return res;
hfs_brec_insert(fd, hip->cached_extents,
sizeof(hfsplus_extent_rec));
hip->extent_state &= ~(HFSPLUS_EXT_DIRTY | HFSPLUS_EXT_NEW);
} else {
if (res)
- return;
+ return res;
hfs_bnode_write(fd->bnode, hip->cached_extents,
fd->entryoffset, fd->entrylength);
hip->extent_state &= ~HFSPLUS_EXT_DIRTY;
@@ -117,11 +117,13 @@ static void __hfsplus_ext_write_extent(struct inode
*inode,
* to explicily mark the inode dirty, too.
*/
set_bit(HFSPLUS_I_EXT_DIRTY, >flags);
+
+ return 0;
}
static int hfsplus_ext_write_extent_locked(struct inode *inode)
{
- int res;
+ int res = 0;
if (HFSPLUS_I(inode)->extent_state & HFSPLUS_EXT_DIRTY) {
struct hfs_find_data fd;
@@ -129,10 +131,10 @@ static int hfsplus_ext_write_extent_locked(struct inode
*inode)
res = hfs_find_init(HFSPLUS_SB(inode->i_sb)->ext_tree, );
if (res)
return res;
- __hfsplus_ext_write_extent(inode, );
+ res = __hfsplus_ext_write_extent(inode, );
hfs_find_exit();
}
- return 0;
+ return res;
}
int hfsplus_ext_write_extent(struct inode *inode)
@@ -175,8 +177,11 @@ static inline int __hfsplus_ext_cache_extent(struct
hfs_find_data *fd,
WARN_ON(!mutex_is_locked(>extents_lock));
- if (hip->extent_state & HFSPLUS_EXT_DIRTY)
- __hfsplus_ext_write_extent(inode, fd);
+ if (hip->extent_state & HFSPLUS_EXT_DIRTY) {
+ res = __hfsplus_ext_write_extent(inode, fd);
+ if (res)
+ return res;
+ }
res = __hfsplus_ext_read_extent(fd, hip->cached_extents, inode->i_ino,
block, HFSPLUS_IS_RSRC(inode) ?
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
On Fri, 2013-04-05 at 00:47 -0400, David Miller wrote: > From: Sven Joachim > Date: Wed, 03 Apr 2013 13:41:32 +0200 > > > On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote: > > > >> 3.8-stable review patch. If anyone has any objections, please let me know. > > > > I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and > > 3.9-rc5: "udevd[56]: sender uid=65534, message ignored". Reverting the > > patch below on top of 3.8.6-rc1 fixes that. I'm using udev version 175 > > here, and 65534 is the uid of user "nobody". > > Greg and Ben, please stop this patch from all of the -stable trees. > > I'm going to revert it and use Eric Biederman's fix instead. > > Thanks! OK, dropped it. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Re: [PATCH -next 1/3] bcache: Add missing #include
On Wed, 27 Mar 2013, Kent Overstreet wrote:
> Nope - looks like __WARN() doesn't exist if CONFIG_BUG=n, whoops.
>
> Adding this to the queue:
>
> commit 796c213186b850b3e6e8d5fd5799b0fd74721ea3
> Author: Kent Overstreet
> Date: Wed Mar 27 12:47:45 2013 -0700
>
> bcache: Use WARN_ONCE() instead of __WARN()
>
> Signed-off-by: Kent Overstreet
>
> diff --git a/drivers/md/bcache/bset.c b/drivers/md/bcache/bset.c
> index d4f2164..cb4578a 100644
> --- a/drivers/md/bcache/bset.c
> +++ b/drivers/md/bcache/bset.c
> @@ -883,7 +883,7 @@ struct bkey *bch_btree_iter_next(struct btree_iter *iter)
> iter->data->k = bkey_next(iter->data->k);
>
> if (iter->data->k > iter->data->end) {
> - __WARN();
> + WARN_ONCE(1, "bset was corrupt!\n");
> iter->data->k = iter->data->end;
> }
>
This problem still persists in linux-next as of today, how is this fix
being pushed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] netdev/phy: Implement ieee802.3 clause 45 in mdio-octeon.c
From: David Daney Date: Wed, 3 Apr 2013 12:25:32 -0700 > From: David Daney > > The Octeon SMI/MDIO interfaces can do clause 45 communications, so > implement this in the driver. > > Also fix some comment formatting to make it consistent and to comply > with the netdev style. > > Signed-off-by: David Daney Applied to net-next. -- 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 -next] usb, gadget: use appropriate warning accessors
Use the appropriate WARN() and WARN_ON() accessors to avoid a build error
when CONFIG_BUG=n:
drivers/usb/gadget/configfs.c: In function 'config_usb_cfg_unlink':
drivers/usb/gadget/configfs.c:442:2: error: implicit declaration of
function '__WARN_printf'
drivers/usb/gadget/configfs.c: In function 'configfs_do_nothing':
drivers/usb/gadget/configfs.c:733:2: error: implicit declaration of
function '__WARN'
Reported-by: Randy Dunlap
Signed-off-by: David Rientjes
---
drivers/usb/gadget/configfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -439,7 +439,7 @@ static int config_usb_cfg_unlink(
}
}
mutex_unlock(>lock);
- __WARN_printf("Unable to locate function to unbind\n");
+ WARN(1, "Unable to locate function to unbind\n");
return 0;
}
@@ -730,7 +730,7 @@ USB_CONFIG_STRINGS_LANG(gadget_strings, gadget_info);
static int configfs_do_nothing(struct usb_composite_dev *cdev)
{
- __WARN();
+ WARN_ON(1);
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes
From: Alan Ott Date: Wed, 3 Apr 2013 10:00:54 -0400 > Version 2 of this patch series: > > Differences from v1: > > 1. Patches previously numbered 5 and 6 were squashed (to become current > patch #4) at the request of Alexander Smirnov. > > 2. Current patch #2 had extraneous braces removed. > > 3. Current patch #1 was changed. It is now a patch to make mac802154 _not_ > retry sending packets on failure. I believe this to be consistent with the > 802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006) Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM/reboot: call syscore_shutdown() after disable_nonboot_cpus()
On Sunday, April 07, 2013 08:29:32 AM Greg KH wrote: > On Sun, Apr 07, 2013 at 10:46:00AM +0200, Rafael J. Wysocki wrote: > > On Sunday, April 07, 2013 10:14:14 AM Huacai Chen wrote: > > > As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core > > > subsystems PM) say, syscore_ops operations should be carried with one > > > CPU on-line and interrupts disabled. However, after commit f96972f2d > > > (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()), > > > syscore_shutdown() is called before disable_nonboot_cpus(), so break > > > the rules. We have a MIPS machine with a 8259A PIC, and there is an > > > external timer (HPET) linked at 8259A. Since 8259A has been shutdown > > > too early (by syscore_shutdown()), disable_nonboot_cpus() runs without > > > timer interrupt, so it hangs and reboot fails. This patch call > > > syscore_shutdown() a little later (after disable_nonboot_cpus()) to > > > avoid reboot failure, this is the same way as poweroff does. > > > > > > BTW, add disable_nonboot_cpus() in kernel_halt() for consistency. > > > > > > Signed-off-by: Huacai Chen > > > Cc: > > > > While I agree with the changes, I'm not sure if I'm the right maintainer, > > as this isn't really PM code. > > > > Andrew, should I take this? > > Andrew is on vacation for a few weeks, so you might need to take this > through your tree. OK But, it looks like we should actually disable interrupts on the remaining CPU after we've called disable_nonboot_cpus() so that the syscore_shutdown() assumptions are satisfied which the patch doesn't do. Chen (I apologize if that's not the right part of your full name to use here), do you think that's not necessary and if so, then for what reason? Rafael -- 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: [PATCH v2 net-next 1/8] r8169: Remove firmware code
From: Francois Romieu Date: Fri, 5 Apr 2013 01:42:29 +0200 > David Miller : > [...] >> If so, should I just apply this series as-is ? > > Yes. > > - the series is imho -stable unfriendly: whoever wants to figure what > should be fed into a -stable branch will have a hard time. :o/ > - the driver could had been more careful about firmware version/magic > checks and firmware opcodes recycling. It's a bit late. It won't > necessarily hurt. > - there is a whole release cycle ahead to find problems - if any - due > to the hw_start flow change. It seems sane. > - the relative amount of binary like cruft is going down. > > I am not overflowed with enthusiasm but the gain should exceed the pain. All applied to net-next, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: MT - handle semi-mt devices in core
Most semi-mt drivers use the slots in a manual way, but really only
need to treat the finger count manually. With this patch, a semi-mt
driver may use the input-mt core for everything else.
Signed-off-by: Henrik Rydberg
---
Hi Dmitry,
an earlier version of this patch came about as a test to handle the
synaptics profile sensor without too much extra work. I do not know
how that test panned out (no response), but this patch will likely be
useful regardless.
Henrik
drivers/input/input-mt.c | 8 +++-
include/linux/input/mt.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index 71db193..d398f13 100644
--- a/drivers/input/input-mt.c
+++ b/drivers/input/input-mt.c
@@ -79,6 +79,8 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int
num_slots,
}
if (flags & INPUT_MT_DIRECT)
__set_bit(INPUT_PROP_DIRECT, dev->propbit);
+ if (flags & INPUT_MT_SEMI_MT)
+ __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
if (flags & INPUT_MT_TRACK) {
unsigned int n2 = num_slots * num_slots;
mt->red = kcalloc(n2, sizeof(*mt->red), GFP_KERNEL);
@@ -246,6 +248,7 @@ void input_mt_sync_frame(struct input_dev *dev)
{
struct input_mt *mt = dev->mt;
struct input_mt_slot *s;
+ bool use_count = false;
if (!mt)
return;
@@ -259,7 +262,10 @@ void input_mt_sync_frame(struct input_dev *dev)
}
}
- input_mt_report_pointer_emulation(dev, (mt->flags & INPUT_MT_POINTER));
+ if ((mt->flags & INPUT_MT_POINTER) && !(mt->flags & INPUT_MT_SEMI_MT))
+ use_count = true;
+
+ input_mt_report_pointer_emulation(dev, use_count);
mt->frame++;
}
diff --git a/include/linux/input/mt.h b/include/linux/input/mt.h
index 2e86bd0..1b1dfa8 100644
--- a/include/linux/input/mt.h
+++ b/include/linux/input/mt.h
@@ -19,6 +19,7 @@
#define INPUT_MT_DIRECT0x0002 /* direct device, e.g.
touchscreen */
#define INPUT_MT_DROP_UNUSED 0x0004 /* drop contacts not seen in frame */
#define INPUT_MT_TRACK 0x0008 /* use in-kernel tracking */
+#define INPUT_MT_SEMI_MT 0x0010 /* semi-mt device, finger count handled
manually */
/**
* struct input_mt_slot - represents the state of an input MT slot
--
1.8.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][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
On Sun 07-04-13 14:00:24, Li Zefan wrote: > On 2013/4/4 20:00, Michal Hocko wrote: > > On Wed 03-04-13 17:11:15, Li Zefan wrote: > >> (I'll be off from my office soon, and I won't be responsive in the > >> following > >> 3 days.) > >> > >> I'm working on converting memcg to use cgroup->id, and then we can kill > >> css_id. > >> > >> Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can > >> still be alive. This patchset converts memcg to always use css_get/put, so > >> memcg will have the same life cycle as its corresponding cgroup, and then > >> it's always safe for memcg to use cgroup->id. > >> > >> The historical reason that memcg didn't use css_get in some cases, is that > >> cgroup couldn't be removed if there're still css refs. The situation has > >> changed so that rmdir a cgroup will succeed regardless css refs, but won't > >> be freed until css refs goes down to 0. > >> > >> This is an early post, and it's NOT TESTED. I just want to see if the > >> changes > >> are fine in general. > > > > yes, I like the approach and it looks correct as well (some minor things > > mentioned in the patches). Thanks a lot Li! This will make our lifes much > > easier. The separate ref counting was PITA especially after > > introduction of kmem accounting which made its usage even more trickier. > > > >> btw, after this patchset I think we don't need to free memcg via RCU, > >> because > >> cgroup is already freed in RCU callback. > > > > But this depends on changes waiting in for-3.10 branch, right? > > What changes? memcg changes or cgroup core changes? I don't think this depends > on anything in cgroup 3.10 branch. cgroup (be445626 e.g.) but now I've noticed that those are already merged in Linus tree. FYI: I've cherry-picked themo my -mm git tree. -- Michal Hocko SUSE Labs -- 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][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
On Sun 07-04-13 16:44:07, Li Zefan wrote: > Hi, > > I'm rebasing this patchset against latest linux-next, and it conflicts with > "[PATCH v2] memcg: debugging facility to access dangling memcgs." slightly. > > That is a debugging patch and will never be pushed into mainline, so should I > still base this patchset on that debugging patch? Could you split CONFIG_MEMCG_DEBUG_ASYNC_DESTROY changes into a separate patch so that Andrew could put it on top of the mentioned patch? > Also that patch needs update (and can be simplified) after this patchset: > - move memcg_dangling_add() to mem_cgroup_css_offline() > - remove memcg->memcg_name, and use cgroup_path() in > mem_cgroup_dangling_read()? Every improvement is welcome. Thanks -- Michal Hocko SUSE Labs -- 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] tty: mxser: fix cycle termination condition in mxser_probe() and mxser_module_init()
There is a bug in resources deallocation code in mxser_probe() and
mxser_module_init().
As soon as variable 'i' is unsigned int, cycle termination condition i >= 0 is
always true.
The patch fixes the issue.
Signed-off-by: Alexey Khoroshilov
---
drivers/tty/mxser.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 484b6a3..302909c 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2643,9 +2643,9 @@ static int mxser_probe(struct pci_dev *pdev,
mxvar_sdriver, brd->idx + i, >dev);
if (IS_ERR(tty_dev)) {
retval = PTR_ERR(tty_dev);
- for (i--; i >= 0; i--)
+ for (; i > 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd->idx + i);
+ brd->idx + i - 1);
goto err_relbrd;
}
}
@@ -2751,9 +2751,9 @@ static int __init mxser_module_init(void)
tty_dev = tty_port_register_device(>ports[i].port,
mxvar_sdriver, brd->idx + i, NULL);
if (IS_ERR(tty_dev)) {
- for (i--; i >= 0; i--)
+ for (; i > 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd->idx + i);
+ brd->idx + i - 1);
for (i = 0; i < brd->info->nports; i++)
tty_port_destroy(>ports[i].port);
free_irq(brd->irq, brd);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Revert "tty/8250_pnp: serial port detection regression since v3.7"
This reverts commit 77e372a3d82e5e4878ce1962207edd766773cc76.
Checking for disabled resources board breaks detection pnp on another
board "AMI UEFI implementation (Version: 0406 Release Date: 06/06/2012)".
I'm working with the reporter of the original bug to write and test
a better fix.
https://bugzilla.redhat.com/show_bug.cgi?id=928246
Signed-off-by: Sean Young
Cc: stable
---
drivers/tty/serial/8250/8250_pnp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pnp.c
b/drivers/tty/serial/8250/8250_pnp.c
index b3455a9..35d9ab9 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -429,7 +429,6 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
{
struct uart_8250_port uart;
int ret, line, flags = dev_id->driver_data;
- struct resource *res = NULL;
if (flags & UNKNOWN_DEV) {
ret = serial_pnp_guess_board(dev);
@@ -440,12 +439,11 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
memset(, 0, sizeof(uart));
if (pnp_irq_valid(dev, 0))
uart.port.irq = pnp_irq(dev, 0);
- if ((flags & CIR_PORT) && pnp_port_valid(dev, 2))
- res = pnp_get_resource(dev, IORESOURCE_IO, 2);
- else if (pnp_port_valid(dev, 0))
- res = pnp_get_resource(dev, IORESOURCE_IO, 0);
- if (pnp_resource_enabled(res)) {
- uart.port.iobase = res->start;
+ if ((flags & CIR_PORT) && pnp_port_valid(dev, 2)) {
+ uart.port.iobase = pnp_port_start(dev, 2);
+ uart.port.iotype = UPIO_PORT;
+ } else if (pnp_port_valid(dev, 0)) {
+ uart.port.iobase = pnp_port_start(dev, 0);
uart.port.iotype = UPIO_PORT;
} else if (pnp_mem_valid(dev, 0)) {
uart.port.mapbase = pnp_mem_start(dev, 0);
--
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/
Re: [PATCH] regulator: mc13783: Add device tree probe support
On Sun, Apr 07, 2013 at 09:02:11PM +0400, Alexander Shiyan wrote:
> Patch adds device tree probe support for mc13783-regulator driver.
I'd expect to see a document describing the binding for any new binding.
> + if (num_parsed != num_regulators) {
> + dev_warn(>dev,
> + "parsed %d != regulators %d - check your device tree!\n",
> + num_parsed, num_regulators);
>
> - init_data = >regulators[i];
> - desc = _regulators[init_data->id].desc;
> + num_regulators = num_parsed;
> + priv->num_regulators = num_regulators;
Why is this something we warn about? Users should be able to omit
unused regulators, no point in adding nodes that don't have any real
information.
signature.asc
Description: Digital signature
Re: Linux 3.8.6
On Sun, Apr 7, 2013 at 12:56 AM, Lucas wrote: > Thanks for reporting in. > > Somehow the thread got all messed up in LKML. It didn't parse correctly > there, but it seems that Gmane did. Here is the link: > > http://comments.gmane.org/gmane.linux.kernel.stable/48872 Those patches still have an unresolved regression against them. Unfortunately I can't reproduce it despite that I have a very similar system, and obviously a bunch of other people like you reported that the exact same patches which regressed actually fix the lvds panel fitter. So for now this stays in limbo :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
On Sat, Apr 06, 2013 at 10:11:32PM +0200, Wolfram Sang wrote: > Hi, > > > Very interesting discussion, especially the argument that "we already > > shipped" > > would not be a convincing argument. > > > > I had senior kernel maintainers tell me and the company I work for that we > > should > > submit _all_ our platform specific kernel code and drivers for inclusion > > into > > the upstream kernel. > > Yes, great. Really! > Yes, though, thinking about it, it was "submit" and didn't say anything about potential for acceptance. > > This exchange suggests that "it is a shipping product" does not count for > > such > > submissions, and that "Benefit for the kernel" would be the deciding factor > > instead. Which of course is a very vague statement - if code supporting > > Chromebookis is of no benefit for the kernel, support for my company's > > products > > for sure is much less so. > > First, let me state that I did not intend to say that the arbitrator > muxer here has NO benefit for the kernel. I was aware there might be > arguments for that and I wanted some more discussion to make that > clearer to me. Simon's mail was very helpful in that regard and I will > comment on that somewhen later. > > Still, I do have problems with "we already shipped it". If the driver is > bad or the underlying concept is fragile, I want the freedom to reject a > patch, product shipped or not. I will be supportive to find a proper > solution, promised. If all fails, there is still staging/ or the > possibility of out-of-tree patches. > I think there is a difference between a bad driver or underlying hardware. To me, "shipped" applies to hardware or firmware which can not be upgraded, not to the software running on it. > > Which kind of leaves me in a bind. On one side I promote that we should > > submit > > all our kernel code, on the other side there is a very compelling case to be > > made that it won't be accepted anyway. That doesn't make my life easier - > > Concentrate on argumenting why the driver is useful and it will be fine. > "we already shipped this" feels a bit like blackmailing to me. And since > most drivers do have well thought reasons for their existance, I'd > primarily like to hear about those. > > > essentially since it supports those who say that we should not submit > > anything > > in the first place. And believe me, there are many of those. > > > > Just to give some examples: > > - I2C multiplexers. We have a bunch of those. Looking at this exchange, > > it doesn't look good to get that code included. > > Multiplexers should be easy going, it is the arbitration which is discussed > here. > I am open to consider some generic arbitration schemes. What I am reluctant to > do is to allow every board to have its own arbitration scheme. This > would be board support hosted in the I2C directory. Meh. > "board support hosted in the I2C directory". But that is exactly what I am talking about, isn't it ? I have board specific multiplexers and a board specific I2C controller, and that is just talking about the I2C code. > > It would be nice have to get some well defined guidelines for "acceptable" > > contributions. "Benefit for the kernel" sure isn't one. > > I don't think it is possible to write down concrete guidelines for this. > "According to rule 4a) of the guidelines you have to accept my patch"? > That would be a mess, I think. > Looking at it from a maintainer perspective, I agree. Where it gets murky is really the hardware part. The (in my opinion) philosophical arguments around not permitting device-tree based instantiation of uio devices is one example. Another practical example I had to deal with in my previous company is VGA memory space. Some hw geniuses decided to re-use the VGA memory space in an embedded x86 device for an EEPROM. Guess what - the x86 kernel writes into that space no matter what. A patch to address that problem was rejected because "you should not re-use VGA memory space". As if I had a choice. A better example might be Kontron board support. They implement gpio, I2C mux, and a watchdog in a PLD. They too have an access arbitration scheme where one has to acquire a hardware mutex before accessing the pld, if I understand correctly because some microcontroller might need to access it as well. Leaving the actual code aside, would you reject that too if you don't like the arbitration scheme, or because you don't want to have board support in the i2c directory ? Thanks, Guenter -- 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 part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently
> From: Dan Magenheimer > Subject: RE: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages > more efficiently > > > From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com] > > Subject: Re: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled > > pages more efficiently > > > > Hi Dan, > > > > Some issues against Ramster: > > > > Sure! I am concerned about Konrad's patches adding debug.c as they > add many global variables. They are only required when ZCACHE_DEBUG > is enabled so they may be ok. If not, adding ramster variables > to debug.c may make the problem worse. Oops, I just noticed/remembered that ramster uses BOTH debugfs and sysfs. The sysfs variables are all currently required, i.e. for configuration so should not be tied to debugfs or a DEBUG config option. However, if there is a more acceptable way to implement the function of those sysfs variables, that would be fine. Thanks, Dan -- 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 part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently
> From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com] > Subject: Re: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages > more efficiently > > Hi Dan, > > Some issues against Ramster: > > - Ramster who takes advantage of zcache also should support zero-filled > pages more efficiently, correct? It doesn't handle zero-filled pages well > currently. When you first posted your patchset I took a quick look at ramster and it looked like your patchset should work for ramster also. However I didn't actually run ramster to try it so there may be a bug. If it doesn't work, I would very much appreciate a patch. > - Ramster DebugFS counters are exported in /sys/kernel/mm/, but > zcache/frontswap/cleancache > all are exported in /sys/kernel/debug/, should we unify them? That would be great. > - If ramster also should move DebugFS counters to a single file like > zcache do? Sure! I am concerned about Konrad's patches adding debug.c as they add many global variables. They are only required when ZCACHE_DEBUG is enabled so they may be ok. If not, adding ramster variables to debug.c may make the problem worse. > If you confirm these issues are make sense to fix, I will start coding. ;-) That would be great. Note that I have a how-to for ramster here: https://oss.oracle.com/projects/tmem/dist/files/RAMster/HOWTO-120817 If when you are testing you find that this how-to has mistakes, please let me know. Or feel free to add the (corrected) how-to file as a patch in your patchset. Thanks very much, Wanpeng, for your great contributions! (Ric, since you have expressed interest in ramster, if you try it and find corrections to the how-to file above, your input would be very much appreciated also!) Dan -- 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] backports: adds regulator and media susbsystems
On Sat, Apr 6, 2013 at 7:37 PM, Luis R. Rodriguez
wrote:
> On Sat, Apr 6, 2013 at 7:35 PM, Luis R. Rodriguez
> wrote:
>> Segmentation fault
>> make[8]: *** [/home/mcgrof/tmp/build/compat/core.o] Error 139
I've narrowed the segfault to a core.c file with just:
#include
#include
void poo(void)
{
}
EXPORT_SYMBOL_GPL(poo);
Removing asynch.h fixes it. Doing this on an standalone module works
Luis
--
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 v6] pstore/ram: Add ramoops support for the Flattened Device Tree.
On Thu, Apr 04, 2013 at 09:03:47PM -0500, Rob Herring wrote: > On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov > wrote: > > On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote: > >> On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote: > >> > When called with a non-zero of_node, fill out a new ramoops_platform_data > >> > with data from the specified Flattened Device Tree node. > >> > Update ramoops documentation with the new FDT interface. > >> > Update devicetree/binding documentation with pstore/ramoops.txt. > >> > >> Thanks for your work, Bryan! There were a few issues, I fixed > >> them myself but I need your confirmation if you're OK w/ all > >> the changes. > > [...] > >> So, the resulting patch is down below. But I have not pushed > >> it out yet, I'm waiting for your sign off. If you're OK with the > >> changes, please reply with > >> 'Signed-off-by: Bryan Freed ' > > > > Bryan, have you had a chance to look into this? > > Whatever happened to this? Olof was also looking at doing a binding > back in Jan 2012: > > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg09905.html I don't know. Bryan's patch looked good, I'd happily apply it. But I still need Bryan's Signed-off-by tag. :-/ Or, somebody needs to sign off on his behalf (anyone from Chromium project?). Or redo the patch. Thanks, Anton -- 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 cgroup/for-3.10] devcg: remove broken_hierarchy tag
>From f913fbedbdfc08eeff742c4b3077e267d8fc867f Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Sun, 7 Apr 2013 10:25:39 -0700
bd2953ebbb ("devcg: propagate local changes down the hierarchy")
implemented proper hierarchy support. Remove the broken tag.
Signed-off-by: Tejun Heo
Cc: Aristeu Rozanski
---
Applying to cgroup/for-3.10.
Thanks.
security/device_cgroup.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 221967d..994aecc 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -739,15 +739,6 @@ struct cgroup_subsys devices_subsys = {
.css_offline = devcgroup_offline,
.subsys_id = devices_subsys_id,
.base_cftypes = dev_cgroup_files,
-
- /*
-* While devices cgroup has the rudimentary hierarchy support which
-* checks the parent's restriction, it doesn't properly propagates
-* config changes in ancestors to their descendents. A child
-* should only be allowed to add more restrictions to the parent's
-* configuration. Fix it and remove the following.
-*/
- .broken_hierarchy = true,
};
/**
--
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/
Re: [PATCH] do not try to sync identity map for non-mapped pages
On Sun, Apr 07, 2013 at 09:34:07AM -0700, H. Peter Anvin wrote: > We shouldn't, no. /dev/mem really needs to be fixed along a bunch of > axes. Yes, it is privileged and extra creepy, but it should either > work or it should fail cleanly. Can't we filter out accesses through /dev/mem and not BUG_ON in __phys_addr() if they come through /dev/mem? Simply fail cleanly. No idea whether we'll break something still reading /dev/mem though. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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: mc13783: Add device tree probe support
Patch adds device tree probe support for mc13783-regulator driver.
Signed-off-by: Alexander Shiyan
---
drivers/regulator/mc13783-regulator.c | 55 ++
drivers/regulator/mc13xxx-regulator-core.c | 2 ++
2 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/mc13783-regulator.c
b/drivers/regulator/mc13783-regulator.c
index c46c670..fba8d5e 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -398,33 +398,62 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
struct mc13xxx_regulator_platform_data *pdata =
dev_get_platdata(>dev);
- struct mc13xxx_regulator_init_data *init_data;
+ struct mc13xxx_regulator_init_data *mc13xxx_data;
struct regulator_config config = { };
- int i, ret;
+ int i, ret, num_regulators, num_parsed;
- dev_dbg(>dev, "%s id %d\n", __func__, pdev->id);
+ num_regulators = mc13xxx_get_num_regulators_dt(pdev);
- if (!pdata)
+ if (num_regulators <= 0 && pdata)
+ num_regulators = pdata->num_regulators;
+ if (num_regulators <= 0)
return -EINVAL;
+ num_parsed = num_regulators;
+
priv = devm_kzalloc(>dev, sizeof(*priv) +
- pdata->num_regulators * sizeof(priv->regulators[0]),
+ num_regulators * sizeof(priv->regulators[0]),
GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ priv->num_regulators = num_regulators;
priv->mc13xxx_regulators = mc13783_regulators;
priv->mc13xxx = mc13783;
+ platform_set_drvdata(pdev, priv);
- for (i = 0; i < pdata->num_regulators; i++) {
- struct regulator_desc *desc;
+ mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13783_regulators,
+ ARRAY_SIZE(mc13783_regulators),
+ _parsed);
+ if (num_parsed != num_regulators) {
+ dev_warn(>dev,
+ "parsed %d != regulators %d - check your device tree!\n",
+ num_parsed, num_regulators);
- init_data = >regulators[i];
- desc = _regulators[init_data->id].desc;
+ num_regulators = num_parsed;
+ priv->num_regulators = num_regulators;
+ }
+
+ for (i = 0; i < num_regulators; i++) {
+ struct regulator_init_data *init_data;
+ struct regulator_desc *desc;
+ struct device_node *node = NULL;
+ int id;
+
+ if (mc13xxx_data) {
+ id = mc13xxx_data[i].id;
+ init_data = mc13xxx_data[i].init_data;
+ node = mc13xxx_data[i].node;
+ } else {
+ id = pdata->regulators[i].id;
+ init_data = pdata->regulators[i].init_data;
+ }
+ desc = _regulators[id].desc;
config.dev = >dev;
- config.init_data = init_data->init_data;
+ config.init_data = init_data;
config.driver_data = priv;
+ config.of_node = node;
priv->regulators[i] = regulator_register(desc, );
if (IS_ERR(priv->regulators[i])) {
@@ -435,8 +464,6 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
}
}
- platform_set_drvdata(pdev, priv);
-
return 0;
err:
while (--i >= 0)
@@ -448,13 +475,11 @@ err:
static int mc13783_regulator_remove(struct platform_device *pdev)
{
struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
- struct mc13xxx_regulator_platform_data *pdata =
- dev_get_platdata(>dev);
int i;
platform_set_drvdata(pdev, NULL);
- for (i = 0; i < pdata->num_regulators; i++)
+ for (i = 0; i < priv->num_regulators; i++)
regulator_unregister(priv->regulators[i]);
return 0;
diff --git a/drivers/regulator/mc13xxx-regulator-core.c
b/drivers/regulator/mc13xxx-regulator-core.c
index 23cf9f9..836e21e 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -205,6 +205,8 @@ struct mc13xxx_regulator_init_data
*mc13xxx_parse_regulators_dt(
for_each_child_of_node(parent, child) {
for (i = 0; i < num_regulators; i++) {
+ if (!regulators[i].desc.name)
+ continue;
if (!of_node_cmp(child->name,
regulators[i].desc.name)) {
--
1.8.1.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
[PATCH] F2FS: Fix the logic of IS_DNODE()
Signed-off-by: Zhihui Zhang
---
fs/f2fs/node.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index afdb130..2be47b2 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -239,7 +239,7 @@ static inline bool IS_DNODE(struct page *node_page)
return false;
if (ofs >= 6 + 2 * NIDS_PER_BLOCK) {
ofs -= 6 + 2 * NIDS_PER_BLOCK;
- if ((long int)ofs % (NIDS_PER_BLOCK + 1))
+ if (!((long int)ofs % (NIDS_PER_BLOCK + 1)))
return false;
}
return true;
--
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: [PATCH] driver core: add uid and gid to devtmpfs
On Sat, Apr 6, 2013 at 7:58 PM, Greg KH wrote: > On Sat, Apr 06, 2013 at 06:45:12PM +0100, Al Viro wrote: >> On Sat, Apr 06, 2013 at 10:26:12AM -0700, Greg KH wrote: >> >> > Why not? "closed" systems, like Android and other embedded systems, >> > have "assigned" uid and gid values that never change. Right now they >> > have to have a horrible shell-script to set these values in devtmpfs >> > when the device shows up to the needed numbers. This tiny patch gets >> > rid of that shell script entirely, allowing them to specify it from the >> > kernel as needed. >> >> What's to stop them from using static /dev? Has an extra benefit of >> getting rid of devtmpfs shite completely... > > True, it would, but they like using devtmpfs :) > > This change also allows systems that have "control" devices to properly > be able to pass in the uid for the device they are creating, like rawctl > (which I know is "obsolete"), and probably dm and lvm. I thought loop > devices might also want this, as they can now be created by normal > users, but I don't think that's needed for them. It is generally useful to be able to control the uid/gid of userspace-initiated device nodes, instead of racy post-adjusting this setting from udev rules with an unpredictable long window between the request and the adjustment. The created device node can inherit the ownership of the calling process, in a similar way like we do for devpts. We have the same for the mode already, and want to be able to do the same for the other permissions properties. Thanks, Kay -- 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] do not try to sync identity map for non-mapped pages
On 04/07/2013 06:33 AM, Borislav Petkov wrote: > > looks like we haven't whacked all the moles - I keep seeing this when > testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is > still that /dev/mem accessing thing called wdm. > > I'm still wondering though whether we should BUG_ON on a /dev/mem > access? > We shouldn't, no. /dev/mem really needs to be fixed along a bunch of axes. Yes, it is privileged and extra creepy, but it should either work or it should fail cleanly. -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: [PATCHSET] cgroup: unexport locking interface
On Sun, Apr 07, 2013 at 01:38:21PM +0800, Li Zefan wrote: > On 2013/4/5 7:36, Tejun Heo wrote: > > Hello, > > > > Most cgroup_mutex abuses outside cgroup core proper have been > > eradicated but there's still one use remaining and locking interface > > is still exported. This patchset updates the last user and unexports > > the locking interface and is composed of the following five patches. > > > > 0001-cgroup-cpuset-replace-move_member_tasks_to_cpuset-wi.patch > > 0002-cgroup-relocate-cgroup_lock_live_group-and-cgroup_at.patch > > 0003-cgroup-unexport-locking-interface-and-cgroup_attach_.patch > > 0004-cgroup-kill-cgroup_-un-lock.patch > > 0005-cgroup-remove-cgroup_lock_is_held.patch > > > > Acked-by: Li Zefan Applied to cgroup/for-3.10. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm: when handling percpu_pagelist_fraction, use on_each_cpu() to set percpu pageset fields.
(4/5/13 4:33 PM), Cody P Schafer wrote: > In free_hot_cold_page(), we rely on pcp->batch remaining stable. > Updating it without being on the cpu owning the percpu pageset > potentially destroys this stability. > > Change for_each_cpu() to on_each_cpu() to fix. > > Signed-off-by: Cody P Schafer Acked-by: KOSAKI Motohiro -- 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 2/3] mm/page_alloc: convert zone_pcp_update() to use on_each_cpu() instead of stop_machine()
(4/5/13 4:33 PM), Cody P Schafer wrote: > No off-cpu users of the percpu pagesets exist. > > zone_pcp_update()'s goal is to adjust the ->high and ->mark members of a > percpu pageset based on a zone's ->managed_pages. We don't need to drain > the entire percpu pageset just to modify these fields. Avoid calling > setup_pageset() (and the draining required to call it) and instead just > set the fields' values. > > This does change the behavior of zone_pcp_update() as the percpu > pagesets will not be drained when zone_pcp_update() is called (they will > end up being shrunk, not completely drained, later when a 0-order page > is freed in free_hot_cold_page()). > > Signed-off-by: Cody P Schafer NAK. 1) zone_pcp_update() is only used from memory hotplug and it require page drain. 2) stop_machin is used for avoiding race. just removing it is insane. -- 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] PM/reboot: call syscore_shutdown() after disable_nonboot_cpus()
On Sun, Apr 07, 2013 at 10:46:00AM +0200, Rafael J. Wysocki wrote: > On Sunday, April 07, 2013 10:14:14 AM Huacai Chen wrote: > > As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core > > subsystems PM) say, syscore_ops operations should be carried with one > > CPU on-line and interrupts disabled. However, after commit f96972f2d > > (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()), > > syscore_shutdown() is called before disable_nonboot_cpus(), so break > > the rules. We have a MIPS machine with a 8259A PIC, and there is an > > external timer (HPET) linked at 8259A. Since 8259A has been shutdown > > too early (by syscore_shutdown()), disable_nonboot_cpus() runs without > > timer interrupt, so it hangs and reboot fails. This patch call > > syscore_shutdown() a little later (after disable_nonboot_cpus()) to > > avoid reboot failure, this is the same way as poweroff does. > > > > BTW, add disable_nonboot_cpus() in kernel_halt() for consistency. > > > > Signed-off-by: Huacai Chen > > Cc: > > While I agree with the changes, I'm not sure if I'm the right maintainer, > as this isn't really PM code. > > Andrew, should I take this? Andrew is on vacation for a few weeks, so you might need to take this through your tree. greg k-h -- 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] AVR32: fix building warnings caused by redifinitions of HZ
On 04/07/2013 03:55 PM, Hans-Christian Egtvedt wrote: > Around Sun 07 Apr 2013 00:43:36 +0800 or thereabout, Jiang Liu wrote: >> Fix building warnings caused by redifinitions of HZ: >> In file included from >> /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4, >> from include/linux/timex.h:63, >> from include/linux/jiffies.h:8, >> from include/linux/ktime.h:25, >> from include/linux/timer.h:5, >> from include/linux/workqueue.h:8, >> from include/linux/srcu.h:34, >> from include/linux/notifier.h:15, >> from include/linux/memory_hotplug.h:6, >> from include/linux/mmzone.h:777, >> from include/linux/gfp.h:4, >> from arch/avr32/mm/init.c:10: >> /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:6:1: warning: "HZ" >> redefined >> In file included from >> /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:4, >> from >> /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4, >> from include/linux/timex.h:63, >> from include/linux/jiffies.h:8, >> from include/linux/ktime.h:25, >> from include/linux/timer.h:5, >> from include/linux/workqueue.h:8, >> from include/linux/srcu.h:34, >> from include/linux/notifier.h:15, >> from include/linux/memory_hotplug.h:6, >> from include/linux/mmzone.h:777, >> from include/linux/gfp.h:4, >> from arch/avr32/mm/init.c:10: >> /ws/linux/kernel/linux.git/arch/avr32/include/uapi/asm/param.h:6:1: warning: >> this is the location of the previous definition > > Thanks for fixing. > >> Signed-off-by: Jiang Liu >> Cc: Haavard Skinnemoen >> Cc: Hans-Christian Egtvedt >> Cc: linux-kernel@vger.kernel.org > > Acked-by: Hans-Christian Egtvedt > >> --- >> arch/avr32/include/uapi/asm/param.h |6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/arch/avr32/include/uapi/asm/param.h >> b/arch/avr32/include/uapi/asm/param.h >> index d28aa5e..abda103 100644 >> --- a/arch/avr32/include/uapi/asm/param.h >> +++ b/arch/avr32/include/uapi/asm/param.h >> @@ -2,7 +2,11 @@ >> #define _UAPI__ASM_AVR32_PARAM_H >> >> >> -#ifndef HZ >> +#ifndef __KERNEL__ >> + /* >> +* Technically, this is wrong, but some old apps still refer to it. >> +* The proper way to get the HZ value is via sysconf(_SC_CLK_TCK). >> +*/ > > With this comment, are there AVR32 drivers/users that should be fixed? Or is > it parts of the tree in general? Hi Hans, It's copied from arch/ia64/include/uapi/asm/param.h, I feel it should be the same for AVR32 too. Regards! Gerry > >> # define HZ 100 >> #endif >> -- 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] mm: fixup changers of per cpu pageset's ->high and ->batch
(4/5/13 4:33 PM), Cody P Schafer wrote: > In one case while modifying the ->high and ->batch fields of per cpu pagesets > we're unneededly using stop_machine() (patches 1 & 2), and in another we > don't have any > syncronization at all (patch 3). > > This patchset fixes both of them. > > Note that it results in a change to the behavior of zone_pcp_update(), which > is > used by memory_hotplug. I _think_ that I've diserned (and preserved) the > essential behavior (changing ->high and ->batch), and only eliminated unneeded > actions (draining the per cpu pages), but this may not be the case. at least, memory hotplug need to drain. -- 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/4] regulator: ab8500-ext: Remove get_voltage to avoid duplicate implementation
The implementation of ab8500_ext_fixed_get_voltage is identical to
ab8500_ext_list_voltage. We can avoid the duplicate implementation by just
remove get_voltage. For fixed regulator, regulator core will call
list_voltage(rdev, 0) to get voltage if both get_voltage get_voltage_sel are
not implemented.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500-ext.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index c7896af..9aee21c 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -237,21 +237,6 @@ static unsigned int ab8500_ext_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_ext_fixed_get_voltage(struct regulator_dev *rdev)
-{
- struct regulation_constraints *regu_constraints = rdev->constraints;
-
- if (regu_constraints == NULL) {
- dev_err(rdev_get_dev(rdev), "regulator constraints null
pointer\n");
- return -EINVAL;
- }
- if (regu_constraints->min_uV && regu_constraints->max_uV) {
- if (regu_constraints->min_uV == regu_constraints->max_uV)
- return regu_constraints->min_uV;
- }
- return -EINVAL;
-}
-
static int ab8500_ext_list_voltage(struct regulator_dev *rdev,
unsigned selector)
{
@@ -275,7 +260,6 @@ static struct regulator_ops ab8500_ext_regulator_ops = {
.is_enabled = ab8500_ext_regulator_is_enabled,
.set_mode = ab8500_ext_regulator_set_mode,
.get_mode = ab8500_ext_regulator_get_mode,
- .get_voltage= ab8500_ext_fixed_get_voltage,
.list_voltage = ab8500_ext_list_voltage,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] regulator: ab8500-ext: Remove unnecessary checking for ab9540 and ab8540
This code was added by commit 0fe17e20a6
"regulator: ab8500-ext: Add support for AB9540 regulators"
and commit bd44e2cb "regulator: ab8500: Also check for AB8505 based platforms"
The original patch[1] is to set info->desc.ops = _ext_regulator_ops.
However, ab9540_ext_regulator_ops is identical to ab8500_ext_regulator_ops[2].
Thus we can complete remove the unnecessary checking for ab9540 and ab8540.
[1] https://lkml.org/lkml/2013/3/28/333
[2] https://lkml.org/lkml/2013/4/1/178
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500-ext.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 5e604a2..c7896af 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -389,15 +389,8 @@ int ab8500_ext_regulator_init(struct platform_device *pdev)
config.init_data = >ext_regulator[i];
config.driver_data = info;
- if ((is_ab9540(ab8500) || is_ab8540(ab8500)) &&
- ((info->desc.id == AB8500_EXT_SUPPLY1) ||
-(info->desc.id == AB8500_EXT_SUPPLY2) ||
-(info->desc.id == AB8500_EXT_SUPPLY3)))
- info->desc.ops = _ext_regulator_ops;
-
/* register regulator with framework */
info->rdev = regulator_register(>desc, );
-
if (IS_ERR(info->rdev)) {
err = PTR_ERR(info->rdev);
dev_err(>dev, "failed to register regulator %s\n",
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] regulator: ab8500-ext: Get rid of is_enabled from struct ab8500_ext_regulator_info
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500-ext.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 57d43a1..5e604a2 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -29,7 +29,6 @@
* @desc: regulator description
* @rdev: regulator device
* @cfg: regulator configuration (extension of regulator FW configuration)
- * @is_enabled: status of regulator (on/off)
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
* @update_mask: mask to enable/disable and set mode of regulator
@@ -46,7 +45,6 @@ struct ab8500_ext_regulator_info {
struct regulator_desc desc;
struct regulator_dev *rdev;
struct ab8500_ext_regulator_cfg *cfg;
- bool is_enabled;
u8 update_bank;
u8 update_reg;
u8 update_mask;
@@ -78,8 +76,6 @@ static int enable(struct ab8500_ext_regulator_info *info, u8
*regval)
return ret;
}
- info->is_enabled = true;
-
return ret;
}
@@ -125,8 +121,6 @@ static int disable(struct ab8500_ext_regulator_info *info,
u8 *regval)
return ret;
}
- info->is_enabled = false;
-
return ret;
}
@@ -177,11 +171,9 @@ static int ab8500_ext_regulator_is_enabled(struct
regulator_dev *rdev)
if (((regval & info->update_mask) == info->update_val_lp) ||
((regval & info->update_mask) == info->update_val_hp))
- info->is_enabled = true;
+ return 1;
else
- info->is_enabled = false;
-
- return info->is_enabled;
+ return 0;
}
static int ab8500_ext_regulator_set_mode(struct regulator_dev *rdev,
@@ -207,7 +199,7 @@ static int ab8500_ext_regulator_set_mode(struct
regulator_dev *rdev,
return -EINVAL;
}
- if (info->is_enabled) {
+ if (ab8500_ext_regulator_is_enabled(rdev)) {
u8 regval;
ret = enable(info, );
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] wfcqueue: implement __wfcq_enqueue_head() (v3)
Implement enqueue-to-head. It can run concurrently with enqueue, splice
to queue, and iteration, but requires a mutex against dequeue and splice
from queue operations.
Useful for special-cases where a queue needs to have nodes enqueued into
its head.
This patch is only compile-tested.
Changes since v1:
* Don't require mutual exclusion between traversals and
__wfcq_enqueue_head().
Changes since v2:
* Only issue cmpxchg() if queue was empty.
* Add missing memory barrier.
Signed-off-by: Mathieu Desnoyers
---
include/linux/wfcqueue.h | 76 ++-
1 file changed, 69 insertions(+), 7 deletions(-)
Index: linux/include/linux/wfcqueue.h
===
--- linux.orig/include/linux/wfcqueue.h
+++ linux/include/linux/wfcqueue.h
@@ -55,14 +55,16 @@
* [4] __wfcq_splice (source queue)
* [5] __wfcq_first
* [6] __wfcq_next
+ * [7] __wfcq_enqueue_head
*
- * [1] [2] [3] [4] [5] [6]
- * [1] - - - - - -
- * [2] - - - - - -
- * [3] - - X X X X
- * [4] - - X - X X
- * [5] - - X X - -
- * [6] - - X X - -
+ * [1] [2] [3] [4] [5] [6] [7]
+ * [1] - - - - - - -
+ * [2] - - - - - - X
+ * [3] - - X X X X X
+ * [4] - - X - X X X
+ * [5] - - X X - - -
+ * [6] - - X X - - -
+ * [7] - X X X - - X
*
* Besides locking, mutual exclusion of dequeue, splice and iteration
* can be ensured by performing all of those operations from a single
@@ -230,6 +232,66 @@ ___wfcq_node_sync_next(struct wfcq_node
}
/*
+ * __wfcq_enqueue_head: prepend a node into a queue.
+ *
+ * Issues a write memory barrier before enqueue to head. Mutual
+ * exclusion is the responsibility of the caller.
+ *
+ * Returns false if the queue was empty prior to adding the node.
+ * Returns true otherwise.
+ */
+static inline bool __wfcq_enqueue_head(struct wfcq_head *head,
+ struct wfcq_tail *tail,
+ struct wfcq_node *node)
+{
+ bool not_empty = 0;
+
+/*
+* Move tail if queue was empty. Tail pointer is the
+* linearisation point of enqueuers.
+*/
+ if (CMM_LOAD_SHARED(tail->p) != >node
+ || cmpxchg(>p, >node, node)
+ != >node) {
+ not_empty = 1;
+
+ /*
+* Queue was non-empty. We need to wait for
+* head->node.next to become non-NULL, because a
+* concurrent wfcq_append may be updating it.
+*/
+ CMM_STORE_SHARED(node->next,
+ ___wfcq_node_sync_next(>node));
+ }
+
+ /*
+* If cmpxchg succeeds (queue was empty), tail now points to
+* node, but head->node.next is still NULL. Concurrent
+* traversals seeing this state will busy-wait until we set
+* head->node.next.
+*
+* Else, queue was observed as not empty: traversals will only
+* see node after we set head->node.next.
+*/
+
+ /*
+* Orders earlier stores to data structure containing node and
+* setting node->next to NULL (or to previous head->node.next
+* value) before publication.
+*/
+ smp_wmb();
+
+ /*
+* From this point, we know that wfcq_append cannot touch
+* head->node.next, either because we successfully moved tail->p
+* to node, or because we waited for head->node.next to become
+* non-NULL. It is therefore safe to update it.
+*/
+ CMM_STORE_SHARED(head->node.next, node);
+ return not_empty;
+}
+
+/*
* __wfcq_first: get first node of a queue, without dequeuing.
*
* Content written into the node before enqueue is guaranteed to be
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] regulator: ab8500: Get rid of is_enabled from struct ab8500_regulator_info
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
This patch also moves ab8500_regulator_is_enabled() close to
ab8500_regulator_[en|dis]able functions.
This is required to avoid a forward declaration because now we call
ab8500_regulator_is_enabled() in ab8500_regulator_set_mode().
This change also makes the code better in readability by moving similar
functions to one place.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 72
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 517305e..9ebd131 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -46,7 +46,6 @@ struct ab8500_shared_mode {
* @desc: regulator description
* @regulator_dev: regulator device
* @shared_mode: used when mode is shared between two regulators
- * @is_enabled: status of regulator (on/off)
* @load_lp_uA: maximum load in idle (low power) mode
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
@@ -69,7 +68,6 @@ struct ab8500_regulator_info {
struct regulator_desc desc;
struct regulator_dev*regulator;
struct ab8500_shared_mode *shared_mode;
- bool is_enabled;
int load_lp_uA;
u8 update_bank;
u8 update_reg;
@@ -259,8 +257,6 @@ static int ab8500_regulator_enable(struct regulator_dev
*rdev)
return ret;
}
- info->is_enabled = true;
-
dev_vdbg(rdev_get_dev(rdev),
"%s-enable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n",
info->desc.name, info->update_bank, info->update_reg,
@@ -288,8 +284,6 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
- info->is_enabled = false;
-
dev_vdbg(rdev_get_dev(rdev),
"%s-disable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n",
info->desc.name, info->update_bank, info->update_reg,
@@ -298,6 +292,37 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
+static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
+ u8 regval;
+
+ if (info == NULL) {
+ dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
+ return -EINVAL;
+ }
+
+ ret = abx500_get_register_interruptible(info->dev,
+ info->update_bank, info->update_reg, );
+ if (ret < 0) {
+ dev_err(rdev_get_dev(rdev),
+ "couldn't read 0x%x register\n", info->update_reg);
+ return ret;
+ }
+
+ dev_vdbg(rdev_get_dev(rdev),
+ "%s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,"
+ " 0x%x\n",
+ info->desc.name, info->update_bank, info->update_reg,
+ info->update_mask, regval);
+
+ if (regval & info->update_mask)
+ return 1;
+ else
+ return 0;
+}
+
static unsigned int ab8500_regulator_get_optimum_mode(
struct regulator_dev *rdev, int input_uV,
int output_uV, int load_uA)
@@ -398,7 +423,7 @@ static int ab8500_regulator_set_mode(struct regulator_dev
*rdev,
mask = info->update_mask;
}
- if (info->is_enabled || dmr) {
+ if (dmr || ab8500_regulator_is_enabled(rdev)) {
ret = abx500_mask_and_set_register_interruptible(info->dev,
bank, reg, mask, val);
if (ret < 0)
@@ -464,39 +489,6 @@ static unsigned int ab8500_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
-{
- int ret;
- struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
- u8 regval;
-
- if (info == NULL) {
- dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
- return -EINVAL;
- }
-
- ret = abx500_get_register_interruptible(info->dev,
- info->update_bank, info->update_reg, );
- if (ret < 0) {
- dev_err(rdev_get_dev(rdev),
- "couldn't read 0x%x register\n", info->update_reg);
- return ret;
- }
-
- dev_vdbg(rdev_get_dev(rdev),
- "%s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,"
- " 0x%x\n",
- info->desc.name, info->update_bank, info->update_reg,
-
Re: [PATCH v4, part3 00/15] accurately calculate memory statisitic information
On 04/07/2013 09:34 AM, Simon Jeons wrote: > Hi Jiang, > On 04/06/2013 09:54 PM, Jiang Liu wrote: >> Jiang Liu (15): >>mm: fix build warnings caused by free_reserved_area() >>mm: enhance free_reserved_area() to support poisoning memory with >> zero >>mm/ARM64: kill poison_init_mem() >>mm/x86: use free_reserved_area() to simplify code >>mm/tile: use common help functions to free reserved pages >>mm, powertv: use free_reserved_area() to simplify code >>mm, acornfb: use free_reserved_area() to simplify code >>mm: fix some trivial typos in comments >>mm: use managed_pages to calculate default zonelist order >>mm: accurately calculate zone->managed_pages for highmem zones >>mm: use a dedicated lock to protect totalram_pages and >> zone->managed_pages >>mm: make __free_pages_bootmem() only available at boot time >>mm: correctly update zone->mamaged_pages >>mm: concentrate modification of totalram_pages into the mm core >>mm: report available pages as "MemTotal" for each NUMA node > > What I interested in is how you test different platform? I don't think you > can have all the physical platform. > Hi Simon, That's one issue I'm facing, I only have limited hardware platforms for testing, so I could ask for help from the community to review and test the patch series. Regards! Gerry -- 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 PATCH] wfcqueue: implement __wfcq_enqueue_head() (v2)
* Eric Wong (normalper...@yhbt.net) wrote: > Mathieu Desnoyers wrote: > > Implement enqueue-to-head. It can run concurrently with enqueue, splice > > to queue, and iteration, but requires a mutex against dequeue and splice > > from queue operations. > > > > Useful for special-cases where a queue needs to have nodes enqueued into > > its head. > > > > This patch is only compile-tested. > > > > Changes since v1: > > * Don't require mutual exclusion between traversals and > > __wfcq_enqueue_head(). > > > > Signed-off-by: Mathieu Desnoyers > > Thanks! The first hunk (sync table comment) conflicted with > my __wfcq_enqueue patch, but other than that I could not benchmark any > regression with my 4-core machine with v4 of my > "epoll: avoid spinlock contention with wfcqueue" patch. > > All I needed was "s/__wfcq_prepend/__wfcq_enqueue_head/g" to my original > patch to use the updated API. > > I was worried about the cmpxchg at first, but it does not seem to hurt > performance on my 4-core system. In fact, it was slightly better > (but within margin of error) > > time ./eponeshotmt -c 100 -w 4 -t 4 -f 10 > real0m 5.78s > user0m 1.20s > sys 0m 21.90s > > Tested-by: Eric Wong > > Hopefully somebody can test my epoll patches with more cores/threads :) Thanks for testing. Taking care of your comments, and of memory barriers, brings me to send a v3 of this patch shortly. Testing is welcome! Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: at91/setup: fix trivial typos
Fix a few trivial typos in panic, warning and debug messages.
Signed-off-by: Johan Hovold
---
arch/arm/mach-at91/setup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 4b67847..9e7c1e1 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -333,7 +333,7 @@ static void at91_dt_rstc(void)
of_id = of_match_node(rstc_ids, np);
if (!of_id)
- panic("AT91: rtsc no restart function availlable\n");
+ panic("AT91: rtsc no restart function available\n");
arm_pm_restart = of_id->data;
@@ -353,7 +353,7 @@ static void at91_dt_ramc(void)
np = of_find_matching_node(NULL, ramc_ids);
if (!np)
- panic("unable to find compatible ram conroller node in dtb\n");
+ panic("unable to find compatible ram controller node in dtb\n");
at91_ramc_base[0] = of_iomap(np, 0);
if (!at91_ramc_base[0])
@@ -403,7 +403,7 @@ static void at91_dt_shdwc(void)
np = of_find_matching_node(NULL, shdwc_ids);
if (!np) {
- pr_debug("AT91: unable to find compatible shutdown (shdwc)
conroller node in dtb\n");
+ pr_debug("AT91: unable to find compatible shutdown (shdwc)
controller node in dtb\n");
return;
}
@@ -419,7 +419,7 @@ static void at91_dt_shdwc(void)
if (!of_property_read_u32(np, "atmel,wakeup-counter", )) {
if (reg > AT91_SHDW_CPTWK0_MAX) {
- pr_warn("AT91: shdwc wakeup conter 0x%x > 0x%x reduce
it to 0x%x\n",
+ pr_warn("AT91: shdwc wakeup counter 0x%x > 0x%x reduce
it to 0x%x\n",
reg, AT91_SHDW_CPTWK0_MAX,
AT91_SHDW_CPTWK0_MAX);
reg = AT91_SHDW_CPTWK0_MAX;
}
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: at91: remove trailing semicolon from macros
Remove trailing semicolon from register-access macros. Signed-off-by: Johan Hovold --- arch/arm/mach-at91/at91_rstc.h| 2 +- arch/arm/mach-at91/at91_shdwc.h | 2 +- arch/arm/mach-at91/at91x40_time.c | 2 +- arch/arm/mach-at91/include/mach/at91_matrix.h | 2 +- arch/arm/mach-at91/include/mach/at91_st.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-at91/at91_rstc.h b/arch/arm/mach-at91/at91_rstc.h index 875fa33..a600e69 100644 --- a/arch/arm/mach-at91/at91_rstc.h +++ b/arch/arm/mach-at91/at91_rstc.h @@ -23,7 +23,7 @@ extern void __iomem *at91_rstc_base; __raw_readl(at91_rstc_base + field) #define at91_rstc_write(field, value) \ - __raw_writel(value, at91_rstc_base + field); + __raw_writel(value, at91_rstc_base + field) #else .extern at91_rstc_base #endif diff --git a/arch/arm/mach-at91/at91_shdwc.h b/arch/arm/mach-at91/at91_shdwc.h index 60478ea..9e29f31 100644 --- a/arch/arm/mach-at91/at91_shdwc.h +++ b/arch/arm/mach-at91/at91_shdwc.h @@ -23,7 +23,7 @@ extern void __iomem *at91_shdwc_base; __raw_readl(at91_shdwc_base + field) #define at91_shdwc_write(field, value) \ - __raw_writel(value, at91_shdwc_base + field); + __raw_writel(value, at91_shdwc_base + field) #endif #define AT91_SHDW_CR 0x00/* Shut Down Control Register */ diff --git a/arch/arm/mach-at91/at91x40_time.c b/arch/arm/mach-at91/at91x40_time.c index 0e57e44..f4c81c2 100644 --- a/arch/arm/mach-at91/at91x40_time.c +++ b/arch/arm/mach-at91/at91x40_time.c @@ -33,7 +33,7 @@ __raw_readl(AT91_IO_P2V(AT91_TC) + field) #define at91_tc_write(field, value) \ - __raw_writel(value, AT91_IO_P2V(AT91_TC) + field); + __raw_writel(value, AT91_IO_P2V(AT91_TC) + field) /* * 3 counter/timer units present. diff --git a/arch/arm/mach-at91/include/mach/at91_matrix.h b/arch/arm/mach-at91/include/mach/at91_matrix.h index 02fae9d..f8996c9 100644 --- a/arch/arm/mach-at91/include/mach/at91_matrix.h +++ b/arch/arm/mach-at91/include/mach/at91_matrix.h @@ -14,7 +14,7 @@ extern void __iomem *at91_matrix_base; __raw_readl(at91_matrix_base + field) #define at91_matrix_write(field, value) \ - __raw_writel(value, at91_matrix_base + field); + __raw_writel(value, at91_matrix_base + field) #else .extern at91_matrix_base diff --git a/arch/arm/mach-at91/include/mach/at91_st.h b/arch/arm/mach-at91/include/mach/at91_st.h index 969aac2..67fdbd1 100644 --- a/arch/arm/mach-at91/include/mach/at91_st.h +++ b/arch/arm/mach-at91/include/mach/at91_st.h @@ -23,7 +23,7 @@ extern void __iomem *at91_st_base; __raw_readl(at91_st_base + field) #define at91_st_write(field, value) \ - __raw_writel(value, at91_st_base + field); + __raw_writel(value, at91_st_base + field) #else .extern at91_st_base #endif -- 1.8.1.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: [RFC PATCH arm: initial TI-Nspire support]
On Sunday 07 April 2013, Daniel Tang wrote:
> On 07/04/2013, at 12:24 AM, Arnd Bergmann wrote:
> >
> >> @@ -313,7 +314,7 @@ define archhelp
> >> echo ' Image - Uncompressed kernel image
> >> (arch/$(ARCH)/boot/Image)'
> >> echo '* xipImage - XIP kernel image, if configured
> >> (arch/$(ARCH)/boot/xipImage)'
> >> echo ' uImage- U-Boot wrapped zImage'
> >> - echo ' bootpImage- Combined zImage and initial RAM disk'
> >> + echo ' bootpImage- Combined zImage and initial RAM disk'
> >> echo ' (supply initrd image via make variable
> >> INITRD=)'
> >> echo '* dtbs - Build device tree blobs for enabled boards'
> >> echo ' install - Install uncompressed kernel'
> >
> > This looks like it wasn't meant to be in the patch.
>
> It probably isn't. I think there was trailing whitespace on that and my
> editor happened to remove it automatically.
>
> Should this be a separate patch to fix up formatting or should I leave it in
> as a drive-by fix?
Any cleanups like this should be separate patches, and ideally even
part of a different patch series.
> >
> >> + uart: uart@9002 {
> >> + reg = <0x9002 0x1000>;
> >> + interrupts = <1>;
> >> +
> >> + clocks = <_clk>;
> >> + clock-names = "uart_clk";
> >> + };
> >
> > The name for a uart should be "serial". Since this is a pl01x, please add
> > the required properties for the device, e.g.
> >
> > compatible = "arm,pl011", "arm,primecell";
> >
> > You will need the "arm,primecell" bit to make the device appear on the
> > amba bus rather than the platform bus.
>
> That was actually deliberate because different models of the TI-NSPIRE have
> different
> serial hardware. On the newer CX models, it is a PL01x and on the older
> models, it has
> a 8250-like interface. They all reside at the same address with the same IRQ
> though.
>
> I thought it might be cleaner to specify the interrupts and registers in the
> common file
> and leave it to the board specific ones to implement the "compatible"
> property.
I see. It seems a little confusing to the reader though. I don't have a good
answer,
but there are two other options how this can be handled:
* Put both devices in the devicetree and mark them as status="disabled" in the
main file,
but enable one of them in the version specific files.
* leave them out of the .dtsi file and only define them in the specific .dts
files.
> >> + err = of_property_read_string(of_aliases, "timer0", );
> >> + if (WARN_ON(err))
> >> + return;
> >> +
> >> + timer = of_find_node_by_path(path);
> >> + base = of_iomap(timer, 0);
> >> + if (WARN_ON(!base))
> >> + return;
> >> +
> >> + clk = of_clk_get_by_name(timer, NULL);
> >> + clk_register_clkdev(clk, timer->name, "sp804");
> >> +
> >> + sp804_clocksource_init(base, timer->name);
> >> +
> >> + err = of_property_read_string(of_aliases, "timer1", );
> >> + if (WARN_ON(err))
> >> + return;
> >
> > In particular, I think the method of using aliases to pick the right sp804
> > instance is being deprecated now. If both timers are identical, the kernel
> > will now just pick one of them.
>
> Sorry, I don't quite understand.
>
> Out of the timers, I want to add one as a clocksource and one as a clockevent.
> If they're identical (i.e. without using aliases), how should I tell the
> kernel,
> "Take the first timer you see and make it a clocksource, take the next one you
> see and make it a clockevent"?
The modified sp804 driver will have logic to do that. I think in the end we
decided that the driver should first look for any device that can be used as
a clocksource and use it that way. If it finds a second device, that can be
used as clockevent.
Arnd
--
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] kernel: module: strncpy issue, using strlcpy instead of strncpy
On Sun, Apr 7, 2013 at 1:38 PM, Chen Gang wrote:
> ownername and namebuf are all NUL terminated string.
>
> need always let them ended by '\0'.
>
> Signed-off-by: Chen Gang
> ---
> kernel/module.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 3c2c72d..597efd8 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
> }
> /* Make a copy in here where it's safe */
> if (ret) {
> - strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
> + strlcpy(namebuf, ret, KSYM_NAME_LEN);
> ret = namebuf;
> }
> preempt_enable();
Is this buffer ever copied to userspace?
If yes, it may leak innocent kernel stack to userspace, as strlcpy()
doesn't fill
the remaining of the buffer with zeroes, while strncpy() does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] uprobes/tracing: Change create_trace_uprobe() to support uretprobes
* Oleg Nesterov [2013-04-01 18:09:00]:
> Finally change create_trace_uprobe() to check if argv[0][0] == 'r'
> and pass the correct "is_ret" to alloc_trace_uprobe().
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> kernel/trace/trace_uprobe.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 1b3622a..2773d2a 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -200,7 +200,7 @@ end:
>
> /*
> * Argument syntax:
> - * - Add uprobe: p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS]
> + * - Add uprobe: p|r[:[GRP/]EVENT] PATH:SYMBOL [FETCHARGS]
> *
> * - Remove uprobe: -:[GRP/]EVENT
> */
> @@ -212,20 +212,23 @@ static int create_trace_uprobe(int argc, char **argv)
> char buf[MAX_EVENT_NAME_LEN];
> struct path path;
> unsigned long offset;
> - bool is_delete;
> + bool is_delete, is_return;
> int i, ret;
>
> inode = NULL;
> ret = 0;
> is_delete = false;
> + is_return = false;
> event = NULL;
> group = NULL;
>
> /* argc must be >= 1 */
> if (argv[0][0] == '-')
> is_delete = true;
> + else if (argv[0][0] == 'r')
> + is_return = true;
> else if (argv[0][0] != 'p') {
> - pr_info("Probe definition must be started with 'p' or '-'.\n");
> + pr_info("Probe definition must be started with 'p', 'r' or
> '-'.\n");
> return -EINVAL;
> }
>
> @@ -323,7 +326,7 @@ static int create_trace_uprobe(int argc, char **argv)
> kfree(tail);
> }
>
> - tu = alloc_trace_uprobe(group, event, argc, false);
> + tu = alloc_trace_uprobe(group, event, argc, is_return);
> if (IS_ERR(tu)) {
> pr_info("Failed to allocate trace_uprobe.(%d)\n",
> (int)PTR_ERR(tu));
> ret = PTR_ERR(tu);
> --
> 1.5.5.1
>
--
Thanks and Regards
Srikar Dronamraju
--
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 5/6] uprobes/tracing: Make seq_printf() code uretprobe-friendly
* Oleg Nesterov [2013-04-01 18:08:57]:
> Change probes_seq_show() and print_uprobe_event() to check
> is_ret_probe() and print the correct data.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> kernel/trace/trace_uprobe.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index f75e52d..1b3622a 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -434,9 +434,10 @@ static void probes_seq_stop(struct seq_file *m, void *v)
> static int probes_seq_show(struct seq_file *m, void *v)
> {
> struct trace_uprobe *tu = v;
> + char c = is_ret_probe(tu) ? 'r' : 'p';
> int i;
>
> - seq_printf(m, "p:%s/%s", tu->call.class->system, tu->call.name);
> + seq_printf(m, "%c:%s/%s", c, tu->call.class->system, tu->call.name);
> seq_printf(m, " %s:0x%p", tu->filename, (void *)tu->offset);
>
> for (i = 0; i < tu->nr_args; i++)
> @@ -569,10 +570,18 @@ print_uprobe_event(struct trace_iterator *iter, int
> flags, struct trace_event *e
> entry = (struct uprobe_trace_entry_head *)iter->ent;
> tu = container_of(event, struct trace_uprobe, call.event);
>
> - if (!trace_seq_printf(s, "%s: (0x%lx)", tu->call.name, entry->vaddr[0]))
> - goto partial;
> + if (is_ret_probe(tu)) {
> + if (!trace_seq_printf(s, "%s: (0x%lx <- 0x%lx)", tu->call.name,
> + entry->vaddr[1], entry->vaddr[0]))
> + goto partial;
> + data = DATAOF_TRACE_ENTRY(entry, 2);
> + } else {
> + if (!trace_seq_printf(s, "%s: (0x%lx)", tu->call.name,
> + entry->vaddr[0]))
> + goto partial;
> + data = DATAOF_TRACE_ENTRY(entry, 1);
> + }
>
> - data = DATAOF_TRACE_ENTRY(entry, 1);
> for (i = 0; i < tu->nr_args; i++) {
> if (!tu->args[i].type->print(s, tu->args[i].name,
>data + tu->args[i].offset, entry))
> --
> 1.5.5.1
>
--
Thanks and Regards
Srikar Dronamraju
--
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 4/6] uprobes/tracing: Make register_uprobe_event() paths uretprobe-friendly
* Oleg Nesterov [2013-04-01 18:08:54]:
> Change uprobe_event_define_fields(), and __set_print_fmt() to check
> is_ret_probe() and use the appropriate format/fields.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> kernel/trace/trace_uprobe.c | 19 +++
> 1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index db2718a..f75e52d 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -631,8 +631,14 @@ static int uprobe_event_define_fields(struct
> ftrace_event_call *event_call)
> struct uprobe_trace_entry_head field;
> struct trace_uprobe *tu = event_call->data;
>
> - DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_IP, 0);
> - size = SIZEOF_TRACE_ENTRY(1);
> + if (is_ret_probe(tu)) {
> + DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_FUNC, 0);
> + DEFINE_FIELD(unsigned long, vaddr[1], FIELD_STRING_RETIP, 0);
> + size = SIZEOF_TRACE_ENTRY(2);
> + } else {
> + DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_IP, 0);
> + size = SIZEOF_TRACE_ENTRY(1);
> + }
> /* Set argument names as fields */
> for (i = 0; i < tu->nr_args; i++) {
> ret = trace_define_field(event_call, tu->args[i].type->fmttype,
> @@ -655,8 +661,13 @@ static int __set_print_fmt(struct trace_uprobe *tu, char
> *buf, int len)
> int i;
> int pos = 0;
>
> - fmt = "(%lx)";
> - arg = "REC->" FIELD_STRING_IP;
> + if (is_ret_probe(tu)) {
> + fmt = "(%lx <- %lx)";
> + arg = "REC->" FIELD_STRING_FUNC ", REC->" FIELD_STRING_RETIP;
> + } else {
> + fmt = "(%lx)";
> + arg = "REC->" FIELD_STRING_IP;
> + }
>
> /* When len=0, we just calculate the needed length */
>
> --
> 1.5.5.1
>
--
Thanks and Regards
Srikar Dronamraju
--
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 2/6] uprobes/tracing: Introduce is_ret_probe() and uretprobe_dispatcher()
* Oleg Nesterov [2013-04-01 18:08:48]:
> Create the new functions we need to support uretprobes, and change
> alloc_trace_uprobe() to initialize consumer.ret_handler if the new
> "is_ret" argument is true. Curently this argument is always false,
> so the new code is never called and is_ret_probe(tu) is false too.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> kernel/trace/trace_uprobe.c | 42 --
> 1 files changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 2ea9961..e91a354 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -75,6 +75,8 @@ static DEFINE_MUTEX(uprobe_lock);
> static LIST_HEAD(uprobe_list);
>
> static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs
> *regs);
> +static int uretprobe_dispatcher(struct uprobe_consumer *con,
> + unsigned long func, struct pt_regs *regs);
>
> static inline void init_trace_uprobe_filter(struct trace_uprobe_filter
> *filter)
> {
> @@ -88,11 +90,16 @@ static inline bool uprobe_filter_is_empty(struct
> trace_uprobe_filter *filter)
> return !filter->nr_systemwide && list_empty(>perf_events);
> }
>
> +static inline bool is_ret_probe(struct trace_uprobe *tu)
> +{
> + return tu->consumer.ret_handler != NULL;
> +}
> +
> /*
> * Allocate new trace_uprobe and initialize it (including uprobes).
> */
> static struct trace_uprobe *
> -alloc_trace_uprobe(const char *group, const char *event, int nargs)
> +alloc_trace_uprobe(const char *group, const char *event, int nargs, bool
> is_ret)
> {
> struct trace_uprobe *tu;
>
> @@ -117,6 +124,8 @@ alloc_trace_uprobe(const char *group, const char *event,
> int nargs)
>
> INIT_LIST_HEAD(>list);
> tu->consumer.handler = uprobe_dispatcher;
> + if (is_ret)
> + tu->consumer.ret_handler = uretprobe_dispatcher;
> init_trace_uprobe_filter(>filter);
> return tu;
>
> @@ -314,7 +323,7 @@ static int create_trace_uprobe(int argc, char **argv)
> kfree(tail);
> }
>
> - tu = alloc_trace_uprobe(group, event, argc);
> + tu = alloc_trace_uprobe(group, event, argc, false);
> if (IS_ERR(tu)) {
> pr_info("Failed to allocate trace_uprobe.(%d)\n",
> (int)PTR_ERR(tu));
> ret = PTR_ERR(tu);
> @@ -529,6 +538,12 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
> return 0;
> }
>
> +static void uretprobe_trace_func(struct trace_uprobe *tu, unsigned long func,
> + struct pt_regs *regs)
> +{
> + uprobe_trace_print(tu, func, regs);
> +}
> +
> /* Event entry printers */
> static enum print_line_t
> print_uprobe_event(struct trace_iterator *iter, int flags, struct
> trace_event *event)
> @@ -799,6 +814,12 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
> uprobe_perf_print(tu, 0, regs);
> return 0;
> }
> +
> +static void uretprobe_perf_func(struct trace_uprobe *tu, unsigned long func,
> + struct pt_regs *regs)
> +{
> + uprobe_perf_print(tu, func, regs);
> +}
> #endif /* CONFIG_PERF_EVENTS */
>
> static
> @@ -853,6 +874,23 @@ static int uprobe_dispatcher(struct uprobe_consumer
> *con, struct pt_regs *regs)
> return ret;
> }
>
> +static int uretprobe_dispatcher(struct uprobe_consumer *con,
> + unsigned long func, struct pt_regs *regs)
> +{
> + struct trace_uprobe *tu;
> +
> + tu = container_of(con, struct trace_uprobe, consumer);
> +
> + if (tu->flags & TP_FLAG_TRACE)
> + uretprobe_trace_func(tu, func, regs);
> +
> +#ifdef CONFIG_PERF_EVENTS
> + if (tu->flags & TP_FLAG_PROFILE)
> + uretprobe_perf_func(tu, func, regs);
> +#endif
> + return 0;
> +}
> +
> static struct trace_event_functions uprobe_funcs = {
> .trace = print_uprobe_event
> };
> --
> 1.5.5.1
>
--
Thanks and Regards
Srikar Dronamraju
--
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][PATCH 0/9] extend hugepage migration
>> Please refer to hugetlb_fault for more information. > > Thanks for your pointing out. So my assume is correct, is it? Can pmd > which support 2MB map 32MB pages work well? Simon, Please stop hijaking unrelated threads. This is not question and answer thread. -- 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/6] uprobes/tracing: Introduce uprobe_{trace,perf}_print() helpers
* Oleg Nesterov [2013-04-01 18:08:45]:
> Extract the output code from uprobe_trace_func() and uprobe_perf_func()
> into the new helpers, they will be used by ->ret_handler() too. We also
> add the unused "unsigned long func" argument in advance, to simplify the
> next changes.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> kernel/trace/trace_uprobe.c | 29 -
> 1 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 92a4b08..2ea9961 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -496,8 +496,8 @@ static const struct file_operations uprobe_profile_ops = {
> .release= seq_release,
> };
>
> -/* uprobe handler */
> -static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs *regs)
> +static void uprobe_trace_print(struct trace_uprobe *tu,
> + unsigned long func, struct pt_regs *regs)
> {
> struct uprobe_trace_entry_head *entry;
> struct ring_buffer_event *event;
> @@ -510,7 +510,7 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
> event = trace_current_buffer_lock_reserve(, call->event.type,
> size, 0, 0);
> if (!event)
> - return 0;
> + return;
>
> entry = ring_buffer_event_data(event);
> entry->vaddr[0] = instruction_pointer(regs);
> @@ -520,7 +520,12 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
>
> if (!filter_current_check_discard(buffer, call, entry, event))
> trace_buffer_unlock_commit(buffer, event, 0, 0);
> +}
>
> +/* uprobe handler */
> +static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs *regs)
> +{
> + uprobe_trace_print(tu, 0, regs);
> return 0;
> }
>
> @@ -753,8 +758,8 @@ static bool uprobe_perf_filter(struct uprobe_consumer *uc,
> return ret;
> }
>
> -/* uprobe profile handler */
> -static int uprobe_perf_func(struct trace_uprobe *tu, struct pt_regs *regs)
> +static void uprobe_perf_print(struct trace_uprobe *tu,
> + unsigned long func, struct pt_regs *regs)
> {
> struct ftrace_event_call *call = >call;
> struct uprobe_trace_entry_head *entry;
> @@ -763,13 +768,10 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
> void *data;
> int size, rctx, i;
>
> - if (!uprobe_perf_filter(>consumer, 0, current->mm))
> - return UPROBE_HANDLER_REMOVE;
> -
> size = SIZEOF_TRACE_ENTRY(1);
> size = ALIGN(size + tu->size + sizeof(u32), sizeof(u64)) - sizeof(u32);
> if (WARN_ONCE(size > PERF_MAX_TRACE_SIZE, "profile buffer not large
> enough"))
> - return 0;
> + return;
>
> preempt_disable();
> entry = perf_trace_buf_prepare(size, call->event.type, regs, );
> @@ -786,6 +788,15 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
> struct pt_regs *regs)
> perf_trace_buf_submit(entry, size, rctx, ip, 1, regs, head, NULL);
> out:
> preempt_enable();
> +}
> +
> +/* uprobe profile handler */
> +static int uprobe_perf_func(struct trace_uprobe *tu, struct pt_regs *regs)
> +{
> + if (!uprobe_perf_filter(>consumer, 0, current->mm))
> + return UPROBE_HANDLER_REMOVE;
> +
> + uprobe_perf_print(tu, 0, regs);
> return 0;
> }
> #endif /* CONFIG_PERF_EVENTS */
> --
> 1.5.5.1
>
--
Thanks and Regards
Srikar Dronamraju
--
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] do not try to sync identity map for non-mapped pages
Hey Dave, On Thu, Mar 07, 2013 at 08:31:51AM -0800, Dave Hansen wrote: > > The original bug reporter says this fixes it for him, so I'm > broadening the cc list a bit. I assume this should just get > sucked in to the x86 tree. looks like we haven't whacked all the moles - I keep seeing this when testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is still that /dev/mem accessing thing called wdm. I'm still wondering though whether we should BUG_ON on a /dev/mem access? I've added debug output to show why we're triggering: [ 471.102902] slow_virt_to_phys((void *)x): 0x0, phys_addr: 0x37bfe000 [ 471.119500] [ cut here ] [ 471.119500] kernel BUG at arch/x86/mm/physaddr.c:85! [ 471.119500] invalid opcode: [#1] PREEMPT SMP [ 471.119500] Modules linked in: [ 471.119500] Pid: 1571, comm: wdm Not tainted 3.9.0-rc5+ #42 Bochs Bochs [ 471.119500] EIP: 0060:[] EFLAGS: 0206 CPU: 0 [ 471.119500] EIP is at __phys_addr+0x86/0xb0 [ 471.119500] EAX: 37bfe000 EBX: 37bfe000 ECX: 0001 EDX: 37bfe000 [ 471.119500] ESI: f7bfe000 EDI: 2000 EBP: f67f1f3c ESP: f67f1f28 [ 471.119500] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 471.119500] CR0: 8005003b CR2: bfeb12d4 CR3: 35edd000 CR4: 06f0 [ 471.119500] DR0: DR1: DR2: DR3: [ 471.119500] DR6: DR7: [ 471.119500] Process wdm (pid: 1571, ti=f67f task=f5c9 task.ti=f67f) [ 471.119500] Stack: [ 471.119500] c16b1f2c 37bfe000 2000 f67f1f64 c131d074 2000 [ 471.119500] 0246 bfeb12ec f67a6c40 c131d040 2000 f67f1f8c [ 471.119500] c1129c85 f67f1f98 f67f f5ebe864 c131d040 0020 f67a6c40 [ 471.119500] Call Trace: [ 471.119500] [] read_mem+0x34/0x100 [ 471.119500] [] ? write_mem+0x110/0x110 [ 471.119500] [] vfs_read+0x85/0x130 [ 471.119500] [] ? write_mem+0x110/0x110 [ 471.119500] [] sys_read+0x47/0xa0 [ 471.119500] [] sysenter_do_call+0x12/0x36 [ 471.119500] Code: 0b a1 88 ae 0c c2 05 00 00 80 00 39 c6 72 bb a1 ac 1a 76 c1 2d 00 a0 3e 00 25 00 00 e0 ff 2d 00 20 00 00 39 c6 73 a3 0f 0b 0f 0b <0f> 0b 89 f0 e8 41 ca ff ff 89 5c 24 08 89 44 24 04 c7 04 24 2c [ 471.119500] EIP: [] __phys_addr+0x86/0xb0 SS:ESP 0068:f67f1f28 [ 471.508967] ---[ end trace 5fc00ac35d61284a ]--- Hmmm. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
AMD Vi error and lost networking with r8169
I'm been seeing some problems with my new ish AMD motherboard/processor combo and networking (r8169). I see the following page fault :- Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 flags=0x0050] Followed by the transmit queue timing out. This seems to hit randomly, sometimes it can take a day or so. A hard reset is the only way to recover networking. (Userspace is Ubuntu 10.04, kernel 3.9.0 rc5+) Cheers David Apr 7 12:26:09 david kernel: [156475.568257] [ cut here ] Apr 7 12:26:09 david kernel: [156475.568273] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x250/0x260() Apr 7 12:26:09 david kernel: [156475.568278] Hardware name: To be filled by O.E.M. Apr 7 12:26:09 david kernel: [156475.568282] NETDEV WATCHDOG: eth2 (r8169): transmit queue 0 timed out Apr 7 12:26:09 david kernel: [156475.568285] Modules linked in: xfs exportfs libcrc32c nls_iso8859_1 nls_cp437 vfat fat ecryptfs encrypted_keys nfsv3 nfs_acl nfs lockd sunrpc binfmt_misc ppdev dm_crypt hid_logitech uvcvideo ff_memless videobuf2_core videodev snd_usb_audio videobuf2_vmalloc snd_usbmidi_lib videobuf2_memops usbhid snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_seq_dummy snd_hwdep snd_seq_oss fbcon ttm tileblit font bitblit snd_pcm_oss softcursor snd_seq_midi drm_kms_helper snd_rawmidi snd_mixer_oss drm snd_seq_midi_event crc32_pclmul serio_raw snd_pcm snd_seq i2c_piix4 r8169 snd_timer snd_seq_device mii snd i2c_algo_bit soundcore snd_page_alloc lp parport Apr 7 12:26:09 david kernel: [156475.568348] Pid: 0, comm: swapper/0 Not tainted 3.9.0-rc5+ #17 Apr 7 12:26:09 david kernel: [156475.568351] Call Trace: Apr 7 12:26:09 david kernel: [156475.568354] [] warn_slowpath_common+0x7a/0xc0 Apr 7 12:26:09 david kernel: [156475.568366] [] warn_slowpath_fmt+0x41/0x50 Apr 7 12:26:09 david kernel: [156475.568374] [] dev_watchdog+0x250/0x260 Apr 7 12:26:09 david kernel: [156475.568380] [] ? __netdev_watchdog_up+0x80/0x80 Apr 7 12:26:09 david kernel: [156475.568386] [] call_timer_fn+0x44/0x120 Apr 7 12:26:09 david kernel: [156475.568391] [] ? __netdev_watchdog_up+0x80/0x80 Apr 7 12:26:09 david kernel: [156475.568396] [] run_timer_softirq+0x213/0x280 Apr 7 12:26:09 david kernel: [156475.568402] [] __do_softirq+0xdf/0x260 Apr 7 12:26:09 david kernel: [156475.568408] [] irq_exit+0xb5/0xc0 Apr 7 12:26:09 david kernel: [156475.568413] [] smp_apic_timer_interrupt+0x69/0xa0 Apr 7 12:26:09 david kernel: [156475.568418] [] apic_timer_interrupt+0x6a/0x70 Apr 7 12:26:09 david kernel: [156475.568420] [] ? sched_clock_cpu+0xc5/0x100 Apr 7 12:26:09 david kernel: [156475.568432] [] ? cpuidle_wrap_enter+0x42/0x80 Apr 7 12:26:09 david kernel: [156475.568437] [] ? cpuidle_wrap_enter+0x3e/0x80 Apr 7 12:26:09 david kernel: [156475.568443] [] cpuidle_enter_tk+0x10/0x20 Apr 7 12:26:09 david kernel: [156475.568448] [] cpuidle_enter_state+0x12/0x50 Apr 7 12:26:09 david kernel: [156475.568453] [] cpuidle_idle_call+0xa2/0x100 Apr 7 12:26:09 david kernel: [156475.568459] [] cpu_idle+0xc7/0x120 Apr 7 12:26:09 david kernel: [156475.568463] [] rest_init+0x6d/0x80 Apr 7 12:26:09 david kernel: [156475.568470] [] start_kernel+0x3b6/0x3c3 Apr 7 12:26:09 david kernel: [156475.568475] [] ? repair_env_string+0x5b/0x5b Apr 7 12:26:09 david kernel: [156475.568481] [] x86_64_start_reservations+0x2a/0x2c Apr 7 12:26:09 david kernel: [156475.568486] [] x86_64_start_kernel+0x129/0x130 Apr 7 12:26:09 david kernel: [156475.568489] ---[ end trace 31688db2ca49b077 ]--- Apr 7 12:26:09 david kernel: [156475.720834] r8169 :02:00.0 eth2: link up dmesg.log.bz2 Description: application/bzip config.bz2 Description: application/bzip
